Flix: разработка полетного контроллера с нуля

Большие обновления в репозитории

❇️ Масштабные изменения в README и прочей документации: выложены все материалы по новой версии дрона, включая подробный список требуемых компонентов, модели для 3D-печати и краткие инструкции по сборке. Схема правда выложена только фрагментарная, буду рад, если кто-то сделает полноценную и наглядную схему. Кроме того, стали сильно более подробными инструкции по настройке и сборке прошивки и симулятора.

❇️ В motors.ino осталась только поддержка MOSFET’ов и убрана поддержка ESC — для упрощения кода. В шапке оставлена ссылка на версию файла с поддержкой ESC.

❇️ Вся логика кода переведена с системы координат FRD (Forward-Right-Down) на более интуитивную FLU (Forward-Left-Up) — в новой версии дрона IMU расположена именно так. Система FRD принята в авиации, но имеет явный недостаток: ось Z направлена вниз. Соответственно, в коде были кривоватые значения вроде Vector up(0, 0, -1), вместо интуитивного Vector up(0, 0, 1). Впрочем, тема с системами координат заслуживает отдельного поста.

❇️ Обновлена моделька дрона в симуляторе (скриншот в комментариях).

❇️ Wi-Fi теперь включен по умолчанию: тесты показали, что дрон вполне юзабелен с телефоном вместо пульта.

❇️ Другие мелкие исправления, например, исправлен баг, что подключение к QGroundControl в симуляторе отваливалось при сбросе (reset) мира в Gazebo.

Во многом все это изменения, накопившиеся в ветке new-version, и касающиеся новой версии дрона. Таким образом, теперь новую версию дрона можно можно считать выпущенной. В этой раме, конечно, есть определенные недостатки, поэтому она будет модифицироваться, но тем не менее на ней уже вполне можно собрать летабельный дрон. Так что жду ваших отзывов и модификаций!

Видео с более длинным полетом новой версии дрона. Управляю по Wi-Fi и изображаю что-то вроде прохождения трассы. (Это, кстати, полетная зона хакатона BRICS Future Skills в Казани).

Основные выводы по полетам.

💡 Дрон довольно неплохо управляется с телефона по Wi-Fi! На нем даже сумели полетать другие участники, несмотря на то, что телефоном управлять намного сложнее, так как он не дает обратной связи.

💡 Главная проблема управления по Wi-Fi — периодические обрывы связи. Сейчас в коде не предусмотрено никакого fail-safe, и в случае обрыва связи дрон просто продолжает лететь так же, как летел. Как раз в итоге такого разрыва дрон мы и раздолбали (фотка в комментариях). Как минимум нужно реализовать простой fail-safe в виде плавного снижения газа. А еще подумать, возможно ли как-то улучшить связь.

💡 В результате падения сломался один из лучей. Ребро жесткости его не спасло. Возможно, стоит увеличить ребра жесткости или, например, использовать PETG вместо PLA (хотя PLA у меня печатает намного лучше). Также при падении часто выскакивают моторы из посадочных «стаканов», стоит их сделать еще уже.

Но в целом я доволен полетами, ведь этот дрон собирается всего из нескольких простейших компонентов (ESP32, IMU, транзисторы), не требует даже RC, и тем не менее вполне полноценно летает и управляется!

Кто не видел, около недели назад на Хабре была опубликована статья про опыт применения моего дрона в университете МАИ: https://habr.com/ru/companies/itmai/articles/840132/.
Кстати, с этой статьи пришло много новых подписчиков, спасибо за подписку!

🎉 Итак, с новым дроном все оказалось не так просто, но в итоге он полетел! На видео дрон управляется с телефона по Wi-Fi, без RC-приемника, и работает это довольно четко.

Как видно, схема с MOSFET'ами оказалась рабочей. Все изменения кода для новой версии (пригодятся тем, кто сейчас хочет собрать версию с транзисторами) находятся в ветке new-version.

Проблемы, с которым я столкнулся:

