EMBEDDED RUST · no_std → WASM

Capstone: The Portable, Deterministic Controller

Compose the whole course into one firmware, a Controller trait, a Phase state machine, and a non-blocking heartbeat, and land the rover inside a tight 0.12 m pad with the status LED beating, all in no_std Rust.

01Challenge

Assemble the language into one firmware. The Controller trait from the abstraction module, the Phase state machine from the types module, and a non-blocking heartbeat are wired up for you. Fill in the pursuit law so the rover lands inside the 0.12 m pad with the LED beating at about 2 Hz.

02Model

This is the whole course in one file. Ownership and borrowing gave you safe access to the peripherals. Option and enums modelled the sensor and the states. The trait gave you a reusable, zero-cost controller. The one-binary seam made it portable, and no garbage collector made it deterministic. Here they come together: a Pursuit controller behind a trait, driven only in the Seek state and stopped in Arrive, with a heartbeat derived from the clock so ground control can see the firmware is alive, all on one non-blocking loop. Fill in the step law, and land the rover on the tight pad. This artifact is portable to a real board and predictable to the tick, which is the point of writing Physical AI in Rust.

03Guided practice

1. Fill in step. Inside Pursuit::step: let turn = self.turn_gain * bearing; let forward = (self.fwd_gain * dist).min(self.cap); return (forward - turn, forward + turn). 2. Read the machine. Seek drives with the controller; Arrive stops. The match is exhaustive. 3. The heartbeat is kept for you. (millis() / 250.0) as i32 % 2 == 0 toggles the LED about twice a second without blocking the loop. 4. Land it. Settle inside 0.12 m within 14 s with the LED toggling: the portable, deterministic controller, complete.

04Feedback

PASS WHEN The composed firmware lands the rover inside 0.12 m within 14 s with the heartbeat LED toggling: trait, state machine, and non-blocking loop working as one.

If your run fails, check:

Rover sits still: `Pursuit::step` still returns `(0.0, 0.0)`. Compute turn and forward from the fields.
Reaches the pad but the LED toggled too few times: the heartbeat line is `(millis() / 250.0) as i32 % 2 == 0`; do not remove it or block the loop.
Overshoots the tight 0.12 m pad: keep `(self.fwd_gain * dist).min(self.cap)` so effort eases to zero as you arrive.

05Retrieve & space

Which piece of the course does each part of this firmware come from, the trait, the enum, and the heartbeat?
Why is deriving the heartbeat from millis() better than sleeping inside the loop? (it never blocks the navigator).
In one sentence, why is this controller both portable to a real board and predictable to the tick?

06Mastery & project

Compose ownership, the type system, a zero-cost trait, and a non-blocking loop into one no_std firmware that lands the rover on a tight pad: the course, proven on the metal.

The capstone artifact of Rust for Physical AI: a portable, deterministic control loop built from every concept in the course.

GO FURTHER · THE LIVE PLAYGROUND

Pilot the rover you programmed ↗ — drive the same MuJoCo rover your firmware controls
Race your control code in the Arena ↗ — code-to-compete: put your controller on the board

← Correct, and On Time Back to course →

EMBEDDED RUST · no_std → WASM

Capstone: The Portable, Deterministic Controller

Compose the course into one no_std firmware: trait + state machine + non-blocking heartbeat. Fill in the pursuit law and 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