Module 0: Vocabulary Primer
If you already know some of these (the calibration questions before this workshop was generated suggested you already have a good instinct for a few), skim rather than skip: several terms carry a more specific meaning in this codebase than the generic industry term implies.
The domain
ADAS (Advanced Driver-Assistance System). Software that assists a human driver rather than replacing them: it can steer, accelerate, and brake, but the driver is still legally and practically in charge and can retake control at any moment. sunnypilot is an ADAS, specifically what the industry calls Level 2: continuous steering assistance (lane centering) plus speed/following-distance control (adaptive cruise), with the driver required to stay attentive.
CAN bus (Controller Area Network). The wiring and message protocol nearly every car has used since the 1990s to let its onboard computers talk to each other: the engine computer, the power steering computer, the brake computer, the instrument cluster, all read and write short numeric messages on a shared pair of wires. sunnypilot doesn't control a car by rewiring it; it controls a car by sending the same kind of CAN messages a human-operated steering wheel or gas pedal would normally cause.
ECU (Electronic Control Unit). Any one of those onboard computers on the CAN bus, e.g. the Electric Power Steering ECU is the one that actually turns the steering column.
comma's data model
Route, segment. A single recorded drive is a route; comma's tools split a route into
one-minute segments for storage and streaming. The demo route used throughout this workshop,
5beb9b58bd12b691/0000010a--a51155e496, has 16 segments, about 16 minutes of driving.
Dongle ID. The unique identifier comma's backend assigns to a physical device the first time it registers; you'll see it referenced in code that talks to comma's servers, but this workshop never needs a real one since everything here runs against local, already-downloaded data.
Talking between programs
Process. One running instance of a program. A running sunnypilot isn't one program: it's around 40 small, separate processes, each doing one job (reading the camera, running the driving model, computing steering commands, ...) and started/stopped independently. Module 1 covers this.
IPC (Inter-Process Communication). Any mechanism that lets separate processes exchange data. Since sunnypilot's processes are separate programs, none of them can call a function in another one directly the way two objects in the same program would; they have to use IPC.
Pub/sub (publish/subscribe). One common IPC pattern: a process publishes a named message without knowing or caring who (if anyone) is listening, and any number of other processes can subscribe to that name and receive a copy. This is the pattern sunnypilot's processes use almost exclusively. It's a deliberate design choice, not an accident: it means any process can be restarted, added, or removed without the others needing to know.
cereal. This codebase's name for both (a) the schema language and compiler (built on Cap'n Proto, an existing open-source serialization format) that defines what fields each named message type carries, and (b) the Python/C++ library that publishes and subscribes to them. Module 2 covers both halves.
msgq. The actual transport cereal's pub/sub API runs on: shared memory that multiple processes on the same machine can read and write directly, which is dramatically faster than sending data through the kernel's normal networking or file APIs. You don't call msgq directly in this workshop (cereal's Python API wraps it), but it's the reason pub/sub is fast enough here to run at up to 100 messages/second per channel.
The hardware boundary
panda. The name (yes, lowercase) of a small, separate microcontroller board that sits physically between the Linux computer running sunnypilot's processes and the car's CAN bus. Every command sunnypilot wants to send to the car passes through it. Module 5 covers why this separate, much simpler piece of hardware exists and what it's allowed to do that the Linux side cannot.
sunnypilot vs. openpilot
sunnypilot is a fork of comma.ai's openpilot: it starts from openpilot's codebase and process
architecture (everything in Modules 1-3 is openpilot, not a sunnypilot invention) and adds its
own layer of processes, safety-firmware code, and driver-facing behavior on top, kept in a
top-level sunnypilot/ directory so it stays distinguishable from the openpilot code it builds
on. Module 4's MADS state machine is the clearest example of that added layer: it doesn't exist
in stock openpilot at all.