Unable to view recorded lidar data

Autonomous Vehicles DRIVE AGX Orin DRIVE AGX Orin General
1

Please provide the following info (tick the boxes after creating this topic):
Software Version
DRIVE OS 6.0.10.0
DRIVE OS 6.0.8.1
DRIVE OS 6.0.6
DRIVE OS 6.0.5
DRIVE OS 6.0.4 (rev. 1)
DRIVE OS 6.0.4 SDK
other

Target Operating System
Linux
QNX
other

Hardware Platform
DRIVE AGX Orin Developer Kit (940-63710-0010-300)
DRIVE AGX Orin Developer Kit (940-63710-0010-200)
DRIVE AGX Orin Developer Kit (940-63710-0010-100)
DRIVE AGX Orin Developer Kit (940-63710-0010-D00)
DRIVE AGX Orin Developer Kit (940-63710-0010-C00)
DRIVE AGX Orin Developer Kit (not sure its number)
other

SDK Manager Version
2.1.0
other

Host Machine Version
native Ubuntu Linux 20.04 Host installed with SDK Manager
native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
native Ubuntu Linux 18.04 Host installed with DRIVE OS Docker Containers
other

Issue Description

We have been testing the LiDAR replay functionality using the VLP-16 and VLP-16 HR sensors. While data recording appears to complete successfully, we encounter errors when attempting to replay the recorded data.

Data Recording Command:

./sample_lidar_replay --protocol=lidar.socket --params=device=VELO_VLP16,ip=192.168.2.201,scan-frequency=10,port=2368 --show-intensity=true --output-dir=/lidar_data

Replay Command:

./sample_lidar_replay --protocol=lidar.virtual --params=file=/usr/local/lidar_puck/1751899524244960.bin

Error String

[08-07-2025 12:41:37] Driveworks exception thrown: DW_INVALID_ARGUMENT: Demuxer: no matching demuxer for file type

terminate called after throwing an instance of 'std::runtime_error'
  what():  [2025-07-08 12:41:37] DW Error DW_INVALID_ARGUMENT executing DW function:
 dwSAL_createSensor(&m_lidarSensor, params, m_sal)
 at samples/sensors/lidar/lidar_replay/main.cpp:149

Logs

