Open-RMF (Open Robotics Middleware Framework) is an open-source collection of libraries and tools built on ROS 2 that enables interoperability among heterogeneous robot fleets. It manages shared resources — space, doors, lifts, corridors, dispensers — so that robots from different manufacturers can coexist in the same facility without collisions or deadlocks.
Since 2024, Open-RMF is managed by the Open Source Robotics Alliance (OSRA). It is licensed under Apache 2.0 — fully commercial-friendly, no copyleft, no patent traps.
Centralized schedule database with look-ahead conflict detection. When robots' trajectories intersect, a peer-to-peer negotiation protocol (similar to conflict-based search) proposes alternative routes, speed changes, or pauses.
rmf_trafficCompetitive bidding system where a Dispatcher broadcasts task requests to all fleet adapters. Each fleet responds with a cost/time bid using rmf_task::agv::TaskPlanner. Best bid wins. Supports composed tasks with phases.
rmf_taskTranslation layer between proprietary robot APIs and standardized Open-RMF protocols. Four control levels: Full Control, Traffic Light, Read Only, and No Interface. Python API via EasyFullControl.
rmf_fleet_adapterStandardized interfaces for doors, lifts, and dispensers. Robots can request door opens, summon elevators, and trigger dispensing stations through uniform ROS 2 messages — regardless of manufacturer.
rmf_building_mapGUI tool to annotate building floor plans with navigation graphs, lanes, waypoints, charger locations, doors, and lifts. Exports navigation graphs consumed by fleet adapters for path planning.
rmf_traffic_editorReact 18 + TypeScript frontend with FastAPI backend. Real-time fleet visualization on building maps, task dispatching, infrastructure control. Socket.IO for live updates, Keycloak for auth.
rmf-webOpen-RMF solves the hardest multi-robot coordination problems — traffic deconfliction, cross-fleet task bidding, and infrastructure arbitration — that TwinSight's proposal currently leaves to custom implementation. Rather than reinventing these algorithms, TwinSight can adopt Open-RMF's battle-tested core and focus engineering effort on its differentiators: the web-native monitoring UX, telemetry analytics pipeline, and business intelligence layer.
Open-RMF follows a layered architecture where fleet adapters bridge individual robots to a centralized coordination core. The web layer provides human oversight.
Open-RMF's adapter hierarchy (Full Control → Traffic Light → Read Only → No Interface) maps directly to TwinSight's real-world challenge: some robot manufacturers will provide full API access, others will only allow monitoring. The adapter framework gives TwinSight a structured way to handle this heterogeneity without custom code for each integration level.
Understanding what each Open-RMF component actually does at the code level — and how mature it is.
The traffic system is the crown jewel of Open-RMF. It maintains a centralized schedule database that stores the predicted trajectories of every robot in the facility — projected into the future.
A living, dynamic database that stores intended robot trajectories. It changes over time to reflect delays, cancellations, and route changes. Every fleet adapter reports its robots' expected itineraries here.
Continuously analyzes the schedule to identify future conflicts — where robot trajectories will intersect in space and time. This is prevention-first: detect before it happens.
When conflicts are inevitable, a peer-to-peer negotiation begins. Each fleet manager submits preferred itineraries. Others respond with accommodating alternatives. A third-party judge selects the optimal arrangement.
Uses time-dependent A* search that plans through both space and time, accounting for other agents in the schedule. For AGVs on predefined grids. AMR support (ad-hoc paths) is planned for future versions.
The planner currently works best with AGVs on predefined navigation graphs. For AMRs that navigate freely (like many modern robots), the traffic system can still track their positions and detect conflicts, but the path planning optimization is limited. This is an active area of development.
The task system handles how work gets assigned to robots across multiple fleets.
User or system submits a task (patrol, delivery, clean, or composed task) via the web dashboard or API.
The rmf_dispatcher_node sends a BidNotice message to all fleet adapters. Any fleet that can handle the task type participates.
Each fleet adapter uses its rmf_task::agv::TaskPlanner instance to calculate the optimal robot, considering current tasks, battery levels, and travel time. Returns a cost estimate.
Dispatcher compares proposals (fastest finish, lowest cost, configurable criteria) and sends a DispatchRequest to the winning fleet.
Fleet adapter executes the task. ChargeBattery tasks are automatically injected into the schedule when battery levels are insufficient for the next task.
Native task types include Patrol (loop between waypoints), Delivery (pick-up → drop-off), and Clean (floor cleaning). Custom tasks can be defined via Composed Requests — sequences of phases (navigate, dock, perform action, etc.) chained together.
Every robot fleet needs a fleet adapter — this is where the rubber meets the road for any Open-RMF deployment.
| Control Level | Capabilities | API | When to Use |
|---|---|---|---|
| Full Control | Complete path direction, pause/resume, battery monitoring, task management, infrastructure interaction | C++ with Python bindings (EasyFullControl) | Robots with full API access — you can tell them where to go, when to stop, and query their state |
| Traffic Light | Read robot status, pause and resume movement | Custom integration via core APIs | Robots with their own planner but that accept stop/go commands |
| Read Only | Monitor position and status — no control | Preliminary ROS 2 messaging | Robots you can observe but not command (e.g., third-party fleets sharing a space) |
| No Interface | None — incompatible with RMF | N/A | Legacy robots with no external API. Must be handled by safety margins and human oversight. |
To build a Full Control fleet adapter, you implement a RobotClientAPI class with methods like navigate(), position(), battery_soc(), is_command_completed(), and stop(). The fleet_adapter_template repo provides a working starting point.
Open-RMF provides standardized ROS 2 message interfaces for common building infrastructure elements. This is critical for multi-floor deployments.
Publishes DoorState and accepts DoorRequest messages. Supports open/close/hold modes. Fleet adapters automatically request door access when a robot's planned path requires it.
Manages elevator arbitration between robots and humans. Publishes LiftState (current floor, door status, motion state) and handles LiftRequest for summoning.
For automated pickup/dropoff stations. DispenserRequest triggers item release; IngestorRequest triggers item acceptance. Both report state via their respective state messages.
If TwinSight is deployed in facilities with shared infrastructure (warehouses with automatic doors, hospitals with elevators, factories with dispensing stations), these interfaces save enormous integration effort. If TwinSight only targets open-floor facilities, this component has lower value — but it's there when you need it.
The web layer is particularly interesting for TwinSight because it shares many architectural choices.
| Component | rmf-web | TwinSight (Proposed) | Alignment |
|---|---|---|---|
| Frontend | React 18 + TypeScript + MUI v5 + Three.js | Ionic + Angular + TypeScript | Different frameworks |
| Backend | FastAPI v0.109 (Python) | FastAPI (Python) | Identical choice |
| Real-time | Socket.IO (python-socketio ~5.11) | WebSocket (native) | Compatible pattern |
| Auth | JWT + Keycloak (OpenID Connect) | JWT + RBAC (custom) | Similar approach |
| ORM | Tortoise ORM (async, SQLite/PostgreSQL) | SQLAlchemy (PostgreSQL) | Different but compatible |
| ROS 2 Bridge | RmfGateway class (in-process ROS node) | ROS Adapter (separate service) | Different topology |
| Models | Auto-generated from ROS IDL via Jinja2 | Manual Pydantic models | Adopt code generation |
The backends are nearly identical (FastAPI). The code generation pipeline (ROS IDL → Pydantic models + TypeScript types) is a genuine time-saver TwinSight should adopt. The frontend is different (React vs Angular), so TwinSight should keep its own UI but can use rmf-web's API server as a reference architecture — or even embed it as an internal microservice behind TwinSight's gateway.
A clear mapping of where the two platforms overlap, complement each other, and where each has unique strengths.
| Capability | TwinSight (Proposed) | Open-RMF | Verdict |
|---|---|---|---|
| Fleet Visualization | Custom web dashboard with map view, real-time robot positions | React dashboard with 2D/3D building maps, fleet overlays | USE OPENRMF for map rendering, build custom UX on top |
| Traffic Deconfliction | Not specified in proposal | Full schedule database + negotiation protocol + A* planner | USE OPENRMF — this is 3-6 months of custom work saved |
| Task Dispatch | Mission system (Created → Assigned → Running → Completed/Failed) | Competitive bidding, phase-based composition, auto battery scheduling | ADAPT — use RMF bidding for allocation, TwinSight for business workflow |
| Multi-Fleet Support | Planned but architecture unclear | Core design — every component assumes multiple heterogeneous fleets | USE OPENRMF — heterogeneous fleet management is its raison d'être |
| ROS 2 Bridge | Zenoh bridge architecture (designed in previous analysis) | Fleet adapters (C++/Python) + free_fleet (Zenoh-based) | ADAPT — free_fleet aligns perfectly with TwinSight's Zenoh strategy |
| Telemetry Storage | TimescaleDB (time-series) + Redis (hot) + PostgreSQL (business) | Tortoise ORM (SQLite/PostgreSQL) — minimal telemetry focus | BUILD IN TWINSIGHT — RMF has no telemetry analytics pipeline |
| Binary Data (bags, video) | ReductStore integration (planned) | Not addressed | BUILD IN TWINSIGHT — ReductStore fills this gap |
| Anomaly Detection | ML-based anomaly detection on telemetry | Not addressed | BUILD IN TWINSIGHT — unique differentiator |
| Alerting & Notifications | Kafka events → alert pipeline → UI notifications | Basic alert system in rmf-web API | BUILD IN TWINSIGHT — need richer pipeline |
| Reporting / BI | Report generation (MinIO storage), GDPR compliance | Not addressed | BUILD IN TWINSIGHT — business layer is TwinSight's domain |
| Building Infrastructure | Not specified | Doors, lifts, dispensers — standardized APIs | USE OPENRMF — ready-made for multi-floor deployments |
| Teleoperation | WebRTC-based remote control | Not addressed (basic joystick in demos) | BUILD IN TWINSIGHT — teleop is TwinSight-specific |
| Auth & RBAC | JWT + custom RBAC (Admin/Operator/Supervisor) | JWT + Keycloak + basic RBAC | ADAPT — use Keycloak as identity provider, custom roles in TwinSight |
| Map Editor | Not specified (upload-only planned) | Full GUI traffic editor with lane/waypoint annotation | USE OPENRMF — don't build a map editor from scratch |
How Open-RMF fits into TwinSight's existing 4-tier architecture without replacing what TwinSight does best.
Open-RMF core runs as a set of ROS 2 nodes alongside TwinSight's FastAPI microservices. A lightweight RMF ↔ Kafka bridge translates between the two worlds: RMF publishes fleet states, task updates, and traffic events on ROS 2 topics; the bridge forwards these as Kafka events that TwinSight's services already consume. Commands flow back the same way. This preserves TwinSight's event-driven architecture while gaining RMF's coordination intelligence.
The definitive matrix — what to adopt, what to build, and why.
The schedule database, conflict detection, and negotiation protocol represent thousands of engineering hours. Building this from scratch would be TwinSight's biggest time sink. Open-RMF's implementation handles multi-fleet conflicts with time-extended A* search and peer-to-peer negotiation.
Saves 3-6 monthsThe competitive bidding system (Dispatcher → BidNotice → BidProposal → DispatchRequest) with automatic battery scheduling. TwinSight's mission system wraps around this — RMF handles "which robot" and "when to charge," TwinSight handles "what business goal."
Saves 2-3 monthsThe EasyFullControl Python API plus the fleet_adapter_template. For each new robot manufacturer, you implement ~5 methods instead of building a complete integration layer. Free Fleet adds Zenoh support for Nav2 robots — perfectly aligned with TwinSight's existing Zenoh bridge strategy.
Saves 1-2 months per fleet integrationGUI for annotating building plans with navigation graphs, waypoints, chargers, doors, and lifts. Exports nav graphs consumed by fleet adapters. Don't build a map editor — this one works.
Saves 1-2 monthsStandardized ROS 2 message types for building infrastructure. Ready to use for multi-floor deployments with elevators, secure doors, and automated stations.
Saves 2-4 weeks per deploymentThe ros_translator tool that generates Pydantic models and TypeScript types from ROS message definitions. Eliminates manual model maintenance and ensures type safety across the stack.
Saves 2-3 weeks + ongoing maintenanceTimescaleDB for time-series telemetry, Redis for hot state, Kafka for event streaming. Open-RMF has no analytics story — it tracks state but doesn't analyze trends, detect patterns, or generate insights. This is TwinSight's primary differentiator.
ML-based anomaly detection on telemetry streams, predictive maintenance, performance degradation alerts. Open-RMF doesn't touch this space. Combined with Mosaico for data pipeline and ReductStore for binary data, this is where TwinSight creates unique value.
TwinSight's Angular/Ionic frontend with custom UX for monitoring, teleop, analytics, and reporting. While rmf-web has a React dashboard, TwinSight's UI requirements go far beyond basic fleet visualization. Use RMF's API server data, present it through TwinSight's richer interface.
Real-time remote robot control via WebRTC video streams and command injection. Open-RMF has no teleoperation capability. This requires tight latency control, video streaming, and input handling that's specific to TwinSight's UX.
Report generation, KPI dashboards, fleet utilization metrics, GDPR compliance, audit logs. This entire business layer is TwinSight's domain — Open-RMF is an infrastructure project, not a business platform.
ROS bag recording, video storage, incident replay — all via ReductStore integration. Open-RMF doesn't address persistent binary data storage at all.
A custom bridge service that subscribes to Open-RMF's ROS 2 topics (/fleet_states, /task_states, etc.) and publishes them as Kafka events. Also translates Kafka commands back to RMF ROS 2 actions. This is the glue between the two systems — ~2-3 weeks of work.
Open-RMF handles robot coordination (traffic, tasks, fleet adapters, infrastructure) — roughly 40% of the total platform scope. TwinSight builds business intelligence (telemetry analytics, anomaly detection, reporting, teleop, custom UX) — the other 60%. The estimated total time savings from adopting Open-RMF is 6-12 months of development, depending on how many fleet integrations are needed.
The free_fleet package deserves special attention because it directly aligns with TwinSight's Zenoh bridge architecture designed in our earlier analysis.
Free Fleet is a Python implementation of the Open-RMF Fleet Adapter that uses Zenoh as its communication backbone. Each robot runs a zenoh-bridge-ros2dds process (or has one on a nearby edge device), namespaced by robot name. The central free_fleet_adapter connects to all robots through a Zenoh router.
TwinSight's Zenoh bridge architecture (from our ROS Adapter analysis) uses the exact same pattern: zenoh-bridge-ros2dds on edge devices, Zenoh router centrally, namespaced per robot. Free Fleet provides the fleet adapter layer that sits on top of this — you don't need to write it from scratch.
Direct reuseFree Fleet's architecture is essentially the same as TwinSight's designed Zenoh bridge pattern: non-namespaced robots → namespaced Zenoh bridges → central router → fleet adapter. By adopting Free Fleet, TwinSight gains the fleet adapter logic (navigate, monitor, stop, battery) without writing it. The only addition is the Kafka bridge to connect RMF's output to TwinSight's event-driven backend.
Tested on: Ubuntu 24.04, ROS 2 Jazzy, Cyclone DDS, Zenoh 1.5.0. Also supports ROS 1 Noetic via zenoh-bridge-ros1. For Humble (the other current LTS), community reports indicate it works but isn't the primary test target. The same REP-2016 type hash incompatibility noted in our earlier Zenoh bridge analysis applies here — stick to same-distro deployments or use distro-aware adapter instances.
How to handle the fact that both TwinSight and Open-RMF have web dashboards.
Run rmf-web's FastAPI API server as an internal service behind TwinSight's API gateway. TwinSight's frontend calls TwinSight's backend, which proxies fleet coordination requests to the RMF API server. Users never see the RMF dashboard.
RecommendedPros: Clean separation, single frontend, RMF API server handles ROS 2 ↔ HTTP translation. Cons: Extra network hop for fleet requests.
Skip rmf-web entirely. TwinSight's ROS Adapter subscribes directly to RMF's ROS 2 topics (/fleet_states, /task_states, etc.) and translates them to Kafka events. Commands go back via ROS 2 action servers.
AlternativePros: No extra service to maintain. Cons: Must maintain ROS 2 message schemas manually, lose rmf-web's task dispatch REST API.
Embed rmf-web's React dashboard as an iframe or micro-frontend within TwinSight's Angular shell. Used for the map/traffic visualization component only.
PossiblePros: Get the traffic visualization for free. Cons: Framework mismatch (React inside Angular), visual inconsistency, harder to maintain.
This aligns best with TwinSight's microservices architecture. The RMF API server becomes just another internal service — alongside telemetry, alerts, and reporting services — that TwinSight's gateway routes to. The code generation pipeline (ros_translator) keeps the Pydantic models in sync. TwinSight's Angular frontend renders fleet data using its own components, maintaining visual consistency.
A phased approach to integrating Open-RMF into TwinSight.
Deploy Open-RMF core nodes (traffic schedule, dispatcher, map server) alongside TwinSight's Docker Compose stack. Build the RMF ↔ Kafka bridge service. Deploy Free Fleet adapter for the first Nav2-based robot fleet. Verify end-to-end: robot state flows from ROS 2 → Zenoh → Free Fleet → RMF → Kafka → TwinSight UI.
Wire TwinSight's mission creation UI to trigger RMF task requests via the API server. Map TwinSight mission states (Created → Assigned → Running → Completed) to RMF task lifecycle events. Implement composed tasks for multi-step missions. Add battery scheduling visibility to TwinSight dashboard.
Configure navigation graphs via Traffic Editor for the deployment facility. Enable traffic deconfliction between the first fleet and a second fleet (possibly different manufacturer, different adapter type). Visualize traffic schedule and conflict resolution in TwinSight's map view. Add infrastructure integration (doors/lifts) if applicable to the facility.
Add health monitoring for RMF nodes (integrate with Prometheus/Grafana from TwinSight's observability stack). Implement failover for the RMF ↔ Kafka bridge. Load-test with simulated fleet scaling. Document fleet adapter development workflow for future manufacturers. Run end-to-end integration tests.
16 weeks for full integration is realistic if the team has ROS 2 experience. The hardest part is Phase 1 — getting the first robot fleet talking through the full pipeline. Once that works, subsequent fleet integrations follow the same pattern with the fleet_adapter_template. Budget extra time (2-4 weeks) for the first custom fleet adapter if the robot doesn't use Nav2.
Open-RMF is the strongest open-source complement to TwinSight's architecture. It provides exactly the coordination intelligence (traffic, tasks, fleet adapters) that TwinSight's proposal marks as "to be built," while having zero overlap with TwinSight's actual differentiators (telemetry analytics, anomaly detection, reporting, teleop). The Zenoh alignment via Free Fleet is almost too good to be true — it validates TwinSight's bridge architecture design and provides a ready-made fleet adapter implementation on top of it.
1. Fleet Adapter Complexity: The fleet adapter is the hardest part of any Open-RMF deployment. For non-Nav2 robots, expect 4-8 weeks per custom adapter. 2. AGV vs AMR: Traffic planning currently optimizes for AGVs on navigation graphs. If TwinSight targets AMRs that navigate freely, the path planning benefit is reduced (conflict detection still works). 3. Team Expertise: The team needs solid ROS 2 experience to operate and debug RMF core nodes. 4. Scalability Ceiling: Current Open-RMF handles tens of robots well; hundreds is being actively developed. The next-generation architecture aims for thousands, but it's not production-ready yet.
rmf-web Dashboard: Don't use the React dashboard as TwinSight's frontend — it's a different framework (React vs Angular), has a simpler UX designed for facility operators rather than fleet analytics, and would create maintenance overhead. Use the API server as an internal microservice instead. Simulation stack: rmf_demos includes Gazebo simulation worlds, but TwinSight should use its own simulation strategy aligned with its specific robot types rather than RMF's demo environments.
Taking into account all previous analyses, TwinSight's optimal stack is: Open-RMF for coordination (traffic + tasks + fleet adapters) → Zenoh/Free Fleet for zero-footprint robot connectivity → ReductStore for binary telemetry storage → Mosaico for ML data pipelines → TwinSight custom for web UI, analytics, anomaly detection, teleop, reporting, and business intelligence. This combination leverages ~4 open-source projects to handle infrastructure concerns while TwinSight focuses entirely on its unique business value.