1 # Copyright (c) 2019-2020 NVIDIA CORPORATION. All rights reserved.
3 @page sensorplugins_gpssensor Custom GPSs (Comprehensive)
6 @section sensorplugins_gpssensor_comm Introduction
8 The Comprehensive Plugin Framework for GPS sensors allows third parties to interface with
9 custom sensor using a shared object (.so) containing their sensor driver implementation.
11 The GPS may use any available interface to communicate with NVIDIA DRIVE™ AGX as the plugin
12 fully implements the communication channel.
14 @section sensorplugins_gpssensor_impl Plugin Implementation
16 The plugin framework defines a set of function pointer definitions which must be
17 implemented and exported to the SAL. For GPS sensors, the plugin must have implementation
18 for the function pointers defined in:
20 * @ref sensor_plugins_ext_common_group.
21 * @ref sensor_plugins_ext_gps_group.
23 In addition, the plugin must implement & export the function, `dwSensorGPSPlugin_getFunctionTable()`,
24 which is the only C function that needs to be exposed from the shared object.
25 This allows the developer flexibility to implement internals of their plugin in C++, if necessary.
27 @section sensorplugins_gpssensor_interface Plugin Interfaces
29 This section does not substitute the API specification, but attempts to give a high-level overview
30 of how implemented plugin functions will be exercised by SAL.
32 @subsection sensorplugins_gpssensor_interface_init Initialization
34 For the purpose of creation, DriveWorks sensors are specified by `dwSensorParams`,
35 which contains a protocol and parameter string for the sensor to be created.
37 For custom GPSs, the protocol and parameter string will be as follows:
39 protocol: gps.custom (for live) OR gps.virtual (playback)
40 params: decoder-path=<path_to_so>[,<custom params>]
42 At initialization, a user's call to `dwSensor_create()` will lead to SAL
43 dynamically loading the plugin library via `dlopen()`.
44 SAL will then make the following call to your plugin:
46 | # | Function Call | Purpose |
47 | - | ------------- | ------- |
48 | 1 | `dwSensorPlugin_createHandle()` | Initialize a context for this sensor (allocate resources, etc.) |
50 After the call to `dwSensorPlugin_createHandle` the plugin should be ready
51 to decode data (see @ref sensorplugins_gpssensor_interface_decoding).
53 @subsection sensorplugins_gpssensor_interface_constants Sensor Creation
55 The plugin framework provides a specific entrypoint to initialize the control-plane /
56 transport layer with the sensor. For this, SAL will make the following calls to your plugin:
58 | # | Function Call | Purpose |
59 | - | ------------- | ------- |
60 | 1 | `dwSensorPlugin_createSensor()` | Initialization of communication & transport plane with the sensor |
62 It is up to the developer to decide what actions need to be taken during this call.
63 The sensor plugin is not expected to serve data until the sensor is started.
65 @note This section only applies for live sensors, and is skipped for virtual sensors
67 @subsection sensorplugins_gpssensor_interface_lifecycle Sensor Lifecycle
69 After sensor creation and initialization, DriveWorks provides a set of
70 @ref sensors_usecase1 user APIs.
72 These have a 1:1 mapping to plugin entrypoints, and their purpose is
75 | DriveWorks User API | Plugin API |
76 | ------------------- | ---------- |
77 | `dwSensor_start()` | `dwSensorPlugin_start()` |
78 | `dwSensor_stop()` | `dwSensorPlugin_stop()` |
79 | `dwSAL_releaseSensor()` | `dwSensorPlugin_reset()` |
81 Before querying the plugin for raw data, SAL will make a call
84 @subsection sensorplugins_gpssensor_interface_rawdata Raw Data Gathering
86 From its communication plane, the sensor plugin is responsible for gathering
87 raw data from the device. Once the sensor has been started via a
88 `dwSensorPlugin_start()` call, SAL will make the following calls to your plugin:
90 | # | Function Call | Purpose |
91 | - | ------------- | ------- |
92 | 1 | `dwSensorPlugin_readRawData()` | Provide raw data for a single sensor message as a byte array |
93 | 2 | `dwSensorPlugin_returnRawData()` | Returns raw data previously acquired |
95 We recommend the following format for the data that is returned:
97 ------------------------- Header -----------------------
98 [Payload Size (uint32_t)][Timestamp (dwTime_t)][Payload]
100 @note There may be multiple calls to `dwSensorPlugin_readRawData()` before a call to
101 `dwSensorPlugin_returnRawData()`. The plugin is responsible for memory management of this
102 raw buffer; an example of a refcounted buffer pool is provided as sample code.
104 @note This section only applies for live sensors, and is skipped for virtual sensors
106 @subsection sensorplugins_gpssensor_interface_decoding Decoding
108 Decoding of data is intentionally split from data gathering on the sensor's communication
109 plane. This is done to uniformly support virtual (file-based) playback of recorded data.
111 In order to decode raw data into DriveWorks-specific data structures, SAL will
112 make the following calls to your plugin:
114 | # | Function Call | Purpose |
115 | - | ------------- | ------- |
116 | ? | `dwSensorPlugin_pushData()` | Receives raw data from SAL |
117 | ? | `dwSensorGPSPlugin_parseDataBuffer()` | Decodes available data in the plugin buffer and returns decoded data |
119 The plugin should not make any assumption on the ordering of these calls, and should return
120 an available decoded packet when available.
122 @section sensorplugins_gpssensor_example Example
124 See @ref dwx_gps_plugin_sample.