Posted by Josh Elijah on 5th Jul 2021

What’s The Best Communication Bus for Robots and Drones?


So you’re designing a robot or drone, awesome. You’ve got your motors, some cameras and sensors, and an embedded computer to make it do things. Pretty early on you’re going to have to figure out how to connect it all together.

In other words you’re going to need to pick a physical communication bus to transfer data between everything inside the robot. This is not an easy choice but it’s a really important one. There’s many options and you’ll want to get this right to make your system architecture able to handle expected data rates, be robust, and scalable for the future.

So what are the options, and how do you pick the right one? There is no one-size-fits-all answer. Are you using cameras distributed across the robot? You’ll need a fast data rate then. Is your robot going to be deployed in challenging environments? Robustness will be key. In this article we’ll look at some of the key criteria and evaluate some of the best options available right now and answer the question, what is the best communication bus for robots and drones?

What Makes a Good Communication Bus?

We’re talking about robots and drones here, and that usually means we care about the following criteria…

  • Physical Robustness – Are the cables and connectors physically robust to strain and abrasion?
  • Noise Immunity – Big spinning motors can be a nightmare for introducing noise into our circuits.
  • Data Rate – Sensors like cameras require higher data rates.
  • Ease of Design – Does the hardware you will use support this communication bus natively? If not, how easy is it for you to add it?
  • Open Software – You don’t want to be writing low level drivers from scratch!
  • Size – Usually a huge consideration for mobile robots. Tight spaces call for compact connectors and cables.
  • Cost – This depends on your budget. Higher data rates usually means higher cost.

Communication Bus Options

There’s 100s of communication buses so let’s restrict our view to the most widely used; This is preferable because it is generally means more available hardware and software support.

  • Embedded buses, SPI, I2C
  • USB 2.0
  • USB 3.0 (and onwards)
  • Ethernet 10BASE/100BASE
  • Ethernet 1000BASE
  • Ethernet 10G
  • CAN-FD
  • RS485/422
  • RF (Wi-Fi/Bluetooth)

Communication Buses | Evaluating The Options

Now let’s evaluate each bus according to our selected criteria.

Bus Physical Robustness Noise immunity Max Data Rate Ease of Design  Open Software Size Cost
I2C/SPI Depends on design Poor 20Mbit/s Easy Good Depends on design Low
USB 2.0 Good  Good  480Mbits/s Ok Ok Small Moderate
USB 3.0 and onwards Ok Ok  10Gbit/s Hard  Hard Moderate High
Ethernet 10BASE/100BASE Good Good 100Mbit/s Ok Ok Large


Ethernet 1000BASE Good Good 1Gbit/s Ok Ok Large


Ethernet 10G Good Good 10Gbit/s Hard Hard Huge


CAN-FD Depends on design  Excellent 8Mbit/s Easy Ok  Depends on design


RS485/422 Depends on design Excellent 10Mbit/s Easy Good Depends on design


RF Good Poor  54Mbit/s Hard Good Small (no physical)


Some Case Studies 

Let’s go through a two examples. Below is a table of typical data rates required by common robotics components. This will help us figure what kind of data rate our bus will need.

Device Update rate Packet size Data rate estimation
High-Speed Motor Controller 500Hz 16 Bytes

8KB/s or 64Kbit/s

Main Embedded Computer for Control and Monitoring 10Hz 265 Bytes

2.56KB/s or 20.48KBit/s

Low-level MCU with sensors 10Hz 32 Bytes

0.32KB/s or 2.6Kbit/s

Small OLED display 60Hz  1 Kbyte

64KB/s or 48 KBit/s

HD 1080P camera (like this) 30Hz ~512KBytes (compressed)

30.72MB/s or 245 Mbit/s

640 x 480 camera 60Hz ~80KBytes

4.8MB/s or 39Mbit/s

Example 1 – A typical high precision rover with 1 HD camera and 4 480p cameras


Example 1 – A robot network

Let’s say our robot consists of…

  • 4 x High Speed Motor Controllers: 4 x 64 Kbits/s = 0.256Mbits/s
  • 1 x Main Embedded computer for control and monitoring: 20.48Kbits/s = 0.02048Mbits/s
  • 10 x Low level MCUs with sensors: 10 x 2.6Kbits/s = 0.026Mbits/s
  • 1 x Small OLED Display: 48Kbits/s = 0.048Mbits/s
  • 1 x HD 1080p camera: 245Mbits/s 
  • 4 x 640 x 480 cameras: 4 x 39Mbits/s = 156Mbits/s

Maximum theoretical data rate required: 0.256Mbits/s + 0.2048Mbits + 0.026Mbits/s + 0.048Mbits/s + 245Mbits/s + 156Mbits/s =

402 Mbits/s

