Flockinator - a microscope for emergent behaviour

Swarms and emergent behaviour

Learn: Swarms and Emergent Behaviour

Imagine a valley after a flood. Roads are blocked, phones are down, and people need help in different places. One rescuer cannot check every house. A group that spreads out, shares what it finds, and calls others over can cover more ground.

This page explains that group idea, step by step. You can read it while you watch the wall of lights.

What you are looking at

Each square on the wall is a node: a Waveshare ESP32-S3-RGB-Matrix (N32R16, 32MB flash, 16MB PSRAM) with a P2.5 64x64 RGB LED panel, 160x160mm. Each node also has microSD storage per node, onboard mics, an SHTC3 temperature/humidity sensor, a QMI8658 IMU, a PCF85063 RTC, and perimeter speakers in printed carriers.

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

The quadcopter rescue scene is a visualisation on a shared virtual world plus the panel wall. Scored results are host replay, not on-node measurement.

1. What a swarm is

A swarm is many small units following simple local rules. No single unit sees the whole valley or tells the others what to do. They sense nearby, share short notes, and act. Useful group behaviour — spreading out, gathering where help is needed — appears from those local choices.

What to watch on the wall: look for patches of colour that spread, split, and rejoin without all panels changing at once.

One experiment that tests it:

  1. Run the same rescue task with 4, 8, then more simulated helpers.
  2. Keep the rules the same, change only the count.
  3. Compare area checked and time to first find. Check the repo docs for exact seed settings.

2. Extra-node intelligence

Extra-node intelligence means the knowledge is not inside one helper. It lives between them, in who trusts whom and what was last shared. One node may hold temperature, another may hold a sound clue, another may remember which path was already checked. Together they can act as if they remember the whole valley.

What to watch: watch two panels change after they exchange light pulses, even though neither had the full picture alone.

One experiment that tests it:

  1. Run a rescue task with clear messages allowed.
  2. Re-run with silence/private notes only.
  3. Re-run with corrupted messages. In host simulation replay we saw 72.9% team success with clear messages, 56.6% with silence/private, and 33.6% with corrupted — check the repo docs for method and limits.

3. Why groups look intelligent

Groups can look clever when three things line up: many tries at once, quick sharing of what worked, and forgetting what did not work. No one plans the smart move. Good finds get copied, poor paths fade away, and the group drifts toward help.

What to watch: watch one bright find attract neighbours, while dim areas go quiet.

One experiment that tests it:

  1. Start all helpers with the same simple rule.
  2. Turn sharing off, then on.
  3. See if finds cluster faster with sharing on. Check the repo docs for scoring details.

4. Acoustic language and pheromone harmonics

Helpers need a simple shared language. Here that means short sound signals through mics and speakers, plus a shared map of markers that rise and fall over time, like scent trails. The term harmonics just means repeated signals can add up or cancel out — check the repo docs for exact signal design.

What to watch: listen for short chirps from the carriers and see matching ripples or trails build on the panels.

One experiment that tests it:

  1. Run with sound markers on.
  2. Run with markers off or scrambled.
  3. Compare time to gather at a test site. Check the repo docs for marker lifetimes.

5. Explorer minority

It is safer if most helpers stay on known good paths while a few scout new ground. If everyone wanders, the group loses what it found. If no one wanders, the group misses people further away. A small scouting share often balances care and coverage.

What to watch: watch most panels hold steady while one or two probe the edges, then call others if they find something.

One experiment that tests it:

  1. Set 0 scouts, then a small scout share, then many scouts.
  2. Keep all else equal.
  3. Compare finds kept versus new ground covered. Check the repo docs for tested ratios.

How we test fairly

We work in a loop so results can be checked, not just admired:

  1. Flash firmware.
  2. Run a seeded rescue task.
  3. Save sealed journals and scores.
  4. Let separate review lanes critique the run.
  5. Build new firmware and re-run.

We pre-register falsifiable hypotheses, use held-out scoring, publish failures, hash-link datasets, and redaction-scan before sharing. Muse Wonder/Spark lanes build, review, and run assessors. SAM 3.1 was tested. Muse Image made illustrations. The coordinator ran for days across 15 pre-registered experiments.

Build notes, for reference: node with pio run --project-dir firmware/node-platform -e waveshare-s3, handheld with lilygo-s3, Korvo on ESP-IDF 6.1 pinned. Python via uv only. Identity is provisioned per device privately with tools/node-commissioner.

Be clear on limits: verified means label segregation, not crypto proof. No planner has passed full gates yet.

Source in the repo