65 Jahre bemannte Raumfahrt: Die Evolution der orbitalen Mechanik

[TomS]

Vielleicht solltest du deine Methode der Lie-Algebren-Integration mal beim DLR oder der ESA vorstellen – wenn das die Recheneffizienz der aktuellen Quaternionen-Systeme schlägt, hättest du dort sicher einen Stein im Brett!

Ich kann mir nicht vorstellen, dass die das nicht kennen.

Aber wenn ich Zeit habe, schaue ich mir mal ein paar numerische Methoden dazu genauer an.

 

[TomS]

Strahlungshärtung vs. Taktrate

Verstanden.

Rechenökonomie

Ich glaube nicht, dass der o.g. Ansatz da so viel schlechter abschneidet. Aber das kann man ja messen.

Speicherplatz und Komplexität

Verstanden.

Das Umschalten zwischen verschiedenen Koordinaten-Karten (dein Atlas-Ansatz) erhöht die Komplexität der Software und den Speicherbedarf für die Standard-Bibliotheken massiv.

Der Ansatz ist vermutlich nur dann sinnvoll, wenn diese Karten vermieden werden können. Für die von dir genannte kinematische Gleichung ist das möglich, für weitere Gleichungen evtl. nicht. Nichts schlimmeres, einen Ansatz zu verfolgen, der sich langfristig als Sackgasse herausstellt.

Echtzeitfähigkeit

Du meinst harte Echtzeitfähigkeit? Also eine Integration gesichert innerhalb einer festen Zeit?

Ich finde es klasse, dass wir das Thema so tief durchdrungen haben.

Ja, ich finde das auch spannend

 

[albertus]

Du meinst harte Echtzeitfähigkeit? Also eine Integration gesichert innerhalb einer festen Zeit?

Ja, die Bordcomputer haben eine "innere Uhr" die im 100ms-Takt tickt.

 

[TomS]

Ja, die Bordcomputer haben eine "innere Uhr" die im 100ms-Takt tickt.

Das haben ja letztlich alle Computer. Aber nicht jedes Software garantiert, dass sie ein Ergebnis nach höchstens x Millisekunden (= realtime) oder nach exakt x Millisekunden (isochronous realtime) abliefert.

 

[albertus]

Genau, TomS, ich meine die harte Echtzeit. Im Flugregler gibt es kein 'Warten auf den Prozessor'. Wenn die Integration der kinematischen Gleichung den 100ms-Slot reißt, läuft der Regelkreis instabil. Das ist ja der Grund, warum wir die Rechenökonomie so priorisieren müssen und komplexe Kartenwechsel im Speicher nach Möglichkeit vermeiden.

 

[TomS]

Ich fasse meine Idee nochmal kurz zusammen.

Wir haben den 3er-Vektor x und die momentane Drehung, generiert durch das Vektorprodukt

Wir schreiben x in bekannter Form als Quaternion bzw. Element der su(2) Algebra

und formulieren die Bewegungsgleichung um mittels

U lebt dabei in der Fundamentaldarstellung der SU(2), liefert jedoch die adjungierte Darstellung vermöge der Wirkung auf X, wobei X seinerseits in der Fundamentaldarstellung der su(2) lebt. Das zusammen liefert eine Darstellung der SO(3).

Der Zusammenhang zwischen omega und A lautet dabei

wobei die Pauli-Matrizen als Generatoren und die omegas als Rotationsparameter auftreten.

Für beliebige zeitabhängige Rotation d.h. zeitabhängige omegas integriert man die Bewegungsgleichung für U(t) mit der Anfangsbedingung U(0) = 1

Möchte man über kurze jedoch nicht-infinitesimale Zeitintervalle integrieren, so kann man die weiter oben genannten Methoden analog zu RK4 einführen; ich verzichte zunächst mal darauf. Das zeitgeordnete Produkt ist ein Element der SU(2) mit der Eigenschaft

Insbs. gilt

wobei A_n die zum Zeitpunkt t_n vorliegende Rotation gemäß omega, und Delta t_n das jeweilige Zeitintervall bezeichnet.

