Симулятор Союз-ТМА - Часть 1⁠⁠

Всем привет! Мы продолжаем публикации по разработке симулятора Союз-ТМА.

С момента последней публикации прошло довольно много времени и пока мы все (я очень на это надеюсь) остаемся дома, то мы решили предоставить Вам свежую информацию по симулятору. Работа кипит и кипит, а следовательно скоро будет первая версия, которую будет не стыдно показать.

Итак от слов к делу. Полностью обновилось СПО МиУ (Моделирование и Управление), которая разработана исключительно для отработки алгоритмов вычислительных процессов в БЦВК Союза и НЕ будет использоваться в симуляторе. Т.е. повторюсь - это не симулятор, а программа для отработки алгоритмов, которые потом будут перенесены уже непосредственно в сам симулятор.

Так что стоит про него рассказать еще немного, постараюсь вкратце, но получится лонг, как всегда...  В будущем я постараюсь составить полноценное руководство пользователя для МиУ, ссылку на которое дам в следующем посту.

На скриншоте выше главный экран МиУ. Все что отладочное (т.е. в данном случае необходимое только для разработки самого МиУ) вынесли в отдельную группу, лишнее стараемся убирать по возможности. В процедуру инициализации добавили обмен с Юнити, так как уже начата работа по этому направлению и поэтому налаживаем ТСР и УДП обмен (пока только двусторонними квитанциями МиУ<->Unity) с Юнити.

Большинство команд в бортовые системы корабля Союз-ТМА выдаются с формата КСП (Командно-Сигнальное поле), который входит в состав информационного обеспечения (и программного то же) ИнПУ. У нас этот формат реализован как на тренажере ДОН-Союз и ТДК-7СТ (что бы не изобретать велосипед - все равно в работу не пойдет), в симуляторе конечно мы будем использовать ИО штатное, которое использовалось на кораблях 200й серии (Союз-ТМА). Вот как выглядят форматы КСП левое и правое (почему левое и правое - читайте тут) в МиУ:

А вот как выглядит формат КСПл на ИнПУ (версия для 213-го изделия)

разница незначительная.

ну и вдобавок КСП на штатном железе в ЦПК, эта фотка гуляет по сети много. и на центральном (ИнПУ 2) загружен формат КСПп. По поводу дикого различия в цветах расскажу отдельно, это еще та задачка, которую мы пока что так и не решили.

У нас реализованы основные алгоритмы обработки выдачи этих команд и многие из них ( в основном касающиеся работы вычислительного комплекса Аргон-16) отрабатываются так же как если бы вы выдали их на реальном корабле (с учетом всех задержек и т.п.). Если вам будет интересно, расскажу как мы это реализовали с программной точки зрения...хотя чего рассказывать - вот репозиторий МиУ. Все что можно я комментировал там. Так же в разработке руководство пользователя по МиУ, о чем говорилось выше.

Логика КСП проста - в реальности команды с КСП - это релейные команды в бортовые системы, в коде это просто запись true в переменную команды (команда - это булевая переменная) и снятие ее (т.к. она релейная) прибором, в который она поступила. Как раз таки снятие ее после выдачи и есть квитанция от прибора, есть еще вариант с использованием short, где если возвращается 1, то это обозначает, что прибор "запитан", если возвращается 2 - команда отправлена, но нет квитанции и т.п.

Хочу привести небольшой пример скрипта одной команды КСПл - А1"ОТКР КРЫШКИ СКД" - Открытия защитной крышки Сближающе-Корректирующего Двигателя (СКД).

Оператор находится в спускаемом аппарате и выдает с ИнПУ с формата КСП команду А1, тем самым записывая в обработчик команд КСП (если будем переносит как алгоритм в Юнити, то скорее всего сделаем в виде отдельного скрипта), где написано, что если ksp_cmd[0][1]=true, тогда проверяем отсутствие признака "отстрел БО-ПО"(признак наличия/отсутствия отсека корабля на котором установлен СКД) и запускаем скрипт открытия крышки. Скрипт этот - анимационный скрипт на 15 секунд открывающий крышку двигателя. По окончанию циклограммы открытия скрипт выдает команду, которая в обработчике индикации КСП (горит/не горит транспарант)  зажигает команду А1, как факт ее отработки (срабатывание концевых выключателей). В МиУ этого не видно, но отрабатывается примерно так.

Продолжим.

Это было по поводу выдачи команд оператором в системы ТК, а теперь пару слов о возвращаемых (формируемых бортовыми системами) квитанциях для представления оператору в виде транспарантов. Мы так же использовали метод, используемый в тренажере ДОН-Союз. Так что для отладки был сформирован вот такой вот формат "ТС" (Табло Сигнальное), на который выводятся квитанции о состоянии систем. Структура проста - на форме стоит таймер, на тик которого записана обработка булевых значений квитанций, если true - тогда соответственно зажигаем транспарант и наоборот. Конечно в ПО ИнПУ это реализовано несколько сложнее, но для первоначального этапа подойдет.  На фото ниже представлен этот формат с активным состоянием некоторых транспарантов во время отработки команды на запуск Гибкого Цикла (довольно интересная штука - я обязательно о ней расскажу) 

