Suppose the warehouse has grown large enough that one ARCHO is no longer enough, and three of them work at the same time: robot_1, robot_2, and robot_3.
If all three ARCHOs simultaneously publish and subscribe on /scan, /odom, and /cmd_vel,
the whole system no longer knows which message belongs to which robot. Each robot's Nav2 tries to send
a motion command meant for all three robots at once — the result is pure chaos.
The simple, common solution is to prefix every topic of each robot with its own name — exactly the same Namespace concept we saw in Chapter 2, just this time at the scale of an entire fleet:
/robot_1/scan
/robot_1/odom
/robot_1/cmd_vel
/robot_2/scan
/robot_2/odom
/robot_2/cmd_velNow each ARCHO listens only to its own topics and publishes only on its own topics. Nav2, SLAM Toolbox, and ros2_control each run inside that same namespace and have no idea other ARCHOs even exist.
Namespace alone isn't enough. Recall from Chapter 5 that the TF Tree is a global structure — if all three
ARCHOs each have a frame called base_link, TF has no way of knowing which base_link
belongs to which robot. The solution: each robot names its own frames with its own prefix.
robot_1/base_link
robot_1/laser_link
robot_1/odom
robot_2/base_link
robot_2/laser_link
robot_2/odom
The map frame is usually a single one shared by the whole fleet — because all the robots
move through the same warehouse. But each robot has its own odometry, its own drift, and its own
accumulated error; so each one needs its own independent odom frame, exactly as in
Chapters 5 and 9 for a single robot.
Namespace and TF Prefix only guarantee that the robots don't get mixed up with each other. But a bigger question is still open: when a new mission comes in (say, "empty shelf 40"), which ARCHO should do it?
Multi-robot isn't just running several parallel copies of Nav2; it requires a fleet management layer (Fleet Manager) to assign missions and resolve conflicts among robots.
| Mode | Scenario | Example |
|---|---|---|
| Shared map | One building, several robots, all moving on the same map | Several ARCHOs on one floor of a warehouse |
| Independent map | Robots work on completely separate floors or environments | One ARCHO on the ground floor, another on the floor above |
Even if each ARCHO avoids fixed obstacles on its own, two robots can still end up facing each other in exactly the same narrow aisle — something a single robot's local costmap cannot predict, because each robot only sees its own surroundings.
Robot A → ← Robot BCommon solutions at the fleet level (not at the level of a single robot):
| Solution | Idea |
|---|---|
| Aisle reservation | Before entering a narrow aisle, a robot reserves it for itself |
| Right of way | One robot (e.g. with a more urgent mission or lower battery) gets priority to pass |
| Traffic graph | The warehouse map is converted into a traffic graph with allowed directions of travel |
| Zone lock | An entire zone is locked for a short time so only one robot can be in it |
| Mission scheduling | Nearby missions are scheduled so robots don't arrive at the same point simultaneously |
| Waiting point | A robot waits at a safe point until the path is clear |
The ARCHO fleet can now operate without communication conflicts (thanks to Namespace and TF Prefix), and missions are intelligently distributed among the robots (thanks to the Fleet Manager) — without two ARCHOs colliding in a narrow aisle.
ARCHO Project now operates in the warehouse as a three-robot fleet with independent Namespaces and TF Prefixes, plus a simple Fleet Manager for mission assignment and aisle reservation.
In Chapter 15 we'll learn how to package this whole system with Docker and automatically test and deliver it with CI/CD — the path that turns a ROS 2 project from "it works on my laptop" into a deployable product.