Daisy chaining ODrive via CAN Bus


I’m re-engineering a robotic arm that uses 3 ODrives to control 5 motors using a Raspberry Pi 4.

It currently has three USB cables running from the RPi to each of the ODrives.

I’m hoping instead to run a single USB cable to the first ODrive and then daisy chain the other two over CAN bus.

Has anyone done this before? Would it be more reliable than using three USB cables?

Thanks in advance


No, you need a CAN interface on the controller end. Use USB for configuration of each ODrive (gains, etc) and CAN for real-time control. You can disconnect the USB while in use, and it should be a bit more robust to electromagnetic noise.
Get a USB-CAN adapter e.g. “innomaker” https://www.inno-maker.com/product/usb-can/ - this one is good because it is isolated, cheap, and works out of the box with Linux (socketcan) and Windows (pyusbcan)
Connect CANH and CANL of each ODrive and the USB adapter in a bus configuiration. The last ODrive (furthest from the USB adapter) needs to have the terminator enabled, and the others you should turn the terminator off.
The CAN protocol is dead simple to use, but I can post some examples if you need.

BTW, do you have any ferrite rings in your robot? I’d highly recommend adding some if not. (they improve control performance by reducing noise on the current sensors, amongst other things)

Hi Tom

Thanks for explaining this. We’re quite tight on space, would something like this work too SN65HVD230 CAN Board - Waveshare Wiki

Should I be running a ground wire between the ODrives or just the twist pair for the CAN H and L?

Some sample code would be great.

And thanks for the tip on the ferrite rings - the original version didn’t have them, I’ll order some.



What controller are you using for the robot? The board you mentioned is only a differential transceiver, and will only work if you already have CAN TX and RX pins on your controller, e.g. NVidia Jetson AGX Xavier has this, along with some other single-board computers.
Raspberry Pi for example does NOT have them. You need a CAN interface IC e.g. mcp2515 in addition to a transceiver for that.

If you are using a Pi, then you can get a ‘hat’ with a MCP2515 SPI-CAN interface plus a differential transceiver.

The board I posted is pretty compact tbh, and it doesn’t need to go in the confined space where the ODrives sit. It plugs into USB and is wired directly to the CANH/CANL pins of ODrive from there.

You don’t need an extra ground wire because the ODrives already share a ground via the battery (you need to make sure that the positive supply is never connected before or without the negative)
And CAN is differential and can tolerate a few volts of ground difference between boards.
Normally you’d need to connect a ground to the controller, but with an isolated CAN interface like the one I posted, you don’t need to (although it might still help if you do connect a GND from one of the ODrives to the isolated side of the interface).

I posted an example here - see if this helps:

There’s also the ODrive CAN guide if you haven’t read that :slight_smile:

Hi Tom

It’s a Raspberry Pi 4 controlling everything. The Raspberry Pi is located in the arm of the robot and space is super tight, hence me looking for more compact options - also the InnoMaker is out of stock in the UK and we’re on quite a deadline. Looking into Hats, I’ve found this

Is this the sort of thing you were suggesting?

I’ve read through the ODrive CAD guide - really helpful.

I’ll have a read through the code properly later on - we’ve got a guy joining the team next month to help with all the coding - I’m not a coder myself, sadly, as it would make things easier.

Thanks again.



No, RS485 is not the same as CAN.

I was thinking more along the lines of: PiCAN2 Duo Isolated CAN-Bus Board for Raspberry Pi 2,3,4 — SK Pang Electronics Ltd (not cheap, but isolated)
PiCAN3 CAN-Bus Board for Raspberry Pi 4 with 3A SMPS + RTC — SK Pang Electronics Ltd
(non-isolated - with this one, you need to be careful about ground loops between the Pi and the ODrives - but it does include a real-time clock for the Pi, and a SMPS that will power the Pi from up to 30V - not 60V sadly)

Also, if this is a static robot arm, have you considered locating the Pi on the outside? :stuck_out_tongue:

The PICAN2 HAT looks really good, we’ve got the budget for it. I couldn’t find a schematic for it, but look at the schematic for non isolated one, it seems that quite a few of the RPi GPIOs are free - The RPi also controls a vacuum pump, solenoid valve and light using the GPIO. I’m guessing it’s possible to stack another HAT on top, like

The controller I found before, said RS485 CAN - is that quite different to CAN?

Unfortunately, the Pi can’t be located elsewhere - the robot moves on linear rails, power is sent through the linear rails. There are no wires to the robot.

Thanks again for all your help.



Oh sorry, I hadn’t read that properly - indeed RS485 is quite different to CAN, and I don’t normally associate RS485 with CAN, normally you want one or the other. :grinning_face_with_smiling_eyes:

Actually it’s RS485 AND CAN, the two are independent of eachother. It’s basically the same as the SKPang PiCAN 2, in that it’s a MCP2515 connected to one of the Pi’s SPI ports, with a non-isolated CAN transceiver (and a RS485 transceiver thrown in too, connected to one of the serial ports of the Pi) and quite a lot cheaper too!

1 Like

Yes, it’s check and pretty compact - I’m going to buy it and the GPIO breakout - see if we can fit them nicely in the arm.

I suddenly had a thought about using the CAN bus rather than the USB connection - on two of the ODrive boards there are sensors connected to the ODrive GPIO and the AVCC pin on the other ODrive. Do you know if there will be an issue reading these sensors over CAN?

Once again, thanks for all your help.

Have a lovely Christmas.



You can add anything you like to the CAN protocol with a simple firmware mod - that’s the beauty of ODrive being open source.

See this thread: Modify firmware to also obtain the measured current from axes using CAN (without having to send the 0x014 msg) - #2 by towen

Merry Christmas! :grinning_face_with_smiling_eyes: