Provide a common and simple unified interface to the sensors
Provide both HW sensor abstraction as well as virtual sensors (for replay)
Provide raw sensor serialization (for recording)
Deal with platform and SW particularities:
- API/Processor Conversion/transfer: CUDA, GL, NvMedia, CPU
- Make use of the additional SoC engines: H264 encoder/decoders, VIC, etc.
Current paradigm is non-blocking functions and blocking with timeout
Defined by EGL, CUDA and NvMedia paradigms and capabilities
Goal is event-driven and non-blocking data-flow model to be light-weight and efficiently:
- Schedule work ahead to hide latencies on triggering work for all our HW engines.
- Minimize your use of threads to increase runtime determinism of the system.

Supported Sensors

DriveWorks provides support for the following sensor types:

Camera (GMSL and USB)
Radar
Lidar
IMU
GPS
CAN bus
Time

DriveWorks supports a diverse set of these sensors out-of-the-box. For the most up-to-date list of supported sensors, please refer to the following:

Release Notes.
Sensor Enumeration Sample.
http://www.open-lab.net/drive/ecosystem-hw-sw.

Note: Native support for Ouster lidars is officially deprecated in favor of the plugin for the AGX platform that is managed and distributed by Ouster. Due to exceeding the POSIX packet size limit for its raw data transmission, users might observe erroneous behavior of the Aurix SoC.

Custom Sensors

In the event a sensor is not natively supported in DriveWorks, integration with custom sensors is also possible. For more information, please refer to Integrating with Custom Sensors.

Other Sensors

DriveWorks does not constrain the integration of any sensors. Any third-party sensor can be used in the DriveWorks modules, if its output is mapped to the sensor data API representation, such as: dwCANMessage, dwGPSFrame, dwIMUFrame, dwLidarDecodedPacket, dwImageCUDA, dwImageGL, dwImageCPU, and dwImageNvMedia. Use dwContext_getCurrentTime() to time-stamp individual sensors.

Sensor Sharing

DriveWorks API supports sharing of the same HW sensor by multiple DriveWorks abstractions. For example, the same GPS sensor can be created twice from the same hardware implementation (e.g. Xsens device or serial connection). Each DriveWorks sensor has its own internal FIFO to keep the data ready for consumption. Sensor data of the shared sensors are equal and can be matched by equal timestamps if required. The sample GPS Location Logger Sample shows, in particular, how two sensors can be created from the same HW GPS sensor.

Sensor Serialization

A dwSensorSerializerHandle_t can be created using any sensor and allows the serialization of the sensor output to file or to a custom callback function. dwSensorSerializer_serializeData() and dwSensorSerializer_serializeDataAsync() are used for all sensors, whereas dwSensorSerializer_serializeCameraFrame() and dwSensorSerializer_serializeCameraFrameAsync() are used for dwImageHandle_t coming from a Camera. Async recordings always require dwSensorSerializer_start(). The way serialization is performed for cameras depends on the camera protocol and parameters (the output can be a .h264/.h265 compressed video, .raw video, .lraw lossless video). When serializing a camera image, it always has to be a NATIVE image.

Relevant Tutorials

Sensors

APIs

Sensors Interface

Table of Contents