RobotFleet: Coordinated Multi-Robot Systems

• RobotFleet is a multi-robot system that coordinates heterogeneous robots through centralized, distributed, or hybrid strategies to achieve unified mission objectives.
• The framework leverages cloud robotics, ROS middleware, and formal optimization methods for efficient task allocation, robust communication, and adaptive planning.
• It addresses challenges in situational awareness, fleet design optimization, and human supervision to enable scalable, mission-critical deployments.

RobotFleet denotes a class of multi-robot systems in which multiple robots—often heterogeneous in sensing, actuation, mobility, or software stack—are coordinated as a fleet through shared planning, scheduling, communication, mapping, and supervision layers rather than as isolated platforms. In the research literature, the term spans cloud-managed autonomous mobile robot deployments in factories, centralized multi-robot task planning with a shared declarative world state, mission-critical teleoperated fleets that contribute to a unified global map, and formal fleet-design problems in which the composition of the fleet is itself an optimization variable (Singhal et al., 2017, Vannini et al., 2 May 2025, Gupta et al., 12 Oct 2025, Wilde et al., 2023).

1. Conceptual scope and evolution

Early RobotFleet work in warehouses and factories treated the fleet manager as a centralized global planner that assigned destinations to autonomous mobile robots while leaving local motion and obstacle avoidance onboard. A representative implementation compared single-master ROS, multi-master ROS, and a Rapyuta Cloud Robotics deployment for a fleet of AMRs operating over a wireless network, with the global planner computing shortest paths on a grid and robots executing them through local navigation stacks (Singhal et al., 2017). This established a durable architectural distinction: fleet-level coordination can be centralized even when control execution remains decentralized.

Subsequent systems broadened the concept beyond warehouse navigation. The AGM system defined a cloud-based robot fleet manager for single or multiple robots, organized around RESTful communication, a common data model for robots, tasks, routings, and workstations, and a task-prioritization decision tree that adapts to robot state, distance, and resource availability (Kazim et al., 2023). Robofleet reframed the problem around resilient inter-robot communication, remote monitoring, and remote tasking for ROS-enabled service-mobile robots, with a central server that deduplicates traffic and enforces authentication and topic-level authorization (Sikand et al., 2021). More recent work extends the term further still: the open-source RobotFleet framework treats high-level goals, heterogeneous capabilities, shared world state, planning, allocation, and execution as modular services, including containerized robot workers and LLM-based open-world reasoning (Gupta et al., 12 Oct 2025).

This evolution suggests that RobotFleet is less a single software package than a systems abstraction. The common denominator is fleet-level coordination under shared mission objectives, but the implementation substrate varies: cloud robotics, ROS/ROS 2 middleware, mesh networking, formal schedulers, learning-based policy sharing, or mission-specific teleoperation frameworks.

2. Architectural patterns and communication substrates

RobotFleet architectures in the cited work fall into three recurrent patterns: centralized server-based coordination, selectively synchronized distributed middleware, and hybrid local/global communication layers. In the AMR fleet-management comparison, single-master ROS exposed all topics globally and was simple to deploy, whereas multi-master ROS reduced bandwidth by synchronizing only selected topics and improved fault isolation. The Rapyuta-based cloud architecture added Linux containers, robot–cloud endpoints, and WebSocket-based bridging, enabling computation to move off robot hardware, but also introduced central dependencies and platform-level limitations in high availability and elasticity (Singhal et al., 2017).

Robofleet crystallized the centralized-server model for ROS 1 fleets. Each robot runs a lightweight client that bridges selected ROS topics to a central server over WebSockets; the server then relays messages to robots and web clients. Two mechanisms are central to its fleet semantics: traffic deduplication, so a robot publishes one copy of a topic to the server rather than one copy per subscriber, and backpressure-aware scheduling with topic-level priorities and no_drop semantics, which preserve safety-critical traffic under adverse network conditions (Sikand et al., 2021). This design directly targets long-term deployments with intermittent and low-bandwidth connectivity.

ROS 2–based fleets introduce a different bottleneck: DDS discovery storms, namespace collisions, and redundant decoding of dense sensor streams. SFG-ROS addresses this by isolating each robot in its own local ROS 2 domain $D_i$, connecting those domains to a shared bridge domain $D_0$ through Fast DDS Router, and enforcing a programmatic fully qualified name schema that separates Local and Global traffic. Its centralized AgentDecoder decompresses each remote stream once per consuming device and redistributes the result locally via IPC, which bounds network traffic for shared camera streams to $\mathcal{O}(1)$ per consuming agent and reduces the per-subscriber CPU scaling penalty by 72.3% versus standard ROS 2 (Blessing et al., 22 May 2026).

Mission-critical field systems often combine these ideas with radio and teleoperation choices dictated by the environment. ASAP-MO used an initial 5 GHz Wi‑Fi mesh and a final 915 MHz mesh radio configuration, with a single mobile base station controlling two heterogeneous UGVs through ROS 2, Zenoh DDS for commands, and NoMachine NX for remote visualization rather than raw point-cloud streaming (Vannini et al., 2 May 2025). The Cambridge RoboMaster fleet adds a dual-network structure of its own: infrastructure WiFi for centralized management and ad-hoc peer-to-peer communication for decentralized multi-agent experiments, all atop a ROS2-based onboard autonomy stack (Blumenkamp et al., 2024).

