Время на прочтение
5 мин
Количество просмотров 35K
На днях в обычном офисном разговоре я сказал: «То, что у нас тут склад костылей — это нормально, во всех ИТ-проектах так. Наверное, из всего софта, который сделало человечество, только в программах посадки на Луну было все красиво». Сказав это, я полез в интернет, найти дополнительные факты к краткому научно-популярному рассказу для коллег о компьютерах и программах лунного модуля. Но одной из первых попалась ссылка, из которой выяснилось, что костыли, и, страшно сказать, баги были и в отшлифованном программном обеспечении, которое позволило человеку высадиться на Луну. А «Аполлоны» -11 и -12 смогли сесть, оказывается, только по счастливой случайности.
Софт и железо
Слева — компьютер, справа — дисплей и клавиатура
На командном и лунном модулях «Аполлонов» стояли идентичные компьютеры, но с разным набором программ. По тем временам это был фантастический хайтек, использовавший интегральные схемы, а не отдельные диоды и транзисторы. «Цикл памяти», примерно соответствующий тактовой частоте современных процессоров, занимал 11,7 микросекунд. Но практически все операции требовали два цикла, поэтому эффективная тактовая частота получалась равной 23,4 микросекундам, или 43 килогерцам, в 100 000 раз медленнее современных процессоров. Память компьютера составляла 36 тысяч 14-битных слов, что примерно соответствовало 64 килобайтам.
Постоянная память на проволоке и ферритовых сердечниках
Софт для лунного модуля разрабатывали примерно 300 человек в течение семи лет. Программа посадки на Луну имела название LUMINARY и хранилась в постоянной памяти на ферритовых сердечниках, провода сквозь которые продевались вручную. Создание такого блока памяти занимало несколько месяцев, поэтому софт должен был быть готов заранее. За годы «Аполлонов» программы модифицировались. На «Аполлоне-11» стоял блок с программой версии 99, а финальная версия (очевидно, посадившая Аполлон-17) имела номер 209. Главным дизайнером программы посадки был Алан Кламп (Allan Klumpp), недавний выпускник Массачусетского технологического института.
Процедура посадки
Посадка на Луну с точки зрения компьютера проходила в три этапа:
Программа P63 отвечала за торможение с орбитальной скорости.
P64 занималась выводом лунного модуля в район посадки.
P65 отвечала за финальный этап посадки.
На участке работы программы P64 пилот лунного модуля называл число, которое показывал на дисплее компьютер. Командир мысленно отмечал это число на шкале, которая была нарисована на иллюминаторе, и получал расчетную точку посадки.
Байка первая: ошибки 1201 и 1202
Довольно известен тот факт, что, когда Армстронг и Олдрин начали торможение с лунной орбиты, их компьютер выдал ошибку 1202. Это был очень нервный момент, потому что сами астронавты не знали значения этого кода. К счастью, специалист ЦУПа Стив Бейлс (Steve Bales) заранее написал список всех ошибок и быстро нашел расшифровку — компьютер не успевал справляться со всей работой. Компьютер «Аполлона» был системой реального времени, и он начал игнорировать некоторые низкоприоритетные задачи, выдавая сообщение об ошибке. Спустя еще минуту появилась новая ошибка — 1201. Но она относилась к этому же типу и не срывала посадку.
Уже после посадки была найдена причина. Как это часто бывает в сложных технических системах, причиной оказалась целая цепочка событий. Во-первых, после начала торможения инструкция требовала включить стыковочный радар на случай аварийного прерывания посадки. Стыковочный радар работал от другого источника питания, нежели компьютер. Этот источник питания имел ту же частоту, но не был синхронизирован по фазе с источником питания компьютера. Небольшие смещения фазы на радаре выглядели для компьютера как дрожания неподвижной в реальности антенны. В норме при посадке процессор компьютера был загружен на ~85%. «Дрожащая антенна» добавила еще 13%. А когда Олдрин дал команду компьютеру посчитать разницу между реальной и рассчитанной высотой по посадочному радару, компьютер оказался в условиях перегрузки. Уже потом посчитали, что это событие «украло» примерно минуту процессорного времени, а из 10 раз в секунду компьютер управлял стабильностью лунного модуля 9 раз. Кстати, баг с дрожащей антенной был замечен на тестировании, но его оставили, потому что он проявился всего один раз, а замена оборудование на новое могла создать более опасные баги.
Та самая посадка, видео повернуто для удобства восприятия, и добавлено много полезной информации. В видео упоминается программа P66, это альтернативный вариант одной из программ
А здесь можно посмотреть на посадку виртуально, с разных сторон.
Байка вторая, счастливая ошибочная оптимизация
Как известно, «Аполлоны» -11 и -12 сели успешно. Однако впоследствии, уже после возвращения астронавтов, по телеметрии в двигателях посадочной ступени обнаружились опасные колебания — тяга то поднималась вверх, то падала вниз. К счастью, колебания не стали слишком сильными и не вызвали проблем с управлением или двигателем. Расследование показало, что причиной колебаний являлось программное обеспечение. Программистам был доступен специальный документ, в котором описывались параметры и свойства лунного модуля. В разделе о двигателе было указано, что он имеет инерционность 0,3 секунды. То есть через 0,3 секунды после команды на изменение тяги он должен был выйти на новый уровень. Это надо было отразить в программе, поэтому была написана специальная подпрограмма, которая измеряла тягу двигателя по данным акселерометра и выполнялась за 0,3 секунды. Но финальная версия этой подпрограммы писалась другим программистом, который решил ее улучшить и сделать быстрее. Новая версия успевала выполниться за 0,2 секунды. Ее протестировали на симуляторе, и она показала себя там отлично. Однако разработчики двигателя улучшили его, и время задержки упало до 0,075 секунды. А внести это изменение в документ для программистов просто забыли. Последующие тесты показали, что, если бы подпрограмма определения тяги работала изначальные 0,3 секунды, то система бы оказалась нестабильной, и колебания становились бы все больше и больше, что привело бы к прыжкам тяги двигателя от минимальной до максимальной и обратно, а это бы, наверняка, сорвало высадку.
Байка третья, о проблемах интерполяции
Напоминаю, что программа P64 нацеливала лунный модуль в точку над местом посадки. Однако, поскольку для расчета траектории использовались полиномы высоких степеней, траектория, выходя в точку прицеливания, могла оказаться под поверхностью Луны. Потому что полином высокой степени мог «прыгнуть» в сторону (это знают математики и инженеры):
Чем выше степень, тем больше может быть этот «прыжок», несмотря на то, что график проходит через все желтые точки
Ирония с этим багом состоит в том, что его никак не исправили. Программа не отслеживала потенциально опасные кривые. Баг не проявился в реальных посадках, но его мог вызвать не такой уж невозможный случай. Если бы лунный модуль немного сбился с курса и оказался над неучтенным достаточно глубоким кратером, компьютер, получая данные от посадочного радара, мог бы подумать, что оказался выше траектории, пересчитать кривую на более крутую и направить лунный модуль к прицельной точке, нырнув сначала в Луну. Отдельно доставляет рецепт борьбы с багом, если бы он проявился — астронавтам надо было бы переместить точку прицеливания за предел досягаемости по запасам топлива и подержать ее там некоторое время. Вы когда-нибудь совершали странные действия, чтобы переупрямить глючную программу? Можете себя поздравить, астронавтам возможно пришлось бы делать то же самое…
16 июля 1969 года «Аполлон-11» стартовал с мыса Канаверал. На борту космического корабля находились 3 астронавта: Нил Армстронг, Майкл Коллинз и Базз Олдрин. И уже 20 июля 650 миллионов человек во всем мире увидели на своих экранах в прямом эфире первые шаги человека по поверхности спутника нашей планеты. Высадка на Луну стала одним из самых замечательных достижений нашей цивилизации. Многим показалось, что это был очень успешный полёт. Однако всем к нему причастным пришлось пережить множество тревожных минут. Разные проблемы и опасности преследовали их в течение всей этой исторической миссии. Сегодня мы расскажем о шести из них.
Аполлон-11
-
1202
Представьте, что вы находитесь в крошечном посадочном модуле («Орёл»), до прилунения остаётся семь с половиной минут, и в это самое время компьютер сигнализирует об ошибке, код которой вам неизвестен. Неприятно, не правда ли? Армстронг уже готовился опуститься на Луну, когда компьютер, называвшийся AGC, выдал код ошибки «1202». Надо сказать, что этот агрегат для своего времени был настоящим технологическим чудом. Он был компактным, весил всего около 32 килограмм и потреблял 70 Ватт при 28 вольтах постоянного тока. От него зависело очень многое, особенно во время прилунения. Он осуществлял навигацию, отвечал за скорость и высоту посадочного модуля, сообщал о производительности двигателя. Также он должен был вернуть экипаж на орбиту, если во время спуска что-то пойдёт не так. Находившиеся внутри «Орла» Армстронг и Олдрин понятия не имели, что значит это «1202». Код ни разу не встречался им во время многочисленных тренировочных упражнений, имитировавших высадку. Командир сообщил о проблеме в Центр управления полётами, откуда ему посоветовали игнорировать ошибку и продолжать выполнять задание. AGC показал код «1202» ещё четыре раза, затем один раз «1201», и прекратил играть на нервах. Впоследствии выяснилось, что компьютер был перегружен большим количеством данных, поступающих от радаров, и ему не хватало памяти.
Состав экипажа Аполлон-11 — слева направо: Нил Армстронг, Майкл Коллинз, Эдвин Олдрин
-
Перелёт
Где-то за 9 минут до прилунения «Аполлон-11» Армстронг осознал, что «Орёл» перемахнёт через тщательно выбиравшуюся для этой цели площадку. По его оценкам, «перелёт» должен был составить около 5 километров, но на самом деле посадочный модуль улетел ещё дальше — на шесть с половиной. Причиной проблемы было то, что во время отстыковки остаточное давление внутри туннеля, соединявшего два модуля «Аполлона», придало «Орлу» дополнительный импульс. Это был относительно слабый толчок, но в условиях невесомости его хватило, чтобы спровоцировать очень серьёзные проблемы. Поверхность Луны покрыта кратерами и скальными обнажениями. Ещё хуже было то, что посадочный модуль сжигал топливо быстрее ожидаемого. Вскоре Хьюстон предупредил Армстронга, что у него осталось горючего всего на 60 секунд. Если бы за это время командир не посадил модуль, то прилунение пришлось бы прервать. В этот момент «Орёл», накренившись, летел над поверхностью на скорости 55 километров в час. Он поднимал пыль и разглядеть, что творится внизу, было очень трудно. Первая в истории пилотируемая посадка на Луну произошла на ровной местности, когда у модуля оставался запас топлива всего на полминуты. На пульте загорелась синяя лампочка, и командир произнёс фразу, которая вошла в историю: «Хьюстон, База Спокойствия на связи. «Орёл» сел».
-
Ледяная пробка
Вскоре после прилунения у посадочного модуля возникла ещё одна проблема. Датчики зафиксировали повышение давления в топливопроводе двигателя «Аполлон-11». Это означало, что пар, образовавшийся между теплообменником и клапанами, замёрз, закупорив систему. Не остывший ещё двигатель «Орла» продолжал генерировать пар, из-за чего его могло разорвать. Специалисты НАСА заметили проблему и разработали план вентиляции. Однако прежде чем они успели передать инструкции Армстронгу и Олдрину, ледяная пробка растаяла сама по себе, выпустив скопившиеся газы.
-
Лунный грунт
До полёта «Аполлона-11» специалисты НАСА не очень хорошо себе представляли, насколько стабилен лунный грунт. Тот факт, что «Орел» прочно стал на свои опоры, не мог не радовать, но вокруг было много пыли, которая могла доставить весьма серьёзные неприятности как посадочному модулю, так и астронавтам. Несмотря на то, что на Луну заранее были посланы разведывательные аппараты «Сервейер», изучившие поверхность, лишь после исторических шагов Армстронга стало окончательно понятно, что здесь возможна запланированная «внекорабельная деятельность». Но местная пыль оказалась довольно опасна. Главным образом, из-за своей абразивности. Она накапливалась в течение миллиардов лет, по всей видимости, образуясь в результате попаданий метеоритов, но на Луне нет природных процессов, которые могли бы придать этим крошечным частичкам более гладкую форму. Все астронавты, работавшие на поверхности нашего спутника, жаловались впоследствии, что пыль проникала в посадочный модуль, заклинивала застёжки-молнии и даже просачивалась сквозь слои защитного материала скафандра.
-
Переключатель
После прилунения «Аполлон-11» внутри посадочного модуля сломался переключатель. Базз Олдрин был уверен, что это произошло вслед за тем, когда он и Армстронг вошли внутрь после пребывания на Луне. Астронавты должны были задраить люк, восстановить давление, снять ранцы и подключить шланги скафандров к системам жизнеобеспечения. Затем им следовало вновь открыть люк и выбросить в него ранцы и всё другое ненужное оборудование, тем самым уменьшая взлётную массу «Орла». Все эти действия были отработаны во время подготовки к полёту, но кто-то из двоих то ли споткнулся, то ли неловко задел приборную панель. Избавившись от балласта, Армстронг и Олдрин устроились на полу, чтобы передохнуть, и второй из них заметил среди лунной пыли, покрывшей пол модуля, чёрный рычажок. Взглянув на панель, они поняли, что он отвечал за очень важную функцию — включал двигатель модуля. Без его переключения о взлёте с Луны можно было даже не мечтать. Астронавты сообщили в ЦУП о проблеме и попытались вздремнуть, а инженеры НАСА начали искать её решение. Они размышляли несколько часов, но так и не смогли придумать, как включить двигатель без переключателя. Астронавты вновь осмотрели гнездо, откуда отломился рычажок, и заметили в отверстии небольшой обломок. Олдрину удалось поддеть его ручкой, что, в принципе, спасло и людей, и всю лунную программу США.
Высадка на Луну. © NASA
-
Посадка
Командный модуль, в котором находились возвращающиеся на Землю астронавты, во время приземления чуть было не попал под горящие обломки служебного модуля. Перед входом в атмосферу нашей планеты «Аполлон-11» разделился на две упомянутые части. Командный модуль расположился тепловым экраном вниз, опустился в нижние слои атмосферы, где над ним раскрылся парашют, мягко опустивший людей на поверхность Тихого океана. Служебный же модуль должен был сгореть в атмосфере. В целях предотвращения столкновения ему полагалось совершить ряд маневров и оказаться на совершенно другой траектории. По плану он вообще должен был войти в атмосферу позже командного модуля. Однако конкретно в этом случае его двигатели не сработали, и обе составляющие «Аполлона-11» начали опускаться вместе. К счастью, сгорающие обломки не задели капсулу с астронавтами, и она благополучно приводнилась. Позже выяснилось, что ошибка была допущена в настройках сброса оставшегося топлива служебного модуля.
“Got the Earth straight out our front window.” As the lunar module Eagle yawed into a windows up orientation, Buzz Aldrin looked away from the computer to see the Earth nearly a quarter of a million miles away.
“Sure do,” agreed Neil Armstrong, adding, “Houston, [I hope] you’re looking at our Delta-H.” The Earth wasn’t his main concern for the moment. The mission’s commander was laser focused on getting the spacecraft down onto the Moon’s surface for the first time in history. He had just 30,000 feet to go …
“That’s affirmative,” replied Capcom Charlie Duke. The room full of flight controllers listened to the exchange while keeping a close eye on the numbers filling their screens, looking for any little anomaly that could force an abort.
Then came Armstrong’s voice over the radio again, this time marked a slight note of urgency. “It’s a 1202 … What is that? Give us a reading on the 1202 Program Alarm …”
The 1202 program alarm is featured is just about every retelling and dramatization of Apollo 11’s lunar landing. Understandably so; it was a dramatic moment in an already dramatic event that could have forced an abort and left the commander of Apollo 12, Pete Conrad, as history’s first man on the Moon. But it didn’t. As we know, Apollo 11 made it to the surface and the alarm has become little more than a story point. So what exactly was the 1202 program alarm that could have killed Apollo 11’s landing? To answer that question, we need to go back and understand a little more about how the Apollo Guidance Computer worked.
Armstrong training in the lunar module simulator. (Credit: NASA)
The Apollo Guidance Computer in Super Brief
By the time Apollo missions flew to the Moon, the software program that ran the mission could fit — though only just fit — into a set of read-only magnetic cores. This meant the pieces of information could be called up at any time and run nearly simultaneously, which was pretty important. Take the moment of landing on the Moon, for example. The computer needed to take in a lot of data points simultaneously to facilitate a good landing. It had to know where the lunar module was and where it was moving, information called state vector. It needed to maintain the right attitude based on that position, as well as velocity, altitude, and engine performance data. It also needed to adjust the abort trajectory constantly, ready to get the crew back into orbit should something force an abort.
Now think about a full lunar landing mission for a second — getting into Earth orbit, burning the engine to travel towards the Moon, recovering the lunar module, adjusting the course mid-way to the Moon, getting into orbit, landing, leaving the Moon’s surface, and traveling home. You can start to appreciate how many pieces of information would be going through that computer at any given time.
For the sake of simplicity, each task (a task in this case would be a single mission event like the lunar landing) was broken down into parts. These parts or programs were manageable modules that could be run individually while rendering the whole system more reliable.
If you’re following along you can see how this creates a potential new problem. The Apollo Guidance Computer was a single processor computer, computer. So how could it run multiple programs — the parts that make up a whole mission event — simultaneously? Well, it didn’t. Not really. But between relatively fast processing speed and relatively slow human perception it was simultaneous enough to run the mission smoothly. The programs were also scheduled and run based on priority with measures in place to interrupt any program should something vital come up.
In the case of the Apollo Guidance Computer, it had a 12-word data area called the Core Set. This contained all the information to execute a given program. There were six of these Core Sets in the Command Module and seven in the Lunar Module. In each 12-word Core Set, processing information took up five words, one each for the program’s priority, entry point address, copy of the BBANK register, flags, and the last pointed to the Vector Accumulator or VAC area. The seven remaining words were left for temporary variables or extra storage … whatever they might be. They’re called Multipurpose Accumulator or MPAC.
So in short: twelve words in the Core Set, five words of memory to execute a program, and the seven MPACs deal with the extra information as needed.
Scheduling a program falls to the Executive. It starts by looking at the task’s starting address and its priority, then passes that to the NOVAC routine. This scans the core set to see if there is any available space for the program to execute, and if so where that space is. It then schedules and runs the program.
Through exhaustive testing, the team at MIT’s Instrumentation Lab designed the computer such that it would never be full at any point in a mission. There would always be space available for the next program, rules in place to interrupt a program if something needed to be run immediately, or space to schedule the program after whatever was currently being run through the computer. But when Apollo 11 was descending towards the lunar surface, the computer ran out of Core Sets. This is where the 1201 and 1202 program alarms come in.
Apollo 11’s 1202 Alarms
Not long after the lunar module got into its 69 mile by 50,000 foot orbit in preparation for landing, the crew turned on their rendezvous radar to track the command-service module. This was was a safety measure. The radar tracked the CSM so it knew where to direct the lunar module in the event of an abort. The crew left the radar on in SLEW mode meaning it had to be manually positioned by an astronaut, and also meant that it wasn’t sending data to the computer.
What neither the astronauts nor the guys in Mission Control knew was that radar Coupling Data Units were flooding the Apollo Guidance Computer with counter interrupt signals. This was due to an oversight in the computer’s power supply design structure. These signals were taking up just a little bit of the computer’s processing time, and the spurious job kept running in the background, taking up space. So unbeknownst to anyone, this signal prevented vital programs associated with the landing from completing. When a new task was sent to the computer there was nowhere for it to go. The running and scheduled jobs were holding their Core Set and VAC areas.
Eventually the Executive found that there was no place to put new programs. This triggered the 1201 alarm signaling “Executive Overflow — No Core Sets” and the 1202 alarm signaling “Executive Overflow — No VAC Areas.” These in turn triggered a software reboot. All jobs were cancelled regardless of priority then started again as per their table order, quickly enough that no guidance or navigation data was lost. But it didn’t clear up the issue. The computer was still overloaded by the same spurious radar data, stopping new programs from running. In all, it triggered four 1202 alarms and one 1201 alarm.
Eventually Buzz Aldrin noticed a correlation. At the second 1202 alarm, he called down, “Same alarm, and it appears to come up when we have a 16/68 up.” The 16/68 code — Verb 16 Noun 68 — was used to display the range to the landing site and the LM’s velocity. The command in itself didn’t place a heavy load on the computer, but with the existing load that extra bit of processing power seemed to trigger the 1202 alarm. Realizing this, the solution was simple: ask Houston for that data instead of calling it up from the computer.
Houston, meanwhile, gave Apollo 11 a GO in spite of the alarms because of how spread apart they were — they came at mission elapsed time 102:38:22; 102:39:02; 102:42:18 (that was the 1201); 102:42:43; and 102:42:58. If they had been closer together it could have wiped out navigation data during a reboot, but being separated even by as few seconds as they were meant that that vital information was retained. The computer behaved exactly as designed, protecting itself in a way that wouldn’t cancel a lunar landing without just cause.
Safe Landing
The 1202 program alarm wasn’t something either Neil Armstrong or Buzz Aldrin had seen in training. Their time simulators had been filled with other alarms, most of which had them reaching for the abort button. Which was the right response. In simulations you train for the right reaction. But when they saw the 1202 and 1201 program alarms it was the real thing, which meant the right response was completing the mission objective. They weren’t going to give up on landing on the Moon if they didn’t have to.
The guys in Houston had the same response. “We’re go on that alarm,” Charlie Duke called back up, though he wasn’t entirely calm when he said it. The astronauts and flight controllers watched the second 1202 alarm blare on board the Eagle, followed by a 1201 alarm three minutes later then the last two back-to-back 1202 alarms almost immediately.
“Eagle, looking great. You’re Go,” came Duke’s call from Mission Control. Thanks to a handful of clever computer programmers, he passed up that Apollo 11 was still clear to land on the Moon.
Sources: NASA; NASA; NASA; The Apollo Guidance Computer by Frank O’Brien.
I agree with your comment «it’s not clear when or if this situation actually occurred.» From reading both Klumpp’s account and his colleague Don Eyles’ book Sunburst and Luminary I do not think we have enough information to know if the situation could have existed on Apollo 11. I think we know it did not exist on Apollo 11, because the radar power supply was not in phase, and Klumpp says
But when the radar’s power supply was in phase, queued commands,
valid only at some remote past time, could be completed and issued in
reverse order, momentarily taking control to guide the LM off its
normal landing trajectory.
(Emphasis mine)
Here is Eyles’ account of the problem from pp. 215-16 of S&L.
As 1970 dawned, with P66 Auto finished and onboard for the upcoming
mission, Allan and I found time to reconsider the problem that so
nearly ruined the Apollo 11 landing — deprivation of processor time,
which we called TLOSS-— but we went about it in different ways.Allan kept the IBM 360 humming as he ran simulations on the Apollo 13
rope to see how it behaved under varying amounts of TLOSS. We already
knew that if the amount of TLOSS was just right, then during a period
of high activity incomplete SERVICER jobs could accumulate in the
Executive queue. The last thing the SERVICER did on each pass was send
information to the DSKY for display. Just before it did that it issued
attitude commands, and before that, throttle commands. What concerned
Allan was what would happen if a SERVICER job was cut off before the
throttle or attitude command was sent out. If enough of these
suspended jobs accumulated, a software restart would occur, as it did
on Apollo 11, and the suspended jobs would disappear. But what if the
computational burden eased before they were flushed?What could happen, Allan found, was that the suspended jobs (Allan
dubbed them “lurkers”) could come back to life, unaware that they had
been in hibernation, and proceed to issue an attitude or throttle
command applicable to an earlier point in the trajectory. Suddenly the
LM might maneuver to the wrong attitude. The worst cases were when
suspended jobs that accumulated during P64 were executed after the
transition to P66.On March 4 Allan put out a carefully written memo describing
“a collection of known manifestations of time loss.” Allan described
eight separate modes of bad behavior, starting at a TLOSS of about 8
percent. In an unusual precaution Allan signed the memo, and asked
Gerry Levine to sign as having approved it.
(Emphasis mine)
My interpretation is that for the problem to happen,
- the rendezvous radar power supply would have to be in sync
- something would have to happen that made the SERVICER jobs run long and not complete
- Whatever caused 2) would have to go away before the situation got bad enough to flush the queue
We know that on Apollo 11 1) was not the case, but I do not know if we have enough information to know if 2) happened or not.
This answer attempts to explain the part about the radar power supply being out of phase.
Как случайно не разбился «Аполлон-11» +58
Космонавтика, Научно-популярное, Физика, Программирование
Рекомендация: подборка платных и бесплатных курсов дизайна интерьера — https://katalog-kursov.ru/
На днях в обычном офисном разговоре я сказал: «То, что у нас тут склад костылей — это нормально, во всех ИТ-проектах так. Наверное, из всего софта, который сделало человечество, только в программах посадки на Луну было все красиво». Сказав это, я полез в интернет, найти дополнительные факты к краткому научно-популярному рассказу для коллег о компьютерах и программах лунного модуля. Но одной из первых попалась ссылка, из которой выяснилось, что костыли, и, страшно сказать, баги были и в отшлифованном программном обеспечении, которое позволило человеку высадиться на Луну. А «Аполлоны» -11 и -12 смогли сесть, оказывается, только по счастливой случайности.
Софт и железо
Слева — компьютер, справа — дисплей и клавиатура
На командном и лунном модулях «Аполлонов» стояли идентичные компьютеры, но с разным набором программ. По тем временам это был фантастический хайтек, использовавший интегральные схемы, а не отдельные диоды и транзисторы. «Цикл памяти», примерно соответствующий тактовой частоте современных процессоров, занимал 11,7 микросекунд. Но практически все операции требовали два цикла, поэтому эффективная тактовая частота получалась равной 23,4 микросекундам, или 43 килогерцам, в 100 000 раз медленнее современных процессоров. Память компьютера составляла 36 тысяч 14-битных слов, что примерно соответствовало 64 килобайтам.
Постоянная память на проволоке и ферритовых сердечниках
Софт для лунного модуля разрабатывали примерно 300 человек в течение семи лет. Программа посадки на Луну имела название LUMINARY и хранилась в постоянной памяти на ферритовых сердечниках, провода сквозь которые продевались вручную. Создание такого блока памяти занимало несколько месяцев, поэтому софт должен был быть готов заранее. За годы «Аполлонов» программы модифицировались. На «Аполлоне-11» стоял блок с программой версии 99, а финальная версия (очевидно, посадившая Аполлон-17) имела номер 209. Главным дизайнером программы посадки был Алан Кламп (Allan Klumpp), недавний выпускник Массачусетского технологического института.
Процедура посадки
Посадка на Луну с точки зрения компьютера проходила в три этапа:
Программа P63 отвечала за торможение с орбитальной скорости.
P64 занималась выводом лунного модуля в район посадки.
P65 отвечала за финальный этап посадки.
На участке работы программы P64 пилот лунного модуля называл число, которое показывал на дисплее компьютер. Командир мысленно отмечал это число на шкале, которая была нарисована на иллюминаторе, и получал расчетную точку посадки.
Байка первая: ошибки 1201 и 1202
Довольно известен тот факт, что, когда Армстронг и Олдрин начали торможение с лунной орбиты, их компьютер выдал ошибку 1202. Это был очень нервный момент, потому что сами астронавты не знали значения этого кода. К счастью, специалист ЦУПа Стив Бейлс (Steve Bales) заранее написал список всех ошибок и быстро нашел расшифровку — компьютер не успевал справляться со всей работой. Компьютер «Аполлона» был системой реального времени, и он начал игнорировать некоторые низкоприоритетные задачи, выдавая сообщение об ошибке. Спустя еще минуту появилась новая ошибка — 1201. Но она относилась к этому же типу и не срывала посадку.
Уже после посадки была найдена причина. Как это часто бывает в сложных технических системах, причиной оказалась целая цепочка событий. Во-первых, после начала торможения инструкция требовала включить стыковочный радар на случай аварийного прерывания посадки. Стыковочный радар работал от другого источника питания, нежели компьютер. Этот источник питания имел ту же частоту, но не был синхронизирован по фазе с источником питания компьютера. Небольшие смещения фазы на радаре выглядели для компьютера как дрожания неподвижной в реальности антенны. В норме при посадке процессор компьютера был загружен на ~85%. «Дрожащая антенна» добавила еще 13%. А когда Олдрин дал команду компьютеру посчитать разницу между реальной и рассчитанной высотой по посадочному радару, компьютер оказался в условиях перегрузки. Уже потом посчитали, что это событие «украло» примерно минуту процессорного времени, а из 10 раз в секунду компьютер управлял стабильностью лунного модуля 9 раз. Кстати, баг с дрожащей антенной был замечен на тестировании, но его оставили, потому что он проявился всего один раз, а замена оборудование на новое могла создать более опасные баги.
Та самая посадка, видео повернуто для удобства восприятия, и добавлено много полезной информации. В видео упоминается программа P66, это альтернативный вариант одной из программ
А здесь можно посмотреть на посадку виртуально, с разных сторон.
Байка вторая, счастливая ошибочная оптимизация
Как известно, «Аполлоны» -11 и -12 сели успешно. Однако впоследствии, уже после возвращения астронавтов, по телеметрии в двигателях посадочной ступени обнаружились опасные колебания — тяга то поднималась вверх, то падала вниз. К счастью, колебания не стали слишком сильными и не вызвали проблем с управлением или двигателем. Расследование показало, что причиной колебаний являлось программное обеспечение. Программистам был доступен специальный документ, в котором описывались параметры и свойства лунного модуля. В разделе о двигателе было указано, что он имеет инерционность 0,3 секунды. То есть через 0,3 секунды после команды на изменение тяги он должен был выйти на новый уровень. Это надо было отразить в программе, поэтому была написана специальная подпрограмма, которая измеряла тягу двигателя по данным акселерометра и выполнялась за 0,3 секунды. Но финальная версия этой подпрограммы писалась другим программистом, который решил ее улучшить и сделать быстрее. Новая версия успевала выполниться за 0,2 секунды. Ее протестировали на симуляторе, и она показала себя там отлично. Однако разработчики двигателя улучшили его, и время задержки упало до 0,075 секунды. А внести это изменение в документ для программистов просто забыли. Последующие тесты показали, что, если бы подпрограмма определения тяги работала изначальные 0,3 секунды, то система бы оказалась нестабильной, и колебания становились бы все больше и больше, что привело бы к прыжкам тяги двигателя от минимальной до максимальной и обратно, а это бы, наверняка, сорвало высадку.
Байка третья, о проблемах интерполяции
Напоминаю, что программа P64 нацеливала лунный модуль в точку над местом посадки. Однако, поскольку для расчета траектории использовались полиномы высоких степеней, траектория, выходя в точку прицеливания, могла оказаться под поверхностью Луны. Потому что полином высокой степени мог «прыгнуть» в сторону (это знают математики и инженеры):
Чем выше степень, тем больше может быть этот «прыжок», несмотря на то, что график проходит через все желтые точки
Ирония с этим багом состоит в том, что его никак не исправили. Программа не отслеживала потенциально опасные кривые. Баг не проявился в реальных посадках, но его мог вызвать не такой уж невозможный случай. Если бы лунный модуль немного сбился с курса и оказался над неучтенным достаточно глубоким кратером, компьютер, получая данные от посадочного радара, мог бы подумать, что оказался выше траектории, пересчитать кривую на более крутую и направить лунный модуль к прицельной точке, нырнув сначала в Луну. Отдельно доставляет рецепт борьбы с багом, если бы он проявился — астронавтам надо было бы переместить точку прицеливания за предел досягаемости по запасам топлива и подержать ее там некоторое время. Вы когда-нибудь совершали странные действия, чтобы переупрямить глючную программу? Можете себя поздравить, астронавтам возможно пришлось бы делать то же самое…
The 50th anniversary of the historic Apollo 11 landing on the moon takes place on July 20, 2019.
You might recall the famous utterance heard worldwide that the Eagle had landed (the word “Eagle” was the name given to the lunar module aka lunar lander used in the Apollo 11 mission).
Going back in time to that incredible feat that occurred five decades ago, listen carefully to the recorded audio chatter between astronauts Neil Armstrong and Buzz Aldrin while carrying on a dialogue with the mission control center during the descent to the moon.
Unless you are a nerdish fan of computers or spaceflight, you might not have noticed that there was a subtle undercurrent of concern about some rather jarring, alarm-blaring, display-flashing error codes known as the numbers 1202 and 1201.
It’s an incredible story that the general public knows little about.
Let’s unpack the tense tale, along with considering lessons learned that can be applied to the now emerging self-driving driverless autonomous cars.
Anxious Moments During The First Landing On The Moon
The lunar module that was being piloted down to the moon surface began to report errors when the craft was just seven and a half minutes away from landing.
Think about this for a moment. I assure you that having errors crop-up while in the midst of such an already tricky and risky effort is not something you desire to occur. It was later indicated that the heart rates for both the astronauts jumped up feverishly when the errors began to appear.
Things were tense, especially since landing on the moon had never actually occurred before and had only been practiced in a simulator.
The astronauts were faced with the possibility that they might need to call off the landing if something went awry during the descent. If they didn’t land on the first try, there was no second try available and they’d have to sheepishly and disappointingly return to earth without having landed on the moon.
It would have been a crushing blow to NASA, it would have been a heart-wrenching let-down for the country, it would have potentially tarnished the image of America worldwide, along with creating an expanded window for the Russians to try and get to a moon landing before the United States did.
Everything was on the line.
Of course, worse still would have been a crash landing onto the moon, which one shudders to even contemplate.
Two obscure error codes were involved, each consisting of four digits, and represented status that there was an issue or problem occurring in their spacecraft. During the design of the system for the lunar lander, the developers had come up with a slew of error codes that could be displayed if the computer detected something amiss on the craft.
Here’s the rub. When the astronauts had done simulated landings, doing so over and over again, not all of the possible error codes were tested out, and thus there were some error codes that the astronauts had never seen or directly knew about.
As luck or unluck would have it, the two error codes of 1202 and 1201 had not been previously exhibited during their training efforts. As such, the astronauts were unaware of what those particular error codes signified. Furthermore, even most of the mission control staff monitoring the landing had not seen the 1202 and 1201 before either.
Okay, let’s try to relive history.
Put yourself into the cramped lunar module. With just minutes left to land, bells start ringing and buttons are flashing, trying to get your rapt attention. Nearly immediately, the astronauts realized they didn’t know what the error code signified, and so they (remarkedly) calmly brought it to the attention of mission control:
“It’s a 1202.”
Within mission control, there were blank stares as by-and-large no one knew what the 1202 was about. Meanwhile, Steve Bales, a guidance officer, called over to a backroom area where various engineers were stationed and ready to dig into any system related matter that might arise.
“1202. What’s that?” he reportedly asked.
John “Jack” Garman, a NASA engineer, took a look at a list he had handmade of the numerous error codes that the teams had come up with.
He realized that the 1202 was a code meaning that the guidance computer on-board the landing craft was getting overloaded with tasks. The programmers had anticipated this overloading might someday occur, and so had established a system internal aspect that would automatically do a fast reboot and then a memory restore to try and get the computer back underway.
In theory, the computer was going to be able to resolve the error, without needing any human intervention. Garman said afterward that he figured if the 1202 error code didn’t recur frequently during the rest of the descent, the astronauts were probably okay to proceed in spite of whatever was seemingly overloading the onboard computer system.
“Give us a reading on the 1202 program alarm,” Neil said.
In the recorded voice transmissions, you can hear in Neil’s voice a seriousness and sternness and exasperation that so far no one from mission control had yet told the astronauts what to do about the error.
Again, place yourself in the lunar module and imagine that you’ve got this crazy unknown 1202 error code screaming at you, you’ve never seen it before, you don’t have any procedure in-hand to deal with it, and it could be something extremely dangerous, happening in real-time, while you are aiming to hopefully safely land on the moon, and you are completely in-the-dark as to what it is and what you are supposed to be doing about it.
Each second that the 1202 remains an unknown could be another second toward your doom.
Within mission control, Darmon and Bales relayed internally that the astronauts should proceed on the landing, and so capcom Charlie Duke said to the astronauts:
“We’re go on that alarm.”
In this context, “go” means that the landing could continue to proceed unabated. Also, since no further instruction of what to do was being voiced to the astronauts, it implied that the alarm, whatever it meant, could be ignored. If you are wondering whether the astronauts might have been curious about what the 1202 represented, I believe they only cared at the moment about whether the 1202 required any action on their part.
I was fortunate to have had lunch with Buzz Aldrin during a recent visit he made to Los Angeles, and when I asked him about the 1202, he indicated indeed that once mission control essentially said to not worry about it, he let it go and didn’t put any further thought towards it.
This makes sense too, namely that no additional explanation or elaboration was particularly needed per se, plus the astronauts already had their hands full with trying to land, so they set aside worries about the 1202 and focused on the landing process.
If you listen to the remaining minutes of the recorded audio, you’ll hear that the 1202 error happened again, and again, along with a related error code of the 1201. Mission control informed the astronauts that it was considered the same type of error and implied therefore that there was no need to do anything about the alarms.
For everyone listening at the time of the actual moon landing, the chatter seemed to be the normal kind of interaction you’d expect between the astronauts and mission control, often technical in nature and you don’t really know what their jargon means or signifies.
In this case, it was a subplot of grave concern and intensity, but that millions upon millions of people listening were unaware was playing out in real-time and could have ditched the landing entirely.
That’s the story within the story about the Apollo 11 moon landing.
Lessons Learned For Self-Driving Driverless Cars
Can a systems related matter that happened some fifty years ago be of relevance today?
Absolutely.
Self-driving driverless cars are real-time based systems that need to act quickly and drive a car while the vehicle is in motion, perhaps on a freeway and barreling along at 70 miles per hour.
Onboard the autonomous car are numerous computer processors, including various electronic memory banks used to house programs that are being executed or performed to drive the car. In addition, there is a myriad of sensors on the car, such as cameras, radar, ultrasonic devices, LIDAR, and the like, all of which are collecting data during the driving act and relaying that data into the computer processors and memory banks.
In the case of the 1202 error on the Eagle, what prompted the error was (in simple terms) a faulty radar unit that was essentially bombarding the onboard computer in such a manner that the computer kept getting handed task after task, though the flooding tasks weren’t truly needed to be undertaken. The Operating System (OS) of the computer allowed the memory to fill-up, but then this meant that other legitimate tasks would not have a slot to work in.
As I had mentioned earlier, the programmers had anticipated that somehow for whatever reason there might be a time when the onboard computer might become overloaded with tasks. They had devised an internal mechanism that if something untoward led to the memory getting maxed out, the system would do a fast reboot and memory reload, which hopefully would clear out whatever was causing the initial problem.
Though this does suggest that the computer can then proceed with the high priority of running the craft, notice that it does not necessarily solve the underlying problem of the radar unit that’s pounding away at the computer. In any case, the good news is that the trick of the quick reboot was able to deal with the matter and the other precious landing subsystems were able to do their thing, meanwhile the radar was continuing to be an irritant but not so much that it led the craft astray.
How many times have you rebooted your smartphone or laptop computer and then had it clear up a problem?
I’m betting you’ve done such reboots many times.
Have you also perchance done a reboot and then later on the same problem seemed to crop-up?
That’s a somewhat similar case of the 1202, namely that the reboot temporarily “solves” the problem of letting the computer proceed, but it didn’t “solve” the root cause of the faulty radar unit aspects.
Here then are some insightful Apollo 11 lessons for AI developers, automakers, and tech firms that are creating the software and systems for driverless cars:
• Anticipate and code for wayward sensors. You cannot assume that the sensors on the driverless car will be working flawlessly. Besides the obvious aspect that the sensor might get blinded by dirt or debris, there is also the chance that the sensor could go awry due to some internal bug or issue. Make sure to code for this possibility and have some provision of what to do once the matter arises.
• Ensure that the driverless car OS is robust. Some of the operating systems being used for autonomous cars are somewhat stripped down for speed, yet they need to also be able to handle a wide variety of both known and unpredictable faults or systems issues that could happen. Make sure the OS is up to the task of supporting the systems involved in driving the car, safely so.
• Do not ignore edge cases. The focus for most driverless car efforts right now is aiming at driving during normal everyday conditions, and not dealing with unusual or infrequent kinds of driving situations (so-called “edge” aspects). This though belies the true aspects of driving which can include foul weather, bad roadways, and the like. Autonomous cars that are being tried out on our public streets need to be ready to handle edge or corner cases.
• Testing must be exhaustive. If you leave out test cases when testing a driverless car, you are setting up a potentially dangerous situation that someday in the real-world the thing you didn’t test will happen, and perhaps have quite adverse consequences. Testing needs to be as complete as feasible.
• Use reboots cautiously and only as a last resort. Imagine you are in a driverless car, zipping along on the highway, and the AI announces that it needs to do a reboot, right away. This is not the same as doing a reboot on your smartphone when you are playing a video game that froze-up the phone. Developers should consider an on-board reboot as a last resort and only invoked with great caution.
Conclusion
You’ll be happy to know that the amount of computer capability packed into a self-driving car is many magnitudes greater than the puny but valiant computers used on the Apollo 11 spacecraft.
Those programmers in 1969 could only dream of someday having access to the incredibly powerful computing that we commonly have available today. Even your smartphone is by far superior in computer power than were the lunar lander computers.
That’s though just the hardware side of things.
From a software perspective, we still today can readily have the same kinds of issues occur, including hidden bugs or suddenly appearing faults, which could have happened back in 1969. Let’s make sure that we learn the lessons of the past and therefore are extremely mindful when designing, coding, testing, and fielding autonomous cars.
Thanks go to NASA and all those involved in getting us to the moon, and hopefully, today’s driverless cars will be prepared for any 1202 or 1201 codes that might pop-up.
Покорение Луны: как астронавтам удалось то, чего не смогла самая совершенная на тот момент техника
20 июля 1969 года посадочный модуль «Орел», на борту которого были астронавты Нил Армстронг и Эдвин Олдрин, впервые в истории доставил людей на Луну. Правила жизни рассказывает, почему в космической гонке 1960-х победить помогла не автоматика, а пресловутый человеческий фактор, позволивший совершить историческую высадку, едва не сорванную ошибками техники.
Часто можно услышать, что человек на борту космического корабля — кто-то вроде свадебного генерала. Якобы всю работу за него делают автоматы, а сам он работает простым символом престижа пославшей его страны.
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
Валентина Понамарева, входившая в советский женский отряд космонавтов, так вспоминала отношение к космонавтам на заре космической эры: «Человек на борту вроде и необязателен, считаться с его запросами и требованиями поэтому особенно не стоит, нужно только обеспечить ему условия существования и, по мере возможности, безопасность. Пусть себе сидит там, на борту, только пусть ничего не трогает!». Это не преувеличение: конструкторам казалось, что управление космической техникой слишком сложное, требует слишком быстрой реакции, и поэтому доступно только автоматам. Были подозрения, что космонавты могут вести себя неадекватно: даже в первом полете Гагарин мог взять на себя управление, только введя специальный пароль (тот должен был подтвердить его вменяемость).
Однако в реальности человеческий фактор, который конструктора трактовали в негативном ключе, позволил миссии «Аполлон-11» состояться, а ноге Нила Армстронга — коснуться поверхности Луны.
Превышение скорости и нервный компьютер
16 июля 1969 года с Земли на ракете «Сатурн-5» стартовала миссия «Аполлон-11». Через трое суток пилотируемый корабль «Колумбия», на борту которого находились Нил Армстронг, Эдвин Олдрин и Майкл Коллинз, был доставлен третьей ступенью к Луне. На окололунной орбите, во время нахождения над обратной стороной Луны, от него отстыковался 15-тонный лунный посадочный модуль «Орел». Коллинз остался в «Колумбии», а Армстронг и Олдрин — на «Орле», который 20 июля 1969 года попытался сесть на поверхность Луны.
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
Корабль «Колумбия», сфотографированный из «Орла» сразу после разделения на фоне обратной стороны Луны.
NASA
В 17.44 по Гринвичу, «Орел» начал снижение к лунной поверхности, причем с самого начала процессом управляла именно автоматика. Почти сразу Армстронг и Олдрин обнаружили, что те элементы лунной поверхности (горы и прочее), над которыми они должны были пройти по заранее утвержденной программе полета в строго заданный момент времени, видны в иллюминаторы на 2-3 секунды раньше, чем должны бы. Тут же они сообщили в центр управления полетами о замеченной аномалии. Получилось, что «Орел» по какой-то причине двигался слишком быстро. Расчеты показывали, что сесть в районе Моря Спокойствия все равно выйдет, но на километры западнее намеченной точки.
Почему автоматика оказалась неточной — до сих пор не вполне ясно. Одна из версий — «масконы» у поверхности Луны, концентрации плотных пород, делающие лунное притяжение над некоторыми точками поверхности чуть сильнее, чем над другими. На самом деле, причин может быть много, вплоть до неточного управления тягой двигателей. Автоматика не безупречна не то что в 1969, но и полвека спустя (достаточно вспомнить недавнее крушение израильского посадочного аппарата «Берешит» при посадке на Селену в апреле этого года).
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
Посадочный модуль «Орел» с Армстрогном и Олдрином сразу после расстыковки с «Колумбией». Хорошо видны «ноги», посадочные опоры модуля, которые должны были коснуться лунной поверхности одновременно.
NASA
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
Через пять минут после начала снижения к проблеме «превышения скорости» добавилась еще одна. Бортовой компьютер «Орла» начал непрерывно бомбардировать астронавтов сообщениями об ошибках. Надо понимать, что его сообщения об «ошибке 1201» и «ошибке 1202» вообще ничего не говорили экипажу: в ходе наземных тренировок все не отработать, и астронавты просто не могли знать, что означает каждая из возможных ошибок компьютера. Центр управления быстро проконсультировался в теми, кто программировал компьютер на предмет того, можно ли продолжать снижение, или «Орлу» надо возвращаться к «Колумбии». В этом случае никакой исторической высадки, конечно, не было бы, но не было бы и риска угробить экипаж лунного модуля.
Специалисты поняли смысл сообщений об ошибках: компьютер рапортовал, что не успевает обрабатывать все свои задачи в реальном времени, и поэтому отменял второстепенные. Другое дело, что с Земли на самом деле было невозможно понять, насколько именно компьютер не справляется с задачами и насколько отмена второстепенных задач может поставить под угрозу успешность прилунения. Поэтому когда Стив Бэйлс ответил, что посадку можно продолжать, он до некоторой степени рисковал.
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
Посадка
Представим себя на месте астронавтов Армстронга и Олдрина. Горы несутся в иллюминаторе быстрее положенного, высадка будет не пойми где, а тут еще и компьютер жалуется, что ему нехорошо. Обстановка нервная, но тут же к ней добавилась еще одна неприятная деталь. Выглянув в иллюминатор снова Армстронг увидел, что модуль снижается над местность, усеянной крупными валунами 2-3 метра в диаметре. Достаточно взглянуть на хрупкие ноги модуля, чтобы понять: они не были предназначены для посадки на такую поверхность.
Если бы модуль повалился на бок, он не мог бы взлететь с поверхности вверх: трение о реголит уничтожило бы его. Поднять 15-тонную железяку, лежащую на боку, вручную, без инструментов и в тогда еще несовершенных скафандрах было бы очень сложно. Да и не факт, что приземление на бок прошло бы без травм для самих астронавтов. Еще один корабль и модуль никак не смогли бы подоспеть к Луне вовремя. Да и в любом случае, на лунных модулях просто не было места для эвакуации двойного экипажа. При посадке «на автомате» двоих астронавтов в лучшем случае ждала бы смерть после полного расхода запаса воздуха.
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
Надо было уже что-то решать, и в 200 метрах над лунной поверхностью Армстронг активировал ручное управление. Ранее у него уже был опыт управления «неправильными» летательными аппаратами. Во время войны в Корее ему приходилось быть пилотом поврежденного боевого самолета, а на борту космического корабля «Джемини» он смог вручную погасить другой сбой автоматики, вызвавший неконтролируемое вращение аппарата с перегрузками в 3,5 g. Между прочим, именно это спасло экипаж корабля от гибели.
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
Рабочее место Армстронга в лунном модуле «Орел»
NASA
Армстронг уменьшил угол траектории «Орла» относительно поверхности с 18 до 5 градусов, то есть резко замедлил снижение в надежде перелетать поле с валунами. Точный размер поля был ему не очень ясен, потому что горизонт на Луне визуально много ближе, чем на Земле, и даже с 200 метров видно не так уже и далеко. Перелетев попавшийся на пути кратер, Армстронг нашел подходящее место для посадки. Однако чтобы быстро потерять высоту, ему нужно было тормозить двигателями — и он вынужден был потратить на этот процесс немало топлива. Остававшийся на борту запас был равен чуть более, чем минуте полета до прилунения. Посадка осложнилась тем, что газы от горящего топлива подняли облако пыли с лунной поверхности, но пилот ориентировался на верхушки крупных валунов, чтобы понять, насколько быстро он снижается. Несмотря на все трудности, посадка прошла идеально мягко. В 20.17 по Гринвичу «Орел» сел с 98 килограммами топлива в посадочной ступени.
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
Человек на Луне: непредвиденные сложности, большая научная отдача
Следует понимать, что в спешке лунной гонки не все было в достаточной мере испытано на Земле, а в ряде случаев оборудование астронавтов еще и не слишком удачно спроектировали. Поэтому американские скафандры плохо гнулись в коленях, что принуждало астронавтом передвигаться подпрыгиваниями и не очень далеко от корабля. Перчатки скафандра сгибались очень тяжело, отчего после работы в них у астронавтов синели ногти (от запекшейся крови, выступавшей от длительных усилий при сгибании кистей). Тем не менее, уже первая лунная экспедиция собрала 21,7 килограмма лунных пород для доставки на Землю. К слову, это больше, чем привезли на нашу планету все автоматы, высадившиеся на Луне (те собрали менее килограмма). Даже если взять пробы, доставленные с астероидов, роботы все еще не догнали первую же высадку людей на Луне по массе собранного внеземного грунта.
Астронавт Дэйв Скотт вскоре после возвращения с Луны. Хорошо видны следы крови под ногтями, следствие работы в неудачных перчатках скафандра
NASA
Научные результаты от одной первой миссии были очень серьезными. До того полета считалось, что Луна сформировалась «по-холодному», от слипания частиц протопланетного диска, без серии крупных столкновений. Образцы же свежедоставленного лунного грунта были очень древними (до 4,5 миллиардов лет, древнейшие из доступных людям), но при этом несли следы формирования при полном расплавлении. Такие высокие температуры были возможны, только если Луна образовалась совсем иначе, «по-горячему», в ходе столкновения крупных небесных тел. При этом происходит мощное выделение тепловой энергии, способное расплавить даже довольно крупное небесное тело, или, по крайней мере. значительную его часть.
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
Олдрин после развртывания прибора по улавливанию частиц солнечного ветра. За ним виден модуль «Орел», чья автоматика едва не погубила и Олдрина, и Армстронга.
NASA
В последующих экспедициях на Луну астронавтам дали луномобили, в которых они за считанные сутки проезжали десятки километров за экспедицию. Это помогло им собрать образцы из самых разных мест, что дало земной науке более полное представление о разнообразии состава лунной поверхности. «Луноход-2» — рекордсмен в беспилотных заездах по Луне: он смог за всю карьеру проехать 40 километров, примерно столько же одолел марсоход «Оппортьюнити» за полтора десятка лет на Марсе. При этом ни один планетоход не может доставить грунт на Землю, а спускаемые аппараты, которые на подобную доставку были рассчитаны (как советская «Луна-24»), могли взять пробу грунта только прямо под местом посадки. Само собой, в разных местах породы разные, и поэтому широта данных по образцам автоматов куда меньше, чем по тем, что астронавты брали в самых разных местах.
Олдрин на фоне мятого флага США. Флаг был нейлоновым на проволочным каркасе, и хранился свернутым, а после развертывания проволока выпрямилась не полностью, что и породило мифы о «развевающемся на ветру» флаге и «съемках в павильонах Голливуда»
NASA
РЕКЛАМА – ПРОДОЛЖЕНИЕ НИЖЕ
В наше время и научные достижения первых пилотируемых экспедиций на Луну, и сама сложность первой высадки во многом забыты: прошло 50 лет, да и NASA не особенно любит рассказывать про шалившую автоматику и синие ногти первых астронавтов. Тем не менее, и то, и другое более чем достойно памяти.
Установка из 1960-х про роль человека в космосе — «Пусть себе сидит там, на борту, только пусть ничего не трогает!» — была опровергнута в первой лунной экспедиции. Человек в ней оказался сообразительнее и точнее автомата, и именно ему, а не дистанционно управляемым планетоходам принадлежит первая роль в изучении геологии Луны.