Post-mortem: einen Drohnenabsturz mit dem Fluglog aufklären

Ein Absturz ist teuer, aber der wahre Schaden ist der zweite, den er nicht verhindert hat. Wenn man nicht versteht, warum die Drohne gefallen ist, fliegt man die gleiche Ursache beim nächsten Mal wieder. Deshalb ist das Fluglog nach jedem Vorfall nicht optional: Der Flugcontroller zeichnet mit, was er gesehen, gedacht und befohlen hat — und diese Aufzeichnung lügt nicht.

In diesem Artikel gehe ich einen konkreten Absturz durch. Es ist kein spektakulärer Fall: ein Propeller gebrochen, Frame und Elektronik heil. Aber die Ursache ist eine generische ArduPilot-Lehre, die jeden trifft, der die Nutzlast oder den Aufbau ändert.

Das Symptom

Der Flug war als einfacher Loiter-Start geplant. Die Drohne war neu konfiguriert, GPS und Lidar gerade montiert, alles frisch kalibriert. Die Loiter-Tests vorher — ohne Wasser — liefen einwandfrei.

Dann: Tank mit 4 Litern befüllt, Abfluggewicht rund 7,2 kg, Start wieder im Loiter-Modus. Beim Abheben schob die Drohne ungewollt nach vorne, kippte auf −54° Pitch und wurde noch in der Luft über ANGLE_MAX automatisch entwaffnet. Ergebnis: ein gebrochener Propeller.

Das ist das Muster, das einen stutzig machen muss: Ohne Wasser funktionierte derselbe Modus, mit Wasser kippte die Maschine beim ersten Meter. Ein reines „Loiter ist empfindlich"-Achselzucken hätte hier die eigentliche Ursache verdeckt.

Die Log-Auswertung

Nach dem Flug habe ich das BIN-Log gezogen und zuerst die üblichen Verdächtigen ausgeschlossen. Das ist wichtig, weil man sonst anfängt, an der falschen Stelle zu reparieren:

Kein Fehlercode, keine EKF-Diskontinuität, keine Vibrationsexplosion. Der Absturz war nicht als Error-Event sichtbar. Genau das macht solche Fälle unangenehm: Wer nur nach roten Meldungen sucht, findet nichts.

Das entscheidende Signal war kein Alarm, sondern der Vergleich zweier Parameter mit der realen Masse. Beim Boot stand im Log:

• MOT_THST_HOVER = 0,288
• MOT_HOVER_LEARN = 2 (lernen und speichern)

Und im Flugverlauf sieht man die Quittung: Die Ausgangs-Gasstellung (ThO) erreichte den Abhebewert 0,51 erst spät und unsauber, während die Drohne schon mit asymmetrischem Motor-Mix reagierte. Ein 29-%-Hover-Wert an einer Maschine, die real rund 55 % braucht, sind 25 Prozentpunkte Fehler im Vorsteuerwert — und zwar ab dem ersten Moment.

Warum das sofort durchschlägt: Der Höhenregler nutzt das Hover-Gas als Vorsteuerung (feed-forward). Der PID-Regler korrigiert nur noch die Restabweichung. Liegt die Vorsteuerung um ein Viertel daneben, muss der Regler permanent gegensteuern, saturiert, und in Loiter — wo Höhe und Position gleichzeitig gehalten werden — multiplizieren sich die Fehler in Z und XY.

Die Ursache

MOT_HOVER_LEARN = 2 bedeutet: Der Flugcontroller darf den Hover-Gaswert selbst lernen und im EEPROM speichern. Auf dem leichten Flug davor (nur rund 3,7 kg) hat er das getan und 0,288 gespeichert. Der Wert war für diese Masse korrekt — und blieb gespeichert.

Beim ersten Wasserflug war die Masse anders. Aber der gelernte Wert galt weiter. Niemand hat ihn zurückgesetzt. Die Drohne startete also mit einer Vorsteuerung, die zu einer 3,7-kg-Maschine passte, während unter ihr 7,2 kg hingen.

Warum das nicht offensichtlich war:

1. Kein Fehler außerhalb des Normbereichs. GPS, EKF, Vibration, Kompass — die vier, die man zuerst prüft — waren unauffällig. Das Log sah bis auf den Kippmoment „gesund" aus.
2. Der Parameter stand nicht in der .param-Datei. Er war im Flugcontroller gelernt und gespeichert worden — per grep in den Dateien nicht zu finden.
3. Die Warnung existierte, aber nur als Text. Die Doku warnte wörtlich vor genau diesem Muster — die Parameter selbst waren am Fluggerät aber nicht entsprechend gesetzt.
4. Contributing Factors verdeckten die Hauptursache. Beim abrupten Motor-Spinup schwappte das Wasser im Tank, der Schwerpunkt wanderte nach vorne. Das verstärkte den Nose-Down — aber ohne die falsche Vorsteuerung hätte die Regelung das weggearbeitet.

Die Kette war also nicht „Loiter ist instabil", sondern: gelernter Hover-Wert passt nicht mehr zur Masse → Vorsteuerung falsch → Regler saturiert → Selbstverstärkung im Loiter → Kippen.

Dieselbe Ursache, andere Richtung