A common misconception is that RobotFleet middleware is mainly a matter of message transport. The cited systems instead show that naming discipline, authorization, relay topology, compression and decompression placement, and the division between local and fleet-wide traffic are all first-order design decisions.

3. Planning, task allocation, and scheduling

A major strand of RobotFleet research formalizes fleet-level decision making as an optimization problem over task assignment, routing, and sometimes fleet composition. In heterogeneous fleet design with deadlines and battery limits, the canonical formulation takes a graph $G=(V,E)$, tasks $T_j=(v_j,t^d_j,\Phi_j)$, robot types $R_i=(\Psi_i,b(R_i),\beta(R_i),D^i)$, and a budget $B$, and seeks a fleet $F$ maximizing the number of tasks serviced before their deadlines, subject to deployment-cost and per-robot battery constraints (Wilde et al., 2023). Because the resulting MILP scales poorly, the proposed Large Neighbourhood Search jointly modifies fleet composition and tours, and in simulation requires substantially lower budgets than a greedy baseline to service all tasks (Wilde et al., 2023).

A complementary perspective treats the fleet itself as a design variable under expensive evaluation. BOFD represents a fleet composition as an integer vector $\mathbf{n}\in N\subset\mathbb{Z}_+^M$, uses a known linear acquisition cost $C(\mathbf{n})=\mathbf{A}^\top\mathbf{n}$, and models performance $D_0$0 through MARL-trained multi-robot exploration policies. The optimization target is the Pareto trade-off

$D_0$1

with a Gaussian-process surrogate and an uncertainty-aware acquisition rule to reduce the number of expensive fleet evaluations (Concha et al., 2024). This shifts RobotFleet from deployment-time scheduling to design-time co-optimization of hardware mix and learned behavior.

At the task-graph level, FLEET converts free-form language into optimized schedules for heterogeneous robot teams. An LLM front-end generates a task graph with durations and precedence constraints together with a capability-aware robot–task fitness matrix, and a formal back-end solves a makespan-minimization problem through MILP or an auction-based fallback (Rivera et al., 8 Oct 2025). The result is a hybrid pattern increasingly common in RobotFleet systems: semantic decomposition and capability interpretation from language, but temporal consistency and assignment feasibility from formal optimization.

The open-source RobotFleet framework adopts a similar separation of concerns in software form. Goals are decomposed into subtasks organized as per-goal DAGs, a big DAG, or a monolithic prompt-derived task set; tasks are then allocated either by an LLM or by a MILP that minimizes the maximum number of tasks assigned to any robot while enforcing capability compatibility (Gupta et al., 12 Oct 2025). Across simulation studies, DAG-structured planning combined with MILP allocation produced lower robot idle time than monolithic prompting or LLM-only allocation (Gupta et al., 12 Oct 2025).

These results collectively argue against a second misconception: that RobotFleet planning is only a dispatch problem. In the cited work it includes fleet sizing, capability-constrained assignment, precedence scheduling, makespan minimization, and explicit reasoning about budget, energy, and uncertainty.

4. Mapping, perception, and shared situational awareness

RobotFleet systems frequently rely on a shared world model, but the way that world model is built depends on fleet heterogeneity. ASAP-MO provides a concrete field-tested example. A large Clearpath Warthog UGV produced an outdoor map using high-resolution LiDAR, radar, IMUs, and GNSS, and a smaller HD2 tracked platform with a Kinova Gen3 arm imported that map, relocalized into the Warthog frame using an operator-provided initial guess and ICP, and then extended the map indoors while maintaining a single global frame (Vannini et al., 2 May 2025). The resulting representation fused outdoor and indoor point clouds and overlaid camera-derived “radiation” intensity as colored map attributes, demonstrating a fleet-level situational-awareness pipeline rather than two separate robot maps (Vannini et al., 2 May 2025).

SLEI3D generalizes this principle to exploration and inspection under intermittent communication. It partitions a heterogeneous fleet into explorers with long-range sensing and inspectors with close-range cameras, organizes work around 3D bounding boxes, and treats exploration, inspection, and communication as coupled planning problems. The fleet objective is re-expressed as minimizing total idle time across the GCS, explorers, and inspectors, while guaranteeing that the GCS eventually receives complete maps and all inspection results (Chen et al., 1 Jan 2026). This suggests that in RobotFleet settings with limited connectivity, shared situational awareness is not equivalent to continuous connectivity; it is often achieved through scheduled meetings and staged data fusion.

