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

Председатель Шенчжи Ян.

image

В сознании каждого человека есть одна простая мысль: космические технологии — это сложно. На самом деле это не так. Не все технологии, применимые в космической отрасли — это Rocket science. И последние успехи в космонавтике, ренессанс космической тематики сподвигли меня на поиск проблемных областей, которые простой Enterprise Java разработчик может улучшить.

Предисловие


Самый простой способ — это пойти на сайт любой компании, работающей в космической отрасли, и поискать вакансии. Несмотря на то, что SpaceX ищет программистов, мне было отказано на этапе резюме. Видимо, государственные контракты от NASA не позволяют им нанимать людей из других стран. Видимо, по этой же причине NASA даже не ответили на моё резюме. JAXA набирает не-программистов и тех, у кого японский не ниже уровня jlpt2.

С небольшими частными компаниями должно было бы быть значительно лучше. Но Planetary Resources отказали на этапе резюме. Видимо, слишком маленькие, чтобы держать под рукой Enterprise Java разработчика. Planet попросили написать программу на Си. Я конечно вспомнил синтаксис и смог, но после пары интервью они отказали. Видимо, слишком маленькая компания, у которой нет офиса в России, и переезд в другую страну они не потянут.

Ну и, наконец, дефолт сити. Роскосмос — ни списка вакансий, ни требований.

Станции наблюдения за спутниками


Но мне повезло, и я случайно обнаружил проект Satnogs. Это проект по созданию любительских станций наблюдения за спутниками по всему миру. Можно самому распечатать на 3д принтере части станции и по инструкции собрать. Также у них есть центральный сервер, который рассылает на станции запросы для наблюдения за пролетающими спутниками и собирает данные со всего мира: https://network.satnogs.org.

Для меня, как новичка в этой области, было не совсем понятно кому и зачем это нужно. Однако, повертевшись на форумах и в mailing листах cubesat, я стал немного представлять проблематику.

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

И тут на помощь должны прийти интернет и глобальная сеть наблюдения.

Телеметрия


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

Поскольку я прежде всего программист, меня заинтересовала именно программная часть, а в особенности digital signal processing. Как из .wav файла можно получить данные. Но прежде чем расчехлять прибор и начать кодить необходимо проанализировать существующие решения. Если вкратце, то эта область застряла где-то в 60х. Энтузиасты пересылают данные в виде скриншотов к windows программам.



Хотелось бы что-то более современное. Например, облачный сервис, который на вход получает .wav файл, а на выходе возвращает json. Почему именно такая архитектура?

  1. для того, чтобы отправить данные и получить результат не нужно специального ПО. Достаточно лишь curl, который есть во всех linux дистрибутивах;
  2. результат в текстовом формате упрощает разработку и интеграцию;
  3. микросервисная архитектура. Такой сервис будет отлично встраивается в другие более сложные системы.

Следующим этапом был выбор технологий. Поскольку специализированные железки для декодирования радио сигналов ну совсем никак не поставить в обычные датацентры, то необходимо программное декодирование. Тут все просто: gnuradio. Это стандарт де-факто для программного декодирования — достаточно мощный и бесплатный инструмент, который поддерживает множество режимов и способов работы. Как раз то, что нужно для того, чтобы работать с зоопарком различных способов кодирования сигнала. Daniel Estevez написал замечательные скрипты по декодированию сигналов различных спутников и приложил рабочие примеры.


Казалось бы вот оно, счастье. Однако, и тут есть несколько ложек дегтя:

  1. GPLv2. Это не позволит вам писать коммерческий софт по декодированию сигналов. И уж точно не подходит для облачного сервиса — кто-то должен платить за хостинг.
  2. Безумная связка C/C++/Python/Swig. Если вкратце, то в gnuradio есть понятие блока. Это такой атомарный преобразователь сигнала. Когда сигнал декодируется данные проходят через множества, связанных между собой, блоков, и на выходе из последнего блока получается результат. Так вот, блоки можно писать на С++ и python. А раз можно писать, значит кто-то обязательно напишет. В итоге, часть блоков написана на Python 2, часть на Python 3, часть на C++, который иногда не компилируется и не всегда устанавливается, и все это связано через SWIG.

