Week 3: Giving Exact Instructions

Session length: 60-75 minutes

Learning purpose

Students learn that computers follow instructions literally and exactly: a robot does what you actually told it, not what you meant. They write an algorithm - a clear step-by-step plan - as pseudocode in plain language, then turn it into a program made of a straight sequence of movement commands with timing, distance, and turns. They predict where the robot will end up before running, then run and compare. This is a sequences-only week: no loops, conditions, or sensors yet - just exact, ordered commands to steer a robot through a delivery path or maze to a goal.

Expected student outcomes

By the end of this week, students can:

Explain that a program is a sequence of commands a computer follows in order, literally and exactly
Write an algorithm as pseudocode - a clear step-by-step plan in plain language - before coding
Control a robot's path using distance, timing, and turn commands in the right order
Predict where a robot will end up before running the program, then check the prediction
Program the robot to follow a delivery path or maze to a goal using only a sequence of commands

Suggested pacing

About 60-75 minutes. Adjust to your group - these are guides, not limits.

Step	Focus	Minutes
Exact instructions, sequences, and events	Computers follow commands literally; a program is an ordered sequence started by an event.	12 min
Algorithms, pseudocode, and controlling the path	Plan an algorithm as pseudocode; control distance with timing, speed, and turns.	10 min
Delivery and maze programming challenges	Plan pseudocode, then program a sequence to reach the goal - first the delivery path, then the maze around a wall.	22 min
Predict-then-test the ending	Predict the stopping square and facing before running, then compare.	12 min
Record predicted vs actual	Fill in the predict-vs-actual record across attempts.	6 min
Knowledge check	Five questions on sequences, algorithms, pseudocode, and turns.	8 min
Reflection	Write about literal instructions, pseudocode, and finding the wrong command.	5 min

Before you start

Set up

Print the path/maze map, the pseudocode planning sheet, and the predict-and-test record for each student or pair.
For kits, tape a simple path with one or two turns on the floor and set out a small delivery object; for the simulator, open the delivery mission on each device.
For unplugged, lay out a tape floor grid or hand out printed grids and arrow/command cards.

Prepare ahead

Run one path yourself to learn roughly how far one forward command moves the kit robot and how far a 90-degree turn rotates it.
Prepare one short 'buggy' sequence you can run so students see a robot follow wrong instructions literally.
Have the Week 2 rolling bases charged and ready.

Materials

Path or maze map with a start, a goal, and grid squares (printable)(Kit, Simulator, Unplugged)
Pseudocode planning sheet (printable)(Kit, Simulator, Unplugged)
Predict-and-test record sheet (printable)(Kit, Simulator, Unplugged)
Pencil and paper(Kit, Simulator, Unplugged)
The rolling robot base you built in Week 2, with its app or software(Kit)
Masking tape and a small object to deliver (a bottle cap or block)(Kit)Tape marks the path and goal on the floor.
Computer or tablet with the browser simulator(Simulator)
Arrow/command cards (forward, back, turn left, turn right, wait, stop)(Unplugged)
Floor grid made from tape, or a printed grid to walk a token across(Unplugged)

Safety

cautionKeep fingers, hair, and loose clothing away from the wheels while the robot drives its program.(Kit)
cautionClear the floor path of feet, bags, and chair legs before running so the robot has a safe route.(Kit, Unplugged)
infoWalk slowly on the floor grid when acting as the robot so no one trips.(Unplugged)
infoTake a short screen break if your eyes get tired using the simulator.(Simulator)

Full safety briefing

Review these once with your group. They apply across the whole course; the notes above are what matters most this week.

Batteries and circuitsKit

Use only appropriate low-voltage educational equipment - no wall outlets and no household batteries wired by hand.
Never connect a battery's two terminals directly to each other.
Stop right away if a motor, wire, or battery becomes hot, and tell an adult.
Disconnect the power before changing wheels, motors, or other mechanical parts.

Motors and gearsKit

Keep fingers, hair, jewelry, sleeves, and loose clothing away from moving gears and wheels.
Do not force a stalled motor that has stopped turning - switch it off and find out why.
Make sure moving parts are secured before you run a test.

Moving robots

Test on the floor, not on a table where the robot could drive off an edge.
Keep robots away from stairs, roads, water, pets, and people's feet.
Use a clear, open test area.
Always include a safe-stop behavior so the robot halts when the job is done or something is in the way.

Tools and materialsKit, Unplugged

Ask an adult for help with cutting or any sharp tools.
Use safe classroom materials - no sharp, toxic, or breakable items.
Never launch or swing an attachment toward a person.

Running the session

1.Open with the literal-instructions idea: give a deliberately vague instruction and have a student follow it exactly to show what goes wrong.
2.Teach sequence, event, algorithm, and pseudocode before any coding; insist pseudocode is written before commands.
3.Run the delivery challenge, then the predict-then-test activity - always predicting before running.
4.Have students record predicted vs actual, then close with the knowledge check and reflection.

