Hardware-triggered Time Synchronization of Roadside Multi-lidar, Multi-camera Measurement System for Accurate Data Alignment

AI summary

Overview

• Research area: Computer vision and multi-sensor perception for intelligent transportation infrastructure — specifically hardware-level time synchronization of roadside lidar and camera sensors for accurate data alignment and fusion.
• Technical level: Intermediate. The paper is readable for someone with basic familiarity with sensors, embedded electronics (Arduino, GPIO pins), and robotic middleware (ROS 2), but the circuit-level detail and sensor configuration parameters require some hardware background.
• Scope: The paper presents an open-source, hardware-triggered time-synchronization circuit for a roadside dual-lidar, three-camera system, evaluates data-alignment quality across configurable trigger delays for three classes of road users, and extends the same circuit to a one-lidar, seven-camera vehicle platform.
• arXiv identifier: arXiv:2607.15889v1 [cs.CV], 17 Jul 2026, by Shiva Agrawal, Savankumar Bhanderi, Zhiran Yan, and Gordon Elger (IIMo, Technische Hochschule Ingolstadt, Germany).

What This Paper Is About

Multi-sensor perception systems only work if the sensors capture the same physical world at the same moment, and if every measurement carries a timestamp tied to one common clock. In practice each sensor runs on its own clock and sampling rate — cameras around 30 Hz, lidar at 10 or 20 Hz — so lidar and camera frames can be offset from each other by tens of milliseconds, which corrupts the spatial overlap between a projected lidar point cloud and the objects visible in a camera image. The goal of this work is to build a simple, low-cost, open-source hardware circuit that triggers a lidar and several cameras together, lets the trigger delay for each camera be programmed independently, and uses that circuit to find the delay that maximizes cross-sensor consistency for cars, bicycles, and pedestrians.

Key Contributions

1. A roadside multi-lidar, multi-camera sensor system is developed for traffic monitoring and control, deployed on a mobile mast near an elementary school in front of a traffic-light crossing.
2. An open-source, hardware-triggered time-synchronization electronic circuit is designed and tested for a lidar and 3-camera setup, with independently and remotely configurable time delays for each camera.
3. Performance of the lidar–camera data alignment is evaluated by systematically varying the temporal offset between measurements and computing object-mask coverage for different road users (car, bicycle, person).
4. The circuit is extended to a vehicle platform with one lidar and seven cameras for hardware-triggered synchronization; that board is fabricated and tested for functionality, though detailed evaluation is stated to be outside the scope of the article.

All hardware circuit design files and source codes are published at https://github.com/shiva-THI/hardware-trigger-time-sync-lidar-cameras.

Main Findings

