Testing the slam_toolbox multi-robot node with Nav2 on three TurtleBot3 Burgers (Jazzy)

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.

real_robots
rviz_multi_slam

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/tf with plain frame names and a shared global_odom frame, so the namespaced TurtleBot3 TF has to be relayed into that layout.
  • On Jazzy, navigation_launch.py does not push the namespace onto the Nav2 nodes, and turtlebot3_node needs enable_stamped_cmd_vel to accept the TwistStamped that 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

1 Like