Bee counter that is based on state transition instead of elapsed time

[svavassori]

First of all I'd like to thank you to put freely available the design of the board and the code to run it.

Looking at the Arduino code I saw that your counter is based on time threshold (200 ms and 600-650 ms) to avoid some bouncing in the reading.

This gave me the idea to try to detect the entering or the exiting pattern in a way that is robust with respect to the bouncing of a single sensor of the gate at a time. This gist ( https://gist.github.com/svavassori/431e78c2d9f1ff55adb63623408eb033 ) implements a state machine that detects the entering or exiting of a bee for a gate, the extension to multiple gate can be easily done be extending the State current[] array to the desired size.

Unfortunately I have no access to a beehive until some months, so I was wondering about these two possibilities:

• if you could test it on your board (the integration shouldn't be difficult) to see if it actually works, or
• if you could share some unfiltered captures of a single-gate sensors (in-out) in order to have real sequences, so I can test it by myself and see if it works.

Regards,
SV

[hydronics2]

Hey, I don't have an active hive right now either... That's a great idea of sharing unfiltered data. I did capture some on another laptop for just that purpose. I'll see if I can dig it up.

…

On Mon, Apr 12, 2021, 4:02 AM svavassori ***@***.***> wrote: First of all I'd like to thank you to put freely available the design of the board and the code to run it. Looking at the Arduino code I saw that your counter is based on time threshold (200 ms and 600-650 ms) to avoid some bouncing in the reading. This gave me the idea to try to detect the entering or the exiting pattern in a way that is robust with respect to the bouncing of a *single* sensor of the gate at a time. This gist ( https://gist.github.com/svavassori/431e78c2d9f1ff55adb63623408eb033 ) implements a state machine that detects the entering or exiting of a bee for a gate, the extension to multiple gate can be easily done be extending the State current[] array to the side desired. Unfortunately I have no access to a beehive until some months, so I was wondering about these two possibilities: - if you could test it on your board (the integration shouldn't be difficult) to see if it actually works, or - if you could share some unfiltered captures of a single-gate sensors (in-out) in order to have real sequences, so I can test it by myself and see if it works. Regards, SV — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3MOPGSXOUT6SIB3A3W6PTTIKSKJANCNFSM42YX36LA> .

[svavassori]

If you could find those, it would be awesome because it will also validate (or invalidate) the assumption of a single sensor change per gate.

Let's hope for the best!

[svavassori]

Do you have any news about the raw capture of the gate?

[rodece]

Do you have any news about the raw capture of the gate?

Hi,

I am interested in the variant of the project, I have the system available on a hive from which I detect the data as a protocol created by hydronics2 ( very beautifull), you can check the data is as follows link :
https://thingspeak.com/channels/1141102
as you can see I have some problems as the data between bees in and bees out are not very aligned, some days the variant is also 15000 bees,
I think the problem is on the setting of the times, I made several changes without solving the problem.
if you have the possibility to send the sketch already compiled on the arduino system, not in C, I will install it for testing.

[svavassori]

@rodece I saw you have almost 20k bees as difference between out and in count over a 24h period, that's really strange. Usually out count should be a little higher than in because bees are dying outside and are born inside, so you have a net flux from inside to outside, but what you got is way too big for a single day.

Moreover it seems that the temperature sensor could be exposed to direct sunlight since it peaks at 11:00 instead of at 16:00-17:00

I don't have an Arduino here because I'm using an ESP32, but before plugging in the state machine, I would like to ask if you can run this sketch to get some raw data: https://gist.github.com/svavassori/37b6db89e4ab47f45748939dbb8f16b2, its output should be like:

1554582,00
1554593,00
1554604,01
1554615,11
...

It's a stripped down version of @hydronics2 one that prints to the serial line only the raw values of sensors at Gate 0 for each loop. In this way we can see how much debouncing (spurious state transition of the sensor) there are and if the precondition on which my solution is built is met (singe sensor transition at a time). If that condition isn't met, the current implementation will go in an error state and so wouldn't be of any use.

The idea is to record what it is read from the sensor (a dozen of bees entering and exiting should be enough) in order to understand the timings and the cases that we face and then to find a solution to properly count the bees (or at least reduce the false counts to a number so small that it doesn't impact on the final result.
Please, pay attention that this version doesn't count, it simply prints the state of each sensor, so it is important also to observe the gate and count them manually (or record a short video) in order to know what was actually happening.

Since gate 0 is the first one, probably it won't be so frequently used by the bees, so closing some other gates with a stick of wood for a couple of minutes can help in getting the results in a shorter time. :-)

[rodece]

@svavassori

I saw you have almost 20k bees as difference between out and in count over a 24h period, that's really strange. Usually out count should be a little higher than in because bees are dying outside and are born inside, so you have a net flux from inside to outside, but what you got is way too big for a single day.

Yes, you are right, however in these days there was a high import, today the values ​​are more correct.

Moreover it seems that the temperature sensor could be exposed to direct sunlight since it peaks at 11:00 instead of at 16:00-17:00

The sensor is installed behind the hive, but the apiary is installed in a wood and the sun only comes around 12 o'clock

I have two bee counters with feather M0, on the second I made the modification you requested and the data can be found in:
https://github.com/rodece58/contavoli/tree/main/log_25_06 ( log and video have the same number),
as you can see they make mistakes, I think due to the fact that the bees can also transit by walking on the sides of the gate and perhaps they are unable to engage the two sensors.
I think try to tighten the gates and do the test again , I just have to check if the drones pass.

[svavassori]

@rodece, thanks for your files, they have been very helpful to do an offline analysis.

As first I tried to run the state-machine as it is but it got stuck too many times to be happy with, so I changed its behavior to reset itself when the gate comes empty again: in this way it doesn't block and just skip the problematic parts. Unfortunately, by doing some stats, it came out that it counted:

• 53 incoming bees
• 3 outgoing bees
• 23 error sequences

This means a 41% of sequences aren't handled properly, and that is not a good number, so probably my assumption of a single-change isn't that right.

Then, I calculate the time it took for each detected bee to pass through the gate, in order to have an idea of the time it needs and the results are interesting, I plotted them in this simple frequency chart:

As it can be seen, filtering below 650 ms it would cut out more than 20% of the counted bees (13 over 56), so at least the idea of being time-independent does make sense, because of the variance of the distribution.

Another interesting thing of the raw data is that it can be seen there are some bees on the inside that check the gate (starts from the inside but then go back) while the bees that are coming in are pretty resolved and traverse the gate without too many doubts.

About tightening the gate, in order to let the drone pass you could tighten just the first and leave some others open. Of course this will imply we aren't counting all the bees, but just to test if it reduces the errors it could be enough.

I saw you uploaded the videos (thanks a lot!), I'll take a closer look later on, but at least they validate that it was mainly an incoming traffic. At first sight, in one of them it seems there are two bees entering at the same time, would that be possible or it's just the point of view of the camera?

[svavassori]

I had a look at the size of the gate on the PCB schema and compared with other references: I think the gate is definitely too big and bees could probably pass on the sides without being detected by the sensors.

From the schema, the gate should be 9.85x15.3x8.4 mm (WxLxH) while the two sensors are around 2 mm wide, this means there is 4 mm on each side that can be used by the bee. Could you please check those measure (9.85x8.4) matches the build one?

Looking at this image, it can be seen how much space there is.

As reference, the classical metallic entrance has gates of 7.8x7 mm (WxH) and the grid of the queen excluder is spaced 4.1 mm, so if the above measures are correct, it means the gate should be shrunk by 1.1 mm on each side; some black tape should be enough for testing.

It could be that also the bottom would benefit of 1 mm lift, in order to avoid two bees passing on top-bottom, but first I would prefer to see how the counter behaves only with shrinking. This top-bottom dual-passing can be observed in the video @hydronics2 shared at second 13: in the center of image, in the gate right under the yellow capacitor, a bee with pollen on her legs is entering and while she is still in the gate, another bee exits from the top

[rodece]

@svavassori
Good job !!!
I confirm that the bees also walk on the sides of the gate, see video 4.
I checked the port measurements and they are 97L x 87H under the sensor. I changed the dimensions of the doors with black plastic sheets, now they are 80L x 70H under sensor. I did the test on 3 hives with different traffic, the data have improved even if not completely.
https://github.com/rodece58/contavoli/tree/main/log_30_06
On Saturday I try on the same hive as the first tests and load the log.

[svavassori]

In log_arnia_1.txt there aren't any inconsistent sequences, so it seems it is mostly working, however in the video I see 7 bees entering; it is possible that there is a time misalignment between the video and the raw data.

In video_arnia_3_new.mp4 there are too many bees to be able to count, and the increased wrong sequences is probably due to the fact that they are entering one behind the other. Another confirmation of that is in video_arnia_5_new.mp4 there are less errors and it is less crowded. This is a limitation of the system that I don't think is possible to resolve since we cannot ask bees to enter one-by-one with some space. :-) At the same time, I can imagine that with all the gates working, it wouldn't be that crowded.
Are they doing some washboarding on the top surface?

In video_arnia_5_new.mp4 it seems that sometimes two bees are trying to enter and when they reach the sensor only one of them passes. A small improvement would be to level with some strips the top part so the sensors don't extend from the surface, this will also reflect the 7 mm high right from the entrance.

When you will do your next Saturday test, I would also ask if you can change in the Arduino code the last delay(15) to delay(9) in order to increase a little the sampling frequency from 62 Hz up to 100 Hz. I don't expect any major benefits but it is just to see if it can help in differentiate some edge cases.
From the specs we have to do a minimum LED off time of 7.5 ms, so we have still some margin.

[rodece]

I make a tests, find the results on
https://github.com/rodece58/contavoli/tree/main/log_03_07,
I changed the delay as per your instructions.
I have also modified the gate by inserting an internal 8mm tube, see attached photo, now only one bee passes !!! ;-)
The data seems to have improved.
As you said there is too much traffic on a gate, to reduce the errors perhaps it would be better to be able to enable an another 3 - 4 gates to check if the counter is working correctly.

[svavassori]

I have also modified the gate by inserting an internal 8mm tube, see attached photo, now only one bee passes !!! ;-)

