Introduction-видео моего квадрокоптера https://youtu.be/8GzzIQ3C6DQ

А вот как выглядит мой квадрокоптер-прототип под «капотом». Виден используемый десятиосный модуль IMU GY-91 (MPU9250) и месиво из проводов. Знаю, что MPU9250 устарел, но тем не менее решил использовать именно его, как проверенную классику. Но не исключено, что стоит его и поменять: он обладает достаточно высоким уровнем шума.

FAQ #1

Получил довольно много вопросов по проекту, большое спасибо вам за интерес! Напишу ответы на некоторые из вопросов, которые задавали больше одного раза.

Где и когда можно купить? Сейчас этот проект на стадии прототипа. Но вы можете купить такой же набор компонентов, которые указаны в таблице, и попробовать собрать этот квадрокоптер самим (на свой страх и риск). Мне будет крайне интересно получить такой фидбэк!
А вот потенциальное создание продукта — это одна из целей этого блога: посмотрим, что из этого получится.

Почему Arduino? Мне очень понравилось, как разработчики Arduino реализовали свою консольную утилиту для работы с Arduino-проектом: arduino-cli. Среди прочего там реализован файл метаданных проекта и зависимостей — sketch.yaml, который позволяет делать воспроизводимые сборки.
Кроме того, мне нравится идея, что прошивку STEM-квадрокоптера можно открыть в стандартной Arduino IDE, модифицировать в ней что угодно и практически одной кнопкой загрузить в квадрокоптер.
Да, Arduino обвиняют в незрелости и игрушечности, но мне кажется, что это куда более актуально для ее древней реализации для AVR, чем для относительно новых для ESP32 и STM.

Где полная схема? Пока еще не готова, но будет. Есть общая структурная схема соединения компонентов, а конкретные номера пинов пока можно найти в исходнике.

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

Изначально моя идея была в том, чтобы симуляция запускала оригинальный Arduino'вский полетный код, не требуя никакой его модификации. И вот как мне удалось это реализовать.

1. Модель. Я разработал физическую модель своего дрона для Gazebo.
2. Плагин для Gazebo. Я написал плагин для Gazebo, который получает инпут с обычного USB-пульта, считывает данные с виртуальных датчиков, передает эту информацию в код для Arduino, а затем рассчитывает силы, которые создают пропеллеры. Исходный код этого плагина находится в файле simulator.cpp.
3. Имитация Arduino. В файле Arduino.h находится частичная реализация API Arduino, которая работает в контексте запущенной в Gazebo симуляции.

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

Сейчас любой желающий может запустить симулятор flix у себя на машине с Linux и macOS (Windows, к сожалению, толком поддерживается Gazebo). Для этого нужно склонировать репозиторий, установить зависимости и запустить симуляцию согласно инструкции. А если возникнут вопросы или проблемы при запуске, смело пишите мне или создавайте Issue на Github — все это очень сильно помогает мне дорабатывать проект!

🎄 Всех с наступившим 2024-м годом! 🎉 В этом году мое начинание с образовательным дроном и этим каналом приобретет поистине грандиозные масштабы :)

Из новостей: реализован общий для симуляции и реального дрона механизм калибровки пульта управления. Теперь можно запускать симулятор (или реальный дрон), калибровать ваш пульт и летать (до этого можно было «откалибровать» пульт только вручную).

Моим проектом заинтересовались люди из МГУ, Государственного университета «Дубна» и Московского авиационного института. Спасибо за ваш интерес!

Как минимум один читатель уже заказал комплектующие для сборки и тестирования моего квадрокоптера. И про нескольких я знаю, что они собирались. Будет очень интересно узнать, что получится!

У канала теперь есть официальный чат, и там уже идет довольно много интересных и детальных обсуждений, вступайте, кто хочет поучаствовать: @opensourcequadcopterchat.

Новости

