commaai/openpilot / Chapter 1

Programming /

E00_Three_Hundred_and_Thirty_Two_Cars_One_Loop

# Three Hundred and Thirty-Two Cars, One Loop > openpilot is not a car app bolted onto the dashboard. It is an operating system whose 100 Hz control loop happens to drive a steering wheel. Three hundred and thirty-two. That is the number you will find in `docs/CARS.md` if you scroll past the autogenerated header. Three hundred and thirty-two supported cars. The README rounds down to "300+", the marketing copy rounds up to "more supported vehicles than any other open-source ADAS project in the world", and neither of those framings is wrong. But neither of them is the right one either. The right framing is that **the 332 figure is a measure of how thinly comma has abstracted the boundary between its software and the wildly different ADAS APIs it speaks to**. That abstraction is the OS metaphor, taken seriously. Not a metaphor in the loose sense — comma actually calls the thing an "operating system for robotics" on the front page of its repository, and the codebase is engineered as if it meant it. A process orchestrator with a safety kernel. A pub/sub bus on which car-specific daemons can be hot-swapped. A package manager that delivers four parallel release trains (`release-mici`, `release-tizi`, `nightly`, `nightly-dev`) to two device classes (the comma 3X and the newer comma four). If you have ever used a Unix system whose kernel is the smallest possible trusted computing base, and whose userland is where all the interesting — and replaceable — work happens, you already have the mental model. openpilot's `panda` firmware is the kernel. The Python `selfdrived` daemon is `init`. The car-specific firmware ports are drivers. I want to spend the next five chapters inside that mental model. Not because it is fashionable to call consumer products "operating systems" — that label gets slapped on everything from microwaves to toothbrushes these days — but because, in the case of openpilot, **the architecture only becomes legible once you stop thinking of it as a single program and start thinking of it as a small distributed system that happens to live in a windshield-mounted compute box**. Once you do, the seemingly strange design choices — why is there a separate process for everything? why are messages serialized through Cap'n Proto? why does the safety-critical code live in C while the rest lives in Python? — fall out as the obvious answers to the obvious questions. Let me set the scene with the most concrete fact I have. Imagine you are at the comma.ai site, picking a harness for your 2018 Honda Civic. The dropdown knows your car. The dropdown knows the part numbers of the three connectors you need, the OBD-C cable length that fits between the dashboard and the comma four, and which firmware branch your car is currently happiest with. That dropdown is the visible top of the OS. Below it: a per-car fingerprinting module that detects your make, model, and trim from the CAN bus traffic, then negotiates the right process configuration, then engages a state machine that is — and I will get into this in E02 — formally too simple to be wrong. That is the bet comma has made: **the cars are drivers, the user is just a privileged process, and the code that talks to the steering wheel is the smallest, most boring, most thoroughly tested layer in the stack**. This is the rare open-source robotics project where the marketing line happens to be the engineering line. Most open-source projects in this space either over-promise (full self-driving) or under-promise (just a visualization library). openpilot promises what it ships: it upgrades the driver assistance system on 332 cars. It does so via a specific, well-bounded, ISO 26262-obsessed design that, if you read the code, has the same texture as a Postgres or an nginx — unglamorous, well-factored, and quietly handling the kind of system that breaks careers when it fails. The 332 number is the proof that the abstraction holds. Here is what I will show you, in order. **E01** opens up the process architecture. We will look at the

Chapter 1 of 5 7m Article Learning path

Three Hundred and Thirty-Two Cars, One Loop

openpilot is not a car app bolted onto the dashboard. It is an operating system whose 100 Hz control loop happens to drive a steering wheel.

Three hundred and thirty-two. That is the number you will find in docs/CARS.md if you scroll past the autogenerated header. Three hundred and thirty-two supported cars. The README rounds down to "300+", the marketing copy rounds up to "more supported vehicles than any other open-source ADAS project in the world", and neither of those framings is wrong. But neither of them is the right one either. The right framing is that the 332 figure is a measure of how thinly comma has abstracted the boundary between its software and the wildly different ADAS APIs it speaks to.

That abstraction is the OS metaphor, taken seriously. Not a metaphor in the loose sense — comma actually calls the thing an "operating system for robotics" on the front page of its repository, and the codebase is engineered as if it meant it. A process orchestrator with a safety kernel. A pub/sub bus on which car-specific daemons can be hot-swapped. A package manager that delivers four parallel release trains (release-mici, release-tizi, nightly, nightly-dev) to two device classes (the comma 3X and the newer comma four). If you have ever used a Unix system whose kernel is the smallest possible trusted computing base, and whose userland is where all the interesting — and replaceable — work happens, you already have the mental model. openpilot's panda firmware is the kernel. The Python selfdrived daemon is init. The car-specific firmware ports are drivers.

I want to spend the next five chapters inside that mental model. Not because it is fashionable to call consumer products "operating systems" — that label gets slapped on everything from microwaves to toothbrushes these days — but because, in the case of openpilot, the architecture only becomes legible once you stop thinking of it as a single program and start thinking of it as a small distributed system that happens to live in a windshield-mounted compute box. Once you do, the seemingly strange design choices — why is there a separate process for everything? why are messages serialized through Cap'n Proto? why does the safety-critical code live in C while the rest lives in Python? — fall out as the obvious answers to the obvious questions.

Let me set the scene with the most concrete fact I have. Imagine you are at the comma.ai site, picking a harness for your 2018 Honda Civic. The dropdown knows your car. The dropdown knows the part numbers of the three connectors you need, the OBD-C cable length that fits between the dashboard and the comma four, and which firmware branch your car is currently happiest with. That dropdown is the visible top of the OS. Below it: a per-car fingerprinting module that detects your make, model, and trim from the CAN bus traffic, then negotiates the right process configuration, then engages a state machine that is — and I will get into this in E02 — formally too simple to be wrong. That is the bet comma has made: the cars are drivers, the user is just a privileged process, and the code that talks to the steering wheel is the smallest, most boring, most thoroughly tested layer in the stack.

