1 # Copyright (c) 2019-2020, NVIDIA CORPORATION. All rights reserved.
3 @page sensors_usecase1 Sensors Life Cycle
5 @note SW Release Applicability: This tutorial is applicable to modules in both **NVIDIA DriveWorks** and **NVIDIA DRIVE Software** releases.
7 Before you use any sensor in NVIDIA<sup>®</sup> DriveWorks, you must create an instance of the sensor, then use a start-stop mechanism to collect data and finally release the sensor so all resources are freed.
9 
11 The following functions support the life cycle shown above:
13 - dwSAL_createSensor() is the function call that prepares the sensor for data delivery. This includes power up, establish connection, open channels, allocates FIFOs, etc... This function is expected to have a significant cost and should only be used during initialization. Sensor type and parameters are determined by using the above protocol and parameter strings.
14 - dwSensor_start() is a low latency call that starts the capturing of sensor data.
15 - dwSensor_stop() is a low latency call that will stop capturing data and will drain any data not consumed in preparation for the next start call.
16 - dwSAL_releaseSensor() is a function call used to stop the sensor, disconnect it from DriveWorks SAL and release any allocated resources. It is expected to be high latency and should only be called at application termination.
18 Here is an example of initialization of a virtual camera for video replay and its release:
20 // Initialize DriveWorks
21 dwInitialize(&sdk, DW_VERSION, &sdkParams);
22 // create SAL module of the SDK
23 dwSAL_initialize(&sal, sdk);
24 // create virtual camera interface
25 dwSensor cameraSensor = DW_NULL_HANDLE;
27 dwSensorParams params;
28 std::string parameterString = "file=/tmp/test.h264";
29 params.protocol = "camera.virtual";
30 dwStatus result = dwSAL_createSensor(&cameraSensor, params, sal);
31 if (result != DW_SUCCESS) {
32 std::cerr << "Cannot create camera.virtual?"
33 << params.parameters << std::endl;
39 Once the sensor has started, it is possible to consume the data being acquired by using generic or specialized accessors.
41 Generic accessors are used mainly for serialization purposes as they provide raw sensor data. The available function calls are `dwSensor_readRawData()` to get access to the data memory pointers and `dwSensor_returnRawData()` to return the pointers back to the sensor abstraction layer.
42 A full workflow based on raw data use is demonstrare in @ref dwx_record_sample.
44 To access processed data one needs to use specialized function calls that will provide the data formatted appropriately depending on the sensor type.
45 For all details on specific sensors see:
47 - @ref dwx_sensors_camera_tutorials
48 - @ref dwx_sensors_canbus_tutorials
49 - @ref dwx_sensors_gps_tutorials
50 - @ref dwx_sensors_imu_tutorials
51 - @ref dwx_sensors_lidar_tutorials
52 - @ref dwx_sensors_radar_tutorials
54 After usage the sensor, SAL and SDK handle must be released.
57 // release camera sensor
58 dwSAL_releaseSensor(&cameraSensor);
60 // release SAL module of the SDK