Multiexplorer — Multi-Robot Frontier Exploration with TurtleBot3

1. Overview and Motivation

Multiexplorer is my first ROS project, built after a 2-week ROS boot camp and ~2 additional weeks of focused project work at TÜBİTAK BİLGEM. The goal was intentionally practical and learning-driven:

build an end-to-end autonomous exploration pipeline in ROS,
scale it from one TurtleBot3 to two and three robots,
learn the “glue” that makes multi-robot systems work in ROS: namespaces, TF, launch design, and topic remapping.

The entire project is simulation-only (Gazebo + RViz), so it is easy to reproduce and extend.

2. What the System Does

At a high level, each robot repeatedly:

builds a local map,
finds “frontiers” (boundaries between known and unknown space),
sends navigation goals toward those frontiers,
and contributes its local map to a global merged map.

Core building blocks

Frontier exploration: explore_lite (frontier detection + goal selection)
Navigation: move_base with DWA local planner (path planning + obstacle avoidance)
2D SLAM: gmapping (per robot)
Map merging: multirobot_map_merge (fuses /tb3_i/map into a merged /tb3/map)

3. Multi-Robot ROS Design

Scaling from one to multiple robots in ROS required consistent separation and a clean “shared world” interface.

Namespaces + TF prefixes

Each robot runs in its own namespace (e.g., tb3_0, tb3_1, tb3_2) so that SLAM, navigation, and TF do not conflict.

Typical patterns used throughout the package:

Per-robot topics:
- /tb3_0/scan, /tb3_0/odom, /tb3_0/map (and similarly for tb3_1, tb3_2)
Per-robot frames:
- tb3_0/base_footprint, tb3_0/odom (etc.)
Merged map topic:
- /tb3/map (used as the shared “global” map for exploration/navigation)

Map merging strategy

multirobot_map_merge is configured to subscribe to each robot’s map topic and publish a merged occupancy grid. For the multi-robot experiment launch, the merge node is set up with:

known_init_poses: true (uses the Gazebo spawn poses as initial alignment priors)
a merged map published on tb3/map
static transforms connecting the world map frame to each robot’s map frame

This structure makes the “multi-robot” part largely a launch/config problem: once topics and frames are isolated, the same SLAM+exploration pipeline can be replicated per robot.

4. Launch Scenarios Included

The package provides one-command launches to reproduce the main scenarios:

Single robot exploration: SLAM + explore_lite + navigation
Two robots: same pipeline for two namespaces + map merge
Three robots: same pipeline for three namespaces + map merge
Map-merge only: run multirobot_map_merge over any set of /map topics
Experimental fiducial SLAM mode: ArUco detection + fiducial_slam in an ArUco-enabled world (for exploration/localization experiments)

Tip: pass gui:=false (when supported) for headless Gazebo runs.

5. Key Parameters I Tuned (Process Focus)

A large part of this project was learning how to make a full pipeline behave reasonably in simulation by iterating on parameters.

Examples of parameters used in the multi-robot launch:

`explore_lite`

planner_frequency, progress_timeout (how often to replan / when to give up on a frontier)
min_frontier_size (filters tiny frontiers)
potential_scale, gain_scale, orientation_scale (frontier scoring)

`move_base` (DWA)

per-robot costmap and DWA configs (kept separate to avoid cross-talk)
local planner behavior tuned through YAML parameter sets

`gmapping`

namespaced frames (base_frame, odom_frame, map_frame)
SLAM sensitivity and update thresholds (especially relevant once robots start moving faster)

6. Setup and Usage

Tested in simulation with common ROS1 TurtleBot3 stacks (Ubuntu 20.04 / 22.04, ROS Melodic / Noetic).

# ❶ Clone & build (catkin)
cd ~/catkin_ws/src
git clone https://github.com/yunusdanabas/multiexplorer_yunusdanabas.git
cd ~/catkin_ws
rosdep install --from-paths src --ignore-src -r -y
catkin_make
source devel/setup.bash

# ❷ Run experiments
roslaunch multiexplorer_yunusdanabas single_robot_exp.launch   # 1 robot
roslaunch multiexplorer_yunusdanabas double_robotexp.launch    # 2 robots
roslaunch multiexplorer_yunusdanabas multi_robotexp.launch     # 3 robots

7. Lessons Learned

Namespacing and TF discipline matter more than anything else for multi-robot ROS1 setups.
Map merging is a real system component, not just a visualization step: topic choices, frame conventions, and update rates affect exploration stability.
Parameter iteration is unavoidable: exploration behavior is highly sensitive to frontier thresholds, replanning logic, and navigation costmaps.