opendbc: the Python API and DBC repository behind openpilot car support

What opendbc actually solves, and for whom

Most cars sold since 2016 expose electronically actuatable steering, gas and brakes, because lane keeping and adaptive cruise control forced manufacturers to put those actuators on the CAN bus. The README states the goal plainly: support controlling steering, gas and brakes on every one of those cars. That is a narrower and more mechanical goal than "a Python API for your car" suggests, and it explains the shape of the repository.

The audience is correspondingly narrow. If you are porting a vehicle to openpilot, adding longitudinal control to a car that only has lateral support, or parsing radar frames, opendbc is the layer you work in. If you want to read your EV charge status from a laptop, the README says the project is interested in that too, but the examples directory contains a joystick controller and a keyboard helper, not a vehicle management app. The ambition is stated; the tooling for it is not there yet.

The four layers: DBC files, CAN parsing, car interface, safety

The repository splits into four directories, and understanding which one you are touching determines how much work you have signed up for.

`opendbc/dbc/` is a repository of DBC files, the standard CAN database format that maps message IDs and bit positions to named signals. `opendbc/can/` is a library for parsing and building CAN messages from those DBC files. `opendbc/car/` is the high-level Python interface to a car. `opendbc/safety/` is the functional safety layer for every car the high-level library supports.

A car port lives entirely in `opendbc/car/<brand>/`. The README lists the files: `carstate.py` parses relevant information from the CAN stream using the car's DBC file, `carcontroller.py` outputs CAN messages to control the car, `<brand>can.py` holds thin Python helpers around the DBC file to build messages, `fingerprints.py` is a database of ECU firmware versions used to identify car models, `interface.py` is the high-level class, `radar_interface.py` parses radar, and `values.py` enumerates the brand's supported cars. That is a real architectural commitment: the data flow runs from raw CAN frames, through DBC-driven decoding, into a brand-specific state object, and back out through a controller that builds frames the safety layer will permit.

Installing opendbc and running the joystick example

The README gives a quick start that clones the repository and runs `test.sh`, described as an all-in-one for dependency installation, compiling, linting and tests, and as what runs in CI. The individual commands it wraps are listed separately. Note the extra index: the project's own docs say `pip3 install -e .[testing]`, not a plain install from PyPI, and the roadmap still carries `pip install opendbc` as an unchecked item.

git clone https://github.com/commaai/opendbc.git
cd opendbc

# all-in-one: dependencies, compiling, linting, tests
./test.sh

# the individual commands it runs
pip3 install -e .[testing]
scons -j8
unittest-parallel
lefthook run lint

The build step is `scons -j8`, which compiles the native pieces; the Python package alone is not the whole story. Python version matters here, and `pyproject.toml` pins it explicitly.

requires-python = ">=3.11,<3.13"  # pycapnp doesn't work with 3.13

For a first real use, the README points at `examples/`, which it describes as small example programs that can read state from the car and control steering, gas and brakes. `examples/joystick.py` lets you control a car with a joystick, and `examples/kbhit.py` is the keyboard helper alongside it. The `examples` optional dependency group in `pyproject.toml` contains `inputs`, the package that reads a joystick or keyboard, so that is the extra to install if you want to run those scripts rather than the test suite. What you should expect to see is a program that connects to a car over the harness, reads state, and sends actuation commands; what you should not expect, based on the README, is a simulator or a recorded-route playback path described in the quick start.

The safety firmware is the part that will stop you

This is the limitation that matters most, and it is documented rather than hidden. When a panda powers up with the opendbc safety firmware, it is in `SAFETY_SILENT` mode by default, and in that mode the CAN buses are forced to be silent. To send anything at all you must select a safety mode. Some modes, `SAFETY_ALLOUTPUT` among them, are disabled in release firmware, so using them requires compiling and flashing your own build.

Safety modes optionally support `controls_allowed`, which permits or blocks a subset of messages based on a state in the board. The README describes the safety firmware as written for use with openpilot and panda, enforcing the openpilot safety model, and says the code rigor inside `safety/` is held to high standards because of that critical function. Read that as a design boundary: opendbc is not a general purpose CAN toolkit that happens to ship a safety module. The safety module defines what the rest of the stack is allowed to do, and it assumes openpilot is the thing asking.

The second limitation is scope. The README states that a car port at its most basic controls steering, and that a complete port has lateral control, longitudinal control, tuning for both, radar parsing if equipped, and fuzzy fingerprinting. Porting is a graduated effort, and the supported cars list in `docs/CARS.md` is where the actual support level per vehicle lives. If your car is not in that list, nothing in the Python API helps you until someone does the CAN reverse engineering.

opendbc versus using a generic DBC or CAN tool directly

The obvious alternative for someone who only wants to decode a CAN bus is to load a DBC file into a general CAN analysis tool and read frames, skipping opendbc's Python layer entirely. The difference in approach is what you get on top of the DBC file. A generic tool gives you signal decoding and a trace view. opendbc gives you a parser built around DBC files, plus brand-specific state and control classes that already know which messages to send and in what sequence, plus the safety firmware that decides whether sending them is permitted.

That trade goes both ways. The generic route works on any bus, any brand, with no repository to clone and no safety mode to select. The opendbc route only pays off where `opendbc/car/<brand>/` exists, and it drags the panda and the safety model along with it. For reverse engineering a new car, the README actually points away from opendbc itself and toward cabana for loading and inspecting a recorded route. opendbc is where the result of that work lands, not where it starts.

Maintenance, licensing and the cost of upgrading

The repository is not archived. The last push was on 2026-04-22, roughly five months before this writing, and it carried release v0.3.1 on the same day, with v0.3.0 earlier that same day and v0.2.1 back on 2025-02-11. That release cadence is worth reading carefully: two patch and minor releases within an hour in April 2026, then nothing in the four months since. It is a burst pattern, not a steady drip.

The upgrade cost is dominated by the car ports rather than the library. Version 0.3.1 is what `pyproject.toml` declares, so the package version tracks the release tag, but the meaningful churn is in `opendbc/car/<brand>/` files and in the safety firmware, both of which are coupled to openpilot behaviour. If you vendor a port, expect to re-read it after an upgrade. The Python constraint (`>=3.11,<3.13`) is the other hard edge, and the comment in `pyproject.toml` gives the reason: pycapnp does not work with 3.13. That is a dependency ceiling you inherit.

Licensing is MIT, declared both in the repository and in `pyproject.toml` as `license = "MIT"`. MIT is permissive, so redistributing modified source is straightforward. That said, the safety firmware's role is to enforce the openpilot safety model, and the README ties it to that use; if you are building something that actuates a vehicle, the licence tells you what you may copy, not what you may safely deploy. That question is outside the scope of the licence text and outside the scope of this article.

Editorial conclusion

Adopt opendbc if you are porting a car to openpilot or writing tooling against its DBC files and CAN parser; the safety firmware and the brand-by-brand port layout only make sense in that context. Do not adopt it if you want a stable, versioned API for a production fleet app: the README calls itself the docs and the roadmap still lists `pip install opendbc` as unfinished, so the public surface is still moving. Before committing, verify three things: that your car brand has a directory under `opendbc/car/`, that a harness for it exists or that you can crimp a developer harness, and that the DBC file for your platform actually decodes the signals you need. If the brand directory does not exist, you are writing a port, not integrating a library, and the effort is measured in weeks of cabana sessions.

Frequently asked questions

Official sources

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