fix(at128): allow negative values in points' elevation fields

[mojomex]

PR Type

• Improvement

Related Links

• feat(hesai): software-based precise FoV limit & early publishing #173 -- the base for this PR, needed because AT128 is broken before this PR

Description

⚠️ This has to be rebased onto develop after #173 is merged, and then be merged.

Only AT128 normalized its points' elevation field to [0, 2pi) while other sensors allowed negative elevation values. While the normalization is done on azimuth as well and thus, for consistency sake, would be nice on the elevation field, too, this causes visualizations to look ugly when coloring by elevation.
Anyway, trigonometry functions won't care about this change as they are periodic, and given that all other sensors are not normalizing elevation, it is safe to assume this doesn't impact downstream modules.

Old (normalized)	New (unnormalized)

Review Procedure

Confirm the elevation field looks correct. Code review.

Pre-Review Checklist for the PR Author

PR Author should check the checkboxes below when creating the PR.

• Assign PR to reviewer

Checklist for the PR Reviewer

Reviewers should check the checkboxes below before approval.

• Commits are properly organized and messages are according to the guideline
• (Optional) Unit tests have been written for new behavior
• PR title describes the changes

Post-Review Checklist for the PR Author

PR Author should check the checkboxes below before merging.

• All open points are addressed and tracked via issues or tickets

CI Checks

• Build and test for PR: Required to pass before the merge.

[knzo25]

@mojomex
#173 was merged, so could you rebase or solve conflicts before checking this PR?

[mojomex]

@knzo25 Thank you for the reminder, done. 👍

[mojomex]

@knzo25 As discussed internally, since this is a small 'hotfix'-style change, this is fine to merge into main.
I have tested the PR with a live sensor during the develop-eval tests and confirmed it working (see screenshots above). Code review should be enough imho.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 25.78%. Comparing base (9f706e3) to head (7245521).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #193      +/-   ##
==========================================
- Coverage   29.65%   25.78%   -3.88%     
==========================================
  Files          99       99              
  Lines        8760     8747      -13     
  Branches     2173     2146      -27     
==========================================
- Hits         2598     2255     -343     
+ Misses       6116     6106      -10     
- Partials       46      386     +340     

Flag	Coverage Δ
differential	25.78% <100.00%> (?)
total	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[knzo25]

LGTM

question though:
You are using MAX_AZIMUTH to normalize elevation.
I know that it is set to 360 * AngleUnit but if there comes a time where that stops being true (separate directly solid state from mechanical devices, etc), it would be worth considering using a separate variable

[mojomex]

@knzo Thanks for the input! The angle corrector classes are very sensor-specific (e.g. only AT128) so I think we are fine for some time to come. Other sensors such as the Aeries II don't have such variables at all for example.