Wasserrakete · Flugrechner · Navigationsfilter
Wie die Rakete lernt, wo sie ist
Eine Rakete hat keinen Sinn für ihren eigenen Ort. Sie hat nur Sensoren, die alle lügen — jeder auf seine eigene Art. Das hier ist die Geschichte, wie man daraus trotzdem eine Antwort baut, und was dabei alles schiefging.
„Sie weiß, wo sie ist, weil sie weiß, wo sie nicht ist“
Es gibt einen berühmten Textausschnitt aus einem Ausbildungsfilm für Lenkflugkörper, der im Internet seit Jahren als Scherz herumgereicht wird, weil er sich beim Lesen immer weiter in sich selbst verheddert:
The missile knows where it is at all times. It knows this because it knows where it isn’t.
Der Witz daran ist die scheinbare Zirkularität. Der Haken ist: es stimmt. Nicht als Spruch, sondern erstaunlich wörtlich — der Ausschnitt beschreibt, ungeschickt formuliert, aber der Sache nach richtig, genau das Verfahren, um das es in diesem Artikel geht. Deshalb steht er hier am Anfang und nicht als Fußnote.
Der längere Teil, um den es gleich geht:
The missile knows where it is at all times. It knows this because it knows where it isn’t. By subtracting where it is from where it isn’t, or where it isn’t from where it is (whichever is greater), it obtains a difference, or deviation.
The guidance subsystem uses deviations to generate corrective commands to drive the missile from a position where it is to a position where it isn’t, and arriving at a position where it wasn’t, it now is.
Consequently, the position where it is, is now the position that it wasn’t, and it follows that the position that it was, is now the position that it isn’t.
Aus einem Ausbildungstext zu Lenksystemen · seit Jahren als Meme im Umlauf
Warum das kein Unsinn ist
Zeile für Zeile beschreibt der Text eine Regelschleife — und der Filter in dieser Rakete ist genau eine solche. Nebeneinandergestellt:
Warum „wo sie nicht ist“ der wichtigere Teil ist
Stell dir vor, du sollst mit geschlossenen Augen durch einen Raum gehen und die ganze Zeit sagen, wo du bist. Du kannst mitzählen: „drei Schritte, jeder etwa 70 Zentimeter“. Nach zehn Schritten bist du sicher falsch, aber du weißt nicht, wie falsch.
Jetzt darfst du gelegentlich mit der Hand die Wand berühren. Die Wand sagt dir nicht, wo du bist. Sie sagt dir, um wie viel du danebenlagst — und das ist die brauchbarere Information, weil du damit auch dein Schrittmaß korrigieren kannst, nicht nur deinen Standort.
Genau das tut der Filter. Das Barometer sagt ihm nicht, wo er ist. Es sagt ihm, um wie viel seine Vermutung danebenlag — und daraus lernt er nicht nur die Höhe, sondern auch, wie sehr seine Sensoren gerade danebenliegen.
Wo der Scherz aufhört, richtig zu sein
Zwei Stellen sind wirklich Unsinn, und beide sind lehrreich.
„whichever is greater“
„Wo es ist, minus wo es nicht ist — oder umgekehrt, je nachdem, was größer ist.“ Das ist der Punkt, an dem der Text kippt. Ein Vorzeichen ist keine Geschmacksfrage. Zieht man in der falschen Reihenfolge ab, korrigiert der Filter in die falsche Richtung, und die Abweichung wird mit jedem Schritt größer statt kleiner.
Der Text sagt nicht, wie stark korrigiert wird
Und das ist die eigentliche Frage. Der Barometer-Messwert schwankt um etwa 70 Zentimeter. Soll der Filter beim nächsten Messwert seine Höhe voll darauf setzen? Dann zappelt er mit dem Rauschen mit. Gar nicht? Dann läuft er langsam weg.
Die Antwort lautet: so stark, wie man der Messung im Vergleich zur eigenen Vermutung gerade trauen kann. Der Filter führt dazu Buch darüber, wie unsicher er sich selbst ist, und rechnet das Gewicht daraus in jedem Schritt neu aus.
Das ist der Unterschied zwischen dem Spruch und einem Kalman-Filter — und der Rest dieses Artikels handelt im Wesentlichen davon, wie schwer es ist, dieses Buchführen über Jahre… beziehungsweise über 50 Minuten stabil hinzubekommen.
Woher der Text stammt
Er wird üblicherweise einem Ausbildungsfilm zu Lenksystemen zugeschrieben. Die genaue Herkunft ist schwer zu belegen — als Erklärung taugt er trotzdem, und zwar unabhängig davon, wer ihn zuerst formuliert hat.
Das Problem: vier Sensoren, vier verschiedene Lügen
Auf dem Flugrechner sitzen vier Sensoren, und jeder hat eine andere Schwäche. Das ist der ganze Ausgangspunkt — wäre einer davon perfekt, bräuchte man keinen Filter.
| Sensor | misst | Stärke | Schwäche |
|---|---|---|---|
| Beschleunigungssensor | Kraft pro Masse | sehr schnell (100×/s), reagiert sofort | Um daraus die Position zu bekommen, muss man zweimal aufsummieren. Kleine Fehler werden dabei riesig. |
| Gyroskop | Drehrate | sehr schnell und sehr genau, kurzfristig | Ein winziger Nullpunktfehler summiert sich zu einer immer größeren Winkelabweichung. |
| Barometer | Luftdruck → Höhe | driftet nicht weg, langfristig verlässlich | verrauscht (±0,7 m), langsam, und Wetter verschiebt den Nullpunkt |
| GPS | Position, Geschwindigkeit | absolut — weiß, wo auf der Erde | langsam (1×/s), ungenau (Meter), kann ganz ausfallen |
Analogie
Stell dir vor, du gehst mit verbundenen Augen durch einen Raum. Du kannst deine Schritte zählen — das ist der Beschleunigungssensor: schnell und sofort, aber nach 50 Schritten weißt du nicht mehr genau, wo du bist. Ab und zu ruft dir jemand aus dem Nebenzimmer ungefähr zu, wo du stehst — das ist GPS: selten und ungenau, aber es driftet nicht weg.
Ein Navigationsfilter ist die Vorschrift, wie man diese beiden Informationen so verrechnet, dass das Ergebnis besser ist als jede einzelne für sich.
Warum das für dieses Projekt zählt
Das langfristige Ziel ist Schubvektorsteuerung: die Rakete soll ihre Düse aktiv schwenken und einer geplanten Bahn folgen. Eine Rakete kann nur dorthin steuern, wo sie zu sein glaubt. Ein Filter, der sich um 30 Meter irrt, steuert die Rakete um 30 Meter falsch. Deshalb wird der Filter zuerst auf einfachen Wasserraketen überprüft, bevor er irgendeine Entscheidung treffen darf.
Wichtige Sicherheitsregel dieses Projekts: Der neue Filter rechnet mit, aber er steuert nichts. Kein Fallschirm, keine Düse, keine Auslösung. Er wird beobachtet, bis er sich bewiesen hat. Wie sich später zeigen wird, war das keine übertriebene Vorsicht.
Die Grundidee: raten, dann korrigieren
Ein Kalman-Filter ist im Kern erstaunlich einfach. Er macht dauernd zwei Dinge abwechselnd:
ich sein?
eingetroffen
- Vorhersage. „Ich war hier, ich hatte diese Geschwindigkeit, der Beschleunigungssensor sagt mir das — also müsste ich jetzt dort sein.“ Das passiert 100-mal pro Sekunde.
- Korrektur. Kommt eine Messung herein (Barometer, GPS), vergleicht der Filter: „Ich dachte, ich bin auf 30,0 m. Das Barometer sagt 30,4 m.“ Die Differenz heißt Innovation — das Neue, was die Messung beiträgt.
Der eigentliche Trick: der Filter weiß, wie sicher er ist
Was den Kalman-Filter von einem simplen Mittelwert unterscheidet: Er führt nicht nur eine
Schätzung mit, sondern auch, wie sicher er sich ist. Diese Unsicherheit heißt
Kovarianz und wird meistens P genannt.
Was Kovarianz anschaulich bedeutet
Stell dir um deine geschätzte Position eine Wolke gezeichnet. Ist die Wolke klein, bist du dir sicher. Ist sie groß, bist du unsicher. Die Kovarianz ist die mathematische Beschreibung dieser Wolke.
Sie enthält aber mehr: auch, wie Unsicherheiten zusammenhängen. „Wenn ich mich bei der Höhe irre, dann irre ich mich wahrscheinlich auch bei der Steiggeschwindigkeit, und zwar in dieselbe Richtung.“ Diese Zusammenhänge sind das Wertvollste am ganzen Verfahren — durch sie kann eine Höhenmessung sogar die Geschwindigkeit verbessern, obwohl das Barometer Geschwindigkeit gar nicht misst.
Aus dieser Unsicherheit berechnet der Filter, wie stark er einer neuen Messung folgt — die Kalman-Verstärkung. Ist er sich sehr sicher und die Messung ist verrauscht, ignoriert er sie fast. Ist er unsicher, folgt er ihr bereitwillig. Das passiert automatisch, ohne dass jemand Regeln dafür schreibt.
Warum „Fehlerzustand“?
Der gebaute Filter heißt ESKF — Error-State Kalman Filter, Fehlerzustands-Kalman-Filter. Er schätzt nicht die Position selbst, sondern den Fehler der Position: „Wie sehr liegt meine Schätzung daneben?“
Das klingt umständlich, hat aber einen handfesten Grund: Drehungen. Eine Orientierung im Raum lässt sich nicht einfach addieren — dreht man erst um die eine, dann um die andere Achse, kommt etwas anderes heraus als in umgekehrter Reihenfolge. Die Mathematik gewöhnlicher Kalman-Filter setzt aber voraus, dass man Größen addieren darf. Rechnet man stattdessen mit kleinen Fehlern, ist dieses Problem weg: Sehr kleine Drehungen darf man addieren. Dieselbe Idee steckt in fast jedem echten Trägheitsnavigationssystem, von Apollo bis heute.
Der Filter führt 15 Zahlen mit, die zusammen den Zustand beschreiben:
| Zustand | Zahlen | Bedeutung |
|---|---|---|
| Position | 3 | Ost, Nord, Hoch — in Metern vom Startpunkt |
| Geschwindigkeit | 3 | in dieselben drei Richtungen |
| Lage | 3 | Ausrichtung im Raum |
| Gyroskop-Nullpunkt | 3 | der Fehler, den das Gyroskop dauerhaft hat |
| Beschleunigungs-Nullpunkt | 3 | dasselbe für den Beschleunigungssensor |
Die letzten sechs sind besonders interessant: Der Filter lernt die Fehler seiner eigenen Sensoren im laufenden Betrieb. Niemand muss sie vorher ausmessen.
Fünf Probleme, und was sie gelehrt haben
Der Filter war nach zwei Tagen geschrieben. Der Rest der Arbeit — der weitaus größere Teil — bestand daraus, herauszufinden, wo er falsch lag. Jeder dieser Fälle folgt derselben Form, und die Form ist wichtiger als die Einzelheiten.
Das Problem
Das Board lag still auf dem Tisch. Der Filter behauptete nach 78 Sekunden, es habe sich 2400 Meter weit bewegt.
Warum
Ein Beschleunigungssensor misst nicht Beschleunigung, sondern die Kraft, die auf ihn wirkt — und dazu gehört immer die Schwerkraft, 9,81 m/s². Um sie herauszurechnen, muss der Filter wissen, wie das Board im Raum liegt. Kippt seine Vorstellung davon nur um ein halbes Grad, rechnet er einen kleinen Rest der Schwerkraft als echte waagerechte Beschleunigung. Zweimal aufsummiert werden daraus Kilometer.
Das Barometer konnte nicht helfen: Es misst nur die Höhe und sagt über die Neigung nichts aus. Der Filter hatte schlicht keine Information über seine eigene Ausrichtung.
Die Lösung
Zwei Zusatzmessungen, die nur gelten, solange sich nichts bewegt. Erstens ZUPT (Zero Velocity Update): „Ich stehe still, also ist meine Geschwindigkeit null.“ Zweitens Schwerkraft-Nivellierung: „Ich stehe still, also zeigt der Beschleunigungsvektor genau nach unten — daran kann ich meine Lage ausrichten.“
Das Erkennen des Stillstands macht der Filter selbst aus den Rohdaten. Nach der Korrektur: 2 Zentimeter über sechs Stunden.
Das Problem
Der Filter muss wissen, wie stark seine Sensoren rauschen — sonst kann er nicht entscheiden, wie sehr er ihnen trauen soll. Diese Zahlen standen als grobe Schätzungen im Code.
Die Methode: Allan-Varianz
Man lässt den Sensor stundenlang still liegen und zeichnet alles auf. Dann mittelt man die Daten über verschieden lange Zeitfenster und trägt auf, wie stark die Mittelwerte noch schwanken.
Der Trick daran: Verschiedene Fehlerarten verhalten sich unterschiedlich. Zufälliges Rauschen mittelt sich weg — je länger man mittelt, desto ruhiger wird es. Ein langsam wandernder Nullpunkt tut das nicht. Trägt man beides zusammen auf, bekommt man eine Kurve, aus der man die verschiedenen Fehleranteile getrennt ablesen kann. Das ist Standardverfahren für Trägheitssensoren.
Das Ergebnis
Sechs Stunden Aufzeichnung, 1 079 001 Messpunkte. Die geschätzten Werte waren rund 50-fach zu pessimistisch. Der Filter hatte seinen eigenen Sensoren also deutlich weniger geglaubt, als sie verdient hätten.
Nebenbei fiel dabei ein Fehler im Auswerteprogramm auf: Es hatte die Abtastrate aus dem mittleren Zeitabstand berechnet und kam auf 62,5 Hz statt der echten 50 Hz. Alle Rauschzahlen waren dadurch um 12 % falsch. Behoben, indem die Rate aus Anzahl geteilt durch Gesamtdauer bestimmt wird.
Das Problem
Eine Routineabfrage am Flugrechner nach 53 Minuten Laufzeit zeigte:
- Position: 1 260 000 000 Meter (das ist mehr als dreimal die Entfernung zum Mond)
- Geschwindigkeit: 1 340 000 m/s
- Geschätzter Gyroskop-Nullpunkt: −286 rad/s — das sind 16 400 Grad pro Sekunde, bei einem Sensor, der überhaupt nur bis 2000 messen kann
- Jede Barometermessung wurde verworfen
Das Board lag dabei still auf dem Tisch.
Die Ursachenkette
Erinnerung an die Unsicherheitswolke aus Kapitel 2. Die Wolke war auf null zusammengefallen. Ein Filter mit einer Wolke der Größe null glaubt, er wisse alles perfekt — also folgt er keiner Messung mehr. Und weil er keiner Messung mehr folgt, werden seine Fehler immer größer, was die Messungen immer unglaubwürdiger erscheinen lässt. Ein Teufelskreis.
Die Wolke kollabierte, weil eine Rechenschutzmaßnahme sie kaputtmachte. Ein Computer rechnet mit begrenzter Genauigkeit; nach Millionen Rechenschritten kann eine Unsicherheit rechnerisch negativ werden, was physikalisch unmöglich ist. Der Code fing das ab, indem er den Wert einfach auf eine winzige positive Zahl setzte.
Warum genau das falsch war
Die Wolke ist kein einzelner Wert, sondern eine Tabelle von Zusammenhängen. Setzt man einen Eintrag auf einen neuen Wert und lässt alle anderen stehen, ist die Tabelle in sich widersprüchlich. Es ist, als würde man behaupten: „Über meine Höhe weiß ich absolut nichts, aber über den Zusammenhang zwischen meiner Höhe und meiner Geschwindigkeit weiß ich ganz genau Bescheid.“ Aus solchen Widersprüchen berechnet der Filter unsinnige Korrekturen.
Das Bittere daran: Vierzig Zeilen weiter oben in derselben Datei stand ein Kommentar, der genau davor warnte. Die Schutzmaßnahme tat exakt das, was der eigene Code als gefährlich beschrieb.
Warum 18 bestandene Tests das nicht gefunden haben
Der Fehler braucht zwei Zutaten gleichzeitig: eine merkliche Neigung des Boards und Zeit. Alle Tests liefen nahezu waagerecht und nur Sekunden bis Minuten. Keiner hatte beides.
Und die Neigungen, bei denen es schiefgeht, sind nicht geordnet: Bei 15° und 32° stirbt der Filter, bei 20° und 45° nicht. Der Fehler ist numerisch, nicht physikalisch — deshalb prüft der neue Dauertest sechs verschiedene Winkel. Ein einzelner Winkel hätte mit hoher Wahrscheinlichkeit einen der unauffälligen erwischt.
Die Sofortlösung
Statt einen Wert zu klemmen und die Widersprüche stehenzulassen, wird der betroffene Zustand entkoppelt: Alle seine Zusammenhänge werden auf null gesetzt und seine Unsicherheit auf den Startwert zurückgesetzt. Das sagt etwas Wahres — „über diesen Zustand weiß ich gerade wenig, und wie er mit den anderen zusammenhängt, weiß ich auch nicht“ — und bleibt in sich stimmig.
Das hielt den Filter am Leben. Es war aber nur ein Verband, kein Heilmittel: Über sechs Stunden echter Daten musste er 521-mal eingreifen. Etwa alle 42 Sekunden ging etwas kaputt, das dann repariert werden musste.
Die Idee
Wenn eine Größe nicht negativ werden darf, dann sollte man sie so speichern, dass sie gar nicht negativ werden kann.
Die Analogie, die alles erklärt
Angenommen, du sollst eine Zahl verwalten, die niemals negativ werden darf. Ein Weg: Du speicherst die Zahl und prüfst nach jeder Rechnung, ob sie noch positiv ist. Das ist fehleranfällig — irgendwann vergisst du eine Prüfung.
Der bessere Weg: Du speicherst nicht die Zahl selbst, sondern ihre Wurzel. Denn x² ist niemals negativ, egal was x ist. Du brauchst keine Prüfung mehr — die Form der Speicherung macht den Fehler unmöglich.
Was tatsächlich gemacht wurde
Genau das, nur für eine Tabelle statt für eine Zahl. Die Unsicherheitstabelle
P wird nicht mehr direkt gespeichert, sondern in zwei Teile zerlegt:
P = U · D · Uᵀ. Dabei ist D eine reine Liste von
Unsicherheiten und U beschreibt die Zusammenhänge.
Der Gewinn: Die Widerspruchsfreiheit der Tabelle hängt jetzt nur noch daran, dass die
Einträge in D positiv bleiben — und die Rechenvorschriften sind so gebaut,
dass sie das garantieren. Sie können D nur mit positiven Faktoren
multiplizieren, und eine positive Zahl mal einer positiven Zahl bleibt positiv.
Das Verfahren heißt Bierman-Thornton-UD-Filter und wurde in den 1970er Jahren am Jet Propulsion Laboratory der NASA für genau dieses Problem entwickelt. Es ist nicht neu und nicht ausgedacht — es ist die etablierte Antwort der Luft- und Raumfahrttechnik auf divergierende Filter.
Wie geprüft wurde, dass die Umsetzung stimmt
Eine falsch umgesetzte Version wäre schlimmer als gar keine: Sie sähe stabil aus und würde dabei still die falschen Korrekturen berechnen. Deshalb wurde ihr nicht geglaubt, sondern sie wurde verglichen.
Ein Testprogramm erzeugt 200 zufällige, absichtlich schlecht skalierte Rechenaufgaben
und löst jede zweimal: einmal mit dem neuen Verfahren, einmal mit der Lehrbuchformel in
doppelter Genauigkeit. Dann werden die Ergebnisse Eintrag für Eintrag verglichen. Ein
vierter Test treibt 200 000 harte Rechenschritte durch — genau das Szenario, das den
alten Filter zerstörte — und prüft, ob D positiv bleibt. Bleibt es.
Das Ergebnis, auf sechs Stunden echter Sensordaten
Dieselben aufgezeichneten Daten vom echten Flugrechner, durch beide Varianten desselben Programms geschickt. Das Board lag die ganze Zeit still.
Die Balken sind nicht maßstäblich — der erste Wert ist milliardenfach größer als die anderen und ließe sich sonst nicht darstellen.
| Kennzahl über 6 h echter Daten | mit Verband | mit UD-Form |
|---|---|---|
| Widersprüchliche Tabelle aufgetreten | 521 × | 0 × |
| Barometermessungen angenommen | 99,93 % | 99,996 % |
| Scheinbare Wanderung, Ende | 36,42 m | 0,02 m |
| Geschätzter Gyroskop-Nullpunkt | 0,047 rad/s | 0,025 rad/s |
| Geschätzter Beschleunigungs-Nullpunkt | 0,305 m/s² | 0,048 m/s² |
Die letzten beiden Zeilen sind der überzeugendste Teil, und zwar aus einem Grund, der nichts mit dem Filter zu tun hat: Das Datenblatt des Sensors gibt für den Beschleunigungs-Nullpunkt typisch etwa 0,2 m/s² an. Der Wert 0,305 war unplausibel hoch. Der Wert 0,048 liegt genau dort, wo er physikalisch hingehört. Der Filter schätzt also nicht nur stabiler, sondern richtiger — überprüfbar an einer Quelle außerhalb des Projekts.
Wenn eine Verbesserung drei andere Dinge kaputtmacht
Eine Anforderung lautete: Rohdaten immer aufzeichnen und übertragen, damit man nach dem Flug neue Algorithmen nachrechnen kann. Das wurde eingebaut — und brach nacheinander drei Dinge, von denen keines etwas mit Rohdaten zu tun hat.
Erstens: der Funkempfang hörte auf zu funktionieren
Die Bodenstation erkannte Paketgrenzen an Sendepausen: 50 ms Stille bedeutete „Paket zu Ende“. Das war gemessen worden und stimmte — solange nur der Beacon sendete.
Mit den zusätzlichen Rohdaten war der Kanal ausgelastet. Die Pausen traten schlicht nicht mehr auf. Eine echte 60-Sekunden-Aufnahme dekodierte null Pakete, während der Flugrechner einwandfrei sendete.
Die Lösung: Pakete werden nicht mehr an Pausen erkannt, sondern an ihrer Struktur. Dabei stellte sich heraus, dass eine Prüfsumme allein nicht reicht. Die verwendete Prüfsumme hat 8 Bit, passt also bei rein zufälligen Bytes mit einer Wahrscheinlichkeit von 1 zu 256. Prüft man sie einmal pro Paket, ist das unerheblich. Sucht man aber an jeder Byte-Position, wird es zur Regel: In einem Teststrom mit 6 Paketen wurden 33 Stellen als „gültig“ erkannt, von denen 27 falsch waren.
Die endgültige Lösung wählt deshalb die Aufteilung, die die meisten Bytes erklärt. Ein Falschtreffer überlappt fast immer das nächste echte Paket und verliert dadurch. Zwei naheliegendere Varianten wurden vorher verworfen — besonders die, die ein Paket nur akzeptiert, wenn ein weiteres folgt: Die hätte genau die Pakete weggeworfen, die kurz vor einer Funkstörung ankommen. Also die wertvollsten.
Zweitens: ein einziges gestörtes Paket konnte die Verbindung killen
Beim Testen mit absichtlichem Rauschen fiel ein älterer Fehler auf: Ein Paket mit einem ungültigen Zustandsbyte löste eine Ausnahme aus, die den Empfangs-Thread der Bodenstation beendete. Ein einziges zufällig durchgerutschtes Störpaket hätte die gesamte Live-Telemetrie abgerissen — bei schwacher Verbindung, also im Flug. Regel daraus: Nichts, was aus empfangenen Bytes berechnet wird, darf eine Ausnahme in die Empfangsschleife werfen. Ein schlechtes Paket darf ein Paket kosten, niemals die Verbindung.
Drittens: der Rückkanal starb
Befehle von der Bodenstation zur Rakete kamen nicht mehr an. Der entscheidende Hinweis kam
vom Zähler im Flugrechner selbst: Kommandos empfangen = 10, und diese Zahl
stand fest, während 150 Befehle gesendet wurden.
Das Funkmodul speichert zwischen, was es noch nicht abgestrahlt hat. Gibt man ihm mehr, als es senden kann, wächst dieser Rückstau. Und weil das Modul halbduplex arbeitet — es kann entweder senden oder empfangen, nie beides —, kommt es nie wieder in den Empfangsmodus. Anfangs war die Warteschlange leer, deshalb kamen die ersten 10 Befehle durch. Danach nie wieder.
Gelöst durch eine Aufteilung nach Flugphase, die kein Kompromiss ist, weil die beiden Bedürfnisse zeitlich getrennt sind und in entgegengesetzte Richtungen zeigen:
- Am Boden zählt der Rückkanal (Log löschen, Status abfragen). Rohdaten per Funk sind hier fast wertlos — die Rakete liegt vor einem und der Speicher zeichnet dieselben Daten in voller Auflösung auf.
- Im Flug ist der Rückkanal ohnehin abgeschaltet (bewusst, aus Sicherheitsgründen), und die Funk-Rohdaten werden zur einzigen Kopie, die überlebt, falls die Rakete nicht wiedergefunden wird.
Das eigentlich Lehrreiche: Eine Funktion, drei Ausfälle — und keiner davon hatte mit den Daten zu tun, die sie hinzufügte. Alle drei hatten damit zu tun, wie ausgelastet der gemeinsame Kanal wurde. Kein Korrektheitstest findet so etwas, weil Auslastung keine Eigenschaft eines einzelnen Bauteils ist. Sie entsteht erst im Zusammenspiel.
Zwei eigene Denkfehler, und warum sie hier stehen
Diese beiden gehören genauso zur Geschichte wie die technischen Fehler — sie zeigen, wie man sich beim Messen selbst täuscht.
Was ich behauptet habe
„Die Rohdaten haben den Rückkanal getötet.“ Beleg: PING 0 von 25 gemessen, historisch waren es 20 von 20.
Was daran nicht stimmte
Meine Messung lief, während der Flugrechner im Zustand ARMED war. Der Rückkanal hört aber nur in den Zuständen IDLE, LANDED und ERROR zu — das ist eine bewusste Sicherheitseigenschaft. Die historischen 20 von 20 stammten aus IDLE.
Ich habe also zwei verschiedene Zustände verglichen und den Unterschied der einzigen Sache zugeschrieben, die ich zuletzt geändert hatte. Die Zahlen waren echt, die Schlussfolgerung nicht.
Die Regel daraus
Ein Unterschied zwischen zwei Messungen ist nur dann ein Beleg für die Sache, die man geändert hat, wenn nichts anderes verschieden war. Hier war der Flugzustand verschieden, und er war die ganze Erklärung.
Ironischerweise war die Schlussfolgerung am Ende trotzdem richtig — die Rohdaten stören den Rückkanal, wie die spätere korrekte Messung in IDLE zeigte. Aber zufällig recht zu haben ist keine Methode.
Was passierte
Nachdem ich den ersten Fehler bemerkt hatte, machte ich es „richtig“: abwechselnd mit und ohne Hörfenster messen, mehrfach, um zeitliche Effekte auszumitteln. Ergebnis: 0 von 36 in beiden Varianten. Sah nach einem sauberen Beleg aus, dass das Fenster nichts bringt.
Warum auch das falsch war
Zwischen dem Umschalten und dem Messen lagen nur 1,5 Sekunden. Der aufgestaute Sendepuffer des Funkmoduls braucht viel länger, um sich zu leeren. Ich habe also in beiden Varianten dasselbe verstopfte Modul gemessen.
Mit 20 Sekunden Wartezeit kam heraus: ohne Fenster 0 von 10, mit Fenster 6 bis 8 von 10. Das Fenster wirkt sehr wohl.
Die Regel daraus
Beide Denkfehler sind derselbe in anderer Verkleidung: Eine Zahl als Beleg für eine Ursache zu nehmen, ohne sichergestellt zu haben, dass alles andere wirklich gleich war. Beim ersten Mal war es der Flugzustand, beim zweiten Mal der Zustand des Funkmoduls.
Derselbe Filter, zweimal gemessen, zwei Sieger
In der Nacht auf den 30. August wurde derselbe Vergleich noch einmal gerechnet — diesmal mit Daten aus dem Flugspeicher statt aus der Daueraufnahme. Gleiche Rakete, gleiches Programm, gleicher stillstehender Tisch. Das Ergebnis kehrte sich um:
| Verfahren | bei 50 Messungen/s | bei 5 Messungen/s |
|---|---|---|
| Komplementärfilter | 0,0900 m/s | 0,0871 m/s |
| Kalman, 2 Zustände | 0,0317 m/s | 0,0244 m/s |
| ESKF, 15 Zustände | 0,0044 m/s | 0,0289 m/s |
Bei 50 Messungen pro Sekunde ist der große Filter siebenmal genauer als der kleine. Bei 5 Messungen pro Sekunde ist er schlechter.
Und beim genauen Nachprüfen wurde es deutlich schlimmer
Die beiden Spalten stammen aus verschiedenen Aufnahmen. Damit ist die Rate nicht der einzige Unterschied — also wurde der Versuch sauber wiederholt: dieselbe 50-Hz-Aufnahme, nur jeder zehnte Datensatz behalten. Jetzt ändert sich wirklich nichts außer der Rate.
Der große Filter ist dann nicht „etwas schlechter“. Er zerlegt sich: nach einer Minute meldet er −9,9 Meter und 42 Meter pro Sekunde Sinkrate, nach einer Stunde −64 Millionen Meter.
| Zeit | gemeldete Höhe | Unsicherheit |
|---|---|---|
| 0,2 s | 38,5 m | 0,69 m |
| 12 s | 38,3 m | 0,16 m |
| 24 s | 32,5 m | 0,34 m |
| 60 s | −9,9 m | 1,1 m |
| 120 s | −6 047 m | 1005 m |
Die Ursache steht in der dritten Spalte. Nach zwölf Sekunden ist der Filter sehr sicher geworden — 16 Zentimeter Unsicherheit. Ein Vorhersageschritt über 200 Millisekunden bringt aber deutlich mehr Fehler mit sich, als diese Sicherheit zulässt. Also hält der Filter die nächste Barometermessung für unglaubwürdig und wirft sie weg. Und die übernächste. Von 17 978 Messungen nahm er 116 an. Ohne Stützung rechnet er nur noch seinen Beschleunigungssensor hoch, und der läuft weg.
Das Unangenehme: Der Lauf mit den Flugspeicherdaten wird bei Sekunde 12 genauso übersicher (0,15 m) — und fängt sich wieder. Zwei fast gleiche Ausgangslagen, zwei entgegengesetzte Ausgänge. Bei 5 Messungen pro Sekunde steht dieser Filter also auf der Kippe. Der eine Datensatz hat überlebt; sicher war er nicht.
Warum das den Flug nicht betrifft — und warum es trotzdem wichtig ist
An Bord läuft der Filter mit 100 Messungen pro Sekunde, zwanzigmal so oft. Die 5 pro Sekunde sind nur die Rate, mit der vor dem Start ins Protokoll geschrieben wird. Der Flugrechner gerät nie in diesen Bereich.
Wichtig ist es aus einem anderen Grund. Ich war im Begriff, „bei 5 Hz etwas schlechter“ als Ergebnis aufzuschreiben. Das wäre eine ordentlich klingende, mit echten Zahlen belegte und falsche Aussage gewesen — und sie wäre nur deshalb nicht falsch aufgefallen, weil zufällig der eine Datensatz gewählt worden war, der durchkommt.
Gerettet hat es der kontrollierte Versuch: dieselben Daten, nur ausgedünnt. Zwei Messungen aus zwei verschiedenen Aufnahmen zu vergleichen und den Unterschied einer einzelnen Größe zuzuschreiben, ist genau der Fehler, der in dieser Nacht schon zweimal vorkam.
Warum das kein Widerspruch ist
Stell dir zwei Leute vor, die im Dunkeln durch einen Raum gehen sollen und alle paar Meter kurz die Wand berühren dürfen.
Der eine zählt einfach seine Schritte grob mit. Der andere achtet zwischen den Wandberührungen genau auf jede Bewegung: Schrittlänge, Drehung, Neigung. Wenn beide die Wand oft berühren dürfen, ist der Sorgfältige klar besser — seine feine Zwischenrechnung zahlt sich aus.
Erlaubt man ihm aber nur alle zehn Meter einen Handgriff und fragt ihn auch nur dann nach seiner Position, dann nützt ihm seine Sorgfalt wenig. Er hat dieselben groben Sprünge zu überbrücken wie der andere — und mehr Größen, in denen sich dabei Fehler ansammeln können.
Genau das ist der Unterschied. Der große Filter verdient seinen Vorsprung zwischen den Messungen. Nimmt man ihm diese Zwischenschritte, bleibt vom Vorsprung nichts.
Was das für die Entscheidung bedeutet — und was nicht
Es ändert sie nicht. An Bord laufen alle Filter mit 100 Messungen pro Sekunde. Die 5 pro Sekunde sind nur die Rate, mit der vor dem Start ins Protokoll geschrieben wird — die rechte Spalte beschreibt also die Nachrechnung, nicht den Flugrechner.
Es ändert aber, wie man solche Tabellen liest:
Ein Filtervergleich lässt sich nur dann auf den Flug übertragen, wenn er mit der Flugrate gerechnet wurde. Und selbst die linke Spalte, auf der die Entscheidung beruht, ist mit 50 statt 100 noch um den Faktor zwei zu langsam.
Praktische Folge: Eine Nachrechnung aus dem Flugspeicher taugt für die Flugphasen, in denen mit 100 pro Sekunde geschrieben wird. Für die Wartezeit auf der Rampe, wo mit 5 geschrieben wird, sagt sie über diesen Filter nichts Verwertbares aus.
Die Nachrechnung sagt das jetzt von selbst
Das Vergleichsprogramm hatte die Abtastrate fest eingebaut — 50 pro Sekunde, richtig für die Daten, gegen die es geschrieben wurde. Mit Flugspeicherdaten gefüttert rechnete es alles zehnmal zu schnell und meldete „0,10 Stunden“ für eine Stunde Daten. Die Zahlen sahen dabei völlig plausibel aus, und das ist das Gefährliche an dieser Art Fehler.
Jetzt nimmt es die Zeit aus den Daten selbst — jeder Datensatz hat einen Zeitstempel — und schreibt die erkannte Rate in die Ausgabe, mit einem Hinweis, wenn sie langsamer als 50 ist. Nebenbei fiel dabei auf, dass eine Flugspeicherdatei neun getrennte Sitzungen enthielt: Die Uhr zählt ab dem Einschalten, und der Speicher wird zwischen Neustarts nicht geleert.
Das Vorgehen, das sich bewährt hat
Auf dem PC iterieren, auf der Hardware beweisen
Ein Versuch auf der Hardware dauerte anfangs etwa eine Stunde — der Fehler brauchte 53 Minuten, um aufzutreten. Sechs Stunden aufgezeichnete echte Sensordaten laufen auf dem Laptop in 23 Sekunden durch. Das ist ein Faktor von etwa 900.
Entscheidend dabei: Das Testprogramm auf dem PC übersetzt die echte Filterdatei aus dem Flugrechner-Code, keine Nachbildung. Eine Nachbildung würde man testen, während etwas anderes fliegt. Trotzdem bleibt die Hardware die Instanz — Fließkommazahlen runden auf einem PC minimal anders als auf dem Mikrocontroller, und bei einem numerischen Fehler ist ausgerechnet das relevant.
Ein Test, der nur bestehen kann, beweist nichts
Nach jeder Reparatur wurde die kaputte Version wiederhergestellt und der neue Test gegen sie laufen gelassen. Fällt er nicht durch, prüft er nicht, was er zu prüfen vorgibt. Beim Kovarianz-Test war das der wichtigste Schritt überhaupt: Er fiel gegen den alten Filter durch und bestand gegen den neuen — erst damit war er ein Beleg.
Messen statt schätzen, wo immer es geht
Rauschparameter wurden gemessen statt geschätzt (50-fach daneben). Die Erdbeschleunigung wird beim Start ausgemessen (9,957 statt 9,81 m/s²). Die Wirkung des Hörfensters wurde gemessen statt begründet. Und wo etwas nicht gemessen wurde, steht das ausdrücklich dabei — zum Beispiel, dass die Funkreichweite bei reduzierter Sendeleistung nie geprüft wurde.
Alte Verfahren behalten, nicht ersetzen
Der alte Filter läuft weiterhin parallel mit, und auch die alte Kovarianzform lässt sich per Schalter wieder aktivieren. Nur deshalb war der Vergleich auf identischen Daten überhaupt möglich — und dieser Vergleich ist der einzige Beleg dafür, dass die neue Version derselbe Filter ist, nur stabil, und nicht einfach ein anderer.
Wo es steht, und was fehlt
Belegt auf der echten Hardware
| Größe | Wert | Bedeutung |
|---|---|---|
| Unsicherheit der Höhe | 0,033 m | der Filter kennt seine Höhe auf gut 3 cm |
| Verworfene Barometermessungen | 0 | er glaubt seinen Sensoren wieder |
| Gyroskop-Nullpunkt | 0,0054 rad/s | 0,3 °/s — genau im Datenblattbereich |
| Dauerlauf ohne Zusammenbruch | > 59 min | vorher starb er nach 53 |
Die wichtigste verbleibende Lücke
Fast alles ist im Ruhezustand belegt. Ein stillstehendes Board kann einen guten Schätzer nicht von einem unterscheiden, der einfach null ausgibt, wenn nichts passiert. Es fehlt ein Bewegungstest: das Board eine gemessene Höhe anheben, halten, absenken. Ein einziger solcher Durchgang beantwortet mehrere offene Fragen gleichzeitig — und er braucht einen Menschen.
Was noch aussteht
- Bewegungstest — mit Abstand der wertvollste offene Punkt
- Magnetometer — vorbereitet, aber nicht verbaut. Ohne ihn ist die Gierrichtung nicht dauerhaft bestimmbar; genau dieser unbeobachtbare Freiheitsgrad steckte hinter dem Kovarianz-Problem.
- Temperaturkompensation — die Sensornullpunkte wandern mit der Temperatur. Die Daten werden aufgezeichnet, aber noch nicht genutzt.
- Funkreichweite — bei reduzierter Sendeleistung nie gemessen
- Die Umschaltung — der neue Filter darf noch nichts steuern. Wann er das darf, ist eine bewusste Entscheidung, keine technische.
Begriffe
- Kalman-Filter
- Ein Verfahren, das eine Vorhersage und eine Messung so verrechnet, dass das Ergebnis besser ist als beide einzeln — und dabei mitführt, wie sicher es sich ist.
- Kovarianz (
P) - Die „Unsicherheitswolke“ um die Schätzung. Enthält nicht nur, wie unsicher jede einzelne Größe ist, sondern auch, wie die Unsicherheiten zusammenhängen.
- Innovation
- Die Differenz zwischen dem, was der Filter erwartet hat, und dem, was gemessen wurde. Nur dieser Unterschied trägt neue Information.
- Innovationsgatter
- Eine Prüfung, ob eine Messung zu unglaubwürdig ist, um sie zu verwenden. Schützt vor Sensorausfällen — aber wenn der Filter selbst kaputt ist, verwirft es plötzlich alles.
- ZUPT (Zero Velocity Update)
- „Ich stehe still, also ist meine Geschwindigkeit null.“ Klingt trivial, ist aber eine echte Messung mit hohem Informationsgehalt.
- Allan-Varianz
- Ein Verfahren, das aus einer langen Ruhemessung die verschiedenen Fehlerarten eines Sensors getrennt sichtbar macht — zufälliges Rauschen mittelt sich weg, ein wandernder Nullpunkt nicht.
- UD-Faktorisierung
- Die Unsicherheitstabelle wird als Produkt zweier Teile gespeichert statt direkt. Dadurch wird ein bestimmter Rechenfehler nicht nur unwahrscheinlich, sondern unmöglich.
- Beobachtbarkeit
- Ob die vorhandenen Sensoren eine Größe überhaupt bestimmen können. Ohne Magnetometer ist die Gierrichtung im Stillstand nicht beobachtbar — kein Filter der Welt kann das reparieren, weil die Information schlicht fehlt.
- Halbduplex
- Ein Funkmodul, das entweder senden oder empfangen kann, nie beides gleichzeitig. Wer zu viel sendet, hört nichts mehr.