Спутник как VPS: честная история про космический SSH, TinySat и TriSat

Космический аппарат не обязательно должен весить сотни килограммов и стоить как небольшой завод. Иногда достаточно платы размером с ладонь, Raspberry Pi, радиоканала и команды, которая готова несколько месяцев отлаживать термостабилизацию, прошивку и связь с орбиты.

В июле прошлого года я рассказывал, что мы готовим к запуску спутник с бортовым компьютером, к которому можно будет подключаться по SSH. Прямо как к нашему VPS, только он летит над головой со скоростью 7,8 км/с. Звучало как фантастика, но мы это сделали.

Сейчас расскажу, что из этого вышло на самом деле, почему мы ушли от предыдущего форм-фактора и что такое TriSat — платформа, которую мы выбрали для нашего космического эксперимента.

Почему мы ушли от TinySat

Те, кто читал наш старый пост про пикоспутник, помнят: мы начинали с формата TinySat — кубика 5×5×5 см весом до килограмма. NanoPi NEO на борту, простенький веб-сервер, радиолюбительский диапазон. Идея была красивая: сделать максимально дешёвый спутник, который можно собрать буквально в гараже.

Наш самый первый эксперимент со спутником как сервером был до смешного простым: мы передали на TinySat HTML-страницу. Звучит элементарно, но для космического радиоканала это уже нетривиально: нужно доставить данные через UHF и записать в память бортового компьютера. Эксперимент сработал — и мы поняли, что хотим большего. Не просто передавать файлы туда-сюда, а дать пользователю полноценный доступ к вычислительной системе аппарата.

Вот тут и вылезли ограничения TinySat, которые для этой задачи оказались критическими.

Первое — энергетика. TinySat, особенно в одноблочном исполнении, не тянул нормальную солнечную панель. Стандартные космические призмы 40×80 мм в кубик 5×5 просто не влезали. Мы, конечно, планировали двухблочный вариант — но всё равно энергобюджет оставался на грани. А нам нужно было, чтобы на борту работал полноценный Linux, пусть и на Raspberry Pi Zero, и чтобы он мог обслуживать входящие SSH-подключения. Это не «принял пакет — уснул». Это постоянная работа процессора с относительно высоким энергопотреблением.

Вот прямое сравнение TinySat (в лучшей, 2tU-конфигурации) и TriSat:

* Мы даём доступ к последовательному порту, на котором висит аппаратная консоль Linux. В tcp/ip мы заворачиваем уже на Земле.

Ключевое — последняя строка. У TinySat 4,8 кбит/с были сырой скоростью радиолинии в симплексном режиме, из них на пользовательские данные приходилась лишь доля, и никакой интерактивной сессии не было как класса. У TriSat эффективная скорость — около 1 кбит/с, но это полноценная SSH-консоль через весь стек GRID → MQTT → SSH. Медленно, но интерактивно.

Из опыта миссии NORBY, кстати, выяснилось: у TinySat на низкой орбите рабочими оказались только режимы LoRa со спред-фактором ≤11 и полосой >31,25 кГц, иначе доплер «съедал» узкополосные пакеты. То есть даже эти 4,8 кбит/с были не всегда.

Второе — платформа. TinySat базировался на платформе StratoSat от Геоскана. Это означало, что любая доработка или интеграция требовала согласования на уровне организаций — мы не контролировали ни деплоер, ни низкоуровневую архитектуру. Для экспериментов с HTML-страницей этого хватало. Для полноценного SSH-сервера с собственной логикой управления — уже нет. К тому же спутники в этой схеме запускались группой: просто «выплёвывались» на орбиту один за другим, без возможности гибко управлять порядком и временем отделения. Для сервера, который должен сразу начать работать и которому критичен первый контакт с наземной станцией, это тоже минус.

Третье — орбитальная жизнь. Все шесть TinySat'ов отделились от носителя StratoSat TK-1 11 июля 2023 года в одной солнечно-синхронной орбите высотой 556,7 км. Через 26 месяцев оба 2tU-аппарата всё ещё были на орбите (371,7 и 354,4 км по данным CelesTrak на март 2026-го), а 1tU-версии исчезли из каталога между декабрём 2024 и августом 2025 года. То есть даже внутри семейства TinySat двухблочная компоновка жила радикально дольше. TriSat проектно рассчитан на год — но это год активной работы с пользовательской нагрузкой, а не пассивного дрейфа.

