Arduino Learning Studiorobotics pathway

Ages 12–14 (or beginners 15+) · 12 sessions

Arduino Rescue Rover

Pilot · not yet classroom-validated

Twelve sessions from a first blinking LED to a slow indoor rover that senses obstacles, decides what to do, can be stopped at once, and is tested properly.

Coming from the unit plans: After R13-U1 to U3, start the Arduino Rescue Rover course at session 10; sessions 5–9 become a quick review.

By the end, a learner can

  • Tell a power path from a signal path, and explain why a motor needs a driver.
  • Explain the sense → decide → act cycle of a robot.
  • Change an Arduino program that reads inputs and drives outputs.
  • Build a rover with two motors driven through a suitable driver.
  • Plan and run repeatable trials, isolate a fault, and justify a change with test results.

⚠ Before any session

  • One kit per 2–3 learners; an adult checks every circuit before power-on.
  • Motors run from their own battery pack through a motor driver, never from a pin.
  • A power-off switch the learner can reach that cuts the motor battery; the software stop button is extra, never a replacement. Slow speed; indoors only.
  • No mains power, loose lithium cells, sharp payloads or unsupervised powered tests.
  • Simulation shows behaviour, not proof: physical evidence is recorded separately and checked by an adult.

How progress is recorded

In the studio (simulation)
Read from the labs automatically. It shows behaviour; it is not proof that a real circuit works.
Done for real
Ticked by the supervising adult after checking the real build. The app trusts the tick; it cannot check who made it. Kept only in this browser: no names, no photos, no account.

Done for real: 0/12 sessions · Trials logged: 0

Sessions

  1. Session 1

    Who needs a rescue rover?

    A safe indoor mission: obstacles, people's safety and what success means.

    In the studio

    No studio lab: this session is off-screen.

    Build for real

    Draw the course and a chassis idea; agree a stop rule.

    Evidence

    A problem statement, constraints and three test cases.

  2. Session 2

    How can a controller act?

    Inputs and outputs; setup() and loop().

    In the studio

    Build for real

    Wire an LED with its resistor and make the blink configurable.

    Evidence

    An annotated circuit and modified code.

    ⚠ Adult checks before power-on: Resistor in series with the LED; USB unplugged while wiring.

  3. Session 3

    How do we take a command?

    A button as the operator's command and stop request.

    In the studio

    Build for real

    A button-controlled LED, then a latching stop button.

    Evidence

    An input state table and a stop demonstration.

    ⚠ Adult checks before power-on: Button between the pin and GND, never straight across 5V and GND.

  4. Session 4

    Can the computer understand a measurement?

    Analog and digital readings; thresholds.

    In the studio

    Build for real

    Collect readings and explain a threshold.

    Evidence

    A measurement table with units.

    ⚠ Adult checks before power-on: USB unplugged while wiring; the potentiometer's outer legs only to 5V and GND; the light sensor has its fixed resistor to GND.

  5. Session 5

    How far is the obstacle?

    Measuring distance; noise; what a model leaves out.

    In the studio

    Build for real

    The sensor detects objects at several distances.

    Evidence

    At least five ruler-versus-sensor comparisons.

    ⚠ Adult checks before power-on: Sensor VCC to 5V and GND to GND, not reversed, before USB goes in.

  6. Session 6

    How can the robot warn us?

    Lights, a buzzer and conditions.

    In the studio

    Build for real

    An audible and visible obstacle warning.

    Evidence

    Three threshold tests, described.

    ⚠ Adult checks before power-on: Each LED has its resistor; the buzzer is a passive piezo on the pin. A magnetic buzzer needs a transistor driver and a flyback diode, never a pin.

  7. Session 7

    What makes a wheel move safely?

    The motor driver: power vs signal, and speed. Direction comes in session 8.

    In the studio

    Build for real

    An adult-checked circuit drives one motor and stops it.

    Evidence

    A correct power-path sketch and safe operation.

    ⚠ Adult checks before power-on: Motor on its own battery through the driver, never from a pin; grounds joined; battery voltage within the motor's and driver's ratings; a flyback diode across the motor if the driver is a single transistor; wheels lifted off the table for the first power-on.

  8. Session 8

    Can two wheels steer?

    Two-wheel speed combinations: forward, reverse, turn, stop.

    In the studio

    Build for real

    Assemble the chassis; drive forward, reverse, turn and stop.

    Evidence

    Motion commands and labelled troubleshooting.

    ⚠ Adult checks before power-on: Wheels guarded, low speed; the power-off switch cuts the motor battery: tested before driving.

  9. Session 9

    How should a robot behave?

    Sense → decide → act without blocking: states and millis().

    In the studio

    Build for real

    The first integrated rover with a cautious stop-and-turn.

    Evidence

    A state diagram and a baseline trial.

    ⚠ Adult checks before power-on: Before any trial, test both: the software stop button stops the motors, and the power-off switch cuts the motor battery.

  10. Session 10

    Can we find the fault?

    A deliberate mismatch between sensor, wiring, code and motor direction.

    In the studio

    Build for real

    Identify, reproduce, isolate and repair one fault.

    Evidence

    A debug record with observed data.

    ⚠ Adult checks before power-on: Deliberate faults go in the code or sensor wiring only, never in the power path (no reversed battery, no motor on a pin). Power off before touching any wire; re-check after each repair.

  11. Session 11

    What works repeatedly?

    Compare two strategies with a controlled, repeatable test.

    In the studio

    Build for real

    Five indoor course trials; improve one subsystem; five more.

    Evidence

    A before/after table, the failure cases and the chosen fix.

    ⚠ Adult checks before power-on: Course clear of people's feet and anything fragile; the power-off switch (motor battery) tested before the first trial.

    Trial log (real rover)

    Run five trials, make one change, then run five more. Record every trial, not just the good ones.

    Add a trial
    Describe the rover, not people: no names.

  12. Session 12

    Does our rover solve the problem?

    Demonstrate, explain, and say honestly what it can't do.

    In the studio

    Build for real

    The final rescue course demo, with the power switch in use.

    Evidence

    Design sketch, code, test evidence and a reflection.

    ⚠ Adult checks before power-on: The power-off switch (motor battery) tested before the demo.

Capstone

Rescue Rover Mission

A small indoor robot must cross a pretend supply corridor without hitting cardboard obstacles. It must stop when commanded and work over several trials.

Constraints. Low voltage, low speed, indoors; a visible stop switch; no contact with people. Keep the course within the sensor's range and the rover's turning space: measure those, don't guess.

Test protocol. Mark start and goal and measure the route. Use five different but repeatable obstacle placements. Record each trial, make one change, then run the trials again. One good run is not reliability.

Questions to explain

  • What does each sensor measure?
  • How does the program choose the next motor command?
  • Why can't the motors draw current from Arduino pins?
  • Which condition caused a failure?
  • What would make the robot safer if its sensor came loose?