VLP-16HR device is provided with lidar.socket, however Driveworks is rejecting it

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
why does the latest driveworks even doesn’t support the device? protocol specifies a device id to be 0x22, while VeloView, webinterface and wireshark can evidence the presence on the Lidar on network.

Ive got both VELO_VLP16 and VELO_VPL16HR, why such discrepancy?

image
image875×706 81.4 KB

Error String

root@6.0.10.0-0009-build-linux-sdk:/usr/local/driveworks/bin# ./sample_lidar_replay --protocol=lidar.socket --params=device=VELO_VLP16HR,ip=192.168.2.202,port=2368,scan-frequency=10,decoder-path=./libsample_nv_lidar_plugin.so --show-intensity=true
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...
[16-05-2025 15:57:30] Platform: Detected Generic x86 Platform
[16-05-2025 15:57:30] Adding variable DW_Base:DW_Version
[16-05-2025 15:57:30] Added variable DW_Base:DW_Version
[16-05-2025 15:57:30] Platform: number of GPU devices detected 1
[16-05-2025 15:57:30] Platform: currently selected GPU device 0, Resource Data Dir: trt_08_06_12_04, Arch: ga1xx-discrete
[16-05-2025 15:57:30] Platform: currently selected GPU device discrete ID 0
[16-05-2025 15:57:30] Context::mountResourceCandidateDataPath resource FAILED to mount from './resources': VirtualFileSystem: Failed to mount './resources/resources.pak'
[16-05-2025 15:57:30] 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'
[16-05-2025 15:57:30] Context::findDataRootInPathWalk data/DATA_ROOT found at: /usr/local/driveworks-5.20/bin/../data
[16-05-2025 15:57:30] 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'
[16-05-2025 15:57:30] Context::findDataRootInPathWalk data/DATA_ROOT found at: /usr/local/driveworks-5.20/data
[16-05-2025 15:57:30] 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'
[16-05-2025 15:57:30] 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
[16-05-2025 15:57:30] 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
[16-05-2025 15:57:30] SDK: No resources(.pak) mounted, some modules will not function properly
[16-05-2025 15:57:30] [16-05-2025 15:57:30] Initialize DriveWorks SDK v5.20.24
[16-05-2025 15:57:30] [16-05-2025 15:57:30] Release build with GNU 9.3.0 from buildbrain-branch-0-gb4c0b405b15
[16-05-2025 15:57:30] SensorFactory::loadPluginLibraryHelper:Succeed to load dynamic lib - /usr/local/driveworks-5.20/bin/../lib/libsensor_plugin_public_radar.so
[16-05-2025 15:57:30] SensorFactory::createSensor() -> lidar.socket, device=VELO_VLP16HR,ip=192.168.2.202,port=2368,scan-frequency=10,decoder-path=./libsample_nv_lidar_plugin.so
[16-05-2025 15:57:30] Found driver: lidar.socket
[16-05-2025 15:57:30] LidarSocket::getParameters, return-mode not specified. Using default value 2
[16-05-2025 15:57:30] hfov-start is empty, default value 0 will be used
[16-05-2025 15:57:30] hfov-end is empty, default value 360 will be used
[16-05-2025 15:57:30] Destination IP address, Horizontal Resolution is used only by OUSTER and Hesai Lidars
[16-05-2025 15:57:30] Return Mode is used only by Velodyne and Hesai Lidars
[16-05-2025 15:57:30] Horizontal FOV is used only by Ouster, Velodyne and Hesai Lidars
[16-05-2025 15:57:30] Driveworks exception thrown: DW_FAILURE: DecoderVelodyne::processStatus, device type does not match product ID 0x22

terminate called after throwing an instance of 'std::runtime_error'
  what():  [2025-05-16 15:57:30] DW Error DW_FAILURE executing DW function:
 dwSAL_createSensor(&m_lidarSensor, params, m_sal)
 at samples/sensors/lidar/lidar_replay/main.cpp:149
Aborted (core dumped)
root@6.0.10.0-0009-build-linux-sdk:/usr/local/driveworks/bin#