I saw from the videos that with the tube it seems they slips and it is problematic for them to enter upside down.

As you said there is too much traffic on a gate, to reduce the errors perhaps it would be better to be able to enable an another 3 - 4 gates to check if the counter is working correctly.

Sure, with less traffic should perform much better.
The mention I did about closing some gates was to increase, if needed, the traffic through the monitored gate, not to let only that open :-)

Thanks for the new dataset, here is the relative frequency chart:

This confirms two things:

1. bee traversal can have a big variance
2. there are false positive

A gate traversal in 50 ms is very unlikely to be a real bee (walking 20cm/s is too fast), so anything below 100 ms would be suspicious, and probably is due to two bees at each side of the gate that accidentally trigger a sequence that matches an inbound (but it could be an outbound as well). Nonetheless this is not a big problem since it can be easily filtered by doing some stats and see what is a reasonable minimum time to get through the gate.
A possible way to have some reasonable value about that threshold is use piece of transparent tube as gate and record a video on top of it with a millimeter band next or under. The visual assessment of the speed has to be done manually but it is a one-off.

On the other hand, that false positive made me think about the impossibility to guarantee a false positive free counter with a two sensor gate: two bees could just stay there for the right amount of time to be in the "likely" range and there will be no way to distinguish it from a real arrival or departure. It shouldn't impact a lot on the big numbers because I suppose it would average to zero between false arrivals and false departures and it will mostly happen when there is "traffic jam", but it is an intrinsic limit of this solution.

