Multi-Robot Systems & Swarms: The Ultimate Guide

One robot is a control problem. A thousand robots is an economics problem, a networking problem, and a distributed-systems problem wearing a control problem as a hat. The instant you have more than one machine sharing a space and a goal, the hard questions stop being "how do I track this trajectory?" and become "who does which job, how do they avoid each other without a central traffic cop, and what happens when the radio link drops mid-maneuver?" A warehouse with 4,000 mobile robots, a light show with 3,000 drones holding a logo in the night sky, a field of 20 tractors covering a section before the rain: all of them are the same underlying question of how you get many bodies to behave like one system without a single brain that has to think about every body at once.

This guide is about that question. We will build up from the coordination architecture (centralized versus decentralized, and the hybrid that almost everything real actually uses), through the two problems that dominate practice (who does what, and how do bodies not collide), into the swarm ideas that let coordination scale to thousands (flocking, stigmergy, emergence), the communication and consensus math that holds a decentralized team together, multi-robot mapping, the real deployed systems, and the scaling walls that stop a demo of ten from becoming a fleet of ten thousand. The math is here where it earns its place: the assignment problem and its auction solution, Reynolds' three rules, the consensus update, and the reciprocal velocity obstacle that keeps two robots from politely stepping into the same gap at the same instant.

The take: Multi-robot coordination is a spectrum from a single central optimizer that sees everything to a fully local swarm where each robot reacts only to neighbors, and the right point on that spectrum follows from your communication budget and your fleet size. Small structured fleets (dozens of warehouse robots on known aisles) run centralized and get provable optimality. Large or comms-limited teams (hundreds of drones, defense swarms, robots underground) run decentralized because the central approach's O(n) communication and computation, plus its single point of failure, stop scaling. The durable ideas are the assignment problem for who-does-what, reciprocal velocity obstacles for local collision avoidance, average consensus for agreeing without a leader, and stigmergy for coordinating through the environment instead of the network. Almost every fielded system is a hybrid: central planning where the fleet is small and connected, local reaction where it is large and sparse.

Companion reading: mobile robots: AMRs & AGVs, warehouse & logistics robotics, drone delivery, military drones & loitering munitions, and SLAM & localization.

Table of contents

1. Key takeaways
2. Why many robots is a different problem
3. Centralized vs decentralized coordination
4. Task allocation: the assignment problem and auctions
5. Formation control
6. Swarm principles: flocking, stigmergy, emergence
7. Communication and consensus
8. Decentralized collision avoidance: RVO and ORCA
9. Multi-robot SLAM and shared maps
10. Applications: warehouses, light shows, agriculture, defense
11. The real scaling limits
12. Frequently asked questions

Why many robots is a different problem

A single robot has a state, a goal, and a controller that closes the gap. Add a second robot sharing the same floor and three genuinely new problems appear at once, and none of them existed before.

Interaction. The two robots now occupy the same space, so each is an obstacle to the other, and worse, a moving, decision-making obstacle whose future depends on what the other decides to do. Collision avoidance between two agents that are both avoiding is a coupled problem: my best move depends on your move, which depends on mine. Treating the other robot as a static obstacle produces the sidewalk shuffle, two agents stepping into the same gap, backing off, and stepping in again.

Allocation. With one robot and one job, there is nothing to decide. With n robots and m jobs, someone has to decide which robot does which job, and the quality of that decision (measured in total distance, total time, or energy) can differ by large factors between a good assignment and a naive one. This is a combinatorial optimization problem that grows fast.

Coordination without a shared brain. You could route everything through one central computer that knows every robot's state and issues every command. That works beautifully up to a point and then stops, because the central node's workload grows with the fleet, the communication to and from it grows with the fleet, and when it fails the whole fleet stops. Past a certain size or in environments where robots cannot reliably reach a central node (underground, underwater, contested airspace), coordination has to happen locally, which means each robot decides for itself using only what it can sense and hear from neighbors.

Rule of thumb: The number that decides your architecture is the fleet size multiplied by how tightly the robots interact and divided by how much bandwidth you have, so fleet size alone tells you little. Ten robots doing independent jobs in a big open space barely need coordination. Ten robots threading a narrow shared corridor need a lot. A thousand robots anywhere need decentralization.

The field that studies this sits at the intersection of control theory, distributed algorithms, and operations research, and the reason it is hard is that the clean guarantees of single-robot control (stability, optimality, a provable controller) get expensive or impossible to preserve once behavior is distributed across many bodies with partial information and unreliable links.

Centralized vs decentralized coordination

Every multi-robot system makes one architectural choice first, and everything else follows from it: where do the decisions get made?