▶️ Для сборки я использовал схему от пользователя, и на ней неправильно были подключены моторы в смысле направления вращения. Проблема решилась перестановкой пропеллеров и изменением знака параметра YAWRATE_P. Сейчас ошибка в схеме исправлена.

▶️ На моей плате IMU оказался нерабочим акселерометр. Выглядит это так: оси X и Y зависли в значениях -19.613600 и 19.613001, ось Z меняется. А без акселерометра невозможен полет в режиме STAB. Или возможен?

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

Вскоре будет создана полноценная страница со списком компонентов, 3D-моделями и схемой сборки, ждите обновлений!

Наконец-то собрал новую версию дрона с 3D-печатной рамой! В процессе пришлось ее перемоделить и перепечатать еще несколько раз. Поменял форм-фактор используемой батареи и ориентацию IMU. А еще новый дизайн позволяет вытащить все «внутренности» квадрокоптера и переставить их в другую раму без перепайки.

RC-приемник пока не ставил, попробую полетать с телефона по Wi-Fi.

Осталось проверить все компоненты, модифицировать код для использования мосфетов и другой ориентации IMU и попробовать полететь!

Проверка управления мотором

Наконец-то начал собирать новую версию дрона. Спаяна и проверена схема на MOSFET'е для подключения одного из моторов. На вид работает нормально!

Преимуществом использования MOSFET'а для управления коллекторным мотором перед ESC в прошлой версии является то, что я могу использовать любую частоту ШИМ для управления мотором. В ESC частота ограничена фиксированными длительностями импульсов (от 1600 до 2300 мкс). Еще одно преимущество — тот ESC слишком уж умный: пытается крутить мотор или издавать им какие-то звуки сразу после включения, что особенно неприятно, когда питание идет от USB.

Недостаток — отсутствие реверса, но он и не особенно нужен. А еще отсутствие тормоза, хотя для квадрокоптера это не критично (критично для ровера).

Скоро, надеюсь, дрон допаяю и дособеру, и мы увидим, насколько хорошо он будет летать, и будет ли летать вообще!

🎉 1000 подписчиков на канале!

Не ожидал, что на мой канал подпишутся столько людей, причем, меньше чем за год! В основном, это получилось благодаря статье на Хабре. А откуда еще вы узнали про мой канал?

В качестве бонуса на 1000 подписчиков выкладываю самое первое осмысленное видео, сделанное в рамках моего проекта по созданию полетника с нуля. Ноябрь 2019 года, офис COEX.

Выбор MOSFET-транзистора*

Как я уже писал, в новой версии дрона я решил отказаться от ESC для управления моторами, потому что они: 1) очень дорогие, 2) очень труднодоступные, 3) очень бессмысленные. Эти ESC предназначены в первую очередь для подключения моторов напрямую к RC-приемнику, поэтому обычно обладают слишком сложной, ненужной мне логикой.

Вместо них я буду управлять моторами через обычные MOSFET’ы. Опишу простой алгоритм выбора MOSFET'а для управления моторами с МК, который я в итоге выработал, основываясь на статьях, туториалах и консультациях.

▶️ Вначале необходимо определить максимальный ток нагрузки, которой планируется управлять. Для этого нужно подключить нагрузку (мотор) и мультиметр (в режиме измерения силы тока) к источнику питания последовательно. Я измерял ток при заблокированном моторе — это еще называется stall current. Это максимальный ток, который мотор может «съесть». Он составил около 5 А.

▶️ Далее подходящие MOSFET’ы ищутся по параметрам:

