KI-DrohneFrankfurt UAS
Start › Fliegen

Flugversuche und Absturz

Historischer Untersuchungsstand: 20.–21. August 2026. Die beschriebenen Softwareänderungen gehören zum archivierten Experiment und sind keine heutige Bedienungsanleitung. Aktuelle Betriebsgrenzen stehen unter MAVLink-Steuerung. Rohberichte und Logs bleiben im datierten Archiv erhalten.

Jeder Startversuch, der Absturz vom 21.08. und die drei gemessenen Ursachen.

Der vollständig autonome Flug wurde nicht erreicht. Am 21.08.2026 wurde die Drohne bei einem Startversuch zerstört. Niemand wurde verletzt. Die Auswertung ist das lehrreichste Ergebnis dieser Arbeit, deshalb steht sie hier vollständig: Jeder Versuch ist über Telemetrie und das Dataflash-Log der Drohne nachvollzogen, nicht aus der Erinnerung beschrieben.

Die Versuche

WannWas passiert ist
20.08. Erster Flug überhaupt. Die Drohne armierte und hob zum ersten Mal ab, stieg über die befohlene Höhe hinaus und blieb oben. Sie hing an einer Leine und wurde gestoppt, indem der Akku abgezogen wurde.
21.08. vormittags Zwei Starts in STABILIZE, kein Abheben. Der Rangefinder meldet über 13 Sekunden konstant 0,02 m. Der befohlene Schub lag bei 0,128 gegen einen gelernten Schwebeschub von 0,263 — etwa die Hälfte des Nötigen.
21.08. — Totalschaden Der Abbruch flog die Drohne. Nach dem Timeout forderte die Software eine Landung an — und LAND ist ein höhengeregelter Modus. In einem einzigen Log-Sample ging der Schub von 0,128 auf 1,000, und die Drohne stieg in einer Sekunde in die Decke der Sporthalle.
21.08. abends Erstes echtes Abheben nach dem Wiederaufbau, in ALT_HOLD: 0,02 m auf 0,57 m in 0,4 Sekunden. Der Höhenwächter stoppte den Steigflug korrekt.
21.08. abends Der neue Wächter greift. Das Fahrzeug meldet „steigt mit +0,96 m/s“, während der Rangefinder 0,00 m/s misst. Abbruch nach 0,8 Sekunden Widerspruch — bevor überhaupt Schub aufgebaut wurde.

Video des Absturzes

Aufnahme vom 21.08.2026

Der zweite Start in STABILIZE: dreizehn Sekunden ohne jede Bewegung, dann der Abbruch, der die Drohne in einem Zug in die Hallendecke fliegt.

Video öffnen

Drei Ursachen, gemessen

1. Der EKF hatte keine Höhenquelle

EK3_SRC1_POSZ=2 benannte den Rangefinder als primäre Höhenquelle, während EK3_RNG_USE_HGT=-1 genau dessen Nutzung für die Höhe verbot. Zwischen beiden Parametern blieb dem Filter gar keine Höhenstützung: Seine Vertikalgeschwindigkeit lief als unkorrigiertes Integral des Beschleunigungsfehlers davon. Gemeldet wurden −10 000 m und −38 m/s Sinken, während die Drohne auf dem Boden stand.

STABILIZE ist ein manueller Modus und ignoriert das vollständig — deshalb vergingen dreizehn Sekunden ereignislos. LAND dagegen regelt auf die Höhe. Es las 38 m/s Sinken, gab Vollgas dagegen und flog die Drohne in die Decke. Mit dem Barometer als Höhenquelle meldet dieselbe Drohne im Stand +0,05 m und +0,01 m/s.

2. Die Schubkennlinie war falsch angenommen

ArduPilot liest den Gasknüppel in STABILIZE nicht als Schubanteil. Es formt ihn so, dass Knüppelmitte Schwebeschub ergibt, mit einer kubischen Kennlinie aus MOT_THST_HOVER. Unser Code setzte den Knüppel auf 0,313 im Glauben, das sei Schweben — die Kennlinie macht daraus 0,135. Das Log bestätigt es: 0,128 gegen einen gelernten Schwebeschub von 0,263.

3. Ein Beschleunigungs-Offset im Betrieb

Eine stillstehende Drohne misst in jeder Lage genau ein g — der Betrag der Beschleunigung prüft sich auf der Werkbank also selbst. Diese hier misst 9,79 m/s² mit gestoppten Motoren und 10,65 m/s² mit im Leerlauf drehenden Motoren, bei unveränderter Lage. EKF3 integriert die Differenz zu rund 0,75 m/s² Drift pro Sekunde. Daher „steigt mit 4,27 m/s“ bei 0,020 m Bodenabstand, und daher auch der überschießende Steigflug eine Stunde zuvor: derselbe Fehler in die andere Richtung.

Die Vibrationsmetrik der Drohne bleibt dabei blind, weil sie Streuung misst und ein gleichgerichteter Rüttler als Gleichanteil erscheint. Solange dieser Offset vorhanden ist, ist ALT_HOLD auf dieser Drohne nicht fliegbar.

Was damals im experimentellen Code geändert wurde

Was die Simulation leistet — und was nicht

Der damalige Experimentalbranch enthielt ein simuliertes Fahrzeug, in das elf Fehlerbilder injiziert werden können: verweigertes Armieren, ausbleibendes Abheben, weglaufende Höhe, Batterieeinbruch, veraltete Telemetrie, Heartbeat-Verlust, verweigerte Landung, durchgehender Schub, divergierender EKF. Der Unfall vom 21.08. ist als Fehlerbild nachgebaut, dazu kommen über 500 Offline-Tests in jenem Branch. Der gepflegte Code verwendet eigene Regressionstests und die separat dokumentierten ArduCopter-SITL-Szenarien.

Die eigentliche Lehre steht daneben: Der Simulator enthielt dieselbe falsche Annahme über die Schubkennlinie wie der Flugcode. Eine Probe gegen ihn konnte diesen Fehler deshalb prinzipiell nicht finden. Eine Simulation prüft Code gegen Annahmen — nicht Annahmen gegen die Wirklichkeit. Wo eine Annahme über das Protokoll gefährliche Bewegung erzeugen kann, muss stattdessen etwas an der Drohne gemessen werden.

Offene Punkte der damaligen Untersuchung

Die vollständigen Messwerte — Telemetrie, Dataflash-Log und das ausführliche Protokoll — liegen als datierte Aufzeichnung im Repository unter notes/archive/preflight-and-nogps-takeoff/. Der originale Experimentalcode bleibt über seinen unveränderlichen Commit erhalten.