Ein halbes Jahr später hat mir derselbe Parameter noch einmal einen Flieger gelegt — nur invers. Nach dem Rückbau von Spray-Armen und Pumpe wog die Maschine plötzlich nur noch rund 3 kg. Der Hover-Wert war aber noch auf 0,50 für die schwere Konfiguration gesetzt.

Ergebnis: derselbe Loiter-Start, diesmal Roll von −2° auf +173° in einer Sekunde. Zwei Propeller kaputt. Die erste Vermutung — „ein Motor ist defekt" — hielt einem Test nicht stand: Alle vier Motoren zogen symmetrisch. Erst der Log-Vergleich zeigte, dass auch hier nur der Hover-Wert nicht zur Masse passte.

Die Lehre in einem Satz: MOT_THST_HOVER ist kein „set and forget"-Wert. Er bildet das Verhältnis von Schub zu Gewicht ab — ändert sich die Masse, ändert sich der richtige Wert. Ein zu niedriger Wert lässt die Drohne sinken, ein zu hoher lässt sie übersteuern. Beide enden in einem Crash.

Nicht jede Oszillation ist ein Schub-Problem

Nicht jeder Absturz gehört in diese Schublade. In einem anderen Flug baute sich über die gesamte Flugdauer eine Lage-Oszillation auf — die Drohne pendelte sich nicht ein, und am Ende reichte eine einzelne Kante, um sie in einen Roll-Überschlag zu drehen. Hier war die Schubvorsteuerung korrekt kalibriert; das Problem lag woanders (Sensorik und eine Rückkopplung, die sich aufschaukelte).

Wichtig ist die Unterscheidung, die man im Log trifft: Ein einmaliger Kippmoment mit sauberen Sensoren deutet auf ein Modellproblem (Masse, Vorsteuerung). Eine Oszillation, die über Minuten kontinuierlich wächst, ist ein Regelkreis-Problem. Wer beides als „Loiter spinnt" zusammenwirft, sucht lange an der falschen Stelle. Beide Fälle haben eines gemeinsam: Der Log sagt dir, welcher es ist — aber nur, wenn du ihn dir ansiehst.

Die Gegenmaßnahme

Aus dem ersten Absturz wurde eine feste Regel, die vor jedem Flug mit geänderter Masse greift:

MOT_HOVER_LEARN = 0     # niemals lernen bei variablem Payload
MOT_THST_HOVER  = zur aktuellen Masse passend, manuell gesetzt

MOT_HOVER_LEARN = 0 ist die wichtigste Zeile. Bei einer Drohne mit variablem Payload (Tank!) darf der Controller den Hover-Wert nie selbst lernen und speichern — sonst friert er einen Zustand ein, der nur für genau eine Füllung galt. Den Wert setzt man manuell, passend zur realen Betriebsmasse.

Und die zweite Lehre: Was man zu setzen glaubt, ist nicht dasselbe wie das, was im Flug gilt. In einem späteren Fall habe ich einen Hover-Wert gesetzt und zweimal als korrekt zurückgelesen — im Flug-Log stand beim Boot trotzdem der alte Wert. Deshalb prüft man den effektiven Wert im Log des Flugs, nicht nur am Schreibtisch.

Lessons Learned

• Die Sensoren zuerst ausschließen, aber nicht bei ihnen stehen bleiben. GPS, EKF, Vibration und Kompass waren alle unschuldig. Das Ausschlussverfahren ist richtig — die Ursache lag danach eben eine Ebene höher, im Modell.
• Ein Absturz ohne Fehlermeldung ist trotzdem im Log. Das entscheidende Signal war ein falscher Parameter gegen die reale Masse, kein Error-Event.
• Gelernte Werte sind unsichtbare Zustände. Ein im EEPROM gelernter Parameter steht in keiner .param-Datei und ist per grep nicht zu finden. Wer die Flugbasis verifizieren will, muss ans Fluggerät, nicht nur ins Repo.
• Nach jeder Massenänderung ist der Hover-Wert neu zu setzen. Leichter oder schwerer — beides ist gefährlich. Der Parameter gehört zur Masse, nicht zur Drohne.
• Erster Flug mit neuer Konfiguration nie in Loiter. Loiter kombiniert Höhen- und Positionsregelung; ein Fehler in einem Subsystem schlägt auf beide durch. Die sichere Reihenfolge ist Stabilize → AltHold → Loiter.
• Das BIN-Log nach jedem Flug parsen. Dieser Absturz war in den Daten glasklar — ein automatischer Post-Flight-Check hätte ihn erkannt, bevor der nächste Flug überhaupt startete.

Checkliste nach Umbau oder Nutzlastwechsel

• MOT_HOVER_LEARN = 0 gesetzt (niemals lernen lassen)
• MOT_THST_HOVER an die reale Abflugmasse angepasst
• Effektiven Wert im Flug-Log nach dem Boot gegengeprüft, nicht nur am Schreibtisch
• Kalibrierungen wiederholt, die der Umbau invalidiert hat (u. a. Kompass, falls Struktur/Befestigung betroffen)
• Schwerpunkt voll und leer geprüft
• Erster Flug in Stabilize, danach AltHold, erst dann Loiter
• BIN-Log nach dem Flug gezogen und ausgewertet
• Auffälligkeiten (zu frühe/unsaubere Gasstellung, wachsende Lage-Oszillation) notiert, bevor der nächste Flug freigegeben wird