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 https://github.com/hydronics2/2019-easy-bee-counter/issues/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!

[rodece]

@svavassori ; tested the prototype with 4 sensors, the videos and logs can be found on: https://github.com/rodece58/contavoli/tree/main/log_4sens_13_07

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.

I had used VLC for the conversion and saw that it was losing the first few seconds of the video, now I have used another converter and it works.

Can you please measure the length of the 4 sensors?

The distance between the sensors is 5 mm. The size of the gate are 8 x 8 mm.

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

I confirm that the sequence is correct

@hydronics2 it's a pleasure to help you and thanks for your beautiful open source work.

[svavassori]

I'm sorry for all these days of silence but the analysis took me more time than expected.

@hydronics2 it's nice to hear you again!

The distance between the sensors is 5 mm. The size of the gate are 8 x 8 mm.

Actually I was referring to the whole length of the 4-sensor row. :-)

About the analysis, first I mangled a little the video (crop, rotate, enlarge and extract frames) in order to read more easily the different positions for each bees and I collect a total of 58 sequences with various length. I used 1mm granularity in order to avoid some parallax problem and I checked that the speed over 2 frames matched the sum of the single frames. For a video at 30 fps, 1 mm/frame is equivalent to 3 cm/s. This is the normalized frequency chart of bees' speed:

As it can be seen, the top speed is about 12 cm/s but it cannot be sustained through all the length of the gate, so it cannot be used as maximum average speed.

My initial idea was to integrate the speed for each bee to find the space as a function of time and then invert that function to calculate how much time would have been needed to traverse a gate of a given size according to the possible initial positions. However, since some bees stopped or walked back a little in some frames, it means the relation t → s(t) is not invertible, so I wrote a small program to calculate for each gate size (parameterized) the time needed to traverse it using the given sequence of speeds. The size of the gates I used varied from 17 to 24 mm with a increment of 1 mm, this is to simulate the length of a bee (12-15 mm) plus the length of the real gate (5-9 mm). Then, since we are interested in the minimum time, I took the lowest time for each gate size across all bees and these are the results:

<!DOCTYPE html>

gate [mm] | Time [frames] | avg. speed [mm/frame] | avg. speed [cm/s] -- | -- | -- | -- 17 | 6 | 2.83 | 8.50 18 | 7 | 2.57 | 7.71 19 | 7 | 2.71 | 8.14 20 | 8 | 2.50 | 7.50 21 | 8 | 2.63 | 7.88 22 | 9 | 2.44 | 7.33 23 | 9 | 2.56 | 7.67 24 | 9 | 2.67 | 8.00

According to these data, it seems that in the best case (small bee and small gate) the minimum time to pass through the gate is 200 ms, but looking at the frequency chart I find a little odd that 100 and 150 ms are false positive and 200ms are good since they have the same frequency.

In addition I had a look at the new 4-sensors gate data to see if that would make sense and I found this sequence that shouldn't happen: inner sensors are occupied without having passed through outer sensors.

17317,00,00
17327,00,00
17337,00,00
17348,01,10
17358,00,00
17368,00,00
17378,01,00
17389,00,00
17399,00,00

At first I thought of a possible light leak from the other sensors of the board, but as it can be seen here, the board doesn't have any sensor attached to it, so they cannot leak.

That made me think that maybe the @hydronics2 schema is correct from the receiver point of view, but not for the emitter+receiver system. With that I mean that since each sensor is composed by the emitter and the receiver, the IR light reflection point should be in the middle of the two, and under normal condition, it doesn't leak in the other receiver, so it could be that the actual sensing area is smaller than I though.

For this reason, in order to estimate the actual sensing area of the 2-sensor and 4-sensor gate and to shed some light on the possible causes of that strange behavior, I would ask if @rodece could you do this test (it doesn't need the hive):

• use a millimeter strip (7mm wide) and manually pass through the gate to check the sensors don't get triggered, otherwise reverse and cover with black tape on the white side (so you can look at the bottom for the mm grid).
• fix/glue a dead bee on the strip
• mark as zero reference when the head of the bee is aligned with the entrance of the gate (black plastic border)
• insert it 1mm at a time in order to see at which distance gets triggered each sensors.

With this we can control what is happening at each moment when a bee is entering and hopefully understand better what is going on.

[rodece]

Great analysis again !!! :-)