Die Lösung für den Vektor X(t) folgt dann wie oben, für ein iteratives Vorgehen je neuem Zeitschritt zu

Das Schöne an der Darstellung ist, dass man einfach je Zeitschritt mit der infinitesimalen Rotation multiplizieren kann, dass die Norm automatisch erhalten ist, und dass U bzw. A unmittelbar aus omega folgen. Eine Umrechnung zwischen verschiedenen Koordinatensystemen und Darstellungen ist nicht notwendig (falls man omega direkt verwenden darf, wovon ich immer ausgegangen bin; falls das nicht zutrifft, geht ein wesentlicher Vorteil verloren). Ein Nachteil besteht ggf. darin, dass die Einführung von Methoden analog zu RK4 notwendig und aufwändig wird, und dass die kompakte Form zerbröselt. Allerdings könnten man tatsächlich jede Matrix je Schritt n dergestalt auffassen, die Mathematik ließe das zu.

In der von mir genannten Form muss das letztlich die von euch verwendete Integration der Bewegungsgleichung mittels Quaternionen sein, denn die Entsprechung zwischen su(2) & SU(2) sowie Quaternionen ist eins-zu-eins; ich habe da sicher nichts neues entdeckt.

 

[TomS]

Genau, TomS, ich meine die harte Echtzeit. Im Flugregler gibt es kein 'Warten auf den Prozessor'. Wenn die Integration der kinematischen Gleichung den 100ms-Slot reißt, läuft der Regelkreis instabil. Das ist ja der Grund, warum wir die Rechenökonomie so priorisieren müssen und komplexe Kartenwechsel im Speicher nach Möglichkeit vermeiden.

Nun, die Matrixoperationen sind echtzeitfähig, insofern sie eine feste Anzahl von Schritten (FLOPS) benötigen. Wie gerade geschrieben, vom Grundgerüst her muss das (mit Ausnahme von RK4) eurer Lösungsmethode entsprechen.

 

[Jakito]

2. Rechenökonomie: Jeder Rechenzyklus kostet Energie und erzeugt Wärme, die im Vakuum schwer abzuführen ist. Die Quaternionen-Kinematik nutzt nur einfache Multiplikationen und Additionen. Ein Lie-Gruppen-Integrator hingegen erfordert die Berechnung von Matrix-Exponentialsätzen oder hohen Taylor-Reihen in jedem Zeitschritt – das ist für diese CPUs purer „Rechen-Luxus“.

Ich vermute, der Teil mit der Berechnung von Matrix-Exponentialsätzen oder hohen Taylor-Reihen täuscht ein wenig. Das M in dem Paper oben, wo ich RKMK nachgelesen habe, ist nämlich eine allgemeine Manigfaltigkeit, mit einem allgemeinen Vektorfeld. Demnach kann man M so parameterisieren, wie es am billigsten ist.

Und auch die iterierten Poisson-Klammern müssen nicht zwangsläufig schlecht sein. Dies sind vermutlich nur höhere Ableitungen der Koordinatendarstellung der Manigfalitgkeit, und nicht des zu integierenden Vektorfeldes. Problematischer ist, dass es "zu viele" Luft- und Raumfahrtingenieure überfordern könnte.

In der von mir genannten Form muss das letztlich die von euch verwendete Integration der Bewegungsgleichung mittels Quaternionen sein, denn die Entsprechung zwischen su(2) & SU(2) sowie Quaternionen ist eins-zu-eins; ich habe da sicher nichts neues entdeckt.

Ich vermute, es wird schon Unterschiede zwischen RKMK und RK4 geben. Bei RK4 ist ja gar nicht genau spezifiziert, wie zurück auf die Mannigfaltigkeit projiziert werden soll. Andererseits entfernt man sich bei RK4 auch gar nicht so schnell von der Mannigfaltigkeit, weil ja ihre Einbettung in einen höherdimensionalen Umgebungsraum mit benützt wird.

