Before proceeding, is there an existing issue or discussion for this?
Description
Hi Open-RMF maintainers,
The CHART team would like to contribute a set of hardware-tested capabilities developed under RMF 2.0 (Healthcare) back into upstream Open-RMF. We plan to propose them in small stages, starting with a minimal GoToZone slice and building up from there.
0. Stage overview
Progress tracker. Each stage ticks when all its PRs merge.
1. Background & motivation
We're the CHART team (Centre for Healthcare Assistive & Robotics Technology), based in Singapore, focused on healthcare robotics. CHART's involvement with Open-RMF goes back to the very beginning — we were one of the consortium members that built the framework from scratch. Since then Open-RMF has been operationalised in several Singapore public healthcare institutions on the RMF 1.0 baseline.
Between 2023 and early 2026, CHART worked on RMF 2.0 (Healthcare), a development project funded by Singapore's National Robotics Programme (NRP). The focus was on making Open-RMF more robust in dynamic, patient-centred environments: Emergency Departments, Operating Theatres, and similar hospital spaces where robots have to share tight, constantly-changing areas with people. Development wrapped up in January 2026.
One thing we'd like to emphasise up front: all of this was built on top of upstream Open-RMF. We've tried to track upstream where we could and layer our work on the existing architecture.
This issue, and the PRs that follow, are that contribute-back effort. It also follows on from a face-to-face discussion we had with @mxgrey earlier about the plan.
Everything here is of course subject to your review. We don't come in with a fixed design, and we fully expect to rework, rename, split, or reshape stages based on your feedback. We've broken the contribution into small stages for exactly this reason, so you can steer us early, before we over-commit to the wrong direction.
Thanks in advance for the time you'll spend on these reviews.
2. What's next — staged rollout
We'll be proposing the work as a sequence of stages, each scoped to be reviewable on its own. After each stage we'll pause, take in your feedback, and fold it into the next stage before opening more PRs.
The pacing is deliberate. We'd rather hear "please rework this" on a small slice than on a large one. If you'd prefer a different sequencing, different scoping, or a different structure altogether, we'll happily adjust.
3. Stages
Stages are listed in the order we currently plan to propose them. A few can be reviewed in parallel while the last three will go one at a time. Each description below is intentionally short, and the full design notes will accompany the actual PRs for each stage.
Stage A (current) — simple GoToZone
Dispatch a robot to a zone by name, without having to specify a waypoint. The new zone supervisor picks an available waypoint inside the zone. If the caller wants to influence that choice, they can pass modifiers along with the request.
Feature scope:
- A new task type
zone / GoToZone that takes a zone name.
- Optional modifiers:
group — prefer waypoints tagged with this group label.preferred_waypoints — an ordered preference list of waypoint names.orientation — a final-heading hint.
- A
zone_supervisor node that arbitrates allocations across fleets.
- A new
rmf_zone_msgs protocol (request / booking / rejection / revocation / manual-release).
- Zone-authoring UI in
traffic_editor, and zone rendering in rmf_visualization.
PR list:
| Repo |
PR |
Status |
rmf_internal_msgs |
PR#91 |
ready for review |
rmf_building_map_msgs |
PR#10 |
ready for review |
rmf_traffic |
PR#133 |
ready for review |
rmf_traffic_editor |
PR#544 |
ready for review |
rmf_task |
PR#136 |
ready for review |
rmf_ros2 |
PR#516 |
ready for review |
rmf_visualization |
PR#91 |
ready for review |
rmf_demos |
PR#350 |
ready for review |
Main PR is at the rmf_ros2 repo, PR#516.
Stages B & C & D (can be reviewed in parallel)
Stage B — zone and boundary closures
Closing a zone has two layers:
- A zone closure means the supervisor rejects new GoToZone requests for that zone, so no robot will be dispatched to enter it through the zone entry path.
- A boundary closure means any lane that touches or crosses the zone boundary is closed, so robots whose normal paths would pass through the zone are rerouted around it instead of 'entering' incidentally.
The two are independent and useful for temporary exclusion (cleaning, maintenance, an active incident) without having to edit the nav graph.
Stage C — sensor intelligence for GoToZone
Extend GoToZone so that the supervisor's waypoint selection can be informed by external sensor input at execution time. For example: a sensor telling us which parking spot inside the zone is actually free of obstacle right now. Opt-in, dispatches without sensor input keep working as in Stage A.
Stage D — sensor augmented robot localization
Robots tend to get lost in certain areas, either because the area is featureless or because the features are blocked by dynamic obstacles (e.g., moving shelves). This feature uses externally-mounted sensors to detect the robot's location in those areas and trigger an auto-relocalisation via RMF.
Stages E, F, G (can be reviewed in parallel)
Stage E — reconfigurable robots
Full integration for small-scale reconfigurable robots: multiple smaller units that can physically combine into a larger-footprint composite robot for heavier tasks (for example, towing or carrying larger payloads). Covers fleet modelling, task dispatch, and traffic/navigation for the composite form.
Stage F — remote intervention
A flexible way for an operator to step in on a robot mid-task, to pause, adjust, take over, or resume, without having to cancel and re-dispatch.
Stage G — mobile manipulator
Integration of mobile manipulators (a robot arm mounted on an AMR) into the RMF task framework, so that manipulation tasks like picking, placing, and cleaning can be orchestrated alongside existing mobile-base workflows.
Stages H, I, J (sequential, one at a time)
These three are all lift-related, and we want to propose them sequentially rather than in parallel. Each depends on the guidance we get on the previous one.
Stage H — neighbourhood-based multi-lift selection
Dynamic multi-lift selection that takes the lift server's dynamic assignments into account (lifts allocated on demand per request), rather than a static single-lift assignment.
Stage I — robot–human lift sharing
Let a robot share a lift with human passengers. The lift no longer needs to be in AGV-mode while a robot is using it.
Stage J — robot–robot lift sharing
Let more than one robot occupy the same lift at the same time: a simple shared-lift mode for cases where multiple robots are traveling between the same floors.
Before proceeding, is there an existing issue or discussion for this?
Description
Hi Open-RMF maintainers,
The CHART team would like to contribute a set of hardware-tested capabilities developed under RMF 2.0 (Healthcare) back into upstream Open-RMF. We plan to propose them in small stages, starting with a minimal
GoToZoneslice and building up from there.0. Stage overview
Progress tracker. Each stage ticks when all its PRs merge.
GoToZone(in review)GoToZone(parallel with B, D; not yet opened)1. Background & motivation
We're the CHART team (Centre for Healthcare Assistive & Robotics Technology), based in Singapore, focused on healthcare robotics. CHART's involvement with Open-RMF goes back to the very beginning — we were one of the consortium members that built the framework from scratch. Since then Open-RMF has been operationalised in several Singapore public healthcare institutions on the RMF 1.0 baseline.
Between 2023 and early 2026, CHART worked on RMF 2.0 (Healthcare), a development project funded by Singapore's National Robotics Programme (NRP). The focus was on making Open-RMF more robust in dynamic, patient-centred environments: Emergency Departments, Operating Theatres, and similar hospital spaces where robots have to share tight, constantly-changing areas with people. Development wrapped up in January 2026.
One thing we'd like to emphasise up front: all of this was built on top of upstream Open-RMF. We've tried to track upstream where we could and layer our work on the existing architecture.
This issue, and the PRs that follow, are that contribute-back effort. It also follows on from a face-to-face discussion we had with @mxgrey earlier about the plan.
Everything here is of course subject to your review. We don't come in with a fixed design, and we fully expect to rework, rename, split, or reshape stages based on your feedback. We've broken the contribution into small stages for exactly this reason, so you can steer us early, before we over-commit to the wrong direction.
Thanks in advance for the time you'll spend on these reviews.
2. What's next — staged rollout
We'll be proposing the work as a sequence of stages, each scoped to be reviewable on its own. After each stage we'll pause, take in your feedback, and fold it into the next stage before opening more PRs.
The pacing is deliberate. We'd rather hear "please rework this" on a small slice than on a large one. If you'd prefer a different sequencing, different scoping, or a different structure altogether, we'll happily adjust.
3. Stages
Stages are listed in the order we currently plan to propose them. A few can be reviewed in parallel while the last three will go one at a time. Each description below is intentionally short, and the full design notes will accompany the actual PRs for each stage.
Stage A (current) — simple
GoToZoneDispatch a robot to a zone by name, without having to specify a waypoint. The new zone supervisor picks an available waypoint inside the zone. If the caller wants to influence that choice, they can pass modifiers along with the request.
Feature scope:
zone/GoToZonethat takes a zone name.group— prefer waypoints tagged with this group label.preferred_waypoints— an ordered preference list of waypoint names.orientation— a final-heading hint.zone_supervisornode that arbitrates allocations across fleets.rmf_zone_msgsprotocol (request / booking / rejection / revocation / manual-release).traffic_editor, and zone rendering inrmf_visualization.PR list:
rmf_internal_msgsrmf_building_map_msgsrmf_trafficrmf_traffic_editorrmf_taskrmf_ros2rmf_visualizationrmf_demosMain PR is at the rmf_ros2 repo, PR#516.
Stages B & C & D (can be reviewed in parallel)
Stage B — zone and boundary closures
Closing a zone has two layers:
The two are independent and useful for temporary exclusion (cleaning, maintenance, an active incident) without having to edit the nav graph.
Stage C — sensor intelligence for
GoToZoneExtend
GoToZoneso that the supervisor's waypoint selection can be informed by external sensor input at execution time. For example: a sensor telling us which parking spot inside the zone is actually free of obstacle right now. Opt-in, dispatches without sensor input keep working as in Stage A.Stage D — sensor augmented robot localization
Robots tend to get lost in certain areas, either because the area is featureless or because the features are blocked by dynamic obstacles (e.g., moving shelves). This feature uses externally-mounted sensors to detect the robot's location in those areas and trigger an auto-relocalisation via RMF.
Stages E, F, G (can be reviewed in parallel)
Stage E — reconfigurable robots
Full integration for small-scale reconfigurable robots: multiple smaller units that can physically combine into a larger-footprint composite robot for heavier tasks (for example, towing or carrying larger payloads). Covers fleet modelling, task dispatch, and traffic/navigation for the composite form.
Stage F — remote intervention
A flexible way for an operator to step in on a robot mid-task, to pause, adjust, take over, or resume, without having to cancel and re-dispatch.
Stage G — mobile manipulator
Integration of mobile manipulators (a robot arm mounted on an AMR) into the RMF task framework, so that manipulation tasks like picking, placing, and cleaning can be orchestrated alongside existing mobile-base workflows.
Stages H, I, J (sequential, one at a time)
These three are all lift-related, and we want to propose them sequentially rather than in parallel. Each depends on the guidance we get on the previous one.
Stage H — neighbourhood-based multi-lift selection
Dynamic multi-lift selection that takes the lift server's dynamic assignments into account (lifts allocated on demand per request), rather than a static single-lift assignment.
Stage I — robot–human lift sharing
Let a robot share a lift with human passengers. The lift no longer needs to be in AGV-mode while a robot is using it.
Stage J — robot–robot lift sharing
Let more than one robot occupy the same lift at the same time: a simple shared-lift mode for cases where multiple robots are traveling between the same floors.