Open-RMF coordinates tasks across robot fleets and facility resources; its fleet adapter translates between RMF and a vendor’s robot system. It does not replace the vendor fleet manager, robot safety controls or interoperability standards such as VDA 5050 and ISO 21423.
It does not replace the robot’s localization, SLAM, obstacle avoidance or low-level motion control. A connected adapter can still send the robot to the wrong place if maps, frames, waypoints or time are inconsistent. Successful integration requires state agreement and recovery, not only message exchange.
Use this guide with the fleet allocation guide and robot frame guide. Begin with simulated and single-resource tests before expanding to a facility.
Place Open-RMF at the orchestration layer
The official Open-RMF repository describes a platform for multi-fleet robot management. It coordinates tasks, traffic and shared infrastructure above vendor navigation systems. Draw this layer boundary before assigning failures or promising that RMF will repair a robot-local perception defect.
List every system of record: task, robot state, map, door, lift and user authority. Define which component can command and which only observes. Two authoritative writers for one robot or facility session create conflicting recovery even when each API works correctly.
Trace a task from dispatch to robot execution
A task request enters a dispatcher, candidate fleets evaluate it, and an award selects an executor. The fleet adapter then converts the task into vendor-specific plans or commands and reports progress. Preserve task identity and state across every translation.
Record request time, bid or estimate, award, adapter acceptance, robot execution and completion. Reject duplicate or expired awards idempotently. A dispatcher success should not become final task success until the physical workflow and required delivery evidence are complete.
| Boundary | Input | Output | Primary failure |
|---|---|---|---|
| Dispatcher to fleet | Task and constraints | Award | No feasible or stale bid |
| RMF to adapter | Plan and itinerary | Vendor request | Translation mismatch |
| Adapter to robot | Vendor command | Robot state | Rejected or stale command |
| RMF to door | Access request | Door session/state | Wrong owner or no response |
| RMF to lift | Floor and cabin session | Lift state | Session or occupancy conflict |
What an Open-RMF fleet adapter owns—and what it does not
The adapter maps robot names, poses, battery, mode, path progress and task commands between RMF and a vendor fleet API. Write conversion rules for every field, unit, state and error. Do not infer active motion from a heartbeat or convert an unknown vendor state into Idle.
The Free Fleet repository offers an integration path for supported systems, but production contracts remain vendor specific. Measure adapter update rate, age and reconnection behavior. Preserve raw vendor errors beside normalized RMF state.
Understand the time dimension of traffic schedules
RMF traffic coordination uses planned trajectories and time, not only occupied map points. Delays, path changes and pauses should update the itinerary so other participants negotiate against current intent. A robot that deviates locally without schedule update can invalidate conflict predictions.
Synchronize clocks well enough for the chosen schedule tolerance and monitor data age. Test delayed updates and reconnection. Use the robot time synchronization guide to separate clock offset from network or adapter latency.
Connect door intent to facility state
A door adapter translates a requested access session into actual building control and state. Model requester, target mode, current mode, timeout and release. The robot should not cross the threshold because an open command was sent; it needs verified door state and route clearance.
Test denied access, slow opening, obstruction, manual override, controller restart and a robot stopping in the doorway. Define whether RMF waits, reroutes or cancels. Facility safety and access control retain authority over the door.
| Facility test | Injected condition | Expected orchestration | Required evidence |
|---|---|---|---|
| Door delay | Late open state | Robot waits before threshold | Request and verified state |
| Door denial | Access rejected | Reroute or fail task | Reason and authority |
| Lift session loss | Owner disappears | Bounded cleanup | Cabin and robot occupancy |
| Wrong floor | State mismatch | No exit command | Floor sensors and session |
| Manual override | Human changes equipment | Suspend automation | Mode and operator identity |
Treat lift use as a session and occupancy problem
A lift workflow includes calling, acquiring a cabin session, verifying the correct cabin and floor, entering, selecting or requesting destination, riding, verifying arrival, exiting and releasing. A single button command cannot represent these ownership and occupancy states.
Test another user entering, doors reopening, floor mismatch, lost robot localization and communication loss inside the cabin. Decide who can release a stale session. Use physical occupancy evidence before assigning the cabin to another robot.
Align map names, frames and waypoint semantics
RMF maps, vendor maps and facility floor names may use different origins, scale, axes and identifiers. Calibrate transforms with multiple surveyed points and verify heading, not only one translation. A numerically valid conversion can mirror or rotate the route.
Version map transformations and waypoints. Test entry and exit points for every door and lift from both directions. Reject unknown map names explicitly; silently using a default floor can move a robot toward the wrong physical location.
Track component state across one workflow
For each task, correlate dispatcher state, adapter state, vendor task, robot pose and mode, traffic itinerary, facility requests and resource sessions. Put timestamps and identifiers in one trace. This makes the earliest disagreement visible.
Avoid a single green Integrated indicator. Expose stale data, session owner and last successful transition. When the robot stops before a door, operators should know whether it is waiting for traffic, access, door state, navigation or adapter acknowledgment.
Assign fault ownership before automatic recovery
Classify failures as robot-local, vendor fleet, adapter, RMF core, network or facility. Define which layer retries and which only reports. Multiple layers retrying the same command can create duplicates, route churn or repeated door operation.
Preserve the first fault and each recovery attempt. Limit retries and require changed evidence. A building controller that reports persistent failure should escalate to facility operations, not trigger endless robot replanning.
Integrate from simulation to one resource at a time
Use the Open-RMF demonstrations to understand flows, then connect a simulated fleet adapter. Move to one physical robot, one corridor, one door and one lift floor before enabling many concurrent tasks.
At every stage, repeat normal and failed workflows, cancellation, restart and manual takeover. Freeze versions of ROS 2, Open-RMF packages, adapters and facility APIs. Expand only when evidence and rollback are reproducible.
Keep VDA 5050 and Open-RMF at distinct boundaries
VDA 5050 specifies a communication interface between a central control and mobile robots, while Open-RMF provides broader multi-fleet and facility orchestration. They can intersect through an adapter, but naming both does not define the mapping or responsibility.
Document which component acts as master control, how orders and states map, and who owns traffic and facility resources. Use the VDA 5050 guide to test protocol behavior independently, then compare its scope with ISO 21423 in the VDA 5050 versus ISO 21423 guide.
Close security, manual recovery and operations
Authenticate control interfaces, segment networks and restrict who can dispatch, open facilities or override sessions. Log operator actions. Define safe manual recovery for a robot or lift stranded between normal states, including physical access and task reconciliation.
Release with a boundary checklist.
- Assign one authority for each task, robot and facility state.
- Validate map and time conversions with measured evidence.
- Test doors and lifts as owned sessions.
- Bound retries at one responsible layer.
- Prove restart, manual takeover and state reconciliation.
Frequently asked questions
Does Open-RMF replace robot SLAM and navigation?
No. It coordinates fleets, traffic and resources while vendor or robot systems retain localization and motion control.
Is a vendor API enough to build a fleet adapter?
Only if it exposes the commands, state, timing, cancellation and error semantics required by the integration contract.
Must every door and lift use one protocol?
No. Resource-specific adapters can translate different protocols, but state and session semantics must be consistent.
Must a project choose between Open-RMF and VDA 5050?
Not necessarily. They occupy different scopes and can be connected through a defined adapter and authority model.
Which failure should be tested first?
Start with stale or lost state at each boundary because it reveals authority, timeout and recovery assumptions quickly.
Orchestration and Facility Control Boundary
Open-RMF orchestration does not override robot safety, building access control, lift safety or emergency procedures. Those systems retain their required authority.