24 Multi-Agent Systems and Coordination
The previous chapter ended on a scaling seam it could see but not cross: a single drone herds a single cohesive flock well, but the moment a flock splits — or a second flock lands across the site — one aircraft cannot hold two herding vectors at once. The Harassment Pattern Generation chapter’s whole design vocabulary assumes one point of pressure; a protected area large enough to need a lawnmower sweep is large enough to make one point of pressure a bottleneck. The obvious answer — add a second aircraft — turns out to be the least obvious part of the problem. Two drones over the same field are not twice one drone; they are a new kind of system, one whose members must divide work without duplicating it, share what they see without drowning their radios, avoid each other without a referee, and keep functioning when the thing coordinating them goes silent. This chapter is about that system.
It is also, deliberately, a chapter about architecture rather than a survey of vendors and acronyms. The multi-drone field has a large vocabulary — mesh networks, flying ad-hoc networks, formation taxonomies, commercial fleet-management suites — and a much smaller set of load-bearing ideas. The chapter works four of them in depth: the centralized-versus-decentralized design axis and the real evidence that the best answer is often neither extreme; one genuinely fielded ROS-plus-PX4 multi-drone framework, chosen because its stack is nearly the running example’s own; a decentralized collision-avoidance algorithm with an actual geometric core, deployed on physical quadrotors that sensed each other with cameras and never exchanged a message; and the concrete question the running example has earned the right to ask — what, exactly, would have to change about the Goose Management System’s single-drone code for two or three aircraft to fly it together? The chapter closes Part IV by answering that question at the level of topics, tokens, and nodes, using every piece of machinery the Part has built.
24.1 Learning Objectives
- Define a multi-agent system and identify the three coordination problems any multi-drone deployment must solve — task allocation, mutual collision avoidance, and shared situational awareness — independent of how the fleet is architected.
- Explain the centralized/decentralized architectural trade-off as a design space rather than a binary, using the classification literature’s separate axes (control, communication, awareness) and reported experimental evidence that hybrid architectures can outperform both pure extremes.
- Describe the architecture of a real ROS-plus-PX4 multi-drone framework — the MRS UAV System — and explain why redundant multi-frame state estimation and a swappable controller pair matter for multi-vehicle field deployment.
- Derive the velocity-obstacle picture of drone-on-drone collision risk, state the ORCA half-plane construction, and work a two-drone encounter numerically from relative velocity to each drone’s corrected command.
- Write the basic consensus update rule and a simple leader-follower separation-bearing law, and recognize both as the same error-times-gain pattern used by the book’s earlier control loops, with the error now measured against another aircraft.
- Redesign the running example’s single-drone architecture for \(N\) drones: per-drone topic namespaces, the scope of the active-controller token, a fleet-level allocator node, and the fallback behavior each drone needs when the allocator disappears.
24.2 Key Vocabulary
- Multi-agent system (MAS) — a system of multiple autonomous agents, each able to sense its environment, make local decisions, and communicate with peers, cooperating toward a shared mission objective rather than being driven as remote effectors of one program.
- Centralized coordination — an architecture in which one entity (a ground station or designated leader) holds the global picture and computes every agent’s assignment or trajectory; globally informed and easy to reason about, but its hub is a single point of failure and a communication bottleneck.
- Decentralized coordination — an architecture in which each agent decides from local information and peer-to-peer exchange, with no global authority; robust to individual loss and scalable, at the cost of harder-to-verify global behavior.
- Swarm — a fleet of cooperating drones treated as one collective; the term describes fleet behavior, not architecture — real swarms exist at both ends of the centralization axis.
- Telemetry sharing — the continuous exchange of vehicle state (position, velocity, heading, battery, mission status, detections) between aircraft or between aircraft and a ground station; the raw material of every coordination scheme that uses communication at all.
- Communication topology — the graph of who can exchange messages with whom — star, mesh, ring, fully connected — whose connectivity determines both a fleet’s failure modes and, for consensus algorithms, how fast agreement spreads.
- Velocity obstacle (VO) — for agent \(A\) facing agent \(B\), the set of velocities that, if held, lead to collision within a time horizon; the geometric object that turns “will we hit?” into a question about a region in velocity space.
- Reciprocal collision avoidance (RVO/ORCA) — a decentralized scheme in which each of two conflicting agents takes responsibility for half of the needed correction; ORCA expresses each pairwise obligation as a half-plane of permitted velocities, so avoiding all neighbors is a small linear program.
- Consensus protocol — a distributed update rule in which each agent nudges its own state toward its neighbors’ states, provably driving a connected network to agreement on a shared value with no central coordinator.
- Formation control — maintaining designed geometric relationships between flying agents; classically approached by leader-follower control, virtual rigid structures, or blended local behaviors.
- Task allocation — deciding which agent performs which job — which sector to sweep, which flock to herd, which corridor to watch — and reassigning as the world changes; the fleet-level twin of the single drone’s state machine.
24.3 What a Second Aircraft Buys — and What It Costs
A multi-agent system, in the standard sense, is a set of autonomous agents that each perceive their environment, decide locally, exchange information with peers, and share a mission objective. Every word of that definition is doing work. Autonomous excludes a fleet of remotely piloted aircraft — the agents decide, not a bank of operators. Locally concedes that no agent sees everything. Exchange admits that coordination has a price paid in bandwidth and latency. And share a mission objective is what separates a team from air traffic: two delivery drones deconflicting over a street corner are coexisting; two deterrence drones splitting a flock’s escape routes are cooperating.
For the running example, the benefits of a second or third aircraft are concrete and worth pricing honestly. Parallel coverage: the Path Planning on the Edge chapter’s lawnmower sweep is embarrassingly parallel — split the protected area into \(N\) sectors and \(N\) drones sweep it in roughly \(1/N\) the time, which matters because sweep time bounds how long a flock can graze undetected. Multiple simultaneous viewpoints: the Target Tracking and Visual Servoing chapter’s whole inner-loop apparatus exists because one camera loses what it cannot face; two aircraft on opposite bearings make the flock’s position estimate richer and the track harder to break. Multi-point pressure: the previous chapter’s herding geometry places one drone on one herding vector; two drones can close two escape directions at once, or one can herd while the other holds station over the escape corridor watching for the flock to double back. Graceful degradation: a single-drone mission ends when its battery does; a fleet rotates aircraft through charging and keeps the site covered. These are the classic advantages claimed for multi-drone fleets — parallel sensing, faster completion, redundancy — and for this mission each maps to a specific, named piece of Part IV machinery being duplicated or complemented.
The costs are just as specific, and they are the chapter’s real subject matter. The moment a second aircraft exists, three problems exist that no single-drone chapter ever had to solve. Who does what? — task allocation, because two drones sweeping the same sector paid double for nothing. How do they not hit each other? — mutual collision avoidance, because the airspace over the protected area is now shared by cooperating aircraft whose paths, unlike the goose’s, are fast, deliberate, and mutually invisible unless engineered otherwise. What does each believe? — shared situational awareness, because drone 1’s confirmed flock and drone 2’s confirmed flock may be the same birds counted twice, and a fleet that cannot agree on how many flocks exist cannot allocate itself sensibly. Every architecture in this chapter is a different answer to these three questions, and the axis along which the answers differ most is where the deciding happens.
24.4 Centralized, Decentralized, and the Space Between
The textbook contrast is easy to draw. In a centralized architecture, one entity — a ground control station, or one designated aircraft — collects every agent’s telemetry, holds the only global picture, and computes everyone’s assignments or trajectories; the agents execute. Coordination is exactly as good as the hub’s information and algorithms, which makes global optimization natural and debugging tractable: there is one place where every decision is made, and one log to read. The costs mirror the benefits point for point: the hub is a single point of failure, every byte of coordination transits its radio link, and both burdens grow with fleet size. In a decentralized architecture there is no hub: each agent decides from its own sensing and whatever its neighbors share, following local rules designed so that sensible global behavior emerges. Lose any aircraft — any aircraft — and the rest continue; add aircraft and no bottleneck saturates. The price is that the design problem inverts and hardens: instead of writing an algorithm that computes good global behavior, the designer must write local rules and then prove or test that good global behavior follows, and debugging means reconstructing a distributed interaction from \(N\) logs whose clocks may not even agree.
Two pieces of real research keep this picture honest, and both push back on the two-column-table version of it. The first is the classic classification of multi-robot coordination by Farinelli, Iocchi, and Nardi, which makes the point that “centralized versus decentralized” is not one switch but shorthand for a small design space: where control decisions are made is one axis, but it is separate from the communication structure (who can talk to whom, at what range) and from awareness — whether agents model their teammates at all or simply treat them as environment (Farinelli, Iocchi, and Nardi 2004). The axes combine freely. A fleet can be centrally controlled over a mesh network; a fully decentralized fleet can be built from agents that never model each other. Collapsing the space to a binary hides real designs — including most of the good ones.
The second is quantitative. A controlled comparison by Jamshidpey and colleagues put five control architectures — from random walk and decentralized beacon-following through a hybrid self-organizing hierarchy to fully centralized formation control and predetermined paths — on the same sweep-coverage task, using ground robots aided by UAVs, and measured them across coverage completeness, uniformity, completion time, scalability (at 4, 8, and 16 robots), and fault tolerance (with up to 75% of robots failed) (Jamshidpey et al. 2025). The reported pattern matches the folk trade-off in its outlines — centralized approaches generally stronger on completeness, uniformity, and time; decentralized approaches generally stronger on scalability and fault tolerance — but the reported headline is that a hybrid architecture, combining central structure with local self-organization, achieved better outcomes across more scenarios than either pure form. The trade-off, in other words, is real but not a dilemma: it is a menu, and the strongest fielded designs order from both columns. That finding shapes this chapter’s own design for the running example in its final section — a fleet with a central allocator and per-drone reflexes that survive the allocator’s death.
One more correction the literature insists on: “swarm” is not a synonym for “decentralized.” Crazyswarm, for years the standard academic swarm testbed, is reported to have flown 49 palm-sized Crazyflie quadrotors in tight indoor formation from a single central process — one computer tracking every vehicle by motion capture, planning every trajectory, and streaming commands over a few shared radios (Preiss et al. 2017). It is unambiguously a swarm, and it is architecturally a star with one very busy hub. What made centralization the right call there is instructive: indoors, with motion capture, the hub’s global picture is essentially perfect and its radio link is short and reliable — the two resources whose scarcity is the usual argument against centralization. Architecture follows the resource budget, not the vocabulary word.
24.5 A Framework That Actually Ships: The MRS UAV System
Between the diagram and a working fleet sits an unglamorous mountain of engineering — state estimation that survives sensor dropouts, controllers that fly real airframes in wind, per-vehicle configuration, simulation that matches the field — and it is worth studying one system that actually climbed it. The MRS UAV System, from the multi-robot systems group at the Czech Technical University in Prague, is the closest published match to this book’s own stack: it is built on ROS and integrates directly with the PX4 autopilot through a dedicated hardware-abstraction plugin, exactly the ROS-to-PX4 bridge shape the running example has used since Part II, hardened for multi-vehicle research deployment (Báča et al. 2021). Reading its architecture is like reading the running example’s own stack after several years of field seasons.
Two of its design decisions matter most for this chapter. The first is what the authors call multi-frame localization: each UAV estimates its state simultaneously in several coordinate frames — satellite navigation (GNSS), local odometry, vision-based sources — with redundant estimators that can be swapped in when a given source degrades (Báča et al. 2021). A single-drone hobby stack picks one localization source and hopes; a multi-drone field system cannot, because with \(N\) aircraft aloft, some source is degraded on some vehicle most of the time, and a fleet whose members silently diverge in their beliefs about where they are is a fleet whose separation guarantees are fiction. The Coordinate Frames chapter priced a single drone’s frame chain in centimetres and milliradians; MRS’s answer to that chapter’s error budget is redundancy with a switch. The second decision is a controller pair — an aggressive, precise controller and a smoother, noise-tolerant one, selected by mission phase (Báča et al. 2021). That is the two-personalities idea the running example met in miniature when the Harassment Pattern Generation chapter separated the swoop’s committed phase from the orbit’s patient one, promoted to a first-class architectural feature.
What makes MRS more than infrastructure for this chapter is what the same group built on top of it. Hořyna and colleagues reported a fully decentralized search-and-rescue swarm on this ROS/PX4 stack whose defining feature is coordination without explicit communication: each UAV detects its neighbors directly with an onboard RGB camera and adapts its own flocking motion accordingly — a “local visual communication channel,” in the authors’ framing, standing in for a radio link (Hořyna et al. 2023). Pause on how strong a statement that is. The slide-deck picture of multi-drone coordination is a picture of messages — telemetry sharing over MAVLink (Micro Air Vehicle Link, the telemetry protocol Part II introduced), mesh networks, synchronized clocks — and here is a fielded system reporting that the messages are optional: what coordination fundamentally requires is that each agent can estimate its neighbors’ states, and a camera pointed at a teammate is one estimator among several. The same lesson arrives from the wildlife side of the literature. A recent preprint from an MIT-led group describes a decentralized multi-quadrotor wildlife-monitoring system designed for exactly the constraint profile of a field deployment — no motion capture, no reliable central infrastructure, one RGB camera per drone — in which neighboring drones reconcile their independently detected animals by aligning bounding-box sets and passing the agreed identities around a ring topology, each drone talking only to its two neighbors in messages of a few hundred bytes, with consensus confirmed when the information returns to its originator (Chahine et al. 2025). The same work is candid about the cost: its own analysis notes that pairwise-registration success compounds geometrically as the ring grows, so the scheme does not trivially scale to large fleets (Chahine et al. 2025) — a real, quantified instance of the decentralized column’s “complex algorithms” bullet. And a drone-swarm field campaign monitoring zebra herds at a Kenyan conservancy — the published mission closest in shape to the running example’s own — coordinated its drones’ viewpoints with a particle-swarm-optimization placement algorithm and reported that the optimizer’s computation time was slow enough to degrade monitoring quality, motivating a faster redesign (Rolland et al. 2026). Coordination algorithms, that report reminds us, must clear the same latency bar the rest of this book’s control loops do: correct-but-slow is a failure mode, not a compromise.
24.6 Collision Avoidance Without a Conversation
Of the three coordination problems, mutual collision avoidance has the most elegant decentralized solution in the literature, and it is worth working in full because it is a complete, deployable algorithm whose entire mathematical content is one geometric construction. The line of work runs from velocity obstacles through Reciprocal Velocity Obstacles (RVO) (Berg, Lin, and Manocha 2008) to Optimal Reciprocal Collision Avoidance (ORCA) (Berg et al. 2011), and its premise is the same one the Vector-Based Threat Evasion chapter reached from the other direction: collision is a fact about velocities, not positions, so the natural place to reason about it is velocity space.
Model each aircraft as a disc (a safety envelope of radius \(r_A\), \(r_B\) — the same move the previous chapters made when they wrapped the goose in a safety radius). For agent \(A\), the velocity obstacle induced by agent \(B\) over a time horizon \(\tau\) is the set of relative velocities \(\mathbf{v} = \mathbf{v}_A - \mathbf{v}_B\) that, if held, bring the two envelopes into contact within \(\tau\). Geometrically it is a cone in velocity space, pointed at \(B\)’s relative position and truncated near its apex by a disc: relative velocities aimed at \(B\) and fast enough to arrive within the horizon. If \(A\)’s current relative velocity lies outside this region, the encounter resolves itself; inside it, something must change.
The naive fix — each agent picks the nearest velocity outside the other’s obstacle — has a famous failure mode: two agents approaching head-on each dodge the same way at the same instant, discover the conflict re-created, dodge back, and oscillate. RVO’s insight is that the dodging must be reciprocal: each agent assumes the other will also handle half of the correction, rather than assuming the other will plow on unchanged (Berg, Lin, and Manocha 2008). ORCA turns that insight into a linear constraint (Berg et al. 2011). Let \(\mathbf{u}\) be the smallest change to the current relative velocity that moves it just outside the velocity obstacle — the minimum correction that resolves the impending collision. Each agent takes responsibility for half of \(\mathbf{u}\), which defines for agent \(A\) a half-plane of permitted velocities:
\[ ORCA^{\tau}_{A|B} = \left\{ \mathbf{v} \;\middle|\; \left(\mathbf{v} - \left(\mathbf{v}_A + \tfrac{1}{2}\mathbf{u}\right)\right) \cdot \hat{\mathbf{u}} \ge 0 \right\}, \]
the set of velocities on the far side of the line through \(\mathbf{v}_A + \frac{1}{2}\mathbf{u}\), perpendicular to \(\mathbf{u}\)’s direction \(\hat{\mathbf{u}}\). With several neighbors, \(A\) intersects one half-plane per neighbor — a convex region in velocity space — and picks the velocity inside it closest to the velocity it actually wants (its goal-directed, pattern-following preference). That choice is a tiny linear program, solvable in microseconds, and re-solved every tick. Under mild conditions the construction guarantees each pair stays collision-free for at least the horizon \(\tau\) (Berg et al. 2011) — and since the program re-runs every tick, the horizon perpetually recedes.
A worked encounter. Put two of the running example’s aircraft on a collision course during a two-sector sweep: drone \(A\) at the origin flying east at \(\mathbf{v}_A = (1.3, 0)\) m/s, drone \(B\) six metres due east flying west at \(\mathbf{v}_B = (-1.3, 0)\) m/s, each wrapped in a 0.75 m safety envelope, so contact means the relative position closing within \(r = 1.5\) m. Take a horizon \(\tau = 2\) s. The relative velocity is \(\mathbf{v} = \mathbf{v}_A - \mathbf{v}_B = (2.6, 0)\) m/s — closing at 2.6 m/s with 4.5 m of clearance to lose, contact in \(4.5 / 2.6 \approx 1.7\) s, inside the horizon, so \(\mathbf{v}\) lies in the velocity obstacle. The obstacle’s truncating cap is the disc of radius \(r/\tau = 0.75\) m/s centered at \(\mathbf{p}_{B} / \tau = (3.0, 0)\); our \(\mathbf{v}\) sits \(0.4\) m/s from that center, inside the cap. For this head-on geometry the cheapest exit is straight backward through the cap boundary at \((2.25, 0)\) — the relative speed at which contact arrives exactly at the horizon — because any sideways exit through the cone’s flank is more than twice as far for these numbers. So
\[ \mathbf{u} = (2.25, 0) - (2.6, 0) = (-0.35, 0)\ \text{m/s}, \]
and agent \(A\)’s half-plane boundary passes through \(\mathbf{v}_A + \frac{1}{2}\mathbf{u} = (1.3 - 0.175,\, 0) = (1.125, 0)\), with \(\hat{\mathbf{u}} = (-1, 0)\): \(A\) may fly any velocity whose eastward component is at most \(1.125\) m/s. Its preferred velocity \((1.3, 0)\) violates the constraint, so the linear program returns the nearest permitted point, \((1.125, 0)\) — ease off by \(0.175\) m/s. Drone \(B\), running the identical computation from its own frame, eases off by the same amount in mirror image. The new closure rate is \(2.25\) m/s, and the check writes itself: \(4.5\ \text{m} / 2.25\ \text{m s}^{-1} = 2.0\ \text{s}\) — contact deferred to exactly the horizon, which next tick’s re-solve defers again, each round shaving speed until the conflict dissolves or geometry opens sideways. (A perfectly collinear encounter is a measure-zero special case; the moment the geometry is even slightly off-axis, the nearest exit becomes the cone’s flank and the familiar mutual sidestep emerges instead — implementations break exact ties by convention.)
Notice what the algorithm never needed: a message. Each agent requires only an estimate of its neighbors’ positions and velocities, and it is indifferent to where the estimate comes from — a shared telemetry stream, or perception. That indifference was demonstrated physically by Conroy, Bareiss, Beall, and van den Berg, who implemented reciprocal collision avoidance in three dimensions on real quadrotor helicopters with each vehicle sensing its neighbor’s relative position and velocity through an onboard camera — no motion capture, no GPS, no inter-vehicle communication — and reported that the avoidance held up even when a human pilot deliberately tried to steer one aircraft into the other, with the approach reported to scale in simulation to real-time operation for over a hundred vehicles (Conroy et al. 2014). Set that beside the Hořyna flocking result from the previous section and a theme crystallizes: the camera-and-estimator machinery Part III and Part IV built for geese is, unchanged in kind, the machinery that lets drones coordinate with each other when the radio is unavailable, jammed, or simply not trusted.
One more connection worth making explicit. ORCA is a reciprocal protocol — its halving of \(\mathbf{u}\) is a contract, honored by symmetric computation rather than by handshake, and it works because both parties run the same rule. The goose does not run ORCA. That is why the Vector-Based Threat Evasion chapter’s escape machinery and this section’s machinery remain two systems: against a non-reciprocating intruder, the drone must absorb the whole correction itself, which is exactly what the evasion vector does. Cooperative separation and adversarial evasion are both velocity-space reasoning, but only one of them gets to assume the other party is being reasonable.
24.7 Consensus and Formation: One Control Pattern, Again
Collision avoidance keeps a fleet apart; the remaining primitives pull it together — toward agreement on shared quantities, and toward designed geometry. Both reduce, pleasingly, to a control pattern the reader has now seen in every Part of this book.
Consensus. Suppose the fleet must agree on something — a common search altitude, a shared estimate of the flock’s centroid, a synchronized mission clock — with no coordinator to decree it. The canonical answer, analyzed in the standard reference by Olfati-Saber, Fax, and Murray, is the linear consensus protocol (Olfati-Saber, Fax, and Murray 2007): each agent continuously nudges its own state toward its neighbors’,
\[ \dot{x}_i = \sum_{j \in \mathcal{N}_i} a_{ij}\,\big(x_j - x_i\big), \]
where \(\mathcal{N}_i\) is the set of agents that \(i\) can currently hear (its neighbors in the communication graph) and \(a_{ij} > 0\) weights each link. In discrete per-tick form — the shape every control law in this book has taken —
\[ x_i(k{+}1) = x_i(k) + \epsilon \sum_{j \in \mathcal{N}_i} a_{ij}\,\big(x_j(k) - x_i(k)\big), \]
for a small step \(\epsilon\). Read it as a P controller: the “error” is each neighbor’s disagreement with me, the gain is \(\epsilon\, a_{ij}\), and the setpoint is wherever we all end up — under mild connectivity conditions on the (possibly time-varying) graph, every \(x_i\) provably converges to a common value (Olfati-Saber, Fax, and Murray 2007). A three-drone example makes it concrete. Drones 1, 2, 3 hold search altitudes of 12, 8, and 7 m and want to agree; the radio graph is a chain (1 hears 2; 2 hears 1 and 3; 3 hears 2), all weights 1, \(\epsilon = 0.25\). One tick:
\[ \begin{aligned} x_1 &\leftarrow 12 + 0.25\,(8 - 12) = 11.00 \\ x_2 &\leftarrow 8 + 0.25\,\big[(12 - 8) + (7 - 8)\big] = 8.75 \\ x_3 &\leftarrow 7 + 0.25\,(8 - 7) = 7.25. \end{aligned} \]
The spread has contracted from 5 m to 3.75 m in one step, and — a property worth noticing — the sum is still 27: with symmetric weights, the protocol conserves the average, so the fleet is converging on the mean of its initial opinions, 9 m, with no agent ever computing that mean. Run it again and the spread contracts by the same factor. How fast it contracts is governed by the communication graph’s algebraic connectivity — the second-smallest eigenvalue of the graph’s Laplacian matrix (Olfati-Saber, Fax, and Murray 2007) — which is the rigorous version of an intuition the topology vocabulary gestures at: a well-connected mesh agrees quickly; a sparse chain agrees slowly; a disconnected graph never agrees at all. The deck-level bullet “mesh topologies are robust” has, underneath it, an eigenvalue.
Formation. The literature’s three classical strategies are leader-follower (one drone flies its own trajectory; each follower servos to hold a desired range and bearing from its assigned leader), virtual structure (the formation is one rigid virtual body; each drone tracks its assigned offset from the body’s pose), and behavior-based (each drone blends local rules — cohesion, separation, alignment — in the style of classical boid flocking). The leader-follower scheme descends from the separation-bearing formulation introduced for nonholonomic ground robots by Desai, Ostrowski, and Kumar (Desai, Ostrowski, and Kumar 2001), and a minimal control law in that spirit is two proportional channels. If a follower measures range \(l\) and bearing \(\psi\) to its leader and wants to hold \(l_d\) and \(\psi_d\):
\[ \begin{aligned} v_{\text{cmd}} &= K_l\,(l_d - l) \\ \omega_{\text{cmd}} &= K_\psi\,(\psi_d - \psi). \end{aligned} \]
Speed up to close a range error; turn to fix a bearing error. The reader has written this controller twice already. It is the Closed-Loop Control chapter’s proportional law with the altimeter swapped for a range estimate, and it is precisely the Target Tracking and Visual Servoing chapter’s decoupled centering law — error, gain, command, per axis — with one substitution that is the whole point of this chapter: the error is now measured relative to another drone. Servoing on a goose’s pixels, holding a standoff behind a flock, and keeping formation on a wingmate are one control idea wearing three error signals, and everything that chapter taught about that idea — deadbands against jitter, saturation against lunges, gain versus delay — transfers intact. What is genuinely new in the multi-agent setting is not the controller but the graph: who measures against whom, and what happens to the formation when a link in that graph — a leader, a radio, a line of sight — goes away. Which is to say: the new content is architecture, and it is time to build some.
24.8 N Drones over the Protected Area
Everything so far has been other people’s systems. This section asks the chapter’s real question: the Goose Management System, exactly as Parts II through IV built it, is a single-drone architecture — so what specifically breaks at \(N = 2\), and what is the smallest honest redesign? Working that out requires being concrete about what the single-drone system is, so here is its coordination-relevant skeleton, assembled from the chapters that built it. One mission supervisor — the five-state machine of the Finite State Machines chapter — owns all behavioral decisions in a single-writer tick. Multiple behavior nodes (navigation, harassment) can each compute Offboard setpoints, and PX4 will fly whichever arrives; the stack prevents fights with the active-controller token, a String on one topic (/goose/active_controller, the constant T_ACTIVE_CONTROLLER) naming the node that currently owns the aircraft, and every behavior node’s tick begins by checking whether it is the one named. The harassment node reports pattern completion on T_HARASS_DONE and the supervisor — never the node — performs the transition. Perception publishes a world-frame target estimate that the orbit re-centers on every tick. And underneath everything, PX4’s own topics arrive under the /fmu/... namespace via the DDS bridge from the PX4 and the Autopilot Stack chapter.
Now clone the aircraft, change nothing else, and watch three failures happen in order.
Failure one: the graphs collide. ROS 2 topic names are global to the graph. Two aircraft whose bridges both publish /fmu/out/vehicle_local_position produce one topic carrying interleaved positions of two different vehicles; every subscriber — the supervisor’s staleness ladder, the harassment node’s self.pos, the frame chain — silently consumes a superposition of two drones. Nothing crashes; everything is wrong. The fix is the standard ROS 2 one, and it is the fix PX4’s own multi-vehicle simulation support anticipates — each vehicle runs its own PX4 instance, and everything the vehicle publishes or consumes lives under a per-vehicle namespace: /drone_1/fmu/out/vehicle_local_position, /drone_2/goose/active_controller, and so on. Done properly, this costs almost no code: nodes that already use relative topic names (goose/target, not /goose/target) are namespaced by launch configuration, unmodified — the single-drone stack becomes a per-drone stack by being launched differently, not rewritten. This is the first architectural law of the extension: everything about flying one aircraft stays inside that aircraft’s namespace.
Failure two: the token’s scope was never stated. With one drone, “the active controller” had an unambiguous referent. With two, is the token fleet-wide — one node in the whole system may command an aircraft? — or per-drone? The question answers itself the moment it is asked: the token exists to enforce PX4’s one-setpoint-author rule, and each aircraft has its own PX4, so the invariant is per-vehicle. /drone_1/goose/active_controller arbitrates drone 1’s nodes; /drone_2/... arbitrates drone 2’s; the namespacing of failure one already delivers this, and drone 1’s harassment node can own its aircraft while drone 2’s navigation node owns its aircraft, simultaneously and correctly. The token generalizes cleanly precisely because it was scoped to a resource (one vehicle’s setpoint stream) rather than to the mission. What the token cannot do — and was never built to do — is decide which aircraft should be harassing in the first place. That is not authority over a vehicle; it is allocation of work across vehicles, and it is genuinely new.
Failure three: nobody owns the mission. Each namespaced stack contains a supervisor that runs its aircraft’s mission — but “sweep the whole area without duplication, herd the flock without both drones converging on it” is a statement about the fleet, and no node anywhere holds it. This is the hole the architecture-axis section equips us to fill deliberately. The chapter’s choice, for a fleet of two or three: a centralized allocator — one new node, the fleet coordinator — assigning each drone a sector and a role, with the decentralized column’s virtues recovered through per-drone fallbacks. The reported evidence favors centralized allocation on exactly the metrics this mission cares about at this scale (coverage completeness and time (Jamshidpey et al. 2025)), the fleet is far too small for the hub’s scaling costs to bind, and a two-drone “emergent” design would spend its entire novelty budget avoiding one small node. But the same evidence says pure centralization buys its optimality with fragility, so the design is explicitly hybrid: the coordinator does slow allocation (a 1 Hz assignment loop — sectors, roles), each drone keeps its fast loops local (the 20 Hz supervisor tick, evasion, pattern flight, and an ORCA-style peer-separation filter fed by subscribing to the other drone’s namespaced position topic), and every drone treats the coordinator’s silence like any other stale telemetry: a heartbeat ladder, in the exact style of the Finite State Machines chapter’s staleness guards, that falls back to finish-my-sector-then-home when the allocator dies. Losing the coordinator degrades the mission; it grounds nothing.
The coordinator itself is a small node, and its skeleton is worth writing out because every line is a decision defended above:
class FleetCoordinator(Node):
"""Fleet-level allocation: sectors and roles, at 1 Hz.
Owns no aircraft. Each drone's own supervisor and token
arbitrate everything inside that drone's namespace."""
DRONES = ("drone_1", "drone_2")
def __init__(self):
super().__init__("fleet_coordinator")
self.sectors = split_lawnmower(PROTECTED_AREA, len(self.DRONES))
self.pose, self.flock, self.last_role = {}, {}, {}
self.role_pub = {}
for d in self.DRONES:
self.role_pub[d] = self.create_publisher(
String, f"/{d}/goose/role", 10)
self.create_subscription(
VehicleLocalPosition, f"/{d}/fmu/out/vehicle_local_position",
lambda m, d=d: self.pose.update({d: m}), qos_px4)
self.create_subscription(
Target, f"/{d}/goose/target",
lambda m, d=d: self.flock.update({d: m}), 10)
self.create_timer(1.0, self._allocate) # slow loop, by design
def _allocate(self):
flocks = merge_tracks(self.flock) # 2 drones, 1 flock? or 2?
if not flocks: # nothing found: sweep sectors
for i, d in enumerate(self.DRONES):
self._assign(d, f"search:{i}")
return
# one flock: nearest drone herds; the other guards the corridor
herder = min((d for d in self.DRONES if d in self.pose),
key=lambda d: dist(self.pose[d], flocks[0]))
for d in self.DRONES:
role = "herd:0" if d == herder else "guard:exit"
self._assign(d, role)
def _assign(self, drone, role):
if self.last_role.get(drone) != role:
self.get_logger().info(f"[ALLOCATE] {drone} -> {role}")
self.last_role[drone] = role
self.role_pub[drone].publish(String(data=role)) # heartbeat tooThree details carry the design. First, merge_tracks is doing the shared-situational-awareness job and deserves respect: two drones reporting flocks must be reconciled into a fleet-level belief — are these one flock seen twice, or two flocks? — which is the same data-association problem the ring-consensus wildlife system solved with bounding-box alignment (Chahine et al. 2025); for two drones over one site, gating by world-frame distance (tracks within tens of metres are one flock) is a defensible start, and the Coordinate Frames chapter’s error budget says how tight that gate may be. Second, the role message doubles as the coordinator’s heartbeat — republished every allocation tick even when unchanged, so each drone’s supervisor can run a staleness guard on it with no extra machinery. Third, the roles themselves are the previous chapter’s own vocabulary, promoted: herd is the herding-vector hold; guard:exit parks the second drone at standoff over the escape corridor, watching for the flock to double back and feeding the tracker a second viewpoint — one drone herding while another watches the escape corridor is the two-drone version of the herding architecture the previous chapter could only draw with one aircraft. On the drone side, the change is one subscription and one guard added to the supervisor: a role callback stores the assigned role; the tick’s preamble gains a coordinator stale > 5 s → fall back to own sector, then home rung on the existing staleness ladder; and SEARCH_GRID reads its waypoint list from the assigned sector rather than the whole area. The five states, the token, the behavior nodes, T_HARASS_DONE, the slew limiter — all unchanged. That smallness is the point, and it was purchased in earlier chapters: an architecture of single-writer ticks, resource-scoped tokens, and topic-shaped seams extends to a fleet by addition, not surgery.
What would not survive growth is worth stating with the same honesty the book applies to its own safety numbers. At \(N = 10\) the coordinator’s global merge_tracks and sector optimizer start to look like the PSO planner that could not keep up with the zebras (Rolland et al. 2026); the single allocation topic becomes the bottleneck the architecture chose knowingly at \(N = 2\); and the design pressure points toward the decentralized column — market-based or role-based task allocation negotiated among the drones themselves, in the style of the searcher/worker protocols reported for distributed search-and-rescue fleets (Freitas et al. 2021), consensus on the merged flock picture instead of a central fusion, and the fleet inheriting the fault tolerance that the reported evidence says decentralization buys (Jamshidpey et al. 2025). The chapter’s two-drone design is not the end state; it is the honest first rung, with the ladder above it clearly labeled.
24.9 Check Your Understanding
- A colleague argues: “We should make the goose fleet a true swarm — no ground coordinator — because swarms are decentralized by definition.” Using the Crazyswarm counter-example and the classification axes of Farinelli, Iocchi, and Nardi, explain what is wrong with “by definition,” and name the two resource conditions that made a fully centralized architecture the right call for that particular swarm.
“Swarm” describes fleet behavior — many vehicles acting as one collective — not where decisions are made; the classification literature treats centralized-versus-distributed control as one axis of a design space, separate from communication topology and from whether agents model each other at all (Farinelli, Iocchi, and Nardi 2004). Crazyswarm is the standing counter-example: a genuine swarm, reported at 49 nano-quadrotors in tight formation, flown by one central process that tracked every vehicle and streamed all commands over a few shared radios (Preiss et al. 2017). Centralization was right there because the two resources whose scarcity usually argues against it were abundant: near-perfect global state (motion capture indoors) and short, reliable communication links. Architecture follows the resource budget, not the vocabulary word.
- Two drones fly directly at each other 5 m apart, each at 1.1 m/s, each wrapped in a 0.5 m safety envelope (combined radius 1.0 m), with ORCA horizon \(\tau = 2\) s. Show that the current relative velocity is inside the truncated velocity obstacle, compute \(\mathbf{u}\), state each drone’s half-plane constraint, and verify that the corrected velocities defer contact to exactly the horizon.
Relative velocity \(\mathbf{v} = (2.2, 0)\) m/s; clearance to lose is \(5 - 1 = 4\) m, so contact arrives in \(4/2.2 \approx 1.8\) s \(< \tau\): inside the obstacle. The truncating cap is the disc of radius \(r/\tau = 0.5\) centered at \(\mathbf{p}/\tau = (2.5, 0)\); \(\mathbf{v}\) sits 0.3 from its center, inside. The nearest exit for this head-on geometry is the cap boundary at \((2.0, 0)\) — the relative speed for which contact takes \(4/2.0 = 2\) s — so \(\mathbf{u} = (-0.2, 0)\) m/s. Each drone takes half: drone \(A\)’s boundary passes through \(\mathbf{v}_A + \frac{1}{2}\mathbf{u} = (1.1 - 0.1, 0) = (1.0, 0)\) with \(\hat{\mathbf{u}} = (-1,0)\), so \(A\) may hold any eastward component \(\le 1.0\) m/s and picks \((1.0, 0)\), the permitted velocity nearest its preference; \(B\) mirrors. New closure \(2.0\) m/s, and \(4\ \text{m} / 2.0\ \text{m s}^{-1} = 2.0\ \text{s} = \tau\) exactly — and the program re-runs next tick, pushing the horizon out again.
- Three drones hold altitudes \((10, 6, 5)\) m on a chain graph (1–2, 2–3), weights 1, step \(\epsilon = 0.25\). Compute one consensus update for all three, verify that the sum is conserved, state what value the fleet is converging to, and explain — without computing eigenvalues — why the same fleet on a fully connected graph would converge faster.
\(x_1 \leftarrow 10 + 0.25(6-10) = 9\); \(x_2 \leftarrow 6 + 0.25[(10-6) + (5-6)] = 6.75\); \(x_3 \leftarrow 5 + 0.25(6-5) = 5.25\). Sum before: 21; after: \(9 + 6.75 + 5.25 = 21\) — conserved, because with symmetric weights every pairwise exchange is equal and opposite. The fleet therefore converges to the initial mean, \(7\) m, with no agent computing it. On a fully connected graph, drones 1 and 3 would also pull directly on each other instead of routing all disagreement through drone 2; more independent paths for disagreement to drain along is exactly what the graph’s algebraic connectivity measures, and higher connectivity is faster convergence (Olfati-Saber, Fax, and Murray 2007).
- The active-controller token was the single-drone stack’s answer to “who commands the aircraft?” Explain why the token generalizes to \(N\) drones without modification once topics are namespaced, why promoting it to a fleet-wide token would be a category error, and what genuinely new decision the fleet coordinator makes that no token — however scoped — could.
The token enforces a one-writer rule over a specific resource: one vehicle’s Offboard setpoint stream, into one PX4 instance. Namespacing gives each vehicle its own instance of that resource and its own copy of the token (/drone_i/goose/active_controller), so the invariant it protects — one setpoint author per autopilot — holds per aircraft with zero new code; drone 1’s harassment node and drone 2’s navigation node can each own their own aircraft simultaneously. A fleet-wide token would conflate authority over a vehicle with allocation of work across vehicles: it would permit only one aircraft to be commanded at a time, which is not a safety invariant but a mission-defeating bottleneck. The coordinator’s genuinely new decision is allocation — which drone sweeps which sector, which one herds, which one guards the corridor — a statement about the fleet’s division of labor that no arbitration mechanism scoped to a single vehicle’s command stream can express.
- Describe what actually goes wrong, at the message level, if two PX4 SITL instances are launched without namespaces so both bridges publish
/fmu/out/vehicle_local_position— and explain why this failure is more dangerous than a crash. Then state which single-drone nodes must change internally for the namespaced fix to work, and why the answer is “almost none.”
Both vehicles’ position estimates interleave on one topic, so every subscriber consumes an alternating superposition of two aircraft: the supervisor’s staleness guard sees a healthy fresh stream (it is fresh — half of it is just the wrong drone), the harassment node’s orbit computes its angle from a position that teleports between two vehicles, and the frame chain transforms detections against the wrong pose on alternate messages. Nothing throws; the system is confidently, silently wrong — the multi-vehicle version of the “wrong with confidence” stale-data failure, worse than a crash because no watchdog fires. The fix is per-vehicle namespaces (/drone_i/fmu/...), and nodes that already use relative topic names are namespaced entirely by launch configuration: the namespace is prepended at launch, so the single-drone code runs unmodified inside its box. Only code that hard-coded absolute topic names — or that must deliberately cross namespaces, like the peer-separation filter subscribing to the other drone’s position — needs touching.
- The two-drone design pairs a centralized 1 Hz allocator with decentralized 20 Hz per-drone loops and a heartbeat fallback. Justify each half of that split with the reported evidence from the sweep-coverage architecture comparison, and describe precisely what each drone does in the first five seconds after the coordinator process dies mid-mission.
The comparison reported centralized approaches generally stronger on coverage completeness, uniformity, and completion time — the metrics a two-drone deterrence mission lives on — and decentralized approaches generally stronger on scalability and fault tolerance, with a hybrid reported to do better across more scenarios than either extreme (Jamshidpey et al. 2025). The design takes the hint literally: allocation, which benefits from the global picture and tolerates a 1 s cadence, is centralized; everything with a deadline — the supervisor tick, evasion, pattern flight, peer separation — stays on the aircraft, so no fast loop ever transits the hub. When the coordinator dies: each drone’s role topic goes silent; for the first ~5 s nothing changes, because the last assignment remains valid and every fast loop is local; when the heartbeat staleness guard trips, each supervisor logs the fallback transition, continues its current sector to completion using its stored sector assignment, declines new engagements that depended on fleet roles, and ends with the normal return-home machinery. Mission degraded; fleet never endangered, never grounded.
24.10 Try It
Part 1 — two aircraft, one graph, no collisions of names. Bring up PX4 multi-vehicle SITL in Gazebo with two vehicles, each under its own namespace (/drone_1, /drone_2), and confirm with ros2 topic list that two disjoint /drone_i/fmu/... trees exist. Launch two complete copies of your single-drone stack from the previous chapters — supervisor, navigation, harassment, the active-controller token — one per namespace, and verify the claim this chapter made: if your nodes used relative topic names, they run unmodified. Split the protected-area polygon into two sectors, hand each drone its own lawnmower list, and fly both missions concurrently: takeoff, parallel sweep, land. The acceptance test is the logs — each drone’s [STATE CHANGE] history should be a complete, self-consistent single-drone story, and the combined coverage map (plot both position logs over the polygon) should show the full area swept with no leg flown twice. Then break it on purpose: relaunch with namespacing disabled and watch what the interleaved /fmu/out/vehicle_local_position stream does to each supervisor’s beliefs — five minutes of confidently wrong telemetry that will permanently change how you feel about topic hygiene.
Part 2 — a coordinator, a role swap, and a dead process. Add the fleet coordinator: sector assignment on goose/role at 1 Hz, a scripted flock in one sector, and the herd-and-guard allocation — nearest drone gets herd:0 and runs the previous chapter’s orbit against the target while the other gets guard:exit and holds standoff over the designated escape corridor. Add the heartbeat guard to each supervisor’s staleness ladder. Wire peer telemetry across namespaces — each drone subscribes to the other’s position — and implement a separation filter downstream of every behavior’s setpoints, in the same place the previous chapter’s safety-radius projection lives: at minimum a mutual-distance floor that projects setpoints apart, or the full ORCA half-plane from this chapter if you want the worked example flying in your own simulator. Then run the three torture cases this Part has taught you to run. Script the flock to bolt between the two drones and confirm the separation filter holds the floor while both aircraft maneuver — log inter-drone distance every tick and treat any dip below the floor as a failed test, not a warning. Kill the coordinator process mid-herd and confirm, from logs alone, the fallback sequence of Check 6: silence, staleness trip, logged transition, sector completion, return home. Finally, inject the Vector-Based Threat Evasion chapter’s threat at one drone mid-sweep and verify that its evasion, its re-entry, and its sector resume all happen inside its own namespace while the other drone’s mission proceeds untouched — one aircraft’s emergency staying one aircraft’s emergency being, in the end, the whole argument for the boxes.
Related Lab: No lab currently maps to this chapter.
This chapter closes Part IV, and the Part’s arc is worth seeing whole from its last rung. It opened with frames — the algebra that lets a pixel become a place — and then built upward through coverage paths, escape vectors, the state machine that arbitrates them, the servo loop that keeps the camera honest, and the deterrent patterns that give the mission its purpose. Each chapter’s machinery became the next one’s raw material, and this chapter spent all of it at once: the sweep became sectors, the token became per-vehicle, the servo law returned wearing a wingmate’s range error, the staleness ladder grew a heartbeat rung, and the herding geometry finally got its second aircraft. What the fleet still lacks is the thing no chapter has yet drawn in full: the complete system — every node, every topic, every authority transfer from perception to PX4, for one drone or several — laid out as one architecture and interrogated as one design. That is the business of the System Architecture chapter in Part V, where the running example is reassembled with the whole book behind it, and where the questions this Part deferred — including what it costs, ethically and ecologically, to run such a system at all — finally come due.