Maybe use a new people counting algorithm

[leyuansugar]

Is your feature request related to a problem? Please describe. In this version, the counting algorithm is derived from gesture direction recognition algorithm. In some practical situations, it will be inaccurate. For example, if a person walks from the outside to the room, stays near the sensor, does not enter the room and then turns out, the sensor will mistakenly believe that someone has entered the room.

Describe the solution you'd like Use st's people counting algorithm.

Describe alternatives you've considered My coding is very bad.I tried to convert ST's stm32 people counting code to esp32 code,but I failed. Maybe you can try this.

Additional context FYI St's source code: https://www.st.com/en/embedded-software/stsw-img010.html stm32 to esp32 example:https://github.com/kazkojima/esp32-vl53l1x-test

[Lyr3x]

The code already handle the situation that you partly go into the sensor and go back in the other direction. Interesting that ST themselves published the adapted direction detection! Will look into it, if there is anything special that might help. Thanks for the heads up!

[leyuansugar]

Yes. I check the code and test the situation,but the results were not very satisfactory. When I go into the sensor(into detection area), and go back,the num of people will add.Every time I do this test,it will add 1 people num. I already test the st's algorithm with vl53l1x and esp32,it's worked fine. If there is any help,I can sent the arduino code of this to you.Maybe you can add to your roode project. I think the esp-idf is better than arduino-ide,but my coding skill is bad.Maybe you can do this.

[markjones89]

For interest here is a very similar project using the ST code https://github.com/Andrea-Fox/peopleCounter

[Lyr3x]

I will start working on Roode again. And check the latest ST code. However i cant reproduce the behavior you describe @leyuansugar The ST code does not something special detection wise. However it is indeed a simpler implementation

[leyuansugar]

@Lyr3x Just go into the sensor(into detection area), and go back，do not leave the testing area during the entire process。

[Lyr3x]

I know what you mean because I worked a lot on that particular issue, and it is working fine for my setup. But I know that the positioning as well as surfaces makes a huge difference in accuracy. nevertheless, I will take a look into the ST lib and will switch my own MQTT implementation to esphome.

If you like to support, I ham happy to accept PRs

Sent with a Spark Am 10. Aug. 2021, 10:38 +0200 schrieb leyuansugar @.***>:

@Lyr3x Just go into the sensor(into detection area), and go back，do not leave the testing area during the entire process。 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Lyr3x]

I'll update the issue if I have something to test :) thank you for your hint!

[leyuansugar]

Ok, ST updated the code for the headcount some time ago, you can see it here https://www.st.com/en/embedded-software/stsw-img010.html My suggestion is to migrate the algorithm for this code to esp32, I tried it and it worked well, but that was the first version and not this latest version of ST.

[Lyr3x]

Getting familiar with esphome atm and added a draft branch with esphome config and an improved algorithm. Thanks to @diplix who provided me his changes which is most of the new ST code. @leyuansugar Not sure if the branch is already working as expected (its compiling, but I didnt test it yet). However, feel free to try! I added the calibration again and removed old code. I will test that branch and fix stuff over the next days and then start to rework the algorithm. Feel free to submit PRs 👍

[aerodolphin]

That sensor works well but with too much light with the same spectrum (sun) will miss counting. Can you test that case?

[Lyr3x]

Makes sense, that's a sensors limitation which we can mitigate with a well designed housing. At least to a certain degree. Also you can change the Position of the Sensor. Where do you installed it?

The sensor emits a laser and 940nm waves are noise for the sensor. Too much sun light will bring the SNR down to a level where the return of the laser cannot be interpreted correctly.

Best way is do always locate the sensor in a fashion that it points down or away from the sun

[Lyr3x]

@leyuansugar Check the v1.1 branch. Would appreciate feedback

[leyuansugar]

@Lyr3x In long distance mode, the parameter setTimingBudgetInMs can be changed to 33 to get better performance. also in practice, different roi area settings can bring very different results, or you need to test the suitable roi area settings several times for different environments. i'm very sorry i don't have time to do some tests lately, i can only give you some of my experience from testing at that time.

[Lyr3x]

@leyuansugar Thanks for the hint. The old algorithm used 33ms (we can even go down to 22 without issues in short mode) but I missed to adapt that accordingly.

[Lyr3x]

Adapted all pieces to use the correct timings. Indeed it improved the latest version. Ofcours everyone needs to set up the personal ROI. That is nothing I can generally provide. The standard settings should work in most cases, like chest height wall to wall mount with ~1m distance