rmf_demos gives you six Open-RMF worlds and a CLI to dispatch tasks

What Open-RMF does that a single fleet stack does not

The Open Robotics Middleware Framework, or Open-RMF, enables interoperability among heterogeneous robot fleets while managing robot traffic that share resources such as space, building infrastructure systems, lifts and doors, and other automation systems within the same facility.

Two further capabilities are named. Open-RMF handles task allocation and conflict resolution among its participants, which the README describes as de-conflicting traffic lanes and other resources. And these capabilities are provided by various libraries in the open-rmf repository, with the comprehensive documentation in the ROS 2 multi-robot book.

That first sentence is the whole argument for the framework. A robot fleet that is all one vendor, or one type, can be scheduled with a scheduler that assumes homogeneity. Mixed fleets, where a delivery robot, a scrubber and a humanoid lift share a lobby, need something that arbitrates between them rather than each system planning independently. The shared resources are the point: space, doors, lifts, and the corridors that are the alternative to those doors.

This repository, rmf_demos, contains demonstrations of those capabilities and serves as a starting point for working and integrating with Open-RMF. A separate, more polished demonstration using Nav2 and MoveIt is built into the Ionic Release Demo, which is worth knowing about if you want a working end to end example rather than a set of scenes.

The audience is robotics integrators and researchers, and the format is ROS 2, which is the entry requirement rather than an implementation detail.

Ubuntu 24.04, ROS 2 Kilted and Gazebo Ionic

The system requirements section is short and explicit about what the demos were built and tested on: Ubuntu 24.04 LTS, ROS 2 Kilted, and Gazebo Ionic.

The note that follows is the practical part for anyone arriving from an older setup. The main branches of the core RMF libraries are fully supported on ROS 2 Humble, Iron and Jazzy as well, but you will need to use the distro-specific branches for rmf_traffic_editor and rmf_simulation.

So the support matrix is not uniform. The core libraries travel on main, and the two development tools, the traffic editor where you draw the lanes and the simulation package, are pinned per distribution. If you are on Jazzy, you can use the core libraries from main, but you have to check out the Jazzy branch of those two packages, and the traffic editor in particular is the tool you will spend real time in, since it is where the map, the lanes and the places are defined.

The same split shows up in the container images, which are tagged per distribution, and the quick start commands are explicit that you should use the appropriate tag for different ROS 2 distributions.

The installation instructions themselves are not in this repository. They are in the open-rmf repository, which is the right place for them, since the demos are a set of packages inside a workspace rather than something you install with a package manager.

Six worlds, each with a different traffic problem

The demo worlds are the reason to look at this repository, because each one isolates a different kind of coordination problem.

The Hotel World consists of a lobby and 2 guest levels, with two lifts, multiple doors and 3 robot fleets with 4 robots between them. It demonstrates an integration of multiple fleets of robots with varying capabilities working together in a multi-level building, which makes it the most structurally interesting of the set. Multi-level means lifts, and lifts mean a shared resource that has to be arbitrated.

The Office World is an indoor office environment for robots to move through, including a beverage dispensing station, controllable doors and laneways integrated into RMF. It can also be run in secure mode using ROS 2 DDS-Security integration, with a separate document for that.

The Airport Terminal World shows robot interaction on a much larger map, with a lot more lanes, destinations, robots and possible interactions between robots from different fleets, robots and infrastructure, and robots and users. The README illustrates it in three views, the world as it looks in traffic_editor, the schedule visualiser in rviz, and the full simulation in gazebo.

The Clinic World, Campus World and Manufacturing and Logistics World complete the list. Between them they cover a building with many constrained spaces, a campus with outdoor routes, and a floor with industrial traffic, and the traffic editor is the tool that turns a floor plan into any of them.

Tasks are dispatched from the command line

Every world is launched as a ROS 2 launch file, and the tasks are dispatched with small Python entry points in the rmf_demos_tasks package.

The pattern for launching a world is the same each time. Source the workspace, then launch the world's file:

source ~/rmf_ws/install/setup.bash
ros2 launch rmf_demos_gz hotel.launch.xml

and the office world follows the same shape with its own workspace and launch file:

source ~/rmf_demos_ws/install/setup.bash
ros2 launch rmf_demos_gz office.launch.xml

Tasks are then submitted with ros2 run rmf_demos_tasks. The Hotel World demonstrates two task types, Loop and Clean, and the README gives the commands:

ros2 run rmf_demos_tasks dispatch_patrol -p restaurant  L3_master_suite -n 1 --use_sim_time
ros2 run rmf_demos_tasks dispatch_clean -cs clean_lobby --use_sim_time

The Office World shows Delivery and Loop. A delivery request moves a can of coke from the pantry to hardware_2:

ros2 run rmf_demos_tasks dispatch_delivery -p pantry -ph coke_dispenser -d hardware_2 -dh coke_ingestor --use_sim_time

and a patrol request moves a robot back and forth between two places:

ros2 run rmf_demos_tasks dispatch_patrol -p coe lounge -n 3 --use_sim_time