Actually I was referring to the whole length of the 4-sensor row. :-)

The measurement between the beginning of the first sensor and the end of the last is 16 mm.

I made the tests you requested, the results on: https://github.com/rodece58/contavoli/tree/main/log_test_18_07

The activation distance of the first sensor is 1 mm. I also did the test with two bees spaced 1 mm . I also logged in for the quick pass. for 1 and 2 bees. Check if it's okay in case I do the test again.

[svavassori]

Thanks for the quick response and videos! Unfortunately the last one with the millimeter band is too low resolution (202x360) to be able to read it, nonetheless the relative logged data proved that the band is reflecting IR light and the sensors' output sequence is expected one: 0000 > 0001 > 0011 > 0111 > 1111 > 0111 > 0011 > 0001 > 0000

About the bees' logged data, they are exactly the same file and it seems they refer to the first one (1 bee "slow"), maybe it has been a copy/paste problem from output of the serial port. Nonetheless it has been useful to find out that the two gates aren't working the same way. As a matter of fact this is the strange thing in the sequence (with only interesting changes):

184904,00,00
184914,10,00
185081,11,00
185235,11,10
185246,01,10
185370,00,10   <-- This is strange, I would have expected 0111 or 0011
185402,00,11
185507,00,01
185600,00,00

I observed that also in the some previous captures, so it isn't by chance, and it is kind of problematic because if the bee can trigger up to 3 sensors, it should always trigger two, unless they are spaced unevenly. This makes me think that the leftmost sensor could be oriented slightly different from the others (looking outward).

The aim of the test is to understand at which distance each sensor is triggered (1 or 0), so the timing is of second importance. The following diagram should help to better explain the setup:

The millimeter paper should be put under the device and aligned with the gate and the moving strip to minimize errors when reading the distance. Once the bee is at the gate entrance, so before the first sensor is triggered, you can mark on the mm paper that point as reference for zero distance and then, with a 1 mm step (or less if possible) push the strip inside the gate and mark each time there is a change in the sensors (0000 > 0001 > 0011 > 0111 > 0110... etc).

The result of the test should be a table like this:

<!DOCTYPE HTML>

Distance [mm] | Sensors’ output -- | -- 0 | 0000 1 | 0001 … | 0011 … | 0111 … | 0110 … | 1110 … | 1100 … | 1000 … | 0000

With that table and knowing the length of the bee and the sensors' length, it possible to understand the actual sensing area of the sensors.

Extra points if you want also to repeat the test with a 1 mm thick white strip (like the one at the bottom of the image) instead of the bee to increase the resolution :-)

[rodece]

Unfortunately the last one with the millimeter band is too low resolution (202x360).

I've seen it too, unfortunately github only accepts files no larger than 20 Mb, so I had to convert them with youtube.

This makes me think that the leftmost sensor could be oriented slightly different from the others (looking outward). I have checked the sensor and it seems to me mounted correctly.

I did the tests you requested and these are the results:

with 15 mm long bee

Distance [mm]	Sensors’ output
0	0000
1	0001
5	0011
10	0111
11	0110
14	1110
16	1100
21	1000
25	0000

with 1mm white line

Distance [mm]	Sensors’ output
0	0000
1	0001
4	0000
5	0010
8	0000
10	0100
13	0000
15	1000
17	0000

If you need other tests, I'm available ;-)

[svavassori]

I've seen it too, unfortunately github only accepts files no larger than 20 Mb, so I had to convert them with youtube.

That is a limitation of the GitHub web interface, with the command line the limit is 100 MiB per file. Nonetheless I think those limits are more than enough for the short length of the video we have. I use handbrake to do simple tranformation (crop, rotate, remove audio etc) and it gives you more control with respect to youtube. Alternatively, you could use some free storage service like Dropbox, Google Drive or Windows Onedrive.

About the tests, it has been useful to have both and with this information it can be deduced the length of the bee as seen by the sensors, the detection area for each sensor and if they overlaps or have blind spots. This is the first table shown in a graphical way:

