Software, Firmware und Datenimport

Software-Kompass nach Aufgabe

Für einen sicheren Betrieb müssen Flug-App, Firmware, Datenexport und Auswertungssoftware getrennt betrachtet werden. Die folgende Übersicht zeigt typische Werkzeuge und verweist auf die jeweiligen Projektquellen. Sie ist keine Freigabe für eine bestimmte Gerätekombination.

Versions- und Quellenprüfung im Betrieb

Softwarezugriff: vom Foto zur programmierbaren Plattform

Welche Möglichkeiten bestehen, hängt von Modell, Fernsteuerung, Firmware und der dokumentierten Schnittstelle ab. Ein Fotoexport ist ein anderer Zugangsweg als eine SDK-Verbindung oder eine veränderbare Flugcontroller-Firmware. Eine Schnittstelle sollte erst dann als geeignet gelten, wenn genau die benötigte Funktion für die konkrete Gerätekombination belegt ist.

Android als Bodenstation: Was das Smartphone leisten kann

Ein Android-Gerät kann, abhängig von der Software und der freigegebenen Verbindung, Benutzerschnittstelle, Telemetrieanzeige, Videoanzeige oder einen lokalen Bildanalyseprozess übernehmen. Ob ein Galaxy S24 Ultra mit einer konkreten Fernsteuerung und einer bestimmten SDK-Version zusammenarbeitet, ist gerätespezifisch zu prüfen; eine Funktionszusage liegt für D.R.O.L. nicht vor.

Status: Entwicklungsansatz. Eigene D.R.O.L.-Android-App, Gerätekombinationen und autonome Flugfunktionen sind hier nicht als fertige Implementierung nachgewiesen. Vier Datenwege ansehen.

Entwurf: eine gemeinsame D.R.O.L.-Softwarearchitektur

Damit vorhandene Drohnen und offene Systeme langfristig ähnliche Auswertungen nutzen können, sieht das Projekt austauschbare Softwaremodule vor. Die folgende Struktur ist ein Entwurf aus der Projektforschung, kein Nachweis einer einsatzfertigen Plattform.

Die Flugstabilisierung verbleibt unabhängig auf dem Flugcontroller. Ein Ausfall der zusätzlichen Auswertung darf nicht als verlässliches Sicherheits- oder Notfallsystem eingeplant werden. Zur Architektur im Lab · Datenverarbeitung und Qualität.

Technischer Leitfaden: Von der Drohne zur eigenen Anwendung

Dieser Leitfaden hilft bei der Auswahl eines realen Datenwegs. Er unterscheidet verfügbare Herstellerfunktionen von einem Architekturentwurf. Fachlich geprüft: 5. November 2026. Hardware, Fernsteuerung und Softwareversion entscheiden im Einzelfall über die tatsächlich verfügbaren Funktionen.

1. Fluggerät und Datenpfade verstehen

Ein Multicopter besteht aus Flugcontroller mit Sensoren, Antrieben und Empfänger; je nach Aufbau kommen GNSS, Kamera und ein zusätzlicher Rechner hinzu. Der Flugcontroller erfasst Sensorwerte, schätzt den Zustand und regelt die Motoren. Telemetrie, Steuerung und Video sind verschiedene Aufgaben: Ein Telemetrielink ist nicht automatisch ein Videolink. Ein Companion-Computer verarbeitet zusätzliche Daten und kann bei passender Schnittstelle mit dem Flugcontroller kommunizieren.

Offenes System: Sensoren → Flugcontroller mit ArduPilot/PX4 → MAVLink-Verbindung → Companion oder Bodenstation → Anwendung. Die Kamera kann getrennt an den Companion oder an eine Bodenstation angebunden sein. Vorhandene Drohne: Kamera → Exportdatei oder dokumentierte Hersteller-Schnittstelle → Anwendung. Beide Wege können anschließend in dieselbe Auswertung münden. ArduPilot: Companion Computers · PX4: Companion Computers.

2. Sechs Eigenschaften getrennt bewerten

1. Offene Firmware: Ist der Quellcode der tatsächlich verwendeten Firmware verfügbar? Eine veröffentlichte App genügt nicht als Nachweis.
2. Offene Hardware: Sind die relevanten Schaltpläne und Entwicklungsunterlagen mit passenden Nutzungsrechten verfügbar? Offenheit der Software allein belegt das nicht.
3. SDK oder API: Welche App-Schnittstellen sind für genau das Modell, die Fernsteuerung und die Version dokumentiert? Die Hersteller-Produktliste ist nur der Anfang der Prüfung.
4. Missionen und Steuerung: Sind die benötigten Funktionen, etwa Missionsübertragung oder einzelne Steuerbefehle, für diese Kombination dokumentiert? Telemetrie lesen bedeutet nicht automatisch steuern zu können.
5. Zusätzliche KI-Verarbeitung: Gibt es zugängliche Dateien oder einen nutzbaren Videostrom, und wo soll die Auswertung stattfinden? Offline-Bildanalyse benötigt keine Änderung am Fluggerät.
6. Firmware verändern: Ist für das konkrete Gerät ein Änderungs- und Installationsweg dokumentiert und autorisiert? Ein SDK oder ein offenes Übertragungsprotokoll ist dafür kein Beleg.

