Giving Exact Instructions

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.

This is the most important idea this week. When a robot misbehaves, it is almost always following your instructions correctly - your instructions just weren't what you wanted.

For example: 'Make a sandwich' fails if you don't say 'open the bread bag first'; A robot told to 'turn' but not how far spins the wrong amount; 'Go to the door' means nothing to a robot - it needs 'forward 3 squares, turn left'

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.

Order matters. 'Turn right, then move forward' sends the robot somewhere completely different from 'move forward, then turn right', even though the commands are the same.

For example: move forward 2 squares -> turn right -> move forward 1 square; Swapping two commands changes where the robot ends up

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.

This week every program has one event at the top that kicks off the sequence, and then the commands run straight through in order.

For example: 'When Start is pressed' at the top of the program; Clicking Run in the simulator; Tapping the go button on the kit app

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.

Pseudocode lets you think through the path without fighting the blocks yet. You might write 'forward 3, turn left, forward 2, stop', check that it makes sense, and only then build it as commands.

For example: Pseudocode: 'forward 3 squares, turn left 90, forward 2 squares, stop'; An algorithm has no missing steps and no 'you know what I mean' gaps

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.

Turns rotate the robot in place, usually by degrees. A 90-degree turn is a quarter turn - a right angle - which lines the robot up with the next part of the path. Getting the turn amount right is what keeps the robot on course.

For example: forward at speed 50 for 2 seconds; turn right 90 degrees to face the next hallway; half turn = 180 degrees to go back the way you came

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.

Then run it and compare. If the robot ends up somewhere else, the difference tells you exactly which command to fix - maybe a turn was 90 when it needed 180, or a forward was one square too short.

For example: Predict: 'ends on the star, facing up'; If it stops one square early, a distance command is too small

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.

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