Подписчик @peter_ukhov создал свою версию подробной принципиальной схемы квадрокоптера, по которой он сам собирается его собрать. Там пока есть кое-какие неточности, но тем не менее я добавил ссылку на нее в README, потому что до этого принципиальной схемы вообще не было.

Этот же подписчик задал справедливый вопрос об отсутствии хэндлинга зависимости проекта от MAVLink: эту библиотеку можно было скачать только вручную. Мне не нравится использовать git-сабмодули (почему-то любой сложный репозиторий, в котором есть сабмодули, в конечном итоге приходит в какое-то полусломанное состояние, такова уж моя статистика). Поэтому я просто решил создать новую библиотеку: MAVLink для Arduino. Это обычный C MAVLink (v2), но который вы легко можете добавить в свой Arduino-проект стандартными средствами Arduino. Его можно поставить из Library Manager в Arduino IDE либо установить при помощи Arduino-CLI. При этом, благодаря GitHub Actions, сама версия протокола MAVLink будет автоматически обновляться (раз в месяц) и при обновлении будет автоматически выпускаться новая версия MAVLink-Arduino. Удивительно, но до этого такой штуки не было, а теперь, вот, будет.

Поскольку решена проблема с зависимостью от MAVLink, а также другая проблема со сломанным релизом необходимой мне версии библиотеки для IMU MPU9250, теперь есть полная инструкция по сборке прошивки в Arduino IDE. Не требуется использование консоли и какой-либо магии, прошивка собирается в обычной Arduino IDE с библиотеками, доступными в Library Manager.

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

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

Прошивка квадрокоптера является обычным Arduino-скетчем, и может быть скомпилирована в Arduino IDE. Для передачи данных между подсистемами используются глобальные переменные.

Почему глобальные, если global variables considered harmful и все такое? В основном, для простоты. Рассматривайте эти переменные как упрощенную реализацию топиков. Многопоточности здесь нет, так что проблемы с синхронизацией доступа также не возникают.

Текущее состояние системы представлено следующими глобальными переменными:

1. t (float) — время текущего шага в секундах.
2. dt (float) — разница во времени между текущим и предыдущим шагами.
3. rates (Vector) — угловые скорости с гироскопа.
4. acc (Vector) — данные с акселерометра.
5. attitude (Quaternion) — текущая ориентация квадрокоптера, представленная в виде кватерниона.
6. control (float[6]) — положение управляющих стиков в диапазоне [-1, 1].
7. motors (float[4]) — команды на моторы в диапазоне [-1, 1] (отрицательные значения — реверс).

Алгоритм управления полетом реализован в файле control.ino, и его можно охарактеризовать так: двухуровневый трехмерный каскадный PID-регулятор (с low-pass фильтрацией d-членов). В следующих постах мы, конечно, разберем его подробнее. Сейчас можно сказать, что это типовой дизайн алгоритма управления квадрокоптерами. Что-то похожее, к примеру, реализовано и в полетном контроллере PX4.

Главный цикл системы работает с частотой ~1000 Гц. Общий dataflow выглядит следующим образом (см. диаграмму):

1. imu.ino считывает данные с IMU-датчика: гироскопа и акселерометра, учитывая калибровку. Записывает результаты в переменные rates и acc.
2. rc.ino считывает данные с RC-приемника, применяет калибровку, записывает результат в переменную controls.
3. estimate.ino рассчитывает текущую ориентацию квадрокоптера при помощи комплементарного фильтра, который объединяет данные с гироскопа и акселерометра. Результат записывается в переменную attitude.
4. control.ino используя команды со стиков (control), рассчитывает требуемую целевую ориентацию — attitudeTarget. Затем он применяет алгоритм регулирования со значениями rates и attitude в качестве обратной связи PID-регуляторов и рассчитывает выходные сигналы на моторы: motors.
5. motors.ino отправляет необходимые PWM-сигналы на регуляторы моторов.

Конечно, это только общий обзор дизайна прошивки, в дальнейшем я буду разбирать конкретные нюансы. Буду рад также и ответить на ваши вопросы в комментариях!

