Sensor Timestamping

Note

Third-party sensors and accessories noted on this page are for illustrative purposes. Please refer to NVIDIA® DRIVE® Hyperion™ 8.1 Sensors and Accessories for supported sensors and accessories.

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 the NVIDIA DRIVE AGX™ Thor, 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:

dwStatus dwContext_getCurrentTime(dwTime_t *time, dwContextHandle_t ctx);

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 NVIDIA DRIVE AGX Thor, so sensor data received 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 and DRIVE AGX Thor 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.

Timestamps may be modified depending on the sensor parameter output-timestamp. This parameter supports four options as follows:

output-timestamp=	Description
host	Default host time as described above.
raw	If sensor provides timestamp embedded in payload, host time is overwritten with the raw sensor timestamp. This option also enables simulated sensors to supply an external timestamp.
synced	If valid Time Sensor is active and sensor provides timestamp embedded in payload, perform software time synchronization to convert to host domain. If successful, this timestamp is preferable as it is closer to time of data capture. If unsuccessful or vendor timestamps unavailable, DriveWorks will fallback to host time. This is the default option if parameter is not set.
smoothed	If sensor supports time smoothing, apply on host timestamps. This option reduces jitter by averaging host/sensor timestamp deltas based on a predetermined window.

Note

• This option is deprecated and will be removed in the next release.

• For a list of supported timestamp options per sensor, see:

  • GPS Sensor Timestamp Options

  • IMU Sensor Timestamp Options

  • Lidar Sensor Timestamp Options

  • Radar Timestamp Options

  • Camera Sensor Timestamp Options

Output options are used in the following sample:

• Time Sensor Sample

Sensor timestamping is used in the following sample:

• VehicleIO Sample