Fleet adapter vs vendor fleet manager in a real-world RMF deployment (no simulation)

Open-RMF Open-RMF General
1

Hi everyone,
I’m currently working on an RMF deployment in a real-world environment (no simulation) and I’d like to clarify the practical role of a fleet manager in this context.

My setup:

  • RMF is running with real robots.

  • I already have a RobotClientAPI.py module that handles HTTP API calls to the robot (navigate, stop, docking, battery state reporting, etc.).

  • The robots do not natively support ROS 2 — the integration is purely via their API.

  • In my config.yaml, I can define multiple identical robots, all managed by the same fleet adapter instance.

Questions:

  1. In a real-world RMF integration, is a vendor fleet manager only necessary when the robots:

    • already speak ROS 2 natively, or

    • expose a vendor fleet management system that RMF can bridge to?

  2. If my fleet adapter already integrates directly with the robot via RobotClientAPI.py and implements the required RMF capabilities (navigate, docking, task state updates, battery monitoring, pause/resume/cancel, etc.), what concrete advantages would I gain by adding a vendor fleet manager layer in between?
    Possible examples I can think of: vendor-level multi-robot coordination, centralized health monitoring, retry logic, logging/analytics, queue management.

  3. For multi-robot control: If I have multiple identical robots listed in config.yaml and my fleet adapter maintains separate state and command handling for each, can I fully manage them without implementing a vendor fleet manager? Are there any common pitfalls here (e.g., API rate limits, local collision avoidance, synchronized docking, recovery strategies)?

I’d like to confirm whether my understanding of the fleet manager’s role in RMF for real-world scenarios is correct, and when it truly makes sense to introduce one.

Thanks for any insights or production examples you can share!

1 Like