Robot fleet management
Robot fleet management – definition
Robot fleet management is the software and operational layer used to coordinate multiple mobile robots that share tasks, physical space, network infrastructure, charging resources, and supervisory systems. In mobile robotics, it combines robot state monitoring, task dispatch, route or resource coordination, fault handling, and interfaces to external applications.
A fleet manager does not replace onboard autonomy. Each UGV still requires local control, localisation, obstacle handling, and safety-related behaviour appropriate to its deployment. The fleet layer decides which robot should execute a task and may reserve shared resources such as corridors, docking stations, inspection zones, or communication gateways. The robot-level navigation stack then executes the assigned mission within its local environment.
For ROS 2 systems, fleet management is usually implemented as a distributed application. It communicates with robots through ROS 2 nodes, actions, services, topics, REST APIs, MQTT bridges, or dedicated fleet adapters. Open-RMF is a commonly used open-source framework for multi-robot coordination in ROS 2 environments. It defines integration patterns for robot fleets, task dispatch, traffic scheduling, and shared infrastructure.
Fleet management in UGV deployments
A UGV fleet differs from a single robot because decisions must account for system-wide state. A task that is valid for one Leo Rover may conflict with the battery state, route, payload, localisation quality, or active mission of another robot. Fleet management therefore requires a consistent representation of each vehicle and its operating area.
Typical fleet-level state includes the following elements:
- Robot identity, namespace, software version, and hardware configuration.
- Current pose, velocity, navigation status, and localisation confidence.
- Battery or power status, charging state, and mission availability.
- Assigned task, task progress, estimated completion time, and failure state.
- Sensor health, network connectivity, diagnostic messages, and safety-related stops.
- Access to shared resources, such as a charging point, narrow passage, inspection area, or loading zone.
In an outdoor or semi-structured deployment, route coordination may be less deterministic than in an indoor warehouse. GNSS availability can change, terrain can become inaccessible, and dynamic obstacles may invalidate a planned route. A fleet manager should therefore treat route estimates as operational data rather than as guarantees.
How robot fleet management works with ROS 2
ROS 2 provides communication primitives that are useful for fleet integration, but it does not provide a complete fleet manager as part of the core middleware. ROS 2 nodes can publish telemetry, expose services, execute actions, and report lifecycle state. The fleet layer consumes these interfaces and translates high-level work orders into robot-specific missions.
For autonomous UGVs using Nav2, a common execution interface is the nav2_msgs/action/NavigateToPose action. A fleet adapter can submit a goal pose to a selected robot, monitor action feedback, and mark the task as completed, failed, or cancelled. Nav2 remains responsible for local path planning, controller execution, recovery behaviour, and costmap-based obstacle processing.
| Fleet function | Typical ROS 2 interface | UGV-level responsibility |
|---|---|---|
| Telemetry collection | Topics such as /odom, /tf, /diagnostics |
Publish current motion, transforms, and component health. |
| Task execution | Actions, including NavigateToPose |
Plan and execute the local mission. |
| Mode control | Services and managed-node lifecycle transitions | Activate, deactivate, restart, or isolate software components. |
| Map-frame consistency | tf2 transforms following REP-105 |
Maintain valid relationships between map, odom, and base_link. |
Namespaces are important when multiple identical robots operate on one ROS 2 network. Each robot should expose isolated topic and frame names, for example /leo_01/odom and /leo_02/odom. Frame IDs must also remain unique, especially when a fleet visualisation or central monitoring node subscribes to transforms from several UGVs.
# Send a navigation task to one namespaced robot
ros2 action send_goal \
/leo_01/navigate_to_pose \
nav2_msgs/action/NavigateToPose \
"{pose: {header: {frame_id: map}, pose: {position: {x: 4.0, y: 2.0}, orientation: {w: 1.0}}}}"The exact action name depends on the Nav2 namespace and launch configuration. The task should only be issued when the robot has a valid localisation source and its navigation nodes are active.
Key metrics for a mobile robot fleet
Fleet performance should be measured at both robot and mission level. Raw robot availability alone is insufficient because a robot can be online while unable to navigate, localise, or complete its assigned task.
Useful engineering metrics include:
- Task completion rate – completed tasks divided by dispatched tasks for a defined mission class.
- Dispatch latency – time between task acceptance by the fleet service and acknowledgement by the target robot.
- Mission duration error – difference between estimated and actual task completion time.
- Navigation failure rate – failed or cancelled navigation actions divided by submitted navigation actions.
- Fleet availability – proportion of time in which a robot is connected, healthy, localised, and eligible for dispatch.
- Resource contention – number of conflicts involving shared routes, docking locations, or mission zones.
Telemetry timestamps must use a documented clock policy. ROS 2 supports system time and ROS time through the /clock mechanism. Mixed or unsynchronised clocks can produce incorrect task durations, stale-state detection, and invalid sensor-to-pose associations.
Use with Leo Rover and Raph Rover
Leo Rover can act as an individual fleet member for laboratory experiments, educational courses, indoor inspection prototypes, and distributed robotics research. It uses differential drive and can be integrated with ROS 2; supported ROS 2 distributions depend on the platform software image and current documentation. Fleet integration does not make Leo Rover autonomous by default. A deployment still needs a navigation stack, localisation method, sensor configuration, map or mission representation, and defined failure behaviour.
For a multi-Leo Rover setup, each platform should have a unique ROS 2 namespace, network identity, transform prefix strategy, and robot configuration. A central computer can run monitoring, task allocation, simulation, and visualisation while the onboard Raspberry Pi runs the robot-specific control and autonomy components. Compute-intensive perception or mapping workloads may require offboard processing or an additional onboard compute unit, depending on the selected sensors and algorithms.
Raph Rover is more suitable where the fleet member must carry a larger payload, additional compute hardware, a larger sensor suite, or field-oriented equipment. Typical examples include multi-robot site inspection, agricultural data collection, or outdoor mapping. The fleet interface remains conceptually the same, but the robot adapter must expose platform-specific limits such as payload-dependent motion behaviour, battery model, permitted terrain, and sensor availability.
Standards, interfaces, and limitations
Open-RMF provides ROS 2-oriented fleet integration components, but it does not define a universal hardware protocol for every UGV. A fleet adapter is normally required between Open-RMF and the robot’s native ROS 2 navigation, diagnostics, and mission interfaces.
VDA 5050 is another relevant reference for fleet communication. It defines an interface between automated guided vehicles and control systems using messages such as orders, instant actions, and state updates. It is primarily intended for AGV and AMR interoperability. It does not define ROS 2 topics, Nav2 interfaces, or the specific control architecture of Leo Rover or Raph Rover.
Fleet coordination also has practical limits. A central scheduler cannot compensate for unreliable localisation, insufficient wireless coverage, inaccurate maps, or missing obstacle detection. For outdoor UGVs, the system should explicitly define what happens when GNSS is degraded, a map is unavailable, a robot leaves its operational area, or network communication is lost.
Normative references and technical sources
The following sources define or document the interfaces commonly used in ROS 2 fleet-management implementations:
- ROS 2 Quality of Service settings documentation – communication reliability and durability policies.
- ROS 2 Managed Nodes design document – lifecycle states and transitions.
- REP-105: Coordinate Frames for Mobile Platforms – conventions for
map,odom, and robot base frames. - Nav2 documentation – ROS 2 navigation actions, planners, controllers, and behaviour trees.
- Open-RMF documentation – fleet adapters, task dispatch, traffic scheduling, and facility integration.
- VDA 5050 specification – AGV and control-system communication interface.
- Leo Rover technical documentation – platform-specific ROS 2 and hardware configuration.