Integrate & defend.Sound-Aware Smart Room
System integration, sound data, fail-safe switching and an independently reviewed capstone. Showcase build: a low-voltage model smart room that answers a trained knock pattern, with a manual override and a peer-reviewed safety case.
- 16 projects8 robotics, 4 AI, 4 integrated
- 20 to 80Sessions by plan
- Python + ArduinoMain language
- Supervised linkAI to hardware
What students do, and what they prove.
Sound-Aware Smart Room
A low-voltage model smart room that answers a trained knock pattern, with a manual override and a peer-reviewed safety case.
Learning check. Integrate sensing, a tested model and fail-safe switching into one system, then defend it with evidence in an independent review.
Individual check. Every learner, on their own: “Justify a false-trigger budget.”
Entry task
Run a reproducible pipeline with a baseline, read a state machine and explain an independent stop.
Robotics core
Sound sensing, relay switching of low-voltage loads, debouncing, power budgets, fault injection and system integration.
AI layer
Timing features from object sounds, false-trigger budgets, robustness across rooms, drift checks and independent audits.
Code & tools
Python and Arduino C/C++ with version control; optional SQL and JavaScript. Arduino IDE, Python + scikit-learn, Git (local), AI assistant (with consent).
Cross-subject link
Electromagnetic relays, semiconductor devices, probability and technical writing.
Scaffolding
Board-year pacing: compact build cycles, Class 11 templates and a capstone scope agreed in writing.
How AI meets hardware here
Local inference and bounded serial control. The relay is off by default and a manual switch always wins.
Sixteen projects, four blocks of twenty sessions.
Each block follows the same pattern: two builds, one AI project, then one integrated project. Open any project to see its five sessions.
- RRobotics
- AAI
- IIntegrated
- 01Ask & understand · Week 1Sound as vibration: amplitude, noise and thresholds
- 02Build & design · Week 1Wire the sound module and read its output
- 03Implement · Week 2Log readings and estimate the noise floor
- 04Test & improve · Week 2Test distance, surface and background noise
- 05Explain & reflect · Week 3Justify a trigger threshold with numbers
Grade 12 UNO, sound sensor module (LM393), USB, breadboard, jumper wires
Twenty readings each in quiet and noisy conditions; the threshold is set from data, not guesswork.
A physical circuit, sensor or mechanism, built and tested on the bench.
- 06Ask & understand · Week 3Relays, isolation and why mains stays out of student work
- 07Build & design · Week 4Wire the relay to a low-voltage lamp
- 08Implement · Week 4Program off-by-default switching with debounce
- 09Test & improve · Week 5Test power loss, reset and manual override
- 10Explain & reflect · Week 5Document every safe state
UNO, 1-channel relay module, low-voltage lamp module, on-off switch, push button, approved pack
Twenty switching cycles plus power-loss, reset and manual-override tests.
A physical circuit, sensor or mechanism, built and tested on the bench.
- 11Ask & understand · Week 6Features without recordings: peaks, gaps and duration
- 12Build & design · Week 6Collect a labelled knock-pattern dataset
- 13Implement · Week 7Train a classifier and a timing-rule baseline
- 14Test & improve · Week 7Evaluate on a separate recording session
- 15Explain & reflect · Week 8Explain which patterns the model confuses
Local Python/scikit-learn, knock-feature CSV logged in P01
Split by recording session; compared with a timing-rule baseline.
A model, an evaluation study or an AI-checking workflow.
- 16Ask & understand · Week 8Map predictions to named commands only
- 17Build & design · Week 9Rehearse the link in a simulator first
- 18Implement · Week 9Validate every command on the controller
- 19Test & improve · Week 10Test stale, unknown and low-confidence input
- 20Explain & reflect · Week 10Show that the manual switch always wins
P02 and P03 builds, USB or simulator, manual override switch
Twenty recorded patterns plus invalid, stale and low-confidence cases.
A laptop model sends named commands only after bench tests, with a simulator as fallback.
- 21Ask & understand · Week 11Latency, bounce and why timing matters
- 22Build & design · Week 11Add timestamps at every stage
- 23Implement · Week 12Implement debounce and a refractory window
- 24Test & improve · Week 12Measure delay under repeated triggers
- 25Explain & reflect · Week 13Report the median and worst-case delay
UNO, sound module, relay module, LED, logging computer
Fifty timed triggers; delay reported as a median and a worst case.
A physical circuit, sensor or mechanism, built and tested on the bench.
- 26Ask & understand · Week 13Current, power and battery capacity
- 27Build & design · Week 14Plan safe measurement points with the trainer
- 28Implement · Week 14Calculate a duty-cycle power budget
- 29Test & improve · Week 15Check the estimate against a timed run
- 30Explain & reflect · Week 15Recommend a safe power design
UNO, relay module, lamp module, buzzer, approved pack, trainer multimeter
Idle, active and fault currents measured; the estimate is compared with a timed run.
A physical circuit, sensor or mechanism, built and tested on the bench.
- 31Ask & understand · Week 16The cost of a false trigger versus a miss
- 32Build & design · Week 16Score held-out patterns at many thresholds
- 33Implement · Week 17Plot the trade-off and choose an operating point
- 34Test & improve · Week 17Confirm the choice on an untouched session
- 35Explain & reflect · Week 18Defend the budget to a non-specialist
Local Python/scikit-learn, P03 dataset plus a new held-out session
Precision, recall and false triggers per hour reported on an untouched session.
A model, an evaluation study or an AI-checking workflow.
- 36Ask & understand · Week 18When should a system refuse to act?
- 37Build & design · Week 19Add confidence and freshness gates
- 38Implement · Week 19Write an append-only decision log
- 39Test & improve · Week 20Replay held-out sessions through the full link
- 40Explain & reflect · Week 20Trace one decision through the log
P04 to P07 builds, USB or simulator, manual override switch
Same held-out sessions and safety limits; every rejection logged with a reason.
A laptop model sends named commands only after bench tests, with a simulator as fallback.
- 41Ask & understand · Week 21How placement and housing change what a sensor hears
- 42Build & design · Week 21Build two mounts and an enclosure
- 43Implement · Week 22Log the same test set for each
- 44Test & improve · Week 22Compare reliability by position
- 45Explain & reflect · Week 23Recommend a mounting with evidence
UNO, sound module, teacher-cut enclosure parts, fasteners, screwdriver
The same knock set in three mounting positions, before and after the enclosure.
A physical circuit, sensor or mechanism, built and tested on the bench.
- 46Ask & understand · Week 23Failure modes, effects and priorities
- 47Build & design · Week 24Build a failure-mode table for the room
- 48Implement · Week 24Add a watchdog and sensor-health checks
- 49Test & improve · Week 25Inject five faults and record each outcome
- 50Explain & reflect · Week 25Present the recovery evidence
Smart-room build, physical power switch, local console
Five injected faults: unplugged sensor, stuck input, brownout, lost link and reset.
A physical circuit, sensor or mechanism, built and tested on the bench.
- 51Ask & understand · Week 26Where AI coding help goes wrong
- 52Build & design · Week 26Write the tests before asking for suggestions
- 53Implement · Week 27Request and review suggestions for one module
- 54Test & improve · Week 27Keep only changes that pass every test
- 55Explain & reflect · Week 28Report what the tests caught
School-approved AI assistant (parent consent on file) or a trainer-prepared suggestion set, local tests, Git
Ten suggestions reviewed; every kept change passes the full test suite.
A model, an evaluation study or an AI-checking workflow.
- 56Ask & understand · Week 28Why models degrade in a new room
- 57Build & design · Week 29Summarise the training-data feature ranges
- 58Implement · Week 29Compare live features with those ranges
- 59Test & improve · Week 30Plant three shifts and one normal session
- 60Explain & reflect · Week 30Write a retraining and rollback rule
P08 build, logged features, local Python, manual override switch
Three planted shifts trigger manual fallback; a matched session does not.
A laptop model sends named commands only after bench tests, with a simulator as fallback.
- 61Ask & understand · Week 31Choose a scoped problem and its users
- 62Build & design · Week 31Write requirements and acceptance tests
- 63Implement · Week 32Build and wire to the specification
- 64Test & improve · Week 32Run the first acceptance tests
- 65Explain & reflect · Week 33Agree the final scope in writing
Smart-room kit, specification template, approved pack
Every requirement linked to at least one acceptance test, reviewed by the trainer.
A physical circuit, sensor or mechanism, built and tested on the bench.
- 66Ask & understand · Week 33Integration risks and test order
- 67Build & design · Week 34Integrate one subsystem at a time
- 68Implement · Week 34Commit every change with a clear message
- 69Test & improve · Week 35Run the full acceptance suite twice
- 70Explain & reflect · Week 35Report what passed, failed and was fixed
Capstone build, test log, Git
The full acceptance suite run twice; a repeat run catches regressions.
A physical circuit, sensor or mechanism, built and tested on the bench.
- 71Ask & understand · Week 36What an independent audit checks
- 72Build & design · Week 36Write the model card
- 73Implement · Week 37Package the configuration for reproduction
- 74Test & improve · Week 37Another team reproduces the result
- 75Explain & reflect · Week 38Respond to the audit findings
Local Python, saved model, configuration and dataset, audit checklist
A second team reproduces the headline result from the saved configuration alone.
A model, an evaluation study or an AI-checking workflow.
- 76Ask & understand · Week 38Plan the defence and its evidence
- 77Build & design · Week 39Assemble the safety case
- 78Implement · Week 39Freeze a tagged release for review
- 79Test & improve · Week 40Run the live test plan before reviewers
- 80Explain & reflect · Week 40Defend decisions, limits and next steps
Integrated capstone build, local model, manual override, evidence pack
Acceptance suite, stale and unknown input, power loss and manual override, run live before reviewers.
A laptop model sends named commands only after bench tests, with a simulator as fallback.
Class 12 adds one more layer of judgement.
Relay switching, fail-safe states and power budgets
Sound features, robustness and drift
Versioned Python and Arduino with tests
A versioned system specification with acceptance tests.
Threat-model a workflow: data flows, permissions and misuse.
A safety case with an independent review record.
For school leadersBring Class 12
to your school.
Start with the four Discovery projects for Class 12 (20 sessions), review the evidence together, then extend to Builder or Innovation.
- Prospectus and class-wise plan
- Kit and readiness check
- Pilot one class first
- Evidence at every milestone
Let's plan your pilot.
Share a few details and we will send the right plan for your classes.