Why am I getting the error “state : waiting for odrives” on the web control page when bot_ctrl.py is launched as a systemctl service per the instructions provided?
It works as described when I manually start the demo script bot_ctrl.py but I am getting the waiting error AFTER I set up the auto start systemctl bot_ctrl.service to run the same script. I removed the SSL flag and still getting the same error.
I checked the CAN bus wiring and found no problem.
I suspect there is a CAN BUS initialization or timing problem during the service startup.
Can you ssh into the Pi after having that issue (e.g. after a reboot, once the webpage is reachable but the CAN isn’t working), and show the output of:
sudo journalctl -u bot_ctrl.service
sudo systemctl status bot_ctrl.service
ip link show can0
Also, if you run candump can0, does it show any received CAN packets?
I then reboot the Pi with “sudo reboot” but leave the power on".
When I SSH back into the Pi, everything is working fine.
“candump can0” is returning a stream of data.
Web page showings “state: coast”.
I tried this 3 times today. Same result. Repeatable.
Suspecting a startup timing issue between Pi and Odrive (I guess odrive was looking for the keep alive messages when starting up, failing so, then shuts off) , I tried the following:
Turn OFF the e-switch (that powers the odrive but not Pi) when booting up Pi with the battery switch. This gives Pi some time to initialize. Wait for 10 secs. Then turn ON the e-switch, thus powering the odrive and let it boots up after Pi. This works to get the “coast” state when the web page connects !!! I tried this 3 times and works every time.
Now… Is there a way to config Odrive to deal with this timing issue?
Suspecting a startup timing issue between Pi and Odrive (I guess odrive was looking for the keep alive messages when starting up, failing so, then shuts off)
Watchdog messages only apply to when the ODrive is in closed loop, so it shouldn’t fully apply here. I’m wondering if the CAN HAT on the Pi is initializing into a super weird state if there’s CAN messages on the bus (the ODrives are configured to send out a pretty high amount of CAN messages). This could also be a software issue in our bot_ctrl.py code – it’s really just a demo application, I’m sure there’s a bug or two in there.
I’m curious – can you try this:
sudo systemctl disable bot_ctrl.service
Reboot the Pi while keeping the ODrives on
sudo ip link set can0 up type can bitrate 250000
See if candump can0 outputs anything
If not, it would be interesting to connect to the ODrives over USB and check: odrv0.can.error odrv0.can.n_restarts odrv0.can.n_rx odrv0.can.effective_baudrate
