The LiDAR azimuth unit is ambiguous

[badai-nguyen]

Checklist

• [X] I've read the contribution guidelines.
• [X] I've searched other issues and no duplicate issues were found.
• [X] I've agreed with the maintainers that I can plan this task.

Description

Currently, the LiDAR's azimuth is output in hundredths of degree unit that makes the code unclear and error-prone when adding support for new LiDAR devices. This problem was recognized when adding support for a new LiDAR in this issue: #509

Purpose

Improve the code readability and ease of adding support for new LiDARs.

Possible approaches

• Change output azimuth unit to degree in range of [0.0f , 360.0f] or radian in range of [ 0.0f , 2*pi] in LiDAR drivers: Velodyne and Hesai
• change the respectively unit of azimuth referenced in the related repository.
  • dual_return_outlier_filter
  • ring_outlier_filter
  • LiDAR blockage_diagnostics

The degree unit seems easier for readers to imagine the value of angle setting, while the radian unit may give performance benefits for conversions in sinusoidal/co-sinusoidal related function. Since the main purpose is for readability, it is proposed to use the unit of degree for azimuth.

Definition of done

Unify the new unit of azimuth in AW.

• [ ] output azimuth unit change from Velodyne driver
• [ ] output azimuth unit change from Hesai driver
• [ ] input azimuth unit change for related code and parameter in universe

[stale[bot]]

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

[xmfcx]

My suggestion: Following the discussions for the new point type PointXYZIRCT I think we can do the following:

• Don't calculate the azimuth in the driver.
• Calculate α(azimuth) with p.azimuth = std::atan2(p.y, p.x) in the place it is necessary
• The output will be a double or float (whatever precision is needed) in the range [-π , +π] radians
• Works for any kind of lidars, including solid state lidars too.

@aohsato @miursh

VLP-16 User Manual

[miursh]

@xmfcx In my opinion, calculating the azimuth for each point at the place requires extra calculation cost even though the drivers don't have to calculate since they know the exact azimuth based on the hardware laser configurations or based on sensor output. Since we handle more than 200,000 points (e.g. for VLS128), I think we should avoid those extra computational cost

[xmfcx]

@xmfcx check for how long it takes to compute std::hypot and std::atan2 for large amount of points just to see how much computation it takes.

Also list what nodes make use of azimuth and distance fields.

@esteve also suggests to send down the values because storage/memory is cheaper.

[xmfcx]

I've created a mini benchmark for this topic: https://github.com/xmfcx/bench_point_cloud#readme @esteve @miursh

Let's continue this discussion in https://github.com/autowarefoundation/autoware-documentation/pull/180#issuecomment-1317583569