Course labs
How the course labs work: a copy of a reference module with key functions left for you to write, graded by the same tests that check the reference code.
How a lab works
Each lab is a copy of one of the tutorial's tested modules with the important functions emptied
out. Their signature and docstring are still there; the body raises NotImplementedError with the
name of the page that teaches it. You write the body. The module's own test suite, the one that
checks the reference code in CI, then grades your version.
- Read the module page.
- Open the lab file,
libs/tutorial/labs/<module>.py, and find eachNotImplementedError. - Write the function. The docstring says what it must return and in what shape.
- Grade it:
uv run --group tutorial python scripts/tutorial_labs.py check state_estimationA lab is done when every test passes. Failing tests name the property that broke, such as "the
filter beats raw positions" or "uncertainty grows through a gap", which is usually enough to find the
mistake. To start again, reset writes a fresh copy (your work in that file is lost):
uv run --group tutorial python scripts/tutorial_labs.py reset state_estimationlist prints every lab with its functions and page. The reference implementation is the module of
the same name in libs/tutorial/; look at it after you have tried, not before.
Everything runs on a laptop CPU. Most labs grade in under ten seconds; flow_matching trains small
models and takes about half a minute.
The labs, in course order
| Lab | You write | Taught in |
|---|---|---|
attention | scaled_dot_product_attention | Toolkit: attention and transformers |
flow_matching | flow_matching_loss, euler_sample | Toolkit: generating trajectories with flow matching |
grpo | group_advantages | Toolkit: rewards and policy gradients |
modular_e2e | modular_stack, planner_inputs | From modular stacks to end-to-end driving |
sensor_encoders | lift_splat, pillar_encode | Sensor encoders for driving |
geometry | project_points, to_current_frame | Camera geometry and object queries |
state_estimation | kalman_filter, mean_nis | State estimation and tracking |
label_quality | cohen_kappa, audit_sample_size | Driving data and labels |
imitation | collect | Imitation learning and action chunking |
planning | bicycle_step, idm_acceleration | Planning and vehicle models |
alpamayo_pieces | unicycle_rollout, delta_tokenize, delta_detokenize | Reading the Alpamayo-R1 code |
policy_gradient | gae, ppo_objective | Reinforcement learning |
driving_metrics | ade_fde, min_ade_fde, pdm_score | Evaluating driving models |
conformal | conformal_quantile | Uncertainty and runtime safety |
safety_engineering | rss_min_gap, rss_filter, failure_free_miles | Safety engineering for learned drivers |
mini_driver | teacher, to_token, episode_reward, guarded | Project: build a mini driving VLA |
capstone | cautious_expert, train_driver, guarded_action, evidence | Capstone: ship a car-following driver |
Some labs depend on another module's reference code (the capstone uses the closed-loop scenarios and the safety module's RSS gap). They import the reference version, so you can do the labs in any order.
Course: End-to-end driving
A course path through the tutorial for engineers who know modular driving stacks: from perception, prediction and planning modules to driving vision-language-action models like Alpamayo-R1.
Toolkit: attention and transformers
The part of transformers a driving engineer needs for this course: attention as a soft lookup, queries, keys and values, heads, positions, causal decoding and the key-value cache.