Communication Protocols for Robotic Systems

Communication protocols define the rules, data formats, timing mechanisms, and error-handling procedures that govern how robotic subsystems exchange information. This page maps the primary protocol categories used across robotic architectures — from fieldbus standards in industrial automation to middleware layers in research platforms — and defines the classification boundaries, operational scenarios, and selection criteria relevant to professionals specifying or evaluating robotic communication infrastructure.

Definition and scope

A communication protocol in the context of robotic systems is a formally defined set of rules specifying how data is structured, transmitted, acknowledged, and interpreted between two or more nodes — whether those nodes are sensors, actuators, controllers, edge processors, or cloud services. Protocol selection directly affects latency, determinism, bandwidth, interoperability, and fault tolerance across the full robotic software stack.

The scope spans four architectural layers: physical media (wired Ethernet, CAN bus, serial), transport (TCP/IP, UDP, DDS), middleware (ROS 2 DDS, MQTT, OPC UA), and application-layer messaging (ROS topics, services, actions). Standards bodies governing this space include the IEEE (for Ethernet and wireless standards), the International Electrotechnical Commission (IEC) for fieldbus and industrial network standards, and the Object Management Group (OMG) for the Data Distribution Service (DDS) specification that underpins ROS (Robot Operating System) architecture.

IEC 61158 consolidates 23 distinct fieldbus protocol types under a single international standard, reflecting the historical fragmentation of industrial communication before Ethernet-based systems achieved sufficient determinism for real-time control.

How it works

Robotic communication protocols operate across a layered stack modeled on the ISO/OSI reference model but adapted for determinism and real-time constraints. The following breakdown describes the primary functional layers:

  1. Physical and data link layer — Defines electrical signaling, cable specifications, and frame structure. CAN bus, RS-485, and EtherCAT operate here. EtherCAT, standardized under IEC 61158 Type 12, achieves cycle times below 100 microseconds by processing Ethernet frames on-the-fly at each node rather than requiring full frame reception before forwarding.

  2. Transport layer — Determines reliability, ordering, and flow control. TCP guarantees ordered delivery but introduces latency unsuitable for closed-loop control. UDP is preferred for time-sensitive sensor streams where occasional packet loss is tolerable. DDS (OMG standard formal/2015-04-10) uses a publish-subscribe model over UDP with configurable Quality of Service (QoS) policies including deadline, liveliness, and reliability contracts.

  3. Middleware layer — Abstracts hardware from application logic. ROS 2 uses DDS as its underlying transport, replacing the centralized ROS master of ROS 1 with a fully distributed discovery mechanism. OPC UA (IEC 62541), developed by the OPC Foundation, provides a platform-neutral, service-oriented architecture suited to industrial robotics architecture environments requiring semantic data modeling alongside transport.

  4. Application layer — Defines message types, service calls, and action primitives. In ROS 2, topics carry streaming data (sensor readings, joint states), services handle synchronous request-response interactions, and actions manage long-running tasks with feedback (motion planning execution).

Timing guarantees depend on whether the underlying infrastructure is real-time. Real-time control systems require deterministic scheduling enforced at both the OS level (PREEMPT-RT Linux, QNX) and the network level (Time-Sensitive Networking extensions under IEEE 802.1Q).

Common scenarios

Industrial manufacturing floor: Servo drives communicate over EtherCAT or PROFINET (IEC 61158 Type 10, governed by PROFIBUS & PROFINET International) with cycle times of 1–4 milliseconds. PLCs exchange state data with supervisory SCADA systems over OPC UA. This two-tier topology isolates motion-critical traffic from IT network congestion.

Autonomous mobile robots (AMRs): Onboard LiDAR, IMU, and camera feeds route over internal ROS 2 topics. The sensor fusion architecture pipeline consumes these streams at update rates of 10–200 Hz depending on sensor type. Wireless uplink to fleet management systems typically uses WiFi 6 (IEEE 802.11ax) or 5G cellular, with MQTT serving as a lightweight publish-subscribe protocol for telemetry over bandwidth-constrained links.

Multi-robot coordination: In multi-robot system architecture, inter-robot messaging requires protocols tolerant of intermittent connectivity and variable network topology. DDS with RTPS (Real-Time Publish-Subscribe Protocol, OMG standard) supports peer-to-peer discovery without central brokers, making it suitable for dynamic swarm configurations.

Cloud-connected platforms: Cloud robotics architecture deployments relay non-latency-sensitive data — maps, model updates, logs — over HTTPS or AMQP. Latency-sensitive control remains local, partitioned by the edge computing layer.

Decision boundaries

Protocol selection is determined by four intersecting constraints:

Latency vs. reliability: EtherCAT and PROFINET prioritize determinism (sub-millisecond jitter) at the cost of requiring dedicated network infrastructure. TCP/IP-based protocols such as OPC UA tolerate higher latency in exchange for universal compatibility with IT infrastructure.

Topology: Centralized broker models (MQTT with a broker, ROS 1 with a master) introduce a single point of failure unacceptable in safety-rated systems. Decentralized models (DDS/RTPS, EtherCAT ring topology) distribute discovery and state management. Robot safety architecture requirements under IEC 61508 functional safety standards may mandate redundant communication paths.

Bandwidth: High-resolution point cloud data from 3D LiDAR sensors can exceed 100 Mbps per sensor. Protocols and physical media must be sized to handle peak throughput without dropping safety-critical packets. Middleware selection for perception-heavy platforms must account for serialization overhead — ROS 2 CDR serialization benchmarks show significant per-message overhead relative to raw binary formats at message rates above 10,000 Hz.

Interoperability and standards compliance: Facilities integrating equipment from multiple vendors require protocols with open specifications and certification programs. OPC UA's UA4OPC certification, administered by the OPC Foundation, and PROFINET's conformance class certification (CC-A through CC-C) provide documented interoperability assurance absent from proprietary fieldbus implementations.

The full landscape of robotics architecture decisions — of which protocol selection is one component — is indexed at the Robotics Architecture Authority, which covers frameworks from perception through actuation.

References

Explore This Site

Services & Options Key Dimensions and Scopes of Technology Services Tools & Calculators Website Performance Impact Calculator FAQ Technology Services: Frequently Asked Questions Overview Technology Services: What It Is and Why It Matters