while Loops as Robot Control Loops

Discussion prompt

Before we open while Loops as Robot Control Loops: without looking back, what was the main idea of Decisions: if / elif / else & Finite-State Thinking, and what could you do by the end of it that you could not do before?

Hint: One sentence for the idea, one for the skill. If the second one is blank, that is the part to revisit.

Discussion prompt

Every loop you write today has to answer one question:

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Discussion prompt

Explain What a while loop does by analogy to something with no Python in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Predict first

Before the robot, here is a tiny while to read - the only finished code we will trace together. Watch the value that changes.

Commit before you compute: what does A first while loop: counting come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.

Correct: Trace each pass

Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. Verified by execution: prints 0, 1, 2, then done.

Comparison matrix

From A first while loop: counting: refill the count (checked) column from what you know. The rest of the table is as it appeared.

Discussion prompt

Explain A while loop is a question asked before every pass to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Comparison matrix

From The maze (the map): every row here is a choice with a cost. Fill the 3 column, then say which row you would actually pick and what you give up for it.

Sort into buckets

Every line below is part of the definition of condition or of stale reading — one or the other, never both. Put each where it belongs.

condition

The True/False test a while loop checks before each pass.; While it is True the body runs again; when it turns False the loop ends.

stale reading

A sensor value read once and then reused.; A real robot that acts on a stale reading drives blind - it ignores walls that appeared after it last looked.; Read sensors inside the loop.

b1

The True/False test a while loop checks before each pass. While it is True the body runs again; when it turns False the loop ends.

b2

A sensor value read once and then reused. A real robot that acts on a stale reading drives blind - it ignores walls that appeared after it last looked. Read sensors inside the loop.

Predict first

The table runs: start | (1,1) · after run 1 | (1,2) · after run 2 | (1,3)

In Your turn - Level 1: move until a wall, given the rows so far: what is the next one — the row where loop run is after run 3?

Correct: after run 3 | (1,4) - wall ahead, stop

Why: The relationship between the columns, not the individual numbers, is what generates the next row. On a clear 3-cell corridor, a correct loop drives forward three times, then stops because look() returns "wall".

Fill in the blanks

From Your turn - Level 2: turn when blocked — one line has had its right-hand side removed. Put it back.

# inside your loop:
camera = ____________ # sense (fresh, every pass)
if ___: # is the way blocked?
turn_right()
else:
move_forward()

Why: camera is what everything below it consumes, so the wrong expression here fails later and somewhere else. Each pass, the camera decides the single action: a wall means turn, a clear cell means move.

Predict first

The table runs: 1 | wall | (1,1) turned · 2 | clear | (2,1) · 3 | clear | (3,1)

In Your turn - Level 3: stop at the goal, given the rows so far: what is the next one — the row where loop run is 4?

Correct: 4 | clear | (4,1) = goal, stop

Why: The relationship between the columns, not the individual numbers, is what generates the next row. On the maze, a correct Level 3 loop turns once, then moves down to the goal - four passes, matching the demo run.

Comparison matrix

From Your turn - Level 3: stop at the goal: refill the camera column from what you know. The rest of the table is as it appeared.

Fill in the blanks

From Your turn - Level 4: add the safety stop — one line has had its right-hand side removed. Put it back.

steps = ____ # start the counter
while ___ and ___: # not at goal AND under the limit
# your sense -> decide -> act body
___ # update the counter each pass

Why: steps is what everything below it consumes, so the wrong expression here fails later and somewhere else. Now the loop has two ways to stop.

Discussion prompt

Explain The update line is the off-switch to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Discussion prompt

Explain Two ways to stop, joined by and by analogy to something with no Python in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Discussion prompt

Every run finishes in one of three states - and your finished controller should handle all three:

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Predict first

A student writes this, and it looks reasonable:

This controller reads the camera in the wrong place. What goes wrong?

It is wrong. Say what breaks — and say it before you turn the page.

Correct: If the first look() was "wall", the robot turns every single pass and never moves.

The fix: move the reading inside the loop.

Why: If the first look() was "wall", the robot turns every single pass and never moves. A stale sensor can't react to the maze.

Annotate

Walk the callouts on Debug challenge: a stale sensor. Each one is a place this is easy to get subtly wrong.

• If the first look() was "wall", the robot turns every single pass and never moves. A stale sensor can't react to the maze.
• Now the robot senses its current cell every iteration, so it turns at real walls and moves through real openings.

Predict first

A student writes this, and it looks reasonable:

You want at most 20 passes. Does this give 20?

It is wrong. Say what breaks — and say it before you turn the page.

Correct: steps takes the values 0, 1, ..., 20 - that is 21 passes, not 20.

Use < for an exact cap.

Why: steps takes the values 0, 1, ..., 20 - that is 21 passes, not 20. <= includes the limit itself.

Predict first

A student writes this, and it looks reasonable:

The robot is boxed in (no path to the goal), and one line is missing. What happens?

It is wrong. Say what breaks — and say it before you turn the page.

Correct: steps stays 0 forever, so steps < max_steps is always True; the boxed-in robot is never at_goal() either.

Add the update so the counter climbs to the cap.

Why: steps stays 0 forever, so steps < max_steps is always True; the boxed-in robot is never at_goal() either. Both parts stay True - an infinite loop.

Annotate

Walk the callouts on Debug challenge: the missing update. Each one is a place this is easy to get subtly wrong.

• steps stays 0 forever, so steps < max_steps is always True; the boxed-in robot is never at_goal() either. Both parts stay True - an infinite loop.
• Now steps climbs 1, 2, 3, ... until steps < max_steps is False. A boxed-in robot stops at the timeout instead of looping forever.

Predict first

A student writes this, and it looks reasonable:

This loop has the condition backwards. What does the robot do?

It is wrong. Say what breaks — and say it before you turn the page.

Correct: If the robot is not yet at the goal, at_goal() is False, so the body never runs - the robot never moves.

Loop until the goal: add not.

Why: If the robot is not yet at the goal, at_goal() is False, so the body never runs - the robot never moves. The 'not' is missing.

Sort into buckets

Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.

Holds up

Every loop you write today has to answer one question:; A while loop repeats its body as long as a condition is True. Before every pass it checks the condition; the moment the condition is False, it stops.; Picture a gate you reach again and again. Each time, you ask the condition: still True? If yes, you walk through and do the body; if no, you stop and move on.

Breaks

This controller reads the camera in the wrong place. What goes wrong?; You want at most 20 passes. Does this give 20?

sound

These are stated as this lesson states them — each one survives the edge cases while Loops as Robot Control Loops puts it through.

flawed

Each of these is lifted from a trap in this deck: reasonable-sounding, and wrong in a way that only shows up once you rely on it.

Discussion prompt

Outside this lesson: where does while Loops as Robot Control Loops actually turn up? Name one concrete situation — a job, a piece of software someone ships, a decision somebody has to make — and say which part of The robot control-loop recipe is doing the work in it.

Hint: Vague is the failure mode here. "Engineering" is not a situation; "deciding whether this build is fast enough to ship" is.

Check your understanding

What does this print?

• A. 0 (correct)
• B. 1
• C. 20
• D. nothing (infinite loop)

Answer: A

Why: A while loop checks its condition BEFORE each pass. The robot is already on the goal, so at_goal() is True, not at_goal() is False, and the body never runs. steps stays 0 and it prints 0. Verified by the simulator.

Why B tempts people

The body never runs even once. while checks the condition first, and it is already False, so steps is never increased past 0.

Why C tempts people

It does not run to the cap. The goal condition already fails the test, so the loop ends immediately with 0 passes.

Why D tempts people

It is the opposite of infinite - it stops before the first pass. Already being at the goal is exactly what ends it.

Check your understanding

How many times does the loop run?

• A. 3 (correct)
• B. 20
• C. 4
• D. forever

Answer: A

Why: Each pass sees a clear camera and moves forward one cell. After 3 moves the robot is on the goal, at_goal() becomes True, and the loop stops - well before the cap of 20. Verified.

Why B tempts people

It stops the instant it reaches the goal (3 passes), not at the max_steps cap. The cap only matters when the goal is never reached.

Why C tempts people

Three forward moves cover the 3 cells to the goal. A 4th pass would only happen if the goal were 4 cells away.

Why D tempts people

It is not forever - at_goal() becomes True after 3 moves. A clear path always ends here.

Check your understanding

What happens?

• A. Runs 3 times and stops one move short of the goal (correct)
• B. Runs 4 times and reaches the goal
• C. Runs forever
• D. Runs 0 times

Answer: A

Why: steps < 3 lets steps reach 1, 2, 3 - exactly 3 passes. The goal needs 4, so the safety cap stops the robot one move short, at a timeout. That is the off-by-one: a cap of 3 leaves no room for the 4th move. Verified by the simulator.

Why B tempts people

3 passes is the most steps < 3 allows. The goal needs 4, so it never arrives - raise max_steps to fix it.

Why C tempts people

It cannot run forever - steps hits the cap and stops it. That safety stop is the whole point of max_steps.

Why D tempts people

It runs 3 times, not 0 - the robot starts away from the goal, so the body does execute up to the cap.

Check your understanding

What does the robot do on each pass?

• A. Turns right every pass - it never re-checks (correct)
• B. Turns once, then moves forward
• C. Moves forward every pass
• D. Stops immediately

Answer: A

Why: camera is read only once, outside the loop, so its value never changes. It stays "wall" for every pass, and the robot turns right again and again without ever sensing that the way might now be clear. The fix is to read look() inside the loop. Verified.

Why B tempts people

The camera value can't change - it was captured once before the loop, so it never becomes 'clear' on a later pass. The robot keeps turning.

Why C tempts people

The first reading was 'wall' and it never refreshes, so the robot turns - not moves - every pass.

Why D tempts people

The loop does run; it just does the wrong thing each time. It ends only when steps reaches max_steps, not because of the stale reading.

Check your understanding

What happens?

• A. Infinite loop - it never stops (correct)
• B. Stops after max_steps passes
• C. Stops after 1 pass
• D. Reaches the goal

Answer: A

Why: Without steps = steps + 1, steps stays 0, so steps < max_steps is always True. The robot is boxed in, so at_goal() is always False too. Neither part of the condition ever changes, so the loop runs forever. The fix: update the value that is supposed to make the loop stop. Verified.

Why B tempts people

The max_steps safety only works if steps actually climbs. With the update missing, steps never reaches max_steps.

Why C tempts people

Nothing ends it after one pass - the condition is still True, so it immediately loops again, forever.

Why D tempts people

A boxed-in robot can never reach the goal, and with no counter there is no timeout either, so it never ends.

Check your understanding

When does this loop KEEP going?

• A. Only while BOTH hold: not yet at the goal AND under the step limit (correct)
• B. While either one holds
• C. Only while the robot is at the goal
• D. Only while steps is over max_steps

Answer: A

Why: and requires both sides to be True. The loop continues only while the robot is not yet at the goal AND still under the cap. The moment either fails - it arrives, or steps hits max_steps - the loop stops. That gives two ways to stop: success or timeout. Verified.

Why B tempts people

That describes or, not and. With and, both must hold; if even one becomes False, the loop ends.

Why C tempts people

not at_goal() means the loop runs while NOT at the goal. Arriving at the goal is one of the things that STOPS it.

Why D tempts people

steps < max_steps keeps it going while UNDER the cap. Going over the cap is what ends the loop, not what continues it.

Comparison matrix

From Check: reading the and condition: every row here is a choice with a cost. Fill the keeps looping while column, then say which row you would actually pick and what you give up for it.

Predict first

Now compare your build to the finished controller. If yours produces the same behavior, the code can look a little different - that's fine.

Commit before you compute: what does The answer: the complete controller come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.

Correct: Run it on the maze (real simulator output)

Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. Verified against the grid-maze simulator: 4 passes, then at_goal() is True and the loop stops.

Comparison matrix

From The answer: the complete controller: refill the steps column from what you know. The rest of the table is as it appeared.

Draw it

One page, no notation unless you need it: draw how these connect — The robot control-loop recipe · The one question for the whole lesson · What a while loop does · A while loop is a question asked before every pass · The one rule: something inside must change. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.