Each row generates a set of constraints on the bee size:

<!DOCTYPE HTML>

sensors output | bee size constraints -- | -- 0000 | 0 <= x 0001 | 1 <= x 0011 | 5 <= x 0111 | 7 <= x 0110 | 8 <= x <= 8 1110 | 7 <= x <= 11 1100 | 4 <= x <= 9 1000 | 5 <= x <= 9 0000 | 9 <= x <= 9

It turns out that:

• each sensor has a 2 mm detection area
• there is a 2 mm blind area between sensors
• the size of the bee detected by the sensors is 8-9 mm

If the bee is detected by the sensors with a length of 8-9 m while it should be 15 mm this can be explained by two possible reasons:

1. When a bee is dead, usually it curves, so the actual length seen from a vertical point of view is correctly 8-9 mm
2. The bee was actually 15 mm long also as seen from above and there is some scattering factor on the abdomen that should be taken in account.

@rodece could you please tell us in which case are we?

Another thing that I noticed is that in this test, we didn't observe the single-triggered sensor (0110 > 0010) like in some previous captures. @rodece have you changed or modified some sensor's position? If these are correct, could you please do again the test with 1 and 2 bead bees to see the output pattern?

[rodece]

As always great analysis ..... ;-)

If the bee is detected by the sensors with a length of 8-9 m while it should be 15 mm this can be explained by two possible reasons

Correct is the n.2, I have measured the bee and the value is 15mm.

have you changed or modified some sensor's position?

No, I have not made any changes but I noticed that sometimes the log stopped, I restarted the pc and now it seems to work regularly

I have made a new tests you can find in https://github.com/rodece58/contavoli/tree/main/log_26_07

I also uploaded the photo of the test bees.

[svavassori]

Thanks for the files, what it puzzles me is why do we have a single triggered sensor when there are two bees, it seems it's related to the length (from the photo the second one is shorter than the first) but not always and it seems to happen more frequently on the rightmost gate.

Here below is the image @rodece uploaded with marks of 8.5 mm length, that is what are detecting the sensors and this impacts also the estimation of the minimum time to traverse the 2-sensors gate, that for a 8 mm "bee" is around 140 ms.

This made me wonder if is only the slope of the abdomen that is scattering out the IR light or is also the color. If the color has a role, I would expect the head shouldn't be detected, especially for the leftmost one.

So, if I may @rodece ask you another tests: could you please with a single bee do again the distance/sensors table and without moving the bee cutting its head and redo again the test starting from the same mark (such that the body starts at the same position in each round)? The leftmost one is better because it has a darker head and thus will give a stronger proof.

The second test is similar but using the rightmost bee and cutting its abdomen, so in the end there should be 4 tables:

<!DOCTYPE HTML">

Distance 1 [mm] | Sensors’ output -- | -- 0 | 0000 ... | 0001 … | …

<!DOCTYPE HTML">

Distance 1 without head [mm] | Sensors’ output -- | -- 0 | 0000 1 | 0001 ...  | …

<!DOCTYPE HTML">

Distance 2 [mm] | Sensors’ output -- | -- 0 | 0000 1 | 0001 … | …

<!DOCTYPE HTML">

Distance 2 without adbomen [mm] | Sensors’ output -- | -- 0 | 0000 1 | 0001 ... | …

In this way we can check what are the parts of the bee that are seen best by the sensors and verify if they aren't triggered only because of the slope or also because of the color.

@hydronics2 have you thought to use some sensors similar to SX1070 (i.e. transmissive instead of reflective)? I don't know if it would give better results but its sensing should be independent of the shape and color of the bee. Could the small split of the photosensor be something that the bees would cover readily with propolis?

[hydronics2]

• Scattering of the IR light on the abdomen is an interesting theory. The abdomen is striped and I also considered this might occur but never tested for it. The reflectivity on the abdomen and/or on the eyes/head could very well be different than what we'd expect being an organic surface and not WHITE or BLACK per the sensor cut sheet
• I also remember 140ms as being about the fastest time to traverse the sensors. I also recall having two bees leaving (one after the other) could trigger sensors to be ON longer (only appear as one bee)
• the sensor LEDs closer to the micro-controller are a little stronger than the sensor LEDs at the end of the board. you may see this in your data
• Yes, it's likely a SX1070 sensor or break/interrupt sensors would work better. The sensor would be a lot more expensive but worth considering.

