Engineering resource
Robot Communication Bus Selection Worksheet
Compare CAN, UART, I2C and SPI by system boundary, failure behavior and validation evidence. Download the matrix and calculate a UART traffic budget.
Choosing a robot communication link starts with the route, the traffic and the consequence of a missing message. Peak interface speed alone cannot establish whether a measurement arrives fresh enough or whether a failed device blocks other nodes.
Use this worksheet beside the CAN / UART / I2C / SPI comparison. The matrix helps shortlist an interface; the decision record captures what must be verified on the actual hardware. The values calculated below are analytical examples, not measurements from a robot.
Start with the system boundary
| Decision | CAN | UART | I2C | SPI |
|---|---|---|---|---|
| Typical fit | A distributed network of compatible controllers and transceivers. | A simple asynchronous stream between endpoints. | Multiple addressed peripheral ICs on a local interconnect. | Clocked exchanges with local sensors, converters or memory. |
| Electrical interface to specify | CAN controller, transceiver, cable, termination and ground/isolation design. | Logic levels and reference ground; external transceivers if the chosen physical layer needs them. | Open-drain lines, compatible voltages, pull-ups and total bus capacitance. | Signal levels, clock polarity/phase, chip-select timing and routing. |
| Sharing the link | Identifier-based priority arbitration; scheduling still needs analysis. | Commonly point-to-point at logic level; framing does not define a multi-node network. | Target addresses; controller and device capabilities must agree. | Usually a separate chip select per target; check the specific device arrangement. |
| Integrity supplied by the interface | Frame CRC, acknowledgement and fault handling; application freshness still needs a policy. | Framing and optional parity; add message boundaries, integrity and sequence rules as required. | Acknowledgement of transfers; no general payload CRC in basic I2C. | No universal acknowledgement or payload integrity scheme; check device protocol features. |
| Timing evidence to collect | Bus load, arbitration delays, errors and recovery under competing traffic. | Serialization, software queues, framing recovery and lost-message behavior. | Clock stretching, transaction duration and behavior when a line stays low. | Complete transactions including command bytes, chip-select gaps and driver scheduling. |
| A weak selection argument | “CAN is deterministic, so every message meets its deadline.” | “It is serial, so a GPIO cable can run anywhere.” | “Two wires make it suitable for the entire robot harness.” | “The clock rate equals useful application throughput.” |
CAN physical-layer decisions depend on topology, propagation and termination. Use the Texas Instruments CAN physical-layer guide for those constraints. UART describes asynchronous framing; an RS-485 transceiver adds a different electrical layer, which needs its own line, loading and termination design.
For I2C, check the operating mode and electrical limits in NXP UM10204 as well as the device datasheets. For SPI, confirm the target’s mode and timing against its datasheet; Analog Devices’ SPI introduction explains the clock and chip-select relationships.
Worked example: UART traffic is larger than the payload
Consider an illustrative stream carrying 32 application bytes and 8 protocol bytes per message, 100 times per second, over a 115200-baud UART configured for 8N1. Each byte takes 10 line bits: one start bit, eight data bits and one stop bit.
That is 40 × 10 × 100 = 40000 bit/s, or about 34.7% of the line capacity in one direction. A message alone takes about 3.47 ms to serialize. Neither figure includes queueing, inter-message gaps, retries or processing. A request/response cycle also needs the response and turnaround time.
Try your own UART 8N1 budget
One direction, one message type, no gaps or retries. Add all framing and integrity bytes to protocol overhead.
A utilization below 100% only passes this arithmetic check. It does not establish a deadline, a safe reserve or acceptable burst behavior. At or above 100%, the specified sustained stream leaves no capacity for additional costs; above 100%, it cannot fit at the chosen baud rate.
Record the evidence behind the choice
Use the downloadable decision record to capture:
- Route and hardware: endpoints, cable route, voltage levels, transceivers, grounding and termination.
- Traffic: payload, framing overhead, update rate, bursts, other nodes and request/response behavior.
- Timing: acquisition meaning, maximum permitted age, queueing and end-to-end measurements.
- Failure response: detection of stale or corrupt messages, disconnect behavior, reset and re-entry rules.
- Verification: configuration, test method, observed result, acceptance limit and owner of each unresolved assumption.
For a mobile robot, a useful test combines concurrent traffic with motor activity and device restart. Record both the communication outcome and how the receiving controller handles missing or old information. A link that reconnects successfully can still deliver a command that should have expired.
Continue with the sensor-to-actuator timing budget, ROS 2 clock domains and command validation layer to connect interface evidence to the rest of the architecture.
Explore the wider reading paths in Robotics Architecture & Safety and Jetson & ROS 2 Engineering.