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

Пока мы обсуждали печатные платы, пользователи собрали четыре успешно полетевших Flix'а! Ничего себе. Значит, что-то в моем проекте есть, раз люди готовы потратить столько сил, чтобы его повторить. А это ведь сделать намного сложнее, чем собрать дрон из готовых компонентов.

🚀 @peter_ukhov собрал уже второй дрон. Очень аккуратное проектирование и сборка. Используется кастомная модель рамы и кастомный держатель ESP32: микроконтроллер не приклеен, а вставлен в специальные пазы. Транзисторы расположены снизу лучей и закреплены в специальных держателях. А еще это первый Flix на IMU ICM-20948 (используется плата GY-ICM20948V2).

🚀 Первый Flix от иностранного подписчика! Пользователь @yi_lun с Тайваня смог собрать дрон в рамках школьного проекта, и он успешно полетел! Здорово, что мой проект нашел отклик и в других странах.

🚀 Сборка от пользователя @p_kabakov. Первый Flix на МК, отличном от классического ESP32. А конкретно — на ESP32-C3. Этот микроконтроллер имеет совершенно иную архитектуру (RISC-V), но благодаря поддержке Arduino, код фактически не пришлось менять, и он просто заработал!

🚀 И еще один полетевший дрон, собранный в близком к эталонному виде, но с четырехлопастными пропеллерами. Автор: @fisheyeu.

Как обычно, я добавил все проекты в свой реестр успешно собранных дронов. Там же находятся ссылки на все материалы от авторов, включая кастомные 3D-модели. #user

Что хочу разместить на плате

Как я уже писал, я хочу сделать плату чуть более универсальной, чем только для квадрокоптера. На ней сможет работать Flix, но она будет подходить и для других проектов, которым может потребоваться мощный микроконтроллер с Wi-Fi и инерциальный датчик: например, для учебных мобильных роботов или чего похожего.

Список компонентов, которые я собираюсь на ней разместить (вначале обязательные, в конце — под вопросом):

🔹 Микроконтроллер + обвязка. Классический ESP32 либо более новый ESP32-S3. Последний мощнее и нативно поддерживает USB — то есть не требуется преобразователь USB-UART. Правда, по некоторым параметрам он хуже, например, в нем меньше PWM выходов. Пока думаю над выбором.
🔹 Вход питания от LiPo-аккумулятора и цепь для измерения заряда аккумулятора.
🔹 Датчик IMU. Наиболее вероятные кандидаты: ICM-20948 или ICM-42688-P/ICM-20602/MPU-6500 (без магнитометра).
🔹 Выходы на коллекторные моторы — MOSFET и обвязка.
🔹 Один или несколько светодиодов для индикации состояния.
🔹 Разъем для подключения шлейфа камеры, аналогичный плате ESP32-CAM. Для реализации простейших алгоритмов компьютерного зрения.
🔹 Слот для SD-карты?
🔹 Барометр?

Также хочу развести на плате гребенку со всеми основными пинами ESP32. К ним можно будет припаять RC-приемник, ESC бесколлекторных моторов, дополнительные датчики и что угодно еще — как на обычной отладочной плате ESP32.

Жду ваших комментариев и предложений! #pcb

Хочу сделать плату

Много было вопросов про печатную плату для моего квадрокоптера, кто-то даже начинал ее делать. Решил вот ее сделать сам. Разрабатывать буду в полностью открытом режиме: буду публиковать промежуточные этапы и учитывать ваш фидбэк. Сама прошивка останется совместимой как с версией Flix на плате, так и с «обычной» версией из отдельных компонентов. Я не большой умелец в пайке, поэтому хочу, чтобы плата была изготовлена «под ключ» — сразу с напаянными компонентами.

В комментариях я хотел бы обсудить — а как ее, собственно, лучше сделать?

Вопросы:

1️⃣ Какой сейчас самый доступный способ изготовить такую плату и доставить ее в Москву?

2️⃣ Какой софт лучше использовать для разводки платы?

3️⃣ Какие компоненты можно использовать, чтобы плату можно было произвести целиком сразу с напайкой, их надо брать из какого-то определенного списка?

Немного забегая вперед — плату я хочу сделать чуть более универсальной, чем только для квадрокоптера. Но подробности и полное описание того, чего я хочу сделать — в следующем посте! #pcb