1. Корпус: все, что начинается на SOT, — мелкие SMD-транзисторы, сложно для пайки. Все, что начинается на TO, — более крупные транзисторы, простая пайка. Самый «простой» корпус — TO-220, подходит и для пайки и для макетных плат.
2. Структура: N-channel. Для управления нагрузкой с микроконтроллера обычно используются именно такие MOSFET'ы.
3. Drain-Source Voltage Vds. Максимальное напряжение на выходе транзистора (сток-исток). Должно быть выше номинального напряжения питания мотора (3.7 В), с запасом. Можно брать произвольно большие значения, например, 30 В.
4. Drain Current Id. Максимальный ток на выходе транзистора. Должен быть выше максимального тока нагрузки (5 A), с запасом. Здесь также можно взять произвольно большие значения, например, 50 А.
5. Gate-Source Voltage Vgs. Максимальное напряжение на входе транзистора (затвор-исток). Должно быть выше напряжения на пине микроконтроллера (3.3 В). Здесь при подборе лучше ориентироваться на меньшие значения, например, 15 В, чтобы транзистор мог полностью открыться, но об этом ниже.
6. Gate Threshold Voltage Vgs(th). Важный параметр, которого почему-то обычно нет в формах поиска. Определяет напряжение на входе транзистора, при котором он приоткрывается. Должен быть в полтора-два раза меньше напряжения на пине микроконтроллера. То есть в случае использования микроконтроллера с 3.3-вольтовыми пинами это значение должно составлять около 1–2 В, и чем меньше, тем лучше!
7. Drain-Source On-State Resistance Rds(on). Сопротивление полностью открытого транзистора. Чем меньше, тем лучше.

▶️ Для подходящего по параметрам MOSFET'а открывается его даташит и ищется самый полезный график: Drain Current — Drain-Source Voltage. На этом графике нарисовано несколько кривых, каждая из которых соответствует определенному напряжению на затворе транзистора. По оси Drain Current указывается «потолок» тока, который транзистор может провести при данном напряжении на затворе. Выбираем кривую, соответствующую напряжению меньше, чем на нашем МК (2.5 В с запасом), и находим по оси Drain-Source Voltage напряжение, которым питается мотор (3.7 В). Если по оси Drain Current выходит значение больше, чем максимальный ток нагрузки (5 А), то этот транзистор нам подойдет.

▶️ Кроме того, в даташите нужно проверить наличие встроенного диода, который нужен для защиты MOSFET’а от обратного тока от катушек мотора при его останове. Этот ток может сильно превысить номинальный ток мотора. Вообще есть разные мнения про этот диод, я остановился на том, чтобы он просто был. Это можно понять по структурной схеме MOSFET’а на первой странице или по упоминанию слов body diode в тексте.

В итоге поисков я выбрал тупо самый популярный MOSFET в Чипе и Дипе: 100N03A. Именно на нем я собираюсь собрать новую версию своего дрона на 3D-печатной раме, и этот процесс я подробно освещу в самое ближайшее время!

Но вообще я ненастоящий схемотехник, так что если что-то упустил или написал неправильно — пишите в комментариях.

* — тавтология.

Поддержка VSCode

Прошивку моего дрона можно редактировать и собирать в Arduino IDE, но сам я изначально писал код, конечно, не в ней, а в редакторе VSCode. При этом я использовал все «блага цивилизации»: автодополнение, go-to-definition и прочие фичи IntelliSense, отладчик (для симулятора). Кроме того, очень сильно помогал встроенный в VSCode ИИ-помощник Copilot.

Давно собирался добавить в репозиторий мою конфигурацию VSCode для проекта, но для этого ее надо было сделать более универсальной и платформонезависимой. В итоге в каком-то виде я это сделал. Теперь при открытия проекта в VSCode сразу начнут работать многие удобные фичи. Состав конфига:

▶️ Файлы settings.json, extensions.json — общие настройки VSCode для проекта и рекомендуемые расширения.

▶️ Файл tasks.json — автоматизация задач проекта, таких как сборка и загрузка прошивки и запуск симулятора. Задачи запускаются через команду Run Task. Консольный вывод задачи VSCode отображает во встроенном терминале, который умеет парсить ошибки и предупреждения компилятора и автоматически переходить на соответствующие строки в коде.

▶️ Файл launch.json для конфигурации отладчика. Сконфигурирован запуск отладки симулятора, все функции (точки останова, просмотр переменных) работают.

