Arduino Learning Studiorobotics pathway

R12-U4 · usually age 12 · Robotics Engineers

Solve a Local Problem

What useful system can we design?

Pilot unit plan · 5 sessions · not yet classroom-validated

Build: Sensor-controlled smart system

A design-cycle project: learners choose a real, local problem, write criteria, design and build a sensor-controlled system from parts they already know, test it against the criteria, improve it, and demonstrate an original variation they can explain.

  • Sense
  • Decide
  • Act
  • Test and debug

Who it is for

Age is a starting point, never a limit. A learner who can show what this unit starts from can begin here at any age.

How they learn
By reading and changing real Arduino sketches, predicting, testing in a model, then building and testing the real circuit.
The adult's role
An adult checks every circuit and anything that moves before it is powered.
Session
75–90 minutes
Hardware
Arduino Uno R3 or compatible (5 V). The adult checks the power circuit and the motor driver. Motors never run from a pin; share GND between supplies.

Starts from

Builds, and what it is the input for

In the studio today

The labs run a model of each sketch in the browser. They prepare the real build; they never count as a working circuit.

Sessions

  1. Session 1 · 75 min

    What problem here is worth solving?

    A problem statement; who the system would help or harm; criteria you can measure and constraints you must keep.

    In the studio

    No studio lab: this session is off-screen.

    Hands-on

    Walk the room or the school and list small problems the kit's sensors could help with (a dark step, a door left open, a bag left where people walk). Pick one. Write who it helps, who it could annoy or harm, and how. Turn the goal into at least three measurable criteria and two constraints: the H2 kit only, low voltage, indoors, and nothing that records people.

    Evidence to collect

    A problem statement, three measurable criteria, two constraints and a help-or-harm note.

    Predict
    Before choosing, predict which problem a sensor from the kit can really detect, and how you would know.
    Debug
    Test each criterion: could two people measure it and get the same answer? Rewrite any that fail.
    Reflect
    Who did you not think of at first, and how does that change your constraints?

    Works towards: Original design

  2. Session 2 · 90 min

    Which design meets the criteria?

    Two concepts compared against the criteria; a sense → decide → act block diagram; a pin plan and a power plan; a test plan written before building.

    Hands-on

    Sketch two different designs and score them against your criteria in a decision table. For the chosen one, draw the block diagram, list every pin and what it connects to (one part per pin), and say where the power comes from. Try your threshold idea in Read a sensor and Make a sound first. Write a test plan with at least three input cases, including a missing or noisy reading.

    Evidence to collect

    The decision table, block diagram, pin and power plan (checked by the adult) and the test plan.

    Predict
    Predict which design will score best before you fill in the decision table.
    Debug
    Check the pin plan against R12-U3: no pin used twice, PWM only on ~ pins, no PWM on 9 and 10 with a servo.
    Reflect
    What did you give up by choosing this design?

    Works towards: Original design

  3. Session 3 · 90 min

    Does the first prototype work?

    Build version 1 from the plan; check before power; first tests against the test plan.

    In the studio

    No studio lab: this session is off-screen.

    Hands-on

    With all power unplugged, build version 1 on the breadboard, following your pin plan. Run your pre-power checklist from R12-U1. After the adult check, upload and run each case in your test plan once. Write down what happened, especially anything surprising.

    Starting code: The learner's own sketch, built from the lab sketches and Arduino examples used in R12-U3 and named in the design.

    Evidence to collect

    An annotated photo or drawing of the circuit (the build only, no people), the sketch, and a first test log with at least one failure or surprise noted.

    Predict
    Before the first run, predict which test case is most likely to fail.
    Debug
    Run the R12-U1 checklist as a planted-fault hunt on a partner's build, with all power unplugged, before anyone powers on.
    Reflect
    Which surprise taught you the most, and what will you change first?

    ⚠ Adult checks before power-on: The wiring matches the checked pin and power plan; with all power unplugged (USB and battery), before the board's 5V and GND jumpers go in, continuity between the 5V and GND rails does not beep; every LED has its resistor; a servo has its own 4×AA NiMH supply with GND shared. No DC motor in this unit: motors need a driver (R13-U1).

    Works towards: Original design

  4. Session 4 · 90 min

    What fails, and why?

    Repeatable trials; isolating one fault in code, wiring or the sensor; one change at a time; re-testing.

    Hands-on

    In Build a project, look at how repeatable trials and a debug record work. Then run each of your test cases five times, the same way each time. Pick the worst failure, find its cause by checking one thing at a time (power off before touching a wire), make one change, upload, and run the same trials again.

    Starting code: The learner's version 1 sketch from session 3.

    Evidence to collect

    A before/after trial table and one debug record: symptom, cause found, change made, result of the re-test.

    Predict
    Predict how many of five trials each case will pass before you run them.
    Debug
    Write the symptom first, then check code, wiring and the sensor one at a time, with the power off for any wire.
    Reflect
    Was your fix the cause, or did it only hide the symptom? How do you know?

    ⚠ Adult checks before power-on: Power off before anyone touches a wire; deliberate faults only in the code or a sensor's signal wire, never in the power path; re-check the circuit after each repair.

    Works towards: Original design

  5. Session 5 · 75 min

    Does our variation solve the problem?

    Demonstrate and explain: what is original, how well each criterion is met (with the trial data), what the system cannot do, and what to try next.

    In the studio

    No studio lab: this session is off-screen.

    Hands-on

    Demonstrate the system to the group with the adult present. Explain what you changed from the examples you started from and why, show your criteria table with measured results, and state one honest limit. Listen to one question from someone the system is meant to help, and note an improvement.

    Evidence to collect

    The unit's evidence: a working demonstration of the original variation, with the learner's explanation, the criteria table, the trial data and one stated limit.

    Predict
    Predict the question your audience will ask first, and prepare the data to answer it.
    Debug
    If the demonstration fails, say so, show the trial data, and name the first thing you would check.
    Reflect
    What would you keep, change or drop in version 3, and why?

    ⚠ Adult checks before power-on: The circuit is re-checked after the final changes, before the demonstration.

    Works towards: Original design

