Flockinator - a microscope for emergent behaviour

How an experiment runs, end to end

How an experiment runs, end to end

This page follows one full cycle of our rescue-team testbed. Small helper devices practise sharing short rescue notes across a wall of lights and a matching computer twin. We show each step, what we keep, and where we fail. The aim is rigour you can check, with datasets others can scrutinise.

Why work in cycles

Each change is tested in a closed loop:

  1. Flash firmware
  2. Run a seeded rescue run
  3. Seal journals and scores
  4. Multi-model review lanes critique the run
  5. Build new firmware
  6. Re-run

We pre-register falsifiable hypotheses, use held-out scoring, and publish failures. Datasets are hash-linked, redaction-scanned, and shareable.

For exact forms and current file names, check the repo docs.

1. Write the guess down first

Before any code runs, we write what we expect and what would prove us wrong. For example: clear messages will help the team finish more searches than silence or corrupted messages.

The guess is frozen with a seed number that controls the layout. Later runs must use the same seed, so no one can pick an easy layout after the fact.

2. Build and flash the helpers

Our wall nodes are Waveshare ESP32-S3-RGB-Matrix boards (N32R16, 32MB flash, 16MB PSRAM) each driving a P2.5 64x64 RGB LED panel, 160x160mm. Each node has microSD storage, onboard mics, an SHTC3 temp/humidity sensor, a QMI8658 IMU, a PCF85063 RTC, and perimeter speakers in printed carriers.

The controller is an ESP32-S31 Korvo with display and touch, web host, planner sim, and learning lab. The handheld is a LilyGo T5 4.7in ESP32-S3. Power is a MEAN WELL LRS-350-5 5V supply. Diffusers, carriers, and mounts are Bambu PLA prints; finished CAD models live in cad/.

To prepare software:

  1. Build node firmware with pio run --project-dir firmware/node-platform -e waveshare-s3
  2. Build the handheld variant with environment lilygo-s3. Build the Korvo controller with pinned ESP-IDF 6.1.
  3. Run Python tools with uv only. Provision identity per device privately with tools/node-commissioner.

For full build flags and wiring notes, check the repo docs.

3. Run the rescue task on wall and twin

Each run uses the same seeded search layout. The quadcopter scenario is a visualisation on a shared virtual world plus the panel wall — lights stand in for helpers moving room to room. Scored results are host replay, not on-node scoring. The wall shows what is happening; the host twin records what counts.

  1. Flash the frozen firmware to all devices.
  2. Start the seeded rescue run from the controller.
  3. Let the helpers exchange notes while they search.

4. Collect everything, quietly

During the run we collect:

  1. Journals from each device, saved to microSD with timestamps from the onboard clock.
  2. Silent wall video, with no sound track.
  3. Host twin logs with matching timestamps and seeds.

Journals are sealed at the end of the run so later review cannot edit them. For camera placement and log format, check the repo docs.

5. Score by fixed rules

Scoring uses a deterministic scorer on the host replay. The same inputs always give the same outputs. Scoring uses held-out checks that were not visible during building.

Here, verified means label segregation, not crypto proof. In plain terms: data from different test conditions is kept in separate labelled folders during review, so clear, silent, and corrupted runs cannot be mixed by accident. For scorer settings, check the repo docs.

6. Review in separate lanes

Review is done by tiered model lanes plus a coordinator:

  1. Muse Wonder and Spark lanes build, review, and run assessors in separate passes.
  2. SAM 3.1 was tested as an additional lane. Muse Image was used for illustrations, not scoring.
  3. The coordinator collects critiques and suggests the next firmware change. The coordinator ran for days across cycles.

Lanes do not see each other's drafts until the critique step. That keeps disagreements visible instead of smoothing them over early.

7. Share honest results, including failures

No planner has passed full gates yet. We keep failures in the record.

One example: the honest baseline failed its frozen floors in cycle-07. We did not move the floors. We fixed the code and re-ran. In cycle-08 the same baseline scored 9 PASS / 9 UNMEASURED / 0 FAIL.

UNMEASURED means the check could not be applied to that run, not a hidden pass or fail. For gate definitions and per-cycle tables, check the repo docs.

8. What we have seen so far

From host simulation replay, NOT on-node, across 15 pre-registered experiments:

These are replay scores for comparison, not claims about live radio performance. All runs, seeds, and journals are kept hash-linked so others can replay and scrutinise the same data.

Source in the repo