Introduction
Network latency matters because a humanoid mixes slow information such as work orders with fast information such as sensor feedback and operator commands. The same delay can be irrelevant for a dashboard and dangerous for a control loop. Network design should therefore start from the timing needs of each data path.
Key facts
- ROS 2 Quality of Service can set reliability deadline lifespan and liveliness behavior.
- Stale data can be more dangerous than missing data for some control functions.
- Critical low level control should not depend on an unpredictable cloud round trip.
Measure latency and jitter separately
Average latency can look good while occasional long delays break motion. Record end to end distributions including high percentile values and jitter. The test should include the actual wireless load cameras logging and fleet traffic expected in production.
Choose communication policy by message type
ROS 2 Humble treats reliability, deadline and lifespan as separate policies. Reliable delivery may retry samples; it does not establish a measured end-to-end latency or certify a safety function. Lifespan sets when a sample expires. Deadline concerns the expected interval between publications.
A best-effort camera publisher is incompatible with a subscriber requesting reliable delivery. No messages pass between that pair even when the network is working. Check the offered and requested policies before diagnosing a cable or wireless fault. This is a documented compatibility rule, not a test executed on a humanoid.
Teleoperation has a human control loop
Delay affects the operator ability to judge contact and stop motion. Video latency command latency and feedback latency can differ. Systems can limit speed predict motion or move some stabilization onboard so the remote human does not control every joint through a long network path.
Keep fast stabilization onboard
Balance joint control collision limits and emergency behavior should remain close to the robot. Edge or cloud compute can support planning and heavy perception when the design tolerates delay. This separation lets the robot enter a safe state when connectivity disappears.
Test network failure as an operating condition
Disconnect wireless links add packet loss saturate the network and restart infrastructure during validation. Record whether the robot pauses stops safely completes a local action or requests help. A production robot should have defined behavior when its normal network assumptions fail.
Limitations and missing information
- Network limits vary with task and controller architecture.
- Wireless performance changes with site layout and interference.
- Reliable transport can increase latency when packets are retransmitted.
Sources and methodology
Related TechniaHQRobot guides
Share this article
Share the current TechniaHQRobot article page.
Continue reading
Open the latest robotics reporting, Physical AI analysis and hardware notes.