Skip to main content

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.

comma.ai develops openpilot as open-source software so that anyone can solve their own problems and, when they’re ready, share those solutions with the entire community. Development is coordinated through Discord and GitHub. Whether you write code, drive regularly, or report problems you encounter, there are meaningful ways to contribute.

​
What openpilot prioritizes

openpilot’s priorities are safety, stability, quality, and features — in that order. All development is in service of comma’s mission to solve self-driving cars while delivering shippable intermediaries. Pull requests that don’t advance that mission, regardless of effort, are unlikely to be merged.

​
What gets merged

The probability of a PR being merged depends on two things: the value it delivers and the effort required to review and land it. Simple, well-tested bug fixes are the easiest to get merged. New features are the hardest.

Typo and doc fixes

Small, precise, and easy to review. An excellent first contribution. Example PR

Removing unused code

Keeps the codebase clean with low risk. Example PR

Simple car model ports

Extends openpilot support to more vehicles with minimal surface area. Example PR

Car brand ports

Broader vehicle support with well-scoped, testable changes. Example PR

​
What doesn’t get merged

If a PR offers some value but will take significant effort to review and land, it will be closed. Focus on scope and clarity.
  • Style changes — Code is art; it’s up to the author to make it beautiful. Style-only PRs will be closed.
  • 500+ line PRs — Break large changes into smaller, focused PRs.
  • PRs without a clear goal — Every PR must have a single, well-defined purpose.
  • UI design changes — There is no reliable review process for this yet.
  • New features — openpilot is considered mostly feature-complete. Most feature PRs are closed immediately. Forks can and do offer features that upstream openpilot doesn’t.
  • Negative expected value PRs — Changes where the risk or validation cost exceeds the benefit. The risk can sometimes be mitigated by getting a failing test merged first.

​
Your first contribution

openpilot bounties is the best starting point. The project goes into detail on expectations when working on a bounty. Many bounties don’t require a comma device or a car — they’re approachable from a standard development environment.
Set up your development environment before starting on a bounty. The tooling makes it much easier to test your changes.

​
Pull request requirements

Pull requests should target the master branch. A good PR includes all of the following:
1

Clearly stated purpose

The PR description explains exactly what the change does and why.
2

Focused changes

Every line changed directly contributes to the stated purpose. No unrelated edits.
3

Verification

Describe how you tested the change. For tuning improvements, include before and after plots. For performance changes, include benchmarks.
4

Justification

If you’ve optimized something, post benchmarks. If you’ve improved car tuning, post before/after comparisons.
5

CI passing

All continuous integration tests must pass before the PR can be reviewed.

​
Contributing without code

Code contributions aren’t the only way to improve openpilot. The following all have a real impact on the quality of the software:

Bug reports

Report software bugs in GitHub Issues. Report driving problems in the #driving-feedback channel on Discord.

Driver camera uploads

Opt into driver camera uploads from your comma device settings. This data directly improves the driver monitoring model.

Training data

Connect your device to Wi-Fi regularly so comma can pull route data for training better driving models.

Data annotation

Annotate images in the comma10k dataset to improve perception model training.
You can also run the nightly branch and report any issues you encounter. This branch is built the same way as a release, making it a good signal for pre-release quality.

​
Contributing training data (for forks)

If you maintain a fork and want your data to be eligible for the training set, three rules apply:
  • Your cereal messaging structs must be compatible with upstream.
  • Do not change how any stock messaging fields are set — including selfdriveState.enabled or carState.steeringAngleDeg. Create your own structs for custom behavior.
  • Do not include cars that aren’t supported in upstream platforms. Create new opendbc platforms for vehicles you want to support outside of upstream.

Build docs developers (and LLMs) love

Get started for freeTalk to us