ROS-396: retrieve xyz for non hit

[Samahu]

Related Issues & PRs

• closes Unable to Retrieve X, Y, Z Coordinates and Range for Non-Hit Points with Ouster Sensor #396

Summary of Changes

• Allow users to assign a value for no-returns (no hit)

TODO(s):

• Expose a parameter that allows user to enable this feature and adjust the invalid (out-of-range) value.

Validation

This image was generated by manually setting the invalid (out-of-range) value to 1m distance.

[luis-robotic]

Hi @Samahu

I’ve actually been working on a similar solution, but in my case, I used a VLP16 sensor, which includes a feature that allows it to send the entire point cloud.

From what I understand, Ouster compresses the point cloud by only including return points, whereas Velodyne sends non-return points as NaN values. Aligning these non-return points with the correct ring and azimuth was somewhat challenging, so having a feature that outputs these points with their original orientation would be incredibly useful for my work.

[Samahu]

I think there is some miscommunication, this MR still sends the entire PointCloud when you choose organized:=true.

The mainline of the ouster-ros driver currently sets no returns to NaN by default, these NaN values will still be sent in case of organized PointCloud, however, when you choose a non-organized PointCloud i.e. organized:=false then NaNs or no-returns values will be omitted out from the final PointCloud.

All this MR is doing is replace NaN values with a valid point at a fixed distance which you can use to infer the direction from the generated PointCloud. So I am not sure what are we still missing here.

[SwiftGust]

I think it would be nice to set some specific value on some point field like intensity, reflectivity that notify ray did not return
rather than multiply certain range on Cartesian coordinate and project points to Cartesian coordinate slightly further than maximum range which would allow filter-out non-returned points with range or some fields on existing codes with ease.

[luis-robotic]

Hi @Samahu
I have to thank you for the proposed solution. It really covers my requirements for now. If I can contribute anything else in the future, I will be happy to do so.
Now we have a unique orientation for each point. And because we can adjust this distance, we can also filter out return and non-return points.

Maybe, as @SwiftGust suggests, you could delimit a specific field for such values, or directly enable a new field such as (is_hit = 0 or 1).

But thank you very much for the effort.

I want to ask about why I am receiving the topic /ouster/points at a very low rate.
average rate: 2.674
min: 0.024s max: 360.629s std dev: 8.07694s window: 1995
average rate: 2.669
min: 0.024s max: 360.629s std dev: 8.07498s window: 1996
average rate: 2.669
min: 0.024s max: 360.629s std dev: 8.06691s window: 2000
average rate: 2.668
min: 0.024s max: 360.629s std dev: 8.05889s window: 2004
average rate: 2.663
min: 0.024s max: 360.629s std dev: 8.05290s window: 2007
average rate: 2.648
min: 0.024s max: 360.629s std dev: 8.05148s window: 2008
average rate: 2.645
min: 0.024s max: 360.629s std dev: 8.04950s window: 2009
average rate: 2.642
min: 0.024s max: 360.629s std dev: 8.04552s window: 2011
average rate: 2.640
min: 0.024s max: 360.629s std dev: 8.04153s window: 2013

The rest of the topics published by the sensor are at 10Hz as I set up in the launch file

arg name="lidar_mode" default="512x10"
description="resolution and rate; possible values: {
512x10,
512x20,
1024x10,
1024x20,
2048x10,
4096x5
}

But this one is going really slow and you can see this on rviz.

I am using ROS2 Humble for this.

[Samahu]

I think it would be nice to set some specific value on some point field like intensity, reflectivity that notify ray did not return
rather than multiply certain range on Cartesian coordinate and project points to Cartesian coordinate slightly further than maximum range which would allow filter-out non-returned points with range or some fields on existing codes with ease.

The issue with this proposal is that some point representation like the PointXYZ (which is a supported point type in the driver) doesn't have an intensity. Other point types have other fields but not intensity.

Regardless, you would still need to substitute zero RANGE value (no-return) with some value before computing xyz coordinates.
I think using the unit vector is mostly sufficient since no real returns would be at 1 mm distance from the sensor center, so you can use that as a threshold to detect whether this is a valid return or not.

[Samahu]

I think it would be nice to set some specific value on some point field like intensity, reflectivity that notify ray did not return
rather than multiply certain range on Cartesian coordinate and project points to Cartesian coordinate slightly further than maximum range which would allow filter-out non-returned points with range or some fields on existing codes with ease.

The issue with this proposal is that some point representation like the PointXYZ (which is a supported point type in the driver) doesn't have an intensity. Other point types have other fields but not intensity.

Regardless, you would still need to substitute zero RANGE value (no-return) with some value before computing xyz coordinates. I think using the unit vector is mostly sufficient since no real returns would be at 1 mm distance from the sensor center, so you can use that as a threshold to detect whether this is a valid return or not.

The one alternative is to create a custom Point type that encode this information in a separate field (is_valid for example) but then you can't get this information with other existing point types.

[Samahu]

I want to ask about why I am receiving the topic /ouster/points at a very low rate.
average rate: 2.674
min: 0.024s max: 360.629s std dev: 8.07694s window: 1995
average rate: 2.669
min: 0.024s max: 360.629s std dev: 8.07498s window: 1996

I bet you are using FastDDS, try switching to CycloneDDS ( as noted here )