[rodece]

Unfortunately, I no longer have the bees from the previous tests available, I still added new bees as you requested, the photos can be found on:

https://github.com/rodece58/contavoli/tree/main/test_28_07

test results:

Distance 1 [mm]	Sensors’ output
0	0000
5	0001
8	0011
12	0010
13	0110
17	1100
22	1000
25	0000

Distance 1 without head [mm]	Sensors’ output
0	0000
5	0001
8	0011
12	0010
13	0110
17	1100
22	1000
25	0000

Distance 2 [mm]	Sensors’ output
0	0000
2	0001
4	0011
5	0010
9	0110
11	0100
13	1100
16	1000

Distance 2 without adbomen [mm]	Sensors’ output
0	0000
4	0001
5	0000
7	0010
10	0000
12	0100
15	0000
17	1000

as you can see the test 1 bee with and without head the result is the same, clearly changes completely with bee without abdomen.

@hydronics2

Scattering of the IR light on the abdomen is an interesting theory. The abdomen is striped and I also considered this might occur but never tested for it. The reflectivity on the abdomen and/or on the eyes/head could very well be different than what we'd expect being an organic surface and not WHITE or BLACK per the sensor cut sheet.

A further problem is that according to the breed of bees the color also varies, for example the "ligustica" bee has a light color, while the "Carnic" bee has an almost black color. I live in the north east of Italy where both breeds are present and above all hybrids that have, in most cases, color as shown in the photo.

the sensor LEDs closer to the micro-controller are a little stronger than the sensor LEDs at the end of the board. you may see this in your data

I used a 120 cm cable to connect the test sensors. , could it affect the results?

@hydronics2 @svavassori

Yes, it's likely a SX1070 sensor or break/interrupt sensors would work better. The sensor would be a lot more expensive but worth considering.

If you want I can see to provide 4 sensors to do the test, I check the characteristics to make the changes.

[svavassori]

Thanks @rodece for the quick testing.

Scattering of the IR light on the abdomen is an interesting theory. The abdomen is striped and I also considered this might occur but never tested for it. The reflectivity on the abdomen and/or on the eyes/head could very well be different than what we'd expect being an organic surface and not WHITE or BLACK per the sensor cut sheet

I think we all agree looking at the test results, the head isn't detected at all, since there is no difference in the first two tables. In the second case, the abdomen is partially detected because it does show some differences, even if it's noisier than the first, so color and shape does have an impact on the sensor's ability to detect the bee.

I used a 120 cm cable to connect the test sensors. , could it affect the results?

From my understanding, if it has any effect, it will be the same on both gates, so the sensors will work under the same conditions.

I also remember 140ms as being about the fastest time to traverse the sensors. I also recall having two bees leaving (one after the other) could trigger sensors to be ON longer (only appear as one bee)

You are right but fortunately it will mostly happen when there is high traffic, so in general I would expect it to be negligible when all gates are open and we are at least counting one of the two. Probably it will get worse with the 4-sensor gate.

Yes, it's likely a SX1070 sensor or break/interrupt sensors would work better. The sensor would be a lot more expensive but worth considering.

If you want I can see to provide 4 sensors to do the test, I check the characteristics to make the changes.

I just have basic knowledge of electronics, so I don't know if the SX1070 is the best the market can offer for this job: any other options are welcomed.

I found it on this short article: their approach is more hardware-based (FPGA) than software-based (as ours) and there is no in-field validation since it has been left as future task. However I wasn't able to find the following paper.

[hydronics2]

I think we all agree looking at the test results, the head isn't detected at all, since there is no difference in the first two tables. In the second case, the abdomen is partially detected because it does show some differences, even if it's noisier than the first, so color and shape does have an impact on the sensor's ability to detect the bee.

That's interesting feedback. I wonder if there's a difference if the bees crawl across the sensor up-side-down. I know this happens quite often but I've never tried to measure the difference.

I used a 120 cm cable to connect the test sensors. , could it affect the results?