Centralized. A single coordinator holds the state of the entire fleet and computes plans for everyone. In a warehouse this is the fleet-management server that knows where all 4,000 robots are and assigns every pickup, route, and right-of-way. The upside is real: the coordinator can compute a globally optimal or near-optimal solution because it sees everything, it can guarantee no two robots are routed into the same cell at the same time, and it is straightforward to reason about and debug. The downsides are equally real. The coordinator's computation grows with fleet size (joint planning for n robots is combinatorial in the worst case). The communication grows with fleet size (every robot reports state and receives commands). And it is a single point of failure: if the coordinator or the link to it goes down, the fleet is blind.

Decentralized. No global coordinator. Each robot decides for itself using its own sensing plus whatever it can exchange with nearby robots. A drone in a flock reacts to the handful of neighbors it can see. The upside is scalability (adding a robot adds one more local decision-maker, not more load on a central node), robustness (losing one robot degrades the team gracefully instead of stopping it), and viability in comms-poor environments (each robot needs only local links). The downside is that you give up global optimality (local decisions can be collectively suboptimal), the emergent behavior is hard to predict and to prove correct, and some global properties (guaranteeing the whole team reaches consensus, or that no deadlock forms) require careful design to hold.

Distributed (the useful middle). In practice most large systems are neither purely central nor purely local. They are distributed: computation and decisions are shared across robots, often with local clusters that coordinate among themselves and report summaries upward, or with a central planner that sets high-level goals while local controllers handle reactive collision avoidance. The warehouse pattern is exactly this: a central server does global task allocation and coarse routing (where bandwidth to a fixed base is cheap and the fleet is on known aisles), while each robot runs its own local obstacle avoidance and motion control at high rate.

Property	Centralized	Decentralized	Distributed (hybrid)
Decision location	One coordinator	Each robot locally	Shared / layered
Optimality	Global optimum reachable	Local, often suboptimal	Good where it matters
Communication cost	Grows with fleet (to/from center)	Local neighbors only	Mixed
Single point of failure	Yes (the coordinator)	No	Reduced
Scales to thousands	Poorly	Yes	Yes
Predictability	High	Low (emergent)	Medium
Best for	Small structured fleets, known space	Large teams, comms-poor, adversarial	Most real deployments

Rule of thumb: Centralize what is small, connected, and where optimality pays (task allocation across a warehouse fleet on a reliable network). Decentralize what is large, sparse, or fragile (reactive collision avoidance, comms-denied swarms). Do not centralize the fast reactive loop and do not decentralize the global objective if you can help it.

Task allocation: the assignment problem and auctions

The cleanest question in multi-robot systems has a clean answer, at least in its simplest form. You have n robots and n tasks, and assigning robot i to task j costs c_ij (distance to drive, energy, time). You want the one-to-one assignment that minimizes total cost. This is the linear assignment problem:

minimize    Σ_i Σ_j  c_ij · x_ij

subject to  Σ_j x_ij = 1   for all i   (each robot gets one task)
            Σ_i x_ij = 1   for all j   (each task gets one robot)
            x_ij ∈ {0, 1}

The remarkable fact is that this integer program can be solved optimally in polynomial time. The Hungarian algorithm (Kuhn, 1955, building on Kőnig and Egerváry) solves it in O(n³). You do not need to search the n! possible assignments; the structure of the problem collapses the search. For a static snapshot of a modest fleet (hundreds of robots), you can compute the provably optimal assignment in milliseconds.

Reality complicates this in three ways, and each pushes you toward a different method.

Tasks arrive over time. In a live warehouse, orders stream in continuously. You re-solve the assignment constantly as new tasks appear and robots finish jobs. This becomes a dynamic assignment or a vehicle-routing problem, and the optimal static solver is now one tool inside a rolling re-optimization.

One robot does many tasks in sequence. If a robot picks up several items on one trip, you are choosing who does what and in what order, which is the multiple traveling-salesman problem, NP-hard, and solved in practice with heuristics and metaheuristics rather than to optimality.

No central computer, or you want robustness. When there is no coordinator, or you want the allocation to survive a failed robot, you use a market-based approach. The idea is borrowed directly from economics: tasks are auctioned, and robots bid.

The auction mechanics, in the common single-item form:

For each unassigned task t:
  1. Auctioneer announces t (a robot, or a rotating role, can be the auctioneer)
  2. Each free robot i computes its bid = its own cost c_i(t)
     (e.g. distance from its current position to t, plus its current workload)
  3. Robot with the lowest bid wins t and commits to it
  4. Repeat for remaining tasks

This is a greedy assignment: each task goes to whoever is cheapest right now. It gives up global optimality (early commitments can force expensive later ones) in exchange for being fast and fully decentralized, needing only local communication and each robot's private cost function, and degrading gracefully when a robot drops out (its tasks simply get re-auctioned). The Contract Net Protocol (Smith, 1980) formalized this announce-bid-award pattern, and it remains the backbone of decentralized task allocation.

