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.

Teleoperation latency: how much delay each robot task tolerates
Illustration

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

Grasping, folding, inserting. Round trip under roughly 100 to 150 ms feels close to natural. Above about 300 ms, continuous control becomes hard and operators fall back to move-and-wait.

Mobile robot driving

Steering a wheeled or legged robot at walking pace tolerates somewhat more, especially with good local obstacle avoidance on the robot.

Supervisory control and remote assistance

Approving a route, picking a grasp point, confirming an action. Delays of seconds are workable because the robot executes on its own.

Drones and vehicles

Usually run through supervision: the aircraft or vehicle flies or drives itself and the remote person handles exceptions and decisions, not moment-to-moment control.

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

Point a robot camera at a running millisecond clock shown on the operator screen, then photograph both together. The difference is your video latency.

Jitter matters as much as the average

A steady 150 ms is easier to work with than a delay that swings between 60 and 400 ms. Track percentiles, not just the mean.

Measure where the robot works

Warehouse Wi-Fi and home networks behave differently from the lab.

Where the delay comes from

Capture and encoding

Camera exposure, frame buffering and video encoding can add tens of milliseconds before anything reaches the network. Low-latency encoder settings help.

Network

Distance, routing and the last hop, often Wi-Fi or cellular at the robot, which is also the main source of jitter.

Decoding and display

Decoder buffers and display refresh on the operator side. Gaming-grade monitors and minimal buffering shave real time.

Command path

The operator’s input travels back, then the robot’s controller and motors respond. Count this half too.

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

The most predictable option for fixed robots such as arms and machine-tending cells.

Managed Wi-Fi

Fine for mobile robots indoors if coverage is planned for them, with roaming between access points tested along the routes they drive.

Cellular

Required for outdoor and delivery robots. Expect more jitter, test the actual routes, and consider bonding more than one carrier for important fleets.

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

Show where the robot will be once the command lands, overlaid on the delayed video.

Shared autonomy

The operator gives intent, such as which object to grasp, and the robot handles the fine motion locally.

Local safety controllers

Collision limits, force limits and emergency stops run on the robot, so delay never turns into a crash.

Move-and-wait

For long delays, operators move in short steps and wait for confirmation. Slower, but reliable.

Show latency on screen

Operators adapt well when they can see the current delay. Hidden latency is what causes mistakes.

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.