VL53L1X for people counting algorithm

[LNGUY.1]

I'm trying to use VL53L1X for counting algorithm in the link: https://www.youtube.com/watch?v=c91Ve-g0J2U but I'm having a problem with accuracy.

Thanks to SparkFun_VL53L1X, I can set ROI centers to separate front/back zones. By measuring and analyzing the distances of targets within field of views of these zones, the main idea for counting algorithm is described in this link: https://www.st.com/resource/en/user_manual/dm00626942-counting-people-with-the-vl53l1x-longdistance-ranging-timeofflight-sensor-stmicroelectronics.pdf 

However, I am facing to a big problem according to the accuracy of distances. Even when I fixed the distances from sensor to ground, the received distances is fluctuating. Currently, I set sensor's position 2.3 m from the ground as well as ROI centers in (159, 231), 50ms for each loop but the result obtained while having someone cross the door isn't as expected(should be like the image below).

The normal case: obtained the same distances to front/back zones even when having someone in front zone or back zone. 

Have you ever faced this problem and can you please suggest a way to improve this case?

I'm also planning to test with 1 more sensor, it should be better but I'm not sure that it can work well. 

Thank you and best regards,

L-T-P NGUYEN

[John E KVAM]

50ms is too long of a period. In 50ms you will only get maybe one sample of someone in each zone. But probably you will see the person show up in both zones.

Try setting your timing budget to 15ms.

If you can see the floor at this Timing budget you will do better.

• john

[LNGUY.1]

Thank you for your reply,

I understand your idea, may be it take up to 100ms to have each results. If the duration for each person passing to the door is around 500ms, I could only obtain around 5 samples, not enough for this algorithm. But I saw in ST's manual for this sensor, the timing budget should be set from 20ms up to 1000ms( recommendation is 33ms for all distance). It's not too much improvement. But I still don't know how ST can obtain too many samples (the image below)as in their paper. I try to reduce timing budget but can't be obtained lots of sample like them.

[John E KVAM]

In the UltraLite Driver - which I believe you are using there is a setting for 15ms.

that's what we used in the demo software.

It should work for you too.

• john

[HMull.1]

Correct me if I'm wrong, but the 15ms timing budget will only work in short distance mode? OP stated that the required height is set at 2.3m which means the sensor should be set in long distance mode. I think timing budget should then be set to 20ms.

[John E KVAM]

On ST.com search for “people counting�?

You will get:

STSW-IMG010

ACTIVE

Embedded Software

Proximity Sensors Software

PEOPLE COUNTING SW code example for VL53L1X

It should have everything figured out for you. It's our example code.

And you are right, I remembered 15ms but not the Short mode only requirement.

[Yle.1]

try set roi center (167,231)

[Julien NGUYEN]

Hi Yle.1,

You are on the right path ! Actually, we are working to improve the people counting example code we provided. I observed that shifting lightly the "theoretical" center I got better signal rate => better detection reliability. The code should be released as soon as we finished to update the user manual.

(175,231) is the best centers couple which give the best detection rate.

#define FRONT_ZONE_CENTER              175 // was 167, see UM2555 on st.com, center = 175 has better return signal rate for the ROI #1

#define BACK_ZONE_CENTER               231 

Concerning the ranging speed, there is no need to go fast for people counting use case. Knowing that the average walking speed is 4~6 KM/ hour. To cross the two areas of the sensor you may need 500 ms or 300 ms depending on the distance between the sensor and the walking people, so setting the timing budget = inter-measurement period = 33 ms you can get up to 15 samples or 10 samples. It is enough, increasing a little bit the timing budget from 20 ms to 33 ms allows the sensor to range with better accuracy avoiding wrong interpretation.

Julien

[Yle.1]

Yes, I've tested setting up a lot of different ROI centers. The result is that the center of ROI has a great impact on the accuracy of the data. I just looked at um2555, but I didn't see a description of the signal rate and ROI. The ROI area I'm currently using is 5x5, with 167 and 275 centers. If according to your setting, should the area size be set to 8x8?

[Julien NGUYEN]

​Hi Yle,

You can use this function      status = VL53L1X_GetSignalRate(dev, &SignalRate) to get the signal rate. The signal rate tells you the quantity of photons coming back from a target. The more the signal rate is, the more the accuracy is. We use two ROIs 8x16 (large x height). For me, you shouldn't  decrease more the ROI size, because you will lose in sensitivity, in fact the receiver area is smaller in 5x5 than 8x16. The reason why you set smaller ROIs is two separate the two detection zones? What is your application, people counting or other ?

Julien  

[Yle.1]

