DriveWorks SDK Reference
3.5.78 Release
For Test and Development only

Sensor Timestamping
Note
SW Release Applicability: This tutorial is applicable to modules in both NVIDIA DriveWorks and NVIDIA DRIVE Software releases.

One of the critical aspects of data acquisition on systems with multiple sensors for real-time processing is to obtain accurate timestamping of the data. NVIDIA® DriveWorks relies on the system time source of Xavier, 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, and the application can get the current time via the function:

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 the Xavier, so sensor data recevied via Sensor Abstraction Layer always has a timestamp associated with it. In particular:

  • GMSL Cameras: timestamping is done by the kernel driver triggered by the hardware when full frame has been written into memory.
  • SocketCAN: timestamping occurs by the kernel driver when the full message is captured from the hardware by the driver. When hardware timestamping is used, timestamping is performed at the hardware level, by the TegraCAN hardware. The hardware counters are synced to the software clock.
  • AurixCAN: messages through this interface are timestamped by the Aurix safety OS. gPTP must be running and Aurix+Xavier 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 software 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.

Sensor timestamping is used in multiple samples: