Flockinator - a microscope for emergent behaviour

The experimental method

When a rescue team enters a damaged building, radios crackle, lights flicker, and information arrives out of order. This project recreates that kind of confusion in a small, repeatable way, so we can study how teams share what they see and decide what to do next.

It does not test people. It tests coordination methods under controlled confusion.

Why human perception counts as an instrument

Computers are good at logging every message. People are good at noticing when something feels wrong.

Human senses are shaped by biology for pattern matching and quick intuition. We spot a pause that is too long, a voice that sounds unsure, two reports that do not fit together. No log file flags those moments on its own.

So we use people as detectors first, and measurement second:

  1. Put the shared situation where everyone can see it.
  2. Create narrow points where the team must come together.
  3. Let people notice strangeness.
  4. Then let recorded data decide whether that hunch holds up.

A hunch starts the inquiry. It does not settle it.

What the room looks like in practice

Imagine a search for missing occupants after a partial collapse. Each helper is represented in a shared virtual world, shown together on a wall of light panels.

That wall is made of P2.5 64x64 RGB LED panels, 160x160mm each, driven by small computer nodes around the room. Each node also has microphones, temperature and humidity sensing, motion sensing, a clock, a memory card, and small speakers in printed carriers. Together the panels form one large, low-resolution picture everyone can watch.

The quadcopter view in this setup is a visualisation in that shared virtual world plus the panel wall. It is not a flying aircraft in the room.

Checkpoints are built into the rescue task. For example, the team must regroup at a stairwell to compare notes, or pass findings through one relay person. At those bottlenecks, missing updates, duplicated warnings, or corrupted locations become visible. People often see the problem first — “we never heard back from the basement team” — and then we check the logs to confirm what happened.

The loop: flash to re-run

Every test follows the same seven steps. The wording is plain on purpose, so any run can be repeated.

  1. Flash firmware. Load the same software onto each wall node.
  2. Run a seeded rescue task. A fixed starting number sets the order of events, delays, and message problems. Same seed means same confusion.
  3. Collect. Nodes save sound levels, sensor readings, timing, and message records to microSD. Journals and scores are sealed at the end of the run so they cannot be edited afterward.
  4. Score. Results are scored on a separate host computer by frozen scoring code that does not change between compared runs. This is called held-out scoring.
  5. Multi-model critique. Separate Muse Wonder and Spark lanes help build the setup, review the design, and run assessors. They read the sealed records and point out flaws, alternative explanations, and missing checks.
  6. Refine firmware. Change one thing at a time based on that critique.
  7. Re-run. Run again with the same seed, plus a new seed to check that the fix was not a one-off.

The coordinator for this work ran for days across many cycles to keep the sequence consistent.

How we keep the test fair

Before a run counts, we write down what we expect to see and what would prove us wrong.

Illustrations for this work were made with Muse Image, and SAM 3.1 was tested as one of the analysis options. Those tools help explain and check, they do not decide the score.

What we have seen so far

All scored numbers below are host simulation replay, not on-node measurement on the wall itself.

Across 15 pre-registered experiments:

In plain terms: when everyone could see the same clear updates, teams finished the search task most often. When updates were silent or kept private, success fell. When messages were damaged, success fell further.

These are early patterns, not proof that one method is always best. Failed runs and edge cases are kept with the same care as successful ones.

What this runs on

The wall nodes use a Waveshare ESP32-S3-RGB-Matrix board (N32R16, 32MB flash, 16MB PSRAM) with SHTC3 for temperature and humidity, QMI8658 for motion, PCF85063 for time, onboard microphones, microSD per node, and perimeter speakers.

A separate ESP32-S31 Korvo board provides display, touch, web hosting, rescue planner simulation, and learning lab functions. A LilyGo T5 4.7in ESP32-S3 unit works as a handheld display. Power is from a MEAN WELL LRS-350-5 5V supply. Diffusers, carriers, and mounts are printed in Bambu PLA, with finished CAD models in cad/.

Build notes:

Source in the repo