SoyuzDeveloper

И я решил сделать себе для компьютера программу с точно таким же функционалом, шрифтом и т.д. Ну уж очень мне они понравились. По итогу получилось вот что

И сделал в добавок справочное окно с описанием принципа работы с ними

Все кнопки функциональны, а за тумблеры прошу простить не смог нормально их сделать.

Собственно нарыл инструкцию к часам

Все сделал на C++ Builder 2006

Скачать можно по ссылке

В начале мы получали только значение долготы и широты, для формирования трассы полёта

Позже добавили множество других параметров для отображения

Эти данные позволили нам дать приблизительное понимание о точности данной модели. Сейчас мы связываемся с Баллистическим Центром им. Келдыша для увеличения точности этой модели за счёт сравнения векторов. Параллельно с этим мы будем добавлять туда уравнения вращения, дабы оперировать векторами угловой скорости и углами.

Раз уж такой проект, то и модель должна быть сверх точная. Мы учитываем приливы и отливы, гравитацию планет, коэф. светового давления, не сферичность Земли, гравитационную шахматку и многие другие возмущения, которые сделают эту модель максимально точной и приближенной к реальности. Как только модель будет сделана, мы займемся моделями датчиков и остальным.

Вот пример формата набора начальных условий для понимания точности модели

Мы будем держать Вас в курсе событий.

Для связи с нами пишите на misha.lexperience@mail.ru

С Уважением, команда SoyuzDeveloperTeam

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

На первом этапе разработки мы (так как не имели опыта в области gamedev) стали делать 3d модели, текстуры и т.д, но через определенное время поняли, что в первую очередь надо было реализовать сами алгоритмы, поэтому было решено описать вначале сами алгоритмы, циклограммы и т.д. Так как мы планируем в симуляторе моделировать все режимы полета (предстартовая подготовка, выведение на орбиту, орбитальный полет, сближение и стыковка, расстыковка и спуск), это ставило определенные сложности в реализации штатного набора алгоритмов, поэтому мы решили сделать отдельное программное обеспечение, моделирующее полет по заданным Начальным Условиям и посылающее в Систему Компьютерной Генерации Изображения (среду, где будет происходить формирование 3D моделей и их расположение на сцене согласно параметрам поступающим из ПО управления) параметры текущего положения и ориентации каждого объекта на сцене - корабля, станции и других небесных тел в виде структур массивов. Обмен между ПО и СКГИ происходит по TCP\IP.

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

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

Теперь подробнее про "МиУ".

СПО "Моделирование и Управление"

На фото выше представлен скриншот текущего состояния "МиУ".

Данное СПО вряд ли будет публиковаться как симулятор, оно скорее всего только для отработки алгоритмов вычислительной системы и не более. Написано на С++ в среде C++ Builder 6. Пользовательский интерфейс реализован по подобию UI тренажера подготовки космонавтов "ДОН-СОЮЗ ТМА-М" в ЦПК.

Возможности пока ничтожны, зато успехи велики.

По запуску СПО пользователю предлагается провести процесс инициализации, в котором будет проведена проверка сопутствующий файлов программы (файлы конфигурации, файлы моделей и т.д.), а так же попытка установки связи с моделью Блока Управления Моделированием и моделью ИнПУ. Ход процесса инициализации можно проконтролировать в журнале:

При успешной инициализации загорятся иконки моделей,

что будет свидетельствовать о установке соединения с выбранными оператором моделями.

После чего пользователю необходимо будет ввести Начальные Условия текущего положения космического корабля Союз и МКС. Делается это в несколько этапов:

1 - Выбор режима полета

- Посадка экипажа в корабль за два часа до команды Пуск (Контакт Подъема) ( Ткп - 02:: ) - в этом режиме происходит предстартовая проверка систем корабля экипажем совместно с специалистами пуска ( в симуляторе - выставка согласно бортовой документации (чеклисту) параметров корабля и подготовка к пуску);

- Выведение - процесс от момента пуска (Ткп  - Время Контакта Подъема) до Контакта Отделения; 

