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

[luis-robotic]

Is your feature request related to a problem?

I'm currently experiencing an issue when attempting to retrieve X, Y, Z coordinates and range information for non-hit points (points where the laser did not return a measurement) using the Ouster sensor. These points are returned with (0, 0, 0) coordinates and range = 0, which makes it impossible to determine the direction of the laser beams or their intended spatial orientation. This lack of information limits our ability to apply processing and noise models to non-hit points in simulations or environmental analysis.

Describe the solution you'd like

I would like a feature that allows the sensor to output the intended direction (in terms of azimuth and elevation) or provide a consistent directional vector for non-hit points. This could be achieved by having:

1. The sensor provide azimuth and elevation angles for each point in the dataset, even for points with range = 0.
   

2. An option to include a flag or placeholder direction vector for non-hit points in the data stream.
   

Having this information would enable downstream processing and analysis to interpret the spatial orientation of non-hit points without ambiguity.

Describe alternatives you've considered

I've attempted to infer the direction of non-hit points using available metadata, such as beam_azimuth_angles and beam_altitude_angles, but this approach is limited due to the lack of synchronization with each measurement and the reliance on a consistent data structure for all points. Additionally, without range data, it's challenging to ensure these inferred directions align with the actual scanning pattern.

Targeted Platform:

Ouster Sensor: OS0, 128 channels.
ROS version/distro: ROS 2 Humble.
Operating System:  Ubuntu 20.04.
Machine Architecture: x86_64.

[SwiftGust]

Excellent question. I also have similar issue - how to distinguish non-returned point or point inside FoV keepout?
it seems both are indistinguishable - as 0.0 for old firmware or as NaN in new firmware in pointcloud / 0(mono16) in range image
I need to distinguish these & ray direction in point cloud or range image

[Samahu]

For the old and new FW a value of 0 means no returns even when you set the MIN_RANGE config to zero. A zero range is at the center of the sensor which is not a valid measurement. The ROS driver since version 0.12.4 replace range values of zero with NaNs to avoid having RVIZ display a point at the center of the sensor.

With regard to original suggestion I think we can replace zero values with unit vectors however it should be done via a parameter that the user needs to set with the default being NaN for a zero range value sent by the sensor.

[SwiftGust]

Thank you for clarification @Samahu.
I'd like to know how to distinguish close (mostly structure of the sensor carrier) or no-return (may be too far, reflected/refracted, absorbed) points if OS firmware treats both as zero - I need to distinguish between close or no-return points at least

[Samahu]

Hi @SwiftGust,

If you can upgrade to FW 3.1 it allows you to set the minimum range to zero. This way you can close the gap for detecting objects that are in close to proximity to the sensor. When you set the minimum range to zero you always get a return for objects with close proximity to the sensor and the only case you get a RANGE equal to zero is when there is no valid returns.

[luis-robotic]

Hello, @Samahu

Thank you for your response and for considering the suggestion!

I appreciate the clarification regarding the handling of zero range values with NaNs in the current ROS driver. The idea of replacing zero values with unit vectors via a configurable parameter sounds like a promising solution to address the issue.

I wanted to follow up and ask if there is any update on this proposed feature. Is it already under development, or are there any plans or timelines for its implementation?

[Samahu]

I wanted to follow up and ask if there is any update on this proposed feature. Is it already under development, or are there any plans or timelines for its implementation?

I have a quick prototype #406 (still in draft mode) but take a look and check if it achieves what you are looking for.