Guide
Teleoperation latency: how much delay each robot task tolerates
Latency decides which tasks can be done remotely and how. Measure it properly and design around it.

Updated
Every remote operation has a delay between the robot's camera capturing a frame and the operator's command moving the robot. Short, steady delay feels natural. Long or jumpy delay makes operators slow, cautious and error-prone. The tolerance depends on the task, so the first question is not how fast your network is but what the operator is doing.
Rules of thumb by task
These are practical rules of thumb, not hard limits. Operator skill, the interface and on-robot assistance all shift them.
Direct manipulation
Mobile robot driving
Supervisory control and remote assistance
Drones and vehicles
Measure glass-to-glass, not ping
Network ping covers only part of the delay. What the operator feels is glass-to-glass latency: camera capture, encoding, network, decoding and display, plus the return path for the command and the robot’s controller.
A simple test
Jitter matters as much as the average
Measure where the robot works
Where the delay comes from
Capture and encoding
Network
Decoding and display
Command path
Measure each stage once and you usually find one or two that dominate. Fixing the biggest contributor is cheaper than shaving milliseconds everywhere.
Plan bandwidth for every camera
Each camera stream needs upstream bandwidth from the robot, and the upstream link is usually the bottleneck. A humanoid with head and wrist cameras, or a vehicle with eight, adds up fast. Prioritize the streams the operator needs for the current task, lower resolution on the rest, and make sure control traffic always gets through ahead of video.
Choosing the network at the robot
Wired Ethernet
Managed Wi-Fi
Cellular
Whatever the link, decide in advance what the robot does when it degrades: slow down, hold position, or finish the current motion and stop. That behavior belongs in the robot, not in the operator’s reflexes.
Ways to work around delay
Predictive displays
Shared autonomy
Local safety controllers
Move-and-wait
Show latency on screen
RoboPilots shows the live latency on the pilot's screen, and pilots are trained to switch technique when it rises. For vehicles, cameras, lidar and CAN signals reach the pilot with latency displayed alongside.
Frequently asked questions
- What latency is acceptable for robot teleoperation?
- As a rule of thumb, direct manipulation feels best under about 100 to 150 ms round trip and gets hard above about 300 ms. Supervisory work tolerates delays of seconds.
- How do I measure teleoperation latency?
- Measure glass-to-glass: film a millisecond clock with the robot camera and compare it with the clock shown on the operator screen. Track jitter as well as the average.
- Can robots be teleoperated across continents?
- For supervisory control and remote assistance, yes. For fast, continuous manipulation, distance adds delay, so shared autonomy or a nearer operator region helps.
- Is jitter worse than high latency?
- Often, yes. Operators adapt to a steady delay; unpredictable swings are what cause overshoot and errors.
- Does 5G solve teleoperation latency?
- It can lower delay and raise upstream bandwidth where coverage is good, but real-world performance varies by location and load. Test on the routes and sites your robots actually use, and keep a local safety layer regardless.