Für jede Eigenschaft sollten Beleg, genaue Variante, Versionsstand, Prüfdatum und Ergebnis festgehalten werden. Unbekannt bedeutet: noch kein belastbarer Nachweis – weder Zustimmung noch Ablehnung. Zu den Modellprofilen · DJI Mobile SDK: Produktübersicht.

3. Protokoll, Schnittstelle und Transport auseinanderhalten

4. KI-Anbindung: vier realistische Varianten

1. Offline: Originalbilder von der Speicherkarte sichern → Qualität und Metadaten prüfen → lokal auswerten → Befunde mit Bildreferenz dokumentieren. Das ist der einfachste Einstieg, wenn kein Livezugriff vorliegt.
2. Extern live: Ein dokumentierter Videozugang liefert Bilder an PC oder Android. Die Anwendung dekodiert und analysiert diese; Telemetrie muss gegebenenfalls getrennt bereitgestellt und zeitlich zugeordnet werden. Ein sichtbares App-Bild beweist noch keinen Drittanbieterzugang.
3. Companion an Bord: Eine geeignete Kamera liefert Bilder an Raspberry Pi oder Jetson; die Anwendung erzeugt Ereignisse und speichert sie lokal. Stromversorgung, Kühlung, Gewicht und Datensicherung gehören zur Systemplanung.
4. Offene Plattform: ArduPilot oder PX4 kommuniziert über eine eingerichtete MAVLink-Verbindung mit einem Companion. Telemetrie und Kameradaten können gemeinsam verarbeitet werden, sofern Zeitbezug, Schnittstellen und Qualität geprüft sind.

Architekturregel: Die Flugregelung bleibt unabhängig von der zusätzlichen Bildauswertung. Starten Sie mit Simulation und lesender Telemetrie. Ein KI-Ergebnis, eine Netzverbindung oder ein Smartphone ersetzen keine verifizierten Sicherheitsfunktionen des Fluggeräts. Vier Datenwege im Lab · Von der Aufnahme zum Bericht.

5. Praktische Prüfung für eine vorhandene Drohne

1. Modellvariante, Serienstand soweit erforderlich, Firmware, Fernsteuerung, Mobilgerät und App-Version erfassen.
2. Originale Beispieldateien sichern und prüfen, ob Bilder, Zeitstempel und Positionsdaten tatsächlich enthalten sind. Fehlende Metadaten als fehlend dokumentieren.
3. Für Live- oder Steuerfunktionen die offizielle Dokumentation der passenden SDK-Version lesen und benötigte Berechtigungen, Lizenzen und Abhängigkeiten festhalten.
4. Jede Fähigkeit einzeln als dokumentiert, praktisch getestet oder offen kennzeichnen. Prüfdatum und direkte Quelle ergänzen; eine funktionierende Hersteller-App belegt keine freie API.
5. Erst dann einen kleinen Testplan für die gewünschte Funktion erstellen. Tests an eigener oder ausdrücklich autorisiert untersuchter Hardware zunächst ohne Propeller und in einer sicheren Umgebung durchführen.

Bei proprietären Systemen kann die Dokumentation Lücken lassen. Protokollanalyse oder Firmwareforschung setzt Berechtigung, passende rechtliche Prüfung und ein sicheres Testumfeld voraus; Sicherheitsmechanismen werden nicht ausgeschaltet. Zum Prüfpfad für vorhandene Drohnen.

6. Häufige Fehler und die nächste Prüfung

• Keine Telemetrie: Verbindungstyp, Port, Baudrate, Gegenstelle und Heartbeat-Ausgabe anhand der Dokumentation prüfen. Ein Netzwerkanschluss allein bestätigt keine MAVLink-Daten.
• Keine Koordinaten im Bild: Originaldatei statt Messenger-Kopie verwenden und Kamera-/Exportoptionen prüfen. Ein fehlendes Positionsfeld darf nicht aus einem anderen Bild übernommen werden.
• SDK erkennt das Gerät nicht: Unterstützte Modell- und Fernsteuerungskombination, Firmware, SDK-Version und Berechtigungen vergleichen. Nicht aus der Produktfamilie auf jede Funktion schließen.
• Erkennung passt nicht zum Bild: Aufnahmebedingungen und Modellgrenzen prüfen; Befunde mit Originalbild und Version nachvollziehbar festhalten und fachlich freigeben.

Projektstand: Der gemeinsame VehicleAdapter, LinkAdapter, die Android-Oberfläche und die KI-Modulverwaltung sind Architekturentwürfe. Eine produktive, universell kompatible D.R.O.L.-Software ist damit nicht nachgewiesen.