Результаты первых тестов платы

✅ Подсистема питания работает, плата запускается от USB, от батареи, и от обоих источников одновременно. Менял вход аккумулятора от 4.2 до 2.5В, buck-boost отрабатывает корректно. ⚠️ Обнаружил такую проблему: если плату сначала запитать от батареи, а потом подключить по USB, то она не будет видна в системе. Думаю, это скорее всего связано с прошивкой, вряд ли с разводкой.

✅ Заливка прошивки работает. В arduino-cli для этого нужно использовать такой FBQN: esp32:esp32:esp32s3:FlashSize=16M,PSRAM=opi. Также в Arduino и arduino-cli необходимо включать опцию USB CDC On Boot, чтобы все выводы в Serial можно было видеть по USB (аналогично тому, как это работает в платах с обычной ESP32).

❌ Но тут обнаружилась проблема: прошивка иногда стартует не с первого раза. То есть надо переткнуть питание 2 или 3 раза, и только тогда она запускается. Как будто есть какая-то проблема с пинами IO0 или EN. Подскажите, что это может быть?

✅ Прошивка Flix базово работает, Wi-Fi раздается, консоль отвечает. Я добавил в прошивку параметр RC_RX_PIN, который позволяет выбрать пин для SBUS‑интерфейса, и по умолчанию он равен -1, то есть SBUS теперь по умолчанию не запускается.

✅ RGB-светодиод — работает. ⚠️ Но когда управляющий пин не задействован прошивкой, то тыкая пальцем в плату, иногда можно включать его в рандомный цвет. Возможно, тут стоит что-то поменять в разводке, чтобы такого не было.

✅ Проверил выводы на моторы, они работают. ⚠️ В левом верхнем выводе перепутана полярность на шелкографии, но это не критично.

Работу IMU пока не проверил: ICM‑40609‑D довольно новая, и пока никто не написал для нее библиотеку для Arduino. Так что теперь займусь ее написанием.

В целом: супер-критичных косяков пока не нашел. В комментариях — несколько видео разных тестов.

Для каких проектов лучше всего подходит ESP32

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

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

Лично я думаю, что ESP32 сейчас — это платформа №1 для получения фана от программирования. Неспроста она снискала такую любовь от DIY-разработчиков по всему миру. А фан важен — для привлечения людей, для сохранения мотивации к работе над проектом.

У ESP крайне разнообразный и гибкий набор фич, который развязывает руки и позволяет экспериментировать. Тот же GPIO matrix — любой пин может быть назначен на любую функцию. Или очень гибкая настройка UART (включая инверсию линии данных), что позволило мне подключить SBUS-приемник напрямую к МК.

Arduino в ESP32 — это first class citizen. Официальной поддержкой Arduino занимается сама Espressif, не сторонние разработчики. А Arduino позволяет на любой популярной ОС (Windows, Linux, macOS) в 3 клика получить рабочий тулчейн для сборки и разработки проекта. Попробуйте поставить и настроить родной тулчейн для STM на macOS — это далеко не простейшая задача, по пути можно растерять всю мотивацию.

По фичам. ESP32 из коробки поддерживает работу с камерами, touch-датчиками, I2S (как универсальный костыль для коммуникации с чем угодно), конечно же, Wi-Fi/Bluetooth/BLE/ESPNOW и весь сетевой стек. Для всего есть удобные библиотеки и понятные примеры. Под капотом (даже когда это Arduino с его setup/loop) всегда крутится FreeRTOS, и при желании можно использовать все ее возможности.

Так что если удовольствие от разработки важно — надо брать ESP32.

А как вы выбираете платформу для своих проектов?

Главный миф об акселерометре

Хочу разобрать один миф, связанный с расчетом текущей ориентации дрона (attitude estimation). Миф заключается в том, что акселерометр якобы может измерять ускорение свободного падения / силу гравитации, и поэтому его можно использовать для коррекции расчета ориентации. Это не так.

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

Но теперь рассмотрим, какие силы действуют на дрон в полете. По сути их три: гравитация, тяга от пропеллеров и ветер. Акселерометр может измерить только последние две. В квадрокоптере конструктивно тяга от пропеллеров всегда направлена строго вверх, то есть без учета шума акселерометр всегда будет выдавать (0, 0, тягу пропеллеров) — это не зависит от ориентации вообще. Ветер может быть в любом направлении, от ориентации также не зависит.

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

Получается, дрейф убрать нельзя?

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

Чтобы использовать эту информацию, нужно всего лишь подмешать чисто вертикальный вектор (0, 0, 1) в расчет ориентации, с небольшим весом. Я реализовал эту идею в ветке est-lvl, в функции applyLevel.

Интересно, что коррекция по акселерометру, как это делается везде, фактически дает нам тот же результат (помните, что тяга всегда направлена вверх?), но только намного шумнее, и с неверной мотивировкой — только в качестве побочного эффекта.

Резюмируя, для attitude estimation:

❌ НЕКОРРЕКТНО: подмешивать вертикаль с акселерометра в полете.

✅ КОРРЕКТНО: подмешивать вектор (0, 0, 1) в полете.

Я уже давно тестирую этот механизм, и он работает довольно хорошо: дрейфа реально нет. У кого есть дрон — протестируйте тоже!

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

Начал работу по вкручиванию поддержки ESP-NOW.

ESP-NOW это одна из главных фишек ESP, низкоуровневый обмен сообщениями по Wi-Fi, но без всяких подключений, SSID и паролей. Есть только сообщение, номер канала и MAC-адрес — и все. Это идеально подходит для обмена информацией с дроном.

Нюансы:

1️⃣ У ESP-NOW довольно странное API в Arduino, которое не придерживается Arduino-стиля. Вместо обычного чтения данных через read() используются коллбэки — причем вызываются они в контексте отдельного потока. Соответственно, для нормальной работы требуется возня с локами и очередями, а их совсем не хотелось бы тащить в код Flix. Интересно, что примеры в интернете про ESP-NOW этот вопрос просто игнорируют и лепят код с side-effect'ами прямо в коллбэки, как будто так и надо.

Хотя вообще решение есть — встроенный класс ESP_NOW_Serial_Class, который реализует интерфейс а ля Serial, и берет все хлопоты с потоками на себя. Но ESP_NOW_Serial_Class тоже не идеален: во-первых, он не позволяет принимать сообщения с произвольного MAC'а — только с заранее заданного (невозможен автоматический биндинг). Во-вторых, он повторяет отправку пакетов до тех пор, пока не получит подтверждение доставки. Это хорошо для имитации Serial-интерфейса, но не очень хорошо для передачи телеметрии или команд с джойстика. Максимальное количество повторов там 5, и это захардкожено. Было бы хорошо, если бы его можно было настраивать, причем для каждого сообщения отдельно, но такой возможности нет (может, сделать PR?).

2️⃣ Есть встроенная криптография, но можно ли использовать ее для аутентификации, или она только для шифрования — я пока не понял. Если нельзя, то придется прикручивать какую-то аутентификацию отдельно, например, использовать MAVLink message signing. Сейчас аутентификацию я сделал только по MAC-адресу, что, конечно, не является защитой и подходит только для лабораторных тестов.

В итоге, в ветке espnow я реализовал поддержку с помощью ESP_NOW_Serial_Class. Для наземной стороны написан простой скетч espnow-proxy, который проксирует ESP-NOW в USB. Для QGroundControl это выглядит как обычное Serial-подключение к полетнику. Настройка: установить WIFI_MODE = 3, командой espnow задать MAC-адрес наземной ESP.

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

Дрон починил (точнее собрал новый), летает, бага с гироскопом пока не наблюдаю. Для стоек теперь использовал TPU 95A, типа демпфирование.

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

Хочу спросить у вас, все же что лучше для проводов, отверстия или контактные площадки? А может все-таки сделать разъемы?