3. Speicherplatz und Komplexität: Bordsoftware muss „Lean“ sein. Weniger Code bedeutet weniger Fehlermöglichkeiten bei der Validierung. Das Umschalten zwischen verschiedenen Koordinaten-Karten (dein Atlas-Ansatz) erhöht die Komplexität der Software und den Speicherbedarf für die Standard-Bibliotheken massiv.

Die Koordinaten-Karten selbst sind oft total harmlos, nur das Umschalten ist gefährlich (und erhöht deshalb die Komplexität). Aber der Speicherbedarf wird dadurch auch nicht massiv erhöht.


Ich vermute, nur weil wir eine "Vorsicht Stufe" Warnung gegeben haben, und irgendjemand uns gebeten hat, ihm zu erklären, warum eine Stufe jetzt so ungeheuer gefährlich sein soll, erwartet keiner von uns, Stufen künstlich als gefährlicher darzustellen, als sie wirklich sind. Manchmal stolpert halt jemand, aber selbst wenn jemand stolpert, passiert meist auch nicht viel.

 

[albertus]

Numerische Präzision vs. Rechenökonomie (Benchmark)​

Um die Diskussion um „Rechen-Luxus“ und „Stufen“ zu versachlichen, habe ich die beiden Integrationsansätze in einer Simulation mit 10.000 Iterationen gegenübergestellt.

Die Fragestellung: Wie viel CPU-Leistung kostet uns die theoretische Eleganz?

1. Die Präzisions-Analyse (Drift-Korrektur)

Ein Standard-Integrator wie RK4 verlässt ohne Korrektur die Mannigfaltigkeit (die Determinante der Drehmatrix weicht von 1,0 ab). In der Praxis nutzen wir hier die „billige“ Projektion: Eine einfache Normalisierung nach jedem Schritt drückt den Fehler sofort wieder auf Maschinengenauigkeit.

2. Die Ressourcen-Analyse (Benchmark)

Der Lie-Gruppen-Integrator (RKMK) bleibt zwar exakt auf der Gruppe, benötigt dafür aber pro Zeitschritt die Berechnung der Matrix-Exponentialfunktion expm.

Ergebnis meines Tests (10.000 Iterationen):

• RK4 + Normalisierung: Rechenzeit im Bereich von Millisekunden.
• Lie-Integration ($expm$): Faktor 50 bis 100 langsamer.
  

import numpy as np
import matplotlib.pyplot as plt
import time
from scipy.linalg import expm

def skew(w):
    """Schiefsymmetrische Matrix (Generator der su(2))"""
    return np.array([[0, -w[2], w[1]], [w[2], 0, -w[0]], [-w[1], w[0], 0]])

# Benchmark: 10000 Iterationen
omega = np.array([0.1, 0.5, 0.2])
dt = 0.01

# RK4 + Normalisierung (vereinfachtes Schema)
start_rk = time.perf_counter()
q = np.array([1.0, 0.0, 0.0, 0.0])
for _ in range(10000):
    q = q + (0.5 * dt) * q # Beispielhafter Rechenschritt
    q /= np.linalg.norm(q) # Die "billige" Projektion
t_rk = time.perf_counter() - start_rk

# Lie-Integration (expm)
start_lie = time.perf_counter()
R = np.eye(3)
for _ in range(10000):
    R = expm(skew(omega) * dt) @ R
t_lie = time.perf_counter() - start_lie

# Visualisierung
plt.bar(['RK4 + Normalisierung', 'Lie-Integration (expm)'], [t_rk, t_lie], color=['green', 'red'])
plt.title("Numerische Präzision: 'Luxus Genauigkeit' frisst CPU")
plt.ylabel("Rechenzeit (Sekunden)")
plt.show()

3. Fazit für die Praxis​

Die Simulation verdeutlicht, dass die Lie-Integration (RKMK) um ein Vielfaches (oft Faktor 50+) langsamer ist. In der Raumfahrt ist Rechenleistung jedoch ein knappes Gut:

