This document outlines the time synchronization strategy to ensure all components operate on a common, highly accurate time reference derived from GNSS.
We use GNSS time as an absolute reference with the SentiBoard v1.3 acting as the central hub for distributing PPS (Pulse Per Second) time signals and synchronizing incoming IMU sensor data.
Establishing a Common Time Reference
The GNSS receiver provides two key pieces of timing information:
- A highly accurate 1 PPS signal
- NMEA (or UBX) messages, which contain absolute timestamps in UTC time (along with position data of course).
We have configured the SentiBoard trigger to be in Synchronized mode to depend on the external PPS signal from the GNSS receiver to sync up its trigger frequency (to the nearest second?).
When the PPS signal arrives, the SentiBoard will send a Trigger packet to the Jetson Orin NX over USB containing the timing information of that trigger.
The NMEA (or UBX) messages is used to establish the system-wide absolute UTC time.
Synchronization of Core Computing Units
Jetson Orin NX
The Jetson three main responsibilities in the synchronization process:
- It receives the 1 PPS signal over GPIO, ensuring its internal clock doesn't drift.
- It acts as a PTP (Precision Time Protocol) Master, providing time synchronization to the LattePanda 3 Delta over Ethernet to the LattePanda (and possibly the LiDAR).
- It processes the ZED X camera data, timestamping it upon arrival in RAM from the capture card.
The Jetson is compiled with the PPS kernel module (we need to recompile the linux kernel) enabled. This allows us to interface with PPS signals via the linux PPS API.
LattePanda 3 Delta
The LattePanda, lacking direct GPIO access for PPS, operates as a PTP slave, receiving updates from the Jetson over Ethernet.
Although it would have been possible to send PPS over serial from the SentiBoard to the LattePanda, USB jitter could introduce ±0.125ms of timing variability, and PTP is simpler to configure.
Synchronization of Sensors
IMU and GNSS Data
The IMU (and GNSS data? or does it use the NMEA data) are timestamped directly on the SentiBoard before beign sent over USB to the Jetson (and LattePanda?).
ZED X Stereo Cameras
As mentioned earlier, the Jetson timestamps stereo camera data when it is received into RAM from the capture card. (TODO: add links from my notes) This is done via the ZED SDK.
There is no hardware trigger available for the ZED X cameras, and it doesn't have a way to timestamp the data at the time of capture, so this is the most practical way to synchronize them with the system.
The downside of this is that the timestamp is often delayed by a few frames according to this.
If we want to improve the delay, we can look into kalibr which provides calibration data based on correlation between IMU data and camera data. We can do this just from ROS bag data.
LiDAR Synchronization
We have a couple options here:
Option 1: PPS + PTP Synchronization
The 1 PPS signal from the SentiBoard synchronizes the LiDAR's internal clock while the Jetson provides PTP synchronization over Ethernet, ensuring the LiDAR timestamps align with the rest of the system.
Option 2: NMEA Forwarding + PPS
This is essentially how the SentiBoard achieves synchronization.
Instead of using PTP, the SentiBoard forwards GNSS NMEA messages directly to the LiDAR so it is informed of absolute UTC time while also receiving a 1 PPS signal to synchronize its internal clock.
Performance
Based on simple testing using the built-in BlueBoat network switch, I experienced +-0.1ms between the Jetson and the LattePanda.
Note that this had no other network traffic and the Jetson and LattePanda was idling.
Wiring & Implementation
LiDAR
U1 is connected to LiDAR