root@6.0.10.0-0009-build-linux-sdk:/usr/local/driveworks/bin# ./sample_lidar_replay --protocol=lidar.virtual --params=file=/usr/local/lidar_puck/1751899524244960.bin
ProgramArguments: Missing argument 'dwTracePath' requested
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to create bus connection: Host is down
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to create bus connection: Host is down
Starting my sample application...
[08-07-2025 12:41:37] Platform: Detected Generic x86 Platform
[08-07-2025 12:41:37] Adding variable DW_Base:DW_Version
[08-07-2025 12:41:37] Added variable DW_Base:DW_Version
[08-07-2025 12:41:37] Platform: number of GPU devices detected 1
[08-07-2025 12:41:37] Platform: currently selected GPU device 0, Resource Data Dir: trt_08_06_12_04, Arch: ga1xx-discrete
[08-07-2025 12:41:37] Platform: currently selected GPU device discrete ID 0
[08-07-2025 12:41:37] Context::mountResourceCandidateDataPath resource FAILED to mount from './resources': VirtualFileSystem: Failed to mount './resources/resources.pak'
[08-07-2025 12:41:37] Context::mountResourceCandidateDataPath resource FAILED to mount from '/usr/local/driveworks-5.20/bin/data': VirtualFileSystem: Failed to mount '/usr/local/driveworks-5.20/bin/data/resources.pak'
[08-07-2025 12:41:37] Context::findDataRootInPathWalk data/DATA_ROOT found at: /usr/local/driveworks-5.20/bin/../data
[08-07-2025 12:41:37] Context::mountResourceCandidateDataPath resource FAILED to mount from '/usr/local/driveworks-5.20/bin/../data': VirtualFileSystem: Failed to mount '/usr/local/driveworks-5.20/bin/../data/resources.pak'
[08-07-2025 12:41:37] Context::findDataRootInPathWalk data/DATA_ROOT found at: /usr/local/driveworks-5.20/data
[08-07-2025 12:41:37] Context::mountResourceCandidateDataPath resource FAILED to mount from '/usr/local/driveworks-5.20/data': VirtualFileSystem: Failed to mount '/usr/local/driveworks-5.20/data/resources.pak'
[08-07-2025 12:41:37] Context::findResourcesPackageInPathWalk: Could not find ./resources/resources.pak in upto 7 parent directories from /usr/local/driveworks-5.20/bin/../lib/libdw_base.so.5.20
[08-07-2025 12:41:37] Context::findResourcesPackageInPathWalk: Could not find ./resources/resources.pak in upto 7 parent directories from /usr/local/driveworks-5.20/targets/x86_64-Linux/lib/libdw_base.so.5.20
[08-07-2025 12:41:37] SDK: No resources(.pak) mounted, some modules will not function properly
[08-07-2025 12:41:37] [08-07-2025 12:41:37] Initialize DriveWorks SDK v5.20.24
[08-07-2025 12:41:37] [08-07-2025 12:41:37] Release build with GNU 9.3.0 from buildbrain-branch-0-gb4c0b405b15
[08-07-2025 12:41:37] SensorFactory::loadPluginLibraryHelper:Succeed to load dynamic lib - /usr/local/driveworks-5.20/bin/../lib/libsensor_plugin_public_radar.so
[08-07-2025 12:41:37] SensorFactory::createSensor() -> lidar.virtual, file=/usr/local/lidar_puck/1751899524244960.bin
[08-07-2025 12:41:37] Found driver: lidar.virtual
[08-07-2025 12:41:37] Driveworks exception thrown: DW_INVALID_ARGUMENT: Demuxer: no matching demuxer for file type

terminate called after throwing an instance of 'std::runtime_error'
  what():  [2025-07-08 12:41:37] DW Error DW_INVALID_ARGUMENT executing DW function:
 dwSAL_createSensor(&m_lidarSensor, params, m_sal)
 at samples/sensors/lidar/lidar_replay/main.cpp:149
2

@SivaRamaKrishnaNV I also tried running the postrecorder check tool on the folder containing the lidar sweeps DriveWorks SDK Reference: Post-record Checker and it generated a post-record-check.json file

post-record-check.json:

{
    "version": "0.0",
    "aux_info_warnings": [],
    "aux_info_errors": [
        "[/usr/local/lidar_puck] missing an aux_info file",
        "[/usr/local/lidar_puck] missing the virtual recorder config file"
    ],
    "config_warnings": [],
    "config_errors": [],
    "sensors": []
}

Logs

