Open-source-Drohnenprojekte erweitern das Spektrum für Maker und Tüftler,eigene Fluggeräte zu entwerfen,zu steuern und zu analysieren. Der Beitrag skizziert zentrale Plattformen wie ArduPilot und PX4, typische komponenten und Workflows sowie Tools für Simulation, Telemetrie und Tests – inklusive Hinweisen zu Sicherheit und rechtlichen Rahmenbedingungen.
Inhalte
- PX4 vs. ArduPilot: Auswahl
- Sensorik und Flugcontroller
- mavlink, GCS und Telemetrie
- Praxisprojekte: Racer, Mapper
- Teilebeschaffung und budget
PX4 vs. ArduPilot: Auswahl
Die Entscheidung zwischen PX4 und ArduPilot hängt von Zielsetzung, Hardwarebasis und Entwicklungsstil ab. PX4 überzeugt mit modularer Architektur, striktem Release-Engineering und tiefer Integration in ROS 2 und Gazebo; ArduPilot punktet mit außergewöhnlicher Gerätevielfalt, ausgereiften Flugmodi und enormer Parametertiefe. Auch das Lizenzmodell beeinflusst die Roadmap: BSD (PX4) begünstigt proprietäre Erweiterungen, GPLv3 (ArduPilot) stärkt Offenheit und Copyleft.
- Entwicklungsfokus und release-Tempo
- Autonomie-Funktionen (Mission, Follow, Terrain)
- Hardwareunterstützung (FCUs, Peripherie, Sensorik)
- Simulation und HIL/SITL-Tooling
- Dokumentation, Foren, Issue-Response-Zeiten
- Regelkonformität: Geofencing, failsafe, Logging
- Integrationen: MAVLink, ROS 2, Companion-Computer
| Kriterium | PX4 | ArduPilot |
|---|---|---|
| Lizenz | BSD | GPLv3 |
| Stärken | Forschung, ROS/Offboard, VTOL | Missionsvielfalt, Flugzeug/Heli, Legacy |
| Konfiguration | QGroundControl, Profile | Mission Planner, Parameterfülle |
| Hardware | Pixhawk-Ökosystem, FMUv5+ | Breite FCU-Spanne inkl. älterer |
| Simulation | Gazebo, jMAVSim | SITL, RealFlight, AirSim |
| Schnellauswahl | Prototyping mit ROS 2 | Flotten-Retrofit und Vielfalt |
Praxisnahe Auswahl orientiert sich an Teamkompetenzen und Langzeitpflege. Für forschungsgetriebene Prototypen mit starkem Offboard-Anteil und hohem Iterationstempo bietet PX4 eine klare Pipeline von Simulation über CI bis Flug. Für heterogene Flotten, die robuste Legacy-Sensorik, komplexe Missionslogik und feingranulare Failsafe– sowie Tuning-Optionen verlangen, liefert ArduPilot ein sehr reifes Ökosystem. Entscheidungsleitend bleibt der Testpfad: erst SITL/HIL, dann Hardware-in-the-loop, danach Feldtests mit sauberem Log-Review (ULog bei PX4, BIN/DFLog bei ArduPilot) und reproduzierbaren Parametern.
Sensorik und Flugcontroller
Präzise Lage- und Positionsschätzung entsteht aus einer abgestimmten Kombination aus IMU, Magnetometer, Barometer, GNSS/GPS (optional RTK) sowie ergänzenden Abstandssensoren wie Optical Flow und LiDAR/tof. Entscheidend sind saubere Vibrationstrennung, korrekte Ausrichtung, sorgfältige Kalibrierung und zeitliche Synchronisation der Messwerte. Moderne Flug-Stacks nutzen Sensorfusion (z. B.EKF/UKF) und adaptive Filter, um Rauschen, Drift und magnetische Störungen zu kompensieren. Temperaturkompensation, harte/sanfte Montagestrategien und EMV-gerechtes Kabelrouting steigern die Robustheit, während hohe IMU-Abtastraten und konsequentes Timestamping die Regelgüte verbessern.
- IMU (Gyro/Accel): Primär für Lage; hohe Rate, vibrationssensibel.
- Barometer: Relative Höhe; anfällig für Propwash, daher dämpfen.
- Magnetometer: Kursreferenz; Abstand zu Hochstromleitungen beachten.
- GNSS/RTK: Position, Geschwindigkeit; RTK für zentimetergenaue Missionen.
- Optical Flow: indoor/Low-Texture-Handling mit Beleuchtung beachten.
- LiDAR/tof: Präzise Bodenabstände, hilfreich bei Landungen.
- Airspeed: Sinnvoll für Flächenmodelle und VTOL-Übergänge.
- Strom/Spannung: Energie- und Range-Management im Flug.
| Sensor | Rate | Nutzen |
|---|---|---|
| IMU | 1-8 kHz | Attitude |
| Barometer | 50-100 Hz | Höhe |
| Magnetometer | 50 Hz | Kurs |
| GNSS/RTK | 5-20 Hz | Position |
| Optical Flow | 30-60 Hz | Hold |
| LiDAR/ToF | 10-50 Hz | Abstand |
Der Flugcontroller bildet das deterministische Nervensystem: eine leistungsfähige MCU mit Echtzeit-Scheduler, rauscharmem Strompfad und reichlich I/O für UART, I²C, SPI und CAN/DroneCAN ermöglicht zuverlässige Anbindung modularer Sensorik. Wichtige Merkmale sind Filterung (Low-Pass, Notch), stabile Loop-Zeiten, Protokolle wie DShot/PWM zu ESCs, sowie Failsafes und Blackbox/SD-Logging für Diagnose. Firmware-Ökosysteme wie ArduPilot, PX4, Betaflight oder INAV bieten unterschiedliche Schwerpunkte von missionslogik bis Racing-Performance; Funktionen wie Autotune, Feedforward und adaptive Gains beschleunigen das Tuning. Redundante IMUs, dual-GNSS mit Yaw und getrennte Versorgungen erhöhen die Ausfallsicherheit, während Soft-Mounting und LC-Filter EMV-Einflüsse begrenzen.
- MCU-Klasse: F4/F7/H7 je nach Regelrate, Speicher und Peripheriebedarf.
- Bus-Topologie: Saubere Trennung von Hochstrom und Signalleitungen, terminierter CAN.
- ESC/Antrieb: DShot für Telemetrie,ausreichende Taktreserve bei hohen kV.
- Power: Rauscharm via BEC/UBEC, LC-Filter, getrennte 5V/9V Rails.
- Failsafe-Strategie: RTL, Landung, Geofence; konsistente GPS/GNSS-Checks.
- Tuning & Logs: Notch-Setzung per Spektrumanalyse,PID/FF-Feinabgleich,Heatmaps.
- Redundanz: Dual IMU, dual GNSS, separate Masseführung und Sicherungen.
MAVLink, GCS und Telemetrie
MAVLink dient als leichtgewichtiges Nachrichtenprotokoll zwischen Flugcontroller und Bodenstation und trägt in Open-Source-Stacks wie ArduPilot und PX4 Telemetrie, Missionsdaten und Parameteränderungen über serielle Links, UDP oder TCP. Herzschlag, Status, IMU‑Streams und Missions-Uploads werden als standardisierte Message-IDs transportiert; Timesync verbessert Log-Kohärenz. Die Wahl des Telemetriepfads – etwa SiK‑Modems (868/915 MHz),WLAN,LTE/5G oder Mesh – bestimmt Bandbreite,Latenz und Zuverlässigkeit. Ein typisches Setup nutzt hochfrequente Sensordaten, sparsame Statusmeldungen und einen Fallback-Link; Paketverluste werden durch Wiederholungen und Pufferung abgefedert.
- Stream-Raten: Anpassung über SRx‑Parameter (ArduPilot) bzw. MAV_X_* (PX4) für Missions-, parameter- und Status-Streams.
- Sicherheit: MAVLink v2 Signing für Integrität; verschlüsselung über Link-Layer (WPA2) oder VPN bei IP‑Links.
- Routing: mavlink-router oder MAVProxy für Mehrfach-Endpoints, UDP‑Broadcast und Log‑Teeing.
- IDs: Sauberes SYSID- und COMPONENT_ID‑management für Mehrfahrzeugbetrieb und Telemetrie-Sharing.
- QoS: Forward Error Correction, niedrige Sendeleistung nahe GCS, getrennte Kanäle für Video/OSD vs. Steuertelemetrie.
| Linktyp | Reichweite | Bandbreite | Latenz | Besonderheit |
|---|---|---|---|---|
| SiK 868/915 MHz | km‑Bereich | niedrig | niedrig | Robust, volle MAVLink‑Kompatibilität |
| WLAN 2.4/5 GHz | hundert Meter | hoch | sehr niedrig | Video + Telemetrie, IP‑Routing |
| LTE/5G | netzwerkweit | hoch | variabel | Remote‑GCS, NAT/VPN empfohlen |
| LoRa (exp.) | km‑Bereich | sehr niedrig | mittel | Nur Status, keine dichten Streams |
Ground Control stations bündeln Telemetrie, Missionsplanung und Analyze. QGroundControl unterstützt Missionseditor, Parameter-Browser, Video‑Overlay und Cross‑Platform‑Deployments; Mission Planner bietet umfangreiche Log-Analyse und ArduPilot‑Tools; mavproxy eignet sich für Headless‑Setups und Skripting. Simulation über SITL/HITL verkürzt Entwicklungszyklen, während Health‑Monitoring (EKF‑Innovationen, Batteriestatus), Geofencing und Failsafes die Betriebssicherheit erhöhen. Für Flottenbetrieb bewährt sich ein zentrales Routing (z. B. mavlink-router) mit Filterregeln, konsistenten System-IDs und getrennten Telemetry‑/Video‑Pipelines; Logging erfolgt parallel als Datenflash und Telemetry‑TLog für reproduzierbare Auswertung.
Praxisprojekte: Racer, Mapper
Ein schneller FPV-Racer demonstriert, wie sich Open-Source-Firmware in Echtzeit ausreizen lässt: Ein 5‑Zoll-setup mit F7-Stack und BLHeli_32-ESCs, getunt mit Betaflight und blackbox-Logs, liefert saubere Regelung und minimierte Latenz. ExpressLRS sorgt für robusten Link, während OpenHD auf einem SBC als digitale Videolösung experimentelles Low-Latency-Streaming ermöglicht. Leichtbau, 6S-LiPo und sorgfältiges Prop-Matching reduzieren Vibrationspektren und verbessern das Propwash-Verhalten, während modularer Aufbau schnelle Reparaturen und Upgrades begünstigt.
- Hardware: 5″-Carbonrahmen, 2306-2207 Motoren, 6S 1100-1300 mAh, 4‑in‑1 ESC 45-55 A
- Stack/Firmware: F7/F405 + Betaflight, BLHeli_32; Blackbox für PID-Analyse
- Funk/Video: ExpressLRS 2.4 GHz; analog 5.8 GHz oder openhd (SBC + Kamera)
- Safety: Buzzer, GPS‑Rescue optional, sauber geführte Stromversorgung (LC-Filter)
| Projekt | Rahmen | Firmware | Flugzeit | Kernnutzen |
|---|---|---|---|---|
| Racer | 5″ | Betaflight | 3-6 min | Agilität, Low-Latency |
| Mapper | 7″ LR | ArduPilot/PX4 | 20-35 min | Autonomie, Präzision |
Ein autonom ausgerichteter Mapper priorisiert Ausdauer und Navigation: Ein 7‑Zoll-Long‑Range‑Quad mit ArduPilot oder PX4, GNSS mit optionalem RTK, Missionsplanung über QGroundControl und getriggerter Kamera eignet sich für Orthofotos und Punktwolken.Effiziente Low‑KV‑Motoren und Li‑Ion‑packs erhöhen die Reichweite, während Geofence, RTL und Log-Telemetrie die Missionssicherheit stärken. Die Datenauswertung mit OpenDroneMap/WebODM erzeugt GeoTIFFs, DSM/DTM und 3D‑Modelle für GIS‑Workflows.
- Komponenten: 7″-Frame, 28xx Low‑KV, 6S Li‑Ion 4000-5000 mAh, vibrationsgedämpfter Kameramount
- Navigation: GPS/GLONASS + RTK‑Option, Magnetometer, Barometer, zuverlässiger Telemetrie-Link
- Mission: 70/60 % Überlappung, Auslösung per GPIO/Hotshoe, Geotagging im Log oder Batch
- Auswertung: WebODM‑Pipeline, Export als GeoTIFF, LAS/LAZ und Mesh für CAD/GIS
Teilebeschaffung und Budget
Eine tragfähige Beschaffungsstrategie beginnt mit einer präzisen Stückliste (BOM) und Priorisierung der kritischen Komponenten: Flight Controller, ESCs/Motoren, LiPo-Akku, Propeller und Frame. Kompatibilität reduziert Fehlkäufe: stecksysteme (z. B.XT60), Spannungen (3-6S), Signale/Protokolle (PWM/DShot, UART/I²C), sowie mechanische Standards (M2/M3) sollten zusammenpassen.Neben Einzelkauf lohnt das Prüfen von Kits und Sammelbestellungen; lieferzeiten, Zoll und ersatzteilverfügbarkeit fließen in die Planung ein. Nachhaltige Optionen wie refurbished-Teile, Recycling von Befestigungsmaterial und 3D-Druck für Halterungen senken Kosten, ohne die Flugsicherheit zu kompromittieren.
- Community-Marktplätze & Open-Source-Shops: Komponenten mit dokumentierten Settings und geprüfter Firmware-Kompatibilität.
- Elektronikdistributoren: sensorik, Kabel, Stecker; zuverlässige Lieferkette und Datenblätter.
- RC-fachhandel lokal: Sofortverfügbarkeit, Beratung und schnelle Ersatzteilversorgung.
- Second-Life/Refurbish: Gehäuse, Frames, Ladegeräte; Zustand und Zyklenzahl von Akkus kritisch prüfen.
- maker-Spaces & 3D-Druck: Kamerahalter, Dämpfer, Kabelmanagement; STL/STEP aus Open-source-Repos.
- sammelbestellungen: Mengenrabatte für Schrauben, Kabelsätze, Propeller in gängigen Größen.
Für einen realistischen Finanzrahmen bewährt sich eine grobe Verteilung: ca. 40 % Antriebsstrang (Motoren/ESC/Props), 25 % Avionik (FC, GPS/Kompass, Telemetrie), 15 % Frame/Mechanik, 10 % Energie (Akkus/Ladegerät) und 10 % reserve für Verschleiß und Kleinteile. einstiegsklassen bewegen sich häufig bei 200-350 €, mittlere Setups bei 400-700 €, ausgereiftere Plattformen mit Zusatzsensorik bei 800-1200 €. Kosten lassen sich durch Standardisierung auf gängige Spannungen (z. B. 4S), druckbare Halterungen, wiederverwendbare Befestiger und die Nutzung gepflegter Open-Source-BOMs reduzieren; eine Ersatzteil- und Crash-Reserve von 10-15 % schützt den Zeitplan.
| Teil | Budget (EUR) | Tipp |
|---|---|---|
| Flight Controller | 40-150 | F7/H7, genügend uarts |
| Motoren + ESC | 80-300 | KV zur Prop-Größe passend |
| Propeller (Satz) | 10-30 | Ersatz stets einplanen |
| Frame | 30-120 | Carbon, auswechselbare arme |
| LiPo-Akku | 25-80 | 4S, 1500-5000 mAh |
| GPS/Kompass | 20-60 | Externer Mast, EMV-Abstand |
| funk/Telemetrie | 20-100 | Reichweite vs. Gewicht abwägen |
| Kleinteile | 10-20 | M2/M3, Kabel, Schrumpfschlauch |
Was sind Open-Source-Drohnenprojekte?
Open-Source-Drohnenprojekte kombinieren frei verfügbare Hardware-Designs und offene flugsteuerungssoftware. Solche Initiativen fördern transparente Entwicklung,Wiederverwendbarkeit und kosteneffiziente tests mit Rahmen,Motoren,Sensoren,Telemetrie und Bodenstationen.
Welche Plattformen und Flugsteuerungen sind verbreitet?
Verbreitete Open-Source-Stacks sind ArduPilot und PX4; für Racer dominieren Betaflight und iNav. Als Hardware gelten Pixhawk-Varianten und andere STM32-basierte Boards als Standard. Für Missionsplanung sind QGroundControl und Mission Planner gängig.
Welche rechtlichen und sicherheitstechnischen Aspekte sind zu beachten?
Relevant sind EU-Drohnenklassen, registrierung, Kennzeichnung und Kenntnisnachweise sowie lokale Flugverbotszonen. Technisch helfen Propellerschutz,sichere Failsafes,Kalibrierungen und Tests auf freiem Gelände.Dokumentation von Änderungen erleichtert Nachvollziehbarkeit.
Welche Komponenten und Tools werden typischerweise benötigt?
Typisch sind Rahmen, BLDC-Motoren, ESCs, Propeller, Flight Controller, GPS/Kompass, Empfänger, Telemetrie, LiPo-Akkus samt Ladegerät und Power-Module. an Werkzeugen helfen Lötstation, Multimeter, Crimpzange, Schraubendreher sowie 3D-Druck für halterungen.
Wie gelingt der Einstieg in ein Open-Source-Drohnenprojekt?
Ein einfacher Einstieg gelingt mit einem gut dokumentierten rahmen oder Kit, anschließend Schritt-für-Schritt nach Projektwiki und Referenzkonfigurationen. Simulatortests, kurze Erstflüge mit Log-Auswertung und Feedback aus Foren reduzieren Fehler und Kosten.
