The Inevitable Problem: Operational Silos in Multi-Vendor Robotics
The automation landscape is evolving rapidly, leading organizations to deploy specialized robotic platforms from multiple manufacturers (AMRs, AGVs, mobile manipulators). While this heterogeneity offers functional specialization, it creates a fundamental engineering challenge: operational silos.
Each robotic platform operates on its own proprietary software stack, communication protocol, and safety mechanisms. The result is a system of disconnected islands where robots from different vendors cannot coordinate tasks, share space efficiently, or respond to facility-level scheduling. This fragmentation fundamentally limits the throughput and scalability of the entire automated system.
This is the problem the Open-source Robotics Middleware Framework (OpenRMF) was engineered to solve.
The OpenRMF Architecture: Centralized Orchestration via ROS 2

OpenRMF is built upon ROS 2 (Robot Operating System 2), leveraging its decentralized communication structure to provide a unified coordination layer above the disparate native robot control systems. The core architectural challenge is converting real-time, vendor-specific robot data into a standard, facility-wide language.
OpenRMF achieves this through three core technical components:
The Unified Traffic Schedule: The Space-Time Constraint Manager
This is the most mathematically demanding component. It operates as a dynamic, centralized database that stores the predicted itineraries for every robot, calculating paths across both spatial coordinates and time.
- Conflict Detection: It constantly analyzes the schedule to look ahead and identify potential conflicts where robot trajectories intersect.
- Resolution Protocol: When a conflict is inevitable, OpenRMF initiates a negotiation process. It doesn’t simply assign right-of-way; it proposes alternative trajectories (e.g., speed reduction, temporary pause, reroute) to the involved robot agents to minimize the disruption to overall flow. The efficacy of the entire OpenRMF system hinges on the real-time accuracy and responsiveness of the data fed into this schedule.
The Task Planner and Allocator
This system is responsible for high-level workflow management and optimization.
- Task Abstraction: It translates abstract facility requirements (e.g., “move pallet from Dock A to Station B”) into sequences of robot actions.
- Optimal Allocation: For tasks that can be performed by multiple robot fleets, the planner employs a form of task auctioning. Robots (or their fleet managers) “bid” on the task by calculating the quickest, most resource-efficient completion time, allowing the system to achieve global optimum task distribution rather than local fleet efficiency. It also intelligently manages resource constraints, such as injecting necessary recharge tasks into a robot’s itinerary.
The Critical Engineering Challenge: Developing the RMF Adapter
The components above form the “brain,” but they are useless without a dedicated, custom-built interface to the robots—the OpenRMF Fleet Adapter. This is the single most technically critical part of any OpenRMF deployment.
The OpenRMF Fleet Adapter is a translation layer that bridges the proprietary API or internal software of a robot/fleet manager with the standardized OpenRMF communication protocols.
Adapter Integration Requirements
A robust OpenRMF Fleet Adapter must consistently perform four demanding functions:
- Kinematic Transformation: Translate the facility-level coordinates (meters in the map frame) provided by OpenRMF into the robot’s local navigation frame, accounting for any required scaling, rotation, or offset.
- Navigation Command Mapping: Receive a high-level PathRequest from OpenRMF and break it down into the specific commands the robot’s onboard navigation stack (e.g., Nav2 actions) can consume.
- State Synchronization: Continuously publish the robot’s true, real-time status (FleetState, including battery, mode, and position) back to OpenRMF with minimal delay to ensure the Traffic Schedule’s accuracy.
- Mode Control Integration: Map OpenRMF’s low-level mode controls (Pause, Resume, Stop) to the robot’s emergency stop and local navigation controls to facilitate safe deconfliction.
Implementation Case Study: The Andino Fleet Integration
A concrete example of this engineering effort is the integration of the Andino robot fleet.
- The Challenge: Deploying a simulated fleet of Andino robots, each requiring a customized controller and fleet manager to expose its internal state and control points.
- The Solution: A custom OpenRMF Adapter was developed to interface seamlessly with the fleet’s controller. This required defining specific message flows to convey task commands from OpenRMF to the fleet manager and to report robot state back to the central system.
- Advanced Requirement (Nav2 Integration): The current development thrust involves integrating this adapter with the modern ROS 2 Nav2 stack. This demands precise command mapping to Nav2’s Action-Based APIs, ensuring the robot is fully compliant with OpenRMF’s path and velocity constraints while leveraging Nav2’s state-of-the-art local planning capabilities.
This type of integration work—developing a reliable, performant, and maintainable OpenRMF Fleet Adapter—is where core robotics and software engineering expertise is absolutely required. It is the distinction between installing open-source code and achieving true, optimized fleet orchestration.
The code and architecture for this implementation are public, showcasing the depth of integration required: https://github.com/Ekumen-OS/andino_rmf.
In Conclusion
The deployment of OpenRMF is ultimately an integration project. Success is defined by the stability and intelligence of the custom software that links the core OpenRMF Orchestrator to the reality of the multi-vendor, dynamic robotic environment.
When executed correctly, the benefits are profound: a single, cohesive system that maximizes asset utilization and scales effortlessly with business demands.
Ready to unlock the full potential of your multi-vendor robotic fleet? Partner with Ekumen to leverage our expertise in bespoke OpenRMF Fleet Adapter development and seamless fleet integration.