Пилотируемая высадка на Луне, запланированная в миссии Artemis III, увы, официально перенесена на 2028 год. NASA столкнулась с эрозией покрытия в ходе миссии Artemis I. К этому добавились задержки Axiom Space со скафандрами AxEMU и технологическая сложность Starship HLS. Последнему необходимо отработать схему для перекачки криогенного топлива на орбите и выполнить беспилотную тестовую посадку.
В статье я постарался разобрать азы теории оптимального спуска, написал скрипт посадки на PowerShell, проанализировал спуск LM-5 Eagle, пилотируемого Нилом Армстронгом, и применил современный метод оптимизации управления G-Fold.
Для меня пилотируемый лунный спуск — личная тема, повлиявшая на выбор профессии программиста. В 1985 году журнал «Техника‑Молодёжи» начал знакомство с системой команд программируемого калькулятора Б3-34. Тогда же, летом, журнал запустил цикл статей Михаила Пухова «Кон‑Тики» и программ Игоря Данилова, моделирующих посадку на Луну (потом был взлет, все этапы перелета к Земле и посадка). Первой была пошаговая программа «Лунолет-1» для вертикальной посадки в условиях ограничения топлива. Я использовал тогда более современный программируемый калькулятор МК-61, траектории чертил на миллиметровке, а позже, в 1990-м, выбрал эту задачу как лабораторную университетского курса автоматизированных систем управления. Тогда же возникли мысли об автоматизации посадки и поиске векторов тяги в многомерном пространстве состояний — это было время, когда нейросети сложнее персептрона заменяли классическим матанализом.
Вот та самая программа для Б3-34, с которой все началось:
Классическое пошаговое моделирование. Вводим тягу, нажимаем кнопку С/П, цифры в окошке мелькают, через секунду получаем новую высоту и скорость. Пока не сядем.
Ниже - скан инструкции к программе, если кому захочется прогуляться по аллее памяти (интересно, а эмулятор Б3-34 есть в природе?)
Условия задачи описать просто — у нас есть посадочный модуль известной массы, который падает в плоском поле тяготения (считаем, что ускорение свободного падения не меняется с высотой). Нам известны вес модуля плюс вес топлива, вертикальная скорость и высота. Вокруг нас вакуум, так что сопротивление атмосферы не учитывается. Регулируя тягу в известных пределах, надо добиться плавной посадки с минимальной вертикальной скоростью в момент касания, при этом израсходовав как можно меньше топлива (расход топлива зависит от используемой тяги). Также надо учитывать, что при работе двигателя вес топлива уменьшается, что делает управление модулем более отзывчивым.
Подобных оптимизационных игр было много в 80-х годах, условия были разными — где‑то надо было регулировать не только вертикальную, но и горизонтальную скорость, где‑то — уклоняться от падающих метеоритов и садиться на сложный рельеф. Добавлять условия можно до бесконечности, но сейчас займемся классической задачей вертикального спуска.
Какая стратегия наиболее эффективна в таких условиях? Если мы должны минимизировать расход топлива, надо помнить, что каждая секунда, проведенная в поле тяготения (в нашем случае, Луны), требует компенсации ускорения. Если модуль зависнет над поверхностью, двигатель будет впустую расходовать топливо на удержание высоты без совершения полезной работы. Суммарная характеристическая скорость выражается интегралом
Для минимизации затрат массы необходимо сократить время работы двигателя. Это достигается применением максимальной тяги в кратчайший промежуток времени непосредственно перед контактом с поверхностью. Такая ст��атегия называется Suicide Burn.
Математическая модель строится на системе дифференциальных уравнений, где состояние системы описывается вектором [координаты, скорость, масса]. Двигатель должен быть либо полностью выключен, либо работать на пределе мощности. В фазовой плоскости координат высота-скорость (изменением массы пока пренебрегаем) существует кривая торможения, в каждой точке которой включение максимальной тяги обеспечивает обнуление скорости точно в момент касания грунта.
Математически все красиво — при достижении линии включаем двигатель на полную мощность, тормозим, и садимся с нулевой скоростью. Вот только такая стратегия не зря называется суицидальной. Двигатель не может за мгновение прыгнуть с нуля на 100% тяги. Придется включить его немного раньше, чтобы у нас был запас во времени, а потом, снижаясь, плавно регулировать тягу.
Тут поведение чуть более сложное. Вначале модуль свободно падает (верхняя часть пунктирной кривой). За 2 сек до достижения «дедлайна» — толстой линии, двигатель включается и за 2 сек доходит до полной тяги. Далее мы просто тормозим полной тягой, приходя в точку (0,0). Хотя нет — мы придем в точку чуть выше (0,0) и зависнем там. Почему? Потому, что мы включили двигатель раньше идеальной кривой. Поэтому придется держать тягу двигателя чуть меньше 100%, стремясь к нулевой точке. Но это хорошо — у нас есть запас по высоте и скорости, если что‑то пойдет не так. Чем больше мы будем снижать риск, чем больше потратим топлива, уходя дальше от оптимальной кривой и теоретического минимума расхода.
Но минимизация расхода топлива — не единственный критерий оптимизации. Что, если мы хотим сесть как можно быстрее? Тогда надо не рассчитывать на естественный набор скорости во время свободного падения, а... разгоняться самостоятельно, перевернувшись дюзами вверх. План такой: первую половину пути мы разгоняемся полной тягой, потом в заранее рассчитанный момент переворачиваемся дюзами вниз и тормозим опять же полной тягой, как раньше.
Форма диаграммы посадки не сильно изменилась — просто теперь мы быстрее достигаем идеальной кривой спуска. Надеюсь, никто из пассажиров не везет с собой аквариум с рыбками.
Есть еще одна оптимизация — комфорт. Это когда нам все равно, сколько топлива потратим и сколько будем снижаться. Главное, чтобы во время посадки ускорение не менялось слишком быстро. Выглядит такая посадка, как спуск на тросе: мы держим постоянную тягу чуть меньше, чем для полного зависания и плавно приходим к нулевой точке, линейно уменьшая скорость.
Теперь двигатель работает все время. Первую половину посадки модуль держит тягу 85% от зависания (взял 85 наобум). Это не свободное падение, то есть не невесомость, так что вода из аквариума с рыбками не соберется в шар и не отправится в полет по кабине. Вторую половину посадки мы выдерживаем уменьшающуюся в зависимости от высоты скорость — максимальный комфорт для пассажиров (и для рыбок). Обратите внимание — теперь диаграмма посадки прижата к оси Y, в диапазоне небольших вертикальных скоростей. Но чем дальше мы от оптимальной кривой, тем больше топлива потратим — плата за комфорт.
Осталось промоделировать посадку скриптом, взяв исходные данные у реального посадочного модуля LM-5 Eagle, на котором прилунились Нил и Базз. Фунты и футы из документа NASA я переводил в привычные килограммы и метры.
static [double]$DryMass = 4500.0 # масса посадочного модуля LM-5 без топлива (кг) static [double]$FuelStart = 10500 # начальная масса топлива LM-5 (кг) static [double]$MaxThrust = 45000.0 # максимальная тяга двигателя DPS LM (Н)
Коэффициент перекрытия тяготения вычисляется как отношение максимальной тяги к текущему весу:
Двигатель модуля обеспечивал почти двукратный избыток тяги, что критически важно для компенсации гравитационных потерь на этапе торможения. По мере выработки топлива и уменьшения веса, этот избыток рос.
Двигатель посадочной ступени (DPS), разработанный компанией TRW, работал на топливной паре «горючее‑окислитель», которая самовоспламенялась при контакте компонентов, так что понятие «зажигание» к такому двигателю неприменимо. Но задержку включения я все же учел — сервоприводы имеют свою инерцию. Расход топлива при максимальной тяге 10500 фунтов (около 46.7 кН) составлял примерно 15.3–15.4 кг/с, при минимальной тяге примерно 1.7 кг/с, а при максимально регулируемой — около 10кг/с.
Двигатель имел также малоизвестную особенность — дроссель позволял эффективно регулировать тягу в интервале от 10 до 60 процентов. При тяге менее 10% двигатель гасился, а превышение 65% становилось нерегулируемым. «Мертвая зона» дросселирования фактически находилась в диапазоне от 65% до 92.5% максимальной тяги. Проблема заключалась в игольчатом инжекторе: в некоторых его положениях возникала турбулентность и кавитация, которые могли привести к прогару камеры сгорания и разрушению сопла. Бортовой компьютер при выполнении программы P63 (этап торможения) удерживал тягу строго на уровне 100%. Когда расчетная потребная тяга опускалась ниже 92.5%, компьютер мгновенно «прыгал» через запрещенный диапазон до уровня 57–60%, переходя в режим плавного регулирования. Любая команда в интервале 65–92% игнорировалась логикой управления. Это я учел при моделировании.
static [double]$MinThrustPct = 10.0 # минимально регулируемая тяга двигателя (%) static [double]$MaxThrustPct = 65.0 # максимально регулируемая тяга двигателя (%)
Еще одна особенность посадки — отключение двигателя непосредственно перед прилунением. Сопло в посадочной конфигурации почти касалось грунта. При работающем двигателе это создавало бы избыточное давление в сопле и могло разрушить двигатель, поэтому инструкция строго предписывала гасить двигатель непосредственно перед посадкой. Чтобы точно знать когда, с опор модуля свисали «усы» длиной 1.7м. Когда хотя бы один из них касался грунта, на пульте загорался индикатор «LUNAR CONTACT» и пилот должен был отключить двигатель.
В реальной посадке Нил замешкался и отключил двигатель за мгновение до прилунения, но все обошлось. Мы в скрипте будем отключать автоматически.
В документе Analysis and Historical Review of the Apollo Program Lunar Module Touchdown Dynamics приведены вертикальные (и горизонтальные, но я их опустил) скорости прилунения модулей всех миссий. Я перевел в привычные м/c:
Номер миссии | Скорость, м/c | Примечание |
11 | 0.55 | Нил заглушил двигатель поздно, поэтому скорость рекордно низкая |
12 | 1.01 | поднятая пыль сделала невозможным визуальный контроль посадки |
13 | не садился на Луну из-за аварии | |
14 | 0.94 | сел на склоне с ощутимой боковой скоростью 0.7м/c, а не вертикально |
15 | 2.07 | самая жесткая посадка - Дэвид заглушил двигатель слишком рано, модуль рухнул, к тому же на склон 11 градусов; впрочем, это было в пределах допустимого |
16 | 1.71 | без происшествий |
17 | 0.91 | без происшествий |
Ну и я учел, что двигатель не выходит на выбранную тягу мгновенно — сервоприводы, то, сё... Переход тяги от текущей до заказанной идет плавно, по S‑кривой (я взял косинус).
Задержку реакции DPS я не смог найти в официальных источниках, но она явно порядка сотен миллисекунд.
static [double]$IgnitionTime = 0.7 # время включения двигателя (с) static [double]$CutoffTime = 0.6 # время отключения двигателя до полной остановки тяги (с) static [double]$ThrottleLag = 0.5 # время реакции двигателя на изменение команды тяги (с)
Осталось задать исходные условия. Отпустим модуль в свободное падение с начальной нулевой вертикальной скоростью, с заправленными баками с высоты 3км. План посадки таков: на контрольной высоте 1750м мы включаем двигатель на полную тягу и гасим вертикальную скорость до 15м/с, после чего переходим на регулируемую тягу 10%-60%. Наша цель - подойти на высоту 20м со скоростью не более 1м/с, а потом плавно гасить ее до 0.1м/c (почти зависание), до момента касания висящих усов поверхности. В момент срабатывания датчиков контакта двигатель выключается и мы на остатках тяги прилуняемся. Расчетная скорость прилунения должна быть в районе 1м/с. У реального модуля LM-5 это была рекомендованная скорость, а предельная расчетная составляла 3 м/с при условии нулевой горизонтальной скорости. На больших скоростях начинались неприятности с опорами вплоть до фатальных.
class Firmware { static [double]$HeightGate1 = 1750.0 # этап 2: включение двигателя на 100% (м) static [double]$VelocityGate2 = -15.0 # этап 3: переход на дроссельную тягу 10-60% (м/с) static [double]$HeightGate3 = 20.0 # этап 4: финальное замедление (м) static [double]$VelocityGate3 = -1.0 # целевая скорость после торможения (м/с) static [double]$VelocityGate4 = -0.1 # целевая скорость на cutoff (м/с) }
Ну, что, как говорится, поехали! Будете пробовать сами — просто запустите скрипт mode1a.ps1. Никаких ключей в командной строке нет; вся конфигурация и стартовые данные внутри, в начале скрипта.
Тормозим на полной тяге. Я пробовал и видео mp4 делать и gif захватывать, но результаты меня не устроили; скриншота хватит. Если интересно (вряд ли, конечно), вот телеметрия спуска.
Ну и успешная посадка. Хорошо сели — 1м/с, как и было запланировано. Сожгли полторы тонны топлива... Но гораздо интереснее смотреть на графики.
Четко видны три фазы. Сначала свободное падение по «параболе» до 40-й секунды, когда скорость достигла 65м/с. Тогда включился двигатель на полную тягу (еще есть короткая фаза «зажигания», но в реальности DPS зажигания не имел, смесь воспламенялась сама — так что это просто задержка между подачей команды и включением) и мы погасили скорость до приемлемой к 78-й секунде. Тогда мы перешли на дросселирование и управляемый спуск — сначала на максимально разрешенной тяге, 60% от полной, которая к моменту зависания над поверхностью была снижена до 49%. Максимальная «перегрузка» была только в момент торможения 40–78с и достигла аж трети земной. Последний излом в ноль в конце графика — это краткий миг невесомости после выключения двигателя и до прилунения на посадочные опоры.
А вот так выглядит диаграмма посадки:
Видно, как от свободного падения (короткий верхний отрезок) мы перешли к практически оптимальному торможению, которое перешло в управляемый спуск (небольшой излом ближе к посадке) и быстрому прилунению (второй излом) после гашения двигателя и падения на опоры.
Кто будет ковыряться в скрипте: он в файле mode1a.ps1. Он же записывает телеметрию в mode1a.log и строит графики. Его функции вынесены в functions.ps1, а юнит‑тесты к ним — в tests.ps1. Диаграммы из статьи тоже строятся PS скриптами: graph1.ps1, graph2.ps1, graph3.ps1, graph4.ps1, graph6.ps1. Используются только родные команды PowerShell и.NET компоненты рисования; никакие сторонние библиотеки не подключались. Учтите, что PowerShell очень не любит русские символы в строках. Чтобы не глазеть на кракозябры в консоли, сохраняйте файлы в кодировке UTF-8-BOM, а не просто UTF-8.
А как в реальности садился LM-5 Eagle? Увы, подробная телеметрия исторической посадки была утеряна NASA (как и некоторые кадры кинохроники - аплодирую стоя!). Все, что нарыл - отчет 1970 года Apollo Lunar Descent and Ascent Trajectories.
После отстыковки от орбитального модуля на высоте 110км был выдан тормозной импульс, чтобы перейти на эллиптическую орбиту с минимальной высотой (перелунием) в 15км над поверхностью. При выходе на минимальную высоту 15км началась активная фаза торможения (по сути, это и есть момент схода с орбиты). За эту фазу посадки отвечала автоматическая программа P63.
P63 активировалась на высоте 15км при горизонтальной скорости 1.7км/с. Вертикальная скорость была равна практически нулю. Двигатель был запущен на максимум, чтобы погасить горизонтальную скорость. На высоте 13700м модуль совершил разворот «окнами вверх, дюзами вниз» для захвата поверхности посадочным радаром LR. Вывод данных на приборную панель начался на высоте 12км. Компьютер привел модуль к контрольной точке High Gate, которая была на высоте 2300м (вертикальная скорость на High Gate, к сожалению, не упомянута, но у других миссий она была в этот момент 30-50м/c, а горизонтальная - 140-150м/c). До места посадки оставалось 8км, угол глиссады составлял 16 градусов. Далее активировалась программа P64.
На контрольной точке Low Gate работа программы P64 завершилась (высота 156м, вертикальная скорость 4.9м/c) и должна была заработать программа автоматической вертикальной посадки P65, но на высоте 125м Нил принял решение переключиться на полуавтоматическую посадку в режиме P66. Это решение было принято из-за того, что расчетное место посадки оказалось полным камней и надо было перелететь через него.
В полуавтоматическом режиме P66 Нил управлял вертикальной скоростью, нажимая две подпружиненные кнопки переключателя ROD на рукоятке - они увеличивали или уменьшали вертикальную скорость спуска на 1 фут в сек (0.3м/с), а компьютер подбирал тягу дросселем, чтобы выдержать указанную скорость спуска. Нил визуально контролировал посадку, глядя в свое обзорное окно, а Базз непрерывно надиктовывал данные по высоте и скорости, чтобы Нил не отвлекался на приборную панель.
Касание усом грунта произошло при вертикальной скорости 0.9м/c. Про этом зажглась лампа «LUNAR CONTACT», о чем Базз предупредил Нила. Но Нил отключил двигатель позже, за мгновение до посадки, полностью сосредоточившись на контролируемом спуске. Горизонтальная скорость в этот момент была нулевой — на последних метрах модуль опускался строго вертикально.
Пилоты, как и ЦУП, достаточно понервничали, так как загорелся индикатор DES QTY — критически низкий уровень топлива 5%. Но, как выяснилось позже, это было ложной тревогой из‑за несовершенства датчиков. Нил активно маневрировал горизонтально, топливо плескалось в баке и датчик выдавал неверный уровень. Начиная с Apollo 14, в баки добавили специальные перегородки‑гасители, чтобы ничего больше не плескалось — соломоново решение. Там еще были ошибки 1201/02, которые отвлекали от посадки — из‑за операционных прерываний от радара, когда нагрузка на процессор превышала его возможности, очередь сообщений переполнялась.
Общее время полуавтоматического снижения P66 ниже 125м составило две с половиной минуты. Забегая вперед, ни одна из последующих миссий так не использовала программу автоматической посадки P65, предпочитая полуавтоматический контролируемый спуск P66. Программистам было, вероятно, обидно.
В Apollo траектория посадки описывалась полиномом второй степени, и задача бортового компьютера AGC сводилась к тому, чтобы на каждом шаге интегрирования вычислять требуемое ускорение для попадания в целевую точку. Эта схема плохо адаптируется к резким изменениям условий и требует ручного вмешательства.
В Artemis III (и конкретно в Starship HLS) будет работать алгоритм G‑Fold (Goddard Fuel Optimal Landing). Основные проблемы Apollo были из‑за того, что множество параметров управления имеют свои особенности, нелинейности и запрещенные участки, как у тяги (0–10%, 65%-92.3%). Как говорят математики, решение по минимизации расхода топлива становится «невыпуклым» — это сложная N‑мер��ая функция с «холмами» и «впадинами» и искать глобальный минимум решения в реальном времени — та еще задача. В G‑Fold пространство параметров управления подвергается преобразованиям. Например, масса убывает по мере траты топлива и тяга становится нелинейной функцией — мы это решали постоянным пересчетом тяги по ходу облегчения баков с топливом. Заранее сказать, сколько будет потрачено топлива, алгоритм не мог и приходилось полагаться на предварительные расчеты. В G‑Fold применяется логарифмическая замена переменных для массы:
Вроде элементарно, но это превращает дифференциальные уравнения из нелинейных в линейные относительно переменных.
Как поступили программисты шестидесятых и как поступили мы в нашем скрипте — установили контрольные точки с заранее подобранными параметрами [координаты, скорость, вес], траекторию между ними подобрали полиномом, а компьютер, управляющий посадкой, постоянно сверял фактические данные полета с предвычисленной кривой и подгонял тягу и ориентацию модуля под нее.
# этапы 3-4: адаптивное управление тягой # целевая скорость — линейная интерполяция по высоте if ($H -gt [Firmware]::HeightGate3) { # этап 3: от текущей высоты до HeightGate3 # целевая скорость: от VelocityGate2 (-25) до VelocityGate3 (-3) $frac = ($H - [Firmware]::HeightGate3) / ` ([Firmware]::HeightGate1 - [Firmware]::HeightGate3) $targetVelocity = [Firmware]::VelocityGate3 + ` ([Firmware]::VelocityGate2 - [Firmware]::VelocityGate3) * $frac } else { # этап 4: от HeightGate3 до HeightCutoff # целевая скорость: от VelocityGate3 (-3) до VelocityGate4 (-0.3) $frac = ($H - [Constants]::HeightCutoff) / ` ([Firmware]::HeightGate3 - [Constants]::HeightCutoff) $targetVelocity = [Firmware]::VelocityGate4 + ` ([Firmware]::VelocityGate3 - [Firmware]::VelocityGate4) * $frac }
Все это работает, если только план полета не приходится менять на месте. Именно это ограничение программы P65 заставляло экипажи Apollo отказываться от автоматической посадки на заключительном этапе и переходить на полуавтоматическое управление, стараясь не сесть на камни или крутой склон.
G‑Fold превращает невыпуклую и нелинейную функцию расхода топлива в выпуклую, а найти минимум у такой функции — дело миллисекунд. То есть мы получаем теоретический оптимальный план полета в любой момент времени, а неизбежные отклонения — неравномерность тяги, недолеты, перелеты, возможные отказы, смена места посадки — неважно, оптимальный план полета всегда в распоряжении компьютера.
Вместо предвычисленных контрольных точек траектории просто задаем желательную скорость при посадке и запас по высоте:
class Firmware { static [double]$TouchdownVelocity = -0.3 # целевая скорость при касании (м/с) static [double]$SafetyMargin = 1.10 # запас высоты для начала торможения (10%) }
Теперь посадим современный G-Fold на пульт архаичного модуля с его ограничениями и посмотрим, как справится он в тех же исходных условиях - посадка с 3км. Скрипт mode2a.ps1:
Уже без анализа телеметрии видно что посадка у G-Fold заняла 117сек против 181сек, и топливо G-Fold потратил 944кг вместо 1443кг. Да и сел мягче. За счет чего такой результат?
Видно, что включение двигателя на полную тягу произошло у обеих программ на 40-й секунде, на высоте 1750м (у G‑Fold на 10 м выше), вот только для классического спуска я подобрал эту точку экспериментами, а G‑Fold вычислил ее сам в реальном времени.
Различие — в последующем регулируемом спуске. Классическая программа окончательно перешла на дросселируемую тягу на высоте 114м и дальше спускалась по контрольным точкам, а G‑Fold держал вычисленную тягу до самого отключения у поверхности. Это незаметно на графике, но телеметрия говорит, что классический алгоритм после фазы интенсивного торможения перешел в режим «затянутого» спуска, подгоняя траекторию к контрольным точкам. G‑Fold же поддерживал более высокую вертикальную скорость до последних метров, завершив посадку почти на минуту быстрее. В классическом режиме (mode1a) после 78-й секунды тяга сбросилась в регулируемый интервал и далее плавно снижалась до 49%. G‑Fold (mode2a) перешел на дросселирование чуть раньше (на 74-й секунде), но удерживал тягу на более эффективном уровне (60-63%), обеспечивая непрерывное и энергичное снижение скорости вплоть до отключения двигателя.
А экономия полтонны топлива произошла из‑за того, о чем я говорил в самом начале — каждую секунду, проведенную в зависании или медленном спуске, двигатель вынужден тратить топливо просто на то, чтобы уравновешивать лунное притяжение, не совершая полезной работы. G‑Fold же с первых секунд полета оптимизирует траекторию так, чтобы минимизировать время работы двигателя.
Переход от полиноминальных алгоритмов к адаптивности G‑Fold — необходимость для Starship HLS. Ему предстоит посадка на южном полюсе Луны, а южный полюс встретит экстремальным рельефом и игрой длинных теней. В таких условиях нельзя полагаться на глаза пилота. Здесь автономная система должна за миллисекунды переваривать данные радаров, лидаров и камер, перестраивая траекторию 200-тонной махины так, чтобы самостоятельно найти ровную площадку, без ям и камней. Математика в конечном итоге заменит реакцию и интуицию пилота.
Зачем все эти полеты на Луну, когда столько незавершенных конфликтов и нерешенных проблем на Земле? Космос остается самым мощным катализатором инженерного прогресса из когда-либо существовавших. Как игра с увеличительными стеклышками в 17-м веке не была решением тогдашней первостепенной проблемы — чумы, но стала инструментом, позволившим её в итоге победить, так и разработка систем для посадки на Луне создает технологический фундамент для решения земных проблем. Мы идем в космос не потому, что у нас закончились дела дома, а потому, что задачи вроде этой заставляют нас изобретать алгоритмы, приборы и материалы, которые позже станут стандартом в нашей повседневности — как автопилоты пятого уровня в автомобилях однажды. Мы начинаем воспринимать нашу планету как межпланетный корабль с замкнутой системой жизнеобеспечения. И каждая строчка кода, оптимизирующая расход топлива — это вклад в наше общее умение управлять этой системой здесь, дома. Мы мечтаем о других планетах, но в итоге лучше видим и понимаем то, что находится у нас под ногами.
Другие статьи на Хабре:
Что, если Солнце исчезнет?
развернутый ответ на вопрос «Что если?»Путь Солнца Золотого
о судьбе нашего Солнца, о его пути и о нашем вместе с нимИмя для гнома
неожиданный экскурс в незнакомые области знания для закрытия мелкой задачиЭволюционная проповедь
как бы священник, прочитавший Докинза, обращался бы к хабровчанам