К интеграционным граблям прототипа это тоже относилось: как показала сборка TinySat, ключевание межплатных разъёмов в таком компактном корпусе требует ювелирной точности, а каждый миллиметр по высоте компонентов (камера, хранилище, концевики) в сечении 48×48 мм — это постоянная борьба. TriSat с его архитектурой «спутник-плата» снимает эти ограничения: вместо плотного стека — раскрывающаяся конструкция с распределёнными компонентами.

Поэтому мы начали смотреть в сторону TriSat.

Почему мы выбрали TriSat и ОКБ Пятое Поколение

С командой ОКБ Пятое Поколение мы познакомились ещё на этапе TinySat. Они тогда выступали операторами наземного сегмента и управляли аппаратами через свои станции. Когда стало ясно, что старый форм-фактор нас ограничивает, они как раз допиливали TriSat.

Что нам в нём понравилось:

• Энергетика. Благодаря раскрывающейся солнечной панели TriSat в разложенном состоянии превращается в «спутник-плату» — единую конструкцию с большой площадью фотоэлементов. Средняя доступная мощность — 2 Вт, потребление бортовых систем — 0,73 Вт. Это сразу снимает вопрос «а потянет ли Raspberry Pi постоянную работу».

• Раздельное отделение. TriSat спроектирован вокруг CubeSat-совместимого контейнера. Спутники отделяются независимо, с контролируемым порядком. Никакого «выплюнули скопом и молятся».

• Собственная платформа «Клеон». В отличие от TinySat, где мы зависели от сторонней платформы, здесь весь CubeSat — разработка ОКБ Пятое Поколение. Платформа «Клеон», собственный деплоер, собственный подход к софту. TriSat унаследовал эту архитектуру: полноценная ОС реального времени Zephyr, нормальная радиосистема, резервирование прошивки и всё остальное. Когда всё своё, интеграция сводится к техническим вопросам, а не к межорганизационным согласованиям.

Ну и главное: ОКБ Пятое Поколение уже построило GRID — облачную сеть наземных станций. Для нас, как для хостинг-провайдера, это была родная модель: мы подключаемся к API, пробрасываем SSH, а всё остальное — радиопротоколы, наведение антенн, расчёт пролётов — делает GRID.

Оттолкнувшись от успеха HTML-эксперимента на TinySat, мы перенесли идею на TriSat и пошли дальше. Вместо передачи отдельного файла решили предоставить доступ к вычислительной системе самого аппарата. Так на борту появился Raspberry Pi Zero, а простая веб-страница превратилась в полноценный SSH-терминал.

Что на борту и как это работает

На борту связка из основного контроллера и Raspberry Pi Zero. Контроллер работает на Zephyr, общается с радиомодулем, следит за телеметрией, авторизует команды. Для сетевого взаимодействия используется протокол CSP — CubeSat Space Protocol. Через UART к контроллеру подключена Raspberry Pi с кастомной сборкой Linux — минимальное ядро, всё заточено под минимизацию потребления.

Контроллер принимает пакеты по радиосвязи, вычленяет из них пользовательские данные и пишет в консоль Raspberry Pi. Вывод консоли забирает, пакует и отправляет на Землю.

На Земле это проходит через несколько слоёв: GRID → MQTT → наш Telnet-сервер → SSH. Для вас это выглядит как обычная консоль. Вы заходите по SSH в указанный слот и можете делать всё, что позволяет песочница.

Кстати, о безопасности: совместно с «Лабораторией Касперского» мы адаптировали для спутника Kaspersky Endpoint Security for Linux — Space Edition. Это специализированная версия антивирусного решения, рассчитанная на скромные ресурсы Raspberry Pi Zero и жёсткие ограничения по энергопотреблению на орбите. Решение установлено на борт — космическому серверу тоже нужна защита, особенно когда к нему подключаются десятки пользователей.

Open source — не синоним «надёжно»

Мы не изобретали всё с нуля. Переход на открытые компоненты позволил использовать наработки сообщества, в первую очередь — Zephyr RTOS. Но open source не отменяет необходимости тщательной проверки. В Zephyr уже были драйверы для некоторых датчиков. Выглядело удобно: не нужно писать код с нуля. Однако затем выяснилось, что некоторые драйверы абсолютно не соответствуют требованиям космического проекта по качеству и надёжности. Ядро ОС написано очень качественно, а отдельные драйверы датчиков содержали ошибки или не учитывали особенности конкретного оборудования. Пришлось их переписать.

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

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

