End-to-End Latency Measurement Methodology for Connected and Autonomous Vehicle Teleoperation

End-to-End Latency Measurement Methodology for Connected and Autonomous Vehicle Teleoperation
Notice: This research summary and analysis were automatically generated using AI technology. For absolute accuracy, please refer to the [Original Paper Viewer] below or the Original ArXiv Source.

Connected and Autonomous Vehicles (CAVs) continue to evolve rapidly, and system latency remains one of their most critical performance parameters, particularly when vehicles are operated remotely. Existing latency-assessment methodologies focus predominantly on Glass-to-Glass (G2G) latency, defined as the delay between an event occurring in the operational environment, its capture by a camera, and its subsequent display to the remote operator. However, G2G latency accounts for only one component of the total delay experienced by the driver. The complementary component, Motion-to-Motion (M2M) latency, represents the delay between the initiation of a control input by the remote driver and the corresponding physical actuation by the vehicle. Together, M2M and G2G constitute the overall End-to-End (E2E) latency. This paper introduces a measurement framework capable of quantifying M2M, G2G, and E2E latencies using gyroscopes, a phototransistor, and two GPS-synchronized Raspberry Pi 5 units. The system employs low-pass filtering and threshold-based detection to identify steering-wheel motion on both the remote operator and vehicle sides. An interrupt is generated when the phototransistor detects the activation of an LED positioned within the camera’s Field Of View (FOV). Initial measurements obtained from our teleoperated prototype vehicle over commercial 4G and 5G networks indicate an average E2E latency of approximately 500 ms (measurement precision +/- 4 ms). The M2M latency contributes up to 60% of this value.


💡 Research Summary

The paper addresses a critical gap in the evaluation of latency for teleoperated Connected and Autonomous Vehicles (CAVs). While most prior work focuses on Glass‑to‑Glass (G2G) latency—the delay between a physical event, its capture by a camera, and its display to a remote operator—this metric alone does not capture the full experience of a driver. The authors introduce Motion‑to‑Motion (M2M) latency, defined as the time between the driver’s control input (steering wheel turn) and the corresponding physical actuation on the vehicle, and argue that the sum of G2G and M2M constitutes the End‑to‑End (E2E) latency that directly impacts safety and usability.

To measure all three components (G2G, M2M, E2E) with millisecond precision, the authors built a hardware‑synchronised measurement platform. Two Raspberry Pi 5 boards run Ubuntu 24.04 and a custom Linux kernel module. Each board is equipped with an MPU‑6050 six‑axis IMU that records angular velocity of the steering wheel, a TEPT‑4400 phototransistor, and a green LED. The boards are synchronised using GPS Pulse‑Per‑Second (PPS) signals and NMEA data via Chrony, achieving an average clock offset of 3 µs (max 12 µs), far superior to conventional NTP‑based methods.

On the operator side, the IMU detects the onset of steering motion; the timestamp is recorded as GY_Station. On the vehicle side, the IMU similarly records GY_Vehicle. When the vehicle‑side software detects motion, it turns on the LED placed within the field of view of the operator’s camera. The LED’s illumination is captured by the camera, and the phototransistor on the operator side generates a GPIO interrupt (PT_Trigger) when sufficient light is received. The LED’s physical turn‑on time (LED_On) and the phototransistor’s physical detection (PT_Ph) are also logged. The authors formalise the latency calculations as:

  • M2M = GY_Vehicle – GY_Station
  • G2G = PT_Trigger – LED_On
  • E2E = PT_Trigger – GY_Station – LED_Delay (where LED_Delay = LED_On – GY_Vehicle)

Each timestamp is further decomposed into the true physical event plus measurement‑induced errors (E_GY, E_LED, E_PT), allowing a clear separation of actual latency from systematic bias.

Software runs a high‑resolution timer (100 µs period) that reads the IMU over I²C. Although the I²C bus was intended to operate at 400 kHz, Linux constraints limited the effective rate to ~97.5 kHz, resulting in a 240 µs acquisition time per loop and an overall loop period of ~250 µs. Low‑pass filtering reduces jitter, and a configurable velocity threshold determines motion onset. A 2.5 s dwell‑below‑threshold rule defines motion completion, calibrated in the field. The phototransistor interrupt is accepted only when exactly one detection occurs per LED activation, improving robustness against spurious lighting.

The authors first performed baseline tests with minimal physical motion and network traffic to quantify intrinsic measurement errors. Results showed mean baseline latencies of 3.475 ms for M2M, 0.470 ms for G2G, and 3.945 ms for E2E, with standard deviations of roughly 2 ms, confirming sub‑5 ms precision. Subsequent experiments were conducted on a research vehicle in Luxembourg using commercial 4G and 5G networks provided by POST. The measured average E2E latency was approximately 500 ms, with M2M contributing up to 60 % of the total. The authors break down M2M into input‑device latency, network latency, pre‑processing, post‑processing, PID controller latency, and mechanical actuation latency. G2G is similarly decomposed into camera capture, stream server processing, network transmission, client processing, and monitor display latency. The experimental data reveal that network variability and the vehicle‑side control pipeline dominate the M2M component.

Key contributions of the work include:

  1. A low‑cost, reproducible measurement framework that achieves ±4 ms precision for all latency components.
  2. Demonstration that GPS‑PPS synchronisation dramatically reduces clock‑offset error compared with NTP.
  3. Empirical evidence that M2M latency is the dominant factor in teleoperated driving, highlighting the need for optimisation of vehicle‑side processing and network handling.
  4. Open‑source release of the hardware schematics and software (GitHub link provided).

Limitations are acknowledged: the IMU sampling rate is constrained by I²C and Linux scheduling, and the LED‑phototransistor method can be sensitive to ambient lighting conditions. Future work proposes higher‑speed sensor interfaces (e.g., SPI or DMA), refined calibration of LED‑to‑phototransistor delays, multi‑vehicle multi‑operator scenarios, and real‑time compensation algorithms that use measured M2M latency to adapt control commands dynamically.

In conclusion, the paper delivers a comprehensive, hardware‑synchronised methodology for quantifying G2G, M2M, and E2E latencies in teleoperated CAVs. The findings that M2M accounts for the majority of the 500 ms end‑to‑end delay provide actionable insight for designers of remote‑driving systems, emphasizing that reducing vehicle‑side processing and network latency is essential for safe and responsive teleoperation. The presented framework offers a practical tool for both academic research and industry development, facilitating rigorous latency benchmarking across 4G, 5G, and future communication technologies.


Comments & Academic Discussion

Loading comments...

Leave a Comment