Communication Watchdog


There are many applications where the ODrive is used where the various
communications channels (USB, UART, etc.) are used to dynamically control the
controller settings, such as setting the desired velocity of the motor based on
some sort of external control.

This presents an issue in situations where the communication channel between the
ODrive and the external controller becomes interrupted either due to a crash on
the external controller or a disconnection of the communication wiring.
Currently, in such a case, the ODrive continues on its last configured
instruction. Depending on what’s connected to it, this can cause a host of
issues such as a vehicle running at full speed into a wall or person.

One way to help with this issue is to implement some sort of communication
watchdog for the ODrive motor control classes. This watchdog system would
prevent the Controller class from driving the motor MOSFETs if a property has
not been changed for longer than a specified interval. Setting a property on the
Controller class would act as a reset to the watchdog and allow the Controller
class to again control the motors.

The way I see this working is as follows:

  • A new property watchdog_timeout is added to each axis. This property
    specifies the watchdog timeout, in seconds, for this axis. If the watchdog
    has not been fed for a time exceeding this timeout, then the motor is
    disarmed and not driven. The value of this property would be saved in
    non-volatile memory. Setting a value of 0 for watchdog_timeout will
    disable this watchdog.

  • A new property watchdog_feed is added to each axis. Writing any value to
    this property will reset the watchdog interval and allow the motor to be

  • External control loops will write the watchdog_feed property after setting
    updating any setpoints or other parameters of the axis. If the external
    controller crashes or otherwise ceases communication, then the watchdog_feed
    property will not be written and the axis will eventually transition into
    safe mode until the watchdog is fed again.

I’d appreciate any thoughts on this subject. Would there be a better way to add
fail-safe functionality to the communication channels? Is this something that could be
considered for inclusion into the default firmware for the ODrive?


Paul Belanger



I like it in general - implementaton specifics need to be worked out. I think it’s best to put a single communications watchdog somewhere for that comms thread. And then any axis -> comms thread interface would have a separate watchdog

External < === > Comms thread < === > Axis 0/1



I would like to just like to add support to this idea. We are using odrives on quite a big robot and already needed to use a hard estop when the odrives lost communication.



@Paul_Belanger Your proposal as written sounds perfect. If you are up for writing this yourself, then I’d suggest to decrement the timeout variable right here, and add a variable like communication_ok.

We could add in calls to watchdog_feed() in the p, v, c, t commands on the ascii protocol while we are at it, since calling those would constitute runtime type communication.

Let me know if you are not comfortable to dive into the firmware code, in which case I can add this when I find some time.



I’ve created an initial implementation of the watchdog, and have submitted a pull request:

I’ve added a watchdog_timeout property to the Axis configuration, as well as a watchdog_feed() method to the axis api.

For the ascii protocol, I’ve added watchdog feeding to all setpoint commands, and added an additional u command to update the watchdog of a motor axis.

I haven’t had the hardware availability to actually test this patch yet, but I should be able to get my hands on some hardware by next week or so.