There's a 560uF capacitor on the board but even with this extra energy source.... I saw a definite difference in the IR LED strength between gate 1 and gate 24. Gate 1 triggered slightly easier than Gate 24 because the LED was pulse was greater as it was closer to the triggering mosfet and apparently less voltage drop from signal trace resistance.

their approach is more hardware-based (FPGA)

I like the idea of trying a 'gate' type sensor but I'm not so motivated to do a redesign at this point. Usually FPGAs are used when you require super fast sensor response so it's curious that was their choice. As we've seen with this project, honey bees aren't super quick :)

[svavassori]

I wonder if there's a difference if the bees crawl across the sensor up-side-down. I know this happens quite often but I've never tried to measure the difference.

I have to admit I haven't thought about that even if we saw it, that is an interesting observation. My take is that it should give a stronger signal with respect to the "classical" crawl because the bee is closer to the sensor and there aren't big differences in color on both sides. Moreover the bottom is mostly flat.

Gate 1 triggered slightly easier than Gate 24 because the LED was pulse was greater as it was closer to the triggering mosfet and apparently less voltage drop from signal trace resistance.

I could be wrong, but I remember the original board to be empty, so the only voltage drop should be the ohmic one of the cable (0.02 V maybe)?

I like the idea of trying a 'gate' type sensor but I'm not so motivated to do a redesign at this point.

I prefer to write software, so don't worry, I won't ask any FPGA redesign: it was only to show where the sensor came from :-)

[rodece]

I ordered some sx1070 sensors, I saw the electrical characteristics and they are similar to the ones installed now, apart from the different connections, as soon as they arrive I try to install 3 or 4, I would say at a distance between the first and third of 17 mm. ?? In the meantime I prepare the support then I send you the photos. I hope to be able to conclude before the bee season is over.

[rodece]

SX1070 arrived. I modified the gate with the new sensors and carried out some tests. After editing the sketch (the new sensor has the output always high), I found that the sx1070 has the tx led positioned at 5,5mm from the base, and therefore it did not always detect the passage of the bee, I inserted a thickness of 2 mm and in the test it regularly detects the passage. The distance from eatch sensor is : 1 - 2 and 3 - 4 = 8mm , 2 - 3 = 10mm, in this situation the worker bee engages only 2 sensors at the same time. Log data, prototype photos, sensor datasheets and videos can be viewed on : https://github.com/rodece58/contavoli/tree/main/log_sx1070_20_08

[svavassori]

Good job with the new sensor's type!

I will have a deeper look at it this weekend, but by the quick look, it seems some sequences are chopped:

53375,11,00
53386,11,00
53396,11,00
53406,11,00
53417,10,00
53427,00,00
53438,00,00
53448,01,00
53458,01,00
53468,01,00
53478,01,00

It may depend on height of the bee.

Have you tried, or do you see it as feasible, to put the sensor vertically? Just to understand if it will improve detection or if that doesn't depend on the orientation.

[svavassori]

Hello all,

I looked again to the data and unfortunately all the sequences are incomplete or broken in the middle. In addition, this is a confirmation that the longer the gate, the stronger the tunnel effect is (two bees entering the gate at the same time and colliding).

What puzzles me most is the spurious reading on the outer gate, there are a lot of transition 01 > 10 or even 01 > 00 > 10: is something I wouldn't have expected with this type of sensor and I don't know if it can be due to some abdomen movement during the passing or some other misalignment between bee's body and the IR beam.

@rodece How hard would be to put all the 4 sensors one next to the other without any space in between in order to reduce the total length of the gate from 32 mm to 24 mm and the sensed one from 26 mm to 18 mm?

A second test would be to build one gate with just two sensors to evaluate how much is the actual improvement with respect to the reflective one. In that case, the distance between the two beams would be 6 mm and the total gate length would be 12 mm, so a little shorter than the original from @hydronics2

[svavassori]

This weekend I found this interesting article from the 90s: Microprocessor-controlled monitoring of honeybee flight activity at the hive entrance by Marc Struye.

It seems one of the most accurate articles that talks about the accuracy and the parameters that affect bee counting. What caught my attention is that:

