Sensor Plugins, Custom Sensor Return Type possible?

**Hardware Platform: DRIVE AGX Pegasus™ Developer Kit
**Software Version: DRIVE Software 10


I am looking to implement a custom GPS sensor via sensor plugins, I have watched the webinar ( and looked at the GPS-Plugin sample coming with DRIVE SW10. I find this very helpful and generally think I know how to go forward with this.

However, the GPS sensor we want to integrate natively returns a lot more information than what can be expressed with the standard dwGPSFrame, i.e. various confidence intervals, standard deviation, acceleration and more. Ideally, I would want to decode and return this information as well.

So the question: is it possible to integrate custom return types for a custom sensor? In GPS.h, where the dwGPSFrame ist defined, there are function definitions for dwSensorGPS_readFrame(…), dwSensorGPS_processRawData(…) etc. I assume these functions would have to be defined by me if I would want to define my own GPSFrame. But since I do not know what these functions exactly do, I do not have any idea if there are any caveats with this or a custom return type would cause trouble with any other functionality of the SAL.

Any information (thoughts, explanations, examples) on this topic would be much appreciated!


Hi @cschro,

If you wish to use the GPS sensor plugin you can only use the dwGPSFrame structure as is for GPS return type (even if you change the header GPS.h and extend the definition of a structure, this will be ignored in DW libs as the struct definition is internally in use hence pre-compiled in the DW libraries).

Alternatively, if the GPS is connected through CAN, you may want to refer to the custom ‘CAN Bus Message Logger Sample’ for your need.

Thanks for the response!

The GPS is connected through ethernet, so unfortunately your suggestions is not an option for us.

Is there any other option to achieve a custom return type? Is it possible to integrate a completely custom sensor with the common interface only or are the sensor plugins strictly required for this? As far as I remember, this option was not discussed in the webinar.

After more search in the documentation, I am having two thoughts:

  1. It says:

The NVIDIA® DriveWorks SDK does not constrain the use of third-party sensors with higher-level modules as long as they output the defined data structures, such as dwLidarDecodedPacket. In certain use-cases, users may bypass the sensor abstraction layer (SAL) and interface directly with the respective modules.

I guess, this would be such a use-case, since I do not want to output the pre-defined data structures. How can such bypassing of the SAL look and what are the caveats? I am aware, that with this approach no use of recording tool, sensormanager etc. is possible. Is there any sample for this?

  1. I found that dwSensorType can also be of type. DW_SENSOR_DATA. sample_sensor_info also outputs:
    Sensor [7] : data.socket ? ip=X.X.X.X,port=XXXX
    Could this be an option to integrate a custom return type via an ethernet-based sensor and still make use of SAL?

Hi cschro,
The recommended way to use GPS is through CAN, some GPS devices have both connections. if your device have both please consider using the CAN communication method.

regarding GPS over Ethernet, the ethernet packets has its own jitter and the network stack/os scheduling and are adding non-deterministic delay as well. this effects the accuracy of the GPS clock and data. have you considered it?

yes, that way you can still make use of the SAL. but, as you mentioned, you won’t be able to create a GPS sensor plugin and use the recording tool and other capabilities that expect a dwGPSFrame as a GPS data structure.