Я играл с линейными законами наведения на основе касательной (в частности, со старым руководством Atlas-Centaur Surveyor, кодом Apollo IGM и Space Shuttle PEG), и хотя у PEG есть опция для фазы движения перед окончательным прожигом, я не знаю никаких режимов. где предиктор-корректор будет оптимизировать этот берег. Похоже, это внешний параметр.
Я нашел такие документы, как, например:
Пинг Лу, Брайан Дж. Гриффин, Грегори А. Дьюкман и Фрэнк Р. Чавес. «Планирование и руководство быстрым оптимальным многократным восхождением», Journal of Guidance, Control and Dynamics, Vol. 31, № 6 (2008), стр. 1656-1664.
Но вырвать внутренности алгоритма PEG и заменить его подобным подходом будет довольно агрессивно (и я не уверен, что сейчас на это способен). Я также не обязательно требую оптимальности вплоть до последнего dV топлива, а простота и конвергенция были бы для меня более важными — поэтому алгоритмы, которые в настоящее время использует НАСА, вероятно, более обширны, чем то, о чем я прошу.
Я подозреваю, что есть несколько простых алгоритмов эпохи конца 60-х / начала 70-х годов для получения по крайней мере достаточно хороших ответов на:
И это, в конечном счете, вопрос космической программы Кербала. И, к сожалению, мой последний курс вариационного исчисления был около 20 лет назад, так что я немного заржавел в математике.
Я смутно понимаю теорию праймер-векторов, и, безусловно, мне кажется, что функция переключения типа «бах-бах» — это то, к чему я хотел бы добраться, но я не знаю, как вытащить ее из ПЭГ или как прикрутить ее к ПЭГ. .
Некоторое возможное уточнение: я не думаю, что меня интересует оптимизация с обратной связью. Я подозреваю, что то, что я хочу, ближе к алгоритму OPGUID и алгоритму SWITCH, определенному в:
Браун, К.Р., Харрольд, Э.Ф. и Джонсон, Г.В. 1969. Быстрая оптимизация полетов ракет с многократным сжиганием. Технический отчет NASA CR-1430, НАСА, Центр космических полетов им. Маршалла.
Чего я не знаю, так это того, есть ли более простые подходы, которые я мог бы использовать, которые могли бы использовать более современные готовые алгоритмы (точнее, я уже ссылаюсь на http://www.alglib.net/optimization/ для Levenberg-Marquardt). оптимизатор, и у него есть много других оптимизаторов, которые могут сделать решение проблемы оптимизации траектории намного проще, но у меня нет опыта, чтобы знать, что может быть полезно).
И я думаю, что мой вопрос сводится к тому, должен ли я погрузиться в алгоритмы OPGUID и SWITCH — и в десятки страниц кода на Фортране, который старше меня — или есть более простой и современный способ сделать это, который я пропал? С учетом внешнего ограничения, что до сих пор мне удавалось более успешно реализовывать старые ТД НАСА, чем алгоритмы, описанные в литературе.
Здесь доступны блок-схемы для кода PEG-4, которые относятся к маневрам на орбите и сходу с орбиты:
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19760024151.pdf
В коде TURNR необходимо, чтобы максимальное значение phi ограничивалось < 45 градусами. А также необходимо реализовать ограничение величины lambdaDot_xz до 0,35 частоты Шулера при записи. Более подробная информация содержится в статье 1979 года об алгоритме PEG:
https://ntrs.nasa.gov/search.jsp?R=19790048206
Код шаттла использовал некоторые подпрограммы, называемые LTVCON и TRANSTIME, для управления нацеливанием на выгорание-побережье для интеграции через выгорание и побережье, включая эффекты J2 сжатия Земли, чтобы поразить цель ar, v.
Я обнаружил, что достаточно (в KSP) реализовать в корректоре:
Большая часть сложности LTVCON и TRANSTIME, по-видимому, связана с использованием точного предиктора в коде челнока для учета эффектов J2 во время фазы выбега (или большей части фазы выбега — поскольку положение выгорания изменяется из-за PEG времени выбега). варьируется в зависимости от побережья дельты, и я думаю, что это происходит через точное предсказание с J2 = 0 - вероятно, либо по причинам численной эффективности, либо по причинам численной стабильности?). Я также все еще несколько озадачен константами C1 и C2 в подпрограмме LTVCON (особенно тем, для чего используется C1).
Что касается времени выполнения, то я обнаружил, что просто опережать процесс записи с помощью tgo/2 работает нормально, хотя это может быть и не совсем оптимально. Я подозреваю, что позволить PEG работать непрерывно, а затем выполнить прожиг на J/L перед прожигом, может быть немного более точным (в отсутствие лучшего планировщика траектории на основе исчисления вариаций).
ОБНОВЛЕНИЕ: я думаю, что теперь я немного лучше понимаю, что ограничения lambdaDot_xz в подпрограмме TURNR используются для аварийного прекращения и спуска с орбиты. В итоге я использовал стандартную процедуру TURNR, которая вычисляет rgo изrgo = rd - ( r + v * tgo + rgrav ) + rbias(который использует rd, где, как я полагаю, ограничение положения возвращается в процедуру), а затем вычисляет lambdaDot в обычном режиме и использует интегралы тяги rthrust и vthrust. Я столкнулся с трудностью в том, что даже через 50-60 секунд после окончания записи вычисление lambdaDot становится совершенно нестабильным. Я зафиксировал lambdaDot до 0,35 * значение частоты Шулера, поэтому ограничение применяется к lambdaDot, и оно становится равным нулю, когда tgo стремится к нулю. Принудительное использование этого зажима на протяжении всего горения (как это происходит при сходе с орбиты или AOA) означало, что место выгорания имело большое значение смещения, поэтому оно было неточным.
ооо
+1