Comments 45
А это перегружает сенсоры вибрациями, снижая их точность.
А вы пробовали добавить фильтрацию данных гироскопа до подачи на вход ПИД-регулятора? Существующие популярные прошивки полетных контроллеров квадрокоптров (betaflight, inav итп) используют различные фильтры и их комбинации:
Low-pass filter/Фильтр низких частот: отсекает выскоеи частоты шума
Notch filter/Полосовой фильтр
Dynamic notch: notch фильтр, частота которого выбирается автоматически как частота наиболее "громкой" гармоники шума
RPM-filter: фильтр из betaflight, который с помощью протокола bidirectional DSHOT получает от регуляторов двигателей их текущие обороты и применяет динамический notch фильтр на частоте, соответствующей скорости вращения двигателей
Matrix filter: фильтр из inav, по-сути dynamic notch, который применяет notch фильтр каждой оси для всех остальных (yaw, pitch, roll), что позволяет учитывать взаимное влияние шумов по разным осям
Фильтр Калмана (в inav называется unicorn filter)
Помимо этого, есть отдельно фильтр (вроде low-pass) по D-компоненте ПИД-регулятора.
в MPU-9250 (сенсор который я использую тут) есть несколько режимов low-pass фильтра для гироскопа и акселерометра, я выбрал режим 3 для обоих (даже добавил в свою приложуху возможность на ходу переключать эти режимы), так что они фильтруются в какой-то степени. Затем использовал complementary filter, объединяя интегрированные показания гироскопа (нешумные, но подверженные накоплению погрешностей) и акселерометра (шумные, но точные) в соотношении 999 к 1 (тоже добавил в приложуху возможность это на ходу менять). И только потом уже этот угол контролируется PID контроллером. Но тем не менее этого недостаточно, если пропеллеры сильно вибрируют, я прямо заметил колоссальную разницу невооруженным глазом до и после того, как отбалансировал их.
Понятно, спасибо.
Насколько я знаю, у гоночных/фристайл квадрокотперов пропеллеры не балансируют (это осталось в прошлом), а требования к шумам там довольно высокие, потому что фильтры увеличивают задержку.
К сожалению, я не знаю, как там реализован режим стабилизации, я использовал только т.н. acro mode, т.е. стабилизация только угловых скоростей по гироскопу. И я бы не сказал, что он нешумный, как раз на гироскоп вешают программные фильтры, помимо встроенного в сенсор. Кстати о сенсорах, почему-то (вроде, наименее шумный и менее подверженный помехам) самым лучшим сенсором для квадов считается MPU-6000.
Очень много усилий потрачено ради достижения цели, вы молодец.
Какой следующий шаг? следопыт, который будет следовать за вами во время покатушек на байке? :)
супер) только правда можно было взять привычные компоненты или даже современный полетник и накатать свою прошивку раз так хочется сделать самому)
но ведь в существующих контроллерах полета есть один фатальный недостаток ) да и я это делал больше ради процесса и скила, который мне пригодится при создании чего-то менее типичного, чем квадрокоптер)
Хорошая работа. И приземление эпичное )))))
хм:
float seconds_elapsed = u_seconds_elapsed / 1000000.f;
так понимаю шаг считывания информации с датчиков, да и работы всей системы управления не фиксирован? Так обычно не делают, ибо все коэф. цифровых фильтров плавать будут, да и вся система управления с плавающим шагом тоже ни к чему хорошему не приведет.
В моем интуитивном представлении, чем быстрее пройдет итерация тем лучше, например точнее сынтегрируется угловая скорость гироскопа в угол. А с фиксированным временем итерации мне бы пришлось взять какой-то запас времени, например на случай, если произойдет коммуникация с другим модулем или еще какие-то нерегулярные для основного цикла действия. Но я подумаю над тем что вы говорите
…чем быстрее пройдет итерация тем лучше…
Подберите минимальновозможный фиксированный шаг, и с ним работайте.
Для есп32 и мпу9250 у меня вышло 2мс (только акс. и гироскоп).
А с фиксированным временем итерации мне бы пришлось взять какой-то запас времени, например на случай, если произойдет коммуникация с другим модулем или еще какие-то нерегулярные для основного цикла действия.
Автопилот - система жесткого реального времени, тут никаких если, весь обмен с датчиками и исполнительными механизмами, а так же вычисления - должны быть жестко расписаны во времени.
Да, вместо того чтобы биться об уже решённые проблемы - лучше почитать код Betaflight/Inav/Arducopter и посмотреть как сделано там.
В Бете точно фиксированный цикл, в Айнав недавно вроде бы сделали некий плавающий, но он по моему работает в режиме 'быстрее Х герц если возможно, но не медленнее'
Кстати, если занимаетесь чем-то подобным, не делайте тех же ошибок и не
используйте художественные 3д-редакторы для дизайна механических частей,
а лучше потратьте пару дней на освоение какого-нибудь параметрического
3д-редактора, поскольку он гораздо лучше подойдет для вещей с четкими
размерами и формами.
Какие есть бесплатные альтернативы?
В блендере делаю модели для 3д печати, сталкиваюсь с некоторыми недостатками, но пока ничего принципиально усложняющего работу не было. Если активно использовать модификаторы, то, как мне кажется, можно и в нём достаточно "параметрическую" модель собрать. И ещё есть привязка вершин к координатной сетке и к другим вершинам, для квадратных моделей с точностью размеров никаких проблем нет.
Я примерно догадываюсь, почему ESP32 для сенсоров, но выбор Raspberry, как основной платформы... как-то не совсем понятно. ESP, по моему опыту, вполне справляются с расчетами.
Контроль удержания позиции у меня сделан с помощью камеры, да и в дальнейшем планирую добавлять другие фичи, опирающиеся на компьютерное зрение. Конечная цель - автономный дрон, а не радиоуправляемый, и esp будет для этого недостаточно
ESP с OpenCV неплохо стыкуются, модули ESP32 с камерой встроенной есть, можно воткнуть несколько штук, плюс их можно легко состыковывать и масштабировать. А Raspberry большая, тяжёлая и дорогая - по цене одной RpI4/8 можно взять штук сорок ESP32 cam.
Другое дело, если малина уже есть, другой не планируется и коммерческие перспективы не интересны.
А можете пояснить, в чем конкретно была проблема с УЗ датчиками? Делаю похожий проект, только на RPi zero w и RP2040. С учетом фильтрации выбросов расстояние измеряется ~ до 3 метров, с небольшой погрешностью.
когда пропеллеры не крутились, то у меня тоже до 3х метров определялось расстояние, но когда они работали, у меня сенсор переставал видеть(слышать) дальше 40см, из-за турбулентности под дроном скорее всего, а может из-за помех в питании, но я чет не стал разбираться, и поменял его на лазерный в итоге и все нормально стало
Меня в лидаре смутила более короткая дистанция, т.к. коптер мной тоже задумывался автономным - хотелось выжать максимум из доступного. С отсутствием слышимости, связанного с винтами, не столкнулся - возможно, из-за другого расположения датчиков (у меня их 6 штук, по одному с каждой стороны), а может быть просто больше повезло. О такой возможности я изначально даже не задумывался, поэтому меня это удивило при прочтении статьи. Надеюсь будет продолжение, т.к. интересно сравнить ваши решения с моими. Например, я проблему с удержанием позиции решил как раз с помощью УЗ датчиков и GPS, а камера используется для распознавания кустов и деревьев от которых стоит держаться подальше.
Я использую vl53l1x и у него вроде как дальность 4м, то есть такая же как и у УЗ сенсора. Вообще на большой высоте я думаю барометр использовать. А по поводу GPS, я его тоже планирую использовать, когда он доступен (на открытом пространстве то есть), а для остальных ситуаций использовать камеру для удержания позиции. А какая у вас модель GPS модуля, кстати? (у меня ublox neo m8n, я вот не знаю достаточная ли у него частота обновления и точность для этой цели)
У меня используется neo 6m. Частоты обновления хватает, а вот точность временами оставляет желать лучшего, зависит от того сколько спутников видит. Для полета от точке к точке обычно достаточно, а для удержания позиции дополнительно опираюсь на показания с УЗ датчиков. В условиях города и внутри помещений такой способ дает не плохие результаты, а вот на природе, где от УЗ информация не поступает и позиционирование выполняется только по GPS - "рысканье" гораздо выше, доходит вплоть до полетов кругами, с радиусом около метра, вокруг заданной точки. Пока оставил так, в будущем буду думать как улучшить это поведение. Возможно модуль придется поменять на какой-либо другой. Сейчас основная задача перенести всю работу с датчиками и двигателями на RP2040.
по-новичковски и пока не оптимально, но лучше эти велосипеды пройти самому. Очень хорошо, что довел до рабочего состояния. Если все еще интересно, то можно уже переписать правильно.
Под капотом у ESP32-arduino - ESP-IDF и FreeRTOS. FreeRTOS можно использовать прямо из ардуино.
Есть ещё проект Дрона на GitHub с приложениями для android и iOS.
Молодец. Очень четко видно, что проделана огромная работа. Сам уже год, как подсел на похожий сценарий. Правда меня больше интересуют тема дронов самолетного типа.
Как говорит моя бабушка: «Детей пора тебе завести»))
Очень интересный материал, спасибо.
У нас есть стартап, находящийся в ранней стадии разработки системы спасения дронов с использованием AI. Было бы интересно с Вами пообщаться - может быть есть поле для сотрудничества.
Как с Вами можно связаться?
Владимир
Есть вот такие jоптические датчики движения: https://shop.pimoroni.com/products/pmw3901-optical-flow-sensor-breakout?variant=27869870358611
Их можно использовать для стабилизации дрона в горизонтальной плоскости.
Я тут дилетант, но почему не взять больше гироскопов и усреднять их значения для стабилизации положения дрона?
Если дрон не получает команду, то в какое положение он возвращается/поддерживает?
Испытания на местности уже проводились? Как планируете решать проблему сдувания дрона ветром? Что будет для дрона опорной точкой, если GPS мотает дрон по радиус 1м? В какой-то момент дрон просто удрейфует в дальние дали, если будете опираться только на GPS.
На винты подумайте защиту лопастей. Китайцы кажется сетку какую-то используют.
Не нагнетаю, просто вот такие вопросы появились.
…но почему не взять больше гироскопов и усреднять их значения…
а смысл? усреднение ошибки от одинаковых источников на выходе даст ту же ошибку.
Что будет для дрона опорной точкой, если GPS мотает дрон по радиус 1м? В какой-то момент дрон просто удрейфует в дальние дали, если будете опираться только на GPS.
При работающем GPS - не удрейфует, т.к. мотается именно позиция получаемая от GPS приемника.
Крутейшая штука. Это ж если продолжить, то можно сделать полную навигацию дрона по картинке с камеры - с высоты в несколько сотен метров изображение уже можно сравнивать со спутниковыми снимками того же гугла или Яндекса, строя опорные точки по ним, игнорируя GPS.
Такой дрон может весело кружить над Кремлём, ибо заглушить его получится только картечью.
… можно сравнивать со спутниковыми снимками … строя опорные точки по ним, игнорируя GPS.
Оптическое поле контраста местности летом/зимой/осенью/весной разное. Какое из этих времен года на снимках? Не говоря уже о том что снимки которые в общем доступе 2-3 годичной давности. Так что в теории - можно, а на практике без свежего снимка получается фигня.
А вот только что как раз опубликовали интересную статью с актуальными снимками.
Да и у Яндекса/Гугла для популярных мест / крупных городов снимки, как правило, вполне себе свежие.
Если допустить, что в интересующем районе не ведётся каких-то постоянных изменений, то основные опорные точки - дороги, силуэты домов - можно будет нормально использовать. Вопрос в том, как правильно изображения обработать и что оставить для привязки.
На будущее: рисуем на крыше дома дорогу/маскируем её под лес - со стороны ничего не меняется, а визуальная навигация дрона ломается.
PID это, конечно, хорошо, но если бы AI и нейросети - было бы ещё интереснее.
Вот что значит по настоящему талантливый разработчик. Жизнь пропадает в вебе, а мог бы творить чудеса
Как я делаю дрон из Raspberry Pi и ESP32 (или мои первые шаги в робототехнике)