The important refinement is bidding on bundles. If tasks have synergies (two pickups near each other are cheaper done together than apart), single-item auctions miss that, and robots should bid on bundles of tasks. Combinatorial auctions capture the synergies but the winner-determination problem is NP-hard, so systems use sequential single-item (SSI) auctions, where robots bid on individual tasks but factor in the tasks they have already won, capturing most of the synergy at a fraction of the cost. The Consensus-Based Bundle Algorithm (CBBA) (Choi, Brunet, How, 2009) is the widely used decentralized version: robots build task bundles greedily and then run a consensus phase to resolve conflicts (two robots wanting the same task), converging to a conflict-free assignment with a provable bound on how far it is from optimal.

Rule of thumb: Static snapshot, central computer, optimality matters: Hungarian algorithm. Streaming tasks, decentralized, robustness matters: auctions (CBBA or sequential single-item). The auction gives up a bounded amount of optimality to buy decentralization and fault tolerance, and for most fleets that trade is correct.

A taxonomy is worth knowing because it tells you which solver applies. Gerkey and Matarić's (2004) three-axis scheme: single-task versus multi-task robots (can a robot do more than one job at once), single-robot versus multi-robot tasks (does a task need one robot or several cooperating), and instantaneous versus time-extended assignment (assign only now, or plan a schedule into the future). The simplest cell (single-task robots, single-robot tasks, instantaneous) is exactly the linear assignment problem with its clean O(n³) solution. Every other cell is harder, and most are NP-hard.

Formation control

Sometimes the goal is to move together in a specific geometric shape rather than spread out on separate jobs: a line of survey drones, a protective ring around a payload, a V of UAVs that saves energy in trailing downwash. Formation control keeps a team in a desired relative configuration while the whole group moves. Three architectures dominate, and they differ in where the shape is defined.

Leader-follower. One robot is the leader and follows the mission trajectory; every other robot maintains a fixed relative position (a desired distance and bearing) to a designated leader or to the robot ahead of it. Each follower runs a simple controller that drives its relative-position error to zero:

Follower i tracks a desired offset (d_ij, φ_ij) from leader j:
  error = (measured relative pose) − (desired relative pose)
  control = −K · error       # a proportional controller closes the gap

It is simple, intuitive, and easy to implement, which is why it is common. The weaknesses are structural: the leader is a single point of failure (lose it and the formation has no reference), errors propagate and amplify down a chain of followers (the "string instability" problem, where a disturbance grows as it passes from robot to robot), and followers depend on sensing or hearing the leader reliably.

Virtual structure. Treat the entire formation as one rigid body. Define a moving coordinate frame (the virtual structure), assign each robot a fixed point in that frame, and have every robot track its assigned point as the frame moves and rotates. There is no privileged leader; the frame itself is the reference, and every robot is symmetric. This gives high precision and rigidity and eliminates the single-leader failure, at the cost of needing the robots to agree on where the virtual frame is (a consensus or synchronization problem, see below) and being less flexible when the formation must deform to fit terrain or obstacles.

Behavior-based. Each robot computes several desired behaviors (move to goal, maintain formation position, avoid obstacles, avoid neighbors) as separate vectors and blends them, usually as a weighted sum. The formation emerges from the balance of these local behaviors rather than being imposed as a rigid geometry. This is flexible and robust and handles obstacles naturally (the avoid-obstacle behavior just gets more weight when something is close), but the shape is soft and the emergent dynamics can be hard to prove stable.

A fourth idea, common in theory and increasingly in practice, is consensus-based formation, where robots agree on the formation through the distributed averaging described in the next section, with each robot's target expressed as an offset from the agreed group centroid. It combines the leaderlessness of the virtual structure with the graceful degradation of decentralized methods.

Architecture	Reference	Failure tolerance	Precision	Flexibility
Leader-follower	The leader robot	Low (leader critical)	Medium	Medium
Virtual structure	A shared moving frame	High (symmetric)	High (rigid)	Low
Behavior-based	Local blended vectors	High	Low (soft)	High
Consensus-based	Agreed group centroid	High	Medium-high	Medium-high

War story: A team runs a leader-follower line of six inspection robots down a pipeline. It works in testing with three. At six, a small speed wobble in the leader grows into a meter of oscillation by the tail robot, because each follower slightly overreacts to the one ahead and the error compounds down the chain. Nothing was broken in any single controller. The chain itself was the amplifier. The fix was to have every follower also reference the leader directly (beyond its immediate predecessor) so the error had no chain to grow along, which is exactly the string-stability lesson platooning research learned decades earlier.

