Цифровой журнал «Компьютерра» № 88 полностью

- Продолжение. Первую часть статьи можно прочитать здесь.

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

Во-первых, это собственный уровень аппаратной абстракции, названный PilotOS, или, сокращённо, PiOS. Он находится между конкретным «железом» и остальной логикой системы. Используя его и переносимый исходный код проекта, стало возможным не только легко адаптировать проект под разные типы процессоров, но даже собрать версию для персонального компьютера. Так получились HiTL – Hardware in The Loop и SiTL – Software in The Loop.

Говоря простыми словами, с помощью специального модуля GCS, умеющего общаться с программными симуляторами полёта, например игровым симулятором IL2, система может получать данные о самолёте не от платы INS с реальными датчиками, а от симулятора, работающего на том же компьютере, что и GCS, или на соседнем, подключённом по локальной сети или даже через интернет. Далее GCS направляет эти данные по каналу телеметрии в плату OP Pro, которая выполняет функции навигации и выдаёт управляющие воздействия не только на свои выходы, но и обратно в GCS. Последняя передает их в симулятор, который ведёт самолёт под управлением реального «железа» проекта OpenPilot. Это и есть HiTL – реальная электроника управляет симулированным самолётом.

Но это ещё не всё. Скомпилировав тот же программный код с заменой одного только уровня PiOS, можно получить программу стабилизации, работающую на том же персональном компьютере. Теперь вся система вообще становится виртуальной: симулятор самолёта, GCS и код системы навигации работают на PC, не требуя специальных плат. Это даёт возможность отлаживать любые алгоритмы навигации вообще без железа и без рисков разбить модель на ранней стадии отладки. Такой уникальной возможностью не может похвастаться ни один из существующих на сегодня любительских проектов.

Второе принципиальное архитектурное решение — это протокол обмена данными, названный UAVTalk. Все данные в системе, будь то настройки или данные управления и состояния, представлены в виде так называемых uavobjects – объектов, знающих о себе всё: тип данных, количество элементов, значения по умолчанию, допустимый диапазон значений и так далее. Весь обмен информацией как внутри системы, так и между моделью и землёй, построен на основе этих объектов.

Что это даёт? Во-первых, каждый объект описан в одном месте. Изменение объекта приводит к изменению во всех частях системы, что устраняет возможность ошибок по забывчивости. Во-вторых, все эти объекты автоматически становятся доступны GCS для просмотра или изменения. В-третьих, они сами докладывают о себе в двух направлениях по каналам телеметрии с заданной периодичностью или по факту своего изменения. В-четвёртых, благодаря этому протоколу стала возможной реализация подключения к симуляторам или управления с земли с помощью компьютера: достаточно установить для объекта запрет обновления со стороны платы сенсоров, и мы можем заполнять эти значения данными из симулятора. Остальная часть системы даже не узнает, что источник данных изменился.

И, наконец, UAVTalk — открытый протокол. Его реализация существует уже на языках программирования C, C++, Python, Java, есть версия для пакета Matlab. Достаточно реализовать формально описанный протокол на новом устройстве, и появляется возможность взаимодействовать как с GCS, так и с моделью на основе OpenPilot.