Dense multi-agent perception places additional systems pressure on RobotFleet deployments. SFG-ROS emphasizes that standard ROS 2 distribution of stereo or LiDAR streams can saturate both network and CPU resources when every consumer independently decodes the same compressed input, and its local-raw/global-compressed architecture is explicitly designed to prevent the fleet software layer from overwhelming the perception pipeline (Blessing et al., 22 May 2026). The Cambridge RoboMaster platform illustrates the opposite end of the spectrum: compact holonomic research robots with sufficient onboard compute to run estimation, control, and zero-shot multi-agent reinforcement-learning policies locally, while still participating in peer-to-peer fleet communication (Blumenkamp et al., 2024).

Across these systems, situational awareness is not merely visualization. It is the coordinated construction, transport, alignment, and annotation of world state across robots with different sensing envelopes, compute budgets, and communication opportunities.

5. Learning, adaptation, and human supervision

Another major interpretation of RobotFleet treats the fleet as a learning substrate. Sirius-Fleet addresses multi-task interactive fleet learning by combining a shared multi-task policy, a frozen visual world model $D_0$2, and task-specific anomaly predictors that operate on predicted future embeddings rather than only on current observations (Liu et al., 2024). Runtime monitoring triggers human intervention when either a failure classifier or an OOD predictor anticipates anomalous behavior, and the intervention threshold adapts according to the human intervention ratio $D_0$3 through

$D_0$4

with $D_0$5, $D_0$6, and $D_0$7 (Liu et al., 2024). The framework therefore treats RobotFleet not only as a deployment unit but as a continual-learning system whose supervision load should decrease over time.

FLEET-MERGE addresses the opposite bottleneck: fleets produce heterogeneous streaming data silos that are expensive to centralize. Its solution is policy merging rather than data pooling. Each robot trains locally, and a permutation-aware merging procedure aligns recurrent policies before averaging them into a consolidated fleet policy, allowing skills acquired on distributed datasets to propagate across the fleet without transmitting all raw experience (Wang et al., 2023). In this view, RobotFleet is a mechanism for federated skill accumulation.

Human attention can also be treated as a fleet resource. Scaled Autonomy formalizes the choice of which robot a human operator should teleoperate as a Luce choice model,

$D_0$8

where $D_0$9 is a learned score over robot states (Swamy et al., 2019). By learning this preference model on small fleets and using it to route operator attention in larger fleets, the method addresses a core RobotFleet problem: even when autonomy is local, human supervision remains a shared and limited fleet-level resource.

Learning-based RobotFleet research therefore spans three distinct levels: learned fleet design and evaluation, learned policy sharing across distributed data silos, and learned or adaptive human oversight. What unifies them is the shift from robot-level competence to fleet-level performance under resource constraints.

6. Applications, scaling limits, and open problems

The application space covered by the cited work is unusually broad. Mission-critical inspection appears in ASAP-MO’s simulated nuclear scenario with two UGVs and a mobile base station (Vannini et al., 2 May 2025). Intra-factory logistics appears in resilient, energy-aware fleet management for battery-powered robots, where nominal task assignments are computed offline by Monte Carlo Tree Search and then updated online by reusing the nominal search tree after disruptions such as blocked passages or battery degradation (Goutham et al., 2024). Exploration and inspection under intermittent communication appear in SLEI3D, which scales in simulation to missions with up to 48 robots and $\mathcal{O}(1)$0 thousand cubic meters and includes hardware experiments with 7 robots (Chen et al., 1 Jan 2026). At a different scale altogether, motion planning for large fleets of floating robots shows that interaction clustering and sparse sequential convex programming can synthesize collision-free trajectories for up to 500 robots in simulation and support real-world choreographic demonstrations (Kamm et al., 8 Jun 2026).

These systems also sharpen the main open questions. One is centralization versus decentralization. Centralized fleet managers simplify global reasoning, task allocation, and shared situational awareness, but create single logical bottlenecks and dependencies on communication and server availability (Kazim et al., 2023, Singhal et al., 2017). Decentralized execution improves local responsiveness and fault tolerance, but temporal coordination, shared resources, and open-world task semantics often still benefit from centralized planning or at least centralized schedule generation (Rivera et al., 8 Oct 2025). The literature therefore increasingly adopts hybrid architectures rather than choosing one extreme.

A second open question concerns the role of LLMs. The current evidence does not support the claim that LLMs obviate formal methods. Instead, the strongest results pair LLM-derived task graphs, world-state interpretation, or capability scores with MILP, auction, or DAG-based schedulers that enforce feasibility and temporal structure (Rivera et al., 8 Oct 2025, Gupta et al., 12 Oct 2025). Likewise, the presence of cloud robotics or mesh networking does not by itself solve fleet communication: robust deployments still depend on topic prioritization, compression policy, relay placement, and low-level transport design (Sikand et al., 2021, Blessing et al., 22 May 2026).

A plausible implication is that RobotFleet is converging on a layered systems model. Fleet-level success increasingly depends on combining heterogeneous hardware, disciplined communication substrates, formal scheduling, perception-aware world modeling, adaptive supervision, and learning mechanisms that improve the fleet without overwhelming network, compute, or human operators. The cited literature does not yet offer a single canonical stack, but it does define the technical dimensions along which RobotFleet systems are now designed and evaluated.