MicroPython and Odrive?

I was just about to order 6 pieces of Odrive V3.6 56V for a robot dog project.
Before ordering, I looked for a MicroPython library and MicroPython examples, but couldn’t find them?
Does Odrive not work with MicroPython?
Thanks for an answer

You cannot run micropython directly on ODrive (it needs all of its CPU for motor control) but you can certainly control ODrive from an Arduino or similar which runs MicroPython, and then communicates with ODrive by UART or CAN Bus.

Yes, I would like to use Odrive on a raspberry pi pico with MicroPython.
But I can’t find any MicroPython libraries and or UART commands in MicroPython.

Is this what you want?
https://docs.micropython.org/en/latest/library/machine.UART.html

You can just send the commands from either the ODrive ASCII protocol (really simple to use, but limited in speed) or the native protocol (faster, but harder to use)
In the ASCII protocol, you can literally just say uart.write("p 0 10\n") for example, to move axis0 to position 10 (revolutions). This is the equivalent of odrv0.axis0.controller.input_pos = 10 in odrivetool

see ASCII Protocol | ODrive

1 Like

Thanks for the answer.
Yes, I was looking for this commands reference.
That means I can send commands via UART using ASCII and use all Odrive functions as it looks.
What does limited speed mean?
Is this enough for a good dynamic regulation?

1 Like

That’s a difficult question to answer without knowing specifics, such as the bandwidth requirement, and also how much data you need to send/receive each cycle.
Given that this is a robot dog, I’m guessing you will be in torque mode, querying the position and velocity and updating the torque as fast as possible.

If you send f 0 to request feedback, odrive responds with something like 10.002671 0.1674567\n (if position is about 10 revs and velocity is 0.16 revs/s.)
This message is 20 characters long (and could get longer with different positions / faster velocities).
20 characters is 160 bits, which takes about 1.5 milliseconds to transmit at 115200 baud.

But the data itself is 2 32 bit “IEEE 754” floats, so a binary protocol such as CAN would use only 64 bits + 37 bits of overhead (message ID, CRC, end of frame etc) = 101 bits, which would take just under 1ms to transmit at the same bitrate.
It also runs much faster (500kbit/s, so the message could be sent in 0.2 ms) and is much more reliable than UART, due to its use of differential signalling, CRCs, message priority, automatic error detection & retransmission.

If you’re confused by all of that, then go ahead with the ASCII protocol, knowing that you can improve the bandwidth slightly by switching to the native protocol or CAN bus later on. :slight_smile:

2 Likes

Thank you for this detailed answer! :+1: