Giving Exact Instructions

Turn a path into a clear step-by-step plan, then program the robot to follow it exactly.

60-75 minutes

Key ideas

Computers follow instructions literally

A robot does exactly what you tell it - not what you meant. If you say 'go forward' but forget to say how far, the robot cannot guess; it does the wrong thing or nothing at all. Computers are fast and tireless, but they have no common sense.

A program is a sequence of commands

A program is a list of commands the robot runs one after another, from top to bottom. Each command is one small instruction, like 'move forward' or 'turn right'. Running them in order is called a sequence.

Events start a program

A program doesn't run until something starts it. That starting moment is called an event - like pressing a 'Start' button, tapping a 'when tapped' block, or clicking Run in the simulator.

Algorithms and pseudocode: plan before you code

An algorithm is a clear step-by-step plan for a task, with every step spelled out and nothing left fuzzy. Before writing real code, engineers write the plan in plain language first - that plain-language plan is called pseudocode.

Controlling distance with timing, speed, and turns

This week you steer the robot with three tools: how far it moves (distance), how long a move runs (timing), and how much it rotates (turns). On many kits, distance comes from timing and speed together - a faster speed for a longer time covers more ground.

Predict before you run

Before running a program, make a prediction: trace the sequence with your finger and mark where you think the robot will stop and which way it will face. Committing to a guess first makes it obvious when a step is wrong.

Words to know

Program:: A list of instructions a computer follows to do a job. This week, a program is a sequence of movement commands.
Command:: One single instruction the robot can carry out, like 'move forward' or 'turn right'.
Sequence:: Commands run one after another, in order, from top to bottom. Order matters.
Algorithm:: A clear step-by-step plan for doing a task, with no missing or fuzzy steps.
Pseudocode:: Writing the steps of a plan in plain language before you turn them into real code.
Event:: The moment that starts a program running, like pressing 'Start' or a 'when tapped' block.
Timing:: How long a command runs, measured in seconds - one way to control how far the robot goes.
Distance:: How far the robot moves in a command, often set in centimeters or grid squares.
Turn:: A command that rotates the robot in place, usually by a set number of degrees like 90.
Speed:: How fast the motors run. Faster speed covers more distance in the same amount of time.
Prediction:: Your best guess about where the robot will end up, made before you run the program.

Your activity

Delivery path programming challenge

Goal: Program the robot to follow a path or maze from start to goal using only a sequence of exact move and turn commands.

Look at the map and find the start, the goal, and the walls or turns along the path. Trace the route with your finger first.
Write the plan as pseudocode in plain language - forwards, turns, and distances in order - before you build anything. Keep it a straight sequence: no loops, no if-checks, no sensors this week.
Turn the pseudocode into commands, run it, and fix the exact command that was wrong if the robot misses the goal.

Write what happened:

Predict-then-test the ending

Goal: Predict where the robot will stop and which way it will face before running a given sequence, then run it and compare.

Take a short sequence of commands and trace it by hand on the map. Mark on paper where you think the robot ends and which way it faces.
Commit to your prediction before running anything - write it down first.
Run the program, compare the real ending to your prediction, and explain any difference by naming the command that caused it.

Write what happened:

Predict

Write your guess before you test.

Before running your delivery program, which square do you predict the robot stops on, and which way will it be facing?

How many commands (steps) do you think your program needs to reach the goal?

Test and record

Predict-vs-actual ending record

For each attempt, write your predicted ending square before running, then run the sequence and record where the robot actually ended. Note which command you changed for the next attempt.

Record: The predicted end position versus the actual end position across attempts

Attempt	Predicted end square	Actual end square	Command changed for next try

Knowledge check

Answer each question. For choice questions, circle the best answer.

Put these steps in the right order for programming the robot to do a task.
- (Number these from 1 to 4.)
- 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
The robot starts facing up. Trace this program. Which way is it facing at the end?
```
turn right
turn right
turn left
```
- A.Facing up
- B.Facing right
- C.Facing down
- D.Facing left
Your robot did the wrong thing even though it ran your whole program. What most likely happened?
- A.The robot decided to be creative
- B.It followed your instructions exactly, but your instructions weren't what you wanted
- C.The robot ignored the program
- D.Programs never work the first time on purpose
What is a sequence?
- A.Commands that run one after another, in order
- B.A command that repeats forever
- C.A command that decides based on a sensor
- D.All the commands running at the exact same time
What is pseudocode?
- A.A secret code only computers can read
- B.The plan for a program written in plain language before you code it
- C.A broken program with bugs
- D.The event that starts a program
Your robot reaches the right spot but is facing the wrong way. Which command should you check?
- A.A forward-distance command
- B.The Start event
- C.A turn command - the degrees or the direction
- D.The stop command
On a kit that uses timing, how could you make the robot travel farther in one forward command?
- A.Run the motors for a longer time (or at a higher speed)
- B.Add a turn command
- C.Change the Start event
- D.Write the command in a different color

Reflect

Which instruction caused the largest error, and how did you make it more precise?

How did writing pseudocode first help you before you built the real commands?

When your prediction didn't match what the robot did, how did you find which command to fix?