Our only options are…

  • USB 2.0 – Not a bad choice with decent noise immunity and widespread usage. The max data rate of USB 2.0 is 480Mbit/s though, so we don’t have a lot of headroom to add more components in the future. Also, all our boards will need to have hub circuitry, which is a bit painful.
  • USB 3.0 – A solid choice if we can compromise a bit on noise immunity. But again, it means all our boards need to have hub circuitry.
  • Ethernet 1000BASE – This is probably the best solution in this case. It’s robust, fast and reasonably easy to design with. We would need to use Ethernet switches to tie the system together though, and the typical connectors RJ-45 can be bulky which is not ideal. It’s also not the cheapest option, but we may not be able to avoid that.
  • Ethernet 10GE – Certainly the best data rate, but we’ll see a massive increase in cost and the size of the connectors. This is probably overkill for this application.

So Ethernet 1000BASE is probably the way to go for this robot. However, let’s look at the system and see if we can make some optimisations to reduce requirements on the communication bus.

Example 2 – A typical high precision rover with 1 HD camera and 4 480p cameras, optimised

In the previous example, we can see that 401Mbit/s of the required 402Mbit/s was taken up just by the cameras! Let’s see if we can fix that. We’ll move the HD camera to have a dedicated connection to the embedded computer, and use another 4 embedded computers (like Raspberry Pis) to interface with each 480p camera. This way the embedded computer and raspberry pis can gather the raw image data directly, and instead send high level control signals on the bus, rather than the bus being clogged up with image data.

Example 2 – A robot network, cameras no longer sitting on the bus.

  • 4 x High Speed Motor Controllers: 4 x 64 Kbits/s = 0.256Mbits/s
  • 1 x Main Embedded computer for control and monitoring: 20.48Kbits/s = 0.02048Mbits/s
  • 4 x Raspberry Pi (or equivalent low power computer) = 4 x 20.48Kbits/s = 0.02048Mbits/s
  • 10 x Low level MCUs with sensors: 10 x 2.6Kbits/s = 0.026Mbits/s
  • 1 x Small OLED Display: 48Kbits/s = 0.048Mbits/s

Maximum theoretical data rate required: 0.256Mbits/s + 0.2048Mbits + 0.2048Mbits + 0.026Mbits/s + 0.048Mbits/s  =


Quite a saving!

  • I2C/SPI/UART – It could work, but since we have four spinning motors in our robot, we are likely to have noise problems. Not ideal.
  • USB 2.0/USB3.0 – Both could certainly work, but the issue of needing hubs everywhere (even it we design our own) is going to be costly and adds unnecessary design complexity.
  • Ethernet 10BASE/100BASE – An excellent choice. Robust and easy to use and you’ll find that nearly all embedded computers will support ethernet (the same cannot be said for some of the other buses). However we’ll need ethernet switches to tie everything together, and they tend to be quite large. (We solved this problem here ;))
  • Ethernet 1000BASE/Ethernet 10GE – It would work but it’s going to be costly. This is probably overkill for this system.
  • CAN-FD – Also an excellent choice. It’s fast, very robust and requires no complicated switch circuitry. However you’ll find that not all embedded computers support this natively. That means you’ll either need to be picky about your hardware, or design your own transceivers and drivers. That being said, more and more embedded computers aimed at robotics are starting to support CAN-FD.
  • RS485/422 – Excellent. Widely used in industry and easy to interface with (most embedded computers can use a native serial port with an RS485/422 transceiver to use this). You’ll find a wide range of communication protocols use RS485/422 as the low level bus.
  • RF – You might find the idea or using Radio Frequency (RF) to connect all components in a robot a little weird, but its entirely possible. An implementation might be for the robot to have a small Wi-Fi LAN onto which all components connect. This means no wires! However now all components need a Wi-Fi transceiver and the motors may also cause noise issues. In addition if we have to enclose parts of the robot in metal, then we’ll see attenuation of the signal or it might not work at all. So it’s probably not the best choice for this.

So which one is best? The choice is not straightforward. For scalability, Ethernet 10BASE/100BASE is the way to go because it gives us up to 100Mbits/s. However if this is unlikely to be needed, RS485 or CAN-FD would be the best choices.


So what’s the best communication bus for robots and drones? Well there’s no simple answer, it’s up to your specific needs and what compromises you can make. You can see in the above examples that there’s a balance between data rate, robustness and ease of integration that end up informing our decision. That being said, here’s a flowchart that illustrates a rough decision process we like to follow. It’s by no means exhaustive and in some cases the hardware you use will force you to use a specific communication bus.

Key Takeaways

  • Calculate your maximum data rate, based on your components.
  • Consider restructuring your robot or drone to reduce the maximum data rate if you can.
  • Eliminate the buses that do not provide the data rate you will need.
  • Consider noise immunity based on the robot’s components (mainly motors) and its external operating environment.
  • Choose the bus that will give you the least work for integration. If there are off the shelf hardware options, use them.
  • Test test test. Create a prototype of your system and run data rate and performance tests before you commit to it fully. Once you make the call, it’s difficult to redesign.
  • The most widely used buses in industrial robots are Ethernet 10/100, Ethernet 1000 and CAN-FD.