Arduino Learning Studiorobotics pathway

R13-U3 · usually age 13 · Robotics Engineers

Autonomous Behaviour

How can a robot decide its next move?

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

Build: Stop-turn-continue behaviour controller

A behaviour controller for the rover: states (drive, brake, turn, stopped) and the transitions between them, timers with millis() so loop() never waits, a STOP button checked first on every pass, and the motor battery's power-off switch as the stop that always works. It ends with the rover passing varied obstacle placements without a collision.

  • Decide
  • 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

After R13-U1 to U3, start the Arduino Rescue Rover course at session 10; sessions 5–9 become a quick review. Open the course →

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 is the rover doing right now?

    Behaviour as states: DRIVE, BRAKE, TURN and STOPPED; a transition is a condition that moves the rover from one state to the next (a close reading, a timer, the STOP button). A state diagram.

    In the studio

    Hands-on

    In Sense, decide, act, watch the state diagram while the model rover meets a box: which arrow lights, and when? Then draw your own diagram on paper for a stop-turn-continue rover: every state, what the motors do in it, and every arrow labelled with its condition. Act it out in pairs: one learner is the sensor and the button, the other the rover, following only the diagram.

    Evidence to collect

    The learner's state diagram (states, motor command in each, every transition labelled) and one case where acting it out showed a missing arrow.

    Predict
    Which arrow lights first when the model rover meets the box?
    Debug
    When acting it out gets stuck, find the missing or unlabelled arrow.
    Reflect
    Which state is the hardest to leave, and why?

    Works towards: States

  2. Session 2 · 90 min

    Why can't the rover just wait?

    A short review of R12-U2's delay() vs millis(), now on the rover: delay() stops loop(), so nothing is read, but the motors keep the last command (the driver's pins hold their states). Timers with millis(): note when a state started and move on when now − start ≥ its time.

    In the studio

    Hands-on

    In Sense, decide, act, predict how far the model rover goes after STOP with the delay(500) pacing, then test it. On the rover, with everything unpowered, add the STOP button across the breadboard's gap: D2 to one leg, GND to the diagonally opposite leg (INPUT_PULLUP, no resistor). Upload the lab's sketch with the pacing set to delay(500), lift the rover, wheels in the air, and switch the motor battery on. Tap STOP once and note whether the wheels braked at once. The lab's sketch then stays STOPPED until RESET, so press the board's RESET button before each of ten taps. Then set the pacing to millis() and repeat.

    Starting code: Sense, decide, act's sketch (Copy code in the lab's code panel), with its pacing set to delay(500), then to millis().

    Pins

    D2
    STOP button (other side to GND)

    Evidence to collect

    A before/after table (taps caught at once out of ten, with delay() and with millis()) and a sentence on what the motors did during the delay.

    Predict
    How many of ten taps will each version catch at once?
    Debug
    If STOP never works, print digitalRead(2) to check the button before blaming the sketch.
    Reflect
    What were the motors doing while the sketch waited?

    ⚠ Adult checks before power-on: The motor battery reaches the driver's VM only, through its power-off switch; the board's 5V goes to the driver's VCC only; every GND is joined. The STOP button goes between D2 and GND, never across 5V and GND, and nothing else uses D2; lifted, wheels in the air, for every test in this session. Lift the rover (wheels in the air) before switching the motor battery back on: the sketch keeps running on USB, so the wheels take its last command at once. No wire is moved, pulled or plugged in while anything is powered: power-off switch off and battery unplugged first, then USB.

    Works towards: States

  3. Session 3 · 90 min

    How does the sketch remember what it is doing?

    A state variable and switch...case: one case per state, each ending with break; a timer per timed state; STOP checked first, before the switch, on every pass; TURN with a way out.

    In the studio

    Hands-on

    In Sense, decide, act, find the faults where STOP is checked only in one case and where TURN has no way out. Then start from your R13-U2 session 4 sketch and write the controller from your diagram, using R13-U1's motor functions: DRIVE → BRAKE on a close reading, BRAKE → TURN after its time, TURN → DRIVE after its time, any state → STOPPED when D2 reads LOW. Compare with the lab's sketch only after your own test. Upload, lift the rover, wheels in the air, hold a box in front and test each transition; press STOP in every state (RESET to leave STOPPED).

    Starting code: The learner's own sketch from R13-U2 session 4, with R13-U1's motor functions.

    Pins

    D2
    STOP button (other side to GND)

    Evidence to collect

    The sketch beside the diagram, with each case matched to its state, and a transition test table: state, input, the state that followed, and STOP pressed in every state.

    Predict
    From your diagram, predict which state follows each input before you test it.
    Debug
    Print the state's name on every transition to find one that never happens.
    Reflect
    Does every arrow in your diagram have a line in the sketch?

    ⚠ Adult checks before power-on: The motor battery reaches the driver's VM only, through its power-off switch; the board's 5V goes to the driver's VCC only; every GND is joined. Lifted, wheels in the air, for every test in this session; the power-off switch in reach. Lift the rover (wheels in the air) before switching the motor battery back on: the sketch keeps running on USB, so the wheels take its last command at once.

    Works towards: States

  4. Session 4 · 75 min

    What if the software stop does not work?

    The STOP button is a software stop: it works only while the sketch runs and reads D2. The power-off switch on the motor battery cuts the motors whatever the sketch does: it is the stop that always works. Both are tested before every run.

    In the studio

    Hands-on

    In Sense, decide, act, read the Explain step on STOP and the power-off switch. On the rover, lifted with its wheels in the air, make the software stop fail on purpose: start from your session 3 sketch, put a delay(5000) in case TURN and upload. Press RESET, hold a box in front so the rover brakes and turns, then press and hold STOP during the turn: nothing happens until the delay ends. Press RESET again and hold the box in front; during the turn, switch the power-off switch off: the wheels stop at once. Take the delay out and upload again. Then write a two-stops check to run before every floor run: STOP brakes the wheels in every state; the power-off switch stops them at once; and the rover is lifted, wheels in the air, before the motor battery is switched back on. Run it. Finish with the first floor runs: one box straight ahead, on the floor at the lowest value that starts both wheels, never above 160 of 255.

    Starting code: The learner's session 3 sketch, with a deliberate delay(5000) added in case TURN and then taken out.

    Pins

    D2
    STOP button (other side to GND)

    Evidence to collect

    A two-stops record: STOP in each state (worked or not), STOP during the deliberate long wait (did not work), the power-off switch (worked), the written two-stops check, and notes on the first floor runs.

    Predict
    What will STOP and the power-off switch each do during the long wait?
    Debug
    If the power-off switch does not stop the wheels at once, stop there and show the adult the wiring.
    Reflect
    Why must the safety stop not depend on the sketch?

    ⚠ Adult checks before power-on: The motor battery reaches the driver's VM only, through its power-off switch; the board's 5V goes to the driver's VCC only; every GND is joined. Lifted while the deliberate wait is in the sketch; it is taken out before any floor run; the two-stops check passes before the rover goes on the floor; then on the floor at the lowest value that starts both wheels, never above 160 of 255. Lift the rover (wheels in the air) before switching the motor battery back on: the sketch keeps running on USB, so the wheels take its last command at once.

    Works towards: States

  5. Session 5 · 90 min

    Can it find its way past obstacles placed in different ways?

    Varied placements: two distances, a box at an angle and a box off to the side; no collision in any of them. When one fails, finding which state or transition went wrong by checking one thing at a time, with a Serial print on each transition.

    In the studio

    No studio lab: this session is off-screen.

    Hands-on

    Start from your session 4 sketch, with the state's name printed on every transition (USB tether, held by the adult; open the Serial Monitor before the motor battery goes on). Run the two-stops check. Place a box at two distances, then at an angle, then off to the side: one trial each, noting every collision or near miss. For a failure, read the printed transitions, find the state or transition that went wrong, change one thing, and run that placement again. Finish with one run of each placement.

    Starting code: The learner's session 4 sketch, with a Serial.println() of the state's name on every transition.

    Evidence to collect

    The unit's evidence: the rover passes varied obstacle placements without a collision. A placement table (placement, what the rover did, the transitions printed, collision or not) ending with every placement passed, and the one change that fixed a failure.

    Predict
    Which placement will be hardest, and why?
    Debug
    Use the printed transitions to find where a failing run went wrong.
    Reflect
    What can your controller still not handle?

    ⚠ Adult checks before power-on: The motor battery reaches the driver's VM only, through its power-off switch; the board's 5V goes to the driver's VCC only; every GND is joined. The two-stops check passes first; on the floor at the lowest value that starts both wheels, never above 160 of 255; soft boxes; the course clear of people's feet. Lift the rover (wheels in the air) before switching the motor battery back on: the sketch keeps running on USB, so the wheels take its last command at once.

    Works towards: States