Еще один успешно собранный дрон, от пользователя @Alexey_Karakash!

Видео, кстати, демонстрирует фичу, которая работает из коробки благодаря поддержке MAVLink и QGroundControl. Возможно подключить аппаратуру непосредственно к телефону или к компьютеру c запущенным QGroundControl (по проводу или по Bluetooth) и управлять дроном через Wi-Fi с аппаратуры, без необходимости установки RC-приемника.

✅ Как и обещал, сделал страницу с «реестром» успешно собранных дронов. Для каждого проекта есть краткое описание и ссылки на дополнительные материалы, включая кастомные 3D-модели для печати. Если у вас получится собрать дрон по моим инструкциям, а еще лучше, его как-либо модифицировать, пишите о результатах в чат или присылайте pull request с описанием проекта! #user

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

В некоторых случаях QGroundControl может дать дрону команду на полный газ сразу же при подключении. Это может произойти, если внешний пульт не откалиброван, или если вы развернете окно QGroundControl, в котором виртуальный стик газа был не на нуле, или еще бог знает по каким внутренним причинам. В этом случае моя прошивка, естественно, сразу же переводила дрон в состояние armed и отправляла его в небеса (или в стену).

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

Моя прошивка минималистическая, и такой механизм арминга я решил пока не вводить. Вместо этого я добавил fail-safe с таким условием: дрон не должен лететь, если он получает команду газа без предшествующей команды нулевого газа.

Это условие добавлено в файл failsafe.ino в виде функции armingFailsafe(). Она запоминает момент времени, когда последний раз был получен нулевой газ, и не дает перевести дрон в armed, если с этого момента прошло более 0.1 с.

Это делает прошивку намного безопаснее: внезапный полный газ при подключении QGroundControl или пульта с поднятым стиком газа почти гарантированно приводит к «крэшу».

Обновил раму дрона.

У старой рамы было слабое место в зоне крепления «стаканов» для моторов. Я его укрепил, продолжив ребро жесткости луча в виде своеобразного свода вниз (см. картинку). А еще в ней плохо держались моторы, постоянно норовили выскочить — я уменьшил диаметр «стаканов» и укоротил боковой разрез так, что он остался только в верхней части. Кроме того, чуть обновил размеры контейтера для батареи и сделал другие мелкие изменения.

Новый файл рамы выложен — теперь это Flix версии 1.1.

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

В чате задали вопрос про допустимость хранения величин, с которым оперирует прошивка, в переменных типа float (вместо double).

Вообще, на вопрос о выборе типа переменной с плавающей точкой хорошо отвечает прикрепленная таблица (источник).

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

В случае нашей прошивки, углы, угловые и линейные скорости, расстояния и пр. обычно имеют «человеческий» масштаб — находятся в пределах 1000. Для таких величин разрешения float более, чем достаточно — ~0.00006 в худшем случае.

Другая ситуация может возникнуть с большими значениями. Например — время с момента запуска прошивки (переменная t).

Значение dt, которое рассчитывается из t, при рабочей частоте в 1000 Гц будет плавать вокруг 0.001. Из таблицы видно, что при t > 1024 сек (17 мин), разрешение float уже достигает 0.0001 — всего на порядок меньше нашего dt. Это уже можно назвать «пограничьем» допустимого. А 17 минут — это вполне реальное время работы прошивки.

Поэтому я изменил тип переменной времени с float на double. В прошивке мало операций с абсолютным временим, так что на быстродействие это не повлияет.

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

Обновления

▶️ Многие спрашивали про возможность использования ESC и бесколлекторных моторов с Flix. Я вернул поддержку ESC в motors.ino. Для их использования нужно установить соответствующие значения PWM_PIN, PWM_MAX (например, 1000 и 2000 мкс) и PWM_STOP (остановка мотора, на некоторых ESC будет отличаться от PWM_PIN). Также необходимо снизить частоту ШИМ — PWM_FREQUENCY, чтобы нужная ширина импульса «влезала» в эту частоту. Например, при значении PMW_MAX в 2000, частота должна быть около 400 Гц.

▶️ Я увеличил разрешение ШИМ для моторов с 8 бит (256 значений) до 12 (4096 значений). Повлияло ли это как-то на полет — сказать сложно, но раз уж ESP32 позволяет, то почему бы и нет.

