gilestrolab / ethoscope

a platform from monitoring animal behaviour in real time from a raspberry pi
http://lab.gilest.ro/ethoscope/
GNU General Public License v3.0
17 stars 25 forks source link

Motors not being activated during tracking #150

Closed posttenebre closed 3 years ago

posttenebre commented 3 years ago

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.

semerson916 commented 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.

ggilestro commented 3 years ago

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.

antortjim commented 3 years ago

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.

antortjim commented 3 years ago

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

antortjim commented 3 years ago

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
posttenebre commented 3 years ago

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

ggilestro commented 3 years ago

Hi @posttenebre - How are you powering the motors / PCB? Can you send a detailed description or photo of your setup?

posttenebre commented 3 years ago

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?

ggilestro commented 3 years ago

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?

antortjim commented 3 years ago

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.

posttenebre commented 3 years ago

@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.

ggilestro commented 3 years ago

I understand this is solved. I will update the instructions to make sure this misunderstanding won't happen again.