By Sarah Xiao 
A humanoid robot looks like one machine and behaves like a federation. Head cameras push images to a main computer. Every joint drive expects position or torque commands on a fixed clock. Fingertip sensors upload contact data that nobody can afford to lose. A cloud service may be doing part of the inference. None of these links want the same thing, which is why no serious humanoid runs on a single bus.
The useful conclusion comes before the protocol list: bandwidth is the least interesting number in the selection. Cycle stability, jitter, wiring mass, fault behaviour, safety architecture and the cost of owning a toolchain decide the design. A gigabit link that stalls for 40 ms is worse than a megabit link that never misses a frame.
Four layers, not one network
Engineering teams that argue about protocols are usually arguing across layers without noticing. Split them and most of the argument dissolves.
Board level — chip to sensor or actuator inside one enclosure. SPI, I²C, UART.
Device level — drive to drive, joint controller to joint controller, end effector to arm. EtherCAT, CAN, RS-485.
Controller level — real-time controller, motion controller and the main compute box talking to each other. Industrial Ethernet, sometimes shared memory or PCIe.
System level — robot to operator station, edge server, fleet manager, cloud. Wi-Fi, 5G, ordinary Ethernet.
Each layer has a different definition of “fast”. Board level means nanoseconds to microseconds. Device level means a control period of 100 µs to 1 ms with jitter small enough that the position loop behaves like a linear system. System level means tens of milliseconds is fine and 500 ms is annoying.
The buses that actually appear
| Bus | Layer | Typical cycle and payload | Strength | Where it bites |
|---|---|---|---|---|
| EtherCAT | Device | 100 µs – 1 ms, tens of bytes per slave | Determinism, distributed-clock sync | Configuration effort, tooling cost, single point of failure in a daisy chain |
| CAN / CAN FD | Device | 1 Mbit/s with 8 bytes (classic); 64 bytes and 2–5 Mbit/s data phase (FD) | Robust differential signalling, cheap, mature arbitration | Bus load, priority inversion under congestion |
| RS-485 / Modbus RTU | Device, sensor | 9.6–115.2 kbit/s typical, polled | Long cable runs, huge installed base | Latency scales with node count, no sync |
| Industrial Ethernet (TCP/UDP) | Controller, system | Gigabit, kilobytes per message | Bandwidth, ecosystem, cheap switches | No bounded latency without TSN |
| ROS 2 / DDS | Software | 10 Hz – 1 kHz, structured messages | Modularity, QoS, distributed discovery | Millisecond-class jitter, not a hard real-time loop |
| UART | Board | Up to a few Mbit/s | Simple, point to point | No arbitration, no framing beyond the byte |
| SPI | Board | Tens of Mbit/s | Speed, timing control | Centimetres, not metres |
| I²C | Board | 100 kHz – 3.4 MHz | Two wires, many devices | Bus capacitance, clock stretching, weak in EMI |
| Wi-Fi | System | 10–100 Mbit/s, jitter in tens of ms | No cable, easy deployment | Roaming handoff, congestion, unpredictable loss |
| 5G / private 5G | System | 10–100 Mbit/s, 10–50 ms realistic | Coverage, mobility, remote operation | Coverage holes, uplink asymmetry, cost per node |
EtherCAT: determinism you buy with configuration
EtherCAT carries standard Ethernet frames that each slave reads and forwards on the fly, so a full cycle touches every node inside a single frame traversal instead of a store-and-forward hop per node. Per-node forwarding delay is on the order of a microsecond or less, which is why a 1 ms cycle covering dozens of axes is routine and 100 µs cycles are achievable with care.
The part that matters more than the raw cycle time is the distributed clock. Slaves synchronise their local clocks to a reference, so the jitter between axes collapses to a small fraction of a microsecond even though the frames themselves arrive with propagation delays. For a position loop, jitter is the enemy: a control loop designed at 1 kHz with 200 µs of jitter behaves nothing like the same loop at 1 kHz with 2 µs of jitter.
Two things EtherCAT does not do, and teams keep assuming it does. It does not make the machine safe — emergency stop, safety-limited speed and safe torque off belong to a separate safety architecture, whether that is FSoE on the same wire or a hardwired circuit. And it does not remove the wiring problem: a daisy chain is one connector away from losing everything downstream, which is why serious machines either split the chain into segments or close it into a ring with redundancy.
CAN and CAN FD: cheap, robust, and quietly congested
CAN is differential, multi-master, and self-arbitrating. Every node hears every frame, lower ID wins arbitration without destroying the frame, and the error counters make a broken node remove itself instead of jamming the bus. That combination is why it has survived four decades in vehicles and why it still shows up in humanoid joints, battery management and end effectors.
Classic CAN carries 8 data bytes at up to 1 Mbit/s. CAN FD keeps the arbitration phase at classic rates and raises the data phase to 64 bytes at 2–8 Mbit/s, which changes what the bus can carry.
The arithmetic is worth doing before committing. A classic CAN frame with 8 data bytes is roughly 110–130 bits on the wire once stuffing is counted, so at 1 Mbit/s the bus tops out near 8,000 frames per second. Twenty joints each requesting a command frame and reporting a status frame at 1 kHz is 40,000 frames per second. That is five times over the theoretical ceiling, before any diagnostics, before any sensor traffic, and before the usual recommendation to keep sustained load under roughly half of capacity so that arbitration stays predictable. Twenty joints at 1 kHz is not a CAN problem you tune — it is a CAN problem you redesign.
CAN FD moves the ceiling by carrying more per frame, not by sending more frames. Where a classic design needs three frames to describe one joint state, FD needs one. Use it that way and the bus load drops; use it as “faster CAN” with the same frame count and you will discover that the arbitration phase still runs at classic rates.
RS-485 and Modbus RTU: two different layers wearing one name
RS-485 is an electrical standard: differential pair, multidrop, common-mode range wide enough to survive an industrial floor. Modbus RTU is a protocol that happens to run on it. Confusing the two leads to conversations where one engineer means “the transceiver” and the other means “the polling model”, and neither notices.
The polling model is the part that hurts at scale. One master asks, one slave answers, and the round trip is serialised. Add nodes or add registers and latency grows linearly, which is fine for a temperature sensor and unacceptable for a joint loop. Termination resistors at both ends, bias resistors somewhere, a common ground reference and firmware that releases the driver promptly — skip any of them and the failures look like random protocol errors that survive every software change.
Ethernet: TCP, UDP, and the difference between speed and determinism
TCP gives ordered, reliable delivery, which is exactly what you want for configuration, logs, model files and task dispatch. It also retransmits, which means a single dropped segment can stall a stream for hundreds of milliseconds while the sender waits for the retransmission timer. For a video stream that is a visible stutter. For a control loop it is a missed deadline.
UDP gives up retransmission and lets the application decide what to do about loss, which is why camera streams, point clouds and status broadcasts use it. Neither protocol provides bounded latency, and neither becomes real-time because the link is 1 Gbit/s or 10 Gbit/s.
If a hard real-time requirement genuinely has to cross Ethernet, the answer is time-sensitive networking: time-aware scheduling on the switches, a common time base via gPTP, and frame preemption for the urgent traffic. That is a switch, NIC and controller decision, not a software setting, and it is worth checking that every device in the path actually supports it before writing the architecture document.
ROS 2 and DDS: the software bus, not the wire
ROS 2 is a framework, not a cable. Underneath it uses DDS, which gives you publish/subscribe, services, actions and a quality-of-service model that is the most underused feature in robotics. QoS lets one topic be best-effort with a shallow history because it carries a 30 Hz camera feed that is worthless if late, while another is reliable with a deep history because it carries calibration parameters that must arrive.
The honest limitation: DDS on a normal Linux system with a normal scheduler produces millisecond-class jitter, sometimes worse under load, and discovery traffic can spike when nodes join. That is fine for perception, planning, navigation and task coordination. It is not fine for the innermost loop. The architecture that works in practice keeps the servo loop on EtherCAT or CAN and lets ROS 2 handle everything above it, with an explicit, monitored boundary between the two.
Wi-Fi and 5G: convenience, never the safety chain
Wi-Fi is the right answer for commissioning, teleoperation, video backhaul and software updates. It is the wrong answer for anything whose failure must be detected in milliseconds, because roaming between access points alone can cost a hundred milliseconds or more, and channel conditions change without warning.
Private 5G widens the coverage and improves mobility, and it makes fleet management, remote assistance and cloud inference practical on a factory floor. It does not change the safety argument. The emergency stop, the joint limit and the protective stop stay local, on a wire, and the robot needs a defined degraded behaviour for the moment the wireless link disappears — hold position, retract, or stop safely. “Wait for the network to come back” is not a behaviour.
Four questions before choosing anything
What is the cycle and what is the jitter budget? Not the average rate. A 1 kHz loop with 20% jitter is a different control problem from a 1 kHz loop with 1% jitter, and the second one is what the tuning procedure assumed.
How many bytes per cycle, across how many nodes? Multiply it out. Bandwidth failures in robotics are almost always arithmetic failures that nobody did.
What is the failure mode, and who notices? Unplugged cable, dropped frame, duplicated command, node power loss, bus congestion. Each needs a detector (timeout, heartbeat, sequence number, error counter) and a response. Protocols do not provide the response; the architecture does.
What does it cost to own? Toolchain licences, analysers, trained people, supply chain, and whether the team can debug it at 2 a.m. on a customer site. A marginally better protocol that nobody on the team can diagnose is a worse protocol.
A stack that ships
| Function | Usual choice | Negotiable? |
|---|---|---|
| Joint servo loop | EtherCAT, 1 ms or faster | Yes, if the joint count and rate fit CAN FD |
| Battery and power management | CAN / CAN FD | Yes |
| Board-level sensors | SPI, I²C, UART | No, these are chip-level constraints |
| Cameras and point clouds | Gigabit Ethernet or USB 3 | Yes |
| Perception, planning, task logic | ROS 2 / DDS | Yes |
| Teleoperation and logs | Wi-Fi, Ethernet, 5G | Yes |
| Safety chain | Hardwired or FSoE, independent of everything above | No |
Write the data contract before the bus diagram
The most reliable teams do the dull thing first: they list every signal and fill in six columns — what it is, how often it must arrive, how many bytes it is, how late it may be, what happens if it is lost, and what safety class it belongs to. Only then does the bus diagram get drawn.
That table exposes the argument that was hidden. The tactile stream that looked like a nice-to-have turns out to have a 5 ms deadline because it feeds a grip reflex. The diagnostics channel that everyone assumed needed real-time priority turns out to be fine at 10 Hz. The vision stream that somebody wanted on the control bus turns out to be 400 Mbit/s of data that no fieldbus will ever carry.
The boundary is the design
No humanoid robot runs on the best protocol. It runs on a set of boundaries that are written down, monitored and tested: this layer is deterministic and that one is not, this failure is detected here and handled there, this link is allowed to disappear and that one is not.
The systems that stay up are rarely the ones with the most sophisticated communication stack. They are the ones where the boundaries are defined most clearly and the fault handling is done most thoroughly — which is a design decision, not a purchase order.
FAQ
Can EtherCAT be used for safety functions?
Not by itself. EtherCAT is a communication and synchronisation technology. Safety functions such as safe torque off, safely limited speed and safe stop require a safety-rated layer — FSoE over the same physical network, or a separate hardwired safety circuit — plus a safety controller and a validated architecture.
Is CAN FD enough for a humanoid with twenty or more joints?
It can be, at reduced rates or with fewer frames per joint. Classic CAN at 1 kHz for twenty joints exceeds the theoretical frame rate by a wide margin. CAN FD helps by carrying more data per frame, but the arbitration phase still runs at classic bit rates, so the gain comes from fewer and larger frames rather than from raw speed.
Why not put everything on ROS 2 and skip the fieldbus?
Because the servo loop needs bounded jitter in the microsecond range and a general-purpose OS with DDS typically delivers millisecond-class jitter. ROS 2 is excellent for perception, planning and coordination; the innermost loop belongs on a bus with hardware timing.
Is 5G fast enough for teleoperation?
For video and supervisory control, usually yes. For bilateral force feedback or anything in the safety chain, no — the latency and jitter are not bounded, coverage is not guaranteed, and the link can vanish. Teleoperation over 5G should always assume the link will drop and define what the robot does when it does.