▶️ Параметризованы максимальные углы наклона полета и максимальная угловая скорость. Теперь их можно настраивать через QGroundControl в реальном времени.

▶️ Много упрощений и оптимизаций кода. Например, для вращения кватерниона теперь используется метод rotate вместо оператора умножения, благодаря чему код подсистемы оценки ориентации становится совсем уж простым и тривиальным.

🚀 Подписчик @peter_ukhov доделал и опубликовал полную схему актуальной версии Flix. Кроме того, по этой же ссылке доступна схема его собственной модификации дрона с ERLS-приемником. Теперь для сборки актуальной версии в дополнение к текстовому описанию в readme можно использовать и наглядную схему!

С наступающим новым годом!🎄

В этом году была написана очень удачная статья на Хабре, канал набрал 1000 подписчиков, в прошивку добавлено много чего нового, у Flix появились реальные пользователи и была опубликована первая глава учебника.

Лучшие посты 2024-го года:

• Сборка и полет второй версии дрона.
• Зарегистрирован домен quadcopter.dev.
• Полет кверх ногами.
• Раннее видео на 1000 подписчиков.
• Подбор MOSFET-транзистора.
• Реализация Fail-Safe.
• Анализ полетных логов.
• Описание архитектуры симулятора.
• Управление с телефона.
• Выполнение флипа.
• Как работает калибровка IMU.

Спасибо за подписку на канал и за ваш фидбэк. В будущем году будет интересно!

Подсистема параметров

Я добавил в прошивку Flix подсистему параметров, которая хранит их во флеш-памяти (а не в коде).

Как и все в моей прошивке, эта подсистема реализована в минималистическом стиле. В переменной parameters хранится список названий параметров и указателей на соответствующие переменные в памяти. При запуске прошивки эти переменные инициализируются значениями из флеша. Если по ходу работы какой-то параметр меняется, он автоматически сохраняется во флеш. За это отвечают функции setupParameters() и flushParameters() (upd: переименовано в syncParameters()).

Для работы с флешем используется стандартная библиотека Preferences. Это удобная обертка над NVS (non-volatile storage) — специальной областью флеша в ESP32, выделенной для хранения настроек программы. А чтобы все это работало и в симуляции, я реализовал такую же библиотеку Preferences.h, но с обычным текстовым файлом в качестве хранилища. В итоге код и поведение параметров в симуляторе практически ничем не отличается от реального дрона.

Учтены две основные проблемы с флешем:

⚠️ Запись во флеш медленная: она может занять до нескольких миллисекунд. Блокировка цикла управления полетом на такое время не желательна, поэтому flushParameters() срабатывает, только когда моторы не активны. При изменении параметров в полете (а это вполне возможно), сохранение будет отложено до приземления.

⚠️ У флеша ограниченное количество циклов перезаписи. Поэтому функция flushParameters() проверяет параметры только раз в секунду, на случай, если они вдруг начнут меняться слишком часто.

Кроме того, параметры полностью поддержаны в MAVLink — то есть с ними можно полноценно работать через QGroundControl, просматривать и изменять. Для этого добавляется поддержка сообщений PARAM_REQUEST_LIST, PARAM_REQUEST_READ и PARAM_SET.

Запись параметров во флеш и поддержка MAVLink сильно улучшает user-experience при использовании прошивки. Особенно, в процессе калибровки IMU и пульта управления — менять и пересобирать код теперь для этого не нужно.

Начало учебника и смена концепции

Как вы знаете, этот проект затевался, как проект по созданию учебника по разработке полетного контроллера квадрокоптера. И сегодня я, наконец, публикую первую версию сайта с учебником и одну из его глав, которая описывает работу с гироскопом:

📖 quadcopter.dev/gyro.html.

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

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

1️⃣ Текущая версия кода Flix станет иллюстрацией к учебнику. Код в ней будет ориентирован на минимализм и ограниченную функциональность. Эта версия кода будет называться «каноничной» и будет находиться в ветке canonical.

2️⃣ В основной же ветке будет разрабатываться новая, «фичная» версия. Она будет основана на каноничной версии, продолжит использовать Arduino и в ней будет та же базовая архитектура, но у нее не будет такого жесткого ограничения на сложность и объем кода. В нее я буду добавлять востребованные фичи, например, хранение параметров во флеше, более полную поддержку MAVLink, удержание позиции и другие. То есть фичный Flix должен стать лаконичным, но полнофункциональным полетным контроллером.

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

