Arduino Learning Studiorobotics pathway

R09-U4 · usually age 9 · Robot Explorers

Smart Crossing

Can a signal system protect a crossing?

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

Build: Programmable pedestrian crossing

A model pedestrian crossing on the micro:bit's display: “don't walk” until someone asks with button A, then “walk”, a flashing “hurry” and “don't walk” again. It is built to choose the safe picture whenever it is unsure, and tested for who it helps and who it could leave out. A model on a table, never a real road device.

  • Decide
  • Power and safety

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 arranging instruction cards or blocks, predicting what happens, and testing on a kit. Short sentences, with words and pictures together.
The adult's role
An adult oversees circuits, batteries and motors.
Session
60–75 minutes
Hardware
micro:bit with MakeCode, or a similar child-friendly board. Start in the board's own simulator. A micro:bit is 3.3 V: never connect a 5 V signal straight to it.

Starts from

Builds, and what it is the input for

In the studio today

No studio lab or activity for this unit yet.

Sessions

  1. Session 1 · 60 min

    What must a crossing do, and for whom?

    Before any code: the crossing's job, its criteria and limits, and the people who use it: people walking slowly, people pushing a buggy or using a wheelchair, people who cannot see the signal, and drivers waiting. The crossing is a model on a table.

    The adult says first: “A crossing keeps people safe. Let's find out who uses it.”

    Learner card

    1. Be the signal, walker or driver.
    2. Show “walk” or “don't walk”.
    3. Who needs more time?
    4. Who cannot see the signal?
    5. Write our rules.

    Key words (show each with a picture): crossing · safe · who

    Timing (0 of 60 min at the screen)

    1. 10 minAway from the screen: Set up the model road on a table; picture cards of who uses a crossing.
    2. 20 minAway from the screen: Role-play: take turns as the signal, the walker and the driver.
    3. 15 minAway from the screen: Write the crossing's criteria and limits together.
    4. 15 minAway from the screen: Fill in the table: who it helps and who it could put at risk.

    In the studio

    No studio lab: this session is off-screen.

    Hands-on

    Nothing is powered. The adult tapes a model road across a table, with toy figures, a toy car and two picture cards: “walk” and “don't walk”. Children take turns as the signal (holding up a card), the walker and the driver. Together they write the crossing's criteria (for example: it shows “don't walk” unless someone asks to cross; “walk” lasts long enough for the slowest walker; the two pictures look different) and its limits (the micro:bit's display, its two buttons, one table). Then the group lists who the crossing helps and who it could put at risk if it goes wrong.

    Evidence to collect

    A prediction of who would find the first plan hardest to use, a short test table (Person | What they need | My guess (hard?) | Our idea) for at least four people, and the group's spoken explanation of who the crossing helps and who it could put at risk.

    Test table columns: Person | What they need | My guess (hard?) | Our idea

    Predict
    Before the role-play, the learner guesses who will find a short “walk” time hardest.
    Debug
    If the role-play goes wrong (a walker is still crossing at “don't walk”), stop and ask which rule was missing.
    Reflect
    Who did we forget at first, and how did we find them?

    Works towards: Help or harm

  2. Session 2 · 75 min

    What should the crossing show when it is unsure?

    A safe default: the picture the crossing shows when it is starting, not asked, or unsure. Here it is “don't walk”. “on start” shows it first; inside “forever”, an “if then else” checks “button A is pressed”: then the walk sequence, else “don't walk”. Anything that is not a clear request lands in else. “show icon” keeps each picture for 600 ms unless told otherwise, so the loop checks the button only between pictures: a quick tap can be missed, so A is held until “walk” shows.

    The adult says first: “When a machine is not sure, it must pick the safe choice.”

    Learner card

    1. Start: show “don't walk”.
    2. Hold A to ask to cross.
    3. Not asked? Show “don't walk”.
    4. Guess each case first.
    5. Safe? Tick ✓ or ✗.

    Key words (show each with a picture): safe · default · unsure

    Timing (30 of 75 min at the screen)

    1. 15 minAway from the screen: Role-play with walk and don't-walk cards: the program checks once per slow count for a raised hand; a quick wave between counts is missed.
    2. 15 minAt the screen: Build “on start” and “forever” with “if then else” in MakeCode.
    3. 10 minAway from the screen: Write a guess for each of the six cases.
    4. 15 minAt the screen: Test the six cases in the simulator.
    5. 10 minAway from the screen: Tick ✓ or ✗ for safe; say why “else” shows “don't walk”.
    6. 10 minAway from the screen: Read the blocks aloud together: what shows when nobody presses?

    In the studio

    No studio lab or activity.

    Outside the studio: MakeCode editor and its micro:bit simulator (makecode.microbit.org)

    Hands-on

    Nothing is powered: this session uses the simulator only. First, away from the screen, the group role-plays the program with walk and don't-walk cards: the learner playing the program checks once per slow count whether a partner's hand is up, and a quick wave between counts is missed. Then the learner builds “on start” holding “show icon” with the “no” icon for “don't walk”, and “forever” holding “if then else” with “button A is pressed” as its condition. “then” holds the walk sequence: “show icon” with the “stick figure” icon and “pause (ms)” 5000, then for “hurry” a “repeat” 3 times holding four blocks: “show icon” (stick figure), “pause (ms)” 300, “clear screen”, “pause (ms)” 300. “else” holds “show icon” with “no”. The learner fills the test table for six cases: just started, nobody pressing, a quick tap on A, A held until “walk” shows, B pressed, and A pressed again during “walk”.

    Starting blocks: Built from scratch: “on start” with “show icon”, and “forever” holding “if then else” with “button A is pressed” as its condition.

    Evidence to collect

    A prediction for each case, a short test table (Case | My guess | What it showed | Safe?) for six cases, and the learner's spoken explanation of why “else” shows “don't walk” and why a quick tap can be missed.

    Test table columns: Case | My guess | What it showed | Safe?

    Predict
    Before each case, the learner says what the crossing will show, and whether that is safe.
    Debug
    If “walk” shows when nobody pressed, check which part holds the walk sequence: “then” or “else”.
    Reflect
    Why is “don't walk” the right picture when the crossing is not sure?

    Works towards: Safe default

  3. Session 3 · 75 min

    Does the real crossing stay safe when things go wrong?

    The real micro:bit, tested on purpose with things going wrong: a button held down, both buttons together, a restart in the middle of “walk” (a short press of the reset button on the back), and the power going off. A dark display tells nobody anything: in this model, dark means do not cross.

    The adult says first: “Now we try to break it, on purpose. A safe crossing stays safe.”

    Learner card

    1. Hold A down.
    2. Press A and B together.
    3. Press reset during “walk”.
    4. What shows first?
    5. Dark means do not cross.

    Key words (show each with a picture): restart · safe · dark

    Timing (10 of 75 min at the screen)

    1. 10 minAway from the screen: Guess what shows first after a restart, and what a dark display means.
    2. 10 minAt the screen: The session 2 program in the simulator, then plug in USB and download.
    3. 35 minAway from the screen: The real tests: nobody, A, A held, A and B, a short press of reset during “walk”, then the pack unplugged once.
    4. 20 minAway from the screen: Fill in the table; talk about what people should do when the signal is dark.

    In the studio

    No studio lab or activity.

    Outside the studio: MakeCode editor and its micro:bit simulator (makecode.microbit.org)

    Hands-on

    In the simulator first, the learner runs the session 2 program once more. Then the learner plugs the micro:bit into USB and downloads it, unplugs USB, and the adult fits the battery pack. The learner tests the cases: nobody pressing; A pressed; A held down; A and B together; and, during “walk”, the adult gives the reset button on the back a short press (a restart). The learner records what the crossing showed first after the restart. Then, once, the adult unplugs the battery pack (a dark display). The group talks about it: what should people do if the signal shows nothing?

    Starting blocks: The learner's session 2 blocks.

    Evidence to collect

    A prediction for each case, a short test table (Case | My guess | What it showed | Safe?) including the restart and the dark display, and the learner's spoken explanation of what the crossing did after the restart and why.

    Test table columns: Case | My guess | What it showed | Safe?

    Predict
    Before the restart, the learner says what the crossing will show first when it comes back on.
    Debug
    If “walk” shows after the restart without a press, check what “on start” shows and what “else” holds.
    Reflect
    What can our model not make safe on its own?

    ⚠ Adult checks before power-on: Nothing metal touches the micro:bit or its gold pins along the bottom edge (no coins, keys, foil, metal clips or jewellery): metal across the pins can short the power. Hands holding the board are fine. The learner plugs in the USB cable, gripping the plug, while the adult watches; only the adult fits or unplugs the battery pack. To restart, give the reset button on the back a short press. Do not hold it: on a micro:bit V2, holding it puts the board into power-saving mode, another dark display (hold it again to wake it). The adult unplugs the battery pack only once, for the dark display, by its connector, never by the wires.

    Works towards: Safe default

  4. Session 4 · 75 min

    Who does our crossing help, and who could it leave out?

    Help or harm, tested: is “walk” long enough for the slowest walker? Can the two signals be told apart by shape? Every LED on the display is the same red, so colour cannot tell them apart. Who cannot see the display at all, and what could help them? One change, tested.

    The adult says first: “A fair crossing works for everyone. Let's test who it helps.”

    Learner card

    1. Time the slowest walk.
    2. Is “walk” long enough?
    3. Change the pause. Test again.
    4. Can you tell the pictures apart?
    5. Who cannot see it?

    Key words (show each with a picture): fair · time · shape

    Timing (15 of 75 min at the screen)

    1. 15 minAway from the screen: Time the slowest walk across a strip on the classroom floor.
    2. 15 minAt the screen: Find the walk time in the blocks (600 ms + 5000 ms); change “pause (ms)”; the simulator, then download.
    3. 20 minAway from the screen: The real board: time “walk” against the slow walk; the two-metre picture test.
    4. 15 minAway from the screen: One idea for people who cannot see the display.
    5. 10 minAway from the screen: Fill in the table; say who the change helps.

    In the studio

    No studio lab or activity.

    Outside the studio: MakeCode editor and its micro:bit simulator (makecode.microbit.org)

    Hands-on

    First, away from the screen, the adult marks a strip about three big steps wide on a clear classroom floor (not a road) and times one learner walking it very slowly, in seconds. In the simulator next, the learner finds the walk time in the program: “show icon” keeps the stick figure 600 ms, then “pause (ms)” 5000 is 5 seconds, so “walk” lasts 5.6 seconds. The learner compares that with the slow walk and changes the “pause (ms)” value so “walk” lasts longer than the slowest crossing, then downloads it to the real micro:bit; the adult fits the battery pack. A learner two metres away says which picture is showing, without being told. The group writes one idea for people who cannot see the display.

    Starting blocks: The learner's session 3 blocks.

    Evidence to collect

    A prediction for each test, a short test table (Test | My guess | What happened) for the slow walk, the new walk time and the two-metre picture test, and the learner's spoken or written explanation of who the change helps.

    Test table columns: Test | My guess | What happened

    Predict
    Before timing, the learner guesses: is 5.6 seconds long enough for the slowest walker?
    Debug
    If “walk” still ends too soon, check that the changed program was downloaded, then time the walk again.
    Reflect
    Who does your change help, and could it make anyone wait too long?

    ⚠ Adult checks before power-on: Nothing metal touches the micro:bit or its gold pins along the bottom edge (no coins, keys, foil, metal clips or jewellery): metal across the pins can short the power. Hands holding the board are fine. The learner plugs in the USB cable, gripping the plug, while the adult watches; only the adult fits or unplugs the battery pack. The timed walk is slow, on a clear classroom floor, never near a real road.

    Works towards: Help or harm

  5. Session 5 · 75 min

    Can I show and explain a safe light sequence?

    The prototype, a programmable pedestrian crossing, demonstrated: the light sequence (don't walk, walk, hurry, don't walk), the safe default when unsure, and who it helps and could still leave out.

    The adult says first: “Show us your crossing. Tell us why each step is safe.”

    Learner card

    1. Show the start.
    2. Ask to cross with A.
    3. Say what comes next.
    4. Press B. What happens?
    5. Who does it help?

    Key words (show each with a picture): sequence · safe · explain

    Timing (10 of 75 min at the screen)

    1. 15 minAway from the screen: Rehearse with the picture cards: what will each step show?
    2. 10 minAt the screen: Run the final program in the simulator once, then plug in USB and download.
    3. 30 minAway from the screen: Demonstrate: start, A, the full sequence, B, and a short press of reset in “walk”.
    4. 20 minAway from the screen: Explain why each part is safe, who it helps and who it still leaves out.

    In the studio

    No studio lab or activity.

    Outside the studio: MakeCode editor and its micro:bit simulator (makecode.microbit.org)

    Hands-on

    First, away from the screen, the learner rehearses the demonstration with the picture cards. In the simulator next, the learner runs the final program once, then downloads it to the real micro:bit; the adult fits the battery pack. The learner demonstrates: the crossing at start, a request with A, the full sequence, a press of B, and a restart by the adult (a short press of reset) in the middle of “walk”. Before each step the learner says what will happen; afterwards they explain why each part is safe, who it helps, and one person it still does not serve well.

    Starting blocks: The learner's own crossing blocks from session 4.

    Evidence to collect

    The unit's evidence: the learner demonstrates and explains safe light sequences: a prediction before each step, a short test table (Step | My guess | What it showed | Safe?) for start, request, the full sequence, button B and a restart, and the learner's spoken or written explanation of why “don't walk” is the default and who the crossing helps and could still leave out.

    Test table columns: Step | My guess | What it showed | Safe?

    Predict
    Before each step of the demonstration, the learner says what the crossing will show.
    Debug
    If the demonstration goes wrong, stop, read the blocks aloud from “on start” down, and find the step that differs.
    Reflect
    If you built this again, what would you change first, and for whom?

    ⚠ Adult checks before power-on: Nothing metal touches the micro:bit or its gold pins along the bottom edge (no coins, keys, foil, metal clips or jewellery): metal across the pins can short the power. Hands holding the board are fine. The learner plugs in the USB cable, gripping the plug, while the adult watches; only the adult fits or unplugs the battery pack. To restart, give the reset button on the back a short press. Do not hold it: on a micro:bit V2, holding it puts the board into power-saving mode, another dark display (hold it again to wake it).

    Works towards: Safe default, Help or harm

Materials

  • Per pair: a BBC micro:bit and its USB cable (USB micro-B at the micro:bit end)
  • A computer with a web browser for MakeCode (makecode.microbit.org); no installs needed
  • Kept by the adult: the micro:bit battery pack with 2 × AAA zinc or alkaline cells; no rechargeable cells, Li-ion, LiPo, RC or coin-cell packs
  • Pencils and paper for the test tables
  • Masking tape, toy figures, a toy car and two picture cards (“walk” and “don't walk”)
  • A stopwatch or a clock with a seconds hand, used by the adult

⚠ Safety before any session

  • The crossing is a model on a table. It is never used at a real road or to tell anyone when to cross.
  • Tell the group: at a real crossing, even when the green figure shows, stop, look and listen, and cross with an adult; follow your local road-safety guidance.
  • Batteries: only the micro:bit's 2 × AAA pack with zinc or alkaline cells, or USB from a computer; no rechargeable cells, power banks, Li-ion, LiPo, RC packs or coin cells.
  • Cells: the adult fits two new cells of the same type, the right way round, never mixes new and used cells, and takes spent cells out of the pack.
  • The official pack has no on/off switch: to switch off, the adult unplugs it, gripping the connector's base and wiggling it gently, never forcing it.
  • Nothing is connected to the micro:bit's pins in this unit. Never connect a 5 V signal or supply to a micro:bit's pins or battery socket: it runs at 3.6 V at most.
  • If the micro:bit or its pack gets warm: don't touch it; tell the adult, who unplugs it.
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

  • Read each step aloud first: your words come before the learner's card. The card uses short sentences; show each key word with a picture.
  • These plans assume one adult for up to four pairs. Learners plug the USB cable into their own computer, gripping the plug, while the adult watches; only the adult handles cells and battery packs. With more pairs, add an adult or bring fewer pairs to the real board at once.
  • Each session's timing keeps screen time to short bursts (15 minutes at most), with building, acting or testing away from the screen between them.
  • Before the first session on the real board, set up each computer and test a download: either pair each micro:bit once with WebUSB (then MakeCode's Download button sends the program straight to it), or download the .hex file and drag it onto the MICROBIT drive. The light on the back flashes while the program copies: unplug only after it stops.
  • The MakeCode simulator and Robot Blocks prepare the work. Only the real micro:bit, seen working by the adult, counts as evidence: a simulator run is never physical success.
  • Hand out each session's test table with its columns ready: the learner fills it in, and the adult writes only for a learner who needs it. Making their own tables is taught in R09-U3.
  • The studio's Arduino labs are written for ages 12 and up and are not used in this unit. Robot Blocks also shows each program as Arduino-style code: point to the blocks, not the code.
  • This unit uses buttons, not sensors: it starts from block programs, if … else and criteria, not from R09-U2 or R09-U3.
  • Talk about people who cannot see the signal without asking anyone to pretend to have a disability.
  • Readiness decides, not age: a learner who already explains a safe default and who a design helps or leaves out can move on to the next band's work.

Planned studio features

Not built yet. The unit runs without them.

  • A micro:bit-style blocks simulator in the studio, with a model crossing that shows the safe default.
  • Printable picture cards for each session's key words, the two crossing signals and printable learner cards.

Sources

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