VISUAL · BLOCKS → PYTHON

Blocks Are Python

A block program generates Python. You raise the rover's speed by editing one generated line, leaving the 0.25 m stop check alone. What happens to the stop?

Read the Python generated by a block program and correctly predict the effect of editing a single generated line before running it.

01Challenge

Split view: Blockly on the left, generated Python on the right. The goal is off to one side, so the rover must turn to face it before driving. Edit exactly one number in the Python pane so the rover drives faster once aligned. Then, before you press Run, predict: will it still stop in time? You pass when your prediction matches what the sim does.

Predict firstA block program generates Python. You raise the rover's speed by editing one generated line, leaving the 0.25 m stop check alone. What happens to the stop?

02Model

Every block you've dragged has been writing code behind your back. This block is this line: set motors left [0.5] right [0.5] becomes rover.set_motor(0.5, 0.5), a friendlier costume for one line of Python. Stack the blocks and you've written a whole program: repeat forever is while True, if/else is if/elif/else.

Once you can read it, you can change it. Bump one number and the rover behaves differently, sometimes in ways you didn't expect. Reading code means predicting what it'll do. That's the whole game from here on.

Each block is exactly one line of Python.

03Guided practice

Step 1 (worked): change set_motor(0.4)->0.6 and predict sooner/same/later + stops y/n; at 0.6 it usually still stops (safe first edit). Step 2 (faded): you choose which single number to edit (one-token diff enforced) and predict. Step 3 (independent): edit one line so the mis-aimed rover faces the goal and drives to it, prediction matching the sim.

04Feedback

PASS WHEN Rover faced the off-axis goal (|bearing| <= 0.05) before driving, reached within 0.25 m with no overshoot, exactly one edited token, and the submitted prediction matches the measured outcome.

If your run fails, check:

FAIL: prediction mismatch. At higher speed the rover covers more ground per tick than the 0.25 m stop check can catch; predict 'overshoots' or lower the speed.
FAIL: rover spins without settling on the goal. The alignment band is narrower than the turn step; widen it or slow the turn.
FAIL: started driving while still off heading. Keep the turn checks above the drive else so it faces the goal first.

05Retrieve & space

Block<->Python match-up: repeat forever -> while True, if/else -> if/elif/else, plus the 1.1 stop and 1.2 proximity branch.
Trace-the-output: given bearing = -0.4, which branch fires first? (elif bearing < -0.05 -> turn right.)
Loop-phase audit: label each Python line SENSE / DECIDE / ACT.

06Mastery & project

Module-1->Module-2 tier gate: read the generated Python, edit exactly one line, correctly predict its effect, and have the rover turn to face the off-axis goal and halt within 0.25 m (bridges L1->L2: can read and reason about the Python the blocks generate).

The Depth-1->Depth-2 hinge: the predict-then-edit-then-verify habit is the debugging loop of every later module, and the goal_bearing turn-to-face logic is the precursor to the PID heading controller in Lesson 2.2.

← React and Avoid Reading the World →

VISUAL · BLOCKS → PYTHON

Blocks Are Python

Read the generated Python, edit ONE number, predict the outcome, then run.

You read

the same obs values, read as blocks

You change

the blocks you snap together inside control

Fixed

the loop, the rover, and the physics