Так вот космонавту на пульте "Нептун-МЭ" (с которым он работает большую часть времени) вся эта информация так же представляется. Вот постарался так стрелками показать, может получилось тупо, но как есть

Последние две группы транспарантов  (под пультом на фото ниже) формируются непосредственно на форматах ПО ИнПУ. Кстати в ПО ИнПУ то же есть свой отладочный формат, где отображаются все ТС (даже больше чем у меня на формате), вот как он выглядит. Если будет интересно, расскажу значение этих транспарантов.

Сразу видно какие необходимы для выдачи, а какие только для отладки. Кстати обмен с ИнПУ мы уже наладили и у нас передаются пакеты от МиУ в штатное программное обеспечение пульта космонавтов "Нептун-МЭ", единственным минусом которого является его -16-ти битность и соответственно невозможность прямого запуска в современных ОС (без использования эмулятора), соответственно нам или придется его переписывать или как то (с шагом 0.100 с) снимать с него картинку и перенаправлять ее в Юнити, для того, что бы накладывать ее как динамическую текстуру, что бы реализовать вид от первого лица в спускаемом аппарате, как на этой фотке.

Так же для решения задач разработки алгоритмов для Симулятора сделали упрощенный вариант имитатора пульта БРУС (Блок Ручного Управления Спускаемым аппаратом) на фото ниже. Пока не прописали ни одного скрипта для него, думаю что так может получится, что он вообще не понадобится и отработку уже будем на 3d делать

Остальные пульты и физические приборы с которыми взаимодействует космонавт пока что не трогали, но до них обязательно дойдет очередь, просто в связи с тем, что мы выбрали движок Юнити писать все равно придется на C#, поэтому это может даже и хорошо, что не делали. Единственные функции, которые может выполнять БУРС - логирование при переводе переключателя в другое положение (в коде так же просто запись true или false в bool"евую переменную и вызов процедуры логирования в журнал.

Ну на этом пока что из того, что относится к текущим обновлениям по МиУ всё. Есть конечно еще несколько форматов - штатные форматы лэптопа РС МКС для управления системой стыковки (точнее выдачи команд или запуска процедур) Служебного Модуля (узла по оси +Х, так как на первом этапе будем отрабатывать автоматическую стыковку именно к нему), но он пока без логики вообще. Только графический интерфейс и стандартный набор процедур и команд. Постарались передать максимально пользовательский интерфейс ОС Солярис (которая используется на лэптопах РС МКС). Так что про него и рассказывать то нечего, вот только скрин покажу и все.

Все с МиУ закончили, теперь перейдем к самому интересному - Юнити. Ранее никто из нас никогда с Юнити не работал - говорю сразу. Это первый опыт. Скажу свое мнение по поводу языка C# - после долгой работы на плюсах он очень неудобен. Думаю со временем это пройдет и мы подружимся, надеюсь на это.
Первоначальная задача проекта в Юнити на текущем этапе разработки такая -
МиУ интегрируя уравнения движения КА Союз-ТМА и МКС формирует на выходе нам вектора положения, скорости и ориентации относительно J2000, которые мы вместе с признаками для ТСЭ (горит/не горит) и другими командами упаковываем и посылаем в Юнити.

Но так как мы хотим полностью отойти от МиУ и перенести все алгоритмы в Юнити ,вместе с этим упростив ввод начальных условий, то вначале мы стараемся сформировать основную базу в самом Юнити.
Для этого мы создали первый элемент игры - главное меню (куда же без него) - пока без красивой графики (хотя были варианты) из задуманной анимации, а просто для отладки действия по клавишам.
Сделаю небольшую отсылочку отвечающую на вопрос, почему же мы налаживаем обмен Юнити с МиУ, а не переносим сразу все алгоритмы и не продолжаем разработку в Юнити - мы не знаем в каком виде перенести алгоритмы - то ли это будут динамические библиотеки, то ли это будет отдельное консольное ПО, то ли это останется МИУ - пока неизвестно, поэтому мы на первом этапе делаем обмен Юнити с МиУ.
Возвращаемся к нашим баранам (главному меню) - вот первый скрин главного меню для симулятора.

Ну тут все понятно и пояснений не требует - скажу только, что в настройках будет формат экрана, звук, выбор органов управления (с клавиатуры или джойстиком или может у кого есть штатные РУДы) и еще по мелочи. Так как пока непонятно как именно будут реализованы (в какой оболочке) алгоритмы систем Союза, то в Юнити так же как и в МиУ требуется предстартовая подготовка (как я понимаю во многих играх при загрузке именно это и происходит - не только загрузка в память моделей и др., но и выставка начальных параметров в заданное состояние) - процедура инициализации. Пока что в нее включено лишь создание ТСР и УДП клиентов для обмена с МиУ. Мы хотим на первом этапе реализовать простейшую логику - игра запускается, создает сокет подключения к МиУ и отправляет квитанцию о запуске в МиУ, где в журнале появляется соответствующее сообщение.

