SteveMacenski
Multi-Robot SLAM in ROS 2
Basic Info
| Info | Please fill out this column |
|---|---|
| Ticket(s) this addresses | #76 |
| Primary OS tested on | Ubuntu 22.04 |
| Robotic platform tested on | Turtlebot3 Burger (hardware and simulation) |
Description of contribution in a few bullet points
This is a ROS 2 Humble port of the ROS 1 implementation from #541, extending SLAM Toolbox to support multi-robot mapping.
- Localization and mapping using information from multiple sensors (one laser scanner per robot)
- Loop closure across paths from multiple robots
Description of documentation updates required from your changes
- Currently, both synchronous and asynchronous mapping is supported.
- To operate, all robots must be part of the same transformation tree.
- They must start close to each other; the first robot to connect establishes the map frame origin. Relative poses for the other robots are determined from the SLAM Toolbox solver.
- Parameters
odom_frames,base_frames, andlaser_topicsdefine the respective information from each robot. - Pose graph colors are randomly assigned for each robot (nodes and edges).
Source code, launch and configuration files are all contained within dedicated multirobot directories.
Future work that may be required in bullet points
- Localization and lifelong mapping are pending. Currently, not a priority for me but would be good to have.
- There is a poblem where robots identify each other as osbtacles. Especially when they're not moving upon first starting the mapping procedure.
Any assistance/suggestions on these is appreciated!
Localization and lifelong mapping are pending. Currently, not a priority for me but would be good to have.
I wouldn't implement them. Localization is better suited on a per-robot basis anyway and the lifelong is experimental that should probably just be removed. I'd say this is done
Can you include a link back to the multirobot configuration file in your README section to point to an example?
I see both images/multirobot/pose_graph_colors.png and images/multirobot/pose_graph_colors_2.png, can the first be removed if its unused?
Motivational question before the review: Is there a reason these are duplicated files instead of having the couple hundred line changes inline in the main code? The previous PRs adding multirobot support didn't have that many changes to the core files. It looks like I wasn't able to merge them in because the authors either didn't respond or fix the items I needed fixed (or were on ROS 1 which I couldn't test)
I am honestly of 2 minds about it:
- I can more easily just merge this in with some quick testing since it is independent of existing capabilities so it won't break anyone, but also can't be used without knowing about the new nodes
- I can less easily merge this in because I can't see the few changes you made w.r.t. the original files, so I'll have to track down every line of the 2,400 line PR to validate it since I don't know what the few changes are.
I think I prefer it being a couple hundred line change in-line over the completely separated nodes, but I could be convinced otherwise...
Can you include a link back to the multirobot configuration file in your README section to point to an example?
Done!
I see both images/multirobot/pose_graph_colors.png and images/multirobot/pose_graph_colors_2.png, can the first be removed if its unused?
Done!
As for your motivational question...
The main reason was robustness ansd safety. Since this work was a "learn as I go" task, I wanted to avoid breaking anything in the application while modifying the original files.
Additionally, keeping the multi-robot functionality separate, at least in my mind, maintains it as an extended feature rather than a core capability. Like lifelong mapping, this approach makes it trivial to update the original files when new commits are made.
Lastly, do you have any suggestions on how (and where) to handle this issue?
There is a poblem where robots identify each other as osbtacles. Especially when they're not moving upon first starting the mapping procedure.
Resolving this would be necessary for a proper multi-robot SLAM solution.
The main reason was robustness ansd safety. Since this work was a "learn as I go" task, I wanted to avoid breaking anything in the application while modifying the original files.
Would it be too much effort to have another branch where you make the few changes you made to these files in-line with the original software? It might help me make that judgement call if I think there's anything you've done that makes me think 'yeah, maybe its better to keep these separated'.
Additionally, keeping the multi-robot functionality separate, at least in my mind, maintains it as an extended feature rather than a core capability.
If its mostly allowing an array of information to stream in and fixing a few frames, I think its not much to have separated (and adds double the maintainer time to fix the multi-robot version when new features / bug fixes are added to the main software, since its duplicated).
There is a poblem where robots identify each other as osbtacles. Especially when they're not moving upon first starting the mapping procedure.
This is virtually a non-issue since other robots are no different than people, other vehicles, etc in a dynamic scene :-)
Would it be too much effort to have another branch where you make the few changes you made to these files in-line with the original software? It might help me make that judgement call if I think there's anything you've done that makes me think 'yeah, maybe its better to keep these separated'.
I’ve created the new branch with the changes integrated into the original files. For now, I’ve commented out the compilation of the "lifelong mapping" and "localization" components, as they require additional adjustments to align with the updated source code. However, this should give you a clear overview of the modifications made for the multirobot functionality.
Should I open a separate pull request? Or is there a cleaner way to integrate the new branch into this thread?
Should I open a separate pull request? Or is there a cleaner way to integrate the new branch into this thread?
Lets start with just a link. I can look at the diff and see what seems like the best path forward
There you go: https://github.com/UTNuclearRoboticsPublic/slam_toolbox/tree/humble_multirobot_v2
@Daniel-Meza sorry for the delay. ROSCon/ROS-I/Actuate conferences and talks have really delayed some of my reviews.
I think your diff looks good against the main servers. I have some review comments for changes, but largely that should sail through with a couple of iterations! I'll just test myself that the single robot case still works and if you can show the 2+ robot situation works, I'm happy with that
No problem at all. Feel free to send over your comments and I'll incorporate them as best as I can.
Also, I don't feel qualified to speak on other multi-robot slam implementations so I'll limit my contributions to this work. However, I'm happy to make necessary adjustments to ensure those who have made further progress can contribute their work to this project.
Sorry for the delay, ROSCon, ROS-I and so forth has kept me busy as of late and returning back to normal.
@Daniel-Meza can you follow up on the comment thread in #592 I started on a meeting between yourself, me, and @acachathuranga to find a shared path forward here?
I like your work here and appreciate your time! This is all great work :-)
Notes from our conversation:
- [ ] @Daniel-Meza update for the delta version + fix localization and lifelong mapping
- [ ] @Daniel-Meza add docs on initialization method
- [ ] @acachathuranga review it
- [ ] Steve: Review this PR, make adjustments as needed
- [ ] Steve: test it
- [ ] Obtain gif of robots / slam
- [ ] Merge baby merge :partying_face:
- [ ] Steve: Add docs on when to use each & publicly announce the updates with thanks for the developers
@SteveMacenski Returning to this with updates and discussion points...
Updated Localization Node for Multirobot Support
Multirobot localization is now functional, but as in collaborative SLAM, all robots share a single pose graph. In the video, you can see up to 6 poses in the buffer being filled based on the most recent pose that was processed. I.e. the different colors come simply from visualization but there is a single underlying smapper_ variable
I'm unsure whether this approach is correct, or whether each robot should have separate pose graphs (or separate localization nodes)? If separate graphs are needed, that may require more substantial rework to shared functionalities from slam_toolbox_common. Thoughts?
Pending LifeLong Mapping
I'm unclear on how this mode operates, especially since its launch file appears to be explicitly excluded in CMakeLists.txt. Could you clarify its expected behavior so I can properly adapt it for the multirobot setup?
Issues with Main ros2 Branch
Building the ros2 branch failed due to Ceres solver version inconsistencies. However, I updated and tested the Jazzy branch, as it seems closest to the main ros2 branch, with the multirobot work. Currently, you can find 2 clean working branches in the forked repo:
- ROS 2 Humble :
humble_multirobot_v2branch - ROS 2 Jazzy :
jazzy_multirobotbranch
Hey guys, really nice work.
I wanted to use the multi-robot approach for my own project and I found out that there is a second PR https://github.com/SteveMacenski/slam_toolbox/pull/592 that references the "same" topic. So I'm wondering what the difference is between these two PRs and which one I should use. Are both still maintained and trying to get published, because both got recent updates and I noticed that you all met together.
I can see that there is a working branch for humble here. Is this the same case for the other approach?
Hello @manuelarling ,
Apologies for the late reply, work has been heavy this beginning of the year and I've had to put things on the back burner...
As per your question above and in the email... Yes, that's exactly what I mean with both robots being on the same transformation tree. The SLAM Toolbox node should be able to subscribe to a single "/tf" topic where it can find all the different robot frames. In fact, that is a fundamental difference between this work and other PR, which distributes this over different trees to handle their specific setup and networking loads.
I'm trying to implement multi-robot slam for my own project in Isaac Sim. Between this and #592 which should I use? It seems like there has been some effort to consolidate things into one PR, has either been selected as the "main" branch? If there is anything I can do to speed things along please let me know