Swarm principles: flocking, stigmergy, emergence

Swarm robotics is the extreme end of decentralization: many simple robots, each running identical local rules, with no global coordinator and no global knowledge, producing coherent group behavior. The inspiration is biological, ant colonies, bird flocks, fish schools, bee swarms, systems where no individual understands the global pattern yet the collective solves real problems. Three ideas carry the field.

Flocking (Reynolds' rules). In 1987 Craig Reynolds showed that lifelike flocking (his "boids") comes from three local steering rules, each computed from only the neighbors a boid can perceive:

For each agent, given its visible neighbors within radius r:

  1. Separation: steer away from neighbors that are too close
       v_sep = −Σ (p_neighbor − p_self) / |p_neighbor − p_self|²

  2. Alignment: steer toward the average heading of neighbors
       v_ali =  average(v_neighbor) − v_self

  3. Cohesion: steer toward the average position of neighbors
       v_coh =  average(p_neighbor) − p_self

  steering = w_sep·v_sep + w_ali·v_ali + w_coh·v_coh

That is the entire algorithm. Each agent looks only at nearby neighbors, blends three vectors, and moves. No agent knows the flock's shape, size, or destination, yet a coherent flock emerges, splits around obstacles, and rejoins. The three weights tune the character: heavy separation gives a loose spread, heavy cohesion a tight ball. Reynolds' rules are the ancestor of nearly every swarm-motion controller, and they scale trivially because each agent's cost depends only on its local neighbor count and stays flat as the total swarm grows.

Stigmergy. Coordination through the environment instead of through direct communication. Ants do not message each other about where food is; an ant that finds food lays a pheromone trail on the way home, other ants are biased to follow stronger trails and reinforce them, and the shortest path emerges because it gets traversed fastest and so accumulates pheromone fastest while longer paths evaporate. The environment itself carries the shared state. In robotics, stigmergy means robots leave traces (physical markers, digital "pheromones" in a shared spatial map, or modifications to the world like cleared or deposited material) that other robots sense and respond to. It sidesteps the communication bottleneck entirely: there is no network to congest because the coordination medium is the world. Ant Colony Optimization (Dorigo, 1992) turned this into a general algorithm for pathfinding and combinatorial optimization, and swarm robotics uses stigmergy for foraging, coverage, and construction tasks.

Emergence. The unifying principle: complex, useful global behavior arising from simple local rules with no global controller specifying it. The flock's shape, the pheromone-optimized path, the collective decision of a bee swarm choosing a nest site, none of these is programmed anywhere; each is a property of the interaction. Emergence is the source of swarm robotics' appeal (robustness, scalability, no single failure point) and its difficulty (you cannot straightforwardly program a desired global behavior; you have to find local rules whose emergent product is what you want, which is often reverse-engineered by trial, simulation, or evolution).

Rule of thumb: Swarm methods buy you scale and robustness and cost you predictability and precision. Use them when you have many cheap robots, a task that tolerates approximate collective behavior (coverage, search, herding, coarse formation), and an environment or comms situation that rules out central control. Do not use them when you need a specific robot in a specific place at a specific time to a tight tolerance; that is a job for structured allocation and formation control.

The honest limitation of swarms is that the mapping from local rules to global behavior runs one way. Given rules, you can simulate and see what emerges. Going backward, from a desired global behavior to the local rules that produce it, has no general method, which is why a lot of swarm engineering is simulation-heavy search over rule parameters, sometimes using evolutionary algorithms to breed rule sets whose emergent behavior scores well.

Communication and consensus

A decentralized team that shares no information is just a crowd. The moment robots need to agree on anything (a common coordinate frame, a synchronized clock, an average of their sensor readings, which target to pursue) without a central authority, you need distributed consensus. The foundational result is beautiful and practical.

Model the team as a graph: robots are nodes, and an edge exists between two robots that can communicate. Each robot i holds a value x_i (a heading, an estimate, a vote). The average-consensus protocol has every robot repeatedly update its value toward the average of its neighbors' values:

x_i(k+1) = x_i(k) + ε · Σ_{j ∈ neighbors(i)} ( x_j(k) − x_i(k) )

  ε = a small step size (stability requires ε < 1/max-degree)

In matrix form this is x(k+1) = (I − ε·L)·x(k), where L is the graph Laplacian. The theorem: as long as the communication graph is connected (there is some path between every pair of robots, not necessarily direct), every robot's value converges to the exact global average of all the initial values. No robot ever sees more than its neighbors, yet the whole team agrees on a global quantity. The rate of convergence is set by the second-smallest eigenvalue of the Laplacian, the algebraic connectivity (the "Fiedler value"): a well-connected graph converges fast, a stringy poorly-connected one converges slowly.

This one primitive is astonishingly general. It gives you distributed averaging of sensor readings (a leaderless team computing the average temperature it collectively measures), clock synchronization (agree on a common time), rendezvous (agree on a meeting point, the average of positions), leaderless formation (agree on the group centroid, then hold offsets from it), and distributed estimation (each robot fuses toward a common estimate). Olfati-Saber and Murray's (2004) analysis of consensus with switching topologies and delays is the reference that made this rigorous for real networks where the graph changes as robots move in and out of range.

The practical caveats are where it gets hard.

The graph must stay connected. If the team splits into two groups that cannot communicate, each group converges to its own local average, not the global one. Maintaining connectivity while the robots move (connectivity-preserving control) is its own research problem, because a robot's motion toward its task might break the only link holding the network together.

Communication is unreliable and delayed. Packets drop, links are asymmetric, and messages arrive late. Consensus is robust to a lot of this (it still converges under switching topologies as long as the graph is connected "often enough" in a union-over-time sense), but heavy loss and delay slow it or bias it.

Bandwidth is shared and finite. A radio channel is a shared medium; the more robots talking, the more they collide and back off (the same contention that congests Wi-Fi). This is a hard scaling wall, addressed below.

Rule of thumb: If your team needs to agree on a global quantity without a leader, reach for average consensus first; it is simple, provably correct on a connected graph, and needs only neighbor-to-neighbor messages. Then spend your engineering on keeping the graph connected and on tolerating dropped and delayed messages, because that is where real deployments break, while the consensus math itself holds.

Decentralized collision avoidance: RVO and ORCA

The single most-used piece of multi-robot math in the field is the machinery for two or more robots to avoid each other, in real time, using only what they can observe, with no communication and no oscillation. It starts with a clean geometric idea and fixes a subtle bug.

Velocity Obstacle (VO). Consider robot A avoiding robot B, both moving. In the space of A's possible velocities, there is a set of velocities that, if held, will lead to a collision with B at some future time (given B's current velocity). That set, a cone in velocity space emanating from B's velocity, is the velocity obstacle. A picks any velocity outside the cone (close to its preferred velocity toward its goal) and it is guaranteed collision-free for the horizon considered.

