Organizing point cloud from HDL-32E

Question

Hi there,

in order to accelerate the data processing on my HLD-32E I would like to organized the data. To this point, I could, under Octave, compute manually an point cloud. But I do actually have no idea how to implement it in C++ and the suggested functions, such as KDTree, don't seems to be fast enough for this task...

Is there somewhere a topic giving information about how to work with those Point clouds in ROS?

---

Originally posted by Dexter111 on ROS Answers with karma: 86 on 2013-04-01

Post score: 5

Answer 1

Are you using the ROS velodyne stack to provide the data?

If so, the velodyne_pointcloud package handles converting the raw data packets received from the device into ROS sensor_msgs/PointCloud2 messages. The HDL-32E spews out about 700,000 points per second in a highly permuted order, the HDL-64E provides about 1,000,000 points per second in a very different and less regular order. So, velodyne_pointcloud keeps things simpler by always producing "unordered" point clouds as the data arrive from the device.

To prevent that unordered representation from losing useful information, velodyne_pointcloud publishes its data using a custom PCL point definition: velodyne_pointcloud::PointXYZIR, defined in the velodyne_pointcloud/point_types.h header. A PointXYZIR differs from the standard PCL PointXYZI (X, Y, Z, and intensity) in adding an additional field containing the "laser ring number" from which the point was measured.

Each ring number corresponds to a device-specific laser number, but the numbers are reordered so that ring 0 corresponds to the innermost laser (at the lowest angle) and ring 31 corresponds to the outermost laser (at the highest angle) of a 32E (that would be ring 63 on a 64E). That encoding ensures that adjacent lasers are labelled with adjacent ring numbers, which is not at all true of the hardware laser numbers. The actual mapping is defined in the velodyne_driver/ring_sequence.h header, provided by the velodyne_driver package. The permutation for a 32E is the same as the first 32 lasers of the 64E, so the same conversions work for both.

So, it should theoretically be possible to produce an ordered point cloud from the unordered PointXYZIR data by using the ring numbers as rows in a 2D representation. I have not heard of anyone actually doing that, and I suspect that the results might become somewhat confused when the device is in motion.

---

Originally posted by joq with karma: 25443 on 2013-04-02

This answer was ACCEPTED on the original site

Post score: 10

---

Original comments

Comment by Dexter111 on 2013-07-03:
Sorry for the long delay, but it could finaly organize the pointcloud and now I can segment and classify the point cloud in less than 0.2s ;)

Comment by kamek on 2013-07-18:
@Dexter111 Do you mind describing how you were able to do that? Did you use PCL at all?

Comment by orsonl on 2016-10-23:
Hi. I need the pointcloud from Velodyne VLP16. You mentioned that "velodyne_pointcloud publishes its data using a custom PCL point definition: velodyne_pointcloud::PointXYZIR". Do you mean that is a topic? After I do roslaunch "velodyne_pointclound VLP16_points.launch", nothing like that are found

Comment by orsonl on 2016-10-24:
For Velodyne VLP16, nothing like velodyne_pointcloud::PointXYZIR are published. Please tell me why

Comment by joq on 2016-10-24:
The topic name is /velodyne_points

Comment by claydergc on 2017-05-26:
I don't know if this is still useful for you, but I wrote some code with PCL to organize a VLP16 point cloud and now I have a 16xN point cloud. I am still doing some tests, but you can find my code here: https://github.com/claydergc/vlp16_pointcloud/blob/master/src/vlp16_cloud.cpp

Comment by M@t on 2019-03-07:
@claydergc, did you ever get that code fully functional? I've tried it out but haven't been able to get it working so far.

Answer 2

TL;DR: Use the function I wrote here: organize_velodyne_cloud

I had to solve this problem recently in order to use the cloud for mesh creation with the Point Cloud Library (PCL). At the time I couldn't find anyone else who had solved this problem, so I had to write the code myself following the suggestions here from @joq. I've added to core functions to the repo linked above, as they're a bit too long to put here. Hopefully this will save anyone after me ~1-2 weeks effort.

How it works is this: every Velodyne LiDAR unit fires its lasers in a pre-defined sequence that repeats. E.g. 0, 16, 1, 17, 2, 18... But not every laser beam returns to the unit, so some parts of the cloud need to be filled in with points whose coordinates are NaN to preserve the organized nature of the cloud. My function creates a 2D organized cloud where there is one row for each "ring" of velodyne data. It then fills in each row, tracking how many points are in each row, i.e. what "column" of data is currently being filled in. When it moves from one column of data to the next, it fills in any gaps with NaN points.

Be careful how you use the organized cloud after this, as some PCL functions will crash if you input a cloud with NaNs, or worse, silently destroy the organized nature of the cloud without warning you.

---

Originally posted by M@t with karma: 2327 on 2019-03-27

This answer was NOT ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by gvdhoorn on 2019-03-28:
@M@t: would this be something to contribute to some more visible package? I'm thinking laser_filters or something similar, but then for lidars. Perhaps even the velodyne package itself?

Comment by M@t on 2019-03-28:
That might certainly be a good idea, the velodyne package would be the best fit as the function depends on the specific operation of Velodyne LiDARs. How time consuming is that process likely to be? Unfortunately I have precious little spare time right now.

Comment by gvdhoorn on 2019-03-28:
re: time: no idea. I'd suggest just opening an issue on the velodyne tracker and seeing whether there is any interest.