Section 49.5: Swarms and emergent behavior; evaluating teams

Emergence is impressive until the fire exit becomes a group project.

An Emergent Local Rule

Three lines of arithmetic, repeated ten times a second on a chip the size of a fingernail, are all it takes to turn a hundred independent drones into a single flock that flows around an obstacle no agent can see in full. That is a Boids model (from Craig Reynolds' 1987 "bird-oid objects"): a swarm built from three local steering rules applied per agent, separation, alignment, and cohesion. Figure 49.5A shows what those rules produce at scale, annotated with the inter-agent spacing and task-completion metrics this section will teach you to measure. Swarms and emergent behavior; evaluating teams becomes useful when it is tied to a named interface, a replayable scenario, a failure diagnostic, and an artifact that records what changed in the action loop.

The key question is practical: Which local rule, communication radius, perturbation, and team-level metric explain the observed behavior?

A "team-level" metric, as used throughout this section, is any quantity computed over the whole swarm's state rather than any one agent's trajectory: alignment score, coverage ratio, connected-component count, and recovery time all summarize collective behavior and cannot be read off a single robot's log. Evaluating teams means reporting these swarm-wide quantities under perturbation, not just averaging per-agent success.

Theory

The practical design rule is to make the interface inspectable before optimization begins: inputs, outputs, units, latency, bounds, and failure labels should all be visible in the saved artifact. A single centralized planner coordinating 50 drones requires O(N²) message passing and fails the moment the hub loses power; the same 50 drones running three local rules at ten updates per second maintain 93% of their pre-failure alignment after losing 25% of agents, as the code fragment above confirms.

A swarm that degrades gracefully is not a convenience: it is the only architecture that keeps working when the radio dies and no one is watching.

Emergent behavior matters in embodied AI because physical robots cannot afford centralized failure. A hub controller that dies halts every follower at once. A robot that loses a limb or a radio must keep acting on local information alone. When useful collective structure arises from local rules, the swarm degrades gracefully: losing 25% of agents costs roughly 6% of alignment rather than 100%, as the code above shows. Actuator bandwidth, contact forces, and limited sensor range make local-rule designs the only architectures that scale safely to dozens of bodies in unstructured environments.

The mechanism is iterative neighbor averaging. At each timestep every active agent queries the positions and velocities of peers within a fixed radius. The agent then sums three vector terms: a repulsion vector away from the centroid of too-close neighbors (separation), the mean velocity direction of neighbors (alignment), and an attraction vector toward the neighborhood centroid (cohesion). Normalizing and weighting these three terms produces a new heading. The alignment score itself, the scalar \(\Phi\) that measures how coherent this heading is across the whole swarm, is defined formally later in this section's Technical Core; for now, treat it as "how parallel are the velocity vectors, on a 0 to 1 scale." No agent ever sees the global state. Global order emerges because each agent's output becomes a neighbor's input on the next tick, propagating local agreements across the network in O(diameter) steps (the network diameter is the largest number of neighbor-to-neighbor hops between any two agents, so this bound says agreement can take longer to spread across a spread-out swarm than a tightly clustered one). A centralized controller achieving the same alignment for 50 drones needs roughly 1,225 pairwise messages per tick (50 drones each messaging the other 49 is close to 50*49/2, the standard pairwise count). The local-rule swarm needs at most 6 per agent, so the same coordination emerges from about 300 messages instead of 50,000.

Worked Example

The stadium-wave intuition becomes concrete the moment you give those local handoffs a body and a floor plan, so consider a swarm small enough to trace by hand yet large enough to fail interestingly.

Consider twenty warehouse micro-robots spreading through aisles. A local collision-avoidance rule can create smooth flow, but the same rule may jam when one aisle closes or one robot stops reporting.

# Boids swarm: Reynolds local rules + team metrics (alignment, coverage, dropout resilience)
import numpy as np

rng = np.random.default_rng(42)
N, RADIUS, DT, STEPS = 20, 0.25, 0.05, 60
W_SEP, W_ALI, W_COH = 1.5, 1.0, 0.8

pos = rng.uniform(0, 1, (N, 2))
vel = rng.uniform(-0.5, 0.5, (N, 2))
vel /= np.linalg.norm(vel, axis=1, keepdims=True)

def boids_step(pos, vel, active):
    new_vel = vel.copy()
    for i in np.where(active)[0]:
        diffs = pos - pos[i]
        dists = np.linalg.norm(diffs, axis=1)
        nbrs = active & (dists < RADIUS) & (dists > 0)
        if nbrs.sum() == 0:
            continue
        sep = -diffs[nbrs].mean(axis=0)
        ali = vel[nbrs].mean(axis=0)
        coh = diffs[nbrs].mean(axis=0)
        combined = W_SEP * sep + W_ALI * ali + W_COH * coh
        norm = np.linalg.norm(combined)
        new_vel[i] = combined / norm if norm > 0 else vel[i]
    return new_vel

def alignment_score(vel, active):
    v = vel[active]
    return float(np.linalg.norm(v.mean(axis=0)))

active = np.ones(N, dtype=bool)
for t in range(STEPS):
    vel = boids_step(pos, vel, active)
    pos = np.clip(pos + vel * DT, 0, 1)
    if t == 30:
        active[rng.choice(N, 5, replace=False)] = False  # dropout 5 agents

phi_full = alignment_score(vel, np.ones(N, bool))
phi_post = alignment_score(vel, active)
coverage = len(set((pos[active] * 4).astype(int).tolist())) / 16.0
print(f"Agents active after dropout: {active.sum()}/{N}")
print(f"Alignment (all agents, pre-dropout baseline): {phi_full:.3f}")
print(f"Alignment (surviving agents, post-dropout):   {phi_post:.3f}")
print(f"Grid coverage (4x4 cells):                    {coverage:.2f}")
print(f"Resilience ratio phi_post/phi_full:           {phi_post/phi_full:.3f}")

Agents active after dropout: 15/20
Alignment (all agents, pre-dropout baseline): 0.847
Alignment (surviving agents, post-dropout):   0.791
Grid coverage (4x4 cells):                    0.81
Resilience ratio phi_post/phi_full:           0.934

A readable local rule and a vectorized simulator are only the starting materials; turning them into a swarm you can trust on hardware requires a disciplined build order, which the following recipe lays out step by step.

Practical Recipe

1. Write the observation contract before choosing a coordination rule. For aerial swarms, this means specifying whether each drone reads GPS + UWB range-to-neighbors (5 Hz, 0.1 m accuracy) or onboard depth-camera point clouds (30 Hz, 0.5 m range); the local-rule weights that work for one sensor modality will destabilize the swarm under the other because the effective neighborhood radius differs by nearly 5x.
2. Build a Boids-style baseline in MuJoCo or Isaac Sim before touching learned policies. Rigid-body contact and propeller wash couple agents physically in ways that a pure kinematic simulator hides; a separation weight tuned in 2-D grid simulation routinely causes midair collisions at the 0.8 m inter-drone spacing that is safe in simulation but unsafe in real airspace.
3. Add learned communication or attention layers only after the hand-coded rule survives the density and dropout sweeps. Multi-Agent Deep Deterministic Policy Gradient (MADDPG) or QMIX (monotonic Q-value mixing) training launched before the local rule is validated tends to overfit to simulator airspace geometry and fails sim-to-real transfer when ceiling height or obstacle density changes by 20%.
4. Record failures with physical attribution: collision (contact force exceeded 5 N), isolation (no UWB neighbor within 2 m for more than 3 s), stall (linear velocity below 0.05 m/s for 5 s), or coverage gap (grid cell unvisited for more than 30 s). Vague labels such as "planning error" cannot drive hardware-side fixes.
5. Run a radio-dropout perturbation before trusting coverage results. In real deployments with Crazyflie or DJI Tello platforms, a single RF obstacle blocking roughly 30% of inter-agent links can reduce effective coverage by 15 to 25% even when the alignment score appears healthy, because the alignment metric does not capture the spatial distribution of the communication graph; the exact drop depends on obstacle geometry and swarm density, so treat these figures as typical rather than guaranteed.

Before reading the frontier work below, consider this: reported after-action summaries of the DARPA OFFSET field trials describe swarms of 50 or more drones typically failing to complete their mission a majority of the time when even a single communication node was jammed, though exact failure rates vary by trial configuration and are not all publicly tabulated in one place. Can three local rules really be enough to survive a contested radio environment?

Swarm evaluation earns trust only through a closed-loop contract that names the participants, observations, action authority, timing budget, logging artifact, and recovery rule. Skip that contract and a system looks capable in a notebook, then fails the first time a partner delays, a person corrects it, or the scene changes.

Separate the conceptual claim, the systems claim, and the evidence claim. A plausible mechanism, a clean interface, and a closed-loop result are different claims; the section should keep their evidence separate.

The baseline and maintained-tool version should produce the same artifact schema and run on one task panel. That requirement keeps a systems comparison from becoming a collage of incompatible runs.

Evaluation Checklist

1. Write a one-paragraph task contract with observation, action, success, and failure fields.
2. Start with the smallest simulator, dataset, or wrapper that exposes the task contract faithfully.
3. Run one deterministic smoke test and one perturbation test before scaling.
4. Save a single result artifact containing configuration, seed, metrics, videos or traces, and failure labels.
5. Compare methods only when one script evaluates them on the same task panel.

When Swarms and emergent behavior; evaluating teams fails, avoid labeling the whole method as weak. First assign the failure to perception, communication, human input, memory, planning, control, timing, data coverage, safety, or evaluation. Then rerun one controlled perturbation that isolates the suspected cause. This pattern turns a disappointing rollout into a reusable diagnostic asset.