VO_A|B = { v : A on velocity v will collide with B (velocity v_B)
               within time horizon τ }

A picks v* = argmin |v − v_preferred|  subject to  v ∉ VO_A|B

The reciprocal problem. VO assumes B holds its velocity. But if B is also a robot running VO, B is also dodging, and now both robots dodge fully, overshoot, find themselves clear, both steer back toward goal, re-enter the collision cone, both dodge again. The result is oscillation, the robotic version of two people doing the sidewalk dance. The bug is that each robot assumed the other would not react, so each did all the avoiding, which is twice as much as needed.

Reciprocal Velocity Obstacle (RVO) (van den Berg, Lin, Manocha, 2008) fixes this with one assumption: each robot takes responsibility for half the avoidance, trusting the other to take the other half. Instead of choosing a velocity fully outside the cone, A chooses one that is the average of its current velocity and a collision-free velocity, so both robots each move halfway and together clear the collision without either over-correcting. The oscillation vanishes.

ORCA (Optimal Reciprocal Collision Avoidance) (van den Berg et al., 2011) is the refinement that made this production-grade and scalable to hundreds of agents. For each neighbor, ORCA computes a half-plane in velocity space of allowed (reciprocally collision-free) velocities. The intersection of all these half-planes (one per neighbor) is a convex region of safe velocities, and the robot solves a small linear program to find the velocity in that region closest to its preferred velocity:

For robot A each timestep:
  1. For each neighbor B, compute the ORCA half-plane:
       the set of A's velocities that reciprocally avoid B for horizon τ
  2. Intersect all half-planes  → convex feasible set of safe velocities
  3. Solve LP:  v* = argmin |v − v_preferred|  s.t. v in feasible set
  4. Move at v*

Because the constraints are linear and the number of neighbors is small (only nearby robots matter), the per-robot computation is cheap and runs at high rate. ORCA needs only each neighbor's observed position and velocity (sensed or broadcast), no negotiation, no shared plan, and it provably avoids collisions among cooperating agents while producing smooth, natural motion. It is the workhorse for dense multi-robot navigation and crowd simulation, and variants handle acceleration limits, non-holonomic robots (a differential-drive base cannot move sideways), and sensing uncertainty.

The catch worth stating: ORCA guarantees collision-freedom only if every agent runs the reciprocal protocol (or is correctly modeled). A non-cooperating agent (a human, an adversary, a robot on a different stack) breaks the assumption, so real systems treat unknown obstacles conservatively (full VO responsibility, larger safety radius) and reserve reciprocal avoidance for known cooperating fleet members. And ORCA is a local, reactive method: it can still drive robots into a dead-end deadlock (a doorway where several robots want to pass in opposite directions), which is why dense settings add a higher-level layer (priorities, reservations, or a central corridor scheduler) on top of the local avoidance.

