При сборке квадрокоптеров и других БПЛА обычно используют готовую плату полетного контроллера, содержащую все необходимые датчики и периферию, и готовую полетную прошивку, например, Betaflight, ArduPilot или PX4. Полетный контроллер управляет моторами квадрокоптера и обеспечивает стабильный полет.
В 2019-м году я взялся за достаточно амбициозную задачу — создать квадрокоптер, не используя готовую плату полетного контроллера и готовую прошивку, то есть реализовать вообще все с нуля. А затем описать этот процесс в виде учебника по теории и практике разработки полетных контроллеров БПЛА. Спустя четыре года мне удалось разработать стабильно летающий квадрокоптер на базе микроконтроллера ESP32 и платформы Arduino и даже получить для этого проекта небольшое распространение.
Исходный код проекта и все материалы опубликованы на GitHub: github.com/okalachev/flix. В статье я разберу из чего собран мой дрон и как устроена его прошивка.
Описание проекта
Прошивка полетного контроллера квадрокоптера — это достаточно сложный софт, который может включать передовые алгоритмы из теории автоматического управления. Такие прошивки пишут целые исследовательские группы и компании. Например, исходный код прошивки PX4, даже без учета сабмодулей, содержит порядка 400000 строк кода на С++. Этот код сложен для понимания и не подходит для изучения базовых принципов управления полетом БПЛА.
Я создал прошивку с максимально простым стилем кодирования, чтобы в ней мог разобраться любой, кто слегка знаком с Arduino. И она уже даже была использована в качестве учебного пособия в курсе по программированию полетных контроллеров в университете МАИ.
Сейчас моя прошивка состоит из 17 файлов на C++, в каждом из которых в среднем около 60 строк кода. Прошивку очень легко скомпилировать и загрузить в ESP32 как при помощи Arduino IDE, так и из консоли. Инструкции по сборке находятся в репозитории проекта.
Также я собрал миниатюрный квадрокоптер, который включает все компоненты полетного контроллера, но отдельно друг от друга. Небольшое видео с демонстрацией дрона, который у меня в итоге получился:
Выбор железа
При выборе железа я отдавал приоритет универсальным компонентам перед квадрокоптеро-специфичными. Я думаю, что именно так можно разобраться в устройстве чего-либо по-настоящему глубоко. Важными факторами также были дешевизна компонентов и их доступность в России.
Микроконтроллер
Центральным компонентом полетного контроллера является микроконтроллер, и чаще всего это микроконтроллеры семейства STM32. Я же решил взять более нестандартный микроконтроллер ESP32 в виде платы ESP32 Mini. Этот китайский микроконтроллер располагает большими ресурсами, чем тот же STM32F4 и при этом стоит дешевле. Но его главная особенность — это встроенный Wi-Fi и Bluetooth. По Wi-Fi можно организовать коммуникацию между квадрокоптером и наземной станцией: получать телеметрию и отправлять команды, а также управлять им при помощи смартфона, что я и реализовал.
Датчики
Минимальный набор датчиков, необходимый для стабильного полета квадрокоптера — это гироскоп и акселерометр. Эти два датчика (а также иногда магнитометр) обычно объединяются в едином чипе, который называется Inertial Measurement Unit, сокращенно IMU. Для своего квадрокоптера я использовал IMU InvenSense MPU-9250. IMU подключается к микроконтроллеру по шине SPI.
RC-приемник
Для приема сигнала с пульта управления используется стандартный 2.4 ГГц RC-приемник, который связывается с пультом по радиопротоколу Futaba S-FHSS. Приемник подключается к микроконтроллеру через интерфейс Futaba SBUS, который фактически является обычным UART с инвертированным сигналом RX. К счастью, ESP32 поддерживает инверсию сигнала UART аппаратно, а кроме того имеет свободные UART-интерфейсы, так что с подключением приемника проблем не возникает.
Моторы
Я использовал коллекторные моторы типоразмера 8520 (8.5 мм на 20 мм), которые часто используются в миниатюрных квадрокоптерах. Они гораздо дешевле бесколлекторных моторов и просты в управлении — подключаются к микроконтроллеру через полевой транзистор (MOSFET) и управляются ШИМ-сигналом. Впрочем, в первой версии для простоты я все же использовал готовый модуль для управления моторами с AliExpress, но в следующих версиях я планирую от него отказаться и использовать обычный транзистор.
Рама
Для размещения всех компонентов я взял стандартную 100-миллиметровую карбоновую раму с AliExpress, подходящую для используемых моторов. Следующую версию я планирую собрать на собственной раме, напечатанной на 3D-принтере, которая лучше подойдет для размещения вышеописанных компонентов.
Питание
Для питания квадрокоптера используется однобаночный литий-полимерный аккумулятор с номинальным напряжением 3.7 В. Я подобрал аккумулятор с высокой токоотдачей, чтобы тока хватило и на моторы, и на микроконтроллер с Wi-Fi, IMU и RC-приемник. ESP32 питается от 3.3 В, но в платах ESP32 Mini и GY-91 есть встроенные LDO-регуляторы напряжения, которые позволили запитать их напрямую от аккумулятора.
Сборка
Вооружившись паяльником, мотком силиконовых проводов и двухсторонним скотчем, я произвел сборку своего дрона. Процесс занял около недели и выглядел примерно так:
На фотографиях видно микроконтроллер, модуль IMU, RC-приемник и моторы. Все это соединено проводами и закреплено на раме.
Полный список использовавшихся в текущей версии компонентов приведен в соответствущем списке в репозитории проекта. Там же есть ссылка на полную схему подключения компонентов.
После сборки я приступил к самому сложному этапу — разработке и отладке полетной прошивки. И этот этап затянулся на годы. Но в итоге я все-таки пришел к успеху. Ниже я рассмотрю общий алгоритм управления квадрокоптером, и как я его реализовал.
Алгоритм управления квадрокоптером
Квадрокоптер это не самостабилизирующийся летательный аппарат, и для его полета необходим достаточной сложный алгоритм управления. Цель этого алгоритма — поддерживать стабильный полет согласно заданным пилотом командам: например, удерживать заданную ориентацию, скорость или позицию. Для этого применяется алгоритм автоматического управления с обратной связью. Этот алгоритм состоит из подсистемы оценки состояния (state estimation) и подсистемы регулирования (control).
Подсистема оценки состояния использует данные с датчиков для того, чтобы максимально точно рассчитать текущее состояние квадрокоптера: угловая скорость, ориентация, линейная скорость, позиция и другие параметры.
Подсистема регулирования принимает на вход текущее состояние и желаемое состояние, которое еще называется уставкой (setpoint). На основе разницы между текущим и желаемым состоянием алгоритм регулирования рассчитывает управляющее воздействие (control action) — сигналы на моторы. Цель управляющего воздействия — наиболее эффективно привести дрон в желаемое состояние. Этот алгоритм выполняется в бесконечном цикле с высокой частотой.
В моей прошивке для реализации этого цикла используется стандартная функция loop из Arduino, в которой последовательно производится чтение датчиков, оценка состояния, регулирование, а также выполняются сервисные функции. В начале итерации вызывается блокирующая функция readIMU, за счет чего частота главного цикла привязана к частоте работы датчика IMU, которая сконфигурирована на 1000 Гц. Главный цикл прошивки находится в файле flix.ino.
Подсистема оценки (файл estimate.ino)
Подсистема оценка реализует классический алгоритм оценки ориентации объекта с использованием гироскопа и акселерометра — комплементарный фильтр.
Этот алгоритм рассчитывает взвешенную сумму между ориентацией, полученной интегрированием угловых скоростей c гироскопа, и направлением вектора гравитации, полученного из акселерометра. Таким образом используются преимущества обоих датчиков и компенсируются их недостатки: дрейф гироскопа при интегрировании, и шум и чувствительность к вибрациям акселерометра.
Выходами подсистемы оценки являются отфильтрованная угловая скорость по трем осям (переменная rates) и текущая ориентация квадрокоптера (переменная attitude). Ориентация представлена в виде кватерниона, что является стандартным способом представления ориентации в робототехнике.
Подсистема регулирования (файл control.ino)
Подсистема регулирования принимает на вход состояние дрона и положение стиков на пульте управления пилота. Задачей является расчет управляющих сигналов на моторы.
Стандартный алгоритм управления квадрокоптером включает несколько подуровней, которые еще называются контурами управления. Каждый контур отвечает за определенный аспект полета: позиция, скорость, ориентация, угловая скорость. Все вместе они образуют так называемый каскад, в котором вход каждого последующего контура является выходом предыдущего. Например, чтобы дрон полетел вперед — приобрел линейную скорость, ему необходимо наклониться вперед — поменять ориентацию, а чтобы поменять ориентацию, ему необходимо изменить угловую скорость.
Я реализовал два нижних уровня этого каскада: управление ориентацией и управление угловой скоростью. Это позволяет пилоту летать в режиме стабилизации ориентации. В этом режиме правый стик пульта определяет наклоны квадрокоптера, а левый — общий уровень газа и вращение вокруг вертикальной оси. В разных дронах этот режим может называться режимом удержания горизонта, «LEVEL», «ANGLE» или «STABILIZE». В моем дроне этот режим называется STAB.
Также есть возможность переключения в режим управления угловой скоростью (ACRO), в котором задействуется только самый нижний уровень каскада управления. Этот режим гораздо сложнее для пилотирования и обычно используется в гонках и при выполнении трюков.
Управление угловой скоростью
Начнем рассмотрение каскада с самого нижнего уровня. Задача этого уровня — принять на вход требуемые угловые скорости и рассчитать управляющие сигналы на моторы. Чтобы понять способ расчета управляющих сигналов, рассмотрим диаграмму сил, действующих на квадрокоптер:
Из диаграммы видно, что на квадрокоптер действуют сила гравитации и четыре силы тяги пропеллеров, которые должны ее компенсировать. Но если создать «перекос» по тяге между парами пропеллеров (передние — задние, левые — правые), то можно создать крутящий момент, который будет изменять угловую скорость квадрокоптера:
Этот крутящий момент будет линейно зависеть от разницы тяги между пропеллерами. Управляя этой разницей, можно управлять продольной и поперечной угловой скоростью квадрокоптера.
Управление угловой скоростью вокруг вертикальной оси (рыскание) реализуется по-другому — используется тот факт, что каждый из моторов помимо вращения пропеллера немного вращает также и сам квадрокоптер в противоположную сторону. Направление вращения у пропеллеров разное, и если одна диагональная пара пропеллеров вращается быстрее, чем другая, то квадрокоптер будет вращаться вокруг вертикальной оси. На диаграмме синие стрелки показывают крутящие моменты от моторов, которые действуют на квадрокоптер:
В итоге, если мы поместим требуемые крутящие моменты в вектор torqueTarget, а общую требуемую тягу в переменную thrustTarget, то управляющие сигналы на моторы можно рассчитать как простые суммы:
motors[MOTOR_FRONT_LEFT] = thrustTarget + torqueTarget.y + torqueTarget.x - torqueTarget.z;
motors[MOTOR_FRONT_RIGHT] = thrustTarget + torqueTarget.y - torqueTarget.x + torqueTarget.z;
motors[MOTOR_REAR_LEFT] = thrustTarget - torqueTarget.y + torqueTarget.x + torqueTarget.z;
motors[MOTOR_REAR_RIGHT] = thrustTarget - torqueTarget.y - torqueTarget.x - torqueTarget.z;
Эта набор формул называется миксером (mixer) и фактически полностью определяет конфигурацию БПЛА. Например, для мультикоптера с шестью пропеллерами (гексакоптера) миксер будет другим, а основной алгоритм управления останется тем же. Миксер реализован в функции controlTorque.
Теперь, зная текущие угловые скорости и требуемые угловые скорости, нам необходимо рассчитать этот самый требуемый крутящий момент torqueTarget. И теоретически в этом нам должен помочь...
...P-регулятор
В идеальном случае для расчета torqueTarget мы просто считаем ошибку регулирования — разницу между требуемой угловой скоростью и фактической и домножаем ее на некоторый произвольно выбранный коэффициент пропорциональности p, который определит «резкость» реакции квадрокоптера:
torqueTarget = p * (ratesTarget - rates);
Такой алгоритм управления называется пропорциональным регулятором или P-регулятором. Но на практике возникают две проблемы:
Во-первых, моторы обладают инерцией, и они не могут мгновенно изменить скорость вращения. Из-за этого при управлении с помощью простого P-регулятора возникнут «перестрелы» и осцилляции.
Во-вторых, все моторы немного отличаются друг от друга и расположены на раме не идеально. Это вызывает статическую ошибку управления, или проще говоря, постоянное нежелательное вращение квадрокоптера вокруг какой-то случайной оси.
Самый простой способ решения этих проблем — это PID-регулятор.
PID-регулятор (файл pid.h)
PID-регулятор вместо одного коэффициента для управления системой вводит три: пропорциональный, интегральный и дифференциальный. Эти три коэффициента подбираются вручную в процессе тюнинга системы.
Дифференциальный коэффициент d умножается на производную ошибки регулирования и таким образом реализует упреждение в управлении системой. Это решает проблему инерционности системы.
Интегральный коэффициент i умножается на интеграл ошибки регулирования и решает проблему статической ошибки управления. Через пару секунд полета это значение «накапливается» и становится в точности равным статической ошибке, компенсируя ее.
Упрощенно, PID-регулятор на С++ выглядит так:
integral += error * dt;
control_action = p * error + i * integral + d * (error - prevError) / dt;
Более интуитивно понять суть его работы можно на специально созданной демо-странице.
В итоге, для управления угловой скоростью применяются три независимых PID-регулятора для каждой из осей: rollRatePID, pitchRatePID и yawRatePID. За работу с этими тремя регуляторами отвечает функция controlRates.
Управление ориентацией
Управление ориентацией принимает на вход требуемую ориентацию (которую определяет пилот), текущую ориентацию квадрокоптера и рассчитывает требуемую угловую скорость ratesTarget. Расчет ошибки регулирования здесь сложнее. Для ее расчета используется специальная кинематическая формула, реализованная в функции angularRatesBetweenVectors. Затем этот вектор ошибки регулирования также поступает на вход трех PID-регуляторов: rollPID, pitchPID и yawPID. Правда интегральный и дифференциальный компоненты в них не задействованы (I = D = 0), так как на практике для стабильного полета в них нет необходимости, так что фактически это простые P-регуляторы.
Этот контур реализован в функции controlAttitude. Согласно каскаду, выход этого контура поступает в описанную выше функцию controlRates.
Результат
Объединив вышеописанные подсистемы, а также добавив к ним сервисные функции — чтение данных с датчиков (imu.ino), положения стиков на пульте управления (rc.ino) и, собственно, вывод управляющих сигналов на моторы (motors.ino), в теории мы и получаем стабильно летающий и управляющийся с пульта квадрокоптер. Ну и на практике, спустя много месяцев отладки, мы также его получаем.
Подытоживая, приведу ссылку на полную диаграмму алгоритма, которую я реализовал на языке D2: диаграмма управления полетом.
В репозитории проекта также есть краткий обзор архитектуры прошивки.
Почему разработка шла так долго
Главная проблема разработки прошивки для квадрокоптера — это крайне сложная отладка летающего аппарата. Ведь летящий дрон нельзя «поставить на паузу», чтобы проанализировать его состояние. Большую часть времени разработки дрон вообще не делал ничего похожего на стабильный полет. При попытке взлета он либо мгновенно переворачивался, либо взлетал, входил в дикие осцилляции и тут же врезался в ближайшую стену. Как правило, после нескольких часов такой отладки у меня опускались руки и я забрасывал проект на месяцы.
Помогло добавление логирования состояний дрона в оперативную память микроконтроллера, с последующим скачиванием и анализом логов. Однако поворотной точкой стала разработка симулятора на базе среды Gazebo. Именно после пошаговой отладки алгоритма в симуляторе удалось добиться самого первого более-менее стабильного полета на дроне.
Основные причины, по которым квадрокоптер не летал или летал плохо:
Из-за неправильной конфигурации IMU реальная частота обновления данных с гироскопа и акселерометра составляла не 1000 Гц, а 50 Гц. Такой частоты критически недостаточно для стабилизации квадрокоптера.
Частота обновления ШИМ-сигнала на моторах также была низкой — 50 Гц. Увеличение частоты до 200 Гц сильно улучшило стабильность полета.
В изначальной версии сборки по ошибке были использованы моторы с некорректным напряжением питания — 6 В вместо 3.7 В. В результате чего когда алгоритм квадрокоптера был относительно отлажен, квадрокоптер был катастрофически слаб по тяге и мог летать только первые 20-30 секунд после полной зарядки аккумулятора.
Отсутствие фильтрации D-компонента PID-регулятора. D-компонент крайне чувствителен к шумам, поэтому его нужно фильтровать. В изначальной версии алгоритма такой фильтрации не было, что приводило к очень сильным осцилляциям при полете. После добавления low-pass фильтра полет стал стабильным.
Многие другие критичные ошибки и неточности в алгоритме управления, которые удалось отладить благодаря симуляции.
Дополнительные функции
Помимо собственно полета с пульта, мой дрон имеет ряд дополнительных функций. Так, он частично реализует коммуникацию по протоколу MAVLink — популярному протоколу для взаимодействия с БПЛА. Это позволяет подключаться к нему по Wi-Fi и просматривать телеметрию при помощи программы QGroundControl. Кроме того, с использованием мобильной версии этой программы можно управлять дроном со смартфона.
Также, как уже было упомянуто, у дрона есть полноценный симулятор, реализованный на основе среды для симуляции Gazebo. Симулятор запускает реальный код прошивки, имитируя работу датчиков и моторов, и частично имитируя API Arduino. Код симуляции и инструкции по его сборке также доступны в репозитории проекта и любой желающий может запустить его на своем компьютере (Ubuntu / macOS).
Впрочем, тема симуляции заслуживает отдельной статьи. Здесь лишь приведу только ссылку на пост в Telegram-канале, который рассказывает об архитектуре симулятора моего дрона.
Блог проекта и будущий учебник
Если вам интересен проект, вы можете подписаться на блог в Telegram, где публикуются все новости проекта, а также посты о разработке полетных контроллеров и БПЛА в целом. Такие, например, как этот пост, где подробно описывается, как на моем дроне был реализован алгоритм выполнения автоматического флипа:
Если статья «зайдет», я могу написать и другие статьи на тему разработки полетных контроллера БПЛА, благо по этой теме есть о чем рассказать. Впрочем, основной контент я планирую размещать в блоге проекта, а также в будущем учебнике по разработке полетных контроллеров, для которого я и создал этот дрон, хотя и для собственного самообразования, конечно, тоже.
Буду рад ответить на любые вопросы и комментарии. Спасибо за внимание!
Комментарии (101)
deadln
14.05.2024 07:47+2Наблюдаю за проектом с момента появления телеграмм канала. Код и в правду весьма понятный, и не пугает своей сложностью как другие мейнстримные прошивки. ТАУ под капотом выглядит не сложно, и не подумал бы что это всё заняло 4 года, хотя область эта конечно для моего понимания непростая. Подумываю над тем чтобы собрать этот дрон как только у меня разгрузится расписание. Есть мысль попробовать сделать вклад в проект добавив поддержку ELRS.
chv Автор
14.05.2024 07:47+21Конкретно этот алгоритм это не рокет-сайенс и 4 года занял не он :). А безуспешные попытки его отладки, чтобы заставить дрон стабильно летать, и последующие за ними забрасывания проекта.
Psychosynthesis
14.05.2024 07:47+1Круто что доделали, представляю какой кайф, когда всё это наконец заработало =)
fivlabor
14.05.2024 07:47+3Помню на какой-то конференции говорили, что "в релиз выходит одна строка в день". То есть строчишь целый год, тестишь/фиксишь/коммитишь и через год смотришь на гит, а там 3 сотни строк.
Это, естественно, не касается крудов и json-манипуляций - там хоть каждый день талмуды выдавай.
AkhramovichSA
14.05.2024 07:47+1Для ELRS и CRSF уже есть много готовых библиотек, например вот эта: https://github.com/BobbyIndustries/crsfSerial. Для ESP32 подключается легко.
Sad_Bro
14.05.2024 07:47+2Здорово! продолжение интересно. Как раз не спешно смотрю что бы повторить для новичка не сильно затратное что бы пощупать эту тему.
nikolz
14.05.2024 07:47+2Несколько вопросов:
1) У Вас используется одно ядро ESP32?
2) На сколько загружен процессор, занята флеш используется RAM ?
3) Сколько потребляют двигатели и блок управления в % ?
4) Какое общее энергопотребление в полете?
5) Какая дальность управления?
6) Какой вес и полезная нагрузка?
7) можно ли в вашем симуляторе отлаживать блоки управления на других процессорах?
Спасибо
chv Автор
14.05.2024 07:47+3Сразу предупрежу, что цель создания дрона была не побить рекорды, а образовательная, но тем не менее:
1. Полетный код использует одно ядро. Но насколько я знаю, Wi-Fi в ESP32 использует второе.
2. Честно говоря, не проверял, предположу, что существенное время итерации он просто ждет данных с IMU. Без поддержки Wi-Fi прошивка занимает 25% флеша, с поддержкой — 59%. Статически используется порядка 30% RAM, сколько используется в процессе работы — не проверял.
3. Не совсем понял вопрос. Каждый мотор потребляет порядка 2 А, остальное — это мелочь.
4. Не измерял, могу прикинуть, что точно до 10 А.
5. Это зависит от приемника и пульта, у тех, что я использую, думаю, достаточно большая, по крайней мере я в помещениях не отлетал настолько далеко, а вне помещения я не летал.
6. Дрон весит ~60 г, максимальная суммарная тяга пропеллеров ~120 г, соответственно, поднять кроме себя он может очень мало чего.nikolz
14.05.2024 07:47Может быть в учебных целях сделать на ESP-12E ?
Будет еще проще.
chv Автор
14.05.2024 07:47+2ESP8266 все-таки менее мощный, чем ESP32.
nikolz
14.05.2024 07:47+1Ну я и говорю, что ESP8266 хватит с запасом, судя по Вашему ответу. Кроме того, код будет еще проще.
----------------
Посмотрел Ваш код. Вы не используете таймеры, а делаете цикл. Т е зря грузите процессор.
chv Автор
14.05.2024 07:47+2Весь полетный код намеренно помещен в Arduino'вский loop, чтобы он проще воспринимался людьми, знакомыми с Arduino. Однако это не значит, что он обязательно будет зря грузить процессор — функция ожидания данных с IMU вполне может и освобождать поток, пока новые данные не появятся. Это реализуемо средствами FreeRTOS, которая и рулит потоками в ESP32 (и в ESP8266).
nikolz
14.05.2024 07:47Вы же не для многоядерного процессора пишите.
RTOS здесь избыточна.
Можно все сделать проще и быстрее.
Делал подобное : гироскоп+магнитометр+акселерометр+измеритель расстояния TOF+синтезатор речи на ESP8266 и все исполняется с запасом.
Но Вы автор, поэтому спорить не буду.
sappience
14.05.2024 07:47+1Вы же не для многоядерного процессора пишите.
RTOS здесь избыточна.
ESP32 двухъядерный. 2. RTOS там почти без вариантов. Контроллер плохо документирован на том уровне который позволил бы отказаться от использования FreeRTOS.
nikolz
14.05.2024 07:47Да, в ESP32 нет альтернативы RTOS. Но у Вас всего одна задача.
Альтернатива есть в esp8285 и esp8266.
buratino
14.05.2024 07:47+2RTOS здесь избыточна.
"ты видишь суслика?" оно там в любом случае есть.
на ESP8266 и все исполняется с запасом.
Там на всё 80кб рамы, из которых в лучшем случае отъест WiFi и прочий Arduino framework
FGV
14.05.2024 07:47... ESP8266 хватит с запасом ...
У 8266 i2c - программный. Чую очень весело будет опрашивать датчики с частотой 1кГц, одновременно руля вайфаем.
nikolz
14.05.2024 07:47Один ESP8266 выше крыши.
Все делается очень просто.
Настраивается таймер на 1 кГц.
При этом процессор свободен или что-то считает в это время.
По прерыванию таймера опрашиваем по I2C со скоростью до 1MГц.
Датчики можно опрашивать по готовности.
Если надо SPI то со скоростью до 8 MГц (DMA)
----------
Можете посчитать сколько на это уйдет времени.
У Вас нет роутера при работе с БПЛА. Максимум точка доступа на смартфоне. Я бы вообще использовал протокол ESPNow.
Ничто ничего не тормозит.
Я делаю опрос датчиков на голом металле, если надо WiFi ,то включаю радио блок .
Все получается до безобразия просто.
chv Автор
14.05.2024 07:47+1Вообще самый корректный и эффективный вариант это использовать пин IMU, который выдает сигнал, когда появляются новые данные, для пробуждения МК по прерыванию. Просто это как-то сильно сложнее, и не уверен, что целесообразно для такого проекта, как у меня.
Впрочем, вполне возможно, что я перейду на такой вариант.
fio
14.05.2024 07:47для пробуждения МК по прерыванию.
Зачем усыплять контроллер? Он хоть и от батарейки питается, но расходует ее пренебрежимо мало по сравнению с моторами.
И при работе WiFi могут быть сюрпризы с прерываниями (они используются для работы WiFi)
chv Автор
14.05.2024 07:47+1Чтобы отдавать CPU на другие таски, которые могут выполяться параллельно (если их добавить).
В "серьезных" полетных контроллерах, как правило, для чтения IMU все же используется прерывание.fio
14.05.2024 07:47Вы писали про пробуждение (из сна). Вот я и не понял зачем нужен режим сна? Это не просто пустой цикл, а специальный режим, отключающий определенные блоки MCU. Нужен в основном для экономии энергии.
Про прерывания все правильно - нужно работать по ним. Таймер - прежде всего. Если внешние модули поддерживают прерывания по готовности данных, то и их использовать
chv Автор
14.05.2024 07:47+1Ну под "сном" я имел в виду idle планировщика задач, в каком-то смысле это тоже сон. Честно говоря, я не знаю, что он делает на ESP32, когда задач нет — переводит CPU в какой-то особый режим или просто делает бесконечный while.
chv Автор
14.05.2024 07:47Но если таска одна, тогда да, нет никакой значимой разницы между засыпанием и просто циклом.
FGV
14.05.2024 07:47+2Речь таки про 8266, у него свои прибабахи, это совсем не stm32.
По прерыванию таймера опрашиваем по I2C со скоростью до 1MГц.
У esp8266 i2c реализовано программно, скорость - до 100кГц.
Тут правда я упустил, imu висит на spi (не знаю почему, но думал что на i2c).
Датчики можно опрашивать по готовности.
А как готовность определить? А, опросить датчик, через spi, i2c, ну или ногу выделить под прерывание (если она есть).
С ногами у 8266 отдельная беда - их мало, примерно с 10 под нужды пользователя.
При этом процессор свободен или что-то считает в это время.
Вот тут вторая особенность esp8266 - у него нет аппаратной поддержки плавающей точки.
В общем мое мнение - на 8266 если это возможно реализовать, то уж сильно теоретически. Данная реализация потребует очень сильной оптимизации, и код будет совсем не на адурине.
buratino
14.05.2024 07:47+1У Вас нет роутера при работе с БПЛА. Максимум точка доступа на смартфоне. Я бы вообще использовал протокол ESPNow.
Какой нафиг ESPNow на смартфоне?
DieSlogan
14.05.2024 07:47Что конкретно проще? Если по размерам, есть варианты ESP32 сопоставимые с ESP8266.
Думаю, что в плане оптимизации чего-либо стоит обратить внимание на варианты с LoraWan или Zegbee, они жрут меньше энергии, чем Wi-Fi
К слову, если код переписать без Arduino Core, то это тоже положительно скажется на энергосбережении.
nikolz
14.05.2024 07:47Проще писать на Си, проще nonOS, чем RTOS.
Меньше размеры модуля, меньше потребление, меньше греется.
Но если очень хочется, то можно и ESP32 оставить.
Если с ардуино уйдете на СИ для ESP32, то будете долго писать и не факт что отладите.
--------------------------
В дронах обычно контроллер питают от отдельной батарейки.
Для ESP32 надо в импульсе до 500 mA, для ESP8285 хватит и 300. Если подключить SX1280, то в ESP передатчик отключаем и ток потребления у ESP8285 17 мА, а BLE реализуем на SX.
Есть готовые модули на которых установлена ESP и SX.
в них WiFi используют для смены прошивки протокола ELRS
--------------------------
LoRa используется для передачи команд и телеметрии и реализует ELRS -протокол управления БПЛА.
ZigBee в данном случае хуже, чем LоRа и здесь нет никаких сетей.
-------------------------
Меня заинтересовал такой вариант:
RP2040-zero (2 ядра, но без RF) и добавить SX1280 (LoRa+BLE).
Но для большой дальности ( а мы знаем зачем) надо использовать диапазон ниже и там уже нет ни WiFi ни BLE ни ZigBee.
DieSlogan
14.05.2024 07:47Проще писать на Си, проще nonOS, чем RTOS.
Меньше размеры модуля, меньше потребление, меньше греется.
Но если очень хочется, то можно и ESP32 оставить.
Как раз только один вариант с ESP8266 и остаётся, т.к. поддержки под ESP32 у производителя нет. Да и зачем мучаться, это не сравнение Python vs C, даже если и будет разница, то в десятки килобайт, это не серьезно.
Если с ардуино уйдете на СИ для ESP32, то будете долго писать и не факт что отладите.
Как раз под nonOS такое возможно, а на родном ESP-IDF я отлаживал :)
AkhramovichSA
14.05.2024 07:47В таких системах реального времени ничего ждать не надо, в IMU есть проверка на готовность данных, если данных нет, то пропускаем и обрабатываем цикл дальше.
chv Автор
14.05.2024 07:47Суть полетного алгоритма в том, чтобы дождаться новых данных с IMU и сразу же на них среагировать. Если данных нет, мы не можем на просто забить на это, мы должны ждать, пока появятся.
AkhramovichSA
14.05.2024 07:47Эх, работали бы все так системы без задержек и сбоев. Для IMU кстати это еще применимо, так как он, на удивление, очень надежен и работает как часы. А вот по сигналам управлению с пульта, или ГНСС-датчика данные могу пропадать или существенно задерживаться.
devlev
14.05.2024 07:47+5Задался я как то раз целью вращать коллекторный двигатель с подключенным энкодером так, чтобы максимально точно возвращать его и уметь возвращать ровно на заданное число оборотов. И тоже стал решать эту задачу с нуля. И что я могу сказать - без тестирования кода, наверно у меня бы ушло на решение этой задачи год. Хотя казалось бы, что тут сложного, нужно лишь в точное время включить двигатель и в точное выключить, а потом проделать тоже самое только обратно. Но есть нюанс.
После того как мне удалось отделить бизнес логику, которая крутилась на ардуино отделить в отдельную библиотеку, дело стронулось с места. Эта библиотека была покрыта тестами, которые поражали своей извращенность. Но в реальности такое ведь может произойти. В реальности датчик может начать выдавать данные которые для него не характерны. Так было в нескольких авариях с самолетами, когда самолет задирал нос, терял скрость и падал штопором. Почему такое произошло? Потому что датчик тангажа начинал врать.
Поэтому главный принцип бизнес логики - не верю никому. Чуть что-то начало присылать странные данные - используем дефолтные значения или переходим к плану Б. Чуть что-то пошло не так - падача питания на двигатель есть а движения энкодера нет - все выключить с выводом ошибки.
Сами сигналы с датчиком можно легко записать в логи и потом покрытть тестами и эти данные. Тогда сразу будет видно - вообще живой ли датчик. Адекватные ли данные он присылает.
Калибровка - тоже не маловажная часть любого подобного проекта. Если нужно то можно делать ее каждый раз перед запуском. Что-то можно откалибровать уже находу.
Короткая 3х секундная программа калибровки уже ввоздухе смоглабы много узнать о реальных показателях коптера. 3 секунды для микрокомпьютера просто бездна времени для сбора данных и их анализа.
Ну и конечно основа основ - юнит тесты! Без них очень сложно сделать поистени сложные вещи. Ардуина или будь то STM32 просто принимает данные с датчиков и передает их в бизнеслогику. Бизнес логика обрабатывает данные и выдает уровни газа для моторов. Безнес логика пакуется в отедельную библиотеку и покрывается юнит тестами. В таких тестах мы можем легко эмулировать перемещение во времени и показания самих датчиков. В идиальных условиях Бизнес логика должны на любые эти изменения уметь реагировать и делать то что нужно.
chv Автор
14.05.2024 07:47+3Калибровка IMU, кстати, в моем коде есть, без нее дрон бы не смог летать. Она просто не влезла в статью.
Dynasaur
14.05.2024 07:47+1только тут нет бизнес-логики, так как это не бизнес. Это просто логика, или логика контроллера.
NutsUnderline
14.05.2024 07:47+2ardupilot то наверное тоже с 100 строчек начинался, а потом .. както все понеслось
chv Автор
14.05.2024 07:47Верное замечание, но ArduPilot все-таки изначально делали только для практических целей, а не образовательных.
nikolz
14.05.2024 07:47+2Можно встроить это:
Некоторые модули ExpressLRS TX включают дополнительный чип ESP8285, который позволяет осуществлять беспроводную связь с другими устройствами с поддержкой ESP8285, используя протокол под названием espnow. Цель TX-Backpack - обеспечить беспроводную связь между EXPRESSLR и другими устройствами, связанными с FPV, для командования и управления или для запроса конфигурации.
Основным вариантом использования является модуль видеоприемника (или VRX). В настоящее время существует не так много модулей VRX, в которые встроен ESP8285, позволяющий им взаимодействовать с EXPRESSLR, поэтому в большинстве случаев вам нужно добавить свой собственный. Небольшой приемник на базе ESP можно “подключить” к вашему модулю VRX, что позволяет ExpressLRS управлять диапазоном и каналом, на которые настроены ваши очки.
AkhramovichSA
14.05.2024 07:47В большинстве модулей ESP8285 (как правило на приемнике) или ESP32 используется как контроллер и реализуют логику, например FHSS. А за радиочасть отвечают микросхемы типа SX1276 которые подключены к микроконтроллеру по SPI.
nikolz
14.05.2024 07:47+2Дополню, не только SX1276, но и SX128X (2.4 ГГц). Эти чипы используются для передачи команд и телеметрии по протоколу LoRa.
Интересное решение ESP8285(8266)+SX1280(81) .
На SX1280(81) реализуется не только LoRa, но и BLE.
В итоге получаем три протокола WiFi,LoRa,BLE, а в действительности еще и протокол FLRC. При этом токи потребление примерно в 3 раза меньше, чем с ESP32. Дальность управления по протоколу LoRa может составлять десятки км.
Дополнительно SX1280 позволяет измерить расстояние до дрона.
AkhramovichSA
14.05.2024 07:47Про измерение расстояния не знал, очень интересно. Уже нашел материалы, почитал как это реализовано.
А такой вопрос - ими можно как-то сканировать радиоэфир?
nikolz
14.05.2024 07:47+1Можно. SX12xx это приемник и передатчик с изменяемой частотой настройки и 3 вида модуляции. Все управление прием-передача делается на внешнем MCU. Можно это совместить с полетным контроллером.
SX1280(1281):
NutsUnderline
14.05.2024 07:47вопрос только в скорости сканирования
На SX1280(81) реализуется не только LoRa, но и BLE.
Ну что GFSK там есть это да, но что на ней прям BLE кто то сделал? или там все таки свой формат пакета
almaz1c
14.05.2024 07:47+3Главная проблема разработки прошивки для квадрокоптера — это крайне сложная отладка летающего аппарата.
В свое время решил эту проблему сборкой стенда, который обеспечивал натяжение рыболовной лески вертикально на высоту 1.5 метра. Леска продавалась в отверстие печатной платы квадрика мах ближе к геометрическому центру квадрика так, чтобы она была мах равноудалена от всех винтов и как можно меньше влияла на движение квадрика. Это позволило отлаживать ориентацию квадрика в пространстве и его вертикальные перемещения, избежав полетов "в стену/в потолок" в процессе отладки.
Vsmarte
14.05.2024 07:474 года, три из которых ты ждал детальки с алиэкспресса
voldemar_d
14.05.2024 07:47В последнее время быстрее месяца обычно приходит, недели за 2-3 даже бывало.
kuznet1
14.05.2024 07:47Дроном можно управлять с телефона, но будет ли работать вообще без DF500?
Можно ли использовать модули esp32-cam?
chv Автор
14.05.2024 07:47+1Да, без приемника он может работать, хотя с телефона летать не очень удобно.
Теоретически можно, хотя не знаю, хватит ли там пинов. И насколько esp32-cam может справиться одновременно и с управлением полетом, и с тем, чтобы что-то делать с камерой.
ef_end_y
14.05.2024 07:47Странный у вас лоупасс фильтр. Он, конечно, сглаживает сигнал, но имхо искажает сильно. Я б делал как среднее значение на нескольких семплах
chv Автор
14.05.2024 07:47Такой тип low-pass фильтрации это не мое изобретение. Он описан очень много где (например), в том числе известно, как переводить cut-off frequency в smoothing constant α.
Это не самый точный тип low-pass фильтра, но зато самый простой.AkhramovichSA
14.05.2024 07:47low-pass здесь стандартный, но надо делать конечно все дискретной форме, как и ПИД-регуляторы. Здравствуй z-преобразование :-)
buldo
14.05.2024 07:47+1Интересный проект. Желаю ему оставаться таким простым и понятным(код не читал, но что угодно понятнее бетафлайта).
Небольшой IMHO. Если бы я сейчас загорелся идеей собрать коптер по вашему проекту, то мне было бы проще найти 4 БК мотора и 4в1 esc на 25й стек, чем паять транзисторы на макетку.
По поводу печатной рамы. Уже видели проект nanoLongRange?
chv Автор
14.05.2024 07:47Вы правы, мой способ сборки вообще не претендует на простоту, в этом его и фишка. Проще всего взять готовый полетный контроллер.
Кажется nanoLongRange кидали, но посмотрю.
blind_oracle
14.05.2024 07:47+1Ну, можно просто последовательно усложнять проект :)
Управлять ESC через DShot с ESP32 достаточно просто (есть библиотека DShotRMT). Отладив полёт можно перейти к написанию своей прошивки для ESC :)
Dexif
14.05.2024 07:47+1Есть такой проект https://espcopter.com/
Тоже все думал собрать на esp32 но так руки и не дошли.
Завидую вам.
chv Автор
14.05.2024 07:47+1Да, это я видел, правда уже после того, как разработал свой. Но этот дрон, насколько я понимаю, не претендует на простой и наглядный исходный код, который можно использовать в качестве учебного пособия. Его код даже не опубликован на GitHub а распространяется просто в виде ZIP-архива.
Тем не менее выглядит интересно.
Dexif
14.05.2024 07:47Ошибаетесь. Есть на гитхабе. Если мне память не изменяет я там на него и наткнулся изначально.
https://github.com/verlab/espcopter
Ну а развивается именно для обучения детей
Но да я не могу сказать что там красиво в плане кода. )
chv Автор
14.05.2024 07:47+2Это я нашел, но там последний коммит 5 лет назад. В ZIP-архиве файлов намного больше. Не думаю, что это официальный репозиторий этого проекта.
Dexif
14.05.2024 07:47Возможно, я давно уже не заглядывал к ним. Просто в памяти отложилось и иногда инста подкидывает их посты посмотреть.
Вы не подумайте я не пытаюсь что-то доказать) Я очень завидую тому что вам такое удалось и с удовольствием буду наблюдать за развитием. Может мой малой подрастет и мы с ним вместе накатим ваш код на очередную уже esp64)
dmandreev
14.05.2024 07:47+4Замечательный проект! Читатели, не поленитесь, зайдите на гитхаб поставьте звезду.
Riketta
14.05.2024 07:47+2Открытая, понятная, легко модифицируемая прошивка для всех видов моделей - https://github.com/nickrehm/dRehmFlight/ (https://www.youtube.com/@NicholasRehm).
Отличный вариант для прототипов необычных моделей (VTOL, трикоптеры, модели с лидарами и другими необычными сенсорами, экранопланы, модели на гидрофойлах и т.д. - смотрите ютуб канал автора), образовательных целей и "поиграться".
В том числе он подробно и с примерами кода рассказывает как работает флайтконтроллер в нескольких своих видео.
checkpoint
14.05.2024 07:47Круто! Молодец! Я тоже когда-то разрабатывал свой "полётник" - IMU сделал, потом аппарат разбил и все это дело забросил. В моём IMU я экспериментировал с алгоритмами "sensor fusion" - обьединение данных с массива однородных датчиков (4 гиро, 4 акселя и 2 магнитометра подключенных к STM32F4) с целью уменьшения собственной ошибки датчиков. У меня не плохо работал алгоритм Махони с небольшими доработками. Какой алгоритм рассчета IMU используется у Вас ?
chv Автор
14.05.2024 07:47+1У меня используется самый простой комплементарный фильтр, который объединяет один гироскоп и один акселерометр, этого, в принципе достаточно для полета. Но при желании можно добавить и другие датчики, поскольку по сути это взвешенная сумма значений.
Didimus
14.05.2024 07:47Через какое время накопленная ошибка становится существенной?
chv Автор
14.05.2024 07:47Накопленная ошибка из-за интегрирования гироскопа, вы имеете в виду? Поскольку есть калибровка, то не очень быстро, 5-10 минут, может.
Didimus
14.05.2024 07:47Это же сравнимо с полетным временем? Как это скомпенсировать?
chv Автор
14.05.2024 07:47В полетных прошивках, где есть estimation позиции, например, при помощи GPS, есть способы при помощи позиции скорректировать ориентацию.
Если есть только акселерометр и гироскоп — то идеально никак. Но можно принять, что пилот скорее всего будет пилотировать дрон так, что в среднем он будет в нейтральной ориентации. И подмешивать нейтральную ориентацию с маленьким весом. Тогда ориентация не уплывет.
jouilk23
14.05.2024 07:47+1Интересный опыт! Желаю проекту развития, хотелось бы наблюдать за ним и дальше.
blind_oracle
14.05.2024 07:47Для разработки можно ещё можно попробовать использовать SITL/HITL (Software/Hardware In The Loop). Для примера https://github.com/iNavFlight/inav/discussions/9246 https://github.com/RomanLut/INAV-X-Plane-HITL
chv Автор
14.05.2024 07:47SITL у меня используется, мой симулятор как раз и разработан по принципу SITL.
Imaginarium
14.05.2024 07:47+4Глубокое уважение и признательность за проект и статью -- на фоне копроблогов и менеджерских рассказов о прекрасном будущем эта статья как глоток воздуха старого доброго Хабра.
Psychosynthesis
14.05.2024 07:47Круто, спасибо!
Было б здорово, если б вы оставили проект в состоянии учебника, не навешивая на него дополнительных "фишек", чтоб можно было в нём разбираться или использовать как базу для своих контроллеров.chv Автор
14.05.2024 07:47+2Да, я пытаюсь так и сделать. Потому что есть много идей, чего можно было бы добавить, но что сильно усложнит код. Возможно, стоит разделить проекта на две части? "Базовая часть", только с текущими функциями, и "практико-ориентированная" часть со всем фаршем?
AkhramovichSA
14.05.2024 07:47Мне очень сильно помог вот такой проект: https://www.youtube.com/@carbonaeronautics
Там и гитхаб есть с простым учебным кодом и сама книга: https://github.com/CarbonAeronautics?tab=repositories
Psychosynthesis
14.05.2024 07:47Можно и так, при условии, что в базовой части не придётся делать какие-то изменения, чтобы работала "практико-ориентированная"...
Ну, то есть, на мой взгляд хорошая практика если части кода по максимуму независимы от других.
AkhramovichSA
14.05.2024 07:47Олег, такое уточнение. То, что вы называете режимом ACRO на самом деле не ACRO. Изучая различные материалы, я заметил, что это общее заблуждение. В коде реализована простая стабилизация угловой скорости или еще называют режим RATE или RATE_CONTROL.
В теории он должен работать как режим ACRO, т.е. увеличиваю джойстик по тангажу, квадрокоптер начинает вращаться, уменьшаю – он остается в заданном угле пока обратным движением джойстика не заставлю вращаться в обратном направлении. Но на практике дрон ведет себя по-другому.
Как я понял, режим ACRO должен еще отслеживать установленный угол после возврата джойстика в 0, т.е. это тот же режим ANGLE, только изменение угла происходит не джойстиком, а джойстик меняет угловую скорость вращения квадрокоптера.
chv Автор
14.05.2024 07:47Интересное уточнение. Вообще я не изучал подробно, как в других полетных контроллерах реализован режим ACRO. Возможно, это разнится от прошивки к прошивке.
В целом, этот нюанс, наверное, очень важен для пилотов, которые летают в ACRO, но с точки зрения понимания полетного алгоритма он не столь значим. Полетный режим ACRO у меня добавлен лишь для иллюстрации идеи полетных режимов и по умолчанию отключен. Я ни разу не пробовал в нем летать.
Ritoneet
14.05.2024 07:47+1Вот ведь люди химичат. Весь мой опыт работы с ESP32 ограничен созданием rgb-подсветки в туалет с датчиком движения
Stratum
14.05.2024 07:47Спасибо автору! Я на таком же железе лодку на радиоуправлении собираю. Утяну пару строчек кода, а статью положил в закладки.
alexvalchuk
14.05.2024 07:47Стучись пообщаться. Я над своей наземкой на мавлинке год тружусь. Может будет полезно пообщаться
erlyvideo
ты не пробовал для отладки дрона делать подвижный подвес?
chv Автор
Серьезный подвес я собирать на пробовал, но я пытался отладить стабилизацию, подвешивая его на нитях. Итог: это очень неудобно и бесполезно. С подвесом отлаживать можно, да.
AkhramovichSA
Подвес обязательно делать делать и уж точно не из ниток. У вас маленький дрон и его отладка безопасна, а когда отлаживаешь дроны от 7 дюймов, то очень опасно. Мы для начала сделали одноосный подвес с жестким креплением и регулируемым противовесом. Можно быстро собрать из станочного профиля и цилиндрическим валом из нержавейки в подшипниках. Был правда момент когда он поднял подвес и попытался с ним улететь.
nikita6776
Расскажите про подвесы. Можно ссылку, где про них можно почитать? Самому не получается найти.
Riketta
Для коптеров не видел, а самолеты вот на таких штуках тестирует Nicholas Rehm. Ну на первом можно и коптер зафиксировать, пример не найду, но вроде все понятно.
Hidden text