This is the rare open-source robotics project where the marketing line happens to be the engineering line. Most open-source projects in this space either over-promise (full self-driving) or under-promise (just a visualization library). openpilot promises what it ships: it upgrades the driver assistance system on 332 cars. It does so via a specific, well-bounded, ISO 26262-obsessed design that, if you read the code, has the same texture as a Postgres or an nginx — unglamorous, well-factored, and quietly handling the kind of system that breaks careers when it fails. The 332 number is the proof that the abstraction holds.

Here is what I will show you, in order.

E01 opens up the process architecture. We will look at the actual subscription list that the central selfdrived daemon registers — the 20+ pub/sub services it reads at 100 Hz — and I will argue that the process boundary is the fault boundary, which is the entire reason the codebase looks the way it does.

E02 is the safety chapter. openpilot enforces two top-level safety requirements (the driver must always be able to retake control; the vehicle must not change trajectory faster than the driver can react) with three independent defensive layers (state machine, excessive-actuation watchdog, driver monitoring) and a fourth social layer (the fork policy). I will walk through the actual Python code of ExcessiveActuationCheck and show you what 2× the maximum allowed lateral acceleration looks like, in a real curve, on a real car.

E03 is the most consequential chapter. In August 2025, version 0.10.0 replaced longitudinal Model Predictive Control with an end-to-end plan produced by a "World Model" — the same architecture described in a CVPR paper — and quietly changed the lateral training objective too. I will argue that this is the most important architectural change in the project's history, and that it is more conservative than it sounds, because the E2E model is being trained on a closed-loop simulator that has internalized millions of minutes of human driving, and the safety kernels I describe in E02 still gate everything the model is allowed to do.

E04 is the synthesis. Every minute of your drive produces a 50+ MB artifact (a rlog.zst plus three H.265 camera streams) that retrains the next release. The roadmap to "openpilot 1.0 — fully end-to-end driving policy" is the closed loop made explicit. I will trace a single minute of your drive from the camera to the cloud to the gradient to the next OTA.

If you are a software engineer, the chapters that will interest you most are E01 (the architecture) and E03 (the ML pivot). If you are a safety auditor, E02 is your chapter — bring a red pen. If you are a strategist, E04 will change how you think about Tesla FSD, GM Super Cruise, and the rest of the consumer AV market, because the openpilot data flywheel is a fundamentally different economic engine from any of them.

One last thing before we start. The README has a paragraph in fine print that says, in effect: "this is alpha quality software for research purposes only, this is not a product, you are responsible for complying with local laws, no warranty expressed or implied". The authors mean it. openpilot is built in a regulatory environment where "we shipped a feature" and "we got a person killed" can be the same sentence, and the codebase is shaped by that reality in ways I will point out at every opportunity. I am not going to argue with the disclaimer. I am going to show you why the people who wrote that disclaimer wrote the code they did.

The install surface, drawn

The simplest possible picture of what a user touches — what hardware, what software, what car, what wire — is also the picture that explains why this thing ships on 332 cars instead of one.

flowchart LR
    User[Driver] -->|buys| Hardware[comma 3X or comma four]
    Hardware -->|boots into| Branch[release-mici / release-tizi / nightly / nightly-dev]
    Branch -->|loads| OS[openpilot process tree]
    Car[One of 332 supported cars] -->|CAN bus traffic| Panda[panda safety kernel C]
    Panda -->|validated commands| Car
    CarHarness[Car-specific harness] --> Hardware
    Hardware --> CarHarness
    OS -->|reads| Panda
    OS -->|engages| Controls[controlsd + plannerd]
    Controls -->|via Panda| Car

The four corners of that diagram are what the comma.ai storefront sells. Everything inside the box is what the GitHub repository ships. The fact that the boundary between them is also the boundary between a closed-source commercial product and a permissive open-source codebase — and that you, the user, type openpilot.comma.ai into a setup URL to install the latter onto the former — is the second non-obvious thing about the project. The first non-obvious thing is the 332.

A quick sanity check on the 332

If 332 supported cars seems like a marketing-driven round number, look at the structure of the list. It is autogenerated from a per-platform file under openpilot/selfdrive/car/, which means the underlying data is whatever the community porters have spent years reverse-engineering per car. The Acura MDX 2022-24 entry credits mvl-boston. The Rivian R1S and R1T 2025 entry credits lukasloetkolben. The Ford F-150 2021-23 entry is in the file. The comma body — comma's own robotaxi prototype — is in the file as comma body All openpilot. Three hundred and thirty-two is not a press-release figure. It is the count of platforms whose CAN bus someone has personally taught the project how to speak to, with credit, in a public changelog, for a hardware product that costs less than a replacement bumper on most of those cars.

I will be specific about one platform because it sets up the rest of the series. The Honda Accord 2018-22 line in CARS.md reads: All | openpilot available | 0 mph | 3 mph | star | star | Hardware: 1 Honda Bosch A connector, 1 OBD-C cable, 1 comma four, 1 comma power v3, 1 harness box, 1 mount. Six parts. A 2018 Honda Civic is the same family. The cost of entry, including the comma four, is in the low four figures. The engineering that lets those six parts replace the stock Honda Sensing on a 7-year-old Accord is what the next four chapters unpack.

Three hundred and thirty-two cars. One loop. Let's open the loop.

---

References: