Blocks Are Python
Read the Python generated by a block program and correctly predict the effect of editing a single generated line before running it.
Try this first — before any explanation.
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.
Read the generated Python, edit ONE number, predict the outcome, then run.
Blocks Are Python
Read the generated Python, edit ONE number, predict the outcome, then run.
The idea, built visually.
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.
▣ Stage animation: A single block melts into monospace text, its slots sliding into parentheses; the whole 1.3 stack morphs line-by-line into Python, each block tethered to its line; zoom on set_motor(0.4) ticking up to 0.9 with two ghost rovers — the 0.4 stops clean, the 0.9 blows past with an overshoot trail.
Build it up, step by step.
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.
How the Bench grades your run.
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.
- 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.
Bring back what you've already mastered.
- 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.
What you must demonstrate to advance.
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).
How this feeds your build.
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.