Implement support for non-repetitive/alternating lidar scan patterns

[Roboterbastler]

Change description

As described in issue #31 there are some lidar sensors using non-repetitive patterns. To accurately model their point cloud data I modified the implementation so that presets for these type of sensors can be created.

The basic idea is that for alternating patterns each update step only uses a subset of samples of the total pattern vector and this subset cycles through the vector until the pattern sequence eventually repeats again.
For this I introduced lidarPatternSampleSize which in the case of an alternating pattern is an integer divisor of the total pattern vector size. Otherwise it just equals lidarPattern.size().
To swap the alternating pattern in each update the compute graph nodes are already created in advance and only re-linked. In my specific testing case (Livox Mid360) this re-linking step adds about 10-20 microseconds which is not really significant compared to the total time of one update step. In the static pattern case the graph is not changed.

Since personally my motivation was to simulate the Livox Mid360 sensor I added the preset for it and while I was at it also added the other sensors whose patterns were available here. For reference I used this small program to convert the Livox config files to the file format used by RGLGazeboPlugin.
I think it could be very useful for the community to have these presets readily available, the only potential problem I see is the file size for this git repository.

I did not implement an option to specify an alternating pattern via <pattern_preset_path>, this would require either extending the XML config or the file format to accommodate the lidar pattern sample size. Could be added in the future though.

Small gallery of added pattern presets (only showing one sub-pattern each):

How to test

• Test static patterns which should work exactly as before
• Test the alternating patterns, using the new presets e.g. <pattern_preset>Livox Mid360</pattern_preset>

---

Fixes #31

[PawelLiberadzki]

@Roboterbastler Thank you for your contribution, we greatly appreciate it! Now all team members are busy with ongoing work, but within incoming 2-3 weeks we will review this code and help you merge it.

[msz-rai]

Great job!

I’ve left a few minor suggestions to improve naming and readability.

Regarding the size of pattern files, we decided to include them in the repository directly since each individual file is under 50MB (as recommended by GitHub). Additionally, these files are not expected to undergo frequent modifications, so the repository size will not grow significantly over time. While we could use Git LFS, this would require extra setup and comes with the risk of exceeding GitHub's bandwidth limits.

[huqin-RM]

@msz-rai @Roboterbastler We look forward to your merging this feature into the mainline, which will facilitate our migration from gazebo classic to gazebo sim.

[msz-rai]

Looks good to me!
Thank you for your contribution 🎉

@Roboterbastler, would you like to backport this feature to fortress branch also? It seems the only difference would be in the logging command (gzerr -> ignerr). If you'd prefer not to handle it, I can take care of it myself.

[huqin-RM]

In order to get closer to the real MID360 radar, motion distortion is taken into account. Is it possible to increase the update frequency to 1000 Hz and collect 200 points 1 ms, so that 20,000 points can also be collected in 100 milliseconds? @Roboterbastler @msz-rai @PawelLiberadzki