What’s the sync strategy of the sensors’ inputs ?
I like this question. Also, I’d like to know the sync strategy in terms of triggered acquisition and timestamping of the data samples from different sensors: e.g. multiple cameras and LiDAR.
What I’ve found so far in the documentation is the synchronization by timestamps upon acquisition of the data packets coming from sensors.
DriveWorks relies on the system time source of Tegra, in particular the CLOCK_MONOTONIC time source. This time source adjusted to the UNIX epoch time is used internally to timestamp all sensors and events. Timestamps within the same context are guaranteed to be in sync. One thing to note is that this time source is relative to UNIX epoch time on Unix based platforms. Any NTP/PTP time corrections will influence this clock.
DriveWorks computes timestamps for each sensor when data arrives to Tegra, so sensor data returned always has a timestamp associated with it. In particular:
• GMSL Cameras: timestamping is done by the kernel driver triggered by the HW when full frame has been written into memory.
• SocketCAN: timestamping occurs by the kernel driver when the full message is captured from the HW by the driver. When HW timestamping is used, timestamping is performed at the HW level, by the TegraCAN hardware. The HW counters are synced to the SW clock.
• AurixCAN: messages through this interface are timestamped by the Aurix safety OS. gPTP must be running and Aurix+Tegra clock must be synced to make CAN messages timestamped by Aurix be in sync with DriveWorks timestamps.
• Serial port sensors (GPS): timestamping occurs when packets arrive to DriveWorks, at the SW level.
• Xsens IMU/GPS proprietary mode: clock of the Xsens devices are synchronized to DriveWorks clock, making timestamps to be in sync with DriveWorks timestamps.
• Lidar: Lidar generated point clouds provide a DriveWorks timestamp (taken when the Ethernet packet was read), the sensor provided timestamp at start of capturing the packet, and the duration of the packet capture. If the particular sensor does not provide timestamps, both host and sensor timestamps are identical.
More details about system synchro:
- Time Synchronization (P2379) in Vibrante Linux docs
- gPTP/802.1AS Conforming Configuration Support in Vibrante Linux docs