Its your friendly neighborhood navigator here. I wanted to bring to you attention a handful of PRs and a discussion that’s been going on for the better part of a year regarding 360 lidar & non-axially-aligned lidar support on SLAM Toolbox. Some of you have been able to use SLAM Toolbox in these conditions without a problem, but others have reported some behaviors we’ve been working on solving.
We’ve found a number of issues that were blocking us from supporting this and resolved the vast majority of them. Alas, one remains that we have a workable solution for which will forever put this issue to bed.
It looks like there was a bug in the original openKarto code that no one caught resulting in a mix-up between the robot base pose and the laser pose when interacting with the optimization engines. This was the root cause of these issues. In fixing this, we allow for any lidar mounted in any position and resolve the issues RPlidar users were reporting (and fixes the largest standing bug stopping multi-laser support!). Overall, is the correct course of action.
However, this fix comes at a price. Because we’re messing at the lowest levels of openKarto, we’re actually changing the information embedded in the serialized files. That means that any files you’ve serialized prior to this PR may no longer work as expected after this change. The serialized pose-graph information given to the optimizer will now be w.r.t.
robot base frame where previously it was stored as
laser frame. When you try to re-run your pose-graph over it, the results could be wacky since the new information being added in a localization mode or continued-mapping mode will be in another reference frame.
This is a non-issue if you have a lidar mounted with the primary axes aligned to your robot base frame (e.x. laser mounted forward; either right side up or up side down). This will only be an issue for anyone mounted at an angle or backwards, but also solves a long standing issue impacting those same people.
I’m here to ask if breaking some old serialized files mid-distribution would be OK to you considering the benefits it provides, especially considering it only breaks behavior of people already with broken behavior they need fixed. Note that this does not in any way impact saved
pgm, etc occupancy map files saved, only the serialized
.data files SLAM Toolbox creates on request.
For any new distributions, this PR will be merged so that new users don’t run into any of these serialization issues - so your files will become invalidated eventually anyway. So we’re really just talking about released distros of
dashing. This is an ABI breaking change I would typically not consider merging, however since ROS(1) is “done” and will still have users for many years, it seems like shooting ourselves in the foot to not fix this issue for everyone else that comes along for the next 4 years.
What I’m leaning towards, since this is a big fix and a big break at the same time is to create
distro_name-devel-unfixed branches for the released distributions which will branch off before this change so that all existing users have access to the existing behavior if they want it. Then we’d merge these changes and re-release with the patch in the next
distro sync. We’d add warnings to the readme files as well letting people know this occurred.
Please let me know what you think.
Ref: 2 Major issues on the topic
- Map temporarily rotates or flips [rplidar] · Issue #281 · SteveMacenski/slam_toolbox · GitHub
- [rplidar users] Potential errors with drivers + 360 lidar support · Issue #198 · SteveMacenski/slam_toolbox · GitHub
Ref: The PRs to resolve for each distribution
- ROS2 fixing 360 lidar issue for ros2 branch by SteveMacenski · Pull Request #360 · SteveMacenski/slam_toolbox · GitHub
- Foxy fixing 360 lidar issue for foxy branch by SteveMacenski · Pull Request #362 · SteveMacenski/slam_toolbox · GitHub
- Dashing fixing 360 lidar issue for dashing branch by SteveMacenski · Pull Request #361 · SteveMacenski/slam_toolbox · GitHub
- Melodic fix the issue (#198) that loop closures can rotate the map 180° if the lidar is mounted backwards by WLwind · Pull Request #326 · SteveMacenski/slam_toolbox · GitHub
- Noetic fix the issue (#198) that loop closures can rotate the map 180° if the lidar is mounted backwards by WLwind · Pull Request #325 · SteveMacenski/slam_toolbox · GitHub