ArduPilot: Fahrzeug-Firmware in C++ mit SITL-Tests und GPL-3.0
ArduPlane, ArduCopter, ArduRover, ArduSub-Quelle. Unsere Autopilot-Software ist in der Lage, nahezu jedes erdenkliche Fahrzeugsystem zu steuern, von herkömmlichen Flugzeugen, Quad-Flugzeugen, Multirotoren und Hubschraubern bis hin zu Rovern, Booten, Balance-Bots und sogar U-Booten.
Auf einen Blick
- Was ist das?
- ArduPilot/ardupilot bündelt ArduCopter, ArduPlane, Rover, ArduSub und AntennaTracker in einem C++-Repository mit SITL-Workflows, namentlichen Maintainern und Release-Tags je Fahrzeug. Stand 4.7.0.
- Für wen ist es gedacht?
- ArduPilot passt zu Vorhaben, die ein ungewöhnliches Fahrzeug steuern wollen oder Eingriffe in die Firmware selbst vornehmen müssen, und zu Teams, die sich über Wiki und Forum einarbeiten. Weniger geeignet ist es, wenn eine fertige, vom Hersteller verantwortete Lösung verlangt wird, oder wenn die Pflichten aus der GPL-3.0 nicht zum eigenen Vertriebsmodell passen.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C++, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
ArduCopter, ArduPlane, Rover, ArduSub und AntennaTracker im Repository
ArduPilot ist laut README eine Autopilot-Software, die seit 2010 von einem Team aus Ingenieuren, Informatikern und Freiwilligen entwickelt wird. Sie steuert nach eigener Darstellung herkömmliche Flugzeuge, Quadplanes, Multirotor, Hubschrauber, Rover, Boote, Balance-Bots und U-Boote.
Der Quelltext ist in Verzeichnisse nach Fahrzeugtyp gegliedert: ArduCopter, ArduPlane, Rover, ArduSub und AntennaTracker. Zu jedem Verzeichnis verlinkt die README ein eigenes Wiki, für ArduSub zusätzlich die Seite ardusub.com. Welche Flugcontroller welche Firmware unterstützen, steht dort und nicht in der README.
Das Repository erreicht 15.762 Sterne und 21.303 Forks bei 3.160 offenen Issues. Die Sprache ist C++, der Standardbranch heißt master.
SITL-Workflows von test_sitl_copter bis test_replay
Die Qualitätssicherung ist im README über eine Reihe von GitHub-Workflows sichtbar. Für jeden Fahrzeugtyp existiert ein eigener SITL-Test, also eine Simulation der Firmware ohne Hardware: test_sitl_copter, test_sitl_plane, test_sitl_rover, test_sitl_sub, test_sitl_tracker und test_sitl_periph. Ergänzend laufen test_chibios für das Echtzeitbetriebssystem, test_linux_sbc für Einplatinenrechner sowie test_replay zur Nachrechnung von Protokollen.
Hinzu kommen test_unit_tests, test_size zur Überwachung von Speichergrenzen und test_environment. Gebaut wird auch unter Cygwin und macOS, die Abdeckung verfolgt test_coverage, statische Analyse liefert Coverity, Ergebnisse sammelt autotest.ardupilot.org. Gelistet ist das Projekt bei bestpractices.dev unter der Nummer 10598.
Diese Aufstellung ist ein Anhaltspunkt für die Testtiefe, ersetzt jedoch keine eigene Erprobung.
Maintainer-Zuordnung: Tridgell bei Plane, Riseborough bei AP_NavEKF3
Der Abschnitt zu den Maintainern ordnet namentlich genannte Personen Fahrzeugen, Platinen und Subsystemen zu. Andrew Tridgell verantwortet Plane und AntennaTracker sowie die Boards Pixhawk, Pixhawk2 und PixRacer. Randy Mackay deckt Copter, Rover und AntennaTracker ab, Grant Morphett Rover, Willian Galvani Sub und Navigator, Tom Pittenger Plane, Bill Geyer TradHeli.
Bei den Subsystemen finden sich Michael du Breuil für Batteries, GPS und Scripting, Peter Barker für DataFlash und Tools, Paul Riseborough für AP_NavEKF2 und AP_NavEKF3, Gustavo José de Sousa für das Build-System sowie Leonard Hall für Lageregelung und Navigation des Copters. Weitere Einträge nennen Platinen wie Cube, VRBrain, NavIO, Bebop und BeagleBone Blue.
Francisco Ferreira ist als Bug Master eingetragen. Wie diese Zuordnungen zustande kommen, beschreibt die README nicht.
Release-Tags Tracker-4.7.0, Sub-4.7.0 und Rover-4.7.0
Die Release-Praxis folgt der Aufteilung nach Fahrzeugen. Die drei jüngsten Tags heißen Tracker-4.7.0, Sub-4.7.0 und Rover-4.7.0, alle veröffentlicht am 27. Juli 2026. Wer eine Firmware sucht, wählt also das zum Fahrzeug passende Artefakt und kein gemeinsames Gesamtpaket.
Das README verweist für die Abläufe auf die Seite zu den Release-Verfahren im Entwickler-Wiki und erwähnt eine Gruppe von Beta-Testern, die neue Stände vor der Freigabe prüft.
Eine Versionshistorie oder ein Änderungsprotokoll enthält die README nicht, beides liegt im Wiki und auf den Release-Seiten. Wie lange eine einmal freigegebene Version gepflegt wird, geht aus dem Material nicht hervor.
discuss.ardupilot.org, das Dev-Wiki und contributing.html
Für den Support nennt die README das Forum unter discuss.ardupilot.org sowie die Community-Seite ardupilot.org, auf der Dokumentation und Ankündigungen liegen. Entwickler finden ihr Wiki unter ardupilot.org/dev, die Diskussion im Forum und den Chat auf Discord; verlinkt werden außerdem ein Kanal für Dokumentation und eine Kontaktseite.
Wer mitmachen will, findet Richtlinien unter ardupilot.org/dev/docs/contributing.html. Fehler und Wünsche gehen in die Issue-Liste, Hilfe bei der Protokollanalyse leistet das Forum, Wiki-Verbesserungen werden im Discord-Kanal für Dokumentation besprochen.
Die Finanzierung läuft über Partner, die das Projekt auf einer eigenen Seite aufführt; Angaben zu Summen oder Laufzeiten fehlen.
GPL-3.0 mit COPYING.txt: Folgen für eigene Hardware
Die Lizenz ist die GNU General Public License Version 3. Der vollständige Text liegt als COPYING.txt im Repository, ergänzt um eine Übersicht im Wiki. Für die Praxis heißt das: Veränderungen an der Firmware, die weitergegeben werden, unterliegen der Pflicht zur Offenlegung des Quelltexts. Wer ArduPilot auf eigener Hardware ausliefert, sollte diese Kette vorher klären.
Die README erwähnt keine doppelte Lizenzierung und keine abweichenden Bedingungen für einzelne Verzeichnisse. Ob Teile des Repositories Ausnahmen enthalten, ist dem Material nicht zu entnehmen.
Die Metadaten weisen GPL-3.0 aus, maßgeblich bleibt der Wortlaut in COPYING.txt.
Hersteller-Firmware und andere Stacks als Alternative zu ArduPilot
Als Alternative bieten sich zwei Richtungen an. Die erste ist herstellergepflegte Firmware, die auf ein bestimmtes Fluggerät zugeschnitten ist und ohne eigenen Build auskommt; dafür entfällt der Blick in den Quelltext, und Anpassungen liegen in der Hand des Anbieters. Die zweite Richtung führt zu einem anderen quelloffenen Autopilot-Stack. Über diesen sagt die README von ArduPilot nichts, ein Vergleich wäre anhand der jeweiligen eigenen Dokumentation zu führen.
ArduPilot selbst punktet dort, wo Fahrzeugvielfalt und Eingriffstiefe zählen: fünf Fahrzeugverzeichnisse, namentlich zugeordnete Maintainer für Fahrzeuge, Platinen und Subsysteme sowie SITL-Läufe je Fahrzeugtyp.
Dem stehen 3.160 offene Issues gegenüber und eine README, die bewusst auf das Wiki verweist, statt alles selbst zu erklären.
Was die ArduPilot-README offenlässt
Ebenso aufschlussreich ist, was fehlt. Die README nennt keine Build-Anweisungen, keine Mindestanforderungen an Hardware, keine Liste unterstützter Flugcontroller und keine Versionshistorie. Auch zur Finanzierung über die Partnerseite hinaus schweigt sich das Material aus.
Wer einsteigt, kommt deshalb am Wiki nicht vorbei. Für eine erste Bewertung lohnt der Weg über die SITL-Workflows: Sie zeigen, welche Fahrzeugtypen automatisiert geprüft werden, und geben damit einen Anhaltspunkt, wie gepflegt der jeweilige Zweig ist.
Zur Einordnung gehört außerdem, dass die README ausdrücklich zur Beteiligung einlädt und Mitarbeit an Code, Tests, Wiki und Forum als gleichrangige Wege beschreibt.
Redaktionelles Fazit
ArduPilot passt zu Vorhaben, die ein ungewöhnliches Fahrzeug steuern wollen oder Eingriffe in die Firmware selbst vornehmen müssen, und zu Teams, die sich über Wiki und Forum einarbeiten. Weniger geeignet ist es, wenn eine fertige, vom Hersteller verantwortete Lösung verlangt wird, oder wenn die Pflichten aus der GPL-3.0 nicht zum eigenen Vertriebsmodell passen. Vor dem Einstieg empfiehlt sich der Blick in das Verzeichnis des eigenen Fahrzeugtyps, etwa Rover für Bodenfahrzeuge, und in den zugehörigen SITL-Workflow, um zu sehen, wie dicht die automatisierte Prüfung für genau diesen Zweig ist.
Community-Notizen