• the distance between sensors limits the minimum distance needed between bees to be detected as two
• it employs a interesting system to try to break bees' queue by using a stepped reduction of the gate where the sensor is instead of reducing all the gate.
• it reports a 0.2%-0.3% error on low-flow controlled environment and a 1.1%1.5% in two field trials.

It was covered by a patent BE1011050A6 that I think it is expired now, so there shouldn't be any problem about intellectual property.

In Abeilles & Cie nº 68 - 1/1999 at page 8 and 9, it reports a 1.76% mortality on July, 3rd and the table has an average of 3% in the first part of August with good weather, then it increases up to 9% with bad and cold weather (also going to the end of September).

Another partial reference that I found from the same author is Possibilities and limitation of monitoring the flight activity of honeybees by means of BeeSCAN bee counters, extracted from Hazards of Pesticides to Bees: Avignon (France), September 07-09, 1999 that shows the following table:

Here are the result of the so called robbers test: in that test an empty beehive containing some honey is monitored with the counter. Obviously bees that entered will exit or have died inside, so by inspecting the empty beehive at the end of the day to count the died bees (d), the counter error can be assessed.

I think those numbers are sound even if it's it's hard to draw the precise line between real mortality and counter error.

All this, together with the tunnel effect we are seeing by adding more sensors, made me think that the shorted the gate, the better it is.

@hydronics2

• for what you know, is there any sensor that is close to the one described in the article?
• would be possible to manually separate the emitter/receiver pair in order to put two receiver one next the other on the other side of the gate or there is some internal wiring that will be damaged?

@rodece if you are willing, we could test before season ends the two-sensors per gate board with all gates opened, using the state-machine enabled and the minimum time-traversal cutoff to check how performs compared with the standard one and the one of the article.

[rodece]

Hi, sorry for the delay, very interesting the article you linked, as you can see the errors in the counts are very small.

I contacted a company that builds electronic boards and I asked if they can find the dualir to do the tests.

The season is now over, but there are still bees coming out on hot days, so I would have no problem testing the new software, if you want I can load it on the couter that I currently have in service in the apiary.

[hydronics2]

Hey, also apologize for missing your email. Wow... that is a great paper. Probably the best paper I've read discussing some of the issues with bee counting.

• They are using an IR break type sensor (emitter and receiver on opposite sides)...specifically they're using one emitter LED and two sensors spaced slightly apart.....
• That sensor was more widely used just 10 years ago...where as this counter uses an IR reflective type.
• IR reflective is easier to build on a PCB... whereas break type sensors require placement of emitter/receiver on opposing surfaces (perhaps two circuit boards facing each other) increasing cost/complexity
• Regardless of sensor type.... having the sensors close together is a good technique to count quick moving bees or bees lined up in quick succession..!
• As an aside, the reflective IR requires the IR light to reflect back into the sensor and because the bee is not a perfect reflector (the bee is not white) the IR sensor creates a bit more noise that has to be dealt with.

Hole size and queue-break (what a great word!)

• decreasing hole size is with a queue-break makes a lot of sense and forces bees one at a time through the sensor(s)
• decreasing hole size also increases blockages with dead bees as they mention in the article
• requires more frequent checks and cleaning
• if we used a queue-break, the bee-counter could alert you to how many gates are blocked each day to signal cleaning

The current hole size is about 10mmWx9.5H... reducing this down to 7.5mm (wide) would be interesting to see and probably wouldn't result in too much blockage. I forgot, have you tried a reduction in hole size using shims or something?

I like the way the graph the data. You can really get a good idea of how the peaks line up... that is; bees taking pretty short flights... within say ~20min [image: image.png]

On Mon, Oct 25, 2021 at 4:55 AM rodece @.***> wrote:

Hi, sorry for the delay, very interesting the article you linked, as you can see the errors in the counts are very small.

I contacted a company that builds electronic boards and I asked if they can find the dualir to do the tests.

The season is now over, but there are still bees coming out on hot days, so I would have no problem testing the new software, if you want I can load it on the couter that I currently have in service in the apiary.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hydronics2/2019-easy-bee-counter/issues/17#issuecomment-950846990, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3MOPHZJYIYBCRE6DDXR7DUIVATJANCNFSM42YX36LA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[svavassori]

