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.
The GNSS receiver provides two key pieces of timing information:
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.
The Jetson three main responsibilities in the synchronization process:
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.
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.
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?).
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.
We have a couple options here:
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.
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.
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.
U1 is connected to LiDAR