Rule of thumb: For reactive avoidance among cooperating robots, ORCA is the default and it is cheap. Layer it under something that handles deadlock (priorities, right-of-way rules, or central routing at chokepoints), and treat any agent you do not control as a full-responsibility obstacle with margin, because reciprocity only holds among robots that are all playing the same game.

Multi-robot SLAM and shared maps

When a team explores or operates in an unmapped space, each robot runs SLAM locally, but the team's value comes from sharing what each has mapped. Multi-robot SLAM is single-robot SLAM plus two hard new problems: agreeing on a common reference frame, and recognizing when two robots have seen the same place.

The single-robot pipeline (front-end perception producing constraints, back-end optimizing a factor graph, loop closure snapping drift back) carries over. What is new:

Inter-robot loop closure. A single robot closes a loop when it revisits its own earlier location. A team closes a loop when robot A recognizes a place robot B mapped. This place-recognition-across-robots is the same appearance or geometric matching problem (bag-of-words, learned descriptors, scan matching) applied between different robots' data, and it is what lets two independently built maps be fused into one. It carries the same catastrophic-failure risk as single-robot loop closure: a false inter-robot match tells the optimizer two genuinely different places are the same, and the merged map folds. Robust back-end kernels and geometric verification are non-negotiable.

Frame alignment (the map-merging problem). Two robots that started in different places have their own local coordinate frames. To merge maps you must estimate the rigid transform between those frames, which is exactly what a verified inter-robot loop closure provides: a measured relative pose that ties the two trajectories together and lets one graph absorb the other. Before any such match, the maps float independently; after, they lock into a common frame.

Architecture: centralized vs distributed SLAM. Centralized multi-robot SLAM ships every robot's data (or processed constraints) to a server that builds one global graph. Simple and optimal, bandwidth-hungry, and dependent on connectivity to the server. Distributed multi-robot SLAM (the modern research frontier, systems like DOOR-SLAM, Kimera-Multi, and related work) has robots build local maps and exchange compact descriptors to detect inter-robot loops peer-to-peer, then run a distributed pose-graph optimization where each robot optimizes its own trajectory while agreeing on shared constraints, using distributed solvers built on the consensus ideas above. This scales and survives comms loss, at the cost of complexity and of only reaching agreement asymptotically.

Rule of thumb: If your team is small and reliably connected to a base, centralize the map: it is simpler and optimal. If it is large, exploring, or comms-denied (search-and-rescue underground, planetary teams), distribute it and treat the inter-robot loop closures as the fragile part, because a single false one corrupts everybody's shared map at once.

The payoff of getting this right is large: k robots exploring a space can cover it far faster than one, and a shared map means each robot benefits from ground it never drove, which is the whole reason to field a team for mapping in the first place.

Applications: warehouses, light shows, agriculture, defense

The theory lands differently in each domain because each has a different fleet size, communication budget, and tolerance for error.

Warehouse fleets. The largest deployed multi-robot systems on Earth are e-commerce warehouses running thousands of mobile robots. Amazon operates more than 1 million robots across its fulfillment network (mobile drive units plus stationary picking arms), coordinated by centralized fleet-management software that does global task allocation (which robot fetches which shelf or tote) and coarse routing on a known grid, while each robot handles its own local motion. This is the hybrid architecture in its purest commercial form: centralize the allocation and traffic management where the space is structured and the network is good, decentralize the reactive control. The grid layout is deliberate; it turns the messy continuous collision-avoidance problem into a discrete cell-reservation problem that a central scheduler can solve with strong guarantees (no two robots in the same cell, no deadlock), which is far more tractable than free-space avoidance at that density. See warehouse & logistics robotics and mobile robots: AMRs & AGVs.

Drone light shows. A show like Intel's or a modern successor flies hundreds to thousands of drones holding precise 3D patterns. These are almost entirely centralized and pre-choreographed: a ground system computes every drone's trajectory offline, verifies the whole ensemble is collision-free, and uploads each drone its own path, with each drone localizing via RTK GNSS to a few centimeters (see drone navigation & RTK) and executing its assigned trajectory. There is little real-time inter-drone coordination during the show; the coordination happened at design time. This is the right architecture because the environment is known, the network to the ground is good on the pad, and the value is precision, exactly the conditions that favor centralization. The hard engineering is the offline trajectory assignment (which drone goes to which point in the target shape, an assignment problem at scale) and collision-free transition planning between formations.