@rodece here is the gist with the state machine version for all 24 gates. I didn't run it, so you may need to tweak the delay at the end to match 100Hz as sampling frequency and maybe tweaks some bits here and there. It has a 130 ms threshold as minimum time for traversing the gate. Please, let me know if you have any doubts on how to modify it.

It could be that during winter you don't need to shrink all the gate as we did in our tests, but it would be better to have it done by spring.

I suppose it will work well for the time being since I don't expect too much traffic. It will be interesting to compare the performance of the counter during winter and spring to understand at which threshold the error starts getting out of control.

[rodece]

Hi, Thank you. I am interested in testing the sketch in the field, even if at the end of the season, but compiling with the Arduino software it signals errors, surely the problem is that part of the writing is in C language that arduino does not solve, example:

typedef enum { LOW, // there is no bee HIGH // there is a bee } Gate_Sensor;

were LOW and HIGH states have other functions on Arduino sketch. I also think that even the "typedef enum" commands are not recognized.

I tried to edit but for my knowledge it is too complicated :-)

[svavassori]

Here is the new version of the gist that should compile on Arduino.

Changes:

• rename Gate_Sensor's enum values LOW and HIGH as SENSOR_LOW and SENSOR_HIGH respectively
• use implicit array initialization for the transition table.

[rodece]

Hi Sergio, good work !!! I edited your sketch to install it in the apiary. It has been in service for about a month now, after several changes it seems to be working. Unfortunately in this period, due to low temperatures, the bees move very little. We wait a few weeks to check the traffic. The data can be viewed at https://thingspeak.com/channels/1141102.

I take this opportunity to wish you and Thomas the best wishes for a Merry Christmas and a Happy New Year!!!!

[claespol]

Hi Sergio, good work !!! I edited your sketch to install it in the apiary. It has been in service for about a month now, after several changes it seems to be working. Unfortunately in this period, due to low temperatures, the bees move very little. We wait a few weeks to check the traffic. The data can be viewed at https://thingspeak.com/channels/1141102.

I take this opportunity to wish you and Thomas the best wishes for a Merry Christmas and a Happy New Year!!!!

Hi rodece, First of all my best wishes for new year. I am claespol and following the work on state transition beecounting. Actually I have a beehive installed with Honeypi (Thingspeak channel 1493465). At this moment i am waiting for the PCB's to assemble the counting module . I was interested by the state transition counting and therefor i was wondering if you could share your modified and implemented sketch.

Thx in advance

[rodece]

Hi svavassori and thomas!!! The season has started !!! As you can see on https://thingspeak.com/channels/1141102 the temperatures during the night are below zero but during the afternoon the bees start coming out. I noticed now, that the traffic has increased, that there are differences between the incoming and outgoing bees, it seems that the system does not count correctly in fact there are more incoming bees than outgoing. Do you think it is better to change the time 130ms or the delay (9)?

[svavassori]

Hello @rodece

Here is today's data plotted one over the other:

The good news is the two curves have the correct phase, namely bees first go out and then come back in, but you are right about the difference in value between in and out.

As a wild guess, I can think the difference in traversal behavior we saw between inbound (go straight in) and outbound (checking the gate or thinking next it) plays a role here, under-counting the out ones.

About tuning the two values, the filtering threshold could be reduced to 100ms but I don't think it would make a big difference, since we saw that the bee cannot traverse the gate that fast and in addition the problem is on outbound, so they are even slower there. The time delay between loops can go down a little to increase sampling frequency but pay attention to the time the diodes must be off to cool down, so processing time + wait time must be greater than 7.5ms

What I would do is to reduce the reporting time from 30 minutes down to 5 minutes to see if there is some pattern we miss (it can be aggregated later to a wider one if needed).

Another data that may be useful to collect is the number of errors for inbound and outbound sequences with the same resolution as above: these can give us an idea of where we are losing some counts. You can easily get it by incrementing the additional two counters here and select which one to increment by looking if counter is one of the three ENTERING states or one of EXITING ones. Let me know if you need any help with that.

[rodece]

Hi Sergio, nice diagnosis!!!

