Communication Protocols for Robotic Systems

Communication protocols define the rules, formats, and sequencing that govern data exchange between robotic components — sensors, actuators, controllers, and external systems. The choice of protocol directly determines achievable latency, bandwidth, fault tolerance, and interoperability across a robotic system's subsystems. This reference covers the major protocol categories used in industrial, mobile, and autonomous robotic platforms, the mechanisms underlying each, the scenarios that drive protocol selection, and the boundaries where one approach must be substituted for another.

Definition and scope

A communication protocol in robotics is a standardized specification that defines how data packets are structured, transmitted, acknowledged, and error-checked across a communication channel between two or more nodes. Protocols operate at distinct layers corresponding to the OSI model defined by the International Organization for Standardization (ISO), spanning physical signal encoding, data link framing, network addressing, transport reliability, and application-level message semantics.

The scope of robotic communication spans three distinct domains:

1. Intra-robot communication — data exchange between internal subsystems such as a microcontroller and motor driver, or a compute board and an IMU sensor.
2. Robot-to-robot communication — peer-to-peer or broadcast data sharing in multi-robot system architectures and swarm platforms.
3. Robot-to-infrastructure communication — links between a robot and external systems including cloud servers, operator consoles, or edge computing nodes.

The IEEE, ISO, and IETF all maintain active standards in this space. ISO 11898 governs the Controller Area Network (CAN) bus, one of the foundational fieldbus protocols in industrial and mobile robotics.

How it works

Protocol operation follows a structured sequence regardless of the specific standard in use:

1. Encoding — The sending node serializes data into a defined binary or structured format (e.g., a CAN frame with an 11-bit or 29-bit identifier, up to 8 bytes of payload, and a cyclic redundancy check field).
2. Arbitration or scheduling — On shared bus topologies, nodes compete for access using priority-based arbitration (CAN) or time-division multiplexing (EtherCAT, PROFINET IRT).
3. Transmission — The encoded frame is passed over the physical medium — twisted pair, Ethernet, serial line, or wireless RF channel.
4. Acknowledgment and error handling — The receiving node validates the CRC or checksum and either acknowledges receipt or flags an error, triggering retransmission where the protocol permits.
5. Deserialization and dispatch — The receiving node unpacks the payload and delivers it to the appropriate application handler.

Middleware layers, such as those described in the middleware in robotics systems reference, sit above this transport mechanism and abstract protocol-specific behavior from application logic. ROS 2 relies on the Data Distribution Service (DDS) specification — standardized by the Object Management Group (OMG) under the DDS-RTPS standard — to handle discovery, QoS policies, and publish-subscribe messaging across nodes. The DDS robotics communication page details how DDS Quality of Service parameters such as reliability, durability, and deadline govern real-time data delivery.

Latency figures vary substantially across protocol classes. EtherCAT, maintained by the EtherCAT Technology Group (ETG) under IEC 61158, achieves cycle times as low as 100 microseconds on a 100-node network, making it suitable for hard real-time servo control. Standard UDP-based ROS 2 transports over Gigabit Ethernet typically operate in the 1–10 millisecond range for intra-host communication.

Common scenarios

Industrial servo control and motion coordination — Fieldbus protocols dominate. EtherCAT and PROFINET IRT are the predominant choices in automated manufacturing cells where 47% of new industrial robot installations (IFR World Robotics 2023) require deterministic cycle synchronization across multiple axes. CAN bus and its higher-speed variant CAN FD (Flexible Data-rate, supporting up to 8 Mbit/s payload phase) handle lower-bandwidth sensor and diagnostic traffic on the same platforms.

Autonomous mobile robots and outdoor vehicles — TCP/IP and UDP over Wi-Fi 6 or 5G cellular handle non-deterministic telemetry and mission commands. For safety-critical signals — emergency stop, geofence breach — a dedicated CAN or hardwired digital line maintains isolation from the variable-latency wireless path. This mirrors the layered approach described under safety architecture in robotics.

Surgical and medical robotics — IEC 62443 and FDA guidance on software in medical devices impose stricter reliability and authentication requirements. UART and SPI remain common for internal sensor buses given their deterministic byte-by-byte transfer and absence of protocol overhead, while encrypted TLS over Ethernet handles external telemetry.

Swarm and multi-robot coordination — IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 (Zigbee/Thread) serve low-power mesh topologies. Gossip protocols and epidemic broadcast trees distribute state without a central broker, aligning with the decentralized approach covered under centralized vs. decentralized robotics.

Decision boundaries

Protocol selection hinges on five ranked criteria:

1. Determinism requirement — Hard real-time control loops with cycle times below 1 millisecond eliminate Ethernet TCP and wireless options; EtherCAT or PROFINET IRT are the viable candidates.
2. Bandwidth envelope — High-resolution point cloud streams from 3D LiDAR (commonly 10–20 Mbit/s per sensor) mandate Gigabit Ethernet or PCIe; CAN and RS-485 are structurally unsuitable.
3. Physical topology — Multi-drop ring topologies favor EtherCAT; star topologies favor standard Ethernet with DDS; linear sensor chains favor RS-485 or CAN.
4. Functional safety classification — Systems under ISO 26262 (automotive), IEC 61508, or ISO functional safety standards for robotics require protocols with defined fail-safe behaviors and error-detection coverage metrics.
5. Power and payload constraints — Embedded microcontrollers on battery-powered platforms, as discussed in embedded systems robotics architecture, favor I²C, SPI, or CAN FD over power-hungry Gigabit Ethernet PHYs.

The intersection of these constraints — not any single factor — determines which protocol is structurally appropriate. The broader architecture landscape for robotic systems is indexed at the Robotics Architecture Authority.