Teleoperating a UGV Over LTE and 5G: The Latency Budget Nobody Publishes

TL;DR: Robot teleoperation latency over LTE often lands in the 180-350 ms glass-to-glass range, while a well-configured 5G SA deployment can reduce it to roughly 60-120 ms in good conditions. There is no universal safe latency limit for manual UGV driving: acceptable delay depends on speed, stopping distance, terrain, visibility, the vehicle’s fail-safe behavior, and the operator’s task. The budget breaks down across five stages: image acquisition, encoding, network transport, decoding, and operator reaction. Below is a reproducible way to measure each stage, representative field values for a Leo Rover-class platform, and a watchdog pattern for graceful degradation when the link drops.

Why robot teleoperation latency over LTE matters

Teleoperating a UGV outside a lab means the radio link becomes part of the control loop. If you drive a Leo Rover across a construction site over a public LTE network, every video frame the operator sees is already old by the time it hits the screen. Every joystick command arrives at the robot after a delay that varies with cell load, handovers, and packet loss. Robot teleoperation latency over LTE is not a single number; it is a chain of delays, and each link in the chain has its own failure modes.

Most datasheets quote radio latency in isolation, ignoring camera pipeline, codec, and human reaction. That is why field teams routinely underestimate how sluggish a remote UGV feels until they measure the full glass-to-glass path themselves.

What the end-to-end latency budget actually contains

Before optimizing anything, you need to know where the milliseconds go. The full loop from a photon hitting the robot’s camera to a control command reaching the motor driver has five measurable stages.

• Image acquisition: sensor exposure, readout, and USB/CSI transfer to the onboard computer.
• Encoding: H.264/H.265/AV1 compression before transmission.
• Network transport: uplink from the robot’s modem to the base station, backhaul, internet routing, and downlink to the operator.
• Decoding and display: operator-side decode plus monitor refresh cycle.
• Operator reaction and command return path: human response, joystick sampling, and the reverse network trip carrying the twist command back to the robot.

Image acquisition: 15-50 ms

A rolling-shutter USB camera at 30 fps has a frame period of 33 ms. Sensor exposure adds 1-20 ms depending on lighting. On a Raspberry Pi 4 or 5, the camera driver and application pipeline can add additional buffering. In testing, a Logitech C920 at 720p30 can deliver frames to userspace approximately 40-60 ms after exposure begins, depending on camera settings and buffering. Global-shutter industrial cameras with GigE Vision can reduce this to roughly 15-25 ms in a low-latency configuration.

Encoding: 5-40 ms

Hardware H.264 encoders on ARM SoCs and NVIDIA Jetson platforms typically add 10-25 ms at 720p when configured for low latency. Encoder availability depends on the specific board, operating system, driver stack, and Raspberry Pi model; it should be verified on the target platform. Software x264 in ultrafast preset can be similar at modest resolutions but consumes significant CPU. AV1 software encoding is generally unsuitable for low-latency teleoperation on small onboard computers. Use hardware H.264 where available with low-latency tuning: no B-frames, short GOP, and a controlled bitrate.

An example GStreamer pipeline on a platform with a V4L2 H.264 encoder:

gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,width=1280,height=720,framerate=30/1 ! v4l2h264enc extra-controls="controls,h264_profile=1,video_bitrate=2000000,h264_i_frame_period=30" ! h264parse ! rtph264pay config-interval=1 pt=96 ! udpsink host=OPERATOR_IP port=5000

Network transport: the variable component

This is the stage that dominates when you move from Wi-Fi to cellular. Representative one-way values observed in real deployments include:

• Wi-Fi (same AP, 5 GHz): 2-8 ms.
• Public LTE, good coverage: 25-60 ms one-way, but with jitter spikes to 200+ ms during handovers or congestion.
• Public LTE, cell edge: 80-250 ms one-way with frequent packet loss.
• 5G NSA (non-standalone): often 20-50 ms one-way, depending on spectrum, core-network routing, and deployment. It uses an LTE anchor for control-plane functions.
• 5G SA (standalone): potentially 8-25 ms one-way in well-provisioned networks with favourable routing.
• Private 5G / MEC: potentially 5-15 ms one-way when traffic remains close to the radio network and edge compute.

These values should be measured on the actual operator, modem, APN, and route being used. 3GPP TR 38.913 describes ambitious URLLC radio-interface targets, including approximately 1 ms user-plane latency for relevant scenarios. Such targets apply to parts of the system under defined assumptions and should not be interpreted as public-network end-to-end latency.

Decoding and display: 20-60 ms

Hardware H.264 decode on a modern laptop can take 5-15 ms. The display adds one refresh interval: 16.7 ms at 60 Hz, 8.3 ms at 120 Hz. Browsers can add compositor and buffering delay, often 20-40 ms on top of raw decode.

Operator reaction and reverse path: roughly 200-300 ms of human, 20-100 ms of network

Human visual reaction time to an unexpected stimulus is commonly on the order of 200-300 ms. This is not part of the technical video budget, but it matters when designing the complete control loop. The usability and safety of longer delays depend on speed, stopping distance, field of view, obstacle density, vehicle dynamics, and local safety functions.

How to measure your own glass-to-glass latency

The cheapest reproducible method: place a millisecond-precision timer in the robot camera’s field of view and compare it with the received image on the operator’s display. Photograph the source timer and operator display together with a phone using a fast shutter. Subtract the timestamps. Repeat 30 times, report median and 95th percentile.

For automated ROS 2 measurement, include a capture timestamp or sequence number in the image stream and record when the corresponding frame is rendered or received. A custom subscriber can calculate transport and processing delay when clocks are synchronized; otherwise, sequence numbers can still be used to measure round-trip behavior.

For the network segment only, use iperf3 in UDP mode with 1400-byte packets at your target bitrate, and log jitter and loss with --json output. For a full loop test including the joystick return path, correlate command sequence numbers at both ends. One-way timing additionally requires sufficiently synchronized clocks, for example using GPS PPS or a carefully validated time-synchronization setup.

Safety thresholds: when remote driving stops being safe

There is no universal standard for teleop latency limits on outdoor UGVs. ISO 15622 concerns adaptive cruise control and SAE J3016 defines driving-automation terminology; neither establishes general UGV teleoperation latency thresholds. The following are conservative operational starting points, not safety limits. They must be validated through a task-specific risk assessment and vehicle testing.

• Under 150 ms glass-to-glass: driving at 2 m/s can feel responsive in favourable conditions. Obstacle avoidance by the operator may be feasible where local safety functions and stopping distance are adequate.
• 150-250 ms: often manageable at speeds up to 1 m/s. Above that, overshoot on turns can become common.
• 250-500 ms: restrict operation to low speeds and predictable terrain unless the robot has validated local safety functions.
• Above 500 ms: continuous manual driving becomes difficult and may be unsuitable; use waypoint or supervisory autonomy where it has been validated for the task.
• High jitter: even if median latency is low, large delay variation makes the loop unpredictable. Slow down or pause when jitter materially affects controllability.

A useful rule of thumb: at speed v, the robot travels v × latency while the operator is viewing delayed video. A UGV at 1 m/s with 300 ms glass-to-glass delay has already moved 30 cm beyond the scene shown on screen. The full delay between issuing a command and seeing its effect can be longer because it also includes the command return path.

Watchdog patterns for link loss

Cellular links do not always degrade gracefully; they can drop. Your teleop stack must assume the link will vanish for 500 ms to several seconds and behave predictably. A minimal ROS 2 watchdog on the robot subscribes to /cmd_vel and enforces a maximum age.

Sketch of a Python node running on the robot:

self.timer = self.create_timer(0.1, self.check_cmd_age)
def cmd_cb(self, msg): self.last_cmd_time = self.get_clock().now()
def check_cmd_age(self):
  age = (self.get_clock().now() - self.last_cmd_time).nanoseconds / 1e9
  if age > 0.3: self.publish_zero_twist()
  if age > 2.0: self.engage_hold_brake()

In production, initialize last_cmd_time safely and use a monotonic clock where possible so that time-source changes cannot suppress the watchdog. Three-stage degradation can work well in field robotics: at 300 ms without a command, zero the velocity; at 2 s, hold position with active braking; at 10 s, remain in a validated safe state and wait for reconnection. Log every transition. Never let the last received twist keep executing indefinitely; that is how UGVs drive into ditches.

Practical bitrate and codec settings for LTE uplink

LTE uplink is often asymmetric and can be much narrower than downlink. Actual public-network uplink varies substantially by operator, spectrum, signal conditions, congestion, and location. Measure sustained uplink at the deployment site and leave headroom for bitrate variation, retransmissions, control traffic, and VPN overhead.