Функционал. Сразу занижаем ожидания

Вот теперь — честно. Без маркетинга.

Срок жизни аппарата оказался ниже, чем мы рассчитывали. Это не геостационарный спутник, который работает десять лет. Это низкоорбитальный аппарат без радиационно-стойкой электроники. Проектный срок TriSat — около года. Мы продолжаем работать с тем, что есть.

Функционал сильно ограничен. Вот что можно и что нельзя:

Что можно:

• Подключаться по SSH в выделенный слот (обычно 5–7 минут пролёта)

• Запускать свои скрипты и программы внутри песочницы (вы под обычным пользователем)

• Получать снимки с бортовой камеры (Sony IMX519, 16 МП)

• Работать с файлами

• Почитать статьи с Хабра, загруженные на борт, или найти в файловой системе дистрибутив DOOM. Запустить его, увы, не выйдет — не тот FPS на орбите, — но сам факт, что DOOM есть на спутнике, уже о многом говорит.

Что нельзя:

• Управлять самим спутником — ориентация, приёмник, передатчик не ваши

• Получать root-доступ — он наш, чтобы в случае чего откатить систему

• Стирать защищённые данные спутника

Канал — около 1 кбит/с, полудуплекс. Это полезная скорость после всех слоёв: радиопротокол, MQTT, авторизация, обёртка в SSH. Для сравнения: у TinySat сырая скорость радиолинии была 4,8 кбит/с — но это был симплексный канал безо всякого пользовательского стека, из которого на полезные данные приходилась лишь доля. А главное — интерактивной сессии там не было как класса. Здесь же вы получаете полноценную консоль, просто в режиме «телетайп с характером». Тяжёлые файлы придётся качать в несколько сеансов или сжимать на борту. Видео в реальном времени забываем сразу — разве что вы придумаете какую-то адскую схему сжатия.

У спутника есть маяк, периодически посылающий пакеты с базовой телеметрией: температура, напряжение, состояние заряда, качество связи, данные о солнечных панелях и параметры отдельных подсистем. Но это технический минимум для отслеживания здоровья аппарата, а не пользовательский интерфейс.

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

Инструкция: как попробовать

Сейчас спутник находится в активной фазе лётных испытаний — мы регулярно обновляем прошивки, отслеживаем телеметрию, корректируем работу бортовых систем. Демостенд на время основной части миссии занят под наши собственные задачи, и отдавать его в публичный доступ прямо сейчас мы не можем — он нужен для отладки.

Как только основная часть миссии завершится, мы откроем демостенд для всех желающих. Это полноценная физическая копия аппарата в лаборатории: та же ОС, та же камера (только показывает серверную, а не Землю), те же ограничения канала. Можно будет отработать команды и проверить скрипты перед реальным сеансом.

Если вы не успеете попасть на реальные сеансы связи в рамках текущей миссии — не переживайте. Демостенд останется доступным и после завершения активной фазы, так что возможность «пощупать» орбитальный Linux будет у всех.

Запись на сеансы — через Telegram-бота, которого найдёте на sat.ruvds.com. Бот напомнит о начале слота. Кстати, спутник есть в открытом каталоге под номером NORAD 67482 — можно в реальном времени отслеживать его положение на n2yo.com и прикидывать, когда он окажется над вами.

Внутри слота вы подключаетесь по SSH и делаете что хотите в рамках песочницы. Что можно сделать прямо в первом сеансе: uname -a покажет, что за машина на орбите; ls -la — содержимое файловой системы; прямо из консоли можно сделать снимок с бортовой камеры или замерить задержку сигнала Земля–спутник–Земля. Ссылки на снимки остаются доступны и после завершения сеанса. По окончании слота сеанс завершается, и управление переходит следующему пользователю — или антенна перестраивается на другой спутник.

Честно про результаты

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

Потом были баги на уровне отдельных микросхем. Одна из них при низкой температуре и определённом напряжении уходила в незапланированный режим. Мы воспроизводили ошибку в самодельной термокамере с сухим льдом — охлаждали до −70 °C и смотрели, что творится с процессором. Нашли, поправили прошивку, полетели дальше.

