Charter 13 · react · programme assignment

The Shy Bug

Data-Driven Behaviour

Create a readable personality driven by another team’s live data.

Difficulty
★☆☆
Prefix
sb
Zone
visitor-centre
Type
ladybug
Device
sb-01
Build time
6 hours

Mission

Build this

A servo and RGB creature that hides as aggregate visitor activity rises.

One kit, one team repository.

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

SourcePartFallback
● kitSG90 servo
● kitRGB LED
● kitActive buzzer

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

  1. Prove the connection first. Flash the unmodified first-message example with this charter’s zone, device type, and device ID.

    done when: sb-01 is alive on the developer view.

  2. 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.

  3. Publish one registered measurement. Use the exact measurement and unit below.

    done when: the reading appears without a reject.

  4. Add the physical response. Keep spine.loop() running and avoid blocking delays.

    done when: repeated movement does not interrupt publishing or reset the board.

  5. 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

TopicUnitSuggested interval
garden/visitor-centre/ladybug/sb-01/statusenumon change

Read another team

garden/entrance/counter/gk-01/count

Physical behaviour

Alive

Move through peeking, alert, and hiding poses without blocking MQTT.

Your call: Define the personality, response curve, recovery time, and sound restraint.

Engineering evidence

Test whether unfamiliar viewers can infer the intended states without explanation.

  1. Define three observable input scenarios.
  2. Ask at least five viewers to label the state.
  3. Revise once and report recognition before and after.

If you are fast: React independently to climate and crowd inputs.

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.

Backbone now

Live status

Updates from the same public event stream

Checking sb-01…