Sensor plugin (IMU, GPS) and recorder tool

[sleff]

Please provide the following info (check/uncheck the boxes after clicking “+ Create Topic”):
Software Version
DRIVE OS Linux 5.2.0
DRIVE OS Linux 5.2.0 and DriveWorks 3.5
NVIDIA DRIVE™ Software 10.0 (Linux)
NVIDIA DRIVE™ Software 9.0 (Linux)
other DRIVE OS version
other

Target Operating System
Linux
QNX
other

Hardware Platform
NVIDIA DRIVE™ AGX Xavier DevKit (E3550)
NVIDIA DRIVE™ AGX Pegasus DevKit (E3550)
other

SDK Manager Version
1.5.0.7774
other

Host Machine Version
native Ubuntu 18.04
other

I have written two custom sensor plugins using dwSensorIMUPlugin and dwSensorGPSPlugin.

Both are working as expected with sample_imu_logger --driver imu.custom and sample_gps_logger --driver gps.custom.

I have also written respective .json rig files, and the recorder tool saves the data succssfully.

However, only the IMU plugin can be played back using sample_imu_logger --driver imu.virtual. The GPS plugin does not work when trying to play back using sample_gps_logger --driver gps.virtual.

Both plugins were implemented in a nearly identical way. In fact, readRawData and pushData are identical between the two.

I did realise that parseData in IMU plugin requires return DW_NOT_AVAILABLE when there is not enough data to parse, whereas GPS plugin requires return DW_FAILURE when there is not enough data to parse. Both plugins require return DW_SUCCESS when there is more data to parse. This is a strange inconsistency and I noticed the documentation in DriveWorks 2.2 is wrong because it says GPS parseData should return DW_NOT_AVAILABLE rather than DW_FAILURE.

Debugging into what is going on when playing back gps.virtual, it starts from pushData, skipping readRawData since the raw data comes from file instead. It seems that size is 0, which is causing the problem. However it is strange that in imu.virtual, size is correct and therefore it can be played back.

Perhaps this is to do with the strange requirement for readRawData to output to data pointer a header consisting of uint32_t size and dwTime_t timestamp before payload. It is strange because size is also output to size pointer. It is even more strange because I tested IMU plugin without the header, and it still works in live, recording and imu.virtual playback. It is clear that for IMU plugin, size is taken from the size pointer rather than from the data header.

So maybe the problem is related to the strange GPS plugin inconsistencies? Maybe the size field in data header is used by GPS but not by IMU plugin? But for GPS plugin, gps.virtual playback does not work (size 0 in pushData) even with and without the size header.

[VickNV]

Hi @sleff ,
Thanks for trying to elucidate the problem. I still have some questions for you below. Thanks.

@sleff

I did realise that parseData in IMU plugin requires return DW_NOT_AVAILABLE when there is not enough data to parse, whereas GPS plugin requires return DW_FAILURE when there is not enough data to parse. Both plugins require return DW_SUCCESS when there is more data to parse. This is a strange inconsistency and I noticed the documentation in DriveWorks 2.2 is wrong because it says GPS parseData should return DW_NOT_AVAILABLE rather than DW_FAILURE .

Did you observe the issue with either gps.custom or gps.virtual? Could you share the detailed command?

@sleff

Debugging into what is going on when playing back gps.virtual , it starts from pushData , skipping readRawData since the raw data comes from file instead. It seems that size is 0, which is causing the problem. However it is strange that in imu.virtual , size is correct and therefore it can be played back.

Please share your complete command with which you see “size is 0” and how you check the size.

[sleff]

@VickNV

Did you observe the issue with either gps.custom or gps.virtual? Could you share the detailed command?

gps.custom works, but gps.virtual does not:

./sample_gps_logger --driver=gps.custom --params=decoder-path=libmy_gps_plugin,ip=x.x x.x,port=xxxx

./sample_gps_logger --driver=gps.virtual --params=file=my_gps.bin,decoder-path=libmy_gps_plugin,ip=x.x x.x,port=xxxx

Note these are based on sample_gps_plugin/main.cpp and sample_imu_plugin/main.cpp with main difference it uses socket instead of canbus.

I read that readRawData for canbus message does not need size and timestamp in data header, but needs header for non canbus. The current sample plugins all use canbus so there is no example of correctly setting data header.

Also there is ambiguity about whether data header size should be inclusive of header or only payload. Docs say output size should be inclusive of header, and I confirm that is necessary for the size pointer output in readRawData to be inclusive. However, description of header in docs say the size value in header is payload size. Also, I saw a webcast on custom plugins where the example lidar plugin uses socket and shows size in readRawData set to payload size for both data header and output pointer.

[sleff]

@VickNV

Please share your complete command with which you see “size is 0” and how you check the size.

In my_gps_plugin/main.cpp:

First line of function pushData(),

std::cout<< "push size " << size << std::endl;

Displays 0

But in corresponding function in my_imu_plugin/main.cpp it displays valid size greater than 0.

Note that both plugins have identical code for readRawData and pushData.

Also to be even clearer, this size variable is an input value argument provided to pushData by dw, as opposed to the size pointer variable that is an output argument to be set during readRawData.

[VickNV]

Please check if your dwSensorPlugin_createHandle() implementation has returned correct properties->packetSize.Thanks.