UGV teleoperation latency is the delay between events at a ground vehicle, the operator seeing them, and the vehicle responding to the operator's commands. It affects how much the scene changes before a correction takes effect. Evaluate the camera-to-display path and the command-to-motion path separately, then test them together at the intended speed and task. A network ping alone cannot describe that loop.
There is no single millisecond figure that this evidence establishes as safe for every UGV. A robot approaching a doorway, a manipulator positioning a tool, and a vehicle following an open route present different control problems. The useful specification connects delay, variability, feedback freshness and local failure behavior to a demonstrated operating task.
On This Page
- Where the delay enters
- Translate delay into distance
- Keep interfaces aware of time
- Choose what stays onboard
- Diagnose the failure pattern
- Specify a repeatable demonstration
Where the delay enters
A video-guided UGV has two connected paths. Cameras send observations through capture, encoding, transport, decoding and display. The operator sends commands through an input device, communications software, the network and the vehicle controller to the actuators. Telemetry provides an additional feedback path whose timing may differ from the video.
Glass-to-glass latency measures the visual path from a physical event to its appearance on the operator's display. Motion-to-motion latency measures the interval between a physical control input and the corresponding vehicle actuation. A 2026 University of Luxembourg research preprint measures these separately with physical sensors and synchronized clocks. Its combined machine-path measure excludes human decision time; that time must be added when evaluating a response to an obstacle.
The distinction changes what to request from a supplier. A timestamp taken when a command reaches a computer omits any remaining controller and actuator delay. A displayed timestamp can also mislead if it marks decoding rather than camera exposure. Record precisely what begins and ends each measurement, including clock synchronization uncertainty.
Video buffering deserves its own inspection. GStreamer's RTP jitter-buffer documentation describes waiting for missing packets, reordering arrivals and treating packets that arrive too late as lost. This improves continuity by spending time. Reducing the waiting period can reduce delay while increasing visible disruption when packets arrive unevenly.
For driving, smooth pictures and fresh pictures are separate requirements. Compare both during congestion; a beautifully continuous view of an old scene is still old. Adjust buffer settings against task performance and image disruption, rather than selecting the smallest setting without observation.
Translate delay into distance
The simplest physical consequence is distance traveled while a response is pending. For constant speed, distance equals speed multiplied by time. The following is an illustrative engineering calculation using chosen inputs, not measured UGV performance or a stopping-distance limit.
Distance before braking begins = speed × (visual delay + operator response time + command-to-braking-onset delay).
Assume a vehicle travels at 2 m/s. Choose 0.20 s for visual delay, 0.40 s for operator response, and 0.10 s from issuing the command to braking onset. The combined interval is 0.70 s, so the vehicle travels 1.40 m before braking begins. These inputs are hypothetical, not typical values or recommendations. The camera and actuation boundaries follow the measurement distinction above; the human interval is an additional scenario assumption.
For the same chosen delays, the arithmetic changes with speed:
| Assumed speed | Assumed total interval before braking | Distance traveled in that interval |
|---|---|---|
| 0.5 m/s | 0.70 s | 0.35 m |
| 1 m/s | 0.70 s | 0.70 m |
| 2 m/s | 0.70 s | 1.40 m |
Source basis: editorial constant-speed calculations, checked September 10, 2026. All timing inputs are hypothetical and held fixed to isolate the effect of speed.
Braking distance comes afterward. This calculation excludes deceleration, slope, tire or track slip, payload effects and an obstacle's own motion. If braking onset is already included in an instrumented command-to-motion measurement, do not add that same delay again. For a manipulator, replace vehicle travel with the relevant tool motion and verify the arm's stopping behavior.
This is why asking whether “200 ms is acceptable” leaves the engineering question unfinished. State which delay it describes, the motion occurring during it, and the remaining clearance. The example supports the arithmetic relationship only; it does not authorize a speed near people or obstacles.
Keep interfaces aware of time
Command formats need more than steering and speed values. An integration specification should define units, coordinate frames, timestamp meaning, ordering, validity period and control ownership. It should also distinguish a received command from one that the controller has accepted and physically executed. These are engineering review questions derived from the timing boundaries, rather than a universal messaging standard.
A concrete example is the Jazzy ROS 2 differential-drive controller. It accepts stamped body-velocity commands and converts them into wheel commands. Its documentation describes odometry, motion limits and automatic stopping after command timeout. A project must verify its configured timeout and actual stopping response; a documented software feature is not proof of a complete vehicle safety function.
Middleware offers useful distinctions. The ROS QoS design document separates deadline, the allowed interval between messages; liveliness, whether a publisher remains alive; and lifespan, how long a message remains valid. It also explains that a middleware deadline does not include all application processing. This is a design reference, so verify support and behavior in the deployed software release.
Consequently, an active connection does not establish that the driver sees current video or that a motor has executed a command. Test each condition explicitly. For example, what happens if valid command packets continue arriving while the camera stream freezes? A command watchdog alone does not answer that question.
The broader open-architecture guide explains why exchanging messages is only part of replacing or integrating a component. For teleoperation, preserve the timing contract when changing a camera, decoder, radio or controller.
Choose what stays onboard
Direct teleoperation leaves the human continually correcting motion using remote feedback. Shared control can let the operator express an intended route while an onboard controller handles a faster local task. The tradeoff is additional dependence on vehicle-side sensing, models and control-authority rules.
In Zhang and colleagues' predicted-trajectory research, the vehicle predicts intended motion from delayed historical commands and lidar observations. Human-in-the-loop simulations found benefits under larger delays, while the authors reported no benefit in smaller-delay cases. This supports investigating a particular compensation approach, not claiming that prediction fixes all UGV links or establishes field safety.
A predicted path also needs to be identifiable as a prediction. During evaluation, compare it with the measured vehicle path and test how disagreement is shown to the operator. An apparently immediate overlay must not obscure the age of the underlying camera view. That display requirement is an engineering implication of using model-based compensation.
The division of work should follow the task. For a ground robot positioning a tool, examine fine motion and camera response together; the EOD robot controls explainer describes the relevant arm-and-camera relationship. For route traversal, evaluate whether local guidance can reduce repeated remote steering corrections. For inspection from a stationary position, distinguish delay in obtaining an observation from delay while repositioning the vehicle.
The edge AI guide covers onboard processing and its interfaces. Bringing processing onboard changes the delay budget and failure dependencies; it does not establish that any particular perception model can detect the hazards in the intended environment.
Diagnose the failure pattern
The table below turns the documented measurement, buffering and command-validity distinctions into a troubleshooting sequence. It is engineering synthesis, not a report of tests on a specific vehicle.
| Observed pattern | What to separate next | Demonstration to request |
|---|---|---|
| Video is smooth but corrections consistently arrive late | Visual age, command transport and physical actuation | Record a physical event and input-to-motion response independently |
| Delay grows while streaming continues | Accumulated waiting in the video path versus the command path | Compare buffer occupancy and frame age during sustained load |
| Commands remain active after the view freezes | Camera freshness versus command freshness | Interrupt video independently and observe the configured vehicle response |
| Motion resumes unexpectedly after reconnection | Old commands versus newly authorized commands | Test ordering, expiry and re-enabling control after an interruption |
| Predicted and observed paths diverge | Model output versus actual motion | Show disagreement and the operator's recovery procedure |
Source basis: the measurement preprint, GStreamer buffer documentation, ROS timing and controller documentation, and predicted-trajectory research cited above.
Change one condition at a time to locate the problem, then repeat with combined stresses. A decoder change that improves visual age cannot establish that steering actuation improved. Likewise, successful packet delivery does not demonstrate correct recovery after a freeze. Preserve the traces that connect the observed symptom to the proposed fix.
Specify a repeatable demonstration
NIST's ground response-robot testing program distinguishes standard test methods from a standard robot specification. Its approach uses repeatable apparatus, procedures, metrics and recorded fault conditions. Apply that discipline when defining a teleoperation trial; do not describe a locally devised latency test as ASTM certification.
For a supplier comparison, request the following as a proposed test record:
- Identify vehicle configuration, payload, route, surface, lighting, camera settings and software versions.
- Measure physical visual and command-to-motion delays, with instrumentation boundaries and uncertainty stated.
- Report the distribution and worst observed interruptions, alongside task completion, corrective inputs and failures. A mean alone hides variation.
- Exercise video loss, command loss and reconnection separately in a controlled test area or appropriate simulation, with predetermined stop and recovery procedures.
- Repeat the intended task under representative load, using the same scoring and conditions across configurations.
Keep the measurement record interpretable
For each controlled trial, assign one run identifier to the camera, operator-station and vehicle records. List the clock used for each timestamp and how the clocks were aligned. Mark the physical events being compared, then keep the raw observations beside the calculated intervals. If a boundary cannot be instrumented, name that gap instead of presenting the remaining measurements as a complete end-to-end result. This proposed record follows the measurement preprint's separation of physical events and instrumentation uncertainty.
Add a configuration row for camera mode, buffer settings, command interface and local control mode. When one changes, begin a separately identified trial. Keep a timeline of connection interruptions, camera freezes, operator interventions and recovery actions so the delay trace can be compared with what the vehicle actually did. Record missing samples and unsuccessful runs rather than silently discarding them. Before summarizing repeated trials, check that the event definitions, configuration and task remained comparable. These are suggested documentation practices extending the NIST-style repeatable-test approach, not a claim that a particular logging format certifies safe operation.
These are proposed evaluation requirements, not results or a universal compliance checklist. Agree on task-specific limits before comparing systems, including when the operator must pause and which protective action the vehicle performs locally. Select the configuration that demonstrates adequate control and predictable recovery throughout that task, with the delay measurements available to explain the result.
Sources
- Provost and colleagues, end-to-end latency measurement preprint (2026): physical visual and motion measurement boundaries; prototype research, not a universal latency limit.
- GStreamer RTP jitter-buffer documentation: packet reordering, waiting, loss handling and buffering tradeoffs.
- ROS 2 Control, Jazzy differential-drive controller: body-velocity interfaces, odometry, limits and command-timeout behavior.
- ROS QoS timing design document (2019): deadline, liveliness and lifespan concepts and middleware boundaries.
- Zhang and colleagues, predicted-trajectory guidance preprint (2022): vehicle-side compensation evaluated in human-in-the-loop simulation.
- NIST ground robot tests: repeatable capability testing and the distinction between test methods and equipment specifications.
Last checked: September 10, 2026.
