The Open Robotics Middleware Framework (Open-RMF) enables interoperability among heterogeneous robot fleets while managing robot traffic that share resources such as space, building infrastructure systems (lifts, doors, etc) and other automation systems within the same facility. Open-RMF also handles task allocation and conflict resolution among its participants (de-conflicting traffic lanes and other resources). These capabilities are provided by various libraries in Open-RMF. For more details about Open RMF, refer to the comprehensive documentation provided here.
This repository contains demonstrations of the above mentioned capabilities of RMF. It serves as a starting point for working and integrating with Open-RMF.
These demos were developed and tested on
Note: RMF is fully supported on ROS 2 Foxy as well
Instructions can be found here.
Answers to frequently asked questions can be found here.
A near-term roadmap of the Open-RMF project can be found in the user manual here.
Full web application of Open-RMF: rmf-web.
In order to interact with the default configuration of the web application, the server_uri
launch parameter will need to be changed to ws://localhost:8000/_internal
, for example,
ros2 launch rmf_demos_gz office.launch.xml server_uri:="ws://localhost:8000/_internal"
By specifying server_uri
, the fleetadapter will update rmf-web
api-server
with the latest task and robot states. User can then monitor on-going states and initiate rmf task with an interactive web dashboard.
- Hotel World
- Office World
- Airport Terminal World
- Clinic World
- Campus World
- Manufacturing & Logistics World
Note: When running the demos on Ubuntu 18.04 (not officially supported), you are required to explicitly supply gazebo_version launch argument. Eg: ros2 launch rmf_demos_gz_classic office.launch.xml gazebo_version:=9
To run the demos using Ignition instead of Gazebo, change the commands from
ros2 launch rmf_demos_gz_classic [...]
toros2 launch rmf_demos_gz [...]
Click this link: https://open-rmf.github.io/rmf-panel-js/
For a full-proof web application of Open-RMF, please refer to rmf-web.
The RMF panel is a web based dashboard for interacting with rmf_demos. It allows users to send task requests to RMF and monitor the status of robots and submitted tasks. For more details.
There are two main modes of submitting tasks to Open-RMF via the Panel:
- Submit a Task: Used to submit a single task.
- Submit a List of Tasks: Used to submit a batch of tasks. A
.json
file containing a list of tasks may be loaded via theChoose file
button. Some example files are found inrmf_demos_panel/task_lists
.
LATEST UPDATE: Display Task States
task_state_uptates
are now published via websocket. To display task states on rmf-panel
, specify server_uri:="ws://localhost:7878"
during ros2 launch. Example:
ros2 launch rmf_demos_gz_classic office.launch.xml server_uri:="ws://localhost:7878"
This will let Open-RMF (websocket clients) to publish their states to port 7878
. In this case, rmf-panel's api_simple_server
is the websocket server.
This hotel world consists of a lobby and 2 guest levels. The hotel has two lifts, multiple doors and 3 robot fleets (4 robots). This demonstrates an integration of multiple fleets of robots with varying capabilities working together in a multi-level building.
To launch the world and the schedule visualizer,
source ~/rmf_ws/install/setup.bash
ros2 launch rmf_demos_gz_classic hotel.launch.xml
# Or, run with ignition simulator
ros2 launch rmf_demos_gz hotel.launch.xml
Here, we will showcase 2 types of Tasks: Loop and Clean
Open RMF Panel to submit clean or loop requests.
To submit a loop task, select Loop
from the Select a request type
dropdown list. Choose desired start and end locations and click submit. Similarly for Clean task, select Clean
, then choose the desired cleaning zone
from the dropdown list.
Or, dispatch robot via CLI
ros2 run rmf_demos_tasks dispatch_clean -cs clean_lobby --use_sim_time
ros2 run rmf_demos_tasks dispatch_patrol -p restaurant L3_master_suite -n 1 --use_sim_time
Robots running Clean and Loop Task:
To submit a list of scheduled tasks via rmf web panel, load hotel_tasks.json, or paste the json list to the Submit a List of Tasks section. Next, click on submit.
Tip: To speedup simulation on gazebo, user can run
gz physics -s 0.01
on a separate terminal after launching the world. Use with care!
An indoor office environment for robots to navigate around. It includes a beverage dispensing station, controllable doors and laneways which are integrated into RMF.
source ~/rmf_demos_ws/install/setup.bash
ros2 launch rmf_demos_gz_classic office.launch.xml
# Or, run with ignition simulator
ros2 launch rmf_demos_gz office.launch.xml
Now we will showcase 2 types of Tasks: Delivery and Loop
To send task requests, open rmf_demos web panel: https://open-rmf.github.io/rmf-panel-js/
To submit a delivery task, select Delivery
from the Select a request type
dropdown list. Next, select coke
from the Select delivery task
list. Choose an desired start time for task and click submit.
Or, submit a task via CLI:
ros2 run rmf_demos_tasks dispatch_patrol -p coe lounge -n 3 --use_sim_time
ros2 run rmf_demos_tasks dispatch_delivery -p pantry -ph coke_dispenser -d hardware_2 -dh coke_ingestor --use_sim_time
To submit a loop task, select Loop
from the Select a request type
dropdown list. Choose desired start and end locations and click submit.
To run a scenario with multiple task requests, load office_tasks.json from rmf_demos_panel/task_lists
in the Submit a list of tasks
section. This should populate the preview window with a list of tasks. Click submit and watch the demonstration unfold.
The office demo can be run in secure mode using ROS 2 DDS-Security integration. Click here to learn more.
This demo 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, as well as robots and users. In the illustrations below, from top to bottom we have how the world looks like in traffic_editor
, the schedule visualizer in rviz
, and the full simulation in gazebo
,
In the airport world, we introduce a new task type to rmf: Clean
. To launch the world:
source ~/rmf_ws/install/setup.bash
ros2 launch rmf_demos_gz_classic airport_terminal.launch.xml
Open RMF Panel. Load the airport_terminal_tasks.json list and click submit to begin a collection of loop, delivery and cleaning tasks.
Or, submit loop
, delivery
or clean
task via CLI:
ros2 run rmf_demos_tasks dispatch_patrol -p s07 n12 -n 3 --use_sim_time
ros2 run rmf_demos_tasks dispatch_delivery -p mopcart_pickup -ph mopcart_dispenser -d spill -dh mopcart_collector --use_sim_time
ros2 run rmf_demos_tasks dispatch_clean -cs zone_3 --use_sim_time
To see crowd simulation in action, enable crowd sim by:
ros2 launch rmf_demos_gz_classic airport_terminal.launch.xml use_crowdsim:=1
Non-autonomous vehicles can also be integrated with Open-RMF provided their positions can be localized in the world. This may be of value at facilities where space is shared by autonomous robots as well as manually operated vehicles such as forklifts or transporters. In this demo, we can introduce a vehicle (caddy) which can be driven around through keyboard/joystick teleop. In Open-RMF nomenclature, this vehicle is classified as a read_only
type, ie, Open-RMF can only infer its position in the world but does not have control over its motion. Here, the goal is to have other controllable robots avoid this vehicle's path by replanning their routes if needed. The model is fitted with a plugin which generates a prediction of the vehicle's path based on its current heading. It is configured to occupy the same lanes as the tinyRobot
robots. Here, a read_only_fleet_adapter
submits the prediction from the plugin to the Open-RMF schedule.
In the airport terminal map, a Caddy
is spawned in the far right corner and can be controlled with geometry_msgs/Twist
messages published over the cmd_vel
topic.
Run teleop_twist_keyboard
to control the caddy
with your keyboard:
# Default launch with gazebo
ros2 run teleop_twist_keyboard teleop_twist_keyboard
# if launched with the Ignition simulator
ros2 launch rmf_demos_gz airport_terminal_caddy.launch.xml
Tip: To speedup simulation on gazebo, user can run
gz physics -ps 0.01
on a separate terminal after launching the world. Use with care!
This is a clinic world with two levels and two lifts for the robots. Two different robot fleets with different roles navigate across two levels by lifts. In the illustrations below, we have the view of level 1 in traffic_editor
(top left), the schedule visualizer in rviz
(right), and the full simulation in gazebo
(bottom left).
To launch the world and the schedule visualizer,
source ~/rmf_ws/install/setup.bash
ros2 launch rmf_demos_gz_classic clinic.launch.xml
Open RMF Panel. Load the clinic_tasks.json list and click submit to begin a collection of loop and delivery tasks.
Or, submit a task via CLI:
ros2 run rmf_demos_tasks dispatch_patrol -p L1_left_nurse_center L2_right_nurse_center -n 5 --use_sim_time
ros2 run rmf_demos_tasks dispatch_patrol -p L2_north_counter L1_right_nurse_center -n 5 --use_sim_time
Robots taking lift:
Multi-fleet demo:
This is a larger scale "Campus" World. In this world, there are multiple delivery robots that operate. The world is designed and traffic lanes are annotated at the planet scale, using GPS WGS84 coordinates. Each robot is also streaming its location in WGS84 coordinates, which are processed by its fleet adapter. This demo intends to show the potential of Open-RMF on a large scale map.
To launch the world and the schedule visualizer,
source ~/rmf_ws/install/setup.bash
ros2 launch rmf_demos_gz campus.launch.xml
ros2 run rmf_demos_tasks dispatch_patrol -p room_5 campus_4 -n 10 --use_sim_time
ros2 run rmf_demos_tasks dispatch_patrol -p campus_5 room_3 -n 10 --use_sim_time
ros2 run rmf_demos_tasks dispatch_patrol -p room_2 dead_end -n 10 --use_sim_time
fleet_robotmanager_mqtt_bridge
can be used to publish robot locations, battery percentage and state to a /robot/status/ROBOT-ID
websocket endpoint. An instance of RobotManager can be configured to subscribe to this server to receive json messages, which will in turn visualize the robots on RobotManager.
# Install the prerequisites
sudo apt install mosquitto mosquitto-clients
# Start the bridge
ros2 run rmf_demos_bridges fleet_robotmanager_mqtt_bridge -y 31500 -x 22000
The json messages for the first robot can be echoed using the following example command,
mosquitto_sub -t /robot/status/00000000-0000-0000-0000-000000000001
An Open-RMF simulation demonstration created by ROS-Industrial Asia Pacific showcasing workcell (conveyor and fixed manipulator), multiple AMR fleets and infrastructure interoperability using the Open Robotics Middleeware Framework (Open-RMF).
[![Alt text](https://img.youtube.com/vi/oSVQrjx_4w4/0.jpg)](https://www.youtube.com/watch?v=oSVQrjx_4w4)
Open-RMF can also manage fleets whose API or fleet managers only offer pause and resume commands to control their robots. Such fleets are classified as traffic_light
. To integrate a traffic_light
fleet, users are expected to implement a traffic_light
fleet adapter based on this API. The rmf_demos
repository contains demonstrations of traffic_light
fleets in various scenarios. A simplistic mock_traffic_light
adapter is used in these demonstrations.
$ ros2 launch rmf_demos_gz_classic triple_H.launch.xml
(new terminal) $ ros2 launch rmf_demos the_pedigree.launch.xml
$ ros2 launch rmf_demos_gz_classic battle_royale.launch.xml
(new terminal) $ ros2 launch rmf_demos battle_go.launch.xml
Note that tinyRobot1
is a standard "full control" robot, while tinyRobot2
"traffic light" robot.
$ ros2 launch rmf_demos_gz_classic office_mock_traffic_light.launch.xml
(new terminal) $ ros2 launch rmf_demos office_traffic_light_test.launch.xml
-
Flexible Tasks Scripts For more details.
-
lift watchdog
- The robot can query an external
lift_watchdog_server
for the permission to enter the lift cabin during theLiftSession
Phase. - Command lines:
# run hotel world with lift_watch_dog enabled ros2 launch rmf_demos_gz_classic hotel.launch.xml enable_experimental_lift_watchdog:=1 ## On a separate terminal, set lift as crowded ros2 launch rmf_demos experimental_crowded_lift.launch.xml # Dispatch robot from level1 to level3, robot will wait in front of the lift cabin ros2 run rmf_demos_tasks dispatch_patrol -p L3_room1 L3_room1 -n 1 --use_sim_time # Lift is cleared. Give robot the permission to enter the lift ros2 launch rmf_demos experimental_clear_lift.launch.xml
- The robot can query an external
-
Custom Docking Sequence
- Fleet adapter will notify the robot (via
dock()
api/ModeRequest) to execute its custom dock sequence when the robot reaches a "dock" waypoint. - Implementation is similar to Clean task, refer to docs here
- Fleet adapter will notify the robot (via
-
Emergency Alarm
- All robots will get directed to the nearest parking spot when the emergency alarm is triggered.
- Command lines:
# toggle alarm ON ros2 topic pub -1 /fire_alarm_trigger std_msgs/Bool '{data: true}' # toggle alarm OFF ros2 topic pub -1 /fire_alarm_trigger std_msgs/Bool '{data: false}'
In Open-RMF version 21.04
and above, tasks are awarded to robot fleets based on the outcome of a bidding process that is orchestrated by a Dispatcher node, rmf_dispatcher_node
. When the Dispatcher receives a new task request from a UI, it sends out a rmf_task_msgs/BidNotice
message to all the fleet adapters. If a fleet adapter is able to process that request, it submits a rmf_task_msgs/BidProposal
message back to the Dispatcher with a cost to accommodate the task. An instance of rmf_task::agv::TaskPlanner
is used by the fleet adapters to determine how best to accommodate the new request. The Dispatcher compares all the BidProposals
received and then submits a rmf_task_msgs/DispatchRequest
message with the fleet name of the robot that the bid is awarded to. There are a couple different ways the Dispatcher evaluates the proposals such as fastest to finish, lowest cost, etc which can be configured.
Battery recharging is tightly integrated with the new task planner. ChargeBattery
tasks are optimally injected into a robot's schedule when the robot has insufficient charge to fulfill a series of tasks. Currently we assume each robot in the map has a dedicated charging location as annotated with the is_charger
option in the traffic editor map.