Мы приносим извинения перед теми, кому не удалось получить доступ к спутнику в этот раз.
Вне зависимости от решения RuVDS повторить эксперимент, мы хотим это сделать, и постараемся учесть весь полученный опыт.
Чтобы не было недопонимания, изначально спутник для экспериментов предоставлялся As Is (мы даём аппарат на орбите с RPi и канал связи до него, всё взаимодействие и разработка остального ПО - на стороне заказчика) и ровно в таких же условиях было запущено 3 из 4 спутников для остальных заказчиков. Один аппарат мы оставили для собственных экспериментов. И в рамках этого эксперимента мы разработали “Console Gate” как более простую обёртку над всеми протоколами взаимодействия с космическим аппаратом. И, чтобы устранить несколько фактологических ошибок и непонимания как это работает, дам немного комментариев.
общаешься со спутником по SSH, оно оборачивается в Telnet и уходит на борт
На спутнике ни SSH, ни Telnet нет. Там нет сетевой подсистемы в ядре. И в радиоканале оно тоже не ходит. Об этом подробнее чуть ниже…
Сначала протокол Console Gate. ОКБ планировали реализовать его как API: подключитесь и работайте. Мы тоже так планировали. Из-за того, что запуск оказался раньше запланированного срока, оказалось, что рабочего API как готового продукта ещё нет, а есть только низкоуровневый стек протоколов. Наша задача внезапно превратилась в «дописать своё и совместно с ОКБ доработать Console Gate».
GRID даёт API и MQTT для связи с космосом. Всё очень просто и тривиально - MQTT для реалтайм соединения, API для работы с сессиями, кадрами, спутниками и проч. Console Gate - это та самая прослойка, которая оборачивает MQTT-пакеты в TCP/IP поток на земле. И на земле это всё ещё не Telnet и не SSH. Это Raw TCP/IP сокет. Эта прослойка писалась по собственной инициативе для ребят, чтобы упростить им жизнь и как раз не погружать в протоколы, пакетирование, команды управления и проч. Благодаря этой прослойке для пользователя RPi всё сводится к “подключаешься к сокету и всё что ты отправляешь - улетает в космос, а всё что прилетает оттуда - ты принимаешь байтами обратно”. Просто до безумия, только учитывай, что радиоканал не гарантирует доставку, и у тебя по сути UDP связь. Выстраивай внутри такой протокол, который будет убеждаться в доставке, и получать подтверждения. Будь готов к тому, что ты повторишь пакет, а аппарат услышит его второй раз. В общем так, будто бы работаешь по UDP. И не забываем про идемпотентность.
Он там проходит, условно говоря, окнами по 10 минут — навелись, он вошёл в узкий луч, сначала много помех, потом нормально, потом снова много помех, потом он выходит из луча. Чтобы поймать ещё раз, нужно наводиться заново, и, возможно, уже через часы или дни в зависимости от ситуации.
Связь со спутником изнутри выглядит совсем не так. Для каждого аппарата GRID рассчитывает баллистику и вектора наведения антенны. Антенна постоянно “следит” за аппаратом и направляется на него. Как только аппарат вылетает из-за горизонта и появляется в зоне прямой видимости - GRID уже начинает “вести” аппарат. При низком возвышении имеем самую большую дальность до аппарата (тысячи километров) и, соответственно, максимальные потери радиосигнала. Чем ближе аппарат - тем лучше сигнал/шум и качество связи. “Узкий луч” антенны постоянно трэкает аппарат, пока он пролетает над станцией.
SSH заканчивается на Земле, на стороне грида, дальше команда оборачивается в Telnet и уходит на борт. Большими ключами над горизонтом никто не обменивается.
Идеология GRID - не вмешиваться в данные. GRID - это мост из одной среды данных (радиоэфир) в другую среду (MQTT).
Console Gate в свою очередь прослойка между протоколами (MQTT в TCP-сокет). И даже он не оперирует протоколом Telnet и тем более SSH. Оно и не нужно - на аппарате ведь данные мы берём из последовательного порта RPi, и TCP-сокет хорошо подходит для работы на земле.
И килобит в секунду — это про радио. То, что видит наш софт, совсем другое: поверх радио сидит MQTT грида со своими контрольными суммами, поверх него наша обвязка, и всё это по очереди, туда-сюда. Очень много уходит на повторы и контроль ошибок при помехах.
Нет, в радио MQTT и не пахнет. В радио есть своя обвязка, но очень экономичная - уже затрагивал в другой статье, Cubsat Space Protocol. Небольшой оверхед при инкапсуляции в радиоканал есть, но он очень небольшой (6 байт заголовок, 4 байта контроль целостности пакета и т.д.). Разработчики понимают возможности радиолинии (командная линия около 1 кбита/с), и стараются использовать её максимально эффективно - ценят каждый переданный байт.
Ну, для начала rm -rf /home/pi/tmp/cache может стать rm -rf /home/pi. Привет. Какой-нибудь chmod -R 755 /var/www/site может стать chmod -R 755. Ладно, это не так страшно. А shutdown -c, ставший shutdown, — уже не так весело. kill 12345 может приехать как kill 123.
Выше я уже писал про идемпотентность. Когда не понимаешь особенности линии связи и не учитываешь, что ты работаешь в UDP канале, то такое, конечно, может удивлять. А наши разработчики когда работали с Трисатами придерживались простых правил:
Генерировать исходящие данные так, чтобы они входили по длине в один пакет (255 байт). Ибо пакет - это простая неделимая сущность в радиосвязи. Он либо принят, либо нет.
Убеждаться в том, что твоя команда в пакете была принята и обработана. То есть повторять команду, пока не получишь ответ.
Реализовывать команды так, чтобы они были идемпотентны - то есть при повторном выполнении команды результат должен быть тот же. Эти 3 правила всё упрощают и делают работу значительно надёжнее, даже в таком непростом канале как радиосвязь. Мы обновили прошивку на аппаратах более 7 раз. Выкачали фотографии в достаточно неплохо качестве (они были в статьях и на превьюшках). Суммарно прогрузили десятки мегабайт данных даже по такой не быстрой линии.
Ад в канале выглядел так: набираете стандартную команду ls -la. Отобразить каталог. До спутника могло долететь ls. Могло долететь только -la. Могло не долететь ничего. Назад мог пойти список каталога и зависнуть на середине. Мог прилететь кусок: только концовка, потому что пакет с началом куда-то делся. Или начало и конец без середины.
3 правила выше. 3 правила и никакого ада не было бы.
В первую очередь из-за несоблюдения очерёдности пакетов.
Пакеты в GRID всегда приходят в том порядке как были получены. Пакеты могут не приниматься, но ни в коем случае не перепутаться. Ядро GRID основано на одном из популярных брокеров сообщений. GRID сам не маршрутизирует данные и не вмешивается в них.
Ответ, если что, простой: оверхед не наш. Наш протокол сидит слишком высоко. Под ним грид гоняет данные по MQTT и считает свои контрольки, под MQTT — радио. Где именно по дороге что-то теряется, мы так до конца и не поняли, но эффект вы уже видели выше.
Если убрать эмоции, то обмен с Трисатами устроен совсем не так. Полное непонимание где какие протоколы. MQTT в радио конечно же нет. При озвученном уровне понимания сложно выстроить надёжную и эффективную связь.
Дальше скрипт ждёт, когда загрузится Linux и появится приглашение логина. Приглашения нет — отправляем Enter. Ждём. Опять нет — ещё Enter, примерно раз в три-пять секунд, по совету коллег. В хорошем случае приходит login:, мы пишем имя пользователя, борт в лучшем случае спрашивает пароль, мы вводим пароль и ждём входа.
Идемпотентность. И 3 простых правила выше. Задача уровня студента, имхо.
Скачивает всё это File Downloader, скрипт со стороны грида, который тянет файл по байтам в хранилище.
GRID ничего никуда сам не тянет. Отправляет пакет с одной стороны, в другую. File downloader - это изобретение не ОКБ.
Ну и пришлось искать, как рассчитывать TLE самим: экстраполировать, подбирать баллистические модели, с полным геморроем.
Команде GRID и моим коллегам из ОКБ5 пришлось освоить много новых навыков и умений: и триангуляцию, и допплерометрию, и различные баллистические модели. Очень круто, когда ты не имея на борту объективных средств геолокации, можешь “вслепую” определить его местоположение и просчитать орбитальные параметры. Ребята из RuVDS хоть за нас и болели, но в этом помочь не смогли. И здорово, что они понимают сложности этого процесса.
Когда с NORAD более-менее разобрались и начали тестироваться, оказалось, что спутники уже стремительно сходят с орбиты и жить им осталось недели две.
К сожалению, технический образец на Земле не был использован в полной мере. Да.
Дублёров у нас было два, с той же прошивкой.
Очень здорово, что мои коллеги из ОКБ5 нашли возможность и согласились отложить все свои эксперименты и выделить другой (свой) аппарат, чтобы RuVDS и пользователи успели хоть как-то воспользоваться этой возможностью и прикоснуться к космосу. Изначально под эксперименты RuVDS предназначался один аппарат.
В любом случае, я считаю это очень классным экспериментом. Без коллег из RuVDS врядли бы мы решили запустить RPi в космос, тем более на таком маленьком аппарате. За время разработки проекта пришлось решить не мало интересных задач. И судя, по комментариям, многим даже в таком виде результат понравился. Уверен, в следующий раз всё выйдет ещё лучше.
Если коротко - мы в ОКБ в общем случае стараемся контрибьютить в те опенсурсные проекты, которые используем. Очевидно, что это полезно и нам (более простые апдейты, меньше патчей и т.д.), и это справедливо по отношению к используемым проектам.
Но на практике это получается не всегда - иногда наши изменения слишком специфичны и не нужны широкой публике, иногда проекты не слишком активны и не рвутся смотреть и обсуждать необходимые нам изменения.
Те, кто пробовал проносить свои изменения в какие-то крупные проекты - поймут сложности. Эта активность может требовать больших усилий.
Трисаты не гоняют IP по радиоканалу, TCP/IP появляется уже на земле... в радио - CSP (Cubsat Space Protocol). 6 байт заголовок, адресация 14 бит. Есть RDP (аналог TCP/IP), поддержка разных сред передачи и т.д. Можно гибко его настраивать под себя и не выдумывать велосипед... В узких кругах CSP довольно популярная вещь.
Мы приносим извинения перед теми, кому не удалось получить доступ к спутнику в этот раз.
Вне зависимости от решения RuVDS повторить эксперимент, мы хотим это сделать, и постараемся учесть весь полученный опыт.
Чтобы не было недопонимания, изначально спутник для экспериментов предоставлялся As Is (мы даём аппарат на орбите с RPi и канал связи до него, всё взаимодействие и разработка остального ПО - на стороне заказчика) и ровно в таких же условиях было запущено 3 из 4 спутников для остальных заказчиков. Один аппарат мы оставили для собственных экспериментов. И в рамках этого эксперимента мы разработали “Console Gate” как более простую обёртку над всеми протоколами взаимодействия с космическим аппаратом. И, чтобы устранить несколько фактологических ошибок и непонимания как это работает, дам немного комментариев.
На спутнике ни SSH, ни Telnet нет. Там нет сетевой подсистемы в ядре. И в радиоканале оно тоже не ходит. Об этом подробнее чуть ниже…
GRID даёт API и MQTT для связи с космосом. Всё очень просто и тривиально - MQTT для реалтайм соединения, API для работы с сессиями, кадрами, спутниками и проч. Console Gate - это та самая прослойка, которая оборачивает MQTT-пакеты в TCP/IP поток на земле. И на земле это всё ещё не Telnet и не SSH. Это Raw TCP/IP сокет. Эта прослойка писалась по собственной инициативе для ребят, чтобы упростить им жизнь и как раз не погружать в протоколы, пакетирование, команды управления и проч. Благодаря этой прослойке для пользователя RPi всё сводится к “подключаешься к сокету и всё что ты отправляешь - улетает в космос, а всё что прилетает оттуда - ты принимаешь байтами обратно”. Просто до безумия, только учитывай, что радиоканал не гарантирует доставку, и у тебя по сути UDP связь. Выстраивай внутри такой протокол, который будет убеждаться в доставке, и получать подтверждения. Будь готов к тому, что ты повторишь пакет, а аппарат услышит его второй раз. В общем так, будто бы работаешь по UDP. И не забываем про идемпотентность.
Связь со спутником изнутри выглядит совсем не так. Для каждого аппарата GRID рассчитывает баллистику и вектора наведения антенны. Антенна постоянно “следит” за аппаратом и направляется на него. Как только аппарат вылетает из-за горизонта и появляется в зоне прямой видимости - GRID уже начинает “вести” аппарат. При низком возвышении имеем самую большую дальность до аппарата (тысячи километров) и, соответственно, максимальные потери радиосигнала. Чем ближе аппарат - тем лучше сигнал/шум и качество связи. “Узкий луч” антенны постоянно трэкает аппарат, пока он пролетает над станцией.
Идеология GRID - не вмешиваться в данные. GRID - это мост из одной среды данных (радиоэфир) в другую среду (MQTT).
Console Gate в свою очередь прослойка между протоколами (MQTT в TCP-сокет). И даже он не оперирует протоколом Telnet и тем более SSH. Оно и не нужно - на аппарате ведь данные мы берём из последовательного порта RPi, и TCP-сокет хорошо подходит для работы на земле.
Нет, в радио MQTT и не пахнет. В радио есть своя обвязка, но очень экономичная - уже затрагивал в другой статье, Cubsat Space Protocol. Небольшой оверхед при инкапсуляции в радиоканал есть, но он очень небольшой (6 байт заголовок, 4 байта контроль целостности пакета и т.д.). Разработчики понимают возможности радиолинии (командная линия около 1 кбита/с), и стараются использовать её максимально эффективно - ценят каждый переданный байт.
Выше я уже писал про идемпотентность. Когда не понимаешь особенности линии связи и не учитываешь, что ты работаешь в UDP канале, то такое, конечно, может удивлять. А наши разработчики когда работали с Трисатами придерживались простых правил:
Генерировать исходящие данные так, чтобы они входили по длине в один пакет (255 байт). Ибо пакет - это простая неделимая сущность в радиосвязи. Он либо принят, либо нет.
Убеждаться в том, что твоя команда в пакете была принята и обработана. То есть повторять команду, пока не получишь ответ.
Реализовывать команды так, чтобы они были идемпотентны - то есть при повторном выполнении команды результат должен быть тот же. Эти 3 правила всё упрощают и делают работу значительно надёжнее, даже в таком непростом канале как радиосвязь. Мы обновили прошивку на аппаратах более 7 раз. Выкачали фотографии в достаточно неплохо качестве (они были в статьях и на превьюшках). Суммарно прогрузили десятки мегабайт данных даже по такой не быстрой линии.
3 правила выше. 3 правила и никакого ада не было бы.
Пакеты в GRID всегда приходят в том порядке как были получены. Пакеты могут не приниматься, но ни в коем случае не перепутаться. Ядро GRID основано на одном из популярных брокеров сообщений. GRID сам не маршрутизирует данные и не вмешивается в них.
Если убрать эмоции, то обмен с Трисатами устроен совсем не так. Полное непонимание где какие протоколы. MQTT в радио конечно же нет. При озвученном уровне понимания сложно выстроить надёжную и эффективную связь.
Идемпотентность. И 3 простых правила выше. Задача уровня студента, имхо.
GRID ничего никуда сам не тянет. Отправляет пакет с одной стороны, в другую. File downloader - это изобретение не ОКБ.
Команде GRID и моим коллегам из ОКБ5 пришлось освоить много новых навыков и умений: и триангуляцию, и допплерометрию, и различные баллистические модели. Очень круто, когда ты не имея на борту объективных средств геолокации, можешь “вслепую” определить его местоположение и просчитать орбитальные параметры. Ребята из RuVDS хоть за нас и болели, но в этом помочь не смогли. И здорово, что они понимают сложности этого процесса.
К сожалению, технический образец на Земле не был использован в полной мере. Да.
Очень здорово, что мои коллеги из ОКБ5 нашли возможность и согласились отложить все свои эксперименты и выделить другой (свой) аппарат, чтобы RuVDS и пользователи успели хоть как-то воспользоваться этой возможностью и прикоснуться к космосу. Изначально под эксперименты RuVDS предназначался один аппарат.
В любом случае, я считаю это очень классным экспериментом. Без коллег из RuVDS врядли бы мы решили запустить RPi в космос, тем более на таком маленьком аппарате. За время разработки проекта пришлось решить не мало интересных задач. И судя, по комментариям, многим даже в таком виде результат понравился. Уверен, в следующий раз всё выйдет ещё лучше.
RuVDS спасибо Вам за такие смелые начинания.
Если коротко - мы в ОКБ в общем случае стараемся контрибьютить в те опенсурсные проекты, которые используем. Очевидно, что это полезно и нам (более простые апдейты, меньше патчей и т.д.), и это справедливо по отношению к используемым проектам.
Но на практике это получается не всегда - иногда наши изменения слишком специфичны и не нужны широкой публике, иногда проекты не слишком активны и не рвутся смотреть и обсуждать необходимые нам изменения.
Те, кто пробовал проносить свои изменения в какие-то крупные проекты - поймут сложности. Эта активность может требовать больших усилий.
Трисаты не гоняют IP по радиоканалу, TCP/IP появляется уже на земле... в радио - CSP (Cubsat Space Protocol). 6 байт заголовок, адресация 14 бит.
Есть RDP (аналог TCP/IP), поддержка разных сред передачи и т.д. Можно гибко его настраивать под себя и не выдумывать велосипед... В узких кругах CSP довольно популярная вещь.
Да, там есть станция сети GRID.