opendbc von comma.ai: Eine Python-API für Gas, Bremse und Lenkung im Fahrzeug
eine Python-API für Ihr Auto. Während der Hauptschwerpunkt auf der Unterstützung von ADAS-Schnittstellen für openpilot liegt, sind wir auch daran interessiert, so viele Dinge wie möglich zu lesen und zu schreiben (Ladestatus des Elektrofahrzeugs, Türen ver-/entriegeln usw.), damit wir die beste Fahrzeugmanagement-App aller Zeiten entwickeln können.
Auf einen Blick
- Was ist das?
- Was das opendbc-README über die Python-Schnittstelle zum Steuerbus des Autos sagt: Projektaufbau, Portierung neuer Fahrzeuge, Sicherheitsfirmware und Entwicklungsworkflow.
- Für wen ist es gedacht?
- opendbc richtet sich an Entwickler, die CAN-Nachrichten von Fahrzeugen mit LKAS und ACC per Python lesen und schreiben wollen, insbesondere als Grundlage für openpilot-Car-Ports. Wer nur Daten aus dem Fahrzeugbus auslesen will, findet in opendbc/can/ und den examples/ einen Einstieg; wer Lenkung oder Bremse steuern will, muss die Sicherheitsfirmware in opendbc/safety/ und deren CI-Regressionstests verstehen, bevor Hardware angesprochen wird.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ziel des Projekts: jeder LKAS- und ACC-Fahrzeugtyp als Python-Ziel
opendbc beschreibt sich im README als eine Python-API für das eigene Auto, mit der sich Gas, Bremse und Lenkung steuern sowie Geschwindigkeit und Lenkwinkel auslesen lassen. Der Ausgangspunkt ist laut README, dass die meisten Autos seit 2016 über LKAS und ACC elektronisch ansteuerbare Lenk-, Gas- und Bremsaktoren haben; das Projekt will genau diese Ansteuerung für jeden einzelnen dieser Wagen unterstützen.
Der Schwerpunkt liegt auf den ADAS-Schnittstellen für openpilot, doch die Betreiber schreiben, dass sie zusätzlich so viele Zustände wie möglich lesen und schreiben wollen, etwa den Ladestatus von E-Autos oder das Ver- und Entriegeln von Türen, mit dem langfristigen Ziel einer Fahrzeugverwaltungs-App. Laut README sind das README selbst und die unterstützte Fahrzeugliste in docs/CARS.md die gesamte Dokumentation des Projekts; alles zu Nutzung, Beitrag und Erweiterung stecke in diesen beiden Quellen. Das Repository zählt zum Erfassungszeitpunkt 3368 Sterne und 2193 Forks bei 342 offenen Issues und steht unter der MIT-Lizenz.
Projektaufbau von opendbc/dbc/ bis opendbc/safety/
Das README gliedert den Code in vier Verzeichnisse. opendbc/dbc/ ist eine Sammlung von DBC-Dateien, also der CAN-Datenbankdateien, die Signale im Fahrzeugbus beschreiben. opendbc/can/ ist eine Bibliothek zum Parsen und Aufbauen von CAN-Nachrichten auf Basis dieser DBC-Dateien. opendbc/car/ bildet die hochgradige Python-Bibliothek zur Anbindung der Fahrzeuge, und opendbc/safety/ enthält die funktionale Sicherheit für alle Autos, die opendbc/car/ unterstützt.
Ein Car-Port lebt vollständig unter opendbc/car/<marke>/ und folgt einer festen Struktur: carstate.py parst die relevanten Informationen aus dem CAN-Strom anhand der DBC-Datei des Wagens, carcontroller.py erzeugt die CAN-Nachrichten zur Steuerung, <brand>can.py bietet dünne Python-Hilfsfunktionen um die DBC-Datei, fingerprints.py führt eine Datenbank der ECU-Firmware-Versionen zur Erkennung der Fahrzeugmodelle, interface.py ist die übergeordnete Klasse, radar_interface.py parst das Radar, und values.py listet die unterstützten Modelle der Marke auf.
Quick start: ./test.sh als All-in-one-Einstieg
Der dokumentierte Einstieg beginnt mit git clone https://github.com/commaai/opendbc.git und cd opendbc. Das README empfiehlt dann ./test.sh als Sammelbefehl, der Abhängigkeitsinstallation, Kompilierung, Linting und Tests abdeckt und auch in der CI läuft. Wer die Einzelschritte sehen will, findet sie im README: pip3 install -e .[testing] installiert die Abhängigkeiten, scons -j8 baut mit acht Kernen, unittest-parallel führt die Tests aus, und lefthook run lint startet den Linter.
Für erste Experimente ohne eigene Hardwarelogik gibt es das Verzeichnis examples/ mit kleinen Beispielprogrammen, die Zustände aus dem Auto lesen und Lenkung, Gas und Bremse ansteuern können. Ausdrücklich genannt wird examples/joystick.py, mit dem sich ein Fahrzeug per Joystick kontrollieren lässt. Wie das praktisch abgesichert abläuft, regelt das Sicherheitsmodell: Die Firmware auf dem panda startet standardmäßig im Modus SAFETY_SILENT, in dem die CAN-Busse stummgeschaltet sind, und erst die Wahl eines Sicherheitsmodus erlaubt das Senden von Nachrichten.
Car-Port anlegen: comma four, Kabelbaum und CAN-Mitschnitt
Der Leitfaden zum Portieren eines Autos deckt laut README alles ab, vom Hinzufügen eines neuen Modells bis zur Verbesserung bestehender Wagen, etwa durch Längsregelung oder Radar-Parsing. Wenn ähnliche Fahrzeuge bereits kompatibel sind, ist ein großer Teil der Arbeit schon erledigt. Ein grundlegender Port steuert zunächst nur die Lenkung; ein vollständiger Port umfasst Quer- und Längsregelung, gute Abstimmung für beide, Radar-Parsing falls vorhanden, Fuzzy-Fingerprinting und mehr. Der Unterstützungsumfang je Fahrzeug wird in den Dokumenten klar ausgewiesen.
Der erste Schritt ist die physische Verbindung über einen comma four und einen Kabelbaum fürs Auto, der an zwei CAN-Busse anschließt und einen davon aufspaltet, um eigene Aktuationsnachrichten einzuspeisen. Ist für das eigene Modell kein Kabelbaum im comma.ai/shop vorhanden, beginnt man laut README mit einem Developer-Harness und crimpt den benötigten Stecker selbst. Zum Reverse Engineering von CAN-Nachrichten empfiehlt das README, eine Fahrt mit vielen interessanten Ereignissen aufzunehmen, etwa dem Einschalten von LKAS und ACC und dem Durchdrehen des Lenkrads an beide Anschläge, und diese Route dann in cabana zu laden. Für die Längsabstimmung gibt es den Bericht der longitudinalen Manöver.
Sicherheitsmodell: SAFETY_SILENT, controls_allowed und Release-Einschränkungen
Das Sicherheitsmodell ist präzise beschrieben: Startet ein panda mit der opendbc-Sicherheitsfirmware aus opendbc/safety/, befindet er sich standardmäßig im Modus SAFETY_SILENT, in dem die CAN-Busse zum Senden gezwungen werden, still zu bleiben. Nachrichten gehen erst heraus, wenn ein Sicherheitsmodus gewählt wird. Einige Modi, als Beispiel nennt das README SAFETY_ALLOUTPUT, sind in Release-Firmwares deaktiviert; wer sie nutzen will, muss seine eigene Firmware kompilieren und flashen.
Sicherheitsmodi unterstützen optional controls_allowed, einen einstellbaren Zustand auf dem Board, der je nach Einstellung eine Teilmenge der Nachrichten erlaubt oder blockiert. Ein eigener Abschnitt zur Code-Anspruchsvollheit erklärt, dass die Sicherheitsfirmware für den Einsatz mit openpilot und panda geschrieben ist und über ihr Sicherheitsmodell die openpilot-Sicherheitsregeln durchsetzt. Wegen dieser kritischen Funktion gelten innerhalb des safety-Ordners hohe Standards für den Anwendungscode, geprüft durch die CI-Regressionstests des Repositorys.
Roadmap: von pip install opendbc bis Automatic Emergency Braking
Die Entwicklung wird laut README auf GitHub und im Discord koordiniert, insbesondere im Kanal #dev-opendbc-cars und im Bereich Vehicle Specific. Die kurzfristige Roadmap listet pip install opendbc, 100 Prozent Typabdeckung und 100 Prozent Zeilenabdeckung, sowie Erleichterungen für Car-Ports durch Refactorings, Tools, Tests und Dokumentation. Zudem soll der Zustand aller unterstützten Fahrzeuge besser sichtbar gemacht werden, was das README an das Issue 1144 bindet.
Langfristig stehen die Erweiterung auf jedes Auto mit LKAS- und ACC-Schnittstellen, eine automatische Bewertung der Quer- und Längsregelung, Auto-Tuning für beide Richtungen und Automatic Emergency Braking, verlinkt mit dem Wikipedia-Eintrag zu automatischen Notbremssystemen. Beiträge zu allen Punkten sind ausdrücklich willkommen. Der Release-Verlauf ist gemessen am Funktionsumfang dünn: v0.2.1 erschien im Februar 2025, v0.3.0 und v0.3.1 folgten erst im April 2026, beide am selben Tag.
Fazit: wofür die opendbc-Bibliothek von comma.ai gebaut ist und wo ihre Grenzen liegen
opendbc ist für zwei Zielgruppen geschrieben: Beiträge, die einen neuen Fahrzeugtyp für openpilot portieren wollen, und Entwickler, die programmatisch mit Fahrzeugbussen arbeiten. Für die erste Gruppe liefert das Repository mit der Portierungsanleitung, den Beispielen und cabana einen durchgängigen Pfad; für die zweite Gruppe sind opendbc/can/ und die DBC-Sammlung in opendbc/dbc/ die Nutzeroberfläche. Die MIT-Lizenz erlaubt beides ohne Copyleft-Pflichten.
Grenzen stehen im README selbst: Die Dokumentation besteht aus dem README und docs/CARS.md, es gibt keine versprochene Abdeckung aller Modelle, und die Auto-Tuning-Ziele stehen erst auf der Roadmap. Zwischen v0.2.1 im Februar 2025 und v0.3.0 im April 2026 lag ein Jahr ohne Release, was bei der Versionswahl auffällt. Wer konkret prüfen will, ob sein Fahrzeug unterstützt wird, schaut zuerst in docs/CARS.md und dort in den je Modell ausgewiesenen Unterstützungsumfang, statt sich auf die Repositorystatistik zu verlassen.
Redaktionelles Fazit
opendbc richtet sich an Entwickler, die CAN-Nachrichten von Fahrzeugen mit LKAS und ACC per Python lesen und schreiben wollen, insbesondere als Grundlage für openpilot-Car-Ports. Wer nur Daten aus dem Fahrzeugbus auslesen will, findet in opendbc/can/ und den examples/ einen Einstieg; wer Lenkung oder Bremse steuern will, muss die Sicherheitsfirmware in opendbc/safety/ und deren CI-Regressionstests verstehen, bevor Hardware angesprochen wird.
Community-Notizen