▶️ Файл c_cpp_properties.json для настройки анализатора C++-кода. В этом файле указываются пути к заголовочным файлам и некоторые другие параметры, чтобы VSCode мог корректно работать с кодом. Работает это все для Arduino-проекта, честно скажу, далеко не идеально. IntelliSense часто тупит, показывает ошибки там, где их нет. Иногда переходит в режим Tag Parser'а, когда в автодополнении он показывает все подряд, а не только то, что подходит по контексту. В общем, в этом плане VSCode для Arduino-проекта не особенно хорош.

Кстати, многие спрашивали, почему я не использую PlatformIO. В основном, потому что PlatformIO изначально показался мне довольно бестолковой надстройкой над тем, что и так работает. Тем не менее, я решил глянуть, как автодополнение и анализ кода будет работать в нем для простого Arduino-проекта на ESP32. PlatformIO по сути генерирует тот же самый c_cpp_properties.json, но при этом, как выяснилось, автодополнение, go-to-definition и все прочее в нем почему-то работают намного лучше и стабильнее, чем в «сыром» VSCode.

Впрочем, если переделывать проект на PlatformIO, то это потребует сильно менять и усложнять код. Придется отказаться от .ino-файлов и использовать классическую схему с заголовочниками и .cpp-файлами. Прошивку больше нельзя будет собрать через обычную Arduino IDE или Arduino CLI. Кроме того, непонятно, возможно ли подружить проект на PlatformIO с кодом для симулятора, который хоть и использует внутри себя код прошивки, но основан на совершенно других библиотеках, компилируется другим компилятором и вообще запускается на компьютере, а не на микроконтроллере.

А какой у вас опыт использования PlatformIO и Arduino в ваших проектах?

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

Анализ полетных логов

Flix записывает лог полета в RAM и передает его на компьютер в формате CSV (каждая строка — состояние дрона в определенный момент времени). И хоть памяти хватает всего на 10 секунд, до добавления этой функции отладить полетный код и оттюнить параметры было крайне затруднительно. Особенно активно анализ лога применяется при разработке хитрых маневров, типа флипа или полета кверх ногами.

Я добавил в репозиторий туториал по инструментам для анализа лога. Все эти инструменты использовались при разработке Flix, хотя и в разной мере:

1. PlotJuggler. Это основной инструмент, с помощью которого я анализировал логи. Он напрямую поддерживает импорт CSV-файлов (что очень удобно), и обладает неплохой функциональностью: может отображать несколько графиков сразу, поддерживает произвольную обработку данных на языке Lua, и еще в нем есть система плагинов.

Из минусов можно привести отсутствие готовой бинарной сборки для macOS, то есть приложение приходится собирать самостоятельно и делается это через пень колоду — приходится чинить ошибки и менять код. Для Windows и Linux готовые сборки есть.

2. FlightPlot. Этой мой любимый анализатор логов. Я использовал его для всех своих проектов, в том числе и при разработке "Клевера". Правда, остальные пользователи почему-то его не оценили, и сейчас он фактически находится в deprecated-состоянии.

Очень богатый набор встроенных обработок (интегрирование, дифференцирование, фильтрация, FFT) + удобный и интуитивный интерфейс. Я и сам внес лепту в этот проект, например, добавил недостающую функцию по поиску нужного поля в логе.

Минусом является то, что он поддерживает импорт файлов только одного формата — ULog. Это стандартный формат логов прошивок PX4 и ArduPilot. Готовых утилит для преобразования CSV в ULog почему-то не существовало, поэтому мне пришлось написать свою. Вы можете использовать ее для своих целей.

3. Foxglove Studio. Очень навороченная тулза: куча разных способов визуализации данных и очень замудренные настройки. Ее родной формат данных — MCAP. Готовых утилит для преобразования CSV в MCAP также не существовало, поэтому мне пришлось написать свою. Ее вы тоже можете использовать для своих целей.

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

