Delay in Receiving CAN messages from ODrive S1

Support ODrive S1 Support
1

Hello,
I am currently using a Raspberry Pi 4B with the ODrive S1 to control a motor through CAN. I can set control values on the ODrive in real-time through without any issues. However, I am encountering a significant delay when trying to receive the torque values back from the ODrive while closing the loop.

I am unsure if this delay is due to a configuration issue on my end or if the ODrive is designed to prioritize setting control values over retrieving (get) them. To address this, I have tried turning off all cyclic messages except for one or two which are relevant, but the delay persists. The cyclic messages are set at 5 ms. I also checked the CAN bus load, which is around 40-50%, so it does not seem to be excessively loaded.

Could anyone provide insights into what might be causing this delay or suggest potential solutions to optimize the real-time data retrieval from the ODrive S1? Is anyone else facing this issue? Is there a workaround this?

Thanks!

2

Hi! What are you using to receive the messages on the Pi? I assume a CAN HAT, or are you using a CAN-USB adapter? And are you using python-can or something else? How long is the delay, on average?

3

Hi!
I am using a Raspberry Pi CAN Hat (Amazon.com). I have tested it with both python-can and MATLAB/Simulink on the Raspberry Pi.

Additionally, I also tried using an ESP32 with a CAN Hat (Adafruit CAN Bus FeatherWing - MCP2515 : ID 5709 : Adafruit Industries, Unique & fun DIY electronics and kits), using the Adafruit_MCP2515 library.
Still the same results.
The delay is around 1 second.

4

My first thought is that you’re not polling for messages fast enough, so the incoming buffer is filling up faster than you’re receiving. The other possibility is that your CAN bus has some sort of electrical issue (e.g. only one termination resistor, spotty wiring, improper grounding, etc) that’s causing the ODrive TX to fail (at which point it’ll retry). My guess is that it’s the former – both of python-can and Matlab are going to be fairly slow, especially when using python-can you need to ensure there isn’t any code slowing things down and blocking your incoming messages – usually I’ll use multithreading or multiprocessing to poll the bus and add messages to a queue/fifo/etc to be processed. 400Hz polling (2x cyclic messages at 200Hz) is pretty fast, so a bit of consideration is needed.