Xsens IMU framerate plunges when serialization starts

Autonomous Vehicles DRIVE AGX Xavier DRIVE AGX Xavier General
1

Hardware Platform: DRIVE AGX Xavier™ Developer Kit
Software Version: DRIVE Software 10
Running on the platform
Host Machine Version: Ubuntu 18.04

Hi, I have configured an Xsens imu to run at 100HZ. Everything runs fine without serialization. However, when I start serialization, the frame rate plunges from 100HZ to ~20 HZ. I found that dwSensor_readRawData and dwSensorIMU_processRawData return DW_NOT_READY much more often when serialization is enabled. Following is my configuration:

for sensor handle:
.parameters = device=/dev/ttyUSB0,frequency=100
.protocol = imu.xsens

for serializer handle:
.parameters = type=disk,file=/some/aribitrary/path

2

Dear @ylin1,
Could you provide a simple repro code and steps to reproduce on our side?

4

Hi @SivaRamaKrishnaNV,

Sorry for the late reply, please see the file attached. It should be able to be compiled into a standalone executable:

xsens_serialize_repro.cpp (3.3 KB)

5

Dear @ylin1,
Thank you for providing repro code. I will check internally and get back you.

Did you check recording using our recorder tool and noticed the same? If not, can you check and provide feedback.

Also, can you please share your connection details and output log for checking.

7

Yes, I have tried the sample recorder tool. However the terminal outputs are throttled at 10HZ so I can’t troubleshoot by looking at the terminal output. Are there easy ways for me to inspect the recorded file?

Connection details
Xsens MTi 710: USB cable plugged in USB3-XA1
.parameters = device=/dev/ttyUSB0,frequency=100
.protocol = imu.xsens

Repro sample output:
poll took longer than expected: 49865 us (expected < 10000)
accel [0.063, -0.056, 9.802]
poll took longer than expected: 46360 us (expected < 10000)
accel [0.083, -0.060, 9.804]
poll took longer than expected: 93534 us (expected < 10000)
accel [0.065, -0.045, 9.799]
poll took longer than expected: 49972 us (expected < 10000)
accel [0.082, -0.039, 9.799]
poll took longer than expected: 49947 us (expected < 10000)
accel [0.053, -0.050, 9.805]
poll took longer than expected: 49942 us (expected < 10000)
accel [0.067, -0.048, 9.803]
poll took longer than expected: 39884 us (expected < 10000)
accel [0.066, -0.039, 9.796]
poll took longer than expected: 49984 us (expected < 10000)
accel [0.074, -0.048, 9.803]
poll took longer than expected: 49915 us (expected < 10000)
accel [0.074, -0.048, 9.803]
poll took longer than expected: 49959 us (expected < 10000)
accel [0.074, -0.039, 9.796]
poll took longer than expected: 49933 us (expected < 10000)
accel [0.066, -0.043, 9.800]
poll took longer than expected: 39940 us (expected < 10000)
accel [0.064, -0.052, 9.799]
poll took longer than expected: 49908 us (expected < 10000)
accel [0.087, -0.032, 9.793]
poll took longer than expected: 49956 us (expected < 10000)
accel [0.059, -0.046, 9.807]
^Cpoll took longer than expected: 49977 us (expected < 10000)
accel [0.062, -0.048, 9.808]
[07-10-2020 13:07:17] IndexTable: saving to file “/home/nvidia/xsens.bin.seek”
[07-10-2020 13:07:17] EndpointXsens: stopped for device /dev/ttyUSB0
[07-10-2020 13:07:17] Sensor statistics for: imu.xsens, device=/dev/ttyUSB0,frequency=100
[07-10-2020 13:07:17] Events: 0
Errors: 0
Drops: 0
minDelta: 0.0000000
maxDelta: 19924.0000000
meanDelta: 9576.407227
Standard deviation: 1711.890991
[07-10-2020 13:07:17] Releasing Driveworks SDK Context
[07-10-2020 13:07:17] SDK: Release NvMediaDevice
[07-10-2020 13:07:17] SDK: Release NvMedia2D

Sample output when commenting out lines related to serialization (L60, 61, 83)
accel [0.116, 0.057, 9.809]
accel [0.114, 0.065, 9.792]
accel [0.107, 0.072, 9.799]
accel [0.096, 0.056, 9.796]
accel [0.118, 0.053, 9.801]
accel [0.106, 0.064, 9.791]
accel [0.101, 0.066, 9.796]
accel [0.107, 0.063, 9.809]
poll took longer than expected: 10019 us (expected < 10000)
accel [0.112, 0.069, 9.803]
accel [0.115, 0.068, 9.808]
accel [0.122, 0.070, 9.819]
accel [0.125, 0.083, 9.788]
poll took longer than expected: 10018 us (expected < 10000)
accel [0.106, 0.065, 9.801]
accel [0.109, 0.069, 9.803]
accel [0.112, 0.056, 9.802]
accel [0.099, 0.046, 9.796]
accel [0.099, 0.055, 9.799]
accel [0.109, 0.057, 9.799]
accel [0.113, 0.053, 9.803]
accel [0.115, 0.059, 9.786]
poll took longer than expected: 13779 us (expected < 10000)
accel [0.121, 0.075, 9.793]
accel [0.111, 0.074, 9.794]
accel [0.110, 0.064, 9.807]
accel [0.118, 0.075, 9.801]
accel [0.115, 0.064, 9.812]
accel [0.120, 0.074, 9.795]
^Caccel [0.102, 0.067, 9.800]
[07-10-2020 13:15:30] Driveworks exception thrown: DW_INVALID_HANDLE: Cannot cast to C handle, given instance is a nullptr, type=P24dwSensorSerializerObject

[07-10-2020 13:15:30] Driveworks exception thrown: DW_INVALID_HANDLE: Cannot cast to C handle, given instance is a nullptr, type=P24dwSensorSerializerObject

[07-10-2020 13:15:30] EndpointXsens: stopped for device /dev/ttyUSB0
[07-10-2020 13:15:30] Sensor statistics for: imu.xsens, device=/dev/ttyUSB0,frequency=100
[07-10-2020 13:15:30] Events: 0
Errors: 0
Drops: 0
minDelta: 0.0000000
maxDelta: 19923.0000000
meanDelta: 9580.421875
Standard deviation: 1620.147095
[07-10-2020 13:15:30] Releasing Driveworks SDK Context
[07-10-2020 13:15:30] SDK: Release NvMediaDevice
[07-10-2020 13:15:30] SDK: Release NvMedia2D

8

Dear @ylin1,
We could reproduce the issue and filed bug internally to fix it. I will update you on the status.

9

Thank you. Looking forward to the updates

10

Dear @ylin1,
Thank you for your patience. We have fixed the bug and is available in next DRIVE SW release. The next release is tentatively in December.

Apart from this issue, I could see the code snippet uses dwSensorIMU_popFrame() call only once. It is expected to call as many times as possible (until the call doesn’t return DW_SUCCESS).

1 Like
12

@SivaRamaKrishnaNV
Thanks for the update and advise for popFrame(). I just want to follow up to verify that the bugfix is in the new release. Would the release version I need be DriveOS 5.2.0 and Driveworks 3.5? I did not see this in the “fixed issues” section in the release note.

13

Dear @ylin1,
Would the release version I need be DriveOS 5.2.0 and Driveworks 3.5?

Yes. Could you check with that?

1 Like
14

Sorry for getting back late. We checked, and yes the issue is indeed fixed. Thank you

1 Like