Kris WinerJanuary 26, 2020
I haven't posted anything on this project for a while as I was busy with other things. But I have recently had occasion to revisit and I have made some progress in understanding how best to use this device. The kind of testing I had been doing was either 1) looking at copious output on the serial monitor upon egress/ingress detection on the bench or 2) installing and simply using the device to count egress and ingress transits reported via LoRaWAN. The trouble is that things mostly work in mode 2) but when they didn't I couldn't really diagnose the problem.
For this round of tests, I mounted the device on the entrance way between our Hall and Dining Room where I work in such a way that I could maintain the serial tether to the laptop and record the details of the sensor device while I walked under the PeopleCounter. I streamed object temperature, object temperature theshold, and ingress and egress counts at rates from 10 - 80 Hz, captured the data from the serial monitor and plotted the data in a spreadsheet. This is a typical result:
The way the PeopleCounter works is that the sensors detect when a warm human crosses their line of sight, the time difference in the detection determines the direction of the transit. Simple. The sensors allow a threshold to be specified so that an interrupt is generated upon crossing the threshold, either upward or downward crossing. I have been using about 200 counts as an upper threshold to detect people crossing at a distance of ~1 - 2 foot from the sensors (where the head and shoulders are, more or less, when the device is mounted on an upper door jamb). The problem, as can easily be seen, is that the sensor responses drift, and if the baseline isn't corrected every so often, the drift will result in a large enough separation between the transit excursion and the threshold that it will never be crossed and the device will stop counting.
The threshold, then, has to be reset at a fast enough rate to keep track of any baseline drift but not too fast to cause a large power drain on the battery. But there is a problem here as well. If the threshold adjustment happens to coincide with a person transiting the device (as in the fourth peak in the figure), the baseline reset can be skewed upward. So some limit needs to be applied. Threshold management turns out to be critical to obtaining accurate performance. I expected this from the start, but didn't realize how difficult it would be to find a 100% accurate solution.
The good news is that the people counter accuracy is > 90% in simple tests that I can do around the house. We are about to test it "in the field" and will have data from more realistic deployments soon. I expect to learn a lot more about how such a device might behave in less controlled environments.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
@Kris Winer did the "variety of more complicated schemes" reveal any role for e.g. peak detection, gradient threshold (as opposed to absolute value threshold) or exponential moving average filters?
I wonder if this is a case where you could train an SVN such as in the recently linked article on machine learning on the ATtiny85 https://eloquentarduino.github.io/2019/12/machine-learning-on-attiny85/
Another thing I have been wondering is whether you could use a single sensor with an occlusion across the field of view that would effectively make it a "dual pinhole" camera. This is similar to how PIR thermopiles work - you can just place an opaque bar across the dividing line between the two sides of the thermopile window, at the correct distance, and it will behave as if it has a fresnel lens in place. Although direction of travel would be challenging to extract in this case (maybe with a reflector, or by angling the sensor, to make signal from one side stronger than the other)
Perhaps an autocorrelation algorithm could detect a time difference between similar peaks or even an "ideal" peak template held in memory.
Are you sure? yes | no
We have looked at moving averages as well as differntiating the signal to look for peaks and zero crossings. These all can be made to work. The downside is that the MCU has to be on to collect the data for this kind of processing, which costs power. Instead, we want the sensor ASIC to measure threshold crossing while the MCU sleeps and only wake the MCU to track transits in order to keep the power usage to a minimum. There is more advanced signal processing in these Calipiles we continue to try to exploit. The cost is increased complexity but if we can eliminate or reduce the threshold adjustment this might be a good trade. I don't think we will ever get away with just one sensor. Bottom line, simple methods that acceptably meet the requirements today are better than complex methods that might meet the requirements tomorrow. Still, we continue to explore the trade space available both with the Calipiles and with other sensors, like the AK9754, for example.
Are you sure? yes | no
We have tried a variety of more complicated schemes but the simplest works best. The problem is that threshold changes are unpredictable although fairly smooth and slow. So periodic updates work well as long as the update period is chosen close to 1/(rate of threshold change). Obtaining ~ 100% accuracy using 2 AAA batteries for one year or two AA batteries for two years, as seems likely, is good enough and makes this a viable product for customers. I'd rather put further effort into cutting the production cost.
Are you sure? yes | no
I am wondering if only triggering an interrupt on the Threshold being exceeded is viable and helpful to reduce power consumption slightly? In addition, if some algorithm to adjust the period of time between baselining is viable and beneficial, for example reducing the time between threshold adjustments once a change in baseline of xxx amount is noted?
Are you sure? yes | no