1. Thermische Last: Komplexe Berechnungen erzeugen Abwärme, die im Vakuum schwer abzuführen ist.
2. Abtastrate: Ein schnellerer, "einfacher" Algorithmus erlaubt höhere Abtastraten der Sensoren, was die Gesamtgenauigkeit in dynamischen Situationen oft stärker verbessert als ein theoretisch exakterer Integrator.

In der Raumfahrt ist Rechenzeit gleichbedeutend mit Energieverbrauch und thermischer Last. Die „Stufe“ der Normalisierung ist kein Mangel an Präzision, sondern eine notwendige Optimierung. Ein schnellerer Algorithmus erlaubt höhere Abtastraten der Sensoren, was für die Stabilität realer Systeme oft entscheidender ist als die mathematische Schönheit des Integrators.

Die "Stufe" der Normalisierung ist kein Stolperstein, sondern eine hocheffiziente Methode, um mit minimalem Rechenaufwand maximale Stabilität zu garantieren.

 

[Jakito]

Um die Diskussion um „Rechen-Luxus“ und „Stufen“ zu versachlichen

Der Lie-Gruppen-Integrator (RKMK) bleibt zwar exakt auf der Gruppe, benötigt dafür aber pro Zeitschritt die Berechnung der Matrix-Exponentialfunktion expm.

Nein, so ist RKMK "vermutlich" nicht gemeint. Und es ist auch gar nicht wichtig, ob RKMK jetzt gut oder schlecht ist, oder ob Du RKMK richtig interpretiert hast, oder nicht. Du musst hier gar nicht beweisen, dass RKMK schlecht ist. Und Du musst auch gar nicht verstehen, wie RKMK genau gemeint ist.

 

[albertus]

Hallo Jakito, vielen Dank für deine Erläuterung. Mir geht es gar nicht um eine Bewertung von RKMK als rein mathematisches Verfahren – dieses hat in der theoretischen Numerik zweifellos seine Eleganz.

Worauf ich für die Mitleser hinauswollte, ist der entscheidende Transfer in die Realität der Bordsoftware. In der Luft- und Raumfahrttechnik diskutieren wir nicht nur über die mathematische Ordnung eines Integrators, sondern immer über das Gesamtsystem:

• Die Fehler-Hierarchie: Wenn unsere Eingangssensoren (Gyroskope) ein gewisses Rauschen aufweisen, verschwindet der theoretische Präzisionsvorteil eines Hochleistungs-Integrators oft im Grundrauschen der Daten.
• Die Echtzeit-Bedingung: Ein Integrator, der die 50-fache Rechenzeit benötigt, zwingt uns dazu, die Abtastrate zu senken. In der Regelungstechnik ist eine hohe Frequenz (viele schnelle Korrekturen) jedoch oft wichtiger für die Stabilität als die hohe mathematische Ordnung eines einzelnen, langsamen Schrittes.
• Ressourcen-Management: Energieeffizienz und thermische Stabilität sind im Vakuum keine 'Nice-to-have'-Features, sondern harte Design-Kriterien. Rechenzeit ist dort gleichbedeutend mit Wärmeentwicklung, die man nicht einfach 'wegfächeln' kann.

Mein Benchmark sollte veranschaulichen, warum wir in der Praxis oft die hocheffiziente Normalisierung wählen: Sie ist robust, extrem schnell und hält das System sicher auf der Mannigfaltigkeit, ohne die Hardware unnötig zu belasten. Am Ende zählt, dass die Sonde ihr Ziel erreicht – mit der verfügbaren Energie und Rechenleistung.

 

[TomS]

Ich vermute, es wird schon Unterschiede zwischen RKMK und RK4 geben.

Ja, die gibt es, aber in meiner Rechnung bin ich noch nicht auf RKMK eingegangen. Ich benutze ausschließlich eine triviale Diskretisierung mit einer Zeitintervall dt und schreibe das wieder als Exponenten

RKMK käme ins Spiel, wenn man hier mehrere Zeitintervalle betrachtet, statt A dt mehr Terme a la RK4 dastehen hat, und sich dann überlegt, wie man diese in den Exponenten bringt.

