Комментарии 130
ты не пробовал для отладки дрона делать подвижный подвес?
Серьезный подвес я собирать на пробовал, но я пытался отладить стабилизацию, подвешивая его на нитях. Итог: это очень неудобно и бесполезно. С подвесом отлаживать можно, да.
Подвес обязательно делать делать и уж точно не из ниток. У вас маленький дрон и его отладка безопасна, а когда отлаживаешь дроны от 7 дюймов, то очень опасно. Мы для начала сделали одноосный подвес с жестким креплением и регулируемым противовесом. Можно быстро собрать из станочного профиля и цилиндрическим валом из нержавейки в подшипниках. Был правда момент когда он поднял подвес и попытался с ним улететь.
Расскажите про подвесы. Можно ссылку, где про них можно почитать? Самому не получается найти.
Для коптеров не видел, а самолеты вот на таких штуках тестирует Nicholas Rehm. Ну на первом можно и коптер зафиксировать, пример не найду, но вроде все понятно.
Hidden text
Наблюдаю за проектом с момента появления телеграмм канала. Код и в правду весьма понятный, и не пугает своей сложностью как другие мейнстримные прошивки. ТАУ под капотом выглядит не сложно, и не подумал бы что это всё заняло 4 года, хотя область эта конечно для моего понимания непростая. Подумываю над тем чтобы собрать этот дрон как только у меня разгрузится расписание. Есть мысль попробовать сделать вклад в проект добавив поддержку ELRS.
Конкретно этот алгоритм это не рокет-сайенс и 4 года занял не он :). А безуспешные попытки его отладки, чтобы заставить дрон стабильно летать, и последующие за ними забрасывания проекта.
Помню на какой-то конференции говорили, что "в релиз выходит одна строка в день". То есть строчишь целый год, тестишь/фиксишь/коммитишь и через год смотришь на гит, а там 3 сотни строк.
Это, естественно, не касается крудов и json-манипуляций - там хоть каждый день талмуды выдавай.
Elrs же научили претворяться sbus. Так что всё должно заработать и так
Для ELRS и CRSF уже есть много готовых библиотек, например вот эта: https://github.com/BobbyIndustries/crsfSerial. Для ESP32 подключается легко.
Здорово! продолжение интересно. Как раз не спешно смотрю что бы повторить для новичка не сильно затратное что бы пощупать эту тему.
Отличный проект! Взяли в обучение в МАИ :) Ждем продолжения!
Несколько вопросов:
1) У Вас используется одно ядро ESP32?
2) На сколько загружен процессор, занята флеш используется RAM ?
3) Сколько потребляют двигатели и блок управления в % ?
4) Какое общее энергопотребление в полете?
5) Какая дальность управления?
6) Какой вес и полезная нагрузка?
7) можно ли в вашем симуляторе отлаживать блоки управления на других процессорах?
Спасибо
Сразу предупрежу, что цель создания дрона была не побить рекорды, а образовательная, но тем не менее:
1. Полетный код использует одно ядро. Но насколько я знаю, Wi-Fi в ESP32 использует второе.
2. Честно говоря, не проверял, предположу, что существенное время итерации он просто ждет данных с IMU. Без поддержки Wi-Fi прошивка занимает 25% флеша, с поддержкой — 59%. Статически используется порядка 30% RAM, сколько используется в процессе работы — не проверял.
3. Не совсем понял вопрос. Каждый мотор потребляет порядка 2 А, остальное — это мелочь.
4. Не измерял, могу прикинуть, что точно до 10 А.
5. Это зависит от приемника и пульта, у тех, что я использую, думаю, достаточно большая, по крайней мере я в помещениях не отлетал настолько далеко, а вне помещения я не летал.
6. Дрон весит ~60 г, максимальная суммарная тяга пропеллеров ~120 г, соответственно, поднять кроме себя он может очень мало чего.
Может быть в учебных целях сделать на ESP-12E ?
Будет еще проще.
ESP8266 все-таки менее мощный, чем ESP32.
Ну я и говорю, что ESP8266 хватит с запасом, судя по Вашему ответу. Кроме того, код будет еще проще.
----------------
Посмотрел Ваш код. Вы не используете таймеры, а делаете цикл. Т е зря грузите процессор.
Весь полетный код намеренно помещен в Arduino'вский loop, чтобы он проще воспринимался людьми, знакомыми с Arduino. Однако это не значит, что он обязательно будет зря грузить процессор — функция ожидания данных с IMU вполне может и освобождать поток, пока новые данные не появятся. Это реализуемо средствами FreeRTOS, которая и рулит потоками в ESP32 (и в ESP8266).
Вы же не для многоядерного процессора пишите.
RTOS здесь избыточна.
Можно все сделать проще и быстрее.
Делал подобное : гироскоп+магнитометр+акселерометр+измеритель расстояния TOF+синтезатор речи на ESP8266 и все исполняется с запасом.
Но Вы автор, поэтому спорить не буду.
Вы же не для многоядерного процессора пишите.
RTOS здесь избыточна.
ESP32 двухъядерный. 2. RTOS там почти без вариантов. Контроллер плохо документирован на том уровне который позволил бы отказаться от использования FreeRTOS.
RTOS здесь избыточна.
"ты видишь суслика?" оно там в любом случае есть.
на ESP8266 и все исполняется с запасом.
Там на всё 80кб рамы, из которых в лучшем случае отъест WiFi и прочий Arduino framework
... ESP8266 хватит с запасом ...
У 8266 i2c - программный. Чую очень весело будет опрашивать датчики с частотой 1кГц, одновременно руля вайфаем.
wifi на esp8266 все подвешивает, не получится
Один ESP8266 выше крыши.
Все делается очень просто.
Настраивается таймер на 1 кГц.
При этом процессор свободен или что-то считает в это время.
По прерыванию таймера опрашиваем по I2C со скоростью до 1MГц.
Датчики можно опрашивать по готовности.
Если надо SPI то со скоростью до 8 MГц (DMA)
----------
Можете посчитать сколько на это уйдет времени.
У Вас нет роутера при работе с БПЛА. Максимум точка доступа на смартфоне. Я бы вообще использовал протокол ESPNow.
Ничто ничего не тормозит.
Я делаю опрос датчиков на голом металле, если надо WiFi ,то включаю радио блок .
Все получается до безобразия просто.
Вообще самый корректный и эффективный вариант это использовать пин IMU, который выдает сигнал, когда появляются новые данные, для пробуждения МК по прерыванию. Просто это как-то сильно сложнее, и не уверен, что целесообразно для такого проекта, как у меня.
Впрочем, вполне возможно, что я перейду на такой вариант.
для пробуждения МК по прерыванию.
Зачем усыплять контроллер? Он хоть и от батарейки питается, но расходует ее пренебрежимо мало по сравнению с моторами.
И при работе WiFi могут быть сюрпризы с прерываниями (они используются для работы WiFi)
Чтобы отдавать CPU на другие таски, которые могут выполяться параллельно (если их добавить).
В "серьезных" полетных контроллерах, как правило, для чтения IMU все же используется прерывание.
Вы писали про пробуждение (из сна). Вот я и не понял зачем нужен режим сна? Это не просто пустой цикл, а специальный режим, отключающий определенные блоки MCU. Нужен в основном для экономии энергии.
Про прерывания все правильно - нужно работать по ним. Таймер - прежде всего. Если внешние модули поддерживают прерывания по готовности данных, то и их использовать
Но если таска одна, тогда да, нет никакой значимой разницы между засыпанием и просто циклом.
Речь таки про 8266, у него свои прибабахи, это совсем не stm32.
По прерыванию таймера опрашиваем по I2C со скоростью до 1MГц.
У esp8266 i2c реализовано программно, скорость - до 100кГц.
Тут правда я упустил, imu висит на spi (не знаю почему, но думал что на i2c).
Датчики можно опрашивать по готовности.
А как готовность определить? А, опросить датчик, через spi, i2c, ну или ногу выделить под прерывание (если она есть).
С ногами у 8266 отдельная беда - их мало, примерно с 10 под нужды пользователя.
При этом процессор свободен или что-то считает в это время.
Вот тут вторая особенность esp8266 - у него нет аппаратной поддержки плавающей точки.
В общем мое мнение - на 8266 если это возможно реализовать, то уж сильно теоретически. Данная реализация потребует очень сильной оптимизации, и код будет совсем не на адурине.
У Вас нет роутера при работе с БПЛА. Максимум точка доступа на смартфоне. Я бы вообще использовал протокол ESPNow.
Какой нафиг ESPNow на смартфоне?
Если используете ESPNow, то на смартфоне не точка доступа, а модуль ESP, подключенный через USB.
Достоинство протокола ESPNow в скорости передачи команд на БПЛА , так как не требуется установления соединения.
Соединение устанавливается один раз, а дальше скорость передачи не отличается. ESPNow хорошо в случае передачи данных от малопотребляющих и хорошо спящих устройств. Что в данном случае не наблюдается. Зато предлагается лишнее устройство, которое надо еще как-то интегрировать в программу-пульт на смартфоне.
Один раз, это если в эфире нет никого. Но реально будут потери пакетов и восстановление связи. А это займет не одну секунду.
Кроме того разница в формате пакетов и в алгоритмах обработки.
Wifi имеет смысл лишь для видео и для полетов по комнате, ну или на небольшую дальность, т е для игрушек.
Если у вас эфир настолько засран, что будут потери, то ESPNow ничем не поможет, поскольку работает на том же железе и на тех же частотах, и дальность связи точно такая же. Разница в пакетах на прикладном уровне заключается исключительно в меньшем максимальном размере данных для espnow
Вы очевидно теоретик.
Я практик, тестил оба протокола WiFi и ESPNow по обмену данными. ESPNow всегда выигрывает по скорости передачи.
--------------
еще вы ошибаетесь по затратам на подключение. У Вас будет одно подключение к точке доступа. Но потом будут разрывы в передачах пакетов если это TCP и повтор передачи. Быстрее работает UDP, но это Вас тоже не устроит, потери тоже будут.
тогда это ничем не отличается от lora
Что конкретно проще? Если по размерам, есть варианты ESP32 сопоставимые с ESP8266.
Думаю, что в плане оптимизации чего-либо стоит обратить внимание на варианты с LoraWan или Zegbee, они жрут меньше энергии, чем Wi-Fi
К слову, если код переписать без Arduino Core, то это тоже положительно скажется на энергосбережении.
Проще писать на Си, проще 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.
Проще писать на Си, проще nonOS, чем RTOS.
Меньше размеры модуля, меньше потребление, меньше греется.
Но если очень хочется, то можно и ESP32 оставить.
Как раз только один вариант с ESP8266 и остаётся, т.к. поддержки под ESP32 у производителя нет. Да и зачем мучаться, это не сравнение Python vs C, даже если и будет разница, то в десятки килобайт, это не серьезно.
Если с ардуино уйдете на СИ для ESP32, то будете долго писать и не факт что отладите.
Как раз под nonOS такое возможно, а на родном ESP-IDF я отлаживал :)
В таких системах реального времени ничего ждать не надо, в IMU есть проверка на готовность данных, если данных нет, то пропускаем и обрабатываем цикл дальше.
Задался я как то раз целью вращать коллекторный двигатель с подключенным энкодером так, чтобы максимально точно возвращать его и уметь возвращать ровно на заданное число оборотов. И тоже стал решать эту задачу с нуля. И что я могу сказать - без тестирования кода, наверно у меня бы ушло на решение этой задачи год. Хотя казалось бы, что тут сложного, нужно лишь в точное время включить двигатель и в точное выключить, а потом проделать тоже самое только обратно. Но есть нюанс.
После того как мне удалось отделить бизнес логику, которая крутилась на ардуино отделить в отдельную библиотеку, дело стронулось с места. Эта библиотека была покрыта тестами, которые поражали своей извращенность. Но в реальности такое ведь может произойти. В реальности датчик может начать выдавать данные которые для него не характерны. Так было в нескольких авариях с самолетами, когда самолет задирал нос, терял скрость и падал штопором. Почему такое произошло? Потому что датчик тангажа начинал врать.
Поэтому главный принцип бизнес логики - не верю никому. Чуть что-то начало присылать странные данные - используем дефолтные значения или переходим к плану Б. Чуть что-то пошло не так - падача питания на двигатель есть а движения энкодера нет - все выключить с выводом ошибки.
Сами сигналы с датчиком можно легко записать в логи и потом покрытть тестами и эти данные. Тогда сразу будет видно - вообще живой ли датчик. Адекватные ли данные он присылает.
Калибровка - тоже не маловажная часть любого подобного проекта. Если нужно то можно делать ее каждый раз перед запуском. Что-то можно откалибровать уже находу.
Короткая 3х секундная программа калибровки уже ввоздухе смоглабы много узнать о реальных показателях коптера. 3 секунды для микрокомпьютера просто бездна времени для сбора данных и их анализа.
Ну и конечно основа основ - юнит тесты! Без них очень сложно сделать поистени сложные вещи. Ардуина или будь то STM32 просто принимает данные с датчиков и передает их в бизнеслогику. Бизнес логика обрабатывает данные и выдает уровни газа для моторов. Безнес логика пакуется в отедельную библиотеку и покрывается юнит тестами. В таких тестах мы можем легко эмулировать перемещение во времени и показания самих датчиков. В идиальных условиях Бизнес логика должны на любые эти изменения уметь реагировать и делать то что нужно.
ardupilot то наверное тоже с 100 строчек начинался, а потом .. както все понеслось
Можно встроить это:
Некоторые модули ExpressLRS TX включают дополнительный чип ESP8285, который позволяет осуществлять беспроводную связь с другими устройствами с поддержкой ESP8285, используя протокол под названием espnow. Цель TX-Backpack - обеспечить беспроводную связь между EXPRESSLR и другими устройствами, связанными с FPV, для командования и управления или для запроса конфигурации.
Основным вариантом использования является модуль видеоприемника (или VRX). В настоящее время существует не так много модулей VRX, в которые встроен ESP8285, позволяющий им взаимодействовать с EXPRESSLR, поэтому в большинстве случаев вам нужно добавить свой собственный. Небольшой приемник на базе ESP можно “подключить” к вашему модулю VRX, что позволяет ExpressLRS управлять диапазоном и каналом, на которые настроены ваши очки.
В большинстве модулей ESP8285 (как правило на приемнике) или ESP32 используется как контроллер и реализуют логику, например FHSS. А за радиочасть отвечают микросхемы типа SX1276 которые подключены к микроконтроллеру по SPI.
Дополню, не только SX1276, но и SX128X (2.4 ГГц). Эти чипы используются для передачи команд и телеметрии по протоколу LoRa.
Интересное решение ESP8285(8266)+SX1280(81) .
На SX1280(81) реализуется не только LoRa, но и BLE.
В итоге получаем три протокола WiFi,LoRa,BLE, а в действительности еще и протокол FLRC. При этом токи потребление примерно в 3 раза меньше, чем с ESP32. Дальность управления по протоколу LoRa может составлять десятки км.
Дополнительно SX1280 позволяет измерить расстояние до дрона.
Про измерение расстояния не знал, очень интересно. Уже нашел материалы, почитал как это реализовано.
А такой вопрос - ими можно как-то сканировать радиоэфир?
Можно. SX12xx это приемник и передатчик с изменяемой частотой настройки и 3 вида модуляции. Все управление прием-передача делается на внешнем MCU. Можно это совместить с полетным контроллером.
SX1280(1281):
вопрос только в скорости сканирования
На SX1280(81) реализуется не только LoRa, но и BLE.
Ну что GFSK там есть это да, но что на ней прям BLE кто то сделал? или там все таки свой формат пакета
Есть вариант, но я не проверял.
я тут припомнил что ble хитрыми путями можно и nrf24 заставить работать, делать можно всякое, но че то активно этим никто не пользуется
это было актуально лет 15 назад. Сейчас есть дешевые модули BLE (Telink) , в которых фактически nrf24+MCU+SRAM+FLASH и все это за 2$.
Т е весь контроллер полета на модуле 1.5x2 см2
начать тогда надо с nrf24le который тоже +MCU+SRAM+FLASH, да и кучку всяких других модулей и плат nrf24+mcu, реторический вопрос в том что на них можно сделать (не)хорошего. клавиатуры/мышки им иммитировали, дрон сделали, управление сценическим светом довольно популярная тема, а вот про ble не слыхал кроме одного эксперимента.
Главная проблема разработки прошивки для квадрокоптера — это крайне сложная отладка летающего аппарата.
В свое время решил эту проблему сборкой стенда, который обеспечивал натяжение рыболовной лески вертикально на высоту 1.5 метра. Леска продавалась в отверстие печатной платы квадрика мах ближе к геометрическому центру квадрика так, чтобы она была мах равноудалена от всех винтов и как можно меньше влияла на движение квадрика. Это позволило отлаживать ориентацию квадрика в пространстве и его вертикальные перемещения, избежав полетов "в стену/в потолок" в процессе отладки.
4 года, три из которых ты ждал детальки с алиэкспресса
Дроном можно управлять с телефона, но будет ли работать вообще без DF500?
Можно ли использовать модули esp32-cam?
Странный у вас лоупасс фильтр. Он, конечно, сглаживает сигнал, но имхо искажает сильно. Я б делал как среднее значение на нескольких семплах
Такой тип low-pass фильтрации это не мое изобретение. Он описан очень много где (например), в том числе известно, как переводить cut-off frequency в smoothing constant α.
Это не самый точный тип low-pass фильтра, но зато самый простой.
Интересный проект. Желаю ему оставаться таким простым и понятным(код не читал, но что угодно понятнее бетафлайта).
Небольшой IMHO. Если бы я сейчас загорелся идеей собрать коптер по вашему проекту, то мне было бы проще найти 4 БК мотора и 4в1 esc на 25й стек, чем паять транзисторы на макетку.
По поводу печатной рамы. Уже видели проект nanoLongRange?
Есть такой проект https://espcopter.com/
Тоже все думал собрать на esp32 но так руки и не дошли.
Завидую вам.
Да, это я видел, правда уже после того, как разработал свой. Но этот дрон, насколько я понимаю, не претендует на простой и наглядный исходный код, который можно использовать в качестве учебного пособия. Его код даже не опубликован на GitHub а распространяется просто в виде ZIP-архива.
Тем не менее выглядит интересно.
Ошибаетесь. Есть на гитхабе. Если мне память не изменяет я там на него и наткнулся изначально.
https://github.com/verlab/espcopter
Ну а развивается именно для обучения детей
Но да я не могу сказать что там красиво в плане кода. )
Это я нашел, но там последний коммит 5 лет назад. В ZIP-архиве файлов намного больше. Не думаю, что это официальный репозиторий этого проекта.
Возможно, я давно уже не заглядывал к ним. Просто в памяти отложилось и иногда инста подкидывает их посты посмотреть.
Вы не подумайте я не пытаюсь что-то доказать) Я очень завидую тому что вам такое удалось и с удовольствием буду наблюдать за развитием. Может мой малой подрастет и мы с ним вместе накатим ваш код на очередную уже esp64)
Блин, думаю про простой код и появляется желание портануть его на C# и nanoframework. Тоже чисто в исследовательских целях.
Замечательный проект! Читатели, не поленитесь, зайдите на гитхаб поставьте звезду.
Открытая, понятная, легко модифицируемая прошивка для всех видов моделей - https://github.com/nickrehm/dRehmFlight/ (https://www.youtube.com/@NicholasRehm).
Отличный вариант для прототипов необычных моделей (VTOL, трикоптеры, модели с лидарами и другими необычными сенсорами, экранопланы, модели на гидрофойлах и т.д. - смотрите ютуб канал автора), образовательных целей и "поиграться".
В том числе он подробно и с примерами кода рассказывает как работает флайтконтроллер в нескольких своих видео.
Круто! Молодец! Я тоже когда-то разрабатывал свой "полётник" - IMU сделал, потом аппарат разбил и все это дело забросил. В моём IMU я экспериментировал с алгоритмами "sensor fusion" - обьединение данных с массива однородных датчиков (4 гиро, 4 акселя и 2 магнитометра подключенных к STM32F4) с целью уменьшения собственной ошибки датчиков. У меня не плохо работал алгоритм Махони с небольшими доработками. Какой алгоритм рассчета IMU используется у Вас ?
У меня используется самый простой комплементарный фильтр, который объединяет один гироскоп и один акселерометр, этого, в принципе достаточно для полета. Но при желании можно добавить и другие датчики, поскольку по сути это взвешенная сумма значений.
Не хватает барометра для поддержания высоты
Через какое время накопленная ошибка становится существенной?
Накопленная ошибка из-за интегрирования гироскопа, вы имеете в виду? Поскольку есть калибровка, то не очень быстро, 5-10 минут, может.
Это же сравнимо с полетным временем? Как это скомпенсировать?
В полетных прошивках, где есть estimation позиции, например, при помощи GPS, есть способы при помощи позиции скорректировать ориентацию.
Если есть только акселерометр и гироскоп — то идеально никак. Но можно принять, что пилот скорее всего будет пилотировать дрон так, что в среднем он будет в нейтральной ориентации. И подмешивать нейтральную ориентацию с маленьким весом. Тогда ориентация не уплывет.
Интересный опыт! Желаю проекту развития, хотелось бы наблюдать за ним и дальше.
Для разработки можно ещё можно попробовать использовать SITL/HITL (Software/Hardware In The Loop). Для примера https://github.com/iNavFlight/inav/discussions/9246 https://github.com/RomanLut/INAV-X-Plane-HITL
Глубокое уважение и признательность за проект и статью -- на фоне копроблогов и менеджерских рассказов о прекрасном будущем эта статья как глоток воздуха старого доброго Хабра.
Круто, спасибо!
Было б здорово, если б вы оставили проект в состоянии учебника, не навешивая на него дополнительных "фишек", чтоб можно было в нём разбираться или использовать как базу для своих контроллеров.
Да, я пытаюсь так и сделать. Потому что есть много идей, чего можно было бы добавить, но что сильно усложнит код. Возможно, стоит разделить проекта на две части? "Базовая часть", только с текущими функциями, и "практико-ориентированная" часть со всем фаршем?
Мне очень сильно помог вот такой проект: https://www.youtube.com/@carbonaeronautics
Там и гитхаб есть с простым учебным кодом и сама книга: https://github.com/CarbonAeronautics?tab=repositories
Можно и так, при условии, что в базовой части не придётся делать какие-то изменения, чтобы работала "практико-ориентированная"...
Ну, то есть, на мой взгляд хорошая практика если части кода по максимуму независимы от других.
Олег, такое уточнение. То, что вы называете режимом ACRO на самом деле не ACRO. Изучая различные материалы, я заметил, что это общее заблуждение. В коде реализована простая стабилизация угловой скорости или еще называют режим RATE или RATE_CONTROL.
В теории он должен работать как режим ACRO, т.е. увеличиваю джойстик по тангажу, квадрокоптер начинает вращаться, уменьшаю – он остается в заданном угле пока обратным движением джойстика не заставлю вращаться в обратном направлении. Но на практике дрон ведет себя по-другому.
Как я понял, режим ACRO должен еще отслеживать установленный угол после возврата джойстика в 0, т.е. это тот же режим ANGLE, только изменение угла происходит не джойстиком, а джойстик меняет угловую скорость вращения квадрокоптера.
Интересное уточнение. Вообще я не изучал подробно, как в других полетных контроллерах реализован режим ACRO. Возможно, это разнится от прошивки к прошивке.
В целом, этот нюанс, наверное, очень важен для пилотов, которые летают в ACRO, но с точки зрения понимания полетного алгоритма он не столь значим. Полетный режим ACRO у меня добавлен лишь для иллюстрации идеи полетных режимов и по умолчанию отключен. Я ни разу не пробовал в нем летать.
Вот ведь люди химичат. Весь мой опыт работы с ESP32 ограничен созданием rgb-подсветки в туалет с датчиком движения
Спасибо автору! Я на таком же железе лодку на радиоуправлении собираю. Утяну пару строчек кода, а статью положил в закладки.
Стучись пообщаться. Я над своей наземкой на мавлинке год тружусь. Может будет полезно пообщаться
Экстендед типа аварийной посадки при разряженной батарее планируется добавлять?
Этот дрон все же сделан на базе прошивки Crazyflie, так что не представляет собой чего-то сильно нового в плане софта.
This code was partially based on Multiwii/Baseflight sourcecode
И что?
Читаем далее:
"Этот код был частично основан на исходных кодах Multiwii / Baseflight, но адаптирован для конкретных датчиков и функциональных возможностей, необходимых в этом проекте. Код управления полетом использует RTOS для поддержания постоянного времени выборки PID-сигнала, обеспечивая при этом возможность непрерывного приема радиочастотных управляющих сигналов. "
и далее...
Текущие поддерживаемые функции:
Режим Acro (стабилизация только с помощью гироскопа)
Удержание высоты
Для базового управления ориентацией и высотой контроллер полета работает с 6DOF IMU и барометром. Плата, используемая в этой конструкции, использует BMX055 или MPU6050 для ориентации и MS5611 для определения высоты.
Для питания BLDC и ESC требуется LiPo аккумулятор. Он был протестирован на батарее 3S емкостью 5200 мАч, но способен поддерживать работу от батарей 2S.
Пользовательский интерфейс
Плата имеет несколько вариантов подключения, включая WiFi, BLE и радиочастотный протокол 950 МГц. Для Wi-Fi и BLE Blynk использовался в качестве телефонного интерфейса для управления высотой и ориентацией. Для радиочастотного протокола 950 МГц был разработан пользовательский пульт дистанционного управления.
Очень здорово. Чем проще и меньше код - тем он лучше :)
Интересная тема. Тоже реализовал на дешевых, доступных запчастях, с простым кодом калибровки и прочим. 20dbm приемо передатчик встроенный. Параметры можно менять в приложении. Интересно ваше мнение: GitHub, fademike, fly_drone.
Благодаря вам решил чем займусь в отпуске. Спасибо!
Как я разработал квадрокоптер на ESP32 с нуля (ушло 4 года)