Для этого мы создали отдельную папку net, в которой разместили скрипт sockets в котором описана работа с сокетами. В корневой папке scripts лежим скрипт инициализации init_proc. В нем пока всего два метода - это Initialization (непосредственно сама процедура инициализации, которую я думаю м оставим тут насовсем, просто изменив ее структуру под требуемые задачи) и функция  i_test - возвращающая код ошибки результата инициализации.

Кстати пару слов о том в чем работаем - мы решили использовать Visual Studio Code т.к. он не требователен и не грузится как танк (по сравнению с VS).

Вернемся к меню. Что бы упростить по максимуму выставку начальных условий, мы решили поставить пользователю всего два выбора - выбрать корабль и выбрать непосредственно сам режим, так что по нажатию кнопки "Новая игра" пользователь переходит в меню выбора режима.

Тут он может выбрать корабль и режим. Почему так? и почему выбор сценария, а не режима как я пишу в тексте выше? Да потому что вишенка на торте -  управление всеми бортовыми системами в полностью автоматическом режиме. Нет конечно пользователю надо будет выдать некоторые команды (те же что выдают космонавты для включения режима автоматики), а так как пользователь не параметры орбиты вводит, а выбирает корабль, то соответственно для этого корабля и режима полета уже заранее известны все интересующие нас параметры. К примеру схема сближения и стыковки корабля Союз-ТМА 9 (как раз на него у нас есть программное обеспечение пульта космонавтов, а так же некоторые алгоритмы)

По этой схеме мы можем получить море информации, необходимой для организации автоматического контура управления космическим аппаратом. Все эти параметры уже заранее рассчитаны были баллистиками в службе БНО ЦУП еще задолго до полета самого корабля и такие схемы есть на все корабли серии ТМА (правда найти их - все равно что иголку в стоге сена, а просить ЦУП - то же думаю что бесполезно, вряд ли они будут ради нас в архивах копаться). Так к чему же это я все, да к тому, что выбор режима полета сводится к выбору всего двух параметров - корабля и режима, а уже корабль подразумевает в себе очень и очень много информации - тут и дата/время и соответственно положении земли на начало режима (время Т0) и т.д. т.п. Тем самым мы даем возможность людям, которые в первый раз запустили симулятор без особого труда выбрать и запустить режим.

Небольшое примечание - на первом этапе разработки мы работаем только с орбитальным участком полета т.е. от момента отделения от РН Союз-ФГ и до момента стыковки, т.е. этапы спуска и выведения мы не рассматриваем пока вообще.

Но так же нам дается возможность ввести Начальные Условия (в виде Кеплеровых элементов орбиты Союза и МКС или векторов скорости и состояния в J2000.0)  и отработать их.

По нажатию кнопки "ПУСК" запускается процедура отработки начальных условий - загружаются из базы параметры и состояние выбранного корабля, загружается конфигурация МКС для данного корабля (да учитывайте, что конфигурации МКС менялись!), после чего на сцене планета Земля выставляется на начальное положение соответствующее моменту Т0 (t ноль - модельное "внутри игровое" время начала режима(полета)), выставляются согласно параметрам из базы корабль и станция, если в реальном полете были нештатные ситуации, то они так же отрабатываются (вообще про НшС у нас будет отдельный пост). После всех этих операций программа загружает вторую сцену, где у нас находится вся эта каша-мала и начинается интегрирование уравнений движения, преобразование результата в X, Y, Z, Vx, Vy, Vz, Qs, Qx, Qy, Qz и изменение положения центра масс объектов согласно этим данным. Пользователь находится внутри спускаемого аппарата и у него имеется два основных органа управления (если изначально введен режим ручного управления и выставлены соответствующие признаки, иначе ничего работать не будет) - Ручка управления Ориентацией и Ручка Управления Движением, которые задают угловые и линейные моменты соответственно.

Вот на этом пока и закончим. Еще несколько фото из Юнити Союза (текстуры в последнюю очередь).

Ниже представлен скриншот изделия 11Ф732 Союз-ТМА номер 219 (если кто заметил что ДПО нет одного и то, что они не для ТМА - знаем, исправим). Как видите оси соответствуют начальным строительным осям корабля и тут отсутствует смещение центра масс, согласно заданному, т.к. это смещение идет вместе с параметром корабля, когда его выбирает пользователь, ведь загрузка корабля всегда разная и положение центра масс всегда разное, конечно нам не удастся найти (что очень очень жаль) значения центра масс для всех кораблей, но у нас имеются кое-какие значения на 7-10 сценариев, что бы отработать их точно.

P.S. С прошлого поста к нам в команду пришло несколько людей (за что им огромная благодарность) и у нас в команде сейчас 7 человек, но этого по прежнему очень очень мало, так что если вам интересен космос и пилотируемая космонавтика и вы желаете принять участие в нашем проекте - пишите в дискорд - #3179

или на почту - soyuz.developer@gmail.com
а так же в телегу - @SoyuzDeveloperTeam