Large numbers of robots need an aggregated overview, not a full list

What it is

Once the number of robots a supervisor must watch grows large, the interface should compress individual states into an aggregated overview rather than listing every robot's detail and leaving the supervisor to scan for problems. The unit of aggregation should track task, region, or dependency structure rather than simple robot count — the dimension chosen for aggregation is what determines which questions the overview can actually answer.

Why it happens

This rests on the limited capacity of human visual working memory and scanning ability: once the number of individuals exceeds what a person can hold in attention and compare at once, a full list or panel forces sequential scanning of every entry, which is both slow and error-prone. Aggregation compresses many raw data points into a handful of visual units the eye can take in at once — a distribution colored by status category, an overall health indicator — substituting perceptual pattern recognition for item-by-item cognitive checking, the same idea behind management by exception applied to visual display. But compression has a cost: every aggregation scheme that exposes macrostructure necessarily discards individual variation, and that cost is exactly what the boundary and application sections below have to manage. Which unit is chosen also shapes what questions a supervisor can even ask — aggregating by robot model exposes a different macrostructure than aggregating by operational region: the former surfaces "this batch of hardware has an elevated fault rate," the latter surfaces "coordination in this region is running poorly." Pick the wrong aggregation dimension and the overview simply cannot answer the question the supervisor actually has, which is a more fundamental failure than "not enough detail."

Studying it

A standard test has supervisors complete the same "find the problem individual in the fleet" task under a full-list interface and an aggregated-overview interface, comparing completion time and accuracy as fleet size grows — the aggregated interface is expected to hold up as size increases while the list interface degrades noticeably. Such studies should also include equal-mean, different-distribution scenarios: the same average battery level, once with every robot uniformly a bit low and once with most robots fine but a few critically depleted, to check whether the aggregation scheme itself hides the more dangerous of the two cases.

Where it stops holding

Aggregation only pays off when the fleet is genuinely large and the supervisory task is "spot an overall pattern or anomaly" rather than "confirm every individual's detail." For small fleets — a handful of robots — or tasks that inherently require checking each individual, such as per-robot acceptance testing or tightly coordinated manipulation, aggregation adds an unnecessary layer of abstraction and a direct list may serve better; over-aggregation can also bury a rare but high-consequence outlier under an otherwise normal-looking summary. The size threshold is not a fixed number either — it depends on how much individuals differ: a fleet where every robot runs an identical task and looks alike does not strain scanning much even at moderate size, whereas a small fleet whose members carry very different tasks and sit in very different environments can already benefit from aggregation. An overview is an entry point for attention, not a substitute for the underlying evidence a real check still requires.

Applying it

Design the concrete form of the overview — counts, status distributions, geographic heat maps — around the decisions the supervisory task actually needs, such as clustering by operational region, task type, and risk level and showing count, distribution, trend, and data coverage together, rather than simply re-skinning detailed data as a different chart type; keep filters and the time window stable so supervisors are not re-configuring the view on every check. Verify it with the completion-time-and-accuracy test above at the target fleet size, and specifically with equal-mean, different-tail scenarios to confirm operators can spot the real risk through the overview and drill into it, rather than being reassured by an average. Before launch, aggregate the same historical data by several candidate dimensions — model, region, task type — and ask actual supervisors which one best matches the questions they need to answer day to day, rather than letting designers pick the aggregation dimension by intuition alone.

Related

• Same group: X7.07.2 Aggregated views need a path down to single-robot detail · X7.07.3 Outlier robots must stand out in an aggregated view, not get averaged away · X7.07.4 The level of aggregation should match the supervisory task's grain, not stay fixed
• Nearby: X7.04 Multi-robot supervision · X3.01 Visible Current State
• Search terms: fleet-level aggregation · situation awareness · human-swarm interaction