EMBEDDED RUST · no_std → WASM

Optimize the Critical Loop to the Metal

Re-implement the full autonomy control loop as no_std embedded Rust firmware against the rover HAL, with proportional steer-and-ease plus a non-blocking heartbeat, and prove it lands the rover inside a tight 0.12 m tolerance running directly on the metal.

01Challenge

Your Python autonomy stack from 5.1 reaches the pad, but only when grading end-state with a loose tolerance. The Bench now hands you the SAME rover but the firmware tier: a no_std Rust starter that compiles to WASM and IS the control loop, with the pad shrunk to 0.12 m. The starter only blinks an LED; the rover never moves. There's no interpreter to lean on, no garbage collector pausing whenever it likes, just one constant-time pass every control period. 'It settled fine in Python, so why can't I even reach the pad now?' That gap between correct-on-average and correct-on-time is the whole lesson. Make the metal land it.

02Model

Your Python robot was correct. Now it has to be correct on time. Correct and timely are not the same thing: a control loop that's late is a robot that's wrong, and Python is late at random. The interpreter pauses to collect garbage whenever it likes, and that scatter is jitter. The metal has no interpreter and no garbage collector. The host fires control() at a fixed period like a hardware timer interrupt, and your firmware runs the same handful of instructions every single tick, predictable to the cycle.

So you don't sprinkle optimizations; you move the loop that must be on time down to the metal whole. Read the beacon, steer proportionally on the bearing, and (this is what the tight tolerance forces) ease the forward effort as the distance shrinks, so you glide into the pad instead of slamming through it. Then add the heartbeat: toggle the LED on a fixed millis() schedule WITHOUT blocking, two concerns sharing one non-blocking loop. This is the metal doing the whole job.

To the metal: steady timing, no GC jitter.

03Guided practice

Stage A (worked): read the HAL. p.goal.distance()/bearing() in metres and radians (+ = LEFT), p.motors.set(left,right) signed duty in [-1,1], p.led.set(bool), millis(). The starter only blinks; the rover sits still because motors are never driven. Stage B (scaffolded): in control(), compute turn = 1.2 * bearing and a PROPORTIONAL forward = (0.9 * dist).min(0.6). The .min cap keeps it sane far out, the proportional term eases it down near the pad. Then p.motors.set(forward - turn, forward + turn). Stage C (independent): add the non-blocking heartbeat, let on = (millis()/250.0) as i32 % 2 == 0; p.led.set(on);, and tune the forward gain/cap until the rover settles inside 0.12 m within 14 s with the LED toggling. No blocking, no per-tick state needed: millis() carries the time.

04Feedback

PASS WHEN The firmware drives the rover into the 0.12 m pad within 14 s and the heartbeat LED toggles its required count. The full autonomy loop runs on the metal, constant-time and predictable, with no interpreter or GC. You moved the whole critical loop to the metal and proved it with a landed rover.

If your run fails, check:

FAIL: the rover never neared the pad (closest approach > 0.12 m). Your motors are still set to 0.0. Drive forward AND steer: p.motors.set(forward - turn, forward + turn).
FAIL: closest approach > 0.12 m. You overshot the shrunken pad. A constant forward slams through it; make forward PROPORTIONAL to dist (e.g. (0.9 * dist).min(0.6)) so effort eases to zero as you arrive.
FAIL: you reached the pad but the heartbeat LED toggled too few times. Toggle the LED on a fixed millis() period, (millis()/250.0) as i32 % 2 == 0, and don't block the loop waiting on it.

05Retrieve & space

From 4.1 (registers/GPIO): the HAL hands you p.goal.bearing() in radians with + = LEFT. If the rover veers the wrong way, which sign in turn = k * bearing is flipped, and why does that map to the motor wiring?
From 4.2 (timers/PWM): why does a constant forward effort overshoot a 0.12 m pad while a proportional forward settles into it? Show the duty-cycle the rover commands at dist = 0.1 m.
From 4.3 (interrupts/real-time): the heartbeat shares one non-blocking loop with the navigator. Explain in one sentence why reading the LED schedule from millis(), instead of sleeping, keeps both concerns on time.

06Mastery & project

Course capstone gate: the full autonomy loop, written as no_std Rust firmware, drives the rover into the 0.12 m pad within 14 s on the real physics bench with the heartbeat LED toggling, and does so on the metal, constant-time per tick, no interpreter, no GC (L4: move the whole critical loop down to the metal and prove it with a landed rover, not an average).

Lessons 5.1 + 5.2 together ARE the Course 2 capstone artifact: a fully autonomous rover whose entire control loop runs as no_std embedded Rust firmware on the metal, landing inside a tight tolerance with a live heartbeat, closing the One Robot, Three Depths arc from blocks, to Python, to the metal.

GO FURTHER · THE LIVE PLAYGROUND

Pilot the rover your firmware controls ↗ — the metal loop, live

← Full Autonomy in Python Back to course →

EMBEDDED RUST · no_std → WASM

Optimize the Critical Loop to the Metal

Re-implement the full autonomy loop as no_std embedded Rust firmware against the rover HAL. It compiles to WASM and runs DIRECTLY as the rover's control loop, with no emulator. Capstone tolerance: land inside 0.12 m.

You read

You change

the firmware you write in the control loop

Fixed

the emulated chip, its peripherals, and the wiring