• [ Another data that may be useful to collect is the number of errors for inbound and outbound sequences with the same resolution as above: these can give us an idea of where we are losing some counts. You can easily get it by incrementing the additional two counters here and select which one to increment by looking if counter is one of the three ENTERING states or one of EXITING ones.]

I have modify a sketch but not working correct, I have insert this line :

'else if (current == START_EXITING) { unsigned long elapsed = time - gate->startTime; { startexiting++; //conta IN uscita } } else if (current == MIDDLE_ENTERING) { gate->startTime = ULONG_MAX; { middleentering++; //conta IN transito } '

but the result in test is this:

IN : 3; OUT : 3; entra:10; esce:9; tran_in:42; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:42; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:43; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:44; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:45; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:46; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:47; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:48; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:49; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:50; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:51; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:52; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:53; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:54; tran_out:33; IN : 3; OUT : 3; entra:11; esce:9; tran_in:55; tran_out:33;

more transits are counted in the middle trans. Can you tell me an example of code so I add all sensor situation? Thankyou

[svavassori]

Hello @rodece

I didn't understand exactly the change you applied to the code, but as example of what I was meaning, you can find the updated gist: it will print also the errors (in/out) each time a counter changes, so be prepared for a much higher output on the serial console.

Let's see if we can figure out the reason for that difference, because more than a diagnosis, mine was only an hypothesis that has to be verified :-)

[claespol]

Hello @svavassori

My name is Paul and have installed the state machine software with the errorcounters running. I observe the same problem as rodece. I want to diminue the delay to 7. Therefore my question is how can i measure loop time from delay to delay? I keep stats on thingspeak : https://thingspeak.com/channels/1625705

[svavassori]

You can measure the loop time in any point of the loop, since it is a constant. An easy way is to do it is when the time is read with this call: currentTime = millis(), nonetheless I wouldn't expect any significant improvement going down to 7ms.

For what I can see from your data, you don't have the same problem as @rodece but exactly the opposite: you have more bees going out that coming in. To some extends this is expected since bees born only inside and usually they die outside, but the magnitude is to big.

One thing to understand is why your in error is more than the double of the out error.

[claespol]

Hello @svavassori

The reason is that there were a lot of in/out errors due to the fact (probably) that only 6 gates were open to the bees on the outside but still accessible on the inside. I remove the obstruction making all 24 entrances available to the bees. I did this at 13:00 and the rest of the day counting has dramaticaly improved (also the error counters went drastically down). I found the millis function and used it to trim down the delay to 8 ms. Tomorrow is another sunny day so i will see how the counters behave.

I tried to figure out if i could count a train of bees (1,2,3,4...) but i am confused with the content/use of the transition_table and next_state function and how it can be eventually used in this matter.

[claespol]

Hello @svavassori Is it correct when i think that in the transition_table array EMPTY stays for 00 (insensor-outsensor bits) START_ENTERING stays for 01 ERROR_STATE stays for 11 MIDDLE_ENTERING stays for 11 END_ENTERING stays for 10 START_EXIT stays for 10 MIDDLE_EXIT stays for 11 END_EXIT stays for 01

I also noticed that inbound pattern differs from outbound pattern. I cannot figure out why this is?

[svavassori]

Hello @claespol

If you want to close some gates, it is better to close them from both sides or filter them out then looping on the gates

About the transition_table, it is a classical implementation of a state machine in which the current state and gate's values (array indexes) tells you which is the future state (array value). Inbound and outbound sequences are exactly symmetrical: 1 means there is a bee under that sensor (i.e. 00 > 01 > 11 > 10 > 00 and 00 > 10 > 11 > 01 > 00), and if the hamming distance is 2, it is considered as error.

[claespol]

Hello @svavassori Last night I came to solve (or better explain the errors). One of the shiftregisters was broken. The last 4 ports were not working and inducing errors. So I replaced the counterhardware with a new one I was building and nearly ready. Installed it today at 14:57. Counters look better but see more errors on outgoing than on incoming roughly 3X higher. Will look tomorrow at a full day count (Sunny day and 17°C). Thx for explaining it clarifies a lot to me (a 67Yrs novice).