Materials

  • Per group: Arduino Uno R3 (or compatible), its USB cable, a computer with the Arduino IDE, breadboard and jumper wires
  • The parts from R12-U1 to R12-U3: LEDs and resistors, button, potentiometer, LDR, HC-SR04, passive piezo, micro servo with a 4×AA NiMH holder (4.8 V) with an on/off switch
  • Cardboard, tape and a ruler for the enclosure and the test set-up
  • A digital multimeter

⚠ Safety before any session

  • Only parts and circuits from R12-U1 to R12-U3; anything new is checked by the adult first.
  • No DC motors, mains, heaters, Li-ion, LiPo or RC packs, or loose lithium cells.
  • No cameras or microphones that record people, and no names or photos of people in the evidence.
  • Power off before changing a wire; the adult checks every version before it is powered.
  • If anything gets warm: switch off or unplug at the holder, don't touch it, tell the adult.
Safety for every band
  • Low voltage only: battery packs or USB. Never mains electricity.
  • Never connect a motor straight to a controller pin: use a driver and a separate supply.
  • Every moving robot has a power-off switch within reach that cuts the motor battery (or all power). A software stop button is extra, never a replacement.
  • No coin or button cells and no loose small magnets; battery compartments screwed shut.
  • Guard wheels and moving parts against pinched fingers; keep robots slow and indoors.
  • No exposed lithium cells, improvised chargers or lasers.
  • No Li-ion, LiPo or RC packs: AA alkaline or NiMH cells in a closed holder with a switch, or USB.
  • Check polarity and voltage before power-on; a 3.3 V board must not receive 5 V signals.

Notes for the adult

  • Before the first upload, test an upload on each computer (Blink, with its own board and cable), so the session starts on time.
  • Keep problems small and local: one sensor and one or two outputs are enough for an original variation.
  • Original means changed on purpose for this problem and explained, not invented from nothing.
  • Judge against the learner's own criteria and trial data, not against other groups: there are no scores.
  • A simulation run in a lab is preparation; only the real build's trials are evidence.

Planned studio features

Not built yet. The unit runs without them.

  • A design-cycle notebook page (problem, criteria, decision table, trials, debug records) kept in the browser only, with no names or photos.

Sources

The facts this plan relies on, in each source's own words.

  • Arduino: Digital Pins (pins configured as OUTPUT)
    “ATmega pins can source (provide positive current) or sink (provide negative current) up to 40 mA (milliamps) of current to other devices/circuits. This is enough current to brightly light up an LED (don't forget the series resistor), or run many sensors, for example, but not enough current to run most relays, solenoids, or motors.”
  • Arduino language reference: analogRead()
    “This means that it will map input voltages between 0 and the operating voltage(5V or 3.3V) into integer values between 0 and 1023. On an Arduino UNO, for example, this yields a resolution between readings of: 5 volts / 1024 units or, 0.0049 volts (4.9 mV) per unit.”
  • Arduino language reference: analogWrite()
    “UNO (R3 and earlier), Nano, Mini | 3, 5, 6, 9, 10, 11 | 490 Hz (pins 5 and 6: 980 Hz) … value: the duty cycle: between 0 (always off) and 255 (always on).”
  • Arduino language reference: pulseIn()
    “Returns the length of the pulse in microseconds or gives up and returns 0 if no complete pulse was received within the timeout.”
  • Arduino language reference: tone()
    “Use of the tone() function will interfere with PWM output on pins 3 and 11 (on boards other than the Mega). It is not possible to generate tones lower than 31Hz.”
  • Arduino Servo library (pins 9 and 10)
    “On boards other than the Mega, use of the library disables analogWrite() (PWM) functionality on pins 9 and 10, whether or not there is a Servo on those pins.”
  • Arduino: Servo Motors (powering servo motors)
    “This high current-draw is generally not safe to draw from an Arduino board. To avoid damaging our board we need to power the servo motor through an external power supply.”
  • Arduino: Multimeter Basics (continuity testing)
    “This feature allows you to know if a material is or is not conductive.”