• 720p30 H.264, CBR 1.5-2.5 Mbps: often works on LTE connections with sufficient uplink capacity; encoder latency depends on the hardware and configuration.
• 1080p30 H.264, CBR 3-4 Mbps: needs strong and stable uplink capacity, which may be available on LTE or 5G depending on conditions.
• 480p30 H.264, CBR 800 kbps: fallback for weak coverage; still usable for slow driving.
• Two-stream setup: a higher-bitrate stream when capacity is available, with a lower-bitrate fallback when congestion or loss is detected.

WebRTC with its GCC (Google Congestion Control) adapts bitrate to network conditions automatically. It is a strong default for teleop over public cellular. For private 5G with guaranteed QoS, plain RTP over UDP with a fixed bitrate can be simpler and may reduce application overhead, provided loss handling, encryption, NAT traversal, and monitoring are addressed separately.

Where Leo Rover fits in this picture

The Leo Rover is available with ROS 2 and a Raspberry Pi-based onboard computer. Hardware H.264 encoding capability depends on the selected Raspberry Pi model, operating system, and driver stack, so it should be confirmed for the intended video pipeline. Field teams can attach a 4G/LTE modem via USB or Ethernet and run a WebRTC bridge for remote control. For research on 5G teleoperation, the platform’s open architecture lets you integrate an M.2 5G module or route video through an edge server. Fictionlab’s team also builds custom variants for specific radio, sensor, or payload requirements through custom robotics projects.

FAQ

What is a realistic glass-to-glass latency for a UGV over public LTE?

For a well-tuned 720p H.264 pipeline and good LTE coverage, roughly 180-350 ms glass-to-glass is a realistic planning range, but results vary substantially by camera, codec settings, operator device, cellular network, and routing. Cell-edge or congested networks can exceed 500 ms and add heavy jitter.

Does 5G actually help teleoperation, or is it marketing?

5G SA and private 5G can measurably reduce transport latency when radio conditions, core-network routing, and application placement are favourable. 5G NSA on public networks may behave similarly to fast LTE in some deployments because of its LTE anchor and network configuration. The camera and codec stages do not shrink, so total glass-to-glass latency on 5G can still be tens or more than one hundred milliseconds rather than the approximately 1 ms radio-interface target sometimes cited for URLLC.

What is the maximum safe driving speed at 300 ms latency?

There is no universal maximum safe speed. As a conservative practical starting point, keep speed at or below 1 m/s and reduce it further on cluttered terrain unless local obstacle detection, braking performance, and the full task-specific safety case support faster operation. At 300 ms of glass-to-glass delay, the UGV travels 30 cm beyond the scene shown on screen at 1 m/s.

Should the robot run autonomy locally or on an edge server?

Safety-critical loops such as emergency stop, speed limiting, watchdogs, and collision mitigation should run on the robot. Higher-level planning and perception can run on edge or cloud infrastructure if the link supports it and the resulting failure modes have been assessed. Do not make collision avoidance depend solely on a cellular connection.

How do you handle handovers between cells?

Handovers on LTE/5G can introduce gaps ranging from short disruptions to hundreds of milliseconds or more, depending on network conditions. Use a jitter buffer only after measuring its latency impact, enable WebRTC’s NACK/PLI mechanisms for video recovery, and ensure the watchdog treats a sustained command gap as a stop condition rather than normal operation.

Is WebRTC or plain RTP better for UGV teleop?

WebRTC handles NAT traversal, encryption, and congestion control automatically, which is valuable on public networks. Plain RTP over UDP can have lower application overhead on controlled networks where you manage QoS, security, loss recovery, and routing. Choose based on where you deploy.

Can you rely on VPN for teleop links?

WireGuard usually adds little processing overhead on suitably capable hardware, but its actual latency impact depends on CPU load, packet size, routing, and the VPN endpoint location, so measure it in the deployed system. OpenVPN can add more variable overhead. TCP-based tunnels are generally unsuitable for real-time video because head-of-line blocking can turn packet loss into visible freezes.

Build teleop that survives the field

Measuring the full latency budget, sizing your bitrate to actual uplink, and coding a watchdog that fails safely are the difference between a demo and a deployable UGV. If you need a platform with these hooks already in place, or a custom build for a specific radio and sensor stack, talk to Fictionlab’s engineering team through Custom Robotics or browse configurations in the shop.