017 min
Act on a signal
Step a toy along the score strip, stopping on any score over the threshold.
Ask: “Did every high score mean a real target?”
Listen for: “No, there was a short spike.”
Brightlab
brightlab.Made for curious mindsbrightlab.Made for curious mindsBrightlab
Year 3 · Automation
Should one uncertain signal be allowed to trigger an action?
Go to the investigation ↓An actuator policy with a labelled timeline and before/after error counts.
How much evidence should the rover wait for?
A classifier output is only one part of a system. A controller decides whether and when to act. Our rover sees a synthetic sequence of target scores. A single spike can trigger an unnecessary stop. Requiring several consecutive high readings removes some spikes but delays action and can miss a brief real target. This is a controller simulation, not autonomous navigation.
Before this lesson: Read a yes/no sensor result and follow a simple rule. Useful earlier investigations: What the sensor missed; The playground planner.
A classifier output is only one part of a system. A controller decides whether and when to act. Our rover sees a synthetic sequence of target scores. A single spike can trigger an unnecessary stop. Requiring several consecutive high readings removes some spikes but delays action and can miss a brief real target. This is a controller simulation, not autonomous navigation.
Read a yes/no sensor result and follow a simple rule. Useful earlier investigations: What the sensor missed; The playground planner.
Print the supplied score timeline and marked target intervals. Use a toy rover to step across it. Rehearse how a low reading resets the consecutive-high counter.
ACARA V9 AI curriculum connection ↗ · Technologies ↗
A complete teaching sequence · 55 minutes
Step a toy along the score strip, stopping on any score over the threshold.
Ask: “Did every high score mean a real target?”
Listen for: “No, there was a short spike.”
Predict what requiring three high readings will change with the scores fixed.
Ask: “What might waiting protect us from? What might it cost?”
Listen for: “It can ignore a spike but stop later.”
Step the timeline with persistence 1, then 3. Record counter values, stops and missed intervals. Save each run for comparison.
Ask: “Why did the count return to zero?”
Listen for: “The next reading was below the threshold.”
Load the short real-target interval. Observe why waiting can miss it completely.
Ask: “Was the short high signal always noise?”
Listen for: “No, this one was a real brief target.”
Choose persistence and threshold for a stated fictional task. Compare on the same timeline and name a residual error.
Ask: “Which mistake does your design accept, and why?”
Listen for: “We accept some delay to avoid false stops, but not for every task.”
Draw sensor → score → counter → action with one trace.
Ask: “Where did our design choice enter?”
Listen for: “At the controller after the score.”
Every prediction should trigger an action.
A brief real target looks temporally like a noise spike; persistence can remove both.
Set an action policy and justify it with false-stop, missed-target and delay evidence.
Ask the learner to trace the counter across one below-threshold reading. Credit an explicit trade-off rather than insisting on one best setting.
| Criterion | Beginning | Secure | Extending |
|---|---|---|---|
| State tracing | Reads only the current score | Tracks consecutive highs and reset | Explains the timing of an action |
| Policy evaluation | Chooses the fewest actions | Compares misses and false stops | Justifies delay and residual risk for a task |
Use six time steps and physical counters; keep threshold fixed while investigating only persistence.
Compare consecutive-high gating with a rolling average and explain their different response to alternating spikes.
No physical robot is controlled. The synthetic task is not a road, medical or emergency system and must not be used as one.
Shared device? Turn remembering off. A project file lets you continue on another device.
Your browser is the laboratory
With scores fixed, predict how changing persistence from one to three readings affects false stops and delay.
Scores: 0.1,0.2,0.85,0.2,0.1,0.7,0.8,0.9,0.85,0.8,0.2,0.1,0.2,0.75,0.8,0.85,0.3,0.1. Real targets occupy steps 6–10 and 14–16. Threshold starts at 0.6.
The experiment opens after your prediction.
There is no penalty for being surprised.
Apple Silicon · PyTorch MPS
Evaluate thousands of seeded noisy timelines in parallel. Sweep persistence lengths and measure false stops and missed targets at a controlled threshold.
Students extend the experiment in teams, documenting parameters, outputs and limitations.
The bundle contains lesson-specific working code, a configuration file, a reactive notebook, a deterministic CPU check and hardware setup instructions. Acceleration is reported only after a tensor operation and result read-back succeed.
Download Mac Studio investigation ↓unzip y3-gate-mac-pathway.zip -d y3-gate-mac cd y3-gate-mac bash setup-mac.sh source .venv/bin/activate python experiment.py --device mps --output results marimo edit notebook.py
CPU and available-device execution status is recorded in the downloaded README and validation report. DGX Spark execution requires that hardware; static validation alone does not establish GPU compatibility or performance. The browser lesson remains fully available without this extension.
NVIDIA DGX Spark · PyTorch CUDA
Evaluate thousands of seeded noisy timelines in parallel. Sweep persistence lengths and measure false stops and missed targets at a controlled threshold.
Students extend the experiment in teams, documenting parameters, outputs and limitations.
The bundle contains lesson-specific working code, a configuration file, a reactive notebook, a deterministic CPU check and hardware setup instructions. Acceleration is reported only after a tensor operation and result read-back succeed.
Download DGX Spark investigation ↓unzip y3-gate-dgx-pathway.zip -d y3-gate-dgx cd y3-gate-dgx bash run-dgx.sh # Open the localhost notebook URL printed by the container.
CPU and available-device execution status is recorded in the downloaded README and validation report. DGX Spark execution requires that hardware; static validation alone does not establish GPU compatibility or performance. The browser lesson remains fully available without this extension.
An actuator policy with a labelled timeline and before/after error counts.
Download the editable handout →