Переписывать уже рабочий код, который используется уже много лет и знаком многим энтузиастам, задача неблагодарная. Но помучившись с виртуальными машинами и продравшись сквозь десяток ошибок компиляции, я решил пойти на невозможное: переписать ключевые блоки на Java. Разумеется бездумно переписывать все подряд блоки не имеет смысла, поэтому я решил проверить концепцию, переписав только блоки, нужные для декодирования aausat-4. В итоге у меня получилось сделать бинарно совместимые с gnuradio блоки и декодировать сигнал.

Поскольку концепция оказалась успешной, я решил запустить облачный сервис, который по сути предоставляет REST интерфейс к библиотеке jradio. Следующим этапом я планирую подключить его к satnogs для декодирования данных.

Выводы


Даже если вы Enterprise Java разработчик, вы можете помочь Элону. Возможно, по прошествии времени Вы сможете говорить внукам что шаттл, который летает между Марсом и Землей, каждую секунду выполняет Ваш код. Дерзайте!
Поделиться с друзьями
-->

Комментарии (24)


  1. Imbecile
    08.04.2017 14:05

    Не удержался
    image


    1. dernasherbrezon
      08.04.2017 15:14
      +2

      В этом то и вся статья. Нет стандартного приложения для декодирования сигналов. Каждый университет пишет свои gnu radio блоки и как то слепляет вместе. А уж запускать облачный сервис для постоянного декодирования потока и подавно никто не пробовал. Блеск и нищета open source.


      1. Valerij56
        08.04.2017 19:51
        +1

        Но если кто-то сделает такое приложение, то оно может довольно быстро стать де-факто стандартным для самых разных владельцев и конструкторов спутников.

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


        1. dernasherbrezon
          08.04.2017 21:03
          +2

          Да, идея витает в воздухе. Есть например коммерческий: https://leaf.space


  1. Mingun
    08.04.2017 14:22

    Немного не понял — причем тут .wav файл? И еще — сайт с описанием API выглядит очень круто. Это какой-то сторонний сервис такое генерит (ну, типа readthedocs.org, docs.rs и прочее), или сами под свою задачу делали?


    1. dernasherbrezon
      08.04.2017 15:01

      • Данные с rtf-sdr по непонятным мне причинам обычно передают в формате .wav. Возможно это самый удобный способ передавать звуки и данные, аналоговые и цифровые.
      • Этот API генерирует swagger


      1. Rumlin
        08.04.2017 21:24
        +1

        Скорее это исторический вопрос — выход радиоприемника подключался к линейному входу звуковой карты компьютера. Поэтому на выходе или аудиозапись, либо звук декодируется на лету.
        Программ не так много, многие достаточно древние. Желающих переписать под SDR немного. Поэтому принципиально ничего не меняется — вместо рации используется SDR, звук с которого поступает на обработку в «древнюю программу». Вот пример https://ukhas.org.uk/projects:dl-fldigi

        Dl Fldigi is an adapted version of the excellent free FLdigi soundcard decoding software. It takes the audio from your radio, decodes the balloon's signal, and then sends the telemetry it's found over the internet to a server running habitat, which plots the payloads position on to the SpaceNear map.


        Хотя сейчас для raspberry pi для некоторых радиосервисов появились варианты обрабатывать в «цифре», минуя преобразований в звук.


    1. alcheorg
      08.04.2017 16:53

      На страничке с API ссылка на http://swagger.io/


  1. isden
    08.04.2017 15:01
    +3

    > Даже если вы Enterprise Java разработчик, вы можете помочь Элону.

    To conform to U.S. Government space technology export regulations, applicant must be a U.S. citizen, lawful permanent resident of the U.S., protected individual as defined by 8 U.S.C. 1324b(a)(3), or eligible to obtain the required authorizations from the U.S. Department of State.


    1. Valerij56
      08.04.2017 16:42
      +3

      Да, устроиться на работу в SpaceX вы сможете только на этих условиях.

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


  1. Ciiol
    08.04.2017 15:06

    GPLv2. Это не позволит вам писать коммерческий софт по декодированию сигналов. И уж точно не подходит для облачного сервиса — кто-то должен платить за хостинг.

    А каким образом GNU GPLv2 ограничивает создателей облачного сервиса?


    1. dernasherbrezon
      08.04.2017 15:10
      +1

      Меня, как параноика GPLv2 беспокоит :) Если придется выдать исходники облачного сервиса, то его ценность резко упадет. Каждый может поднять свой собственный, у каждого будет свой собственный немного улучшенный API не совпадающий с другими.


      1. Ciiol
        08.04.2017 15:34

        Так ведь эта лицензия накладывает ограничения только на распространение самого приложения. Если вы не будете делать такие частные сервисы «под ключ», то это вас не коснется.

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


      1. selivanov_pavel
        08.04.2017 15:59

        Параноика должно беспокоить как раз отсутствие возможности получить исходники облачного сервиса. Я правильно понимаю, что вы хотите затруднить создание альтернатив, то есть vendor lock-in? ИМХО это как-то совсем нелогично для некоммерческого сервиса, созданного с целью помочь освоению космоса.


        Кстати, GPL выдавать исходники облачного сервиса не требует, пока вы не начнёте эту программу продавать или распространять сторонним лицам. Выдавать исходники сетевых сервисов требует AGPL.


        1. dernasherbrezon
          08.04.2017 16:12
          +1

          vendor lock-in случается только тогда, когда вендоров больше 1.

          С закрытыми исходниками есть выбор: можно делать коммерческий сервис, а можно и не делать.


          1. selivanov_pavel
            08.04.2017 16:22

            А, ну если в дальнейшем возможен перевод сервиса в платный, то не использовать GPL логично.


          1. wych-elm
            09.04.2017 15:11
            +1

            Это расхожее заблуждение. Почему коммерческие означает у вас закрытый исходный код? Продавать можно и с открытым. Ценность программный продукт при этом никакой не теряет. Слова про «каждый сможет», это как? Чтобы воспользоваться исходным кодом нужно иметь определенную квалификацию и долгое время разбираться в самом исходном коде и документации чтобы понять как он работает, иногда это время и деньги большие нежели создать собственное с нуля.
            GPL никак не запрещает вам получать коммерческую выгоду. Она только обязывает вас предоставлять исходный код и право его использовать и менять (и те же условия распространяются и на тех кто пользуется этим правом).
            Ну и последнее, делать закрытой программу на Java, скажем так «немного затруднительно».


  1. Valerij56
    08.04.2017 16:19
    +2

    Несмотря на то, что SpaceX ищет программистов, мне было отказано на этапе резюме. Видимо, государственные контракты от NASA не позволяют им нанимать людей из других стран.
    Любая компания, связанная с ракетными запусками в любой развитой западной стране работает под ограничениями Договора о нераспространении ракетных технологий, плюс, возможны национальные ограничения. У SpaceX были проблемы, когда в Мак Грегоре, на испытаниях Кузнечика, в команде нанятых операторов оказались двое русских. Для работы в SpaceX нужно иметь, как минимум, «зеленую карту».


    1. alexeypa
      09.04.2017 07:09

      > У SpaceX были проблемы, когда в Мак Грегоре, на испытаниях Кузнечика, в команде нанятых операторов оказались двое русских.

      Интересно. А ссылка есть на эту историю? Было бы интересно почитать.


      1. Valerij56
        09.04.2017 13:05

        Увы, когда читал ссылку не запоминал. Насколько помню, короткое сообщение об этом было года два назад в _http://www.parabolicarc.com/


  1. Psychopompe
    08.04.2017 22:04

    А что за задание на С было?


    1. dernasherbrezon
      09.04.2017 16:46

      Это было давно, года 2 назад, поэтому деталей не помню. Какой то простой алгоритм на массивах. Я еще долго искал аргументы к memset


  1. Bel_Riose
    08.04.2017 22:06

    Эпиграф из SMAC что ли?


    1. dernasherbrezon
      08.04.2017 22:07

      Да