Communication, Drones, Robots

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 480Mbit/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 Moderate
Ethernet 1000BASE Good Good 1Gbit/s Ok Ok Large Moderate
Ethernet 10GE Good Good 10Gbit/s Hard Hard Huge High
CAN-FD Depends on design Excellent 8 Mbit/s Easy Ok Depends on design Low
RS485/422 Depends on design Excellent 10 Mbit/s Easy Good Depends on design Low
RF Good Poor 54 Mbit/s Hard Good Small (no physical) Moderate

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 256Bytes 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 KBytes 6KB/s or 48Kbits/s
HD 1080P camera (like this) 30Hz ~512KBytes (compressed) 30.72MB/s or 245Mbits/s
640 x 480 camera 60Hz ~80KBytes 4.8MB/s or 39Mbits/s

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

Robot Network 1

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 - Another robot network

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.

This flowchart illustrates a simplified process for selecting the right communication bus for your robot or drone.

A simplified decision process for selecting a 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.
Get updated with our new products


Join our email list to get updated of our new product releases.

Contact us by e-mail

3 thoughts on “What’s The Best Communication Bus for Robots and Drones?

  1. Stephan says:

    Excellent write up. We use your SwitchBlox because it is tiny, and it works straight out of the box. SwitchBlox’s tiny size, and low power demand, means even our small drones can have the benefit of five port Ethernet switch as a bus.

    1. Josh Elijah Josh Elijah says:

      Thanks Stephan, glad you liked it.

  2. John Munro says:

    Agreed, great writeup Josh!

Leave a Reply

Your email address will not be published. Required fields are marked *