Поддержка ICM-20948 в Flix

Все, кто пробовали собирать мой дрон, заметили, что сейчас довольно проблемно купить модуль GY-91 (плата с IMU). MPU-9250 окончательно сняли с производства, и, видимо, на складах она тоже закончилась, поэтому на большинстве плат вместо нее стоят MPU-6500 (без магнитометра), а многие вообще идут с браком.

Официальная замена для MPU-9250 от InvenSense — это ICM-20948. Эта IMU имеет примерно те же функции, она чуть менее шумная и она сейчас производится и доступна. На Ali появились новые платки с одноименным названием (см. фото и видео), их много и они не дорогие. Поэтому я решил поддержать ICM-20948 в Flix.

Поддержка реализована на уровне библиотеки FlixPeriph. Я придумал простой универсальный интерфейс для обоих драйверов — MPU-9250 и ICM-20948. Этот интерфейс содержит базовый набор функций, который должен более-менее подходить для любой IMU.

Код Flix работает с этим интерфейсом, поэтому для использования ICM-20948 нужно просто заменить тип переменной с MPU9250 на ICM20948, а все дальнейшие вызовы останутся теми же. Если в FlixPeriph будут добавлены другие IMU, то они также будут использовать этот интерфейс и не будут требовать изменения кода Flix.

Таким образом, Flix теперь можно собрать как на плате GY-91 (или MPU6500), так и на новой плате ICM-20948.

Именно ICM-20948 я подумываю использовать в версии Flix с печатной платой, хотя это не точно. Кстати, а какие новые IMU вообще сейчас в тренде? Какие у них особенности и преимущества? Может сейчас для квадрокоптеров стоит использовать совсем другие IMU?

😎 Еще один летающий Flix! 4-й в общей сложности, и 2-й из собранных не мной.

Подписчик @rudpa смог его собрать, сконфигурировать и запустить в полет! Используется карбоновая рама K100, плата с IMU MPU-6500 (не GY-91) и мосфеты для управления моторами. Дрон управляется с телефона по Wi-Fi.

Этот дрон получился чем-то средним между официальной версией 1 и официальной версией 2 на 3D-печатной раме.

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

В процессе сборки, кстати, были найдены довольно странные баги в ESP32, обсуждение шло в чате проекта. Также по ходу я доработал и наконец-то опубликовал статью Troubleshooting, которая может помочь найти и починить проблемы.

Думаю, стоит завести в документации секцию с дронами пользователей и публиковать туда, что у кого получилось!

Реализация простейшего fail-safe.

Управление дроном по Wi-Fi не очень надежное: периодически связь отваливается, особенно на расстоянии. Если эту ситуацию никак не обработать, то дрон просто продолжит исполнять последнюю команду и, скорее всего, врежется в стену. Механизмы обработки подобных отказов часто называют fail-safe.

В этом коммите в код добавлен простейший RC fail-safe.

Вводится переменная controlsTime, в которой хранится момент последнего получения команд управления — от пульта или с телефона. Если с этого момента прошло времени больше заданного порога, то активируется fail-safe. Дрон переходит в псевдо-режим Descend, который подменяет собой пульт. В этом режиме дрон просто плавно уменьшает значение команды газа до 0 (оставаясь в горизонтальной ориентации). Время уменьшения газа с максимума до нуля задано, как DESCEND_TIME (3 с).

Режим Descend отличается от режима посадки (Land). Режим посадки требует дополнительных датчиков и управляет позицией дрона — происходит вертикальный полет вниз, а Descend просто спускается, как получится. Такое терминологическое разделение, кстати, принято во многих полетных контроллерах.

Таким образом, с этим изменением при отвале сигнала Wi-Fi или пульта дрон просто плавно «осядет» (см. видео). Не обязательно ровно и точно, но это все равно лучше, чем продолжать лететь по последней команде и куда-то врезаться.

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

Правда, потом передумали, потому что я в России, а они больше не возят платы в Россию.

Интересно, они многим так пишут?

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

❇️ Масштабные изменения в 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. Теперь у проекта есть официальный пользователь. Кроме того, он собирается внедрить мой дрон в учебный курс по разработке полетных алгоритмов в МАИ.

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

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

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

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