Normieren muss man nur, wenn man

nicht in den Exponenten bringt, und zwar unabhängig von der genau betrachteten Anzahl der Zeitschritte.

Andererseits entfernt man sich bei RK4 auch gar nicht so schnell von der Mannigfaltigkeit, weil ja ihre Einbettung in einen höherdimensionalen Umgebungsraum mit benützt wird.

Na ja, für SU(2) ist der Fehler ohne RK* von der Ordnung

und für Quaternionen wird das ähnlich sein.

Die Einbettung in den Unterraum ist dabei eigtl. egal, die Norm des Vektors ändert sich.

Für RK* ist das natürlich komplizierter, da die A's für verschiedenen t's nicht mehr vertauschen.

 

[albertus]

Hallo TomS, vielen Dank für deine ergänzende mathematische Einordnung. Du triffst den Nagel auf den Kopf: Die Diskussion um RKMK versus RK4 ist im Kern eine Abwägung zwischen theoretischer Eleganz und systemischer Effizienz.

Deine Analyse zum Fehler dritter Ordnung

bei der SU(2) verdeutlicht sehr schön, warum der 'rechnerische Luxus' eines Lie-Integrators in der Realität oft keinen Mehrwert bietet. Wenn wir – wie du sagst – die Zeitintervalle durch einen effizienteren Algorithmus verkleinern können, gewinnen wir für die Stabilität des Gesamtsystems deutlich mehr als durch eine exakte Gruppenwahrung bei niedrigerer Abtastrate.

Es freut mich, dass wir hier die gleiche Sprache sprechen: Die Mathematik ist das Fundament, aber die Hardware-Ressourcen (Energie, Abwärme) diktieren am Ende das Design im Orbit.

 

[Jakito]

Ich benutze ausschließlich eine triviale Diskretisierung mit einer Zeitintervall dt und schreibe das wieder als Exponenten

RKMK käme ins Spiel, wenn man hier mehrere Zeitintervalle betrachtet, statt A dt mehr Terme a la RK4 dastehen hat, und sich dann überlegt, wie man diese in den Exponenten bringt.

Hallo TomS, vielen Dank für deine ergänzende mathematische Einordnung. Du triffst den Nagel auf den Kopf: Die Diskussion um RKMK versus RK4 ist im Kern eine Abwägung zwischen theoretischer Eleganz und systemischer Effizienz.

Ich befürchte, ihre missbraucht beide das Label RKMK für Eure eigenen Ideen. Das ist alles schön und gut, nur solltet ihr besser nicht aus Euren Experimenten schlussfolgern, dass ein sinnvoll eingesetzter "echter" RKMK wirklich 50 mal langsamer als ein RK4 ist.

 

[albertus]

Hallo Jakito, es geht hier nicht um ein ‚Label‘, sondern um Systemarchitektur. Selbst wenn ein optimierter RKMK nur Faktor 10 (statt 50) langsamer wäre als ein RK4 mit Normalisierung, bliebe er in der Raumfahrtpraxis oft zweite Wahl. Reale Missionen (siehe PD-Regler-Standards bei Kleinsatelliten) priorisieren Robustheit und eine hohe Abtastrate gegenüber mathematischer Gruppenreinheit. Ein Integrator ist nur so gut wie seine Fähigkeit, auf einer CPU zu laufen, die auch noch die Nutzlast und das Thermalkonzept versorgen muss.

Noch ein kurzer Nachtrag zur praktischen Relevanz:

Wenn wir über 'echtes' RKMK oder andere geometrische Integratoren sprechen, müssen wir die Hardwareumgebung berücksichtigen. Bei großen Missionen (man denke an Kommunikationssatelliten von Airbus oder Thales) sieht die Realität so aus:

