Вход для пользователей

You are here

"Аполлон" на HP-42s

Итак, освежив в памяти математические формулы для численного моделирования космических полётов, я отыскал в ТМ блок-схему алгоритма
Блок-Схема "Лунолёт-3"
и принялся за реализацию программы на языке КПК НР-42S.

Дело продвигалось быстро, за пару вечеров я написал весь код, причём, за счёт более богатого функционала операторов обращения с регистрами, он получился даже короче «классических» для программ КЭИ 98 шагов. Потом отладил программу. Как обычно, поначалу вылезло пару-тройку багов (по разному работали команды переходов по условию и ещё несколько мелочей), но довольно быстро всё заработало, как надо. Скорость расчётов была настолько высока, что после нескольких прогонов появилась идея повысить точность расчётов. В результате, вместо приближённых формул, которые использовались в программах для старых советских ПМК, интегрирование траектории теперь выполнялось с постоянным шагом в 1 секунду.

Потом, вспомнив эталонный во всех отношениях «Орбитер», принялся щедро оснащать программу отдельными процедурами, которые считали и выводили на индикатор разную полезную информацию типа (высоты апо- и пери-центра, период орбиты, время до цели и т.п). Лёгкость, с которой всё это реализовывалось, не могла не радовать.

Воплощая мои хотелки, программа обрастала дополнительными переменными и, быстро перевалив за 200 строк, продолжала жадно расти в объёме.

Поначалу всё было здорово, но постепенно что-то определённо становилось “не так”.

Все переменные уже не помещались в одну строку, интерфейс программы начал терять в наглядности. То же было и с дополнительными процедурами - для их вызова приходилось всё дальше углубляться в меню. И в какой-то момент, вместо восторгов я стал ощущать явную неудовлетворённость.

Становилось ясно, что для точных расчётов в нынешние времена гораздо удобнее использовать полноценный компьютер, с клавиатурой и дисплеем. БОльшая точность требует более объемного кода, а даже банальный ввод программы в память с клавиатуры ПМК, когда эта программа превышает сотню шагов, превращается в утомительное занятие. Кроме того, одно дело разобрать математику расчётов, реализованную в виде ОПН, в 15-20 шагов, когда вся программа умещается перед глазами, другое дело, когда это цепочки уже за сотню операций. В 80е - 90е, использовать обратную нотацию имело смысл - это повышало быстродействие тогдашних медленных процессоров. Но сейчас для программ такого объёма гораздо удобнее и нагляднее стандартный математический вид.

Да и вообще, дальнейшая логика модификации программы и повышение точности расчётов естественно приводила к режиму «полёта в реальном времени» - а это на калькуляторе с экраном в две строки делать не сильно интересно получается… Дело в том, что при полёте на современных симуляторах ты, как правило, ничего не считаешь. За тебя всё делают разнообразные MFD (Многофункциональные дисплеи). Тебе заранее подсказывают, сколько осталось до апо- или пери-центра, куда развернуться, как долго включать двигатель, как меняется высота орбиты, где будет находится цель и т.д и т.п. Конечно, когда ты летишь, тебе не до расчётов - нужно успеть вовремя сделать то, что нужно…

И вдруг я понял, что главная «фишка» тех старых «космических» программ для ПМК заключалась именно в том, что они, как сейчас принято говорить, были «пошаговые»! После каждого манёвра время «останавливалось», и ты имел возможность спокойно подумать, что делать дальше, «в следующее мгновение». И тут важно было именно понимание физики процессов. У тебя не было MFD, перед глазами всегда был только один единственный индикатор, но вся необходимая информация сидела в регистрах, и ты мог (и должен был!) сам разделить, к примеру, расстояние на скорость, чтобы оценить время, или подобрать расход топлива, или величину тормозного импульса и т.д.

А повышая точность симуляции, неизбежно следовало поставить вопрос о том, какая степень точности необходима и достаточна? Я ведь не собирался запускать в космос реальную ракету. Мне не нужны были точные расчёты, мне вполне достаточна была упрощённая математическая модель. Модель, реалистичная на качественном уровне, «в обвязке» игровой программы, позволявшая пролететь путь Аполлона с орбиты на поверхность Луны и обратно с поверхности, до стыковки с командным модулем на орбите.

