He estado jugando con las leyes de orientación basadas en la tangente lineal (específicamente la antigua guía Atlas-Centaur Surveyor, Apollo IGM y el código PEG del transbordador espacial) y aunque PEG tiene una opción para una fase de costa antes de la quema final, no hay ningún modo donde el predictor-corrector optimizará esa costa. Parece ser un parámetro externo.
He encontrado documentos como, por ejemplo:
Ping Lu, Brian J. Griffin, Gregory A. Dukeman y Frank R. Chavez. "Orientación y planificación de ascenso rápido óptimo de múltiples quemaduras", Journal of Guidance, Control, and Dynamics, vol. 31, núm. 6 (2008), págs. 1656-1664.
Pero sacar las entrañas del algoritmo PEG y reemplazarlo con un enfoque como ese va a ser bastante agresivo (y no estoy seguro de que sea capaz de hacerlo ahora). Tampoco necesito necesariamente la optimización hasta el último dV de combustible, y la simplicidad y la convergencia serían más importantes para mí, por lo que los algoritmos que la NASA usa actualmente son probablemente más extensos de lo que estoy pidiendo.
Sospecho que hay algunos algoritmos simples de la era de finales de los 60 y principios de los 70 para producir respuestas al menos lo suficientemente buenas para:
Y esta es, en última instancia, una pregunta del Programa Espacial Kerbal. Y desafortunadamente mi último curso de cálculo de variaciones fue hace unos 20 años, así que estoy un poco oxidado en matemáticas.
Entiendo vagamente la teoría del vector primario, y ciertamente parece que la función de cambio bang-bang es lo que me gustaría llegar, pero no sé cómo sacarlo de PEG o cómo conectarlo a PEG. .
Algunas posibles aclaraciones: no creo que me preocupe la optimización de circuito cerrado. Sospecho que lo que quiero está más cerca del algoritmo OPGUID y el algoritmo SWITCH definido en:
Brown, KR, Harrold, EF y Johnson, GW 1969. Optimización rápida de vuelos de cohetes de combustión múltiple. Informe técnico NASA CR-1430, NASA, Marshall Space Flight Center.
Lo que no sé es si hay enfoques más simples que podría usar que podrían aprovechar los algoritmos estándar más recientes (más específicamente, ya tengo un enlace con http://www.alglib.net/optimization/ para Levenberg-Marquardt optimizador allí, y tiene muchos otros optimizadores que pueden hacer que resolver el problema de optimización de trayectoria sea mucho más simple, pero no tengo experiencia para saber qué podría ser útil).
Y creo que mi pregunta se reduce a si debo sumergirme en los algoritmos OPGUID y SWITCH, y en docenas de páginas de código Fortran que son más antiguas que yo, o si hay una forma más simple y moderna de hacer esto que yo estoy perdido? Sujeto a la restricción externa de que hasta ahora he tenido más éxito en la implementación de viejos TD de la NASA que en los algoritmos de la literatura.
Aquí hay diagramas de bloques disponibles para el código PEG-4 que se ocupan de las maniobras de onorbit y deorbit:
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19760024151.pdf
Es necesario en el código TURNR tener el límite máximo de phi a < 45 grados. Y también es necesario implementar la limitación de magnitud lambdaDot_xz a 0,35 de la frecuencia de Schuler en la quema. Hay más detalles en el artículo de 1979 sobre el algoritmo PEG:
https://ntrs.nasa.gov/search.jsp?R=19790048206
El código del transbordador usó algunas subrutinas llamadas LTVCON y TRANSTIME para manejar la orientación de la costa quemada para integrarse a través de la quemadura y la costa, incluidos los efectos J2 de la oblación de la Tierra, para alcanzar el objetivo ar, v.
Lo que encontré es que es suficiente (en KSP) para implementar en el corrector:
La mayor parte de la complejidad de LTVCON y TRANSTIME parece estar relacionada con el uso del predictor preciso en el código de transporte para tener en cuenta los efectos J2 durante la fase de costa (o la mayor parte de la fase de costa, ya que la posición de agotamiento cambia debido a PEG el tiempo de la costa varía según la costa delta y creo que se alimenta a través de una predicción precisa con J2 = 0, ¿probablemente por razones de eficiencia numérica o razones de estabilidad numérica?). También estoy algo desconcertado por las constantes C1 y C2 en la rutina LTVCON (particularmente para qué se usa C1).
Para el tiempo de espera, descubrí que simplemente liderar la quema por tgo/2 funciona bien, aunque podría no ser perfectamente óptimo. Sospecho que dejar que PEG se ejecute continuamente y luego ejecutar la quema en J/L antes de la quema podría ser un poco más preciso (en ausencia de un mejor planificador de trayectoria basado en el cálculo de variaciones).
ACTUALIZACIÓN: creo que entiendo un poco mejor ahora que las restricciones lambdaDot_xz en la rutina TURNR se usan para Abort Once Around y deorbit burns. Lo que terminé haciendo fue usar la rutina TURNR estándar que calcula rgo desdergo = rd - ( r + v * tgo + rgrav ) + rbias(que usa rd, que es donde creo que la restricción de posición retroalimenta la rutina) y luego calcula lambdaDot normalmente y usa las integrales de empuje rthrust y vthrust. Donde me encontré con la dificultad es que incluso 50-60 segundos después del final de la quema, el cálculo de lambdaDot se vuelve completamente inestable. Terminé sujetando lambdaDot a 0.35 * el valor de frecuencia de Schuler, por lo que la abrazadera se aplica a lambdaDot y se vuelve cero cuando tgo se vuelve cero. Forzar esa abrazadera a lo largo de todo el quemado (como lo hace la desorbitación o AOA) significaba que la ubicación del quemado tenía un gran valor de polarización, por lo que no era precisa.
UH oh
+1