I wanted to see how well the decentralized multi-robot SLAM that slam_toolbox already implements (PR #592) holds up on real hardware, with one Nav2 stack per robot. Nothing new on the SLAM or navigation side: this is a test of what slam_toolbox and Nav2 already do, on three TurtleBot3 Burgers with ROS 2 Jazzy. It works well. The three robots build one shared map, and each robot sees the other two as obstacles in its costmaps.


A few things to take care of if you try it:
- The multi-robot node is not in the Jazzy release. I cherry-picked the commit from PR #592 onto the jazzy branch and built it from source.
- The LDS-02 returns a different number of beams in every scan, and slam_toolbox rejects a scan whose length changes. I resample every scan to 360 beams.
- The node expects a per-robot TF tree on
/robotN/tfwith plain frame names and a sharedglobal_odomframe, so the namespaced TurtleBot3 TF has to be relayed into that layout. - On Jazzy,
navigation_launch.pydoes not push the namespace onto the Nav2 nodes, andturtlebot3_nodeneedsenable_stamped_cmd_velto accept theTwistStampedthat Nav2 publishes. - With three Nav2 stacks over WiFi, odometry dropped from 20 Hz to 1-4 Hz until I bound Fast DDS to the laptop’s LAN address and enlarged the socket buffers.
- The start poses given to the SLAM nodes have to match the real layout within about 0.25 m and 20 degrees.
Scripts and config: GitHub - prakash-aryan/turtlebot3-multi-robot-slam-nav2: Decentralized multi-robot SLAM (slam_toolbox) and per-robot Nav2 on real TurtleBot3 Burger robots, ROS 2 Jazzy · GitHub