The flags are worth reading as a vocabulary. -p is the pickup place, -ph the pickup human or dispenser, -d the destination and -dh the destination ingester, -n a count of repetitions, -cs a cleaning set, and --use_sim_time tells the system to use simulated time so that the schedule advances with the simulation rather than the wall clock.

That last flag appears in every example, and it is a reminder that these are simulations. A dispatch command that returns instantly in a demo will block on real time in a building.

The web stack: api-server on 8000, dashboard on 3000

The RMF-Web quick start is a separate part of the repository, and it is the part that turns a simulation into something you can watch and command.

The backend API server runs in Docker with host network access using the default configuration, and is reachable at localhost:8000 by default:

docker run \
  --network host -it --rm \
  -e ROS_DOMAIN_ID=<ROS_DOMAIN_ID> \
  -e RMW_IMPLEMENTATION=<RMW_IMPLEMENTATION> \
  ghcr.io/open-rmf/rmf-web/api-server:kilted-nightly

# Use the appropriate tag for different ROS 2 distributions

The frontend dashboard runs the same way and is reachable at localhost:3000:

docker run \
  --network host -it --rm \
  ghcr.io/open-rmf/rmf-web/demo-dashboard:kilted-nightly

# Use the appropriate tag for different ROS 2 distributions

Two notes carry caveats. The API server is configurable by mounting the configuration file and setting the RMF_API_SERVER_CONFIG environment variable, and in the default configuration it uses an internal non-persistent database, so state does not survive a restart. The dashboard via Docker is not runtime-configurable and is best used for quick integrations and testing; to configure it you check out the rmf-web-dashboard-resources branch of this repository and follow the dashboard configuration section of the rmf-web project.

To connect the simulation to the web application, the server_uri launch parameter has to point at the running API server:

ros2 launch rmf_demos_gz office.launch.xml server_uri:="ws://localhost:8000/_internal"

With that set, the fleet adapter updates the api-server with the latest task and robot states, and you can monitor what is happening and initiate rmf tasks from the interactive dashboard.

The image tags are nightly builds for a specific distribution, kilted-nightly here, which is the same warning as the branch note: what you run is the current state of the main branch rather than a fixed release.

The package layout mirrors the framework's own structure

The top level of the repository is a set of ROS 2 packages rather than a single application, and the names map directly onto the concepts in the demos.

rmf_demos_gz holds the Gazebo launch files and the worlds themselves, which is where the launch files you saw come from. rmf_demos_tasks holds the task definitions and the dispatch entry points, which is where dispatch_patrol, dispatch_clean and dispatch_delivery live. rmf_demos_fleet_adapter holds the adapter that bridges a fleet into the framework, the component that the README says will update the api-server with the latest task and robot states once a server_uri is set. rmf_demos_maps holds the maps, and rmf_demos_assets the assets the worlds need, while rmf_demos_bridges is where the connections to other systems sit.

That separation is the part worth copying if you build your own deployment. The worlds, the tasks, the fleet adapter, the maps and the bridges are separate concerns in separate packages, which means a new fleet is a new adapter rather than a fork of the demo, and a new building is a new map and a new set of launch files rather than a new world.

The documentation lives in a docs/ directory, and the README points to docs/faq.md for answers to frequently asked questions, to the open-rmf repository for installation instructions, and to the user manual for the near-term Open-RMF roadmap. The Ionic Release Demo, which uses Nav2 and MoveIt, is the reference to look at when you want a complete example rather than the pieces.

Licence, maintenance and where the demos stop

The licence is Apache-2.0, which is the same permissive licence the core Open-RMF libraries use, so code in a demonstration can be lifted into a project without a licensing conversation.

The repository is not archived and the last push was on 2026-10-20, so the demos are being worked on alongside the framework. There are no GitHub releases, and the container images are tagged as nightly builds for a specific ROS 2 distribution. Read together, that means there is no fixed artefact to pin: what you run is the current state of the main branch, rebuilt continuously, and the README's own note about the main branches being fully supported on Humble, Iron and Jazzy is the same message in a different place.

That is fine for a demonstration, which is what this is. The repository says so itself, that it serves as a starting point for working and integrating with Open-RMF.

The limits are worth stating for anyone tempted to treat it as a product. The worlds are simulated, so every task command carries --use_sim_time and the scheduling behaviour you observe is not the behaviour of a real fleet. The default API server keeps its state in an internal non-persistent database, so restarting it loses the task history. The dashboard in Docker is not runtime-configurable. And the traffic editor and the simulation package are pinned per ROS 2 distribution, so a multi-distribution deployment is a real maintenance task rather than a free choice.

Use it to learn the shape of the framework, then build on the libraries rather than on the demonstrations.

Editorial conclusion

rmf_demos suits an engineer who needs to understand Open-RMF before committing to it, and to a team that wants a working multi-fleet simulation, task dispatch and traffic visualisation in an afternoon rather than a research project. It is the wrong repository to build on, since these are demonstrations rather than an application framework, and the wrong repository if you need a supported release, since the images are tagged nightly. Verify first that the ROS 2 distribution you plan to run matches the one the demos were built against, and read the FAQ in docs/faq.md before you assume a behaviour, because the demo worlds make assumptions about lanes and infrastructure that a real site will not satisfy.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. open-rmf/rmf_demos on GitHub
4. README