That led me think about using 3 or 4 sensors (inline) per gate: it should resolve this problem and probably, by using 4, it will also be able to differentiate:

1. two bees trying to enter and exit and which one wins
2. when a queen is passing (all 4 activated)

It is possible that (2) could be exposed to a false positive in case two bees exits one after the other; hopefully in the majority of cases there will be a space between the two bees big enough to trigger an empty state in one of the inner sensors (at 10cm/s, 10ms is 1mm).

Unfortunately adding more sensors requires a new design and fabrication, so I looked around and it seems that nobody implemented it in that way. I don't know if @hydronics2 had any experience with that or if adding more sensors per gate simply increases complexity and cost without giving any major benefits.

[rodece]

Beautiful analysis !!!!

A possible way to have some reasonable value about that threshold is use piece of transparent tube as gate and record a video on top of it with a millimeter band next or under. The visual assessment of the speed has to be done manually but it is a one-off.

To check the speed I built a gate with the millimeter band, the videos can be found on:
https://github.com/rodece58/contavoli/tree/main/bee_transit

That led me think about using 3 or 4 sensors (inline) per gate: it should resolve this problem and probably, by using 4, it will also be able to differentiate:

If you want I built a gate prototype with 4 sensors, see video, I could connect the first two on port 1, as originally, and the second pair on port 2 of the bee_counter.
If you can make two sketch
1: with 3 sensors
2: with 4 sensors,
I could then test it on the hive; I also inserted a plexiglass to make the video from above the gate.
Tell me if I can start the modify and test in the lab.