I found similar query threads Lidar Connection to Nvidia Drive AGX - #13 by hitesh.pandya1
any status on this yet? : Cannot record LiDAR(VLP16-HiRes) - device type does not match product ID 0x22 - #8 by SivaRamaKrishnaNV

3

@SivaRamaKrishnaNV may I get to know where can I find the source code for the DecoderVelodyne class in logs?

4

Dear @ashwin.nanda ,
Do you see same error with both velodyne lidars? I don’t see VLP 16 HR in supported list at DRIVE AGX Orin Sensors & Accessories | NVIDIA Developer

5

hi @SivaRamaKrishnaNV looking at the previous threaeds, seems like the sensor was supported before and an upgrade to the sensor drivers was promised, however the sensor is dropped from the supported list.

which is why I am asking the source for DecoderVelodyne class here.

socket protocol works for vlp-16 only.

6

Hi @ashwin.nanda ,
The decoder velodyne source code is not publicly available. I could see the issue is because the expected/supported product ID is 0x22. I see we support VLP 16 HR M12 model as per DRIVE AGX Xavier Sensors & Accessories | NVIDIA Developer

7

Exactly my point, wireshark sniff suggests device id to be 0x24. And therefore I asked for the source code.

8

@SivaRamaKrishnaNV to elaborate on the issue, please refer these sensor enumerations in the samples :

lidar.socket mentions VELO_VLP16HR
Sensor [19] : lidar.socket ? ip=X.X.X.X,port=XXXX,device={VELO_VLP16, VELO_VLP16HR, VELO_HDL32E,VELO_VLP32C, VELO_HDL64E, VELO_VLS128, LUMINAR_H, CUSTOM},scan-frequency=XX.X[,protocol=xxx,multicast-ip=X.X.X.X,decoder=filepath.so,time-smoothing=false]

9

Dear @ashwin.nanda ,
I could see the legacy code support velodyne vlp16 HR devices with product ID 0x22(with VELO_VLP16HR flag). As clarified previously we support only VLP 16 HR M12 model. As your model product ID is 0x24, it is not supported by default.

10

@SivaRamaKrishnaNV I would need a bit more clarification on this, I intend to use the Lidar anyways, can you point out what was the difference in the Lidar data packets if there was so? I intend to spend minimal reverse engineering to use the Lidar. Does sample nv_lidar_plugin.so capable of decoding velodyne packets?

12

Dear @ashwin.nanda,

Are you looking for packet difference between VLP16 HI Res A and VLP 16 HR M12? Can you ask velodyne ?

nv_lidar_plugin.so does not work out of the box. You need to write a new plugin as mentioned at DriveWorks SDK Reference: Lidar Plugin Sample

13

Dear @SivaRamaKrishnaNV my two VLP lidar models are VLP-16-A and VLP-16-Hi-Res-A, I can confirm by looking at the datasheets that the UDP packet data contents are same.

I have attached a proof of the launch of both of the Lidar packets in ROS1 environment is here in rviz, typically just changed namespaces for the publishing two different nodes to visualize both pcds, and hence this means that the point packets are being decoded via the user space loaded ros-neotic-velodyne decoder.

63-9229_Rev-K_Puck-_Datasheet_Web.pdf (317.7 KB)
63-9318_Rev-H_Puck Hi-Res_Datasheet_Print.pdf (342.0 KB)

Below is a composite cluster of point clouds from both lidars, please clarify that whether this proves the data packet integrity to be exactly same?

if so can you now understand the context of the querry?

image
image1499×812 109 KB

Seems like all three sensor models, Puck, Puck Lite and Puck Hi Res, contain similar structured point data. The M12 stands for the connection wire which is similar in the three.

please correct me if I am wrong anywhere.

14

Dear @SivaRamaKrishnaNV based on the above deductions, I was under the impression that if just the DecoderVelodyne class could be altered for its enumeration for VLP-16HR from 0x22 to be 0x24 the decoder could still be loaded with the lidar.socket protocol.

15

These are part of libraries and not a standalone file to share.

17

A patch library provided to bypass the error (
libdw_sensors.so.5.20 (13.2 MB))

21

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.