Design a monitor that warns when a pot plant needs water: a soil moisture sensor, an alarm, and a display of the reading, tested at its threshold.
The garden club loses plants every holiday. Can a microcontroller tell them which pot is dry before it is too late?
Client: the school garden club. Context: pot plants in a classroom, checked twice a week.
Brief: a soil moisture sensor on A0 reads low when the soil is dry. The monitor must blink an LED when the reading is 300 or below, stay off otherwise, and show the reading (LCD or serial monitor). It must use only parts from the kit (or Tinkercad's parts), run on 4 × AA or USB, and fit in a box no bigger than a pencil case.
Inquire: Read the brief: who it is for, what it must do (criteria) and the limits (constraints).
Develop: Plan before you build: parts, circuit, code and the tests you will run.
Create: Build it, first in the simulator, then for real if you have the kit. Expect a few tries; that is normal.
Test: Run your tests and record what happened, including what failed.
Evaluate: Judge it against each criterion, and say what you would change.
Make your prediction first. Help opens once you've locked it in.
InquireRead the brief: who it is for, what it must do (criteria) and the limits (constraints).
Inquire: the brief
Sort each line of the brief: a criterion (what it must do, which you can test) or a constraint (a limit you must work within)?
Blinks the LED at a reading of 300 or below
Stays off above 300
Shows the current reading
Only parts from the kit
Runs on 4 × AA or USB
Fits in a pencil-case-sized box
DevelopPlan before you build: parts, circuit, code and the tests you will run.
Develop: plan before you build
Try it yourselfYour edits are saved in this browser.
Prototype the decision: write the sketch so all five tests pass.
Use the board. This ticks when you get there.
CreateBuild it, first in the simulator, then for real if you have the kit. Expect a few tries; that is normal.
Create: build it
TestRun your tests and record what happened, including what failed.
Test: run your table
EvaluateJudge it against each criterion, and say what you would change.
Evaluate: against the brief
For teachers
A Years 8–9 design project: a plant monitor with a soil sensor, an alarm at a threshold and a display, planned with a test table, prototyped on the board, built in Tinkercad and optionally on hardware, tested and evaluated against the brief. About 180 minutes.
I can evaluate my design against each criterion with evidence.
Before class
Builds on Arduino › A small system (the same alarm logic and boundary tests). Real soil sensors read differently in different soils: calibrate the threshold with real dry and wet soil, and say so in the evaluation. Resistive soil probes corrode if powered all the time; powering the sensor from a pin only while reading is a good extension.
If you assess with MYP Design, the steps line up with the criteria:
A Inquiring and analysing: the brief, its criteria and constraints, and research into parts (Inquire).
B Developing ideas: a design specification, the circuit and code plan, and the test table written before building (Develop).
C Creating the solution: building it (in the simulator, then for real), following the plan and justifying changes (Create).
D Evaluating: testing against the specification, recording failures, improvements and impact (Test, Evaluate).
Otherwise, use the same four headings as a simple rubric: each step's reflect checks are the evidence list.
Running the lesson
Inquire: ask which criterion will be hardest to test.
Develop: no wiring until the test table is written.
Evaluate: insist on a test result for every criterion.
The hard part (on purpose)
Students build first and plan never. Hold the test table as the ticket to start building.
When students get stuck
The alarm triggers at the wrong time. Ask: What does the sensor read in dry soil, and in wet? Fix: Print the readings and recalibrate the threshold.
Stretch and support
Stretch: Add a second threshold (very dry: steady on) or a buzzer, and stop the alarm flickering near 300.
Support: A partly filled test table and the A small system sketch as a starting point.
Where it leads
Other Years 8–9 projects: Parking assistant, Reaction game.
Inquire: the brief: Separating what the design must do (criteria) from the limits it works within (constraints) is the first move of any design brief.
Develop: plan before you build: Writing the test table and prototyping the decision on the board before wiring anything turns the criteria into something checkable.
Create: build it: Building in the simulator first catches wiring and code slips cheaply; the real build then tests the design against the world.
Test: run your table: Running the test table written in Develop, and recording every result including failures, is the evidence for the evaluation.
Evaluate: against the brief: Judging the design criterion by criterion, with evidence from the tests, is what separates an evaluation from a description.
Now you can
Turn a brief into criteria and constraints.
Plan and run tests that check a threshold.
Evaluate my design against each criterion with evidence.