Actuator drift when controlled with bpod

David_G

Hi Josh + others!

I’m working on an experiment in which the positions of two lick ports are modulated by linear actuators. To do this, I have strapped a bpod Arduino shield onto an Arduino Zero, which is connected to two linear actuators (one per port) via an L298N driver. When I run a simple standalone test with this Arduino function (extend both ports for X ms, pause, retract both ports for X ms), I find that I am able to accurately control the positions of the lick ports with little to no drift. However, when using a similar function during my bpod task (still using the same amount of time for extending and retracting), both ports drift considerably and in different directions (although one is not quite as bad as the other), such that after about 20 trials one of the lick ports can no longer be reached by the mouse and the other one is poking into its mouth.

Although I imagine I could try to resolve this by first determining if the extend/retract difference is consistent and then changing the extend/retract times accordingly, I’m using some very small movements and measuring their accuracy is non-trivial. Also, the fact that this issue is not inherent to the actuator (given that the standalone test showed no drift), I’m not super excited about that option.

Accordingly, I was wondering if you have any idea why I’m experiencing a drift only in the context of my bpod task, and also if there’s another way of connecting the actuators to bpod (i.e., via softcodes) that might circumvent this issue. Some of my animals have already started pre-training and I’d really like to get this sorted out this week, so any assistance you could provide would be appreciated! Also, please let me know if any additional information would be helpful for troubleshooting this problem (i.e., the bpod task script) and I’d be happy to send it along.

Thanks so much!

-David

Josh

Hello David,

In your first example code, you pause for 500ms and then 1000ms after setting the motor driver pins. The motor has inertia, and this delay gives it time to come to a complete stop. The second example code receives movement instructions from the state machine, which would need similar delays in place. If the motor driver is commanded to move while the shaft is still slowing to a halt, you wouldn't reach the final position and you'd see drift.

In general, rodents are very prone to side bias, and seemingly minor differences in the final position of the left and right lick tubes can have a confounding effect on your experiment. For this application, I'd consider a stepper-driven linear actuator e.g. this, and a stepper driver e.g. this. The changes to your Arduino code will be reasonable to implement, and you'll have much better precision.

-Josh

David_G

Hi Josh,

Thanks so much for the speedy reply and helpful links! Sorry for not mentioning this in my OP, but I saw the same behavior when I include a delay(500) command after each movement in my task Arduino code (as per the test code, so I removed it along with some other attempted fixes from the version I uploaded), and each of my actuator control states is at least 1000ms (so no overlapping commands). Given that information, and the fact that each actuator drifts in different directions and with different magnitudes despite receiving the same commands, I’m not sure inertia would explain what I’m seeing? The actuators I’m using are very precise when controlled with my pure Arduino script, just not in the context of my bpod task, so I was hoping to avoid buying new actuators. In any event, I wasn’t familiar with the stepper actuators and those definitely look like a better fit for the project- if you think those wouldn’t be affected by this kind of thing, I’ll happily make the switch!

-David

Josh

Hello David,

Can you please share your Bpod code?
If it's long or multiple files, you can Email it to support@sanworks.io

Thanks,
Josh

Josh

Hello David,

Looking at your code, in certain states, the state machine sends a single byte to the actuator firmware to run movements that last up to 728ms. The state machine always waits at least 1s between commands to the actuator module. I suspect that the issue is at the firmware level.

Here's are a few debugging steps to try:

In your firmware, replace
ArCOM Serial1COM(Serial1);
with
ArCOM Serial1COM(SerialUSB);
Serial1COM will now target the USB interface.
Change your op codes from 1-12 so that they are now 65-79.
From the Arduino application, open the serial terminal. You can now take the state machine's place, and send op codes using upper-case letters A-L for codes 1-12.

If you send the operations approx. once per second, do you still see the drift? If so, the state machine and your MATLAB code are not implicated.

-Josh

David_G

Hi Josh,

Thanks so much for looking through the code! I implemented the debugging you suggested and did not observe any drift with either port…

-David

David_G

Hi Josh,

With further testing, this issue does in fact appear to be caused by actuator inconsistency- thanks again for your help, I'll grab some of those stepper-driven actuators!

-David

Josh

My pleasure. Please don't hesitate to reach out if you run into any more issues!