И тут до меня дошло, что вся эта мощность продвинутого американца была явно избыточна для моих целей. Ведь с упрощённой моделью расчётов в «пошаговом» режиме, прекрасно справлялись и старые советские ПМК, обходясь программами в 98 шагов и 14 регистрами с данными!

Восторг и восхищение возможностями НР-42 никуда не делись, машинка классная, а для тех лет - просто фантастическая по возможностям, но… После того, как программа для моделирования орбитальных полётов на мощном американском ПМК была написана и протестирована, я пришёл к выводу, который оказался удивительным для меня самого. На самом деле, для моих задач скромный советский МК-61 оказывается вполне (а может, даже и более чем) подходящим.

В итоге, к концу недели я откладываю в сторону “американца” и пересаживаюсь на борт старого знакомого - аскетичного ПМК Электроника МК-61…

Метки публикаций: 

Комментарии

Изображение пользователя Vitasam.

Жалко, что HP42s был отложен в сторону, у меня была надежда попробовать полет на DM42 :)

Я впечатлён возможностями DM42, в школе бы душу за него отдал))
Пока делал аналог "Лунолёта", увидел, что на нём можно попробовать соорудить пошаговый аналог Орбитера - с возможностью полётов по всей системе. Во всяком случае, объединить весь путь "Луна - Земля" в единый комплекс - вообще не проблема.
А использовать его для моделирования посадки на Луну - как-то ... неспортивно, что ли)
Так что пересел пока на МК-61, но "наш бронепоезд стоит на запасном пути"

Изображение пользователя Vitasam.

Это хороший путь.

Ну, тогда пока я надеюсь повторить полет Апполонов на другом "корабле".

Изображение пользователя st.

У нас есть "Лунолет-3" в графике: Прогулка по лунолётам. 4 - Вблизи и на орбите. На МК-61, к сожалению, это не "натянуть".

Изображение пользователя Vitasam.

под прекрасные графические возможности DM42? :)

Посмотрел статью - отличная работа!
Но для моего имхо, особая фишка ПМКшных космических программ - именно в отсутствии графики, как бы спорно это не звучало.
Одно суровое численное моделирование! :)
А поработав над программой для DM42, вижу, что и "пошаговый режим" имеет безусловные достоинства перед симуляцией реального времени.

Orbiter, кстати, не так давно стал open source, если кто пропустил. :)
https://github.com/orbitersim/orbiter

Что касается навигации в окресностях Луны, то на самом деле простыми моделями для ПМК ее можно моделировать только очень и очень ограниченно. В реальности там и масконы, и немного смещенный центр притяжения, и влияние Земли и Солнцы.
Очень интересная система эта Земля-Луна, кстати. Одни только Halo-орбиты чего стоят. Одну из которых, например, планируется использовать для будущей миссии "Артемида".
Так же, самые экономные траектории Луна-Земля и обратно, например, подразумевают выход в область точки Лагранжа L1 Земля-Солнце, где уже притяжение Солнца играет свою роль и плавно направляет корабль к цели, экономя кучу топлива.
Даже в Орбитере нет инструментов, чтоб все это расчитывать. Но моделировать можно,если предварительно расчитать в том же GMAT, например, а потом уже пытаться реализовать это в Орбитере.
На ПМК же смоделировать полет с поверхности Луны к станции, находящейся на NRHO, например, вряд ли вообще реально. Разве что на чем-то вроде HP-42S, тут без перехда в 3D не обойтись, и 105 шагов явно не хватит.
NRHO - это вытянутая орбита плоскость которой всегда почти перпендикулярна линии Луна-Земля, несмотря на движение Луны вокруг Земли, она как-бы поворачивается вместе с Луной и поэтому Луна никогда не закрывает станцию от Земли. Выглядит примерно так: https://www.orbiter-forum.com/attachments/t-png.12352/

Изображение пользователя Vitasam.

