When building any robot or system — whether a complex multi-axis quadruped or a simple actuator — you need some way of communicating with the motor drivers themselves. Hundreds of standards exist out there, from the commonplace to the esoteric — from USB to PWM, EtherCAT to Modbus. However, our favorite — and the protocol of choice for the ODrive Micro — is CAN, which we’ll be taking a deeper look at today.

Why not USB?

When you get your ODrive Micro, chances are the first thing you’ll do is plug it in over USB. And USB is a great protocol! It’s fast, ubiquitous, and flexible. That being said, USB has a few flaws.

First, USB is a very complex protocol. This means there’s lots of layers between ODrivetool or the GUI sending a command to the ODrive, and the data actually being sent, from buffers and delays in your web browser or Python, to your OS, to your computer’s USB controllers. This leads to difficulties guaranteeing message timing, random delays, and other issues, which are especially evident when streaming position setpoints or trying to get precisely timed data back from the ODrive.

Next, USB isn’t very electrically robust. The electrical engineers out there will know it uses a protocol based on uses differential signaling, which means there’s a certain amount of immunity to electromagnetic interference, more than, e.g., a simple UART serial connection. However, the particular nature of the differential signaling USB uses is more designed around maximizing speed, not robustness to interference; long, unshielded USB cables need to be routed away from motor and power wires otherwise the communications can drop.

Furthermore, USB requires a ground connection, which puts you at risk of ground loops. While not an issue for most electronics devices, this is problematic with high-power motor drives and can cause damage to the ODrive or even your host computer. As a result, a USB isolator is strictly required for each ODrive connected to both USB and power at the same time.

And the USB connector itself can be an issue — locking USB connectors are quite rare and, whether USB A or C, vibration can cause momentary disconnections; not great in a robot!

Finally, USB is a 1:1 protocol — only one USB device can talk to a single USB host. Even with USB hubs, a different USB cable is required to connect to each USB device. In a system with twelve ODrives, this would be a veritable mess of USB cables and isolators. You should see our test rack!

Why CAN?

Luckily, for every problem USB has, CAN bus has a solution!

But first, some background. The CAN (Controller Area Network) protocol was originally developed for automotive applications back in the ‘80s. Modern cars have hundreds of pieces of electronics, all of which need to communicate with the central controllers. In addition, there’s plenty of electromagnetic interference being generated from the engine spark plugs, vehicle wiring, and various motors in the car. The data can be safety-critical, so it’s crucial that the electrical signalling protocol is robust and reliable.

So what does CAN look like? Typically, it’s a single pair of wires, which every device on the bus connects to. The two wires — called “CAN High” and “CAN Low”, or CANH/CANL for short — always have the opposite voltage from each other; when one goes low, the other goes high, and vice versa (those with CAN experience, please forgive my over-simplification).

Now, for most communication protocols, everything from SPI to Serial to PWM, a logic high or low is determined by the wire’s voltage relative to the ground voltage — e.g. 5V relative to ground is “high”, 0V relative to ground is “low”. However, with CAN, the two wires are compared with each other — if CANH is higher than CANL, it’s a “high”, and if CANH is the same as CANL, it’s a “low”. As a result, even if there’s a massive amount of electrical interference, as long as the interference affects both CANH and CANL the same amount, the receiving devices won’t even notice!

This robustness also allows each CAN device to not need a ground reference: as long as they’re all powered from the same source, only CANH/CANL is needed, removing any issues with ground loops. See our CAN hardware setup page for more information.

Each device gets a unique “CAN ID”, allowing them to be identified, addressed, and communicated with. In fact, up to 63 ODrives can be on a single CAN bus!

As a result, CAN is extremely robust and reliable, and much easier to wire: only one cable is needed, which every CAN device connects to. It can even be routed next to power cables with no issues.

Typically, CAN devices can run up to 1 Mbit/s. However, the ODrive Micro supports a protocol called CAN-FD, which can run at up to 8 Mbit/s. This functionality is currently experimental, but will be supported fully in the future.

CAN on the Micro

To make wiring easier, the ODrive Micro (as well as the ODrive Pro and ODrive S1) has two CAN connectors. Both are 4-position JST-GH (a locking connector, for high reliability!), and plug-and-play with our offered CAN cables.

Internally, these connectors are electrically identical and connected to each other — it’s a pure electrical passthrough, with the ODrive tapping in. This allows for ultra-easy daisy chaining — in the below picture, all three of the ODrive Micros are on the same CAN bus!

Now, the astute observer may notice there are four wires on the CAN bus, when before we said it only needs CANH and CANL. So what’s up with that?

Along with CANH and CANL are two optional lines, designed for carrying power and ground. By default, these aren’t internally connected on the Micro — however two solder pads on the bottom allow for connecting these to the Micro’s power input. This way, for very low power systems (under 1-2 amps total), both the power and communication can be carried over a single cable!

Talking CAN

I’m going to be honest, I used to think CAN was scary and complex. And I wouldn’t fault you for feeling the same way. It’s a new, unfamiliar protocol for many, and most of the CAN devices out there aren’t made with ease of use in mind. However, we’ve put a lot of work into making CAN as accessible as possible to get started with. So let’s talk about how to actually use it.

From a Computer

Quite possibly the most common use case is to control an ODrive over CAN from a Linux, Windows, or Mac OS computer. For this, we have the ODrive USB-CAN adapter. It’s a compact, high-performance adapter that lets any computer talk CAN. You can use it from Python on Windows and Mac OS, but it’s especially easy on Linux, where it shows up as a network device, just like Ethernet or Wifi!

From here, you can use a whole suite of Linux tools to communicate with the CAN bus, and just about any programming language you’d like — from Python to C/C++ to Rust, or literally any other language with networking support.

From ODrivetool and the GUI

Also, we’re currently working to develop support for using both the GUI and ODrivetool over a CAN bus, you can throw those USB cables away! This will be available by the time our Crowd Supply campaign is complete, so if you pick up a USB-CAN adapter and a CAN cable, you won’t even need to think about USB.

From an Embedded Computer

Another common case is uses an embedded Linux computer, such as a Raspberry Pi or NVIDIA Jetson. While you can still use a USB-CAN adapter with these computers, you may be tempted to ditch USB entirely and avoid all of the aforementioned issues that comes with USB. Luckily, these embedded computers tend to have a high-speed SPI bus which can communicate with this CAN to SPI adapter for the Raspberry Pi, or this adapter for the Jetson Nano . In fact, that’s what we used on our Botwheel Explorer. With a bit of setup, these will also show up as native CAN devices in Linux, just like the CAN-USB adapter.

From an Arduino

Plenty of Arduino-compatible devices exist, and they’re definitely one of the easiest ways to get started with embedded development. Whether it’s an Arduino Uno, Mega, or something else, SPI-CAN adapters work just as well. And microcontrollers with built-in CAN peripherals, like the Teensy and Uno R4, just need a simple CAN transceiver. Plus, with the ODriveArduino library, CAN communication is a breeze!

From something else

Got an STM32? ESP32? A strange, esoteric 16-bit microcontroller you found behind a dumpster? No worries! Our CAN protocol is well documented, with plenty of examples. CAN feels scary at first, but once you get the first few packets flying, everything falls into place nicely.

Next Steps

I hope this overview has given you some insight into the power the CAN bus can bring to your next project! Feeling inspired? Check out our campaign page to learn more about the ODrive Micro and order yours today! Just remember to get a USB-CAN adapter as well. 😉

For more information, check out our CAN guide, CAN protocol definition, and Arduino CAN guide.

Got questions? Reach out to us on email, Discord, or our forums.