A car port enables openpilot support on a particular vehicle. Each car model openpilot supports must be individually ported, and the complexity varies based on factors like whether the brand is already supported and what APIs the car exposes. All car-specific code lives in the opendbc project, a separate repository that openpilot depends on.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/commaai/openpilot/llms.txt
Use this file to discover all available pages before exploring further.
Brand port vs. model port
There are two distinct types of car ports, and understanding the difference is important before you start. Brand port — A port to a substantially new car brand or platform. Brand ports require implementing the full interface from scratch: reading CAN messages, writing control messages, defining safety logic, and authoring tests. These are the most complex contributions. See this example PR for a complete brand port. Model port — A port to a new car model within an already-supported brand. Because the brand’s CAN bus APIs are already understood, model ports are significantly simpler — often requiring only additions tovalues.py and minor adjustments to existing files. See this example PR for a model port.
Structure of a car port in opendbc
Each supported car brand lives underopendbc/car/[brand]/ and follows a standard file layout:
| File | Purpose |
|---|---|
interface.py | Defines the CarInterface class; the primary entry point for the car |
carstate.py | Reads CAN messages from the car and builds openpilot CarState messages |
carcontroller.py | Executes openpilot CarControl actions by sending CAN messages to the car |
[brand]can.py | Composes raw CAN messages for carcontroller.py to send |
values.py | Actuation limits, general constants, and the list of supported car platforms |
radar_interface.py | Parses radar point data from the car, if the car has a supported radar |
Safety files
Safety is openpilot’s top priority. Every brand requires safety logic implemented in C and a corresponding Python test suite:opendbc/safety/modes/[brand].h— Brand-specific safety constraints, enforced in the panda firmwareopendbc/safety/tests/test_[brand].py— CI tests that verify the safety logic
openpilot-specific file
For historical reasons, a small amount of car-specific logic remains in openpilot itself. This will eventually be migrated to opendbc.selfdrive/car/car_specific.py— Brand-specific event logic (e.g., custom fault handling)
Porting process
Jason Young gave a talk at COMMA_CON covering the full car porting process. It is highly recommended viewing before you start: Watch the COMMA_CON car porting talk on YouTubeDetermine the port type
Check the list of supported cars to see if the brand is already supported. If the brand exists, you are doing a model port. If not, you are doing a brand port.
Understand the car's CAN bus
Use cabana and a comma device or panda to capture and decode CAN messages from the car. Identify the messages for steering, braking, throttle, and speed.
Create the opendbc files
Fork opendbc and create
opendbc/car/[brand]/. Implement interface.py, carstate.py, carcontroller.py, values.py, and (if applicable) radar_interface.py.For a model port, you typically only need to add a new entry to values.py and adjust carstate.py or carcontroller.py as needed.Implement safety logic
Write
opendbc/safety/modes/[brand].h with safety constraints appropriate for the car’s actuation limits. Safety code is reviewed strictly — review existing safety files for the expected patterns and constraints.Write safety tests
Create
opendbc/safety/tests/test_[brand].py to test the safety logic you implemented. All safety tests must pass in CI before a PR can be merged.Update openpilot if needed
If the car requires custom event logic, add it to
selfdrive/car/car_specific.py in the main openpilot repository.Test on hardware
Test your port with a comma device installed in the car. Verify that lateral and longitudinal control work correctly and that the car engages and disengages as expected.
Open a pull request
Submit separate PRs to opendbc and openpilot. Each PR must have a clearly stated purpose, explain how you tested it, and pass all CI checks. See CONTRIBUTING.md for PR guidelines.
The openpilot bounties board lists car ports that the comma team is actively interested in. Working on a bounty is a good way to ensure your port has a clear path to being merged.