Ich habe mit linearen Tangenten-basierten Führungsgesetzen herumgespielt (insbesondere die alte Atlas-Centaur Surveyor-Führung, Apollo IGM und Space Shuttle PEG-Code) und obwohl PEG eine Option für eine Küstenphase vor dem endgültigen Brennen hat, gibt es keine Modi wo der Prädiktor-Korrektor diese Küste optimieren wird. Es scheint ein externer Parameter zu sein.
Ich habe Papiere gefunden wie zB:
Ping Lu, Brian J. Griffin, Gregory A. Dukeman und Frank R. Chavez. "Rapid Optimal Multiburn Ascent Planning and Guidance", Journal of Guidance, Control, and Dynamics, Vol. 3, No. 31, Nr. 6 (2008), S. 1656-1664.
Aber die Eingeweide des PEG-Algorithmus herauszureißen und ihn durch einen solchen Ansatz zu ersetzen, wird ziemlich aggressiv sein (und ich bin mir nicht sicher, ob ich dazu im Moment in der Lage wäre). Ich benötige auch nicht unbedingt Optimalität bis zum letzten dV an Treibstoff, und Einfachheit und Konvergenz wären mir wichtiger - daher sind die Algorithmen, die die NASA derzeit verwendet, wahrscheinlich umfangreicher als das, was ich verlange.
Ich vermute, dass es einige einfache Algorithmen der späten 60er / frühen 70er Jahre gibt, um zumindest ausreichend gute Antworten zu erhalten:
Und das ist letztlich eine Frage des Kerbal Space Program. Und leider war mein letzter Variationsrechnungskurs ungefähr 20 Jahre her, daher bin ich in Mathe etwas eingerostet.
Ich verstehe die Primer-Vektor-Theorie vage, und es scheint, als wäre die Bang-Bang-Umschaltfunktion das, was ich gerne erreichen würde, aber ich weiß nicht, wie ich sie aus PEG herausbekomme oder wie ich sie auf PEG schrauben soll .
Einige mögliche Klarstellungen: Ich glaube nicht, dass ich mich mit Closed-Loop-Optimierung befasse. Ich vermute, was ich will, ist näher am OPGUID-Algorithmus und dem SWITCH-Algorithmus, der in definiert ist:
Brown, KR, Harrold, EF und Johnson, GW 1969. Schnelle Optimierung von Raketenflügen mit mehreren Verbrennungen. Technischer Bericht NASA CR-1430, NASA, Marshall Space Flight Center.
Was ich nicht weiß, ist, ob es einfachere Ansätze gibt, die ich verwenden könnte, um neuere Standardalgorithmen zu nutzen (genauer gesagt verlinke ich bereits auf http://www.alglib.net/optimization/ für die Levenberg-Marquardt Optimierer dort, und es hat viele andere Optimierer, die das Lösen des Trajektorienoptimierungsproblems viel einfacher machen könnten, aber ich habe nicht den Hintergrund, um zu wissen, was nützlich sein könnte).
Und ich denke, meine Frage läuft darauf hinaus, ob ich in die OPGUID- und SWITCH-Algorithmen eintauchen sollte - und in Dutzende von Seiten Fortran-Code, die älter sind als ich - oder ob es einen einfacheren, moderneren Weg gibt, dies zu tun, den ich vermisse ich? Vorbehaltlich des äußeren Zwanges, dass es mir bisher besser gelungen ist, alte NASA-TDs zu implementieren als Algorithmen in der Literatur.
Hier sind Blockdiagramme für PEG-4-Code verfügbar, die sich mit Onorbit- und Deorbit-Manövern befassen:
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19760024151.pdf
Im TURNR-Code ist eine Begrenzung des Phi max auf < 45 Grad erforderlich. Und es ist auch notwendig, die LambdaDot_xz-Größenbegrenzung auf 0,35 der Schuler-Frequenz bei der Verbrennung zu implementieren. Es gibt mehr Details in der Arbeit von 1979 über den PEG-Algorithmus:
https://ntrs.nasa.gov/search.jsp?R=19790048206
Der Shuttle-Code verwendete einige Subroutinen namens LTVCON und TRANSTIME, um das Burn-Coast-Targeting zu handhaben, um es durch das Burn und die Küste zu integrieren, einschließlich J2-Effekte der Erdabflachung, um ein ar, v-Ziel zu treffen.
Was ich gefunden habe, ist, dass es (in KSP) ausreicht, im Korrektor zu implementieren:
Der größte Teil der LTVCON- und TRANSTIME-Komplexität scheint darauf zurückzuführen zu sein, dass der genaue Prädiktor im Shuttle-Code verwendet wird, um J2-Effekte während der Coast-Phase (oder den größten Teil der Coast-Phase – da sich die Burnout-Position aufgrund von PEG zur Coast-Zeit ändert) zu berücksichtigen variiert je nach Delta-Küste und ich denke, das wird durch eine präzise Vorhersage mit J2 = 0 gespeist - wahrscheinlich entweder aus Gründen der numerischen Effizienz oder aus Gründen der numerischen Stabilität?). Ich bin auch immer noch etwas verblüfft über die C1- und C2-Konstanten in der LTVCON-Routine (insbesondere wofür C1 verwendet wird).
Für die Vorlaufzeit habe ich festgestellt, dass es gut funktioniert, den Brennvorgang einfach mit tgo/2 zu führen, obwohl es möglicherweise nicht perfekt optimal ist. Ich vermute, dass es etwas präziser sein könnte, PEG kontinuierlich laufen zu lassen und dann das Brennen bei J / L vor dem Brennen auszuführen (in Ermangelung eines besseren Trajektorienplaners, der auf Variationsrechnungen basiert).
UPDATE: Ich glaube, ich verstehe jetzt etwas besser, dass die LambdaDot_xz-Einschränkungen in der TURNR-Routine für Abort Once Around und Deorbit Burns verwendet werden. Am Ende habe ich die Standard-TURNR-Routine verwendet, aus der rgo berechnet wirdrgo = rd - ( r + v * tgo + rgrav ) + rbias(wobei rd verwendet wird, wo ich glaube, dass die Positionsbeschränkung in die Routine zurückfließt) und dann LambdaDot normal berechnet und die rthrust- und vthrust-Schubintegrale verwendet. Wo ich auf Schwierigkeiten gestoßen bin, ist, dass die LambdaDot-Berechnung sogar 50-60 Sekunden nach dem Ende des Brennens völlig instabil wird. Ich habe LambdaDot auf 0,35 * den Schuler-Frequenzwert geklemmt - also wird die Klemme auf LambdaDot angewendet und es geht auf Null, wenn tgo auf Null geht. Das Erzwingen dieser Klemme während der gesamten Verbrennung (wie dies bei Deorbit oder AOA der Fall ist) bedeutete, dass die Burnout-Position einen großen Vorspannungswert hatte, sodass sie nicht genau war.
äh
+1