Closed posttenebre closed 3 years ago
I am also having the same problem. I am unable to get the motors to work when tracking. What was the command you used for the demo? I would like to try that out as well.
The new module with the new electronics has its own stimulator, called mAGO
I would like to code a system so that the stimulator is "learned" by the module itself but I have not had time to do it. Use mAGO with the "motors" option.
I just tried the new PCB from Giorgio (with amazing results so far, only one dirty experiment for now!!!!!!!!!!!!)
But indeed I noticed the roi to channel mapping might have to be updated for the stimulator to work
I created this derived Stimulator
class https://github.com/shaliulab/ethoscope/blob/afec38294e19bc05931cd7aac1a74ed8c4333292/src/ethoscope/stimulators/sleep_depriver_stimulators.py#L271 to account for this minor issue
I also wrote a derived interface to account for the reduced number of channels on this new chip and the lack of support for tuning pulse intensity (only duration). For that I had to tweak the OptoMotor class https://github.com/shaliulab/ethoscope/blob/deployment_test/src/ethoscope/hardware/interfaces/optomotor.py
A quick check to verify your issue is the roi to channel mapping, I suggest you connect your Arduino to a computer with the Arduino IDE installed on it, set the board and port to the Arduino Micro chip, go to Tools > Serial Monitor, and enter D
If the chip and everything works, you should see all your motors moving
If you want to know what's the right mapping, try sending
P 1 1000
P 2 1000
and so on.
More complicated maybe, you can debug your code by writing the following
logging.warning(instruction)
after this line in your ethoscope https://github.com/gilestrolab/ethoscope/blob/38b0fe95ebfae087b5fbabe7a1468ad0e28ef08b/src/ethoscope/hardware/interfaces/optomotor.py#L99
reboot the ethoscope and start tracking again, and then check what instructions is the RPi sending live, by running journalctl -fu ethoscope_device
on the actual ethoscope. In the PCB I kindly got from Giorgio (v1.0 is written on it), I got it to work when I used odd channels (1,3,5,7,9,11...19) and connected my motors to the M plugs.
I am assuming the Arduino you have in your PCB has been flashed with the code in https://www.notion.so/The-new-Modular-SD-Device-05bbe90b6ee04b8aa439165f69d62de8
If you want to try the demo from the ethoscope, save this to communicate.py
import argparse
import serial
ap = argparse.ArgumentParser()
ap.add_argument("cmd")
args = ap.parse_args()
cmd = (args.cmd + "\r\n").encode("utf-8")
port = "/dev/ttyACM0"
baud = 115200
handle = serial.Serial(port, baud, timeout = 2)
print("Sending instruction", end=": ")
print(cmd)
handle.write(cmd)
for i in range(10):
try:
l = handle.readline()
print(l)
except KeyboardInterrupt:
print("Exiting")
break
handle.close()
and then call it like this
python communicate.py "D" # runs the demo, which triggers every pin from 0 to 19 for 1000 ms
python communicate.py "P 1 1000" # activate pin 1 for 1000 ms
Dear all,
Thanks for all the suggestions. I apologise for not dealing with this sooner.
I had already flashed the arduino with the code at the link. I used the appropriate mAGO tracking option, but it had no effect on the issue. I also tried logging the motor activation as described. I see motor activation logged when using the python script mentioned above but not when tracking.
Additionally I have one error message in the ethoscope node logs that might be irrelevant but will need to address eventually.
error: object directory /tmp/yaourt-tmp-node/aur-ethoscope-node/ethoscope-node/objects does not exist; check .git/objects/info/alternates
Hi @posttenebre - How are you powering the motors / PCB? Can you send a detailed description or photo of your setup?
So I have been able to make it work and have the motors spin when the flies stop moving. Before I explain my mistake I apologise for not thinking of this earlier. Because there are 10 motors I only filled the slots in the holder where a tube comes into contact with the motor drive shaft. I thought that maybe the issue was arising from the need for all the slots be filled. Once I did the motors came to life. Is it possible that there is an offset where the motors are activate by the adjacent tube? or is it simply necessary for all tubes to be present with flies for the tracking to function correctly?
This is weird. Is it possible that you mounted the SD module in the wrong direction and that therefore the ethoscope was looking a the wrong ROI?
Hi @posttenebre , I would suggest you share a pair of .db files, one where the SD failed and one where it worked. That will figuring out what happened.
@ggilestro Thank you for that suggestion. I rotated the ethoscope on and it now appears to work correctly even with only the motor shaft touching slots filled. I missed this need for correct orientation while building the SD module. So the slot opening on the motor holder needs to face the side of the USB port on the arduino?
@antortjim I have some .db files if you still with to take a look, but I suspect this is now sorted.
I understand this is solved. I will update the instructions to make sure this misunderstanding won't happen again.
System Raspberry pi 3B+ New optomotor module with printed PCB v1.0 DEV (2021-02-03 14:34:58)
Problem Motors work but not when tracking. They work when sending cmd 'demo' and also spin-up when starting the tracking.
Troubleshooting Tried a few different stimulation options. SleepDepStimulator, OptomotorSleepDepriver, and OptoMidlineCrossStimulator do not activate the motors. Even OptomotorSleepDepriverSystematic does not activate the motors at the set interval, but it does spin-up the motors when starting the tracking.