Agriculture. Fields invite multi-robot systems because the task is embarrassingly parallel: a field is divided into sections and robots (tractors, sprayers, or smaller units) cover them. Coordination is mostly task and area allocation (partition the field, assign sections) plus coverage-path planning within each section, with lighter real-time interaction because robots work separated regions. Fleets of autonomous tractors and swarms of smaller field robots are an active commercial area, and the coordination problem is closer to vehicle routing and area decomposition than to tight formation flying. Communication is often the constraint (rural connectivity), which pushes toward local autonomy with periodic sync.

Defense swarms. Military interest in swarms is driven by mass, attrition tolerance, and the reality of contested communications and GNSS denial. A swarm of many cheap systems can saturate defenses, degrade gracefully as individuals are lost, and, if it coordinates locally, keep functioning when the network is jammed. This is the domain that most needs true decentralization: you cannot assume a reliable link to a central controller in a contested environment, so each system must decide locally with intermittent peer communication, which is exactly the regime where consensus, local collision avoidance, and stigmergy-like coordination matter. The loitering-munitions and counter-drone literature tracks this closely, and the coordination questions (how a leaderless team allocates targets, maintains coverage, and avoids fratricide with intermittent comms) are the decentralized versions of everything in this guide.

Domain	Fleet size	Architecture	Dominant problem	Comms budget
Warehouse	Hundreds to thousands	Centralized alloc + local motion	Task allocation, cell reservation	Good (fixed infrastructure)
Drone light show	Hundreds to thousands	Centralized, pre-choreographed	Offline assignment, collision-free transitions	Good on pad, minimal in air
Agriculture	Tens	Area allocation + local autonomy	Field partitioning, coverage paths	Poor (rural)
Defense swarm	Tens to thousands	Decentralized	Local coordination under jamming	Contested / denied

The pattern across all four: architecture follows the communication budget and the structure of the space rather than fashion. Good comms and a structured space pull toward centralization and its optimality; poor or contested comms pull toward decentralization and its robustness.

The real scaling limits

Demos of ten robots are easy. Fleets of ten thousand are hard, and the walls are specific. Knowing them tells you why systems are built the way they are.

Communication is the first wall. A shared radio channel has finite bandwidth, and it is a contended medium: as more robots transmit, packets collide, robots back off and retransmit, and effective throughput per robot falls. Centralized coordination makes this worse because communication scales with fleet size (every robot to and from the center). Even decentralized neighbor-to-neighbor communication saturates when robots are dense (many neighbors in range all sharing the channel). This is why large swarms minimize communication (react to sensed neighbor states rather than exchanged messages) and why stigmergy (coordinate through the environment, zero network) is attractive at scale. Communication, more than computation, is what caps fleet size in practice.

Joint planning is combinatorial. Planning optimally for n robots in a shared space, treating them as one system, has a state space that is the product of the individual state spaces, so it grows exponentially in the number of robots. Optimal multi-robot path planning (routing many robots through a shared graph without collision) is NP-hard in general. This is why nobody plans a thousand-robot fleet jointly and optimally; they decouple it (plan each robot with the others as moving obstacles, or use prioritized planning, or reserve space-time cells), accepting suboptimality to make it tractable. Conflict-Based Search (CBS) and its bounded-suboptimal variants are the modern tools that push exact multi-agent pathfinding to larger teams, but the fundamental blowup remains.

Consensus slows with size and sparsity. Distributed agreement converges at a rate set by the graph's algebraic connectivity, which typically shrinks as the network grows and thins. A large, sparsely connected team takes many rounds to agree, and if it is moving and the graph is changing, agreement may never fully settle. Global properties that depend on consensus (a whole team synchronizing, a global average being computed) get slow and approximate at scale.

Failures become certain. With one robot, a failure is an event. With ten thousand, at any moment some robots are failing, dropping off the network, or behaving badly. Systems at scale must be designed so that individual failures are normal and absorbed (graceful degradation), which is a strong argument for decentralized and swarm architectures whose whole premise is that no individual is critical.

Emergent behavior is hard to certify. A decentralized or swarm system's global behavior emerges from local interactions and is genuinely difficult to predict, prove, or certify. For safety-critical or regulated deployments this is a real barrier: you can test extensively, but proving that a thousand-robot emergent system will never enter a bad global state is beyond current methods for most nontrivial rule sets. This is why high-consequence multi-robot systems lean toward architectures with more central structure and provable guarantees, accepting the scaling cost to buy predictability.

Rule of thumb: The wall you hit first is almost always communication, then combinatorial planning, then certifiability. Design as if bandwidth is your scarcest resource: push decisions and sensing local, minimize what has to be said, and prefer coordinating through the environment or through observed behavior over coordinating through messages. Everything that scales in multi-robot systems scales because it stopped needing to talk.