- Орбитальный полет - этап от момента КО (Контакта Отделения) до начала режима дальнего сближения. О процедурах входящих в состав этого режима напишу отдельно;

- Сближение и стыковка  - этап начиная от дальнего сближения до касания корабля и станции.

- Расстыковка - начинается за час до расчетного времени расстыковки Союз-ТМА и МКС, за это время экипаж должен произвести ряд стандартных операция входящих в состав подготовки к расстыковки. Заканчивается разделением корабля на отсеки перед входом в плотные слои атмосферы.

- Спуск - этап от разделения до ввода двигателей мягкой посадки.

Переходим к следующему этапу. Исходя из выбранного режима пользователь вводит остальные параметры начальных условий -
Параметр ориентации:

Параметры орбиты:

И дополнительные характеристики корабля и МКС

И напоследок необходимо ввести время и дату начала режима.

После чего на главной форме нажимается кнопка "Отработка НУ" которая отрабатывает введенные пользователем Начальные Условия (или загруженные из файла) и выставляет начальное состояние признаков для модели Вычислительной системы и БУМ.

Остается только выдать команду "ПУСК" и начнется процесс моделирования.

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

Так же в данный момент занимаемся моделью атмосферы в которую входит модель Системы Обеспечения Теплового Режима и Системы Обеспечения Жизнедеятельности. Модель атмосферы должна в основном моделировать температуру и давление в отсеках корабля.

Формат СОТР выглядит следующим образом:

Дополнительно ввели графики для отслеживания изменения параметров:

Ну а теперь перейдем к самой интересной части...

Система Имитации Визуальной Обстановки

В тренажере стыковки "Дон-Союз ТМА" для решения задачи 3-х мерной визуализации используется Система Компьютерной Генерации Изображений «Ариус-СТ»

Назначение системы согласно сайту компании Бликс www.bliks.ru

формирование цветных, управляемых в реальном масштабе времени по командам от вычислительной системы тренажера изображений трехмерных динамических сюжетов внешней визуальной обстановки, наблюдаемых одновременно в шести средствах наблюдения рабочего места операторов «РМО ТМА» тренажера «Дон-Союз ТМА» (визир ВСК-4Т, левый иллюминатор №3, правый иллюминатор №6, ИнПУ-1,2, «Блистер объект», «Блистер фон»), моделирования совместно с другими системами тренажера отдельных режимов работы бортовой телевизионной системы «КЛ-100-01М» и форматов системы «Символ» для рабочего места «РМО ТМА».

У нас же задачи проще:
Программа должна генерировать 3-д модели и изменять их положение и ориентацию на сцене согласно параметрам от СПО "МиУ".

Требования к графике - реалистичные текстуры, хорошее и правильное освещение, отсутствие пластмассовости. 

Вывод картинки должен быть в девяти режимах, из которых 8 статических (неподвижная точная с неподвижным связанным с некоторым объектом вектором направленности) - визир ВСК-4Т, левый иллюминатор №3, правый иллюминатор №6, ИнПУ-1,2, «Блистер объект», «Блистер фон» и один режим отображения динамический - вид от "лица командира корабля" имитирующий глаза космонавта.

Управление планируется от первого лица.

Вот приблизительно что видит командир корабля на своем штатном месте:

Ну и то что мы сделали - вид от первого лица.

Какую информацию выводить на экран пока не решили, будем этим заниматься когда все алгоритмы закончим и отладим их.

Еще несколько скриншотов 3д которые мы разработали для нашего симулятора.

Моделирование большинства деталей делалось по чертежам корабля :

В следующем посту расскажу еще что-нибудь.
Планируем конечно публикацию в Steam.

Оставляйте ваши комментарии и предложения, как только реализуем динамику, опубликуем на GitHub.

P.S.

У нас не хватает людей и если кто желает поучаствовать в проекте на свободных началах (денег нет, но интересное путешествие в мир космоса гарантируем) - пишите Soyuz.developer@gmail.com