DriveWorks SDK Reference
3.5.78 Release
For Test and Development only

Sensor Manager
Note
SW Release Applicability: This module is available in both NVIDIA DriveWorks and NVIDIA DRIVE Software releases.

About This Module

Sensor Manager uses underlying SAL (Sensor Abstraction Layer) APIs to provide applications with a higher-level API to access sensor events. It is a thread-less module, whose purpose is to provide time-sorted stream of events from an aggregate set of sensors. Key features include:

  • Configuration: instantiation of sensors based on JSON configuration data.
  • Sensor Event Access: strictly time-sorted event stream from all sensors in case of "virtual" sensors (i.e. sensor data playback from file); and weakly-sorted event stream from all sensors if running in live mode (with real sensors).

Implementation details:

  • Blocking poll operations with timeout support.
  • Support for multiple event consumers.

Sensor Abstraction Layer

In general, the NVIDIA® DriveWorks SAL implements sensor functionality into two modular layers:

  • Device type: DriveWorks provides implementations for supported sensor interfaces (e.g. Radar, Lidar, Camera, etc.)
  • Device-specific decoder: handles parsing and interpretation of raw data for a given sensor model.

In addition to the device decoders already implemented within the DriveWorks library, customers may implement additional device decoders using plug-in interfaces. The list of interfaces to be implemented is defined in an interface header file that is specific to sensor type. As part of application deployment, this pluggable interface is compiled as a shared object and loaded by DriveWorks at runtime.

The current API definition for the SAL can be found in the DriveWorks SDK documentation.

Sensor Manager

Sensor Manager is agnostic to specific sensor type, instead, it provides unified access to all types of sensors that are supported by SAL. Sensors instantiation is handled through the dwRigHandle_t (see Rig Configuration). An example configuration file is shown below. This configuration defines a one-camera setup (ar0231 RCCB cameras), CAN bus, and a GPS sensor.

{
"rig": {
"sensors": [
{
"name": "camera:front:center:60fov",
"parameter": "camera-type=ar0231-rccb,camera-group=a,camera-count=1,camera-mask=0001,siblingIndex=0",
"properties": {
"Model": "ftheta",
"width": "1920",
"height": "1208",
"cx": "960",
"cy": "604",
"bw-poly": "0.0 0.000545421498827636 -1.6216719633103e-10 -4.64720492990289e-12 2.85224527762934e-16"
},
"protocol": "camera.gmsl",
"nominalSensor2Rig": {
"quaternion": [-0.502444, 0.507493, -0.497444, 0.492494],
"t": [1.749, -0.1, 1.47]
},
"sensor2Rig": {
"quaternion": [-0.502444, 0.507493, -0.497444, 0.492494],
"t": [1.749, -0.1, 1.47]
}
},
{
"name": "can:vehicle",
"nominalSensor2Rig": { "quaternion": [ 0.0, 0.0, 0.0, 1.0 ],
"t": [ 0.0, 0.0, 0.0 ] },
"parameter": "device=can0",
"properties": null,
"protocol": "can.socket",
"sensor2Rig": { "quaternion": [ 0.0, 0.0, 0.0, 1.0 ],
"t": [ 0.0, 0.0, 0.0 ] }
},
{
"name": "gps:dataspeed",
"nominalSensor2Rig": {
"quaternion": [0.0, 0.0, 0.0, 1.0],
"t": [-0.2, -0.1, 0.4]
},
"parameter": "can-proto=can.socket,can-params=device=can0",
"properties": null,
"protocol": "gps.dataspeed",
"sensor2Rig": {
"quaternion": [0.0, 0.0, 0.0, 1.0],
"t": [-0.2, -0.1, 0.4]
}
}
],
},
"version": 2
}

Input

The following are the input requirements to the Sensor Manager:

  • All sensors used by the Sensor Manager (defined in a JSON configuration file) must be supported by the Sensor Abstraction Layer (SAL).
  • All sensor data must be timestamped (as provided by SAL).

Output

The only output requirements for the Sensor Manager is to provide the respective sensor data as specified at the given event when the function to acquire the next event is called.

Relevant Tutorials