Mission
Build this
One conductor device that exchanges beat and status messages with a partner team’s existing device.
Borrowed parts are labelled below and have a fallback. The assigned device ID is fixed; sensing and behaviour decisions remain yours.
Bill of materials
Parts
| Source | Part | Fallback |
|---|---|---|
| ● kit | SG90 servo | — |
| ● kit | Passive buzzer | — |
| ● kit | OLED | — |
Disconnect USB before rewiring. Motors, the relay, and the servo need appropriate power and a shared ground. Never drive an actuator from the ESP32 3V3 pin.
Assembly
Build in evidence-producing steps
- Prove the connection first. Flash the unmodified first-message example with this charter’s zone, device type, and device ID.
done when:
ch-01is alive on the developer view. - Bench-test one input. Read the sensor or control in Serial Monitor before publishing or moving an actuator.
done when: repeated physical conditions produce repeatable raw readings.
- Publish one registered measurement. Use the exact measurement and unit below.
done when: the reading appears without a reject.
- Add the physical response. Keep
spine.loop()running and avoid blocking delays.done when: repeated movement does not interrupt publishing or reset the board.
- Run the investigation. Collect the planned trials before tuning the final logic.
done when: the build log contains observations, method, and a limitation.
Contract
Your topics
| Topic | Unit | Suggested interval |
|---|---|---|
garden/visitor-centre/chorus/ch-01/beat | count | 1–5 s |
garden/visitor-centre/chorus/ch-01/status | enum | on change |
Read another team
garden/visitor-centre/ladybug/sb-01/statusPhysical behaviour
Alive
Keep a visible beat and change the pattern after partner messages.
Your call: Choose leader, follower, or negotiated-turn behavior with the partner team.
Engineering evidence
Measure latency, missed beats, duplicate handling, and recovery after disconnect.
- Log send and receive sequence numbers.
- Interrupt Wi-Fi during a fixed test.
- Report recovery time and how stale messages are handled.
If you are fast: Invite a third team without changing the payload contract.
Acceptance
Ready when all six are true
- The registered device is alive and publishing its required topics.
- The reject feed is clear after the final firmware starts.
- The device reads at least one declared cross-team topic.
- A physical output responds to real data without blocking MQTT.
- The build log contains method, evidence, uncertainty, and a known limitation.
- The enclosure exposes no unsafe wiring and the device ID can be scanned.