[svavassori]

Thanks for the videos, I'll calculate bee's speed during this weekend. It will take me a while but at least we will have some real data about bee's speed.

A thing I noticed by having a quick look at them is that a longer tunnel increases the chance two bees enter in different directions and one "wins" by pushing the other back :-)

By the way, I don't know if it's something that is depending on my VLC or other, but all the videos you uploaded start only with audio, then the video appears after 7-8s.

If you want I built a gate prototype with 4 sensors [...]

That would be really nice to try out!

About the 4 sensor prototype, if you are able to connect those sensors to gate 0 and 1, we can read all 4 and it will cover the 3 sensor variant (by simply ignoring one of the outermost).
In case you are soldering the new sensors in parallel with the old ones, it will probably be useful to close the "original" gate 0 and 1 with black tape to avoid having those sensors doing some spurious read.

If I got it right the mapping will be something like this, please let me know if it's different:

inner -> inner gate 0
inner-center -> outer gate 0
outer-center -> inner gate 1
outer -> outer gate 1

This is the modified gist that reads from gate 0 and 1: https://gist.github.com/svavassori/7fc9af576663dc35193071d04cc8e4cf

Can you please measure the length of the 4 sensors? This is to double-check the queen case and if two bees can trigger it.

[hydronics2]

@svavassori really nice analysis. I went down a similar rabbit holes (design thinking) about the bee counter. You've done a great job articulating the design thinking. @rodece thanks for providing all the data and work!

Uneven Bees count IN vs OUT

• Yes, bees on the inside of the hive seem to start and stop and often return causing false triggers
• another idea I had for miscounts is external IR light (from the sun) makes the outer most row of sensors slightly more sensitive

Bee Speed Through The Gates

• If you look at just the clean data... bee moving cleanly through the gates... can give you a good approximation of speed
• I think the average was maybe 150-250ms to traverse the gates
• There are a lot of points to measure speed
• Time entering 1st sensor (T1), time entering 2nd sensor (T2), time leaving 1st sensor (T3), time leaving 2nd sensor (T4)
  

Size of gates

• I think squeezing down the size of the gates is a good idea.... to an extent
• Bees have to remove dead bees and other materials from the hive and this will inhibit that ability a bit
• Drones are larger and need space to exit

More sensors in the gates

• I prototyped three sensors in a gate. Not too hard to do. A few more shift registers and the sensors are fairly inexpensive.
• I didn't finish and test the prototype... :( I also think this would increase accuracy.

@svavassori / @rodece it was great to hear you work through some of the problems/fixes/prototyping I was working on over the years. great job!