1. Hardware-Limitierung: Wir arbeiten dort oft mit strahlungsgehärteten CPUs. Diese sind zwar extrem robust, aber um Lichtjahre langsamer als ein handelsüblicher PC. Ein Algorithmus muss deterministisch in der vorgegebenen Zeit fertig werden.
2. Industriestandard: Die von mir erwähnte Quaternionen-Normierung ist kein 'Missbrauch von Labeln', sondern der absolute Industriestandard. Sie ist mathematisch billig, physikalisch sicher und seit Jahrzehnten bewährt.
3. Das Power Budget: Ein Satellit hat ein striktes Energiebudget. Die CPU bekommt nur wenige Watt zugewiesen. Ein Missionsleiter würde niemals riskieren, ein wissenschaftliches Instrument oder einen Transponder abzuschalten, nur um die Rundungsfehler in der zehnten Nachkommastelle durch einen hochkomplexen Integrator zu eliminieren.

In der Raumfahrt ist ein Integrator ein Werkzeug, kein Selbstzweck. Er muss fliegen, nicht nur im Lehrbuch glänzen

 

[TomS]

Ich befürchte, ihre missbraucht beide das Label RKMK für Eure eigenen Ideen. Das ist alles schön und gut, nur solltet ihr besser nicht aus Euren Experimenten schlussfolgern, dass ein sinnvoll eingesetzter "echter" RKMK wirklich 50 mal langsamer als ein RK4 ist.

Habe ich doch gar nicht gemacht. Und auf Python würde ich da ohnehin nicht setzen – wobei ich ansonsten schon Fan bin

Sicher rechenintensiv ist die Matrixexponentialfunktion, dafür spart man sich die Normierung.

 

[Jakito]

Sicher rechenintensiv ist die Matrixexponentialfunktion, dafür spart man sich die Normierung.

Nur dass einen RKMK ja gar nicht zwingt, die Matrixexponentialfunktion zu benutzen, oder zu berechnen. Die Kommutatoren muss man hingegen schon ausrechnen, und die ändern sich auch, je nach dem, wie man die Mannigfaltigkeit/Gruppe parameterisiert hat.

Natürlich könnte ich auch versuchen nachzulesen, wie Autoren, die wirklich die Verwendung von RKMK für Quaterionen vorschlagen, die Sachen parameterisieren. Aber ich ich muss das gar nicht, bin eigentlich auch zu faul dafür, und ihr müsst es auch nicht:

Und es ist auch gar nicht wichtig, ob RKMK jetzt gut oder schlecht ist, oder ob Du RKMK richtig interpretiert hast, oder nicht. Du musst hier gar nicht beweisen, dass RKMK schlecht ist. Und Du musst auch gar nicht verstehen, wie RKMK genau gemeint ist.

 

[TomS]

Natürlich könnte ich auch versuchen nachzulesen, wie Autoren, die wirklich die Verwendung von RKMK für Quaterionen vorschlagen, die Sachen parameterisieren.

Danke für den Link, gründliche Arbeit.

@albertus & @Jakito –

noch eine Frage zur Praxis: was sind denn typische Abtastraten für omega, und über welchen Zeitraum muss die Berechnung stabil laufen?

 

[albertus]

Hallo TomS, zur Praxis: Die Abtastraten hängen stark von der Hardware ab. Bei Systemen mit hoher Dynamik (wie Drohnen) liegen wir oft bei 400 Hz bis 1 kHz, während in der Raumfahrt bei großen Trägheiten oft schon 10 Hz genügen. Wichtig ist die numerische Stabilität: Da wir integrieren, nutzen wir meist Renormierungszyklen in jedem Schritt, um die Einheitsform des Quaternions zu erhalten. Die Berechnung muss theoretisch unendlich stabil laufen, wird aber in der Praxis alle paar Sekunden mit Absolutdaten (z.B. Sternsensor oder IMU) abgeglichen, um den Drift der Gyros auszuregeln.

 

[TomS]

Hallo @albertus -

nach meinem Gefühl würde man bei 1 kHz mit einem Verfahren erster Ordnung auskommen, wenn ohnehin alle paar Sekunden neu abgeglichen wird; bei 10 Hz ist das wahrscheinlich aber ähnlich, wenn sich die Orientierungen nur sehr langsam ändern

ich baue gerade ein bisschen was in Python ...