Autopilot & Telemetrie
Flugstabilisierung, Zustandsdaten, Missionsplanung und Failsafes sind getrennte Verantwortlichkeiten. MAVLink transportiert Nachrichten; es ist kein Ersatz für einen Flugregler.
Architektur verstehenDrone Recon Operation Lab · Technical Knowledge Base · Ausgabe 01
Von der Drohne zum reproduzierbaren Datensystem
D.R.O.L. untersucht nicht nur Fluggeräte. Die entscheidende Frage lautet: Welche Sensoren, Flugsteuerungen, Schnittstellen, Datenformate und KI-Werkzeuge lassen sich in einer nachprüfbaren Prozesskette kombinieren?
SDK, API & Firmware
Ein Hersteller-SDK bedeutet nicht, dass jede Drohne, Firmware, Fernsteuerung und Betriebssystemversion unterstützt wird.
Kompatibilität prüfenKamera, GNSS & LiDAR
Sensorfusion verlangt Zeitstempel, Kalibrierung, Koordinatensysteme und einen nachvollziehbaren Datenpfad.
Messkette planenKI & Geodaten
Detektion, Segmentierung, Photogrammetrie und Kartenprodukte haben unterschiedliche Eingabedaten und Qualitätskriterien.
Pipeline aufbauen01 · Referenzarchitektur einer offenen UAV-Plattform
| Schicht | Aufgabe | Typische Technologien | Prüffrage |
|---|---|---|---|
| Flight Controller | Regelkreise, Sensorfusion, Aktuatorausgabe, Failsafes | ArduPilot, PX4 | Bleibt die Flugstabilisierung ohne Companion Computer funktionsfähig? |
| Kommunikation | Telemetrie, Kommandos, Missionsdaten | MAVLink 2, serielle Verbindung, UDP | Welche Nachrichtentypen und Betriebsmodi sind wirklich implementiert? |
| Ground Control | Parameter, Mission, Karten, Diagnose | QGroundControl, Mission Planner | Welche Funktionen werden vom konkreten Autopiloten unterstützt? |
| Companion Computer | Bildverarbeitung, KI, High-Level-Planung | Raspberry Pi, Jetson, ROS 2, MAVSDK | Was geschieht bei Neustart, Paketverlust oder Überlast? |
| Datenspeicher | Medien, Telemetrie, Metadaten, Provenienz | EXIF, CSV, GeoJSON, GeoTIFF | Lassen sich Aufnahme und Ort später eindeutig zuordnen? |
Engineering-Regel: Kritische Flugfunktionen gehören auf den Flight Controller. Ein KI-Modul darf nicht stillschweigend zum einzigen Stabilisierungspfad werden. Entwicklungsversuche beginnen im Simulator und erfolgen nur innerhalb der jeweils geltenden Luftfahrtregeln.
Primärdokumentation: ArduPilot Developer · PX4 Docs · MAVLink · MAVSDK.
02 · SDK- und Firmware-Kompatibilität als Evidenzmatrix
Für eine belastbare Aussage werden Modell, Hardware-Revision, Firmware, Controller, SDK-Version, Host-Betriebssystem und konkrete Funktion gemeinsam geprüft. Eine allgemeine SDK-Produktseite ist kein Kompatibilitätsnachweis.
| Plattform | Integrationsweg | Grenze / Risiko | Erforderlicher Nachweis |
|---|---|---|---|
| ArduPilot / PX4 | MAVLink, MAVSDK, ggf. ROS 2 | Funktionsumfang abhängig von Firmware, Parametern und Hardware | Versionsgebundener SITL-Test und Telemetrielog |
| DJI Kamera-Drohnen | Hersteller-Apps, dokumentierte SDK-Familien, Medienexport | SDK-Unterstützung ist modell- und versionsabhängig; Videoexport ≠ autonome Flugsteuerung | Offizielle Supportmatrix für genaues Modell und Firmware |
| Parrot / ANAFI | Herstellerdokumentation, SDK-/API-Ökosystem | Produkt- und Firmwarevarianten müssen separat bewertet werden | API-Dokumentation plus reproduzierbarer Funktionstest |
| Unbekannte Wi-Fi-Drohne | Eventuell proprietäres App-Protokoll | Reverse Engineering ist kein Beleg für sichere, vollständige Steuerbarkeit | Reproduzierbares Laborprotokoll ohne riskanten Flugbetrieb |
Quellen: DJI Developer · Parrot Developer · D.R.O.L.-Prüfmatrix.
03 · Sensorik: von Rohdaten zu messbaren Ergebnissen
RGB / Photogrammetrie
Überlappende, scharfe Bilder mit ausreichender Textur ermöglichen Structure-from-Motion und dichte Rekonstruktion. Für belastbare Maßangaben sind geeignete Referenzpunkte oder Georeferenzierung erforderlich.
Thermografie
Thermische Auffälligkeiten sind zunächst Beobachtungen, keine automatische Schadensdiagnose. Emissionsgrad, Reflexionen, Umgebungsbedingungen und Sensorkalibrierung beeinflussen die Interpretation.
LiDAR / Tiefensensoren
Ein zusätzlicher USB-C-Sensor wird nicht automatisch zur nutzbaren Drohnen-Nutzlast. Entscheidend sind Masse, Energie, mechanische Montage, Zeitabgleich, Positionierung und Zugriff auf die Daten.
GNSS / RTK / PPK
Georeferenzierung benötigt ein definiertes Koordinatenreferenzsystem und nachvollziehbare Qualitätsmetriken. RTK allein garantiert keine vollständige geometrische Genauigkeit des Endprodukts.
Referenzen: OpenDroneMap Dokumentation · ROS · Open Geospatial Consortium.
04 · KI-Datenpipeline und Qualitätskontrolle
- Erfassen: Originalmedien, Zeitstempel, Fluglog und Sensor-Metadaten unverändert sichern.
- Validieren: Unvollständige Dateien, fehlende Geodaten, Unschärfe und Dubletten kennzeichnen.
- Verarbeiten: Geometrische Rekonstruktion, Objekterkennung oder Segmentierung passend zur Aufgabenstellung ausführen.
- Georeferenzieren: Ergebnisse mit dokumentiertem CRS und räumlicher Unsicherheit exportieren.
- Prüfen: Falschpositive, Stichproben, Referenzmessungen und Modellversionen dokumentieren.
- Freigeben: KI-Ergebnisse bleiben Vorschläge, bis ein nachvollziehbarer Prüfprozess sie bestätigt.
Geeignete offene Werkzeuge je nach Anwendungsfall: OpenCV, OpenDroneMap, ROS 2. Die Auflistung ist keine Aussage über Unterstützung durch eine bestimmte DJI-Drohne.
05 · Konkrete D.R.O.L.-Anwendungsprofile
Foto- und Videodokumentation
Planung → Aufnahme → Medienexport → Auswahl → Bildbearbeitung → Website. Der Nutzen liegt in reproduzierbaren Medien-Workflows; eine direkte SDK-Steuerung ist nicht zwingend erforderlich.
Fassade, Dach, Baustelle
Wiederholbare Perspektiven, Bildprotokolle, Zeitvergleich und geordnete Ablage. Visuelle Inspektion ist von normgerechter Vermessung und gutachterlicher Bewertung zu trennen.
Orthofoto und 3D-Modell
Aufnahmeplanung, Bildüberlappung, Referenzpunkte, Verarbeitung und Genauigkeitsprüfung. Ein schönes 3D-Modell ist noch kein vermessungstechnisch belastbares Produkt.
Autopilot + Companion AI
Simulation, MAVLink-Telemetrie, definierte Sicherheitszustände, KI-Prototypen und dokumentierte Versuchsreihen. Reproduzierbarkeit geht vor spektakulären Demo-Videos.
06 · D.R.O.L.-Evidenzstandard
| Stufe | Bedeutung | Veröffentlichungsregel |
|---|---|---|
| E0 | Ungeprüft / unklar | Nur als offene Frage oder Hypothese anzeigen |
| E1 | Modell- und versionsbezogene Primärdokumentation | Quelle, Datum und Geltungsbereich nennen |
| E2 | Reproduzierbarer Labortest | Testaufbau, Versionen, Logs und Ergebnis dokumentieren |
| E3 | Unabhängig wiederholter Test | Abweichungen und unabhängige Replikation belegen |
Ein Herstellerlink ohne konkrete Funktionsbelege ist nicht automatisch E1. Technische Fähigkeiten werden als YES, PARTIAL, NO oder UNKNOWN bewertet. Der Datenbankkatalog veröffentlicht den bekannten Status; unbewiesene Fähigkeiten bleiben ausdrücklich unbekannt.
Redaktioneller Stand: 07.11.2026. Diese Seite ist eine technische Methodik und Architekturübersicht, keine Behauptung bereits durchgeführter Labortests.