Message decode issue with VLP16

[XinyuC]

We are using the velodyne_decoder to decode the velodyne_packets topic obtained from the VLP16 Lidar. Previously, I was using version 2.3.0 or 2.0.0, and for each scan, I would usually get an array of N-by-6. Today I installed the latest 3.0.0 version, and although I still get an N-by-8 array, I found that each row contains the same values, which seems to indicate an error after the update. For the same bag file, version 2.3.0 gives me the correct results. However, it is obvious that version 3.0.0 is easier to use, and I hope this error can be fixed.

[valgur]

Interesting. I have used version 3.0.0 without issues so far.
I would like to investigate this. Would it be possible for you to share a small slice of data? A couple of scans should be sufficient.

[XinyuC]

Sure, I am willing to share some data with you. Unfortunately, the bag files I have right now are too big to use. I am going to collect some small data and share with you today afternoon. The image shown below is the output points generated with 3.0.0

[XinyuC]

Hi Martin, the attached bag file contains the /velodyne_packets topic, I think it can be used for testing. I forgot to mention earlier when I used the 3.0.0, I was set model=vd.Model.VLP16, it showed that the model was incorrect, then I changed to vd.Model.PuckHiRes to fix the error. I am not sure whether this setting results in identical data points in one scan. Please let me know if you need more data, thank you.

test_bag.zip

[valgur]

Thanks! The bag you shared contains already decoded point clouds as sensor_msgs/PointCloud2, though. Would it be possible to share the actual data you are feeding into velodyne_decoder?
Also, can you please share a snippet of the code you are using for decoding? I assume you are using vd.read_bag(<bag>)?
I would recommend leaving the model config parameter unset in v3. Filling it has basically no benefit unless you are using HDL-64, where that info is not available from the data.

[XinyuC]

Hi Martin, I am sorry I didn't realize the previous bag file doesn't contain the raw Velodyne data packets (velodyne_msgs/VelodyneScan). I have attached another bag file that contains velodyne_packets topic and the scripts we used to parse the bag file. The bag file may contain other topics from different sensors. Please let me know if you have any questions or concerns.
Bag file and parse function.zip

[valgur]

I tested the bag with:

import velodyne_decoder as vd
from rosbag import Bag

bag = Bag("mapping_van_2024-06-28-12-30-32_0.bag")
scans = list(vd.read_bag(bag, topics=["/velodyne_packets"]))

print("Number of points in each scan:")
print([len(scan.points) for scan in scans])
t0 = scans[0].stamp.device
print("Relative device timestamp of each scan:")
print([round(scan.stamp.device - t0, 3) for scan in scans])

Which prints:

Number of points in each scan:
[15024, 15036, 15031, 15021, 15042, 15031, 15039, 15029, 15029, 15031, 15024, 15026, 15020, 15028, 15045, 15033, 15030, 15021, 15035, 15038, 15037, 15023, 15022, 15038, 15031, 15019, 15043, 15019, 15028, 15024, 15035, 15029, 15020, 15028, 15043, 15054, 15066, 15075, 15125, 15146, 15187, 15189, 15215, 15254, 15280, 15284, 15283, 15286, 15272, 15276, 15272, 15279, 15283, 15280, 15275, 15277, 15267, 15285, 15275, 15276, 15271, 15269, 15272, 15287, 15286, 15272, 15278, 15266, 15273, 15278, 15284, 15279, 15282, 15278, 15272, 15281, 15279, 15275, 15270, 15279, 15275, 15286, 15276, 15273, 15268, 15268]
Relative device timestamp of each scan:
[0.0, 0.101, 0.202, 0.303, 0.403, 0.504, 0.605, 0.706, 0.807, 0.908, 1.009, 1.109, 1.21, 1.311, 1.412, 1.513, 1.614, 1.715, 1.815, 1.916, 2.017, 2.118, 2.219, 2.32, 2.421, 2.521, 2.622, 2.723, 2.824, 2.925, 3.026, 3.127, 3.228, 3.328, 3.429, 3.53, 3.631, 3.732, 3.833, 3.934, 4.034, 4.135, 4.236, 4.337, 4.438, 4.539, 4.64, 4.74, 4.841, 4.942, 5.043, 5.144, 5.245, 5.346, 5.446, 5.547, 5.648, 5.749, 5.85, 5.951, 6.052, 6.152, 6.253, 6.354, 6.455, 6.556, 6.657, 6.758, 6.858, 6.959, 7.06, 7.161, 7.262, 7.363, 7.464, 7.564, 7.665, 7.766, 7.867, 7.968, 8.069, 8.17, 8.271, 8.371, 8.472, 8.573]

So the decoded clouds are distinct and I could not reproduce the issue.

My guess would be that there's some kind of logic error in your code. I did not notice anything glaringly wrong in the shared code, except for setting and using config = vd.Config(model = "VLP-16", rpm = 600). It's both unnecessary with the latest version and the string value being passed to model would raise an error with the latest version as well. Are you sure you are using the latest v3.0.0 from pip?

[valgur]

Closing as likely not a library bug, but feel free to follow up with any comments or questions if you have any.

[iabdulhafiz]

I had the same issue when using this library to read pcap files from a VLP-32C.
The workarround for me was to set as_pcl_structs=True which would avoid the duplicate messages.

[XinyuC]

Thank you for your reply, I set 'as_pcl_structs=True` and it works.

I had the same issue when using this library to read pcap files from a VLP-32C. The workarround for me was to set as_pcl_structs=True which would avoid the duplicate messages.

Hi, Marting, I am not sure whether you compared the differences between the two versions. The results I got from version 3.0.0 are different from version 2.3.0. The following two images respectively show the results of the same scan obtained from the two versions, it can be noticed that although the parsed points are closed, there still exists offsets between them. We are using a VLP-16 Hi-Res LiDAR, and using 'config = vd.Config(model = "VLP-16", rpm = 600)' in version 2.3.0, while leaving the config setting empty in the latest version. Is this setting the cause of the different results? Thank you!

[valgur]

I tried to reproduce the duplicated point clouds issue in the test suite and did not encounter the issue there: #17.

@XinyuC The correct model ID for v2.3.0 would have been PuckHiRes rather than VLP-16. Their vertical angles are quite different. On top of that, v3.0.0 includes several small improvements to timing and beam angle calculations which will cause small differences in point coordinates between v2 and v3.

[XinyuC]

We tried v2.3.0 with 'PuckHiRes', but it showed an unsupported velodyne model error, I think that was why we used 'VLP-16' before. We have upgraded to the latest version v3.0.0, it works pretty well and we didn't see any issues. Thank you for your help and quick response.