A visual guide to the quadcopter survey rehearsal
An observation becomes a report. A report invites another viewpoint. The panels make that sequence visible—provided we know what each signal actually means.
01 / The mission story
The objective changes the interpretation of a state: Observe surveys the scene; Compare reports highlights checking and disagreement; Recovery foregrounds returning and availability. These are the model’s existing goal labels.
The camera view, sensor styling, altitude and battery graphics communicate a simulated situation. A moving view is not proof of a real flight controller, a sensor reading or an optimised route.
The ESP32 renders a 64 × 64 frame. Each thumbnail here comes from that firmware renderer with an explicit documentation fixture. It is not a live screenshot.
The communication-learning lab is a separate controlled exercise. Its observations, decisions and outcomes can test whether messages help. The animation alone cannot.
02 / An explanatory decision tree
Use this tree to narrate the survey. It describes questions an experiment should make observable, rather than claiming these are implemented autonomous transition rules.
03 / A message is an event, not a conclusion
The one-pixel border is on for 250 ms, off for 125 ms, on for 250 ms, then off. The footer temporarily shows the peer: TX B1 on A1 pairs with RX A1 on B1. TX ALL denotes a broadcast; receivers still name the source.
SHARE / REPORT followed by CHECK / VERIFY is a useful explanatory vocabulary for inviting corroboration. It is not a literal payload decoded from these images. A real assessment needs the sent report, its receipt and the recipient’s later action.
The preview can show one source and multiple recipients from one scripted event. This explains the event’s scope. It does not mean the receiver acknowledged it, believed it or agreed with it.
LOST concerns an observation. NOLINK concerns the represented stale view. DOUBT concerns conflicting claims. Keep these distinctions visible instead of treating every failure as “bad communication.”
04 / A shared observation needs an owner
The browser preview includes a separate 12-second illustration. Roles and P1 labels are predetermined. It makes a cooperative observation story legible; it does not demonstrate a learned auction or consensus protocol.
| Preview time | Display | Story shown | Communication cue |
|---|---|---|---|
| 0–2 s | ALERT | A source announces symbolic beacon P1. | Source broadcasts. |
| 2–4 s | PRIORITY | P1 is shown first in the task order. | No new event in this phase. |
| 4–6 s | CLAIM / CHECK | Two selected nodes offer to inspect. | Claims at 4.000 s and 4.875 s, addressed to the source. |
| 6–10 s | ASSIGN / YIELD | One node owns the observation; others yield. | The source broadcasts the assignment at 6 s. |
| 10–12 s | SEEN / SCAN | The owner observes; other nodes resume scanning. | No new event in this phase. |
These times describe previews/recon-hud/coordination.mjs, not the firmware’s complete mission schedule. In particular, the assignment broadcaster is the source; its identity can differ from the owner shown on the panels.
05 / The panel vocabulary
The first-person lines are presenter captions. Open each card for the visual meaning and the next question to ask. Scope: the firmware enum has 30 states; this atlas shows 25. ENGAGE and KILL are outside this non-weaponised survey scenario; FRIEND, TARGET, and BLANK are not shown.
25 of 30 states shown
Waiting for a mission
“I have no active task.”
The panel shows READY and REMOTE START.
Next: An operator-authorised rehearsal can begin. Readiness is a display state, not proof that every subsystem passed a pre-flight check.
Mission acknowledged
“The demonstration has been authorised.”
MISSION APPROVED blinks on a black panel.
Next: Show the mission briefing. This is not a real aircraft arming signal.
Understand the objective
“My task is to survey, compare reports or recover.”
The briefing shows SURVEY, COMPARE or RECOVER with SHARE DATA and KEEP CLEAR.
Next: Interpret later observations against the selected objective. The illustration uses the survey briefing.
Enter the simulated world
“The rehearsal is starting.”
The camera and altitude presentation transition into the flight view.
Next: Proceed to the deployment presentation. No motor command is produced by this renderer.
Form up
“I am moving into my assigned part of the scene.”
DEPLOY and FORM UP accompany the simulated movement.
Next: Begin the observation phase. The moving picture alone does not establish a computed flight plan.
Look for an observation
“I am looking for something relevant to the task.”
A scanning overlay marks the observation phase.
Next: Keep searching, or enter SEEN when the scenario presents a candidate observation.
Continue observing
“I am maintaining an observation role.”
LOITER is accompanied by a GRID or ORBIT caption.
Next: Continue observing, respond to a review request, or move into the recovery branch when the scenario requires it.
A candidate observation
“I have noticed something; I have not established what it means.”
A bracket highlights an observation in the scene.
Next: Share a report or seek a check. A bracket is not a confidence score or proof of correct identification.
Offer a report
“Another node may benefit from what I observed.”
SHARE normally shows REPORT. During a communication event, the footer can show TX plus the peer label.
Next: A receiver can consider the report alongside its own observation. The current scripted flash does not itself deliver a real payload.
Seek corroboration
“I need to compare this report with independent evidence.”
CHECK and VERIFY identify a review state; an RX footer can temporarily replace VERIFY.
Next: Continue observation if evidence is incomplete; record agreement or disagreement in an instrumented experiment. Do not equate receipt with agreement.
Keep uncertainty visible
“The available reports do not yet agree.”
DOUBT, a contrasting reticle and the 2 CLAIMS caption show a conflict presentation.
Next: Request another check, keep the observation unresolved, or resume the survey. Two claims can repeat the same source and are not necessarily independent.
Observation no longer available
“I cannot currently maintain this observation.”
LOST is accompanied by SEARCH.
Next: Revisit the observation task or record that the evidence is unavailable. It does not mean that the network link has failed.
Wait for coordination
“I am waiting for the next task decision.”
HOLD and HQ WAIT distinguish waiting from active observation.
Next: Continue when the scenario supplies the next instruction. A waiting panel is not evidence that a model is currently thinking.
Announce a shared observation
“There is a symbolic beacon for the group to review.”
ALERT shows BEACON P1. In the coordination fixture, its source transmits to the other panels.
Next: Move into the fixture's review sequence. P1 is a scripted label, not an inferred urgency or confidence value.
Display the selected task order
“The rehearsal is considering P1 first.”
PRIORITY displays P1 FIRST.
Next: The fixture presents candidate volunteers. This display does not implement a learned priority calculation.
Offer to inspect
“I am volunteering for this observation task.”
CLAIM displays CLAIM P1. Two predetermined participants send their claims separately to the source in the preview fixture.
Next: Wait for the assignment presentation. A claim is an offer, not ownership or evidence that the node is best placed.
Show the observation owner
“I have the observation role for this rehearsal.”
ASSIGN displays OWNER and a node label.
Next: The chosen observer continues observing. The fixture chooses the owner deterministically; no bidding optimisation is demonstrated.
Avoid duplicate ownership
“Another node owns this observation task.”
YIELD displays the same OWNER label as the assignment.
Next: Other participants can return to their survey roles. This is a presentation of coordination, not proof of distributed consensus.
Return to the base
“This rehearsal is moving into recovery.”
R2B and HOME identify the return presentation.
Next: Proceed toward LAND. The example does not specify a real aircraft's reserve threshold or navigation policy.
Finish simulated flight
“I am completing the return sequence.”
The camera/altitude presentation descends into the home view.
Next: Show CHARGE or STANDBY according to the scripted outcome.
Recharge presentation
“I am unavailable while the demonstration shows replenishment.”
CHARGE includes an animated battery indicator.
Next: Return to standby when the sequence advances. The indicator is simulated, not a measured charging current.
Ready for the next role
“I am waiting at the base.”
STANDBY presents the parked state.
Next: Remain available for a subsequent authorised rehearsal.
Stale view or missing link
“I do not have a fresh view to rely on.”
NOLINK freezes the camera presentation and shows an AGE caption.
Next: Treat the represented information as stale. In this scripted mode, AGE is scene time rather than measured packet latency.
Simulated energy exhausted
“The rehearsal has reached an energy failure state.”
The battery indicator falls and the view dims.
Next: Record the simulated failure outcome. This is not a physical battery measurement or an instruction for aircraft recovery.
Simulated failure outcome
“This run has ended in a simulated failure.”
The view rolls toward the ground, then later shows signal loss.
Next: Preserve the event trace for review. The thumbnail shows an early phase of the display sequence, not a photograph or real crash report.
06 / From a flashing frame to a defensible finding
In the separate learning lab, a listener learns sender–symbol associations from training feedback. During held-out evaluation, decoded peer cues contribute to its symbolic sector choice alongside its private clue. This is receiver learning with assigned sender vocabularies—not a claim that the panel renderer learned a language.
The Meta reviewers should cite those records and distinguish an observation, an interpretation and a proposed improvement. Reviewing logs does not establish a gain until a new, comparable evaluation measures it. These documentation fixtures are not assessment evidence.
Run ID, node identity, firmware/policy version, simulation tick, observation reference, message source and ID, receipt time, selected action, reason code, uncertainty, outcome and missing-data flags.
Same-time flashes do not establish causation. More messages do not establish more useful information. A stronger reviewer does not establish a smarter node. Copied SD logs do not establish local execution.
07 / Reproducible documentation
This package contains the renderer driver, state descriptions, generation script and a source-hash manifest. It makes no network or hardware calls. Use uv run --no-project build-guide.py --repo /path/to/flockinator to regenerate it with C++17 and FFmpeg installed.
firmware/node-platform/include/recon_render.h — actual pixels, captions, colours and pulse timing.firmware/shared/recon/model.h — scripted states, goals and event construction.previews/recon-hud/communication.mjs — presentation pairing and broadcasts.previews/recon-hud/coordination.mjs — the 12-second preview fixture.tools/mission-host/coordination_lab.py — separate message-learning exercise.Scope: non-weaponized survey, cooperative observation and recovery. This guide is not a flight-control manual and does not document attack selection or engagement logic.