Expose Multiscan Matching Coarse Fine Resolution Multiplier

[louietouie]

Basic Info

This PR has no corresponding tickets
Tested only on Jazzy, Ubuntu 24.04, small Gazebo simulations

Summary

This exposes the multiplier between the fine search and coarse search for the Multi-resolution Correlative Scan Matcher. This multiplier is only for the translational search (x and y), not the angle. So it scales up the fine resolutions loop_search_space_resolution and correlation_search_space_resolution with the new parameters loop_search_space_coarse_resolution_multiplier and correlation_search_space_coarse_resolution_multiplier. It keeps the default scale at 2.

Documentation updates

I updated the README.md file. I commented out new BOOST_SERIALIZATION_NVP parameters, as I noticed the PR for m_pMinPassThrough did.

Future work

• It needs more rigorous testing
• I think there is a decent amount of repeat code (see calculations of m_xPoses and xPoses) that could be consolidated
• fine_search_angle_offset should be renamed fine_search_angle_resolution
• in this paper, the process described in section D3 searches over multiple of the coarse steps (until no coarse score is larger than some calculated fine score). I think this would guarantee that the best fine resolution would be found, so large multipliers like 10 would have no reduction in scan matching quality and still increase performance.

[SteveMacenski]

@louietouie can you summarize your testing on various parameters, and provide the graph figure, and the output maps for each of the settings? This should be information that other people are aware of and is searchable from our email chain.

With that - what's a good setting we should change the configuration files to use by your testing?

[SteveMacenski]

@louietouie what's a good setting we should change the configuration files to use by your testing?

[louietouie]

As you increase the multiplier, the runtimes get faster (up to a certain point), but theoretically, the scan matching should get less accurate. Before this PR, the multiplier was fixed at 2. From my second image below, even changing the multiplier to 4 had a substantial performance increase.

To minimize the number of scans required, I believe the best multiplier (for correlation_search_space_coarse_resolution_multiplier) would be round(sqrt(correlation_search_space_dimension/correlation_search_space_resolution)). I think this would evenly divide the number of scans between coarse and fine.

The graph below combines scans used for both scan matching odometry (at .5 dimension and .01 resolution) and loop closure (at 4.0 dimension and .01 resolution).

Here are some tests I did at multipliers 2, 4, and 10 using the a ros2 bag file so the path the robot takes was somewhat consistent. This is partially where I struggled; the tests were not repeatable (as is seen in the differences between the two equivalent-parameter tests at each multiplier level) and therefore it will be good to get feedback from others on the effects to accuracy.

If the performance increase is substantial, but the accuracy loss is noticeable, it may be worth implementing the algorithm in D3 of this paper which shouldn't be too hard. I believe this would completely stop any accuracy losses, with close to the same performance increase this PR should provide (if any).

[SteveMacenski]

I think 4 then seems reasonable. That seems to get the bulk of the computational benefits without being such a large change that I would expect massive differences. Can you do some testing on a few maps/worlds and let me know if you see any major differences?

If the performance increase is substantial, but the accuracy loss is noticeable, it may be worth implementing the algorithm in D3 of this paper which shouldn't be too hard. I believe this would completely stop any accuracy losses, with close to the same performance increase this PR should provide (if any).

I think that's worth an experiment!

[louietouie]

Definitely I can do that. I'm crunching to learn rust and finish a robot this week, but I will try to run some tests on other Gazebo maps early next week. Is there any other metrics to measure differences that you prefer (other than timing laserCallback)?

[SteveMacenski]

I think you showed me sufficiently that this is an improvement in run-time performance. At this point I'm more interested in making sure map quality is preserved in exchange for it.

[SteveMacenski]

@louietouie Hi! I wanted to follow up, were you able to run some experiments so we can merge this in?

[louietouie]

@SteveMacenski Sorry for the big delay. It's been a busy month but I have not forgotten. I will try to work on it this and next weekend. My plan is just to make a larger Gazebo map from scratch. If you have other ideas or access to any laserscan bag files of sims or real-world examples, I'd love to test those too.

[SteveMacenski]

I really appreciate the update, thanks! I found a few datasets googling but I didn't find any in particular I can recommend