4. ChatGPT.⚡️ Для меня ChatGPT это настоящая магия, но когда я попробовал его использовать для анализа данных, я офигел, если не сказать больше. ChatGPT действительно позволяет визуализировать и очень подробно анализировать лог полета Flix, причем команды даются в совершенно произвольной форме. Более того, мне даже не требуется описывать, что именно находится в файле лога, на который я его натравил, и вообще о чем он: я просто кидаю файл в чат и говорю, чтобы он сам разобрался, где там что — и он это делает.

Вот пример диалога с ChatGPT, где я попросил его выполнить несколько задач по анализу лога полета: https://chatgpt.com/share/d89c9d9b-317d-46df-a1aa-39703a498cd0. К сожалению, по этой ссылке не отображаются графики, которые он мне показал, поэтому запощу их отдельно в комментариях.

Вообще, ChatGPT и другие ИИ активно использовались при расчетах и при разработке кода в этом проекте, о чем, пожалуй, еще стоит рассказать отдельно.

⚡️ Полет кверх ногами

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

Благодаря тому, что рассчитываемые выводы на моторы в моем алгоритме могут быть и отрицательными, такой режим реализовать не так сложно. Вот, что нужно изменить в алгоритме управления:

1. Перевернуть на 180° цель по ориентации (это логично).
2. Увеличить цель по тяге (в перевернутом состоянии пропеллеры значительно менее эффективны) и поменять ее знак.
3. Перевернуть цель по угловой скорости по рысканию.

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

В итоге, ESC с реверсом именно для этого дрона вряд ли нужны, но как proof-of-concept режим полета кверх ногами на моей прошивке однозначно работает.

Статья на Хабре зашла, топ-1 статья за неделю 🎉. Благодаря Хабру, в канал пришло куча народу, теперь больше 720 подписчиков (было ~350). Спасибо вам всем большое за подписку, будем пилить контент!

Кстати, в посте довольно интересные комментарии, и вот один из комментариев привлек мое особое внимание. Сейчас в прошивке главный цикл привязан к частоте обновления IMU при помощи функции MPU9250::waitForData. Эта функция ожидает новых данных простым бесконечным циклом, то есть блокирует CPU от выполнения других потоков. (На самом деле других потоков в прошивке сейчас нет, а те, которые есть (Wi-Fi), все равно запущены с большим приоритетом. Но все-таки не очень красиво.)

Совсем правильным решением было бы использовать INT-пин IMU, который уведомляет МК о готовности новых данных, вызывая прерывание. Но такое решение намного сложнее, а мне все-таки очень хотелось оставить прошивку в простом Arduino’овском стиле: использовать классические setup и loop.

Я придумал другое более хитрое решение. Поскольку период работы IMU известен, в waitForData я просто жду оставшееся время от этого периода функцией delayMicroseconds, которая по факту отдает CPU другим потокам. Я домножаю период работы IMU на 0.8 на случай, если IMU вдруг надумает отдать данные раньше. Таким образом, большую часть времени ожидания данных с IMU основной поток не занимает CPU, а просто находится в режиме ожидания. Как вам такое решение?

Очень долго писал и наконец написал статью на Хабр о своем квадрокоптере: https://habr.com/ru/articles/814127/. Подробно описал процесс разработки и полетный алгоритм. У кого есть аккаунт, пожалуйста, поставьте плюс/напишите комментарий.

Библиотека FlixPeriph

Как я уже писал, я вынес драйвера устройств, которые используются в Flix, в отдельную Arduino-библиотеку: FlixPeriph. Она основана на библиотеках для IMU и SBUS-приемников от Bolder Flight. Но я сделал их более user-friendly, учел проблемы, которые возникли у первых пользователей моего дрона, и специфику моего проекта:

1. API приведено в соответствие со стилем Arduino.

2. Добавлен метод IMU.waitForData(), который блокирует выполнение программы, пока в IMU не появятся новые данные. Это удобно для организации цикла управления, основанного на частоте IMU, как это сделано в Flix.

