Check your starting point
- I can trace an if/else rule.
- I can explain a repeated loop and a stored state.
- I can distinguish a classroom simulation from a real safety system.
If one item feels unfamiliar, revisit these foundation missions:
FROM A READING TO A RELIABLE RESPONSE
Robotics & physical computing
Model inputs, outputs and state; test missing data and design a simulated controller with a clear handover.
Make a first version.
state = OFF
for each reading:
if reading is missing:
display UNKNOWN
else:
if reading >= 80: state = ON
else if reading <= 75: state = OFF
display state
Test: 74,79,80,78,76,75,74
Expected: OFF,OFF,ON,ON,ON,OFF,OFFCopy this into your chosen tool or trace it on paper. Do not enter passwords, private learner data or API keys.
Separate input, processing and output
A sensor supplies a measurement; a rule interprets it; an output communicates or acts. Units and sensor position affect meaning. A distance-to-surface reading is not automatically the same as water height.
Build & try
Draw a tank model with a labelled height input in cm and an on-screen alarm output. State what your model assumes. Use paper or the free MakeCode simulator.
Show that it works
Your diagram identifies units, the measurement reference and the output without confusing them.
Trace a threshold and a loop
A condition selects what to do for one reading. A loop repeats that decision. Real sensors fluctuate, so a single threshold can switch rapidly near the boundary.
Build & try
Trace 79,80,79,80 using the rule on at ≥80. Write the four outputs. Then use the sensor lab to compare with a two-threshold rule.
Show that it works
You can predict every output and explain the flicker without calling the code random.
Use state deliberately
State stores information from earlier steps. Hysteresis uses different turn-on and turn-off thresholds. Between them, the previous state determines the output.
Build & try
Implement the starter pseudocode as blocks, code or a paper trace. Draw OFF→ON at ≥80 and ON→OFF at ≤75. Explain what happens at 78 after each starting state.
Show that it works
Your seven-reading trace matches the expected sequence. You can explain why 78 alone does not determine the result.
Expose faults
Missing data is not evidence that a condition is safe. Startup, disconnected input and impossible readings need explicit behaviour. A classroom model cannot decide a safe action for real equipment.
Build & try
Insert ?, a negative value and a restart into your tests. Display unknown for missing data; reject impossible negative height. Document the chosen initial state and limits.
Show that it works
Your test log distinguishes valid low readings, absent readings and invalid readings. You make no real-world safety claim.
Repeat trials and keep versions
A single screenshot proves little about behaviour across time. Repeatable sequences and expected results allow comparison after a change.
Build & try
Run normal, boundary and fault sequences. Change one threshold, predict the effect and retest. Record the configuration with each trace so results can be reproduced.
Show that it works
Your log shows at least one unsuccessful prediction and what you learned, alongside passing tests.
Build a second state machine
The same pattern transfers to a simulated rover: stopped, moving and obstacle detected. The meanings of the states and transitions should be explicit before code.
Build & try
Create a paper or browser simulation of a rover that stops at a fictional obstacle threshold and displays unknown for missing input. Provide setup, state diagram, tests and limitations. Physical wiring requires a qualified supervisor and suitable equipment.
Show that it works
Another learner can run your simulation and predict transitions. No hardware purchase is required to complete this project.
Make the idea your own.
Choose a twist. Use paper, a sketch or a conversation.
Optional practice. Copy useful observations into your workbook; choosing a twist does not record completion.
Compare ideas with someone you know. Sharing is optional.