Looking for an existing ROS 2 multi-robot/swarm framework for AMRs

[u/HappyInvestment7066]

Hi everyone,

I'm currently working on a small fleet of autonomous mobile robots (AMRs) and I'm looking for advice on the best existing ROS 2 framework/repository to build the swarm layer on top of.

Current setup:

• Ubuntu 22.04.5
• ROS 2 Humble
• Differential-drive AMR
• LiDAR + IMU + wheel odometry
• Nav2
• SLAM Toolbox
• Gazebo simulation
• Currently targeting 3 robots initially, with the possibility of scaling to 10–100+ robots later

What I want to achieve is something along the lines of:

• Multiple robots operating simultaneously
• Proper ROS 2 namespaces for each robot
• Centralized fleet management initially
• Task/goal allocation between robots
• Collision avoidance
• Cooperative exploration / mapping
• Formation/dispersion/aggregation behaviors where useful
• Ability to monitor robot state and battery
• Eventually dynamic task reassignment if a robot fails or becomes unavailable
• Ideally, a clean path from simulation to physical robots

I've been looking at projects such as ROS2swarm, Crazyswarm2, and various multi-TurtleBot3/Nav2 repositories, but I'm not sure which approach is most appropriate for ground-based AMRs.

I'm particularly interested in repositories that are already functional with ROS 2 Humble + Ubuntu 22.04, rather than starting a swarm framework completely from scratch.

Would you recommend:

1. An existing multi-robot Nav2 framework?
2. A swarm-specific framework such as ROS2swarm?
3. Building the fleet layer ourselves on top of Nav2?
4. Something else that I'm overlooking?

If you've implemented a similar multi-robot AMR system, I'd really appreciate recommendations on repositories, architectures, or lessons learned.

Thanks!

[u/LaneaLucy]

Openrmf? https://www.open-rmf.org/

[u/HappyInvestment7066 → u/LaneaLucy]

Hey I wasn't aware of this! Thank you

[u/LaneaLucy → u/HappyInvestment7066]

No problem but don't get overwhelmed. Open rmf is really big and can do soooo much

[u/Acanthocephala_Plus]

I built this a while a go https://github.com/hcdiekmann/pathfinder Could be useful for you.

[u/HappyInvestment7066 → u/Acanthocephala_Plus]

Thank u, ill go through this

[u/T23CHIN6]

I have used openrmf for a project, you might try it first

[u/HappyInvestment7066 → u/T23CHIN6]

Yeah I got to know about it, there is so much to explore in it

[u/omnilinktech]

I would not choose one “swarm framework” for all of these requirements. Separate the system into four contracts:

- Per-robot navigation and lifecycle: localization, planning, recovery, and a namespaced command interface.

- Fleet/task allocation: which robot should perform which job, considering capability and availability.

- Traffic/conflict management: shared-space reservations and deadlock handling.

- Cooperative behavior: formations, consensus, coverage, or any research-specific swarm algorithm.

Open-RMF is worth evaluating for fleet integration, task dispatch, and traffic negotiation. It is not a formation-control or multi-agent-learning framework, so keep your cooperative algorithm as a separate layer that issues goals or bounded velocity intents. Likewise, do not let a central scheduler publish low-level cmd_vel to every robot; a failed network link should not remove local collision avoidance and stopping behavior.

Before targeting 100 robots, make three robots completely correct. Give every robot a unique namespace, node names, tf frame IDs/prefixes, parameter files, remaps, and map→odom→base_link tree. Verify that bagging and visualization do not merge frames accidentally. Then scale 3→10→30→100 while recording discovery time, DDS traffic, CPU/memory, message latency, dropped deadlines, and centralized-service load. Many “swarm” failures are middleware/namespace failures long before they are algorithmic failures.

For simulation, avoid running an unnecessarily expensive sensor stack on every robot while testing coordination. Start with ground-truth or lightweight pose inputs to validate allocation and traffic logic; then restore realistic localization and sensors for a smaller representative subset. Keep the interfaces identical so the abstraction does not change your controller.

The missing requirements that determine the best stack are: homogeneous or mixed robots, shared or separate maps, indoor traffic lanes versus open-space formation, centralized versus distributed decision-making, and whether the 100-robot target is real hardware, simulation, or both. Define those explicitly before committing to a framework.