Прошивку мы обновляли раз восемь за время работы. На аппарате всегда две копии — основная и резервная. Перед переключением проверяется целостность, потом запуск, потом подтверждение работоспособности. Если новая версия не взлетела — откат на резервную. Критически важное ядро системы — загрузчик, механизм переключения прошивок, watchdog, базовое управление питанием — обновляют особенно осторожно, только если совсем припрёт. Для космического аппарата это не роскошь, а базовый механизм выживания.

Для тестирования используется не цифровой двойник, а физический «тройник» — аппарат на той же аппаратной ревизии, что и лётный экземпляр. Его собирают и не меняют после финальной сборки. К нему вообще нельзя прикасаться просто так: нельзя припаять новый провод или заменить микросхему — он должен оставаться точной копией спутника на орбите. На нём проверяют прошивки, воспроизводят ошибки и при необходимости гоняют в температурных испытаниях.

Борткомпьютер стартовал на этот раз нормально — в отличие от предыдущей миссии, где мы игрались только с контроллером. SSH работает. Камерой пользоваться можно. Да, медленно, да, с перебоями, но это настоящий Linux-сервер в космосе.

Первые снимки от участников проекта уже можно полистать в галерее на sat.ruvds.com/console.

Как организуют попутный запуск

Небольшие спутники редко запускают отдельной ракетой — слишком дорого. Обычно их отправляют, когда у основной миссии есть свободная грузоподъёмность. Механика такая: ракета выводит крупный целевой аппарат, а свободный запас массы оператор продаёт тем, кто хочет запустить свои малые спутники. TriSat шёл именно так — попутной нагрузкой.

У этого подхода есть важное ограничение: команда малого спутника не контролирует дату запуска. Если основную миссию переносят, переносится и запуск всех попутных аппаратов. Появляется соблазн использовать дополнительное время для улучшений — но это рискованно: запуск могут вернуть раньше, и все доработки с полным циклом испытаний провести не успеешь.

Что дальше

Мы не строим иллюзий: этот аппарат — эксперимент. Он ограничен и по времени жизни, и по функционалу. Но он летает, он доступен для подключения, и на нём можно запускать код.

Следующий запуск TriSat планируется после 2027 года, точная дата будет зависеть от попутных миссий.

Из конкретных направлений на будущее: собственный GPS/ГЛОНАСС-модуль, датчики радиации, солнечные сенсоры, экспериментальные радиомодули. Возможны эксперименты со звёздной ориентацией — не обязательно полноценной системой, но интересной как учебный и исследовательский проект. Raspberry Pi на борту мог бы, например, анализировать снимки и передавать только метаданные: есть ли облака, как меняется освещённость, какие участки пригодны для обработки.

Отдельная тема — подключение радиолюбительских станций. Небольшая SDR-система, установленная в университете или дома, могла бы стать частью общей сети GRID. Это и распределение нагрузки между станциями, и вовлечение сообщества.

Ну и ключевое — открытие формата TriSat: публикация внешних интерфейсов, конструкторской документации, возможно, части ПО. Чтобы любой разработчик мог создавать собственные аппараты под этот стандарт, как это произошло с CubeSat.

Отдельная история — мы адаптировали протокол Console Gate, обкатанный на спутнике, для работы с возвращаемой стратосферной платформой. 8 августа с борта атомного ледокола над Северным полюсом запустили радиозонд, а 11 августа там же запустили саму платформу в рамках экспедиции «Ледокол знаний» — она поднялась на высоту более 15 000 метров и, преодолев свыше 100 километров, вернулась в зону старта. Та же связка SSH поверх MQTT, те же принципы — только носитель не орбитальный, а стратосферный. Событие само по себе знаменательное: впервые в истории российским учёным удалось произвести успешный арктический запуск возвратной стратосферной платформы. Но это, как говорится, совсем другая история.

А пока — если хотите попробовать орбитальный SSH своими руками, сделать фотографию, поработать с консолью, посмотреть список самых популярных публикаций на Хабре — бронируйте слот на сайте sat.ruvds.com. И следите за новостями: как только основная часть миссии завершится, мы откроем демостенд для всех.

© 2026 ООО «МТ ФИНАНС»