root@6.0.10.0-0009-build-linux-sdk:/usr/local/driveworks/tools/capture# ./postrecord-checker --recording_session=/usr/local/lidar_puck --sensor=lidar --output=/usr/local/driveworks/samples/
Postrecord-Checker [Version: 0.0]
[08-07-2025 13:10:03] Platform: Detected Generic x86 Platform
[08-07-2025 13:10:03] Adding variable DW_Base:DW_Version
[08-07-2025 13:10:03] Added variable DW_Base:DW_Version
[08-07-2025 13:10:03] Platform: number of GPU devices detected 1
[08-07-2025 13:10:03] Platform: currently selected GPU device 0, Resource Data Dir: trt_08_06_12_04, Arch: ga1xx-discrete
[08-07-2025 13:10:03] Platform: currently selected GPU device discrete ID 0
[08-07-2025 13:10:03] Context::mountResourceCandidateDataPath resource FAILED to mount from './resources': VirtualFileSystem: Failed to mount './resources/resources.pak'
[08-07-2025 13:10:03] Context::mountResourceCandidateDataPath resource FAILED to mount from '/usr/local/driveworks-5.20/tools/capture/data': VirtualFileSystem: Failed to mount '/usr/local/driveworks-5.20/tools/capture/data/resources.pak'
[08-07-2025 13:10:03] Context::findDataRootInPathWalk data/DATA_ROOT found at: /usr/local/driveworks-5.20/tools/capture/../../data
[08-07-2025 13:10:03] Context::mountResourceCandidateDataPath resource FAILED to mount from '/usr/local/driveworks-5.20/tools/capture/../../data': VirtualFileSystem: Failed to mount '/usr/local/driveworks-5.20/tools/capture/../../data/resources.pak'
[08-07-2025 13:10:03] Context::findDataRootInPathWalk data/DATA_ROOT found at: /usr/local/driveworks-5.20/data
[08-07-2025 13:10:03] Context::mountResourceCandidateDataPath resource FAILED to mount from '/usr/local/driveworks-5.20/data': VirtualFileSystem: Failed to mount '/usr/local/driveworks-5.20/data/resources.pak'
[08-07-2025 13:10:03] Context::findResourcesPackageInPathWalk: Could not find ./resources/resources.pak in upto 7 parent directories from /usr/local/driveworks-5.20/tools/capture/../../targets/x86_64-Linux/lib/libdw_base.so.5.20
[08-07-2025 13:10:03] Context::findResourcesPackageInPathWalk: Could not find ./resources/resources.pak in upto 7 parent directories from /usr/local/driveworks-5.20/targets/x86_64-Linux/lib/libdw_base.so.5.20
[08-07-2025 13:10:03] SDK: No resources(.pak) mounted, some modules will not function properly
[08-07-2025 13:10:03] [08-07-2025 13:10:03] Initialize DriveWorks SDK v5.20.24
[08-07-2025 13:10:03] [08-07-2025 13:10:03] Release build with GNU 9.3.0 from buildbrain-branch-0-gb4c0b405b15
[08-07-2025 13:10:03] SensorFactory::loadPluginLibraryHelper:Succeed to load dynamic lib - /usr/local/driveworks-5.20/tools/capture/../../targets/x86_64-Linux/lib/libsensor_plugin_public_radar.so
Postrecord-Checker: [INFO]: finish initialize checker
Postrecord-Checker: [INFO]: finish validating meta info
Postrecord-Checker: [INFO]: finish sensor timestamp analysis
[08-07-2025 13:10:03] [08-07-2025 13:10:03] Releasing Driveworks SDK Context
Postrecord-Checker: [INFO]: stop checker```
4

Is it using the same lidar used in VLP-16HR device is provided with lidar.socket, however Driveworks is rejecting it ?

5

We are using the same patch you provided earlier(x86 host). The sample_lidar_replay was run with that patch using the Velodyne VLP-16 (basic puck) sensor.

Initially, we followed the sample_lidar_replay usage instructions expecting that it would generate .bin file that could then be replayed using the same sample_lidar_replay tool. However, the .bin files generated this way failed during replay with a demuxer error, as detailed in the logs shared.

While exploring alternative recording/visualization tools in DriveWorks, we came across the documentation here:
DriveWorks SDK Reference: Basic Recording

Using this recording method (recorder tool), we were able to generate a singlelidar_front.bin and lidar_front.bin.seek, and when using them with the same sample_lidar_replay tool, the recorded LiDAR data was visualised correctly.

data visualisation on the .bin files generated by recorder tool

./sample_lidar_replay --protocol=lidar.virtual --params=file=/usr/local/driveworks/tools/capture/lidar_front.bin

From our understanding, the documentation and the sample_lidar_replay usage suggest that it should be possible to record live data and then replay it using the same tool. However, based on our results, this doesn’t seem to work unless we use the dedicated recording tool. Let me know if this is not the expected behavior for the sample lidar replay for recording and replay.

I also did hexdump for .bin file captured using the 2 ways:

One of the bin file generated from using sample lidar replay:

root@6.0.10.0-0009-build-linux-sdk:/usr/local/lidar_puck# hexdump -C /usr/local/lidar_puck/1751899524244960.bin | head -20
00000000  77 a1 dd 3d 99 60 3a bf  12 f4 49 be 81 80 80 3c  |w..=.`:...I....<|
00000010  d0 8b 57 40 b5 42 b5 c1  20 b7 cc 3e c2 c0 c0 3c  |..W@.B.. ..>...<|
00000020  22 54 e1 3d af 7c 3d bf  a1 e8 30 be 81 80 80 3c  |"T.=.|=...0....<|
00000030  98 75 2f 40 d6 8c 93 c1  e6 2a 7a 3f 89 88 88 3d  |.u/@.....*z?...=|
00000040  72 5b 0f 3e cb 1b 71 bf  da 86 3d be c2 c0 40 3c  |r[.>..q...=...@<|
00000050  49 c2 53 40 66 13 b2 c1  37 03 fc 3f c2 c0 c0 3c  |I.S@f...7..?...<|
00000060  98 f9 17 3e 41 9a 7f bf  8c b6 23 be 81 80 80 3b  |...>A.....#....;|
00000070  b4 f7 b1 40 cf a8 15 c2  43 9f 94 40 95 94 14 3e  |...@....C..@...>|
00000080  55 93 3f 3e 52 1a a1 bf  77 fc 1f be c2 c0 c0 3c  |U.?>R...w......<|
00000090  c1 2f c9 40 61 2f 29 c2  c0 b9 d8 40 91 90 10 3d  |./.@a/)....@...=|
000000a0  ab 48 19 3e e7 e6 80 bf  fe 6b b6 bd a1 a0 20 3d  |.H.>.....k.... =|
000000b0  b9 a7 25 40 32 4e 8b c1  88 01 5b 40 e2 e0 60 3d  |..%@2N....[@..`=|
000000c0  9d 0e 19 3e 15 b6 80 bf  0a 3a 5a bd 81 80 00 3c  |...>.....:Z....<|
000000d0  a0 f1 b3 40 42 52 17 c2  c7 46 0d 41 85 84 04 3e  |...@BR...F.A...>|
000000e0  18 09 51 40 1a c9 af c1  29 88 c6 be da d8 d8 3d  |..Q@....)......=|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  b4 9b d1 3d 89 99 34 bf  b9 97 43 be 81 80 80 3c  |...=..4...C....<|
00000110  e4 4b 50 40 33 78 b3 c1  b2 96 ca 3e c2 c0 40 3c  |.KP@3x.....>..@<|
00000120  8a 2e dd 3d 55 92 3e bf  82 d4 31 be 81 80 80 3c  |...=U.>...1....<|
00000130  d2 22 2b 40 ad 73 93 c1  71 df 79 3f d2 d0 50 3d  |."+@.s..q.y?..P=|

Bin file generated from using recorder tool

root@6.0.10.0-0009-build-linux-sdk:/usr/local/driveworks/tools/capture# hexdump -C lidar_front.bin | head -20
00000000  00 ee ff ca 06 00 00 00  05 00 00 00 14 00 00 00  |................|
00000010  18 00 00 00 62 34 63 30  62 34 30 35 62 31 35 00  |....b4c0b405b15.|
00000020  69 70 3d 31 39 32 2e 31  36 38 2e 32 2e 32 30 31  |ip=192.168.2.201|
00000030  2c 70 6f 72 74 3d 32 33  36 38 2c 64 65 76 69 63  |,port=2368,devic|
00000040  65 3d 56 45 4c 4f 5f 56  4c 50 31 36 2c 20 73 63  |e=VELO_VLP16, sc|
00000050  61 6e 2d 66 72 65 71 75  65 6e 63 79 3d 31 30 00  |an-frequency=10.|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000940  69 70 3d 31 39 32 2e 31  36 38 2e 32 2e 32 30 31  |ip=192.168.2.201|
00000950  2c 70 6f 72 74 3d 32 33  36 38 2c 64 65 76 69 63  |,port=2368,devic|
00000960  65 3d 56 45 4c 4f 5f 56  4c 50 31 36 2c 20 73 63  |e=VELO_VLP16, sc|
00000970  61 6e 2d 66 72 65 71 75  65 6e 63 79 3d 31 30 00  |an-frequency=10.|
00000980  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001140  3f 00 00 00 00 00 00 00  b6 04 00 00 4c 2d 15 63  |?...........L-.c|
00001150  6b 39 06 00 ff ee cc 2b  7f 08 14 a9 05 03 93 08  |k9.....+........|
00001160  47 08 06 05 5e 04 1f 1e  0a 47 71 04 18 36 0a 5a  |G...^....Gq..6.Z|
00001170  46 05 0f 4b 0a 47 35 05  21 66 0a 39 66 05 0b 95  |F..K.G5.!f.9f...|
00001180  0a 32 7e 05 0a b4 0a 39  6e 08 14 fc 09 0c 82 08  |.2~....9n.......|
00001190  4b fc 05 03 5c 04 21 10  0a 38 79 04 18 1e 0a 56  |K...\.!..8y....V|
1 Like
6

The patch just to bypass the encountered error. Did you test live lidar point cloud data using sample_lidar_replay?
Recorder tool or sample_record is used to record lidar data and lidar replay is used to display recorded or live sensor data.

7

Yes, I did test live LiDAR point cloud data using sample_lidar_replay, and it correctly visualizes the data from the Velodyne VLP-16 sensor in real-time.

However, referring to the official DriveWorks documentation for sample_lidar_replay, it specifically mentions:

--output-dir=[path/to/output/dir]
    Specifies the output directory, where stores lidar point cloud dumps.
    Default value: none

When I use this flag while running sample_lidar_replay on live data, it generates multiple .bin files with timestamped names (e.g., 1751899524244960.bin). This suggests that the sample is recording individual sweeps.

However, when I later try to replay these .bin sweep files using the same sample_lidar_replay with:

/sample_lidar_replay --protocol=lidar.virtual --params=file=<timestamped_bin_file>

Im getting error:

DW_INVALID_ARGUMENT: Demuxer: no matching demuxer for file type

However, the recorder generates a single .bin file showing lidar data for the entire recording session.
How can I capture and later replay individual LiDAR sweeps, instead of recording an entire session using the recorder tool? Is there any supported method within DriveWorks SDK to record a single sweep at a time in a format that is replayable using sample_lidar_replay?

8

@SivaRamaKrishnaNV Are the sample algorithms like sample_pointcloudprocessing, sample_icp expected to run on custom recorded data from supported sensors (recorded via basic recording tool)?

9

We don’t have tool/ samples for this

10

I notice in the sample description “The sample fuses point clouds from two [VELO_HDL32E] recordings and one [VELO_HDL64E] recording.
The sample only supports recorded data as input. It does not support live data. Recordings from other types of Lidars are not guaranteed to work.”

Do you see any issue with your lidars?

11

so what purpose does the --output-dir parameter for sample_lidar_replay serve? It does save recordings in sequential timestamps in bin files. How can we investigate these recordings?

12

does this mean that during any application in runtime SAL calls fed with protocol (lidar.socket) and its associated params related to VELO_VLP16HR we must expect a driver DecoderVelodyne error again?

13

It stores the pointcloud data in a binary file. The same point cloud data is rendered using dwRenderEngine.
Can you check capturing the accumulatedPoints for each file in dumpLidarFrame(). This info can be used to fill the m_pointCloud buffer back and can be used in the dwRenderEngine_setBuffer(). Can you check if this works for your case?

1 Like