• Best per-camera delays: Coverage analysis of lidar points projected onto camera object masks identified best-synchronization trigger delays of 30 ms for the left camera, 50 ms for the middle camera, and 65 ms for the right camera, relative to the lidar scan (these are also the delays used in the qualitative projection figures).
• Left camera favors 30 ms: Near-distance (0–15 m) coverage at 30 ms was 82.38% for a person, 82.81% for a bicycle (the paper's prose quotes 82.82% for this same value while Table I lists 82.81%), and 93.18% for a car — higher than the corresponding values at 25 ms and 35 ms. Person and car far-range coverage was slightly higher at 25 ms than at 30 ms, but the overall evaluation favored 30 ms.
• Coverage is highly sensitive to delay at longer range: For the left camera at 35 ms, far-range (30–50 m) coverage dropped to 25.00% for a person and 34.61% for a bicycle, showing that a wrong delay degrades alignment sharply at distance.
• Middle camera is nearly insensitive to delay: This camera is mounted pointing downward and covers only a very small section of the road, particularly the pedestrian crossing, so no separate near/mid/far ranges were defined and one coverage value per road user was computed over the entire field of view. Coverage was high for all three tested delays, with 50 ms best: 89.86% person, 89.55% bicycle, 99.19% car (versus 88.19%, 89.87%, 98.77% at 45 ms and 86.41%, 88.33%, 98.95% at 55 ms).
• Right camera favors 65 ms: At 65 ms the right camera achieved 81.93% (person), 77.48% (bicycle), 95.32% (car) in the near range; 70.94%, 66.65%, 94.58% in the mid range; and 65.00%, 58.20%, 88.41% in the far range. Note that the near-range person value at 70 ms (87.79%) is higher than at 65 ms, and near-range bicycle coverage at 60 ms (69.60%) is lower, but the paper concludes 65 ms is best overall for this camera.
• Cars are consistently the best-aligned class: Across all cameras and configurations, car coverage is highest (for example 93.18% near, 87.81% mid, 76.93% far for the left camera at 30 ms), while persons and bicycles are consistently lower.
• Coverage falls with distance: For the left camera at 30 ms, person coverage drops from 82.38% (near, 0–15 m) to 66.20% (mid, 15–30 m) to 55.55% (far, 30–50 m); car coverage drops from 93.18% to 87.81% to 76.93%. Evaluations stop at 50 m because lidar point density reduces drastically beyond that, especially for persons and bicycles.
• Jitter is small and non-cumulative: The Arduino Nano interrupt routine may introduce jitter typically in a few microseconds, but because the system re-aligns to the lidar's phase-locked reference every cycle there is no cumulative drift, and this jitter is described as orders of magnitude lower than the non-deterministic latencies of software synchronization.
• Synchronization is hardware-only: Despite using ROS 2 for data collection and processing, the multi-sensor system's time synchronization is implemented entirely through hardware triggering, with no software-based temporal adjustments.
• Dual-lidar alignment uses built-in phase lock: The Ouster OS1 (64 channels, mounted upright) is the reference/master sensor and generates trigger pulses, while the OSDome (128 channels, inverted below the OS1) is synchronized to it using the vendor's built-in phase-lock feature at a phase angle of 0 degrees, aligning the start of both lidar rotations to multiples of 100 ms (e.g., 100, 200, 300, 400, 500 ms) when both sensors operate at 10 Hz.
• The circuit scales to more cameras: The same design was extended to one Ouster lidar and seven identical Basler camera models on a sensor-equipped vehicle, and the fabricated board was successfully tested for functionality.

Methodology in Plain English

The researchers first deployed a measurement mast (maximum height 6 m) holding two lidar sensors — an Ouster OS1 with 64 channels mounted upright at 4.5 m and an Ouster OSdome with 128 channels mounted inverted below it — three GigE Vision Basler ace2 a2a1920-51gcBAS RGB cameras at approximately 5.5 m height, and two weather sensors on top (weather sensors are out of scope here). Spatial calibration of the two lidars and three cameras used a published multi-sensor calibration methodology with static calibration targets, treating the upright OS1 as the reference sensor; once spatial calibration was validated against the static environment, time synchronization was performed.

For timing, the OS1's multipurpose IO pin was configured as an output (using a pull-up resistor via a jumper to supply enough current) to emit one 10 Hz trigger pulse at the start of every scan cycle, aligned to multiples of 100 ms. That pulse alone could directly drive at most three Basler cameras before hitting the maximum current limit, so an Arduino Nano v3 was inserted as a configurable intermediary: it receives the lidar pulse on digital input pins D2, D3, D4 and emits independently time-delayed trigger pulses on output pins D5, D6, D7 for the left, middle, and right cameras. This creates pin-pairs (D2-D5, D3-D6, D4-D7) that make debugging simple and expansion modular. The Arduino is connected to the edge computing device by USB, which provides power, optional serial communication, and the ability to update each camera's delay remotely. A schematic, KiCad PCB layout, and fabricated board are all provided. Because the lidar scans the left camera's field of view first, then the middle, then the right, the required delay grows across the cameras, but the exact overlap geometry cannot be measured directly, so delays were found experimentally.

For the common time base, both lidars are synchronized to the edge computing device's system time via PTP, and that device maintains UTC (adjusted to local time) through its internet connection; the resulting precise timestamps appear directly in the ROS 2 point cloud message headers from the lidar driver. The cameras similarly use PTP settings, chunk time configuration, and hardware trigger parameters, with timestamps written into the ROS 2 Image message headers. ROS 2 Humble on Ubuntu 22.04 LTS handles the data processing. Key lidar configuration parameters were: Lidar Mode 1024 × 10; Timestamp Mode "Time from PTP 1588"; Multipurpose IO Mode "Output from encoder angle"; Phase lock enabled; Phase lock Polarity 0 degrees.

For the evaluation, three dynamic road users were used: a car driven at a constant 30 km/h (the maximum speed limit in the school zone), plus a bicycle and a pedestrian moving at their normal speeds. Each traversed the full field of view in both directions across several short scenes, each recorded with a different time offset. Distance bands were defined as near (0–15 m), mid (15–30 m), and far (30–50 m). Camera object masks were generated with Mask-RCNN for the road user under evaluation only, while the merged dual-lidar point clouds were annotated manually with 3D bounding boxes using the open-source sustechpoints tool. The lidar points belonging to each road user were projected onto the corresponding image mask, and percentage coverage was computed as (projected lidar points inside the mask / total lidar points) × 100%, then averaged per distance range. Delay values were initially obtained by sweeping the delay, visually inspecting alignment, and reasoning about the lidar scan time relative to each camera's mounting position.

Why This Matters

Impact on research. Most prior hardware-based lidar–camera synchronization work either lacks published design details or is not reusable: earlier approaches used external photo diodes and flashing LEDs (unsuitable for roadside masts and vulnerable to bad weather), a PIC32 microcontroller with unpublished hardware details, an FPGA-based SoC that is complex and costly with no published implementation, a custom ARM Cortex board limited to at most two cameras, and a one-lidar/three-camera vehicle rig whose delay-offset correction hardware is not described. This paper supplies a simple, low-cost, open-source, remotely reconfigurable alternative with design files and code, which allows other groups to reproduce and extend the synchronization rather than re-derive it.

Real-world applications (from the paper's framing).

• School-zone pedestrian safety monitoring: the mast is installed near an elementary school in front of a traffic-light crossing, where the near range (0–15 m from the sensors in both directions) matters most for protecting children.
• Roadside traffic monitoring and control in dense urban traffic, using the fused lidar–camera view for road-user detection and motion prediction.
• Distributed intersection infrastructure: multiple sensor masts at one intersection could each replicate the same hardware logic locally and be tied to a common PTP Grandmaster — optionally referenced to a GPS clock — so every lidar is phase-locked to a shared global reference with a deterministic firing sequence.
• Sensor-equipped vehicles: the same circuit was extended to a car with one lidar and seven cameras, showing the approach works for both infrastructure and vehicle platforms.

Industry relevance. The architecture is described as vendor-agnostic: it is claimed to be directly extensible to any lidar supporting physical Phase Lock and Trigger Out signals, such as the Hesai Pandar64 and RoboSense RS-32, and to industrial cameras with dedicated GPIO trigger inputs, such as IDS and Teledyne FLIR. The authors emphasize that relying on a PTP backbone could natively align data across distributed nodes at the hardware level, potentially eliminating the need for complex temporal compensation at the Cooperative Perception Service level and enabling seamless real-time data fusion. The low cost (an Arduino Nano plus a custom PCB) and the ability to reconfigure and add camera channels make it attractive for commercial roadside deployments; the current implementation, however, still leverages Ouster-specific functionality.

Future Directions

• Evaluate the seven-camera vehicle extension in detail. The one-lidar, seven-camera vehicle board was tested for functionality, but detailed evaluations were explicitly left outside the scope of this article and named as possible future work.
• Replace manual delay search with a principled method. The best delays were found by sweeping values, visually observing alignment, and using intuition about lidar scan time versus mounting geometry, because the exact overlap between each camera's and the lidar's field of view is not directly measurable. An automated or geometry-driven procedure could make this systematic.
• Validate distributed multi-mast synchronization. The proposal to replicate the hardware at each mast of an intersection, tie them to a common PTP Grandmaster optionally referenced to a GPS clock, and thereby remove Cooperative Perception Service-level temporal compensation has not been experimentally demonstrated in this paper.
• Test cross-vendor generalization. The extensibility to Hesai Pandar64 and RoboSense RS-32 lidars and to IDS and Teledyne FLIR cameras is argued architecturally but not demonstrated, since the presented system uses Ouster lidars and Basler cameras.
• Quantify residual jitter and address the weather sensors. The circuit's jitter is characterized only qualitatively as a few microseconds; the two weather sensors on the mast are stated to be out of scope of this hardware time-synchronization work.

Target Audience

Researchers and engineers working on multi-sensor perception, intelligent transportation infrastructure, and cooperative/connected vehicle systems will benefit most, particularly those who need practical, reproducible, low-cost ways to time-synchronize lidar and camera data rather than purely software timestamping. Embedded hardware designers building data-collection rigs, and practitioners deploying roadside or vehicle-mounted perception systems who want configurable per-camera trigger delays with remote reconfiguration, are the secondary audience. It is less suited to readers looking for algorithmic advances in fusion, detection, or calibration, since those components are drawn from prior work and only briefly cited.

Authors’ abstract

Accurate temporal alignment of heterogeneous sensors is necessary for reliable environment perception in roadside multi-lidar, multi-camera systems, particularly in dense urban traffic. For this purpose, an open-source, simple, modular, and configurable hardware-triggered time-synchronization circuit is presented in this work to perform temporal alignment or accurate time synchronization between a lidar and multiple cameras. In the designed circuit, a lidar synchronization pulse is used as a reference input, and independently programmable, time-delayed trigger pulses are generated for each camera, allowing flexible adaptation to varying sensor setups and mounting geometries. A series of experiments is conducted on a roadside-mounted perception system comprised of lidar and three cameras, in which the trigger delay is systematically varied, and its impact on spatial-temporal alignment is evaluated. For different classes of road users, the overlap between lidar point cloud measurements and camera measurements is quantified to identify delay configurations that maximize cross-sensor consistency. The proposed circuit is shown to achieve robust and repeatable synchronization while remaining straightforward to deploy, reconfigure, and extend due to its simple and open-source design. Following validation on a three-camera roadside system, the circuit is extended to a vehicle platform with seven cameras and a lidar, providing a low-cost, extensible solution for multi-sensor synchronization across infrastructure and vehicle setups. All hardware circuit design files and source codes are available at https://github.com/shiva-THI/hardware-trigger-time-sync-lidar-cameras.