Materials

  • The rover from R13-U2 (Uno, TB6612FNG, two gear motors, HC-SR04; motor battery: 4 × AA alkaline cells (1.5 V each, about 6 V fresh) in a holder whose on/off switch is the power-off switch)
  • A 4-leg push button for STOP (on D2), mounted where the operator can reach it
  • Cardboard boxes, masking tape and a tape measure
  • A computer with the Arduino IDE and a long USB cable; shared: a 6 × AA (alkaline or NiMH) holder with an on/off switch and a 2.1 mm centre-positive barrel plug for the board, for untethered runs

⚠ Safety before any session

  • The power-off switch on the motor battery is the stop that always works; test it, and the STOP button, before every run.
  • Switch off and disconnect the motor battery before changing any wire, then unplug USB; connect the battery last.
  • Motors run from their own battery through the driver, never from a pin; every GND is joined.
  • Wheels lifted for every new sketch; then on the floor at the lowest value that starts both wheels, never above 160 of 255, soft boxes and no one's feet in the way.
  • Lift the rover (wheels in the air) before switching the motor battery back on: the sketch keeps running on USB, so the wheels take its last command at once.
  • Motor battery: AA alkaline cells only; no NiMH, Li-ion, LiPo, RC packs or 18650 cells.
  • 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

  • Leads into the Rescue Rover course (R13-U4): this unit is course session 9 in depth, with the same states and the same two stops. The course's new work starts at session 10, the Debug Dojo; the five-placement protocol with one change and the failure analysis (sessions 11 and 12) are the course's, not this unit's.
  • Session 2 is a short review of R12-U2's delay() vs millis() experiment, on the rover: keep it to the ten taps and what the motors did.
  • Ask for the diagram before the code, and check that every arrow in the diagram has a line in the sketch.
  • Each session lists a line to predict before power-on, a first check when it goes wrong, and a question to reflect on before tidying up.
  • Before the first upload, test an upload on each computer (Blink, with its own board and cable), so the session starts on time.
  • A software STOP that has passed every test is still not the safety stop: the power-off switch is.
  • The lab's model rover turns only left and sees one box; the real placements here are the evidence.

Planned studio features

Not built yet. The unit runs without them.

  • A state-diagram editor: learners draw their own states and transitions and compare them with their sketch's cases.
  • Varied placements in Sense, decide, act: a box at an angle, two boxes, a wall, and turns either way.
  • Notebook pages for unit plans (today the notebook holds only the Rescue Rover course).

Sources

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