My application is people counting too.Because when I test the STSW-IMG010's setting,it didn't work fine.I think maybe my door frame is too narrow to affect the validity of the data,so I decrease the ROI size. As I expected,using two ROIs 5x5 is work fine.I don't konw why does ROI center affect signal rate.As you said, 33ms is enough to get samples. So why change to 175 will be better?

[HMull.1]

Hi Julien,

I am with Yle here in that I also set my two people counting detection zones to a smaller size. I found that the default (8,16) zones provided poor accuracy (lots of variation in the distance measurement) when used in a normal doorway width (about 2,7m height). I use an "auto calibration" feature where I adjust the ROI sizes and capture data after each adjustment. The ROI size that provides the best repeatable accuracy is then chosen. Currently I have chosen (4,10) for the use case.

I have set timing budget and inter measurement to 50ms because the Lite driver only provides 20ms and 50ms setting, not 33ms.

I will try the new centers.

Yle, I also do something that one of the app notes described (maybe I did not understand it correctly and maybe Julien can comment?):

I keep a rolling window of X distance samples. X is currently set to 5 in my case. In other words I capture 5 distance readings and keep it in memory. As soon as a new reading is done, the oldest reading is forgotten (pushed out of the buffer).

I take the smallest distance reading of the 5 readings in memory and pass that value to the people counting algorithm. I found that this provided some stability...albeit minor. Julien, did I misunderstand the intention here?

Helgard

[Yle.1]

My application is people counting too.Because when I test the STSW-IMG010's setting,it didn't work fine.I think maybe my door frame is too narrow to affect the validity of the data,so I decrease the ROI size. As I expected,using two ROIs 5x5 is work fine.I don't konw why does ROI center affect signal rate.As you said, 33ms is enough to get samples. So why change to 175 will be better?

[Julien NGUYEN]

​Hi Helgard and Yle,

I think we have three main sensor parameters two adjust according to his own use case (ROI size, ROI Center, Timing Budget).

In your use case, it seems that you have narrow width door, and to avoid to sense on the door frame you need to reduce the ROI size (FoV). In my case, I have a large door (2.3 m Height and 1.3 m large) so I need to have the best sensitivity to detect even a small person or child 1.5 m.

Another factor, It seems that the center could be different from part to part so adding a kind of center calibration as you did is very smart. Last comment on what Helgard said about the last 5 reading in a buffer, it is similar to the algo implemented by a colleague in the new people counting release we are preparing.

So different ideas seem to converge. Concerning the timing budget don't forget to set the Inter-measurement period consequently otherwise you will not get as much as samples you think . Inter-measurement period = timing budget. You may probe the interrupt signal from the PIN3 of the Arduino connector CN8 on the expansion board to check the inter-measurement period. With the VL53L1X ULD driver you should be able to set the Timing budget at 33 ms (see api.c) . Thanks, Julien

[HMull.1]

Hi Julien,

Thanks for your reply. I see that 33ms is an option in the ULD.

I actually meant that I adjust the two ROI and not the centers. But I see here now that the centers actually can make quite a difference so I will try to make that part of my calibration process.

If I want to adjust the center values for a typical doorway people counting application, is there a range in which I can adjust? For example...you suggested 175,231 as a good value. I'm struggling to understand what exactly those values mean in practice....but anyway, so if I want to test and calibrate the center values, I assume I will test values around those "ideal" values. My question is, where do I stop? In what range around those values do I test?

Helgard

[Yle.1]

Maybe as julien said you should use status = VL53L1X_GetSignalRate(dev, &SignalRate) to get the signal rate and test the different center’s signal rate?

I'm very interested in your auto calibration function. How does it work?

[HMull.1]

Hi Yle,

I take a series of distance measurements and try to minimize the variance in the data. In other words: If I take 5 measurements and the distance readings are 2000, 2100, 2500, 1800, 2700 I know that there is too much variance. You should probably take more readings but this was just to serve as an example.

After determining that I need improved accuracy, I start to adjust the ROI. Based on the info above, I have also started to adjust the center variables in conjunction with the ROI. All just to get accurate, repeatable distance readings. These adjustments can be made quite quickly and you could code a small algorithm to settle on the best combination; Check distance reading variance, adjust, check again, adjust, etc.

Note that I do believe it will be best to keep the timing budget constant as Julien mentioned.

You will also have to be smart in your ROI and center variable choices. Keep in mind height and width of a door entry ways and the way it affects distance readings. Also keep in mind things like light/dark environments. Keep in mind that your centers should not deviate too much from what ST provides because the state machine relies on detecting objects in both ROIs (at the same time) as shown in the first post above.

You could probably determine accuracy with the GetSignalRate function as well (instead of relying on the distance measurements)