feat(hesai): add a ring section filter to Hesai sensors

[mojomex]

PR Type

• New Feature

Related Links

• TIER IV INTERNAL LINK -- related ticket
• feat: add ring based filter for velodyne #69 -- similar PR for Velodyne
• feat(hesai): software-based precise FoV limit & early publishing #173 -- depends on this PR being merged first

Description

⚠️ Depends on #173, which has to be merged first ⚠️

This PR introduces a simple and extendable framework to implement per-point filters in Nebula. The first filter, also added in this PR, is a ring section filter.

Point Filters

A point filter has one member function bool excluded(const NebulaPoint &) which is called per point, right after that point has been fully decoded (including angle correction). The point is excluded from the pointcloud as soon as any of the configured filters excludes it. Filters run sequentially and later filters are not executed if an earlier filter has exluded the point already.

The filter pipeline is configured via JSON, in a format like {"filter1": filter_params1, "filter2": filter_params2} and each filter type can only appear once.

Ring Section Filter

The filter can be configured to cut out zero or more sections of each ring, each section having a start and end angle.
The configuration looks like this: [[channel_id, start_deg, end_deg], [channel_id, start_deg, end_deg], ...]. Not all channels have to be specified, and channels can be specified multiple times. The start and end values are floating-point, so precise angles can be defined. Sections can overlap, but no optimizations are done on Nebula's side to merge overlapping regions.

Angles greater than 360deg and smaller than 0deg can be specified and will be auto-normalized by Nebula. Sections spanning over the 360/0 boundary are also handled correctly.

Performance

This is a fairly naive implementation:

• while parsing, an array of arrays of sections is created. The index in the outer array corresponds to the channel ID, while the inner arrays are a collection of their rings' sections.
• for each point, all sections on its ring are checked until it is excluded or all sections have been checked.

To measure performance overhead, the following runs have been performed:

• a baseline run with the filter code completely commented out (performance is the same as without this PR)
• runs with a filter on 1-128 channels, with 1-50 sections per channel. Each section is 1deg in size, such that there is no significant performance gain from buffering less points

All runs have been performed with the maximum possible number of points per cloud (all the filtering code, even for invalid points was commented out).

As can be seen in the figure, one filter per channel has no performance impact. 50 filters per channel increase the average runtime by about +160% compared to the baseline. As there will be a very small number of sections in the real world, this should not be a performance bottleneck in real-world operation.

Review Procedure

Remarks

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.