opendbc: comma.ai's Python layer for talking to car CAN buses

What opendbc actually solves

opendbc addresses a specific problem: modern cars expose steering, gas, and brake actuation through CAN buses, but each brand uses different message formats and identifiers. The project collects DBC files that describe those formats, plus Python libraries to parse and build CAN messages, and a safety layer to enforce limits. The README states the goal is to support controlling steering, gas, and brakes on every car with LKAS and ACC interfaces since 2016. It is built for openpilot, comma.ai's open-source driver assistance system, but the README also mentions interest in reading and writing other vehicle data like EV charge status and door locks. The intended users are developers who want to port a new car to openpilot or build a vehicle management app on top of the same CAN access. It is not a generic OBD-II scanner; it assumes you have a comma four and a car harness to connect to two CAN buses.

How the pieces fit: DBC, CAN, car, safety

The repository is split into four directories that form a clear data flow. The opendbc/dbc directory holds DBC files, which are text databases that describe CAN message layouts: which signals exist, their bit positions, and their scales and offsets. The opendbc/can library parses those files and builds or decodes CAN messages. Above that, opendbc/car provides high-level Python classes like CarState and CarController that turn raw CAN data into meaningful values such as speed and steering angle, and generate actuation messages. The safety directory contains firmware for comma's panda hardware. The README explains that when a panda powers up with opendbc safety firmware, it defaults to SAFETY_SILENT mode, which forces the CAN buses silent. To send messages you must select a safety mode, and some modes like SAFETY_ALLOUTPUT are disabled in release firmware. That separation matters: the car-specific code is pure Python, while the safety enforcement runs on the panda, not on the host computer. That design keeps the safety critical path isolated from the application code, which is a deliberate trade-off given the project's focus on openpilot.

Getting it running: the test.sh path

The quick start is straightforward but not a simple pip install. The README recommends cloning the repository and running ./test.sh, which it describes as an all-in-one for dependency installation, compiling, linting, and tests, and it is what CI runs. The individual commands are pip3 install -e .[testing], scons -j8, unittest-parallel, and lefthook run lint. That means you need Python 3, a C compiler for scons, and the lefthook tool for git hooks. The build step compiles the safety firmware and possibly native extensions, so this is not a pure Python package yet. The roadmap lists pip install opendbc as a short term goal, which confirms that distribution is still incomplete. For a quick experiment, the examples directory includes small programs that read state and control steering, gas, and brakes, plus examples/joystick.py that lets you drive a car with a joystick. Those examples are the fastest way to see the API in action, but they require a connected car and a panda in the correct safety mode.

The car port process: what a new model requires

Porting a car is the core contribution workflow. The README describes a port as living entirely in opendbc/car/<brand>/, with files like carstate.py to parse CAN stream data, carcontroller.py to output control messages, fingerprints.py to identify car models by ECU firmware versions, and interface.py as the high level class. There is also radar_interface.py for cars with radar. The process starts with connecting a comma four and a car harness to two CAN buses, then recording a route with events like enabling LKAS and ACC and turning the steering wheel to its limits. You load that route in cabana, comma's CAN visualization tool, to reverse engineer the messages. The README notes that if similar cars are already compatible, much of the work is done. That is a realistic statement: porting is incremental, not from scratch. But it also means the quality of each port varies. The README mentions a support level that is communicated in the new car support docs, so not every port is complete. A basic port may only control steering, while a complete port adds longitudinal control, tuning, radar parsing, and fuzzy fingerprinting. That distinction is important for anyone evaluating whether a specific car is safe to use.

Safety model: the panda gate