На ПМК же смоделировать полет с поверхности Луны к станции, находящейся на NRHO, например, вряд ли вообще реально. Разве что на чем-то вроде HP-42S, тут без перехда в 3D не обойтись, и 105 шагов явно не хватит.

Я тоже голосую за HP42s в этом эксперименте

Благодаря возможности работы с матрицами (их умножение/сложение и пр.) в HP-42s сильно упрощается создание программ где нужно численно интегрировать по нескольким параметрам.
Ради интереса, переписал Лунолет-1 на расчет с применением стандартного Рунге-Кутты 4, где интегрируется по скорости, ускорению, массе, ну еще и добавил по времени (с производной 1), чтоб проще было следить за временем. Один шаг такого интегрирования считает 8-9 секунд в Emu42 на аутентичной скорости, что многовато. Честно говоря, думал HP-42s все-таки по-шустрей был.
Программа получилась такая:

00 { 686-Byte Prgm }
01 LBL "LUN1RK"
02 CLST
03 RCL "T"
04 RCL "M"
05 RCL "V"
06 RCL "H"
07 LBL 00
08 CLMENU
09 "H"
10 KEY 1 XEQ 01
11 "V"
12 KEY 2 XEQ 02
13 "F"
14 KEY 3 XEQ 03
15 "[dM]"
16 KEY 4 XEQ 04
17 "[dT]"
18 KEY 5 XEQ 05
19 "EXEC"
20 KEY 6 XEQ 06
21 MENU
22 STOP
23 GTO 00
24 LBL 01
25 "ALTITUDE="
26 RCL "H"
27 GTO 07
28 LBL 02
29 "SPEED="
30 RCL "V"
31 GTO 07
32 LBL 03
33 RCL "M"
34 RCL- "M0"
35 "FUEL="
36 LBL 07
37 ARCL ST X
38 AVIEW
39 RTN
40 LBL 04
41 FC?C 22
42 RCL "dM"
43 STO "dM"
44 VIEW "dM"
45 RTN
46 LBL 05
47 FC?C 22
48 RCL "dT"
49 STO "dT"
50 VIEW "dT"
51 RTN
52 LBL 06
53 CLRG
54 RCL "dM"
55 RCL "dT"
56 X=0?
57 RTN
58 ABS
59 ÷
60 STO 02 // DM
61 RCL× "U"
62 RCL÷ "M"
63 RCL- "MAXG"
64 X≥0?
65 STO 03
66 RCL "M"
67 RCL "dM"
68 ABS
69 -
70 RCL- "M0"
71 X≥0?
72 GTO 17
73 "NOT ENOUGH FUEL"
74 AVIEW
75 RCL "dM"
76 ABS
77 +
78 RCL÷ 02
79 ABS
80 STO "dT"
81 CLX
82 STO "dM"
83 LBL 17
84 1
85 4
86 NEWMAT
87 STO "Y"
88 INDEX "Y"
89 RCL "H"
90 STOEL
91 J+
92 RCL "V"
93 STOEL
94 J+
95 RCL "M"
96 STOEL
97 J+
98 RCL "T"
99 STOEL
100 RCL "Y"
101 RCL "dT"
102 XEQ 12
103 STO "Y"
104 INDEX "Y"
105 J-
106 RCLEL
107 STO "T"
108 J-
109 RCLEL
110 STO "M"
111 J-
112 RCLEL
113 STO "V"
114 J-
115 RCLEL
116 STO "H"
117 CLV "Y"
118 RCL 03
119 X>0?
120 GTO 16
121 R↓
122 RTN
123 LBL 16
124 STO "dT"
125 0
126 STO 02
127 STO 03
128 "MAXG OVERLOAD"
129 AVIEW
130 GTO 17
131 LBL 10
//def derivatives(z):
// y = z[0]
// v = z[1]
// m = z[2]
// return array([v, u*dm/m-G/(R+y)**2, -abs(dm), 1])
132 STO "Z"
133 INDEX "Z"
134 RCLEL
135 J+
136 RCLEL
137 J-
138 STOEL
139 R↓
140 J+
141 J+
142 RCL "U"
143 RCLEL
144 ÷
145 RCL× 02
146 X<>Y
147 RCL+ "R"
148 X↑2
149 1/X
150 RCL× "G"
151 -
152 J-
153 STOEL
154 J+
155 RCL 02
156 ABS
157 +/-
158 STOEL
159 1
160 J+
161 STOEL
162 RCL "Z"
163 CLV "Z"
164 RTN
165 LBL 11
//def rk4(dt, y, h=0.01):
// t = 0
// y = double(array(y))
// if sign(dt) != sign(h):
// h = -h
// while abs(t) < abs(dt):
// if abs(t+h) > abs(dt):
// h = dt-t
// k1 = derivatives(y)
// k2 = derivatives(y+h*k1/2)
// k3 = derivatives(y+h*k2/2)
// k4 = derivatives(y+h*k3)
// y += (k1+2*k2+2*k3+k4)*h/6
// t += h
// return y
166 STO 01 // h
167 R↓
168 STO "Y"
169 INDEX "Y"   // Altitude < 0 - stop the integration
170 RCLEL
171 X≥0?
172 GTO 18
173 CLX
174 STO 00
175 R↓
176 "LANDED"
177 AVIEW
178 RTN
179 LBL 18
180 R↓
181 XEQ 10
182 STO "K1"
183 2
184 ÷
185 RCL× 01
186 RCL+ "Y"
187 XEQ 10
188 STO "K2"
189 2
190 ÷
191 RCL× 01
192 RCL+ "Y"
193 XEQ 10
194 STO "K3"
195 RCL× 01
196 RCL+ "Y"
197 XEQ 10
198 RCL+ "K1"
199 RCL "K2"
200 RCL+ "K3"
201 2
202 ×
203 +
204 RCL× 01
205 6
206 ÷
207 RCL+ "Y"
208 CLV "Y"
209 CLV "K1"
210 CLV "K2"
211 CLV "K3"
212 RTN
213 LBL 12
// while abs(t) < abs(dt):
// if abs(t+h) > abs(dt):
// h = dt-t
214 STO 00 // dt
215 ABS
216 LBL 14
217 RCL "MAXH"
218 X>Y?
219 X<>Y
220 RCL 00
221 SIGN
222 ×
223 STO- 00
224 RCL ST Z
225 X<>Y
226 XEQ 11
227 RCL 00
228 ABS
229 X≠0?
230 GTO 14
231 X<>Y
232 RTN
233 END
234 LBL "L1INIT"
//m0 = 2250+400
//u = 3660
//R = 1738000
//G = 1.62*R*R
//g_max = 9.81*3
//dm = 0
235 0
236 STO "V"
237 STO "H"
238 STO "T"
239 STO "dT"
240 STO "dM"
241 3660
242 STO "U"
243 1738ᴇ3
244 STO "R"
245 X↑2
246 1.62
247 ×
248 STO "G"
249 2250
250 STO "M0"
251 400
252 +
253 STO "M"
254 0.1
255 STO "MAXH"
256 9.81
257 3
258 ×
259 STO "MAXG"
260 GTO "LUN1RK"
261 END

RAW-файл тут: https://0x0.st/oS5l.raw

Все интегрирование укладывается в определение функции для получения значений производных по каждому интегрируемому параметру - шаги 132 - 164. Потом сам метод RK4 - шаги 165-212. До 131 шага - интерфейсная часть, 213-233 это просто цикл с заданным шагом интегрирования, ну и с 234 в конце - это програмка L1INIT для инициализации данных.
В комментариях дополнительно код на Python, который, собственно, и реализовывался.

Такой подход можно легко масштабировать просто определяя новые переменные по которым нужно интегрировать. Например, добавив к высоте еще и вторую координату (картезианскую или в полярной СК) и дописав соответствующие производные можно легко получить Лунолет-2 или Лунолет-3.

Изображение пользователя Vitasam.

А у Вас нет космически-орбитальных наработок для Ti-nspire CX? Просто у меня на столе под рукой (сын пользуется PC версией на лаптопе).