The Problem
Modern vehicles ship with driver assistance systems that are locked down by the manufacturer. Users cannot extend, modify, or improve them. openpilot replaces that closed system with an open-source, self-driving stack that runs on a dedicated device (comma 3X) and interfaces with the car's existing sensors and controls via a harness.
What This Does
openpilot is a robotics operating system that upgrades the driver assistance system in 300+ supported cars. It reads vehicle state through cereal/car.capnp, processes it through the selfdrive/ and common/ modules, and outputs control commands back to the car. The cereal/ directory defines the message schemas; common/ holds shared utilities (params, logging, transformations, filtering); docs/ contains the integration and safety documentation.
The build system is SCons (SConstruct, selfdrive/SConscript) with Docker images (Dockerfile.openpilot, Dockerfile.openpilotbase) for reproducible builds. CI runs through GitHub Actions (.github/workflows/tests.yaml) and a Jenkins pipeline (Jenkinsfile). The repo uses git submodules (opendbc, rednose, msgq) for car definitions, Kalman filtering, and messaging.
How To Use It
Setup: Install on a comma 3X device by entering openpilot.comma.ai as the custom software URL during device setup. For development, clone the repo and build with Docker.
Configuration: No environment variables required for basic use. Car-specific definitions live in the opendbc submodule. For development, pyproject.toml declares Python dependencies; install with pip or uv.
Running it: The device runs openpilot automatically on boot. For development, the entry point is launchopenpilot.sh:
On a comma device or Linux with the proper setup ./launchopenpilot.sh
The repo does not document a local development run command outside the device. The README only provides the device install command: bash <(curl -fsSL openpilot.comma.ai).
Real-World Use
A user installs openpilot on a comma 3X, plugs it into a supported car via the harness, and the system handles longitudinal and lateral control on highways. The docs/CARS.md file lists supported vehicles. For developers, the workflow is: modify a car port in opendbc, rebuild with SCons, run the test suite (common/tests/, cereal/messaging/tests/), and submit a PR. CI runs model validation and hardware-in-the-loop tests before merge.
Code Health & Issues
Med - No dependency lockfile - pyproject.toml declares dependencies but no lockfile exists, so builds are not fully reproducible across time. The Docker images mitigate this for the device, but local dev environments may drift. Low - Large monorepo with submodules - opendbc, rednose, and msgq are git submodules. A shallow clone or a missing --recursive flag breaks the build. The .gitmodules file exists but there is no documented fallback. Low - Safety-critical code with limited test coverage - selfdrive/ contains only 2 files in this snapshot, suggesting the core driving logic may live in submodules or generated code. The visible tests cover utilities and messaging, not the full driving stack. Good - CI and documentation are present - 20 test files, 35 doc files, and a full GitHub Actions workflow set indicate a mature project. The docs/SAFETY.md and docs/DEBUGGINGSAFETY.md files show explicit attention to the safety-critical nature of the code.
The Bottom Line
openpilot is a serious, well-maintained open-source project with real-world deployment on thousands of vehicles. The codebase is large and modular, but the lack of a lockfile and the reliance on submodules make local development setup non-trivial. It is best suited for developers already familiar with the comma ecosystem or those willing to invest time in the build system. For end users, the device-based install is straightforward.