ros-drivers / velodyne

ROS support for Velodyne 3D LIDARs
http://ros.org/wiki/velodyne
Other
657 stars 653 forks source link

Request: Add Explicit Representation of Non-Return Points in PointCloud2 Output #551

Open luis-robotic opened 1 week ago

luis-robotic commented 1 week ago

Is your feature request related to a problem?qq

I'm working with Velodyne sensors (e.g., VLP-16) and need access to data representing laser beams that do not return a valid measurement (non-return points). These points appear to be excluded or not explicitly available in the published PointCloud2 topic when using the Velodyne driver. This omission makes it difficult to analyze regions where no objects are detected, as those beams are effectively "invisible."

Describe the solution you'd like

I would like the driver to include points for non-returns explicitly in the published PointCloud2. These points could be represented as:

This inclusion would allow users to analyze areas with no valid returns and maintain consistency in the PointCloud2 structure, particularly for organized clouds.

Additional context

Including non-return points can be particularly useful in applications such as:

For example, the DataContainerBase class and its derivatives (e.g., OrganizedCloudXYZIRT) in the driver could explicitly add placeholders for non-return points when the organize_cloud parameter is enabled. Similarly, for flat clouds, these points could be added optionally with a configuration parameter.

If this feature already exists and requires specific configuration, could you provide guidance on how to enable it?

luis-robotic commented 6 days ago

Comment:

Thank you for the discussion and insights on this topic. I wanted to share that I’ve successfully resolved the issue of receiving non-return points as NaN in the PointCloud2 data, largely thanks to the solution and guidance provided in Issue #360.

Now, my challenge is related to retrieving the orientation of these non-return points, specifically their azimuth angle. While the elevation angle (ring field) is already preserved and accurate, the azimuth for these NaN points is either missing or unclear.

This information is crucial for certain applications where the azimuth orientation of a beam is required, even when no valid return is detected.

Would it be possible for the driver to include azimuth information for these non-return points? Or is there an existing method to estimate or retrieve this information using the current driver implementation? Any guidance or suggestions would be highly appreciated.

Thank you again for your work on this driver, and I look forward to any advice you can provide!