Restrict pellet detection to avoid false positives

[Nik Hayes]

One thing I've noticed is that it's possible to register multiple pellets before a motor turn is even able to actually drop a new pellet... I haven't looked into the code yet (still absorbing things) but would it make more sense to have it so that no pellet can be detected until the motor has at least turned somewhat?

[lmur...@vt.edu]

So, I'm convinced you must share wavelengths with us, or have our lab bugged (/sarcasm). 

We are in the middle of a months long experiment and just realized this exact thing literally an hour before you posted. 

We suspected over counting in the form of a pellet bouncing in the well, and manually recreated it. In the following test file, pellets 2, 3, 6, and 12 thru 14 were all a single pellet that was manually jostled a bit in the well, but recorded as three pellets. Somehow, the rest motor turn number function isn't called at the right time, and is held when logging the data. 

[Lex Kravitz]

Hi!  Thanks for writing, and for catching this!  Are you both experiencing this with only the free feeding example?   I confirmed that it occurs there, but not in any example that requires pokes. I think I understand why this is happening (and I will update the free feeding example in the next library release to stop this - thanks again for posting about it!).

An explanation: In the free feeding example, the void loop() on FED3 just calls fed3.run() and fed3.Feed() over and over again: 

void loop() {
   fed3.run();     //Call fed.run at least once per loop
   fed3.Feed();    //Drop pellet
}

fed3.run() updates the screen and a couple timers which takes ~130ms. Then fed3.Feed() turns the motor until a pellet is detected, and exits the fed3.Feed() function when the pellet is removed. So if a pellet was detected during fed3.Feed() and then bobbled, FED3 will count the pellet, exit the fed3.Feed() function, call fed3.run(), and then go right back to fed3.Feed(), which will not turn the motor because the (same) pellet is ~immediately detected (and re-counted). And each time it's bobbled the process repeats, allowing for multiple counts off the same pellet. 

This behavior is not ideal.  I have a quick fix for you.  If you add a timeout after fed3.Feed(); it will stop this rapid pellet-counting behavior for at least the duration of the timeout.  You can add the following line to the free feeding example to add a 5s timeout:

void loop() {
   fed3.run();      //Call fed.run at least once per loop
   fed3.Feed();     //Drop pellet

   fed3.Timeout(5); //5 second timeout

}

As a fix for your data that's already recorded, I would filter out rows based on the InterPelletInterval columns (Column O).  In my experience, mice take ~10-20 seconds to eat a pellet, so if this interval is 0s or 1s you can assume that was a bobble and not a real pellet removal.  

Let me know if this makes sense and if you have other thoughts or discoveries about this!  

-Lex

[Nikolas Hayes]

Thanks Lex! Yep, it's just the free feeding that I've tried.

On another note, I'm trying to figure out the code a bit better so that I can try to make a lower power free feeding mode (i.e. sleep the screen and turn off everything else that might be unnecessary).

--
You received this message because you are subscribed to a topic in the Google Groups "FEDforum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fedforum/Sclp1oIXxnY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fedforum+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fedforum/c75df8d5-6195-4b01-91a8-808a7ac57553n%40googlegroups.com.

[Matias Andina]

Hello,

A bit unrelated but wanted to add my two cents here about double pellets on free-feeding mode.

We have noticed that FEDs deliver 1.1 to 1.2 pellets per each pellet counted. This average comes from multiple pellets going down the well. We didn't notice too many rebound errors, though we didn't look hard enough I guess.

We did notice that the motor turns in such a way that two pellets are delivered before the first one can be registered and the motor stopped.

I guess this is related to the position of the motor, sometimes 1 motor turn will be enough for two pellets to go down before detection.

Best,

Matias

You received this message because you are subscribed to the Google Groups "FEDforum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedforum+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fedforum/CAGCy6WeZR%2BQG9VZCg21sJQhtBOUKhqU-u%3DGZ6093Nb%3DLXYQCtA%40mail.gmail.com.

[Lex Kravitz]

Thanks for bringing this up Matias!  This is concerning to me - we spent a while calibrating this (see Fig 2 of the FED3 paper), but I haven't revisited this issue in ~2 years.  Do you think it would be helpful to slow the dispensing down?  To give FED3 more time to detect the first pellet?  As soon as the pellet well IR beam is broken the motor will stop, so if the motor is continuing to turn either the pellet is not detected, or it is still on its way down the chute when the 2nd pellet is dropped.

The other possibility is that if the metal pellet well isn't positioned correctly there may be a position in which a pellet can drop but not break the beam, and then FED3 would dispense another pellet, and the 2nd would break the beam.  Could this be happening?

Let me know if you have time/interest in testing the impact of slowing the motor down on this.  Thanks again for bringing this up!

(Also Nik, I'll start another thread about power consumption!)

[Nik Hayes]

I was just looking at the speed at which the motor turns and it seems pretty fast --- I have a feeling it wouldn't hurt to turn down the speed slightly but I'd need to check with the Fed3's I'm almost done building now. If the speed of the wheel turning is slower maybe you'd get less grinding of pellets together as well --- I'm just imagining this could help with the pellet types that tend to fall apart more easily.

[Matias Andina]

I think it's a sum of all things you mentioned, positioning of the nosepiece is key. The 1.1-1.2 average is likely not dominated by this issue with the turns.

"As soon as the pellet well IR beam is broken the motor will stop" -> I do notice this and the motor might stop perfectly aligned to the chute for the second pellet.

I wish I had hard data to back this up, all I have comes from counting manually ourselves with the lid of the hopper open and seeing these events during calibration.

It might not be a problem with the electronics, it might be a problem with the prints (pellets taking a bit longer than they should on the chute, the FED doesn't stop as if it had turned with an empty disk hole, once the first pellet is detected, it's too late and the second one is coming). Because I'm mostly running free-feeding, it doesn't kill our experiments so I decided to take it as an acceptable rate.

I should probably run this calibration on shapeways prints, that will likely be on the lower end. 

Best,

Matias

To view this discussion on the web visit https://groups.google.com/d/msgid/fedforum/d1ed78e9-3adc-456b-928c-3c53797ab32an%40googlegroups.com.

[Lex]

Yup these are time consuming issues to calibrate and test!  We did our prior calibrations (in the eLife paper) by weighing the FED3 each day and comparing the decrease in weight to the # of 20mg pellets that were registered by the FED3.  

It sounds like we should try slowing the motor down and doing a head to head calibration test to see if that improves reliability, I'll just have to find time to do it!  

(Or if anyone reading is looking for a new hobby and thinks this sounds fun, please email me!)