3. Несколько пользователей столкнулись с тем, что на плате GY-91 почему-то бывает установлена IMU MPU-6500, вместо MPU-9250. Фактически MPU-6500 отличается от MPU-9250 тем, что в ней отсутствует магнитометр, хотя остальное API там практически такое же. Я добавил в библиотеку поддержку MPU-6500, причем тип IMU выбирается автоматически, основываясь на значении регистра WHO_AM_I. Моя прошивка сейчас все равно не использует магнитометр, то есть Flix теперь можно собрать и на основе MPU-6500.

4. Есть логирование ошибок. Если что-то пошло не так, библиотека выведет сообщение об ошибке, чего крайне не хватало при использовании оригинальной библиотеки. Причем порт для вывода ошибок выбирается на основе стандартного механизма Core Debug Output в ESP32. В этой платформе есть возможность возможность указать стандартный порт для вывода ошибок таким образом:

Serial2.setDebugOutput(true);

И моя библиотека использует этот механизм. На остальных платформах по умолчанию используется стандартный Serial, но это можно поменять методом IMU.setLogOutput().

В дальнейшем в FlixPeriph можно будет добавить и другие устройства. Библиотеку можно установить стандартными средствами Arduino IDE и использовать и в своих проектах. Она доступна под лицензией MIT.

Калибровка датчика IMU

Я решил перенести все драйвера устройств Flix в одну специально созданную для проекта Arduino-библиотеку: FlixPeriph. Там будут драйвера для датчиков IMU, RC-приемника и для чего-нибудь еще. По ходу дела я также вынес калибровку IMU в основной код Flix, потому что это не совсем тривиальная задача и она важна для понимания полетного алгоритма.

Суть калибровки

Без учета шума, искажения, вносимые гироскопом и акселерометром в измеряемое значение для каждой оси, можно описать такой моделью:

результат = измеряемое_значение * scale + bias,

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

Калибровка гироскопа: функция calibrateGyro().

Для гироскопа MPU9250 параметр scale откалиброван на заводе, и нас интересует только определение bias. Чтобы его вычислить, достаточно обездвижить дрон и рассчитать среднее значение данных с гироскопа за определенный период времени. В моем случае калибровка производится усреднением 1000 сэмплов при запуске прошивки. Это значит, что примерно одну секунду после включения дрон желательно не перемещать и не крутить.

Калибровка акселерометра: функция calibrateAccel().

С акселерометром все сложнее: для каждой оси нужно определить и bias, и scale. В процессе калибровки акселерометра мы пользуемся известным значением гравитационного ускорения g, которое акселерометр измеряет, находясь в покое (благодаря силе реакции опоры).

Пользователя надо заставить последовательно расположить IMU в шести ориентациях (горизонтально, на левом и правом боку, кверх ногами и т. д.), чтобы зафиксировать максимальные и минимальные значения, которые акселерометр показывает для известного ускорения g. Сделать это надо как можно точнее, лучше даже еще до установки IMU на дрон. Используя полученные данные, мы вычисляем калибровочные параметры следующим образом:

scale = (max - min) / 2 / g.
bias = (max + min) / 2.

Проверка калибровки

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

🎉 Второй экземпляр квадрокоптера Flix

Когда я начинал делать свой квадрокоптер в 2020 году, я не был уверен, что, даже если он полетит, он будет существовать в более чем одном экземпляре. Ведь реально кем-то используемых опенсорсных прошивок квадрокоптера не так много. Но теперь второй Flix существует!

После очень долгих попыток и обсуждений в чате проекта, @peter_ukhov все-таки смог сконфигурировать и заставить летать собственноручно собранный (по неполным инструкциям!) Flix. Теперь у проекта есть официальный пользователь. Кроме того, он собирается внедрить мой дрон в учебный курс по разработке полетных алгоритмов в МАИ.

Надеюсь, все это сможет стать началом чего-то масштабного и интересного!