The honest state of the field in 2026: structured fleets in good-comms environments (warehouses, choreographed shows) are a solved and deployed technology at the scale of hundreds to thousands, running centralized allocation over local reactive control. Large decentralized swarms operating robustly in unstructured, comms-contested environments are real in research and in narrow deployments but not yet a mature, certifiable, general technology, and closing that gap (predictable, provable, large-scale decentralized coordination) is the central open problem.

Frequently asked questions

Centralized or decentralized: which should I use? Set it by fleet size, interaction density, and communication budget. Small structured fleets in good-comms environments (a warehouse) run centralized because you get global optimality and provable no-collision guarantees. Large teams, or teams in comms-poor or contested environments, run decentralized because centralized coordination's communication and computation grow with fleet size and it has a single point of failure. Most real systems are hybrid: centralize the slow global objective (task allocation), decentralize the fast reactive loop (collision avoidance).

What is the assignment problem and why does it matter? It is the problem of assigning n robots to n tasks to minimize total cost. The clean case (each robot one task, assign now) is solvable optimally in O(n³) by the Hungarian algorithm, which is why who-does-what has a rigorous answer for static snapshots. Streaming tasks, multi-task trips, and decentralization make it harder and push you to auction and market methods that trade optimality for speed and robustness.

How do auction-based task allocation methods work? Tasks are announced, each robot bids its own cost (usually distance or workload), and the lowest bidder wins each task. It is greedy and decentralized: robots need only their private cost function and local communication, and if a robot drops out its tasks are simply re-auctioned. It gives up a bounded amount of optimality for decentralization and fault tolerance. CBBA and sequential single-item auctions are the widely used versions that also capture task synergies.

What are Reynolds' flocking rules? Three local steering behaviors: separation (avoid crowding nearby neighbors), alignment (match the average heading of neighbors), and cohesion (steer toward the average position of neighbors). Each agent computes them from only the neighbors it can perceive and blends them. Coherent flocking emerges with no global coordinator and no agent knowing the flock's overall shape. It is the foundation of swarm-motion control and scales trivially because each agent's work depends only on local neighbor count.

What is stigmergy? Coordination through the environment instead of through direct communication. Ants coordinate foraging by leaving and following pheromone trails; the environment carries the shared state, so no direct messaging is needed. In robotics it means robots leave traces (markers, digital pheromones in a shared map, or physical changes to the world) that others sense and respond to. It sidesteps the communication bottleneck entirely, which is why it is attractive for large swarms where network bandwidth is the scaling wall.

How do robots avoid collisions without communicating? With reciprocal velocity-obstacle methods. Velocity Obstacles predict which velocities lead to collision given a neighbor's observed velocity. Reciprocal Velocity Obstacles and ORCA fix the oscillation that arises when both robots dodge fully, by having each robot take responsibility for half the avoidance. ORCA reduces this to a small linear program over safe-velocity half-planes and runs at high rate using only observed neighbor positions and velocities, no negotiation. It guarantees collision-freedom among agents that all run the protocol.

What is average consensus and what is it good for? A distributed protocol where each robot repeatedly nudges its value toward the average of its neighbors' values. On a connected communication graph, every robot provably converges to the exact global average, with no central coordinator and only neighbor-to-neighbor messages. It underlies distributed sensor averaging, clock synchronization, rendezvous, leaderless formation, and distributed estimation. The catch is that the communication graph must stay connected, and convergence slows as the network grows and thins.

How is multi-robot SLAM different from single-robot SLAM? It adds two problems: agreeing on a common coordinate frame between robots that started in different places, and detecting when two different robots have seen the same place (inter-robot loop closure). A verified inter-robot loop closure provides the transform that merges two local maps into one. It carries the same catastrophic risk as single-robot loop closure: a false inter-robot match corrupts everyone's merged map, so robust kernels and geometric verification are essential.

Why can't I just scale a ten-robot demo to ten thousand? Communication saturates first (a shared radio channel is contended, and centralized coordination's bandwidth grows with fleet size), then joint planning blows up combinatorially (optimal multi-robot planning is NP-hard, with a state space that is the product of individual state spaces), then consensus slows as the network thins, then individual failures become constant, and finally emergent behavior becomes hard to certify. The systems that scale are the ones that stopped needing to talk, by pushing sensing and decisions local.

When should I use a swarm approach versus structured coordination? Use swarm methods (identical local rules, no coordinator) when you have many cheap robots, a task that tolerates approximate collective behavior (coverage, search, herding), and an environment or comms situation that rules out central control. Use structured coordination (central allocation, formation control, cell reservation) when you need specific robots in specific places at specific times to a tight tolerance and you have the communication to support it. Swarms buy scale and robustness at the cost of precision and predictability.