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
A safety state may require reliable delivery while a high rate camera stream can prefer fresh frames over retransmitting old ones. ROS 2 exposes policies for reliability deadline lifespan and liveliness that illustrate this tradeoff. The correct setting depends on what the receiving process does with late data.
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.
Conclusion
Latency is not one number for the whole robot. A sound architecture assigns each message a timing budget and keeps safety critical stabilization local enough to survive network problems.
Sources and methodology
This guide separates published standards and official technical documents from engineering practice. Draft standards are described as work in progress. Product capability is not treated as verified unless a source supports it.
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.