distortion_corrector should update "azimuth" and "distance" field

[VRichardJP]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I'm convinced that this is not my fault but a bug.

Description

Because LIDAR sensors do not shoot laser simultaneously in all directions, raw sensor clouds look distorted when the vehicle turns or drive fast. pointcloud_preprocessor::DistortionCorrectorComponent use vehicle twist/imu data to rectify that distortion. Basically, it interpolates cloud points xyz values to make it as if all point laser had been shot simultaneously.

In the implementation x, y and z fields are modified, but not azimuth nor distance. Downstream nodes thus cannot use these 2 fields reliably.

For example, ring outlier filter is used after the distortion corrector filter, and current implementation relies both on azimuth and distance fields values. If the azimuth field is wrong, then the filter output may be incorrect. In ring outlier filter case, distortion effect is not "too bad", because only consecutive points on the same ring are considered (distortion effect over 2 consecutive points is negligible), except for the last and first point of the ring, which would be far away from each other due to distortion.

This leads to another problem: what do "azimuth" and "distance" fields mean? Are these values related to the sensor origin, or the current frame? Currently, these values are never updated, so they represent points in the original sensor frame, even though the cloud frame may be different (typically base_link). I don't think it is a problem per se, since these fields most likely only make sense in the sensor frame. For example ring outlier filter uses azimuth to group ring points together, but if the values were expressed in a different frame the logic would not make sense anymore.

So if the distortion corrector needs to update the "azimuth" and "distance" fields, it needs to be done in the original sensor frame, not the current one. This would definitely lead to some convoluted implementation.

Instead, it would be maybe simpler to have the input cloud of distortion corrector (and ring outlier filter) use the sensor frame. For example, in the sample_sensor_kit, the velodyne_node_container transforms the raw input cloud to base_link frame in order to filter points on the vehicle body. The sensor frame could be used as output frame for the distortion filter right after.

Expected behavior

pointcloud_preprocessor::DistortionCorrectorComponent also rectifies azimuth and distance

Actual behavior

Does not

Steps to reproduce

N/A

Versions

No response

Possible causes

No response

Additional context

No response

[stale]

This pull request has been automatically marked as stale because it has not had recent activity.

[vividf]

The PR for fixing this is blocked because Velodyne's output azimuth is already wrong before the distortion corrector node.

[vividf]

This issue can be solved by this PR #8380