The safety model is the most consequential part of opendbc for anyone not building openpilot. The README states that when a panda powers up with opendbc safety firmware, it defaults to SAFETY_SILENT mode, forcing the CAN buses silent. To send any messages, you must select a safety mode. Some modes, like SAFETY_ALLOUTPUT, are disabled in release firmware, so you have to compile and flash your own build to use them. That is a deliberate restriction: it prevents casual use of full actuation without understanding the risks. The safety modes optionally support controls_allowed, which blocks or allows a subset of messages based on a customizable state. This is not a software-only safety check; it runs on the panda microcontroller, separate from the Python code. For a vehicle management app that only reads data, you can stay in a read-only mode, but the README does not specify which mode that is. For any write operation, you must flash firmware and select a mode, which adds friction and requires hardware. The trade-off is clear: opendbc is not a library you can pip install and immediately send CAN messages on a laptop. It is tied to comma's hardware and safety philosophy.

Limitations and wrong-tool cases

The most obvious limitation is that opendbc only supports cars that have been ported. The README says the goal is to support every car with LKAS and ACC, but the supported cars list is the real gate. If your car is not there, you have to do the reverse engineering work yourself, which requires a comma four, a harness, and cabana. That is a high barrier for a hobbyist who just wants to read their car's speed. Another limitation is the build process: you need scons and a C toolchain, and the roadmap has pip install opendbc as an unfinished item. That means the API is not yet a clean Python package you can install from PyPI. The safety firmware is also compiled, so you cannot avoid the build step if you want to use the safety layer. For a pure data logging task, opendbc might be overkill; a simple CAN adapter and a DBC parser like cantools could suffice. But opendbc's car-specific interfaces give you high-level values, not just raw signals, which is useful if you want to know steering angle in degrees rather than a raw integer. The wrong tool case is any project that needs to work across many car models without per-model porting. opendbc will not magically understand a new car.

Alternatives: cantools and the openpilot stack

The closest alternative to opendbc's CAN parsing layer is cantools, a Python library that also reads DBC files and encodes or decodes CAN messages. The difference is scope and safety. cantools is a general purpose library with no car-specific logic and no safety firmware. You can use it with any CAN interface, like a SocketCAN or a USB adapter, and it does not enforce any safety model. opendbc's opendbc/can module does the same DBC parsing, but it is tightly coupled to the car-specific code in opendbc/car and the safety firmware in opendbc/safety. If you only need to parse a few CAN signals, cantools is lighter and easier to install. If you need high-level car state like speed and steering angle, or you want to send actuation messages with safety enforcement, opendbc provides that out of the box for supported cars. For actuation, the real alternative is openpilot itself, which uses opendbc internally. You could run openpilot directly instead of building your own control app on opendbc. That gives you a complete ADAS system, but it is far more complex than a library. opendbc sits between cantools and openpilot: more than raw parsing, less than a full driving system.

Maintenance and license reality

The repository is under the MIT license, which is permissive and allows commercial use, modification, and redistribution with attribution. That is a low friction license for a vehicle management app, but it does not come with any warranty, which matters when you are sending actuation commands to a car. The project is actively maintained, with releases in early 2026 and a recent push in April 2026, so it is not abandoned. However, the maintenance cost is on you if you use it outside openpilot. The README states all development is coordinated on GitHub and Discord, and contributions are welcome, but there is no guarantee of long term API stability. The roadmap includes refactors and tooling to make car ports easier, which means interfaces may change. If you build a product on opendbc, you should pin a version and track changes. The safety firmware is compiled and flashed to a panda, so updating opendbc may require updating the firmware, and you must ensure the safety modes you use are still enabled in release builds. The README explicitly says some modes are disabled in release firmware, so a future release could disable a mode you rely on. That is a concrete maintenance risk to verify before adoption.

Editorial conclusion

Adopt opendbc if you are porting a car for openpilot, building a vehicle management app on supported hardware, or need a Python library for CAN parsing with a safety model. Skip it if you want a general-purpose OBD-II tool or a plug-and-play API for every car model, since support depends on community ports and the safety firmware must be flashed to a panda. Before committing, verify your car model is in the supported cars list, confirm your hardware (comma four, panda) is available, and review the safety mode you plan to use, because release firmware disables some modes like SAFETY_ALLOUTPUT.

Official sources

1. Official README
2. Project repository
3. Release notes