Open-RMF: coordinating robot fleets is not a commercial back office

External-source research synthesis, not an OfferSignal client result. Based on the retained October 2026 research and source-specific dates.

A facility may have several robot fleets sharing lanes, lifts, doors and work areas. The difficult problem is choosing a capable fleet, reserving shared space, handling battery and route constraints, and giving operators a way to intervene when the plan meets reality.

What Open-RMF coordinates

Open-RMF is an open-source, vendor-neutral orchestration layer maintained by the Open Source Robotics Alliance since 2024. A request can enter through its web/API or a Robot Operating System (ROS) message. Fleet adapters submit bids; fleet-specific task planners assess capability, route, time and battery; the dispatcher awards the task; and the traffic planner reserves space-time resources and resolves conflicts. An adapter issues a destination, mode or path command, while the dashboard reports state and permits intervention. Doors, lifts and building-management systems are intended integration targets. 1 3

A fleet may provide observation only, accept destination requests, accept pause/resume modes or accept complete paths. Demonstrations cover heterogeneous fleets, delivery, patrol, cleaning, workcells, charging-task injection, emergency parking and read-only vehicles whose predicted paths help controllable robots avoid them. Allocation is deterministic and planner-based, not an autonomous commercial agent: configurable criteria include fastest completion or lowest cost once tasks, locations and capabilities are represented. 3 7

RMF Web provides visualisation and task/API controls, but its default demonstration database is internal and non-persistent. Production persistence, identity, permissions and audit design remain implementation responsibilities. Free Fleet supplies a public adapter for ROS navigation stacks through Zenoh bridges, with stated ROS 2, Jazzy and Cyclone DDS dependencies. The community adapter catalogue includes lift and device integrations, but is limited and contribution-driven. 4 6 8

The evidence from Tartu

The strongest independent implementation evidence is a 2022 peer-reviewed report from Tartu University Hospital. A heterogeneous RMF-based system moved time-critical samples between an intensive-care unit and laboratory through crowded, narrow corridors. One PAL Robotics TIAGo completed a full-scale ICU-to-laboratory-to-ICU run involving two semi-automated doors; dispensing and ingest confirmation remained manual. The setup used Free Fleet, custom device controllers, tablets and a virtual private network. 9

This was a feasibility and implementation result, not a throughput or return-on-investment study. The paper says RMF was not yet fully mature, required custom setup for every device and did not support detecting congestion and waiting in a safe area. Legacy doors created battery, radio-frequency-identification exposure and cybersecurity problems, and multiple delivery robots had not yet been tested. The retained evidence reports no verified fleet-wide uptime, task-success rate, labour saving, cost reduction or revenue impact. 9

Maintainer statements in 2025 describe production deployments and reference Changi Airport, but provide no controlled denominator or site-level operating metrics. They should remain attributed deployment evidence, not measured business outcomes. The April 2026 roadmap proposes modular traffic, task, execution and dashboard components, broader interface integrations and advanced negotiation. Its staged adoption gates and unfixed dates make these future architecture signals, not delivered capabilities. 10 11

What it does not decide

Open-RMF can represent operational capability such as map position, footprint, speed, acceleration, battery, destinations, paths and supported task types. It does not establish product identity, engineering revision, supplier qualification, price, tax, contract, customer acceptance or maintenance planning. A custom machine request still needs governed product and engineering records, commercial rules and a qualified integration layer before validated device capabilities and available capacity enter RMF.

The failure chain is direct: a wrong map frame or unit can produce a bad path; stale state can make a schedule optimistic; an incorrect footprint, lift capability or battery model can strand a task; and a revision mismatch can send the wrong device command. Duties, VAT, sanctions, certificates and product liability remain external cross-border controls.

An illustrative industrial pilot

Illustratively, start with one site and one fleet plus shared infrastructure, or two fleets with a narrow workflow. Define versioned capability schemas, map ownership, safety overrides, human dispatch approval and persistent audit logs. Test valid, stale and conflicting data. Measure completion and exception rates, waiting time, intervention, deadlock and recovery—not just whether a simulated robot reaches a destination. Keep commercial and engineering authorities outside the orchestration layer.

Open-RMF is credible infrastructure for shared-space robot coordination after robots and workflows have been selected. It is not evidenced as supplier discovery, RFQ or configure-price-quote software, an engineering-record system, a contracting and invoicing layer, or a maintenance back office. Its Apache 2.0 core is free to use commercially, but deployment cost and support pricing are undisclosed and normally include modelling, adapters, integration, cybersecurity, commissioning and support. 5

Sources and next reading

Explore OfferSignal · Focused Business & AI Workshop · All research

References