Odrivetool with UART does not seem to work

[peredwardsson]

Describe the bug With the serial port /dev/ttyTHS0 connected to the Odrive, I try to open odrivetool and use this port.

$ odrivetool --path serial:/dev/ttyTHS0
ODrive control utility v0.5.4
10:54:25.233937779 [FIBRE] transport layer "serial" not implemented

To Reproduce See above

Expected behavior Odrivetool opens with connection.

Desktop (please complete the following information):

• OS: Ubuntu 18.04
• odrivetool Version: ODrive control utility v0.5.4

Additional context Running on a Jetson AGX Xavier. Can connect to the odrive via screen. odrivetool -h suggests that I run odrivetool --path usb,serial:/dev/ttyUSB0, which also doesn't work.

$ odrivetool --path usb,serial:/dev/ttyUSB0
ODrive control utility v0.5.4
10:58:08.893970678 [FIBRE] transport layer "usb,serial" not implemented

[samuelsadok]

The current version of odrivetool doesn't support connection via UART because we changed around some stuff and this feature was too niche to carry along.

Is it feasible for you to connect the ODrive via USB instead for configuration?

[peredwardsson]

Yes, for configuration it works fine. However, for troubleshooting, it is unpractical. We communicate via UART, and having USB as well or via another cable for troubleshooting purposes is just not quite as smooth as being able to do it remote. I understand if the functionality is too niche, I just noticed that serial communication works fine via screen so making an odrivetool-like application that works on UART does not seem like too much of a problem. Maybe I will make it myself instead. :)

Perhaps the documentation needs to be updated regardless. Anyway, very much appreciate the stuff you guys produce, keep up the good work.

[samuelsadok]

Yeah two cables are not nice. Are you controlling the ODrive from a computer or from another MCU? If it's from a computer, perhaps you can use USB for your regular communication too.

Note that there are two protocols (on UART, only one of them can be enabled at a time):

• Fibre: Machine-to-machine oriented, more reliable & efficient, supports the full ODrive feature set, used by odrivetool.
• ASCII protocol: Human-to-machine oriented, less reliable/efficient, doesn't support all features but easier to implement in custom code, can be used to type commands directly in screen.

If you'd like odrivetool to support UART, the cleanest way would be to implement the corresponding backend in Fibre.

[peredwardsson]

Makes sense. We communicate via a computer. Our experience with Fibre + USB was quite poor, which is why moved to other protocols. Ultimately we would prefer CAN, on advice from your team, although we have some problems implementing it on our side. So far, best performance is gotten with ASCII protocol delivered via UART.

For the record, the poor experience we had related to poor stability related to error handling. The fire-and-forget nature of UART + ASCII seems like a better fit, at least for now.