Common misconceptions

'The robot did what I meant' - it does what you said, literally, not what you intended.
Order doesn't matter - swapping a turn and a forward sends the robot somewhere completely different.
'Turn' and 'move' are the same kind of command - a turn changes facing, a move changes position.
Skipping the pseudocode plan and building blocks by trial and error.

Questions to ask

What exactly did you tell the robot to do at this step?
Where do you predict it will stop, and which way will it face?
The robot missed the goal - which single command explains that?
Would your program still work if two commands were swapped?

Classroom & group adaptations

Make it easier

Use a short, straight path with a single turn, and give students a pseudocode template to fill in rather than write from scratch.

Make it harder

Add a longer maze with several turns and challenge students to reach the goal using the fewest commands.

Groups & whole class

In pairs or small groups, give each student a role that rotates - driver (builds or types), navigator (reads the plan), and recorder (fills the worksheet) - so everyone participates. For a whole-class demo, run one shared robot or simulator on the board, have students predict together, then let groups repeat it on their own path. Groups can also mix paths: one builds on the kit while another checks the same idea in the simulator or unplugged, then they compare results.

Hardware and no-hardware notes

Every activity this week runs three ways - all three teach the same core idea, so pick whichever fits your room. No specific product is required.

Kit

Path or maze map with a start, a goal, and grid squares (printable)
Pseudocode planning sheet (printable)
Predict-and-test record sheet (printable)
Pencil and paper
The rolling robot base you built in Week 2, with its app or software
Masking tape and a small object to deliver (a bottle cap or block)

Simulator

Path or maze map with a start, a goal, and grid squares (printable)
Pseudocode planning sheet (printable)
Predict-and-test record sheet (printable)
Pencil and paper
Computer or tablet with the browser simulator

Unplugged

Path or maze map with a start, a goal, and grid squares (printable)
Pseudocode planning sheet (printable)
Predict-and-test record sheet (printable)
Pencil and paper
Arrow/command cards (forward, back, turn left, turn right, wait, stop)
Floor grid made from tape, or a printed grid to walk a token across

Troubleshooting

Common problems from this week's activities and what to try.

The robot overshoots or stops short of the goalKitTry: Adjust the distance or the timing on that forward command; a small change in seconds moves it a lot.
The robot turns too far or not far enoughKitTry: Check the turn's degrees - try 90 for a quarter turn - and confirm left vs right.
The robot drives into a wallSimulatorTry: Count the open squares again; a forward block is probably one square too many.
The robot faces the wrong way after a turnSimulatorTry: Swap turn-left for turn-right, or check how many squares come before the turn.
The robot 'cheats' by fixing steps on the wayUnpluggedTry: Remind them to follow cards literally - the point is to find the bug in the instructions, not to hide it.
The robot ends up facing the wrong wayUnpluggedTry: A turn card is on the wrong side or missing; check left vs right.
Prediction and result are far apart every timeKitTry: Re-measure how far one forward command really moves the robot; your distance estimate is off.
Lost track while tracing the sequenceSimulatorTry: Trace one command at a time with your finger and mark each square as you go.
Everyone predicts differentlyUnpluggedTry: Trace the cards together one at a time - a shared trace shows where predictions split.

Knowledge-check answer key

Answers are shown here for the adult only - the student worksheet keeps them hidden.

1. Put these steps in the right order for programming the robot to do a task.
Correct answer: Plan the steps as an algorithm -> Write the steps as exact commands -> Run the program on the robot -> Check whether it did what you expected
Why: You plan the algorithm first, turn it into exact commands, run it, then check the result - the same loop programmers use.
2. The robot starts facing up. Trace this program. Which way is it facing at the end?
Correct answer: Facing right
Why: Right, right, left equals one net right turn. Starting from up, one right turn faces the robot right.
3. Your robot did the wrong thing even though it ran your whole program. What most likely happened?
Correct answer: It followed your instructions exactly, but your instructions weren't what you wanted
Why: Computers follow instructions literally and exactly. A wrong result almost always means the instructions didn't say what you meant.
4. What is a sequence?
Correct answer: Commands that run one after another, in order
Why: A sequence is commands carried out one after another, in order - swapping two commands can change the whole result.
5. What is pseudocode?
Correct answer: The plan for a program written in plain language before you code it
Why: Pseudocode is writing your algorithm's steps in plain language first, so you can plan the path before turning it into real commands.
6. Your robot reaches the right spot but is facing the wrong way. Which command should you check?
Correct answer: A turn command - the degrees or the direction
Why: Turns control the robot's facing. A wrong-way ending points to a turn with the wrong degrees or the wrong direction.
7. On a kit that uses timing, how could you make the robot travel farther in one forward command?
Correct answer: Run the motors for a longer time (or at a higher speed)
Why: Distance comes from timing and speed: running longer, or faster, moves the robot farther in one forward command.