✅ Реализовано управление с телефона

Многие об этом спрашивали, и вот, наконец-то получилось реализовать парсинг MAVLink-сообщений и поддержку сообщения для управления дроном при помощи QGroundControl, с телефона (MAVLink-сообщение MANUAL_CONTROL).
Честно говоря, с самого начала разработки я не был уверен, что это вообще получится реализовать, так как с Wi-Fi на этом дроне есть определенные проблемы (подробности в комментариях ➡️).
Но фикс был найден и полет с телефона осуществлен!
Таким образом, этот квадрокоптер имеет смысл и без приемника/пульта управления, что в текущем прототипе составляло около половины его себестоимости.

Пост про SBUS

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

Физически SBUS представляет собой обычный односторонний UART (без пина RX), работающий с бодрейтом 100000 и с инвертированным пином TX. То есть в стандартном UART сигнал «1» передается низким напряжением на пине, а сигнал «0» — высоким, а в интерфейсе SBUS — наоборот.

Мне не удалось найти однозначное объяснение, зачем так было сделано. На форумах выдвигаются разнообразные версии: «исторические» причины, экономия энергии, сознательное усложнение reverse-инжиниринга интерфейса (см. одно из обсуждений).

Я собирал дрон с уверенностью, что ESP32 не может работать с такой инвертированной логикой, поэтому использовал внешний инвертор (продается на Ali, стоит копейки, однако занимает немало места на моем миниатюрном дроне). Благодаря комментариям к моему ролику на YouTube я узнал, что ESP32 содержит в себе встроенный инвертор пинов, надо лишь активировать его, и тогда внешний инвертор будет не нужен.

В старой версии библиотеки для работы с SBUS, которую я использую, нет возможности передать флаг о необходимости инверсии пина в качестве параметра, поэтому я решил изучить возможность включения этой инверсии «вручную». Изучив API ESP32-Arduino я нашел такую возможность. Это делается при помощи нестандартной функции Serial.setRxInvert().

Недолго думая, я ✅ добавил включение этого внутреннего инвертора в код flix. Правда сейчас у меня под рукой нет сетапа, где SBUS-приемник был бы подключен к ESP32 напрямую, поэтому я не знаю, насколько он рабочий. Просьба к тем, у кого будет возможность проверить, прислать результаты проверки!

В итоге, удалось упростить схему квадрокоптера, убрав из нее инвертор. Кроме того, благодаря обсуждению, инициированному в чате, я обнаружил, что в плате ESP32 Mini, которую я использую, на входе 5В установлен тот же стабилизатор напряжения, что и на плате IMU (ME6211), то есть он сможет питаться от Li-Po батареи. Поэтому я убрал усложнявшее схему питание ESP32 через IMU. Смотрите сильно упрощенную схему, по которой я собираюсь собирать новый дрон, в комментариях. ▶️

По просьбе пользователя, полет с телефонного пульта в симуляторе также реализован. Для этого достаточно запустить приложение QGroundControl на телефоне в той же сети, и оно подключится к симуляции автоматически. Далее надо включить в настройках Virtual Joystick (чекбокс Auto-Center Throttle должен быть выключен), и можно летать в симуляторе!

Для этого я реализовал для симулятора функции из прошивки sendWiFi и receiveWiFi, которые отправляют и принимают широковещательные (broadcast) UDP-пакеты с MAVLink-сообщениями.

Если у вас есть в доступе машина с Linux или macOS, попробуйте запустить мой симулятор: для этого есть подробные инструкции. Будет очень интересно получить фидбэк, работает ли на вашей машине симулятор flix и управление с телефона.

Сделал видео, иллюстрирующее работу Low-pass-фильтров (LPF) в алгоритме управления Flix. См. патч функции interpretRC для этого видео.

LPF (фильтр нижних частот) оставляет в сигнале только низкие частоты, отсекая частоты выше определенного порога (cutoff frequency). Этот фильтр сглаживает сигнал, убирает из него вибрации и шум. Он является одним из ключевых звеньев в алгоритмах управления роботами.

LPF в алгоритме управления моим дроном применяется к:

1. Угловой скорости, полученной с гироскопа (Rates LPF).
2. D-члену PID-регуляторов по угловой скорости (Rates D LPF). В моей реализации PID есть встроенный LPF для этой цели.

Как видно из видео, первый фильтр не оказывает особенного влияния на полет. Но надо учитывать, что IMU MPU-9250 имеет встроенную фильтрацию (184 Гц по умолчанию).

Второй же фильтр оказывает критичное влияние, без него дрон летает нестабильно. Это происходит потому, что D-член PID-регулятора реагирует на скорость изменения ошибки управления и крайне чувствителен к любому входному шуму. Фильтрация D-члена PID-регулятора — это типовой паттерн, и он применяется в самых разных контроллерах, включая PX4 и Betaflight.

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

Готовлю компоненты для второй версии квадрокоптера. Самое сложное — спроектировать и изготовить идеально подходящую 3D-печатную раму.

Во второй версии я собираюсь использовать более свежую ESP32 Mini с разъемом USB Type-C. И еще другие гораздо более дешевые регули для коллекторных моторов. Вообще, было бы неплохо использовать вместо регулей обычные транзисторы, но я пока не разобрался, какие лучше выбрать, плюс они требуют обвязку, которую навесным монтажом собирать будет очень неудобно.

Датчик IMU будет крепиться на винты M3 с пластиковыми демпферами. Также он повернут в более естественную для робототехники ориентацию Forward-Left-Up (в предыдущей версии — Forward-Right-Down).

Я еще до конца не определился, как расположить и закрепить ESP. На плате ESP32 Mini, к сожалению, нет никаких отверстий, чтобы ее можно было привинтить на стойки. Я напечатал десятки прототипов крепежей, все они не особенно работают из-за вариативности размеров ESP. В итоге пока что крепеж на двойной скотч.

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

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

В комментах еще пара фоток. ▶️

⭐️ Выполнение автоматического флипа

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

Реализовать флип на Flix оказалась намного сложнее, чем на «Клевере». Там используется управление угловыми скоростями в PX4, и флип выполняется всего несколькими командами. Качество управления по угловой скорости в Flix для такого резкого маневра пока оставляет желать лучшего, а оттюнить его — это отдельная история. Поэтому я реализовал исполнение флипа с прямым управлением моторами. Сначала я хотел реализовать математически обоснованный, образовательный алгоритм, но реальность внесла коррективы и код оброс подпорками и костылями. Поэтому сейчас это чистый proof-of-concept. В дальнейшем я переделаю алгоритм, чтобы убрать костыли и добавить математической обоснованности, а также применю какой-нибудь интересный метод оптимизации параметров для выполнения идеального флипа, например, генетический алгоритм.

А вот и код, при помощи которого мне удалось снять это видео с флипом: flip.ino. Полный разбор алгоритма и его этапов — в комментариях. ▶️

Поизучал D2 — новый интересный язык для создания диаграмм. Это как Mermaid, но с сильно более простым и очевидным синтаксисом. Такие диаграммы можно рендерить автоматически при сборке документации и очень легко менять.

Вот, попробовал составить более-менее полную диаграмму алгоритма управления моего дрона в стиле Simulink (см. файл). Сложно сказать, насколько это наглядно, но как минимум красиво. Как вам? Исходник смотрится очень хорошо: вот он на D2 Playground.

Еще выложил интерактивную SVG-версию со ссылками на конкретные места в коде: firmware.svg.

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

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

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

Калибровка датчика 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() и проверить стабильность определяемой ориентации. При использовании только гироскопа должен наблюдаться минимальный дрейф. Если использовать только акселерометр, то дрон, лежащий на поверхности в покое, должен показывать идеально точную ориентацию.

Библиотека 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.

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

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

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

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

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