TechnoWorks
Компания
27,03
рейтинг
3 апреля 2014 в 00:32

Разное → Автономный квадрокоптер с нуля: PID и грабли

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

Один из тестовых полётов нашего коптера

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

Определение автономности
Автономность определяется относительно поставленной задачи. Если задача в том, чтобы робот следовал заданным изначально координатам GPS (допустим, огибая препятствия на своём пути), то под автономностью мы понимаем самостоятельное принятие решений роботом с момента получения маршрута и задания. Автономность на более высоком уровне — это, например, самостоятельный выбор маршрута при «патрулировании» некоторой территории. Начальными данными будет информация об этой территории.


ПИД


Простейшая задача стабилизации — контролировать угол наклона, но из законов динамики вращательного движения следует, что непосредственно управлять можно лишь его второй производной. Самый легкий способ повлиять на нужную величину — использовать ПИД.


MEMS — в нашем случае это гироскоп, акселерометр и магнитометр; DMP — Digital Motion Processor; ESC — контроллер оборотов бесколлекторных моторов.

На вход регулятора подаётся обобщённая координата (в нашем случае угол), на выходе мы получаем момент сил (вторая производная угла). Каждый ПИД-регулятор стабилизирует значение одной обобщённой координаты. Мы используем три ПИД с постоянными коэффициентами, по одному на каждый угол Таита-Брайана.

Матчасть


Определим невязку — разницу между требуемым и реальным значением некоторой величины:

 — требуемое значение величины (угол с джойстика),
 — текущее значение величины (угол с датчика).

Зададим момент сил для угла в текущий момент времени:

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

В чём смысл этой формулы? Напишем уравнение динамики, положив .


 — момент инерции.

Для простоты уберём интегральную составляющую (). После переобозначения коэффициентов получим уравнение затухающих колебаний относительно :


где


Т. е. чем больше пропорциональная составляющая, тем более «резкой» будет реакция на воздействие (больше амплитуда). Чем больше дифференциальная составляющая, тем быстрее будет происходить затухание (больше декремент).

Из модели затухающих колебаний получаем выражение для коэффициента затухания:



Из возможных решений уравнения нам подходит режим, близкий к критическому (граница апериодичности, ) — нет отрицательного «перелёта» графика, переходный процесс короткий. Как видно, критический режим задается всего одним соотношением на коэффициенты ПИД-регулятора.

Интегральная составляющая устраняет статическую ошибку. Пусть невязка невелика и постоянна, тогда дифференциальная составляющая нулевая, а пропорциональная может быть настолько мала, что для её учёта не хватит точности ESC. В этом случае коптер не будет стремиться к требуемому положению. Но если суммировать малые отклонения , то через какое-то конечное время суммарного отклонения будет достаточно, чтобы компенсировать статическую ошибку. Коэффициент определяет это время: чем больше значение коэффициента, тем раньше система начинает учитывать нарастающую погрешность. При этом слишком большая интегральная составляющая приводит к автоколебаниям.

Более подробный анализ уравнения ПИД-регулятора можно найти в других статьях: раз, два.

Первая авария


Слишком большая дифференциальная составляющая на практике приводит к автоколебаниям, чего не должно быть в теории. Почему? Уберём все составляющие, кроме дифференциальной, и решим уравнение:

 — экспонента, никаких колебаний!

Причина такого эффекта в большом времени реакции системы (и вообще из-за того, что оно ненулевое). Из-за сдвига фаз, вызванного задержкой системы, аргумент функции получает некоторый декремент:



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


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

Компромиссом является установка не слишком маленьких коэффициентов в совокупности с введением ограничения сверху на все три составляющие: пропорциональную, интегральную и дифференциальную.

Стоит сказать, что реальная коррекция в почти горизонтальном положении — около 1–2 попугаев процентов мощности моторов (полётная мощность около 60%).


Рассмотрим решение уравнения второго порядка (1), которое в одном из случаев является затухающей синусоидой.

На практике действительно получается что-то похожее (пример справа). Для демонстрации коэффициенты специально ухудшены для увеличения времени затухания. Оригинальную прошивку ESC пришлось заменить, т. к. она вносила существенную задержку, из-за которой математическая модель плохо описывала реальную систему.


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

Калибровка ПИД


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



Для углов и мы подвешивали его за противоположную тестируемой ось, а для угла мы использовали 4 верёвки, симметрично закрепленные на раме недалеко от её центра.

Хотя такой подход не самый эффективный (мы не знаем «срок годности» коэффициентов количественно и считаем их константами), на практике задача стабилизации коптера в полёте была нами решена. Правда, возникла проблема с управлением, но об этом позднее.

Величины, от которых зависит поведение аппарата
Мы получили экспериментальное подтверждение того, что коэффициенты ПИД-регулятора существенно зависят от внутренних факторов системы. В будущем есть смысл провести ряд опытов по выявлению зависимости коэффициентов от следующих факторов.
Внутренние факторы
Параметры пропеллеров (диаметр X шаг) Чем больше пропеллеры, тем плавнее поведение коптера
Размеры коптера (расстояние между центром рамы и осями моторов) Чем больше размеры, тем плавнее поведение коптера
Масса полностью укомплектованного коптера Чем выше масса, тем плавнее поведение коптера
Заряд аккумулятора (Вольтаж) Чем выше заряд, тем более динамичное поведение потенциально достижимо у коптера

Внешние факторы
Температура воздуха
Чем теплее воздух, тем ниже плотность. Как следствие, плавность повышается
Атмосферное давление Чем больше давление, тем выше плотность. Как следствие, плавность понижается
Относительная влажность воздуха
Чем больше влажность, тем выше давление водяного пара (и плотность воздуха). Как следствие, плавность понижается
Cила ветра в терминах модели
Модуль -члена ПИД прямо пропорционален постоянной составляющей силы ветра. Переменная составляющая силы ветра влияет на — и -составляющие



Грабли


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

С одной стороны, существует минимальная мощность, которую уменьшить нельзя, или моторы просто остановятся. С другой, уменьшение мощности может быть необходимо для правильной работы алгоритма. Если мощность (throttle) уменьшить слишком сильно, ПИД может «зашкаливать» в нижнюю сторону. Чтобы решить эту проблему, мы ограничиваем доступные пилоту мощности.


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

Третий подводный камень в том, что применение интегрального члена ПИД может помешать при взлёте с наклонной поверхности. Составляющая накапливается ещё до взлёта, и уже в воздухе аппарат испытывает перекос в обратную сторону. Лишь после пары секунд, за которые коптер успевает набрать существенную линейную скорость, интегральная составляющая уменьшается до значений, приемлемых для полёта. Чтобы решить эту проблему, можно включать интегральную составляющую только после того, как тяга моторов достигнет взлётного значения (около 50% от максимума), при этом коптер уже оказывается оторванным от земли.

Программное обеспечение


На рисунке приведена упрощённая блок-схема программы, исполняемой на контроллере платы стабилизации. Главной частью является цикл. Если хотя бы одно действие в нём не выполняется вовремя, частота перестаёт быть постоянной, и стабилизация работает неверно.

В качестве динамического датчика мы использовали MPU-6050 из-за его вычислительных возможностей. Встроенный процессор (DMP) способен частично обрабатывать данные с датчиков, что позволяет разгрузить центральный контроллер. Но оказалось, что надёжных библиотек для работы с этим устройством под Arduino не существует. Решение jrowberg'а привело к проблемам при использовании на сильно загруженном микроконтроллере. Код в примере опирается на синхронность считывания данных. FIFO-буфер датчика, в который записываются посчитанные величины, переполняется в случае несвоевременного считывания. Поскольку всегда считывается первый элемент из FIFO, то при частичной заполненности появляется задержка между помещением новых данных в FIFO и их обработкой на Arduino. В свою очередь, эта задержка приводит к возникновению автоколебаний. При переполнении буфер приходится очищать: его размер 1024, что не делится на 42 — размер пакета. Поэтому, когда буфер переполняется, в начале FIFO находится часть какого-то постороннего пакета. Иными словами, начиная с определенного момента структура нарушается: начало FIFO не совпадает с началом пакета, и считать корректные данные невозможно.

Кроме этого, понадобилось изменить в библиотеке формулу для преобразования «кватернион ↦ углы» для того, чтобы результат был из полного диапазона углов. Подробности этой проблемы описаны на трекере проекта: https://github.com/it-workshop/Quadrocopter/issues/18.

Бортовая электроника


Основной компонент, который мы разрабатывали самостоятельно, — плата стабилизации. Изначально она была основана на платформе Arduino Uno, потом заменили на более мощную Due, что позволило увеличить частоту ПИД-регуляторов с 40Гц до 66.(6)Гц.

Пропеллеры коптера приводятся в движение компактными бесколлекторными двигателями в связке со стандартными контроллерами оборотов — ESC. Мы используем ESC с изменённой прошивкой.

Подробнее об ESC
Стандарт контроллеров ESC использует в качестве управляющего сигнала меандр, управляющим параметром является скважность. В нашем случае сигнал с пульта ДУ изначально получает контроллер стабилизации, который на выходе вынужденно генерирует требуемый для ESC сигнал. Если отказаться от подобного интерфейса (ШИМ), из-за которого приходится преобразовывать дополнительные данные, можно уменьшить время отклика системы. Но проектирование собственного контроллера двигателей — отдельная задача, которая нами пока не рассматривалась.


Для питания всей системы используется литий-полимерный аккумулятор (3S). Из соображений безопасности мы решили сделать систему мониторинга напряжения на аккумуляторе. В штатном режиме использования аккумуляторов система ведёт себя достаточно стабильно. Однако на начальных этапах работы мы наблюдали эффекты, вызванные неоптимальным использованием батарей:
  • Вздувшиеся аккумуляторы. Причина в перезаряде и длительном хранении разряженных аккумуляторов. Производители рекомендуют не разряжать силовые аккумуляторы ниже значения 3,3В на каждую банку батареи, что в нашем случае даёт минимальное допустимое напряжение в 9,9В.
  • Выключение моторов при низком напряжении. Это особенность реакции большинства прошивок ESC на низкое напряжение, которая может привести к серьёзной аварии — в первый момент выключается только один мотор, остальные продолжают работать.


Для наших целей ESC было решено перепрограммировать. Благодаря использованию прошивки tgy (от SimonK) мы добились уменьшения задержки системы на пути от центрального контроллера до двигателей. В результате компоненты ПИД и угловая скорость стали более синусоидальными, а поведение всей системы приблизилось к поведению математической модели.

Для измерения динамических параметров используются следующие датчики:
  • 6-осевой акселерометр-гироскоп InvenSense MPU-6050
  • 3-осевой компас Honeywell HMC5883L


Телеметрия


Дистанционное управление реализовано в двух режимах (для обеспечения более гибкого процесса разработки):
  1. С помощью модулей xBee Pro в конфигурации «коптер  ПК».
  2. С помощью выделенной радиочастоты (2.4ГГц) в конфигурации «пульт ДУ ↦ коптер».


Помимо управления через пульт ДУ происходит пересылка критических данных между коптером и ПК в режиме реального времени, для чего используются xBee Pro и приложение собственной разработки (см. скриншот). На компьютере можно видеть значение углов и угловой скорости, напряжение на аккумуляторе, мощность двигателей. Возможно настраивать коэффициенты ПИД в режиме реального времени. Программа сохраняет все поступающие данные и поддерживает последующее воспроизведение записанных файлов, что помогает при отладке. В случае ЧП мы можем остановить моторы с компьютера.



Данные, пересылаемые между коптером и ПК:
  • ПК ↦ Коптер: канал управления (ПК/пульт ДУ), мощность моторов, настройка для включения/выключения стабилизации, коэффициенты ПИД и ограничения;
  • Коптер ↦ ПК: углы, угловая скорость, компоненты , , , данные с джойстика (мощность + 3 угла), мощности моторов, напряжение на аккумуляторе.


Благодаря датчику от InvenSense, начальная обработка данных с датчиков происходит на встроенном процессоре (DMP). Мы разгружаем плату стабилизации, которая может использовать в качестве вычислителя даже маломощный AVR-микроконтроллер.

Воспроизводимость результатов

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

Код проекта: github.com/it-workshop/Quadrocopter/tree/MPU-6050-Compass (распространяется на условиях лицензии MIT).

Дополнительная инфа про то, из чего мы делали наш коптер и каков был бюджет
Дизайн рамы сильно влияет на полётные характеристики. Поэксперементировав с материалами, пришли к следующему.
  • Пенопластовый каркас позволяет построить крайне лёгкую, но не жесткую систему. У коптера появляется существенная парусность. Из этого материала есть смысл делать небольшие системы (микрокоптеры), которые будут летать в помещении.
  • Каркас из фанерных ферм — наименее удачное решение. Много времени на сборку из-за большого числа мелких деталей. Жёсткость системы можно обеспечить с помощью дополнительной проклейки узлов рамы, но тогда она становится неразборной. Надёжная рама получается массивной и обладает заметной парусностью. Прочность низкая, обычно после жёсткой посадки нужно хорошо проклеивать трещины или менять несущие детали. Из плюсов стоит отметить крайне низкую цену.
  • Один из самых удачных материалов — алюминий. Мы использовали популярную модель X-525. Жёсткость достаточно высока, раму можно повредить разве что в результате серьёзной аварии. Парусность и масса — оптимально низкие. Недостаток — неустранимый небольшой люфт в местах сочленений деталей рамы.
  • Композитное углеволокно обладает крайне высокой прочностью при довольно низкой плотности. Мы использовали модель Talon. Поскольку карбон крайне сложно обрабатывать без специального оборудования, пришлось заказывать готовые детали и применять их без каких-либо модификаций. Из-за того, что связующие узлы в карбоновых каркасах обычно выполнены из пластика или алюминия, на стыках образуются сложные для юстировки места, т. е. возникают частые проблемы при работе с круглым карбоновым профилем: плохая соосность двигателей и люфт в точках соединения.


Список деталей
Компонент Цена Количество Ссылка
Рама Talon 1100 руб. 1 HobbyKing
Аккумулятор 3S, 11.1V 475 руб. 1 HobbyKing
Пропеллеры 10x4.5, 10x4.5R 150 руб. 4 ToyHobby
Моторы Turnigy Brushless 330 руб. 4 HobbyKing
ESC 290 руб. 4 HobbyKing
Пульт ДУ 2.4GHz, 4 канала, с ресивером 875 руб. 1 HobbyKing
Arduino Due 2590 руб. 1 amperka.ru
Arduino Wireless Shield 790 руб. 1 amperka.ru
Датчик InvenSence 6050 2335 руб. 1 www.lawicel-shop.se
Цифровой компас HMC5883L 1290 руб. 1 amperka.ru
XBee Pro 2290 руб. 2 amperka.ru
Антенна для xBee Pro 704 руб. 2 wifimag.ru
Итого 18523 руб.


Направления для развития


  • Процесс тестирования системы стабилизации можно упростить, используя более совершенный стенд. Верёвочный вариант — скорее одноразовое решение, более подходящим был бы жёсткий карданов подвес с тремя степенями свободы.
  • Существуют методики автоматизации подбора коэффициентов ПИД-регулятора. Например, основанные на двоичном поиске (метод ветвей и границ). В нашем проекте коэффициенты подбирались вручную.
  • Приложение для ПК, используемое для мониторинга и управления, было бы удобнее использовать на планшетном компьютере. В планах портировать приложение на Android или IOS.


Итоги


Главное достижение — отличная команда энтузиастов, способных работать над сложными робототехническими проектами. Мы верим, что всё дело в творческом подходе, возможности для самореализации, а также бесценном практическом опыте, которого всегда не хватает.

Мы создали новый проект системы стабилизации для мультикоптеров. Сейчас мы можем пилотировать квадрокоптер на открытом пространстве. Такие внешние факторы, как ветер, дождь и снег компенсируются автоматически благодаря ПИД-регулятору.

В настоящий момент мы усовершенствуем то, что сделали, и разрабатываем новые функции автоматизации.

Полёт коптера с нашей системой стабилизации


лето 2013.


зима 2014.


весна 2014

О нас


Мы — студенты МФТИ (в своём большинстве), которые в свободное время занимаются проектом на мастерской TechnoWorks. Кроме коптера у нас живут и другие проекты: железные и программные. О них мы расскажем как-нибудь потом. А еще у нас можно придумать и реализовать свою идею (а мы поможем найти людей).

Если есть желание присоединиться к нашей команде, свяжитесь с нами! Мастерская активно расширяется, для новых участников у нас полно творческой и технической работы. И печенек.

technoworks.ru
Автор: @alexac
TechnoWorks
рейтинг 27,03
Компания прекратила активность на сайте
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Комментарии (54)

  • +2
    Мне кажется или серийный бюджетный dji phantom всё-таки значительно более стабилен?

    В любом случае такое глубокое погружение в предмет — это всегда похвально. Удачи вам в развитии проекта!
    • +2
      Да, наша система стабилизации только приближается к «продуктовым» решениям. Надеемся, что этим летом получится это изменить.
      Спасибо за напутствие!
      • +2
        Но сейчас же существуют открытые проекты софта для квадрокоптеров, может быть стоит направить силы туда, а не пытаться догнать и перегнать? Зависать на месте и держаться в одной точке умеют даже дешевые китайские квадрики.
        • 0
          Присоединяюсь в предложению. Какой смысл разрабатывать свою систему с нуля, если можно воспользоваться существующими наработками. Тот же MultiWii, например?
          • +1
            Смысл, например, такой, чтобы знать, как оно работает.
  • +15
    Впечатляющее видео с демонстрацией возможностей квадов.

    • +4
      И возможностей ИК камер и серверов, обсчитывающих кучу данных.
  • –4
    человеческий фактор — причина большинства аварий
    Ручное управление еще очень долго будет превосходить автоматическое.
    Для примера мое видео: (мозги dji naza lite, режим atti)

    • +4
      Тут палка о двух концах ) Смогли бы вы вручную повторить, например, то, что показано в видео в предыдущем комментарии? :)
      И не забывайте, без «мозгов» вы бы не смогли так полетать, да и вообще вряд ли смогли квадрокоптер поднять в воздух: основная часть работы все же приходится на «мозги» квадрокоптера, а вы уже даете высокоуровневые команды.
      С развитием сенсоров, автоматический полет, подобно вашему, не будет проблемой. Другое дело, это будет не интересно )
      • +1
        Кстати, видео в предыдущем комментарии демонстрирует систему стабилизации с использованием внешней камеры. В лабораторных условиях коптеры и жонглировать умеют, но стационарная камера и внешний компьютер сильно ограничивают область применения.
        • +2
          Вот появятся 3d сканеры местности с обработкой в реальном времени, тогда можно выходить из теплиц )
          • +1
            Вы умудрились отгадать направление, в котором мы сейчас начинаем развивать проект. Похоже, что эта идея буквально витает в воздухе.
            • 0
              Она не летает в воздухе… Реализацию с носимым 3D сканером (кинект/лидар, не в курсе) в MIT видео показывали еще года 3 назад.
              Не самое впечатляющее видео

              Не могу быстро найти видео, где квадрик летал по лабиринту с лидаров в поисках кнопки и попутно строил 3D карту «местности».
    • +1
      Для того, чтобы человек так управлял коптером, всё равно нужен опыт. В индустрии, на мой взгляд, более важны решения «из коробки». Пусть даже следующие несколько лет автоматика будет туповатой.
      Но видео потрясающее, это раньше не видел.
      • 0
        Ещё важно, чтоб пилот не отвлекался и не «зарулился». Это как с автопилотом в автомобилях: в теории, у автопилота и реакция лучше, он не устаёт, не отвлекается на телефонные звонки, способен видеть то, что не видит человек, но все же развитие техники, а именно развитие «сенсорики» тут немного отстает.
        • +2
          Да, вопросами, честно говоря, отвлекают. Надо такую носить:
          image
          • +3
            Мой вариант:
            1. Нет, в детстве я наигрался.
            2. Да, далеко
            3. Настолько же, настоколько далеко (отдельно спрашивают про дальность и высоту)
            4. На электричестве.
            5. На 15 минут
    • +5
      Вы летаете под проводами и над головами людей и гордитесь этим? А что будете делать, когда коптер таки заденет ветку или провод и приземлится лучём в голову водителя мопеда?
    • +1
      Я не понимаю, чем вы хвастаетесь. Безусловно у вас есть выработанные навыки пилотирования квадром. Но летать в густонаселенных районах, в том числе над проезжей частью через провода, растительность считаю абсолютной халатностью. Сколько весит ваш квадрокоптер?

      UPD #1: Я всегда буду обновлять комментарии перед постингом.
      • +1
        Посмотрите на все комментарии этого автора, похоже что он рекламирует свой сайт и полеты на TBS квадрике.
  • +13
    Очень здорово, что вы решили делать с нуля, то что вы так разобрались в реализации. Но тогда совсем непонятен выбор аппаратной платформы.
    Зачем плодить очередную ардуиноподелку, когда вы все равно начали разбираться с этой темой с нуля? Возьмите более подходящий контроллер, те же DSPшные STMки, нормальную микросхему мемс от них же, в которой сразу интегрированы компас, аксель и гиро.
    Поставьте туда Фри-РТОС, который откроет широчайшие возможности по реализации ваших задумок по автономности.
    И у вас будет продукт, который изначально более интересен и оригинален, чем сотни поделок на ардуине — зачем же добровольно выбирать позицию «догоняющих», жаться на каждом байте, чтобы «разгрузить процессор», совершенно не подходящий для этой задачи и совершенно не оправданный.

    Искренне надеюсь, что ваш проект пойдет в этом направлении и-таки вырастет в автономного дрона с нормальной РТОС на борту и с нормальным ДСП-железом, у него есть все шансы.
    • +1
      Полностью поддерживаю, кроме одного, а нужна ли там ОС? Задачи же примитивнейшие, но требуют минимальных задержек, операционная система тут не нужна совершенно. Для решения задач автономности систему нужно разбить на два вычислителя. Первый будет выполнять задачи положения аппарата в пространстве и его выравнивания, вывод аппарата на заданные координаты, обработку датчиков, а уж второй может медленно рассчитывать координаты, строить маршрутный лист и так далее, уж в нем можно и ОС использовать.

      И к автору поста, мне кажется у вас допущена ошибка в реализации ПИД регулятора. По сути при вычислении углов эйлера вы интегрируете данные с гироскопов и корректируете их уход по акселерометрам/магнитным датчикам. Интегрирование — это всегда накопление ошибок. Потом, в самом ПИД регуляторе, а именно в демпфирующем звене вы дифференцируете теже самые углы эйлера, тем самым опять добавляете ошибку. Зачем? Ведь гироскоп у вас уже сам по себе датчик скорости, не надо добавлять ошибку к нему и ещё задерживать его, сразу умножайте его сигнал на коэффициент и подавайте сумматор.
      • 0
        Про архитектуры я с вами согласен. Скорее всего, когда дойдёт до следования по маршрутам, будем применять 2 вычислителя.

        Насчёт ПИД-регулятора: в реализации используем как раз показания с гироскопа (когда нужна угловая скорость):
        Поскольку D-составляющая пропорциональна угловой скорости, можно прийти к мысли подавать на вход регулятора показания гироскопа вместо того, чтобы применять дискретную разностную схему.
        • 0
          Тогда извиняюсь, в статье не увидел, а на схемах на пид идут только углы эйлера. А не считали задержку между ступенькой на датчиках и установившемся сигналом момента на двигатели? По опыту программирования гироплатформы для камеры могу сказать что несколько милисекунд уже много.
      • +1
        ОС нужна чтобы код не превращался в, извините, говно.
        FreeRTOS дает необходимый минимум, при этом практически не влияя на задержки, самые критичные части могут вообще работать параллельно с системой, она на них не будет иметь влияния. При этом это полноценная ОСРВ, все задержки предсказуемы.
        Поверьте, код задач РТОС намного приятнее читать, поддерживать и отлаживать, нежели код, в котором то же самое реализовано своими велосипедами и костылями — а именно переключение между задачами по средством всяких флагов в интерраптах, синхронизация глобальными переменными и прочим.
      • 0
        Если они сейчас на «Ардуино» летают, то на чипах STM32 они получат в несколько раз большие частоты и скорость обработки самих команд в 1 такт вместо нескольких. Можно легко операционку влепить, тем более, RTOS — системы реального времени, когда по событию можно остановить всё, и запустить нужный блок. Но учитывая избыточную мощность, это вряд ли понадобится.
  • +4
    Что у всех последнее время за желание сделать еще одну свою «прошивку» для ардуинки чтобы коптер хотя бы как нибудь летал?
    Круто конечно что разобрались в теме стабилизации (я вот до сих пор на это смотрю как на магию, понимая только примерно как работает). Но, судя по видео, ваш коптер не догнал по стабильности даже самые старые версии MultiWii, не говоря уже про ArduCopter.
    Делать сегодня на AVR полностью автономные системы стабилизации — так себе затея, только ради just4fun для себя и в образвательных целях. Ниша AVR давно занята и из ардуинки в то же ArduCopter уже наверное максимум вытянули, а теперь 2 ветки (AVR и ARM) начинают разделяться, например в ARM (pixhawk) версии обещают EKF, инерциалку крутую, улучшеную автоподстройку ПИДов и т.д.
    • 0
      На самом деле, коптер мы начали делать несколько лет назад, когда кучи готовых решений еще не существовало. Но делаем мы его в свободное от работы/учебы/жизни время, поэтому получается достаточно медленно (и только в последнее время работу над ним удалось ускорить). Из-за этого сейчас действительно кажется, что это очередной велосипед на ардуине. Несколько лет назад мы посчитали что это платформа, которая отлично подойдет для прототипа, а после посчитали, что переделывать под другую платформу нет смысла, пока не определимся с требованиями к ней, а значит надо сначала заставить относительно стабильно работать эту.

      Ведь смена платформы потенциально ведет к переписыванию тучи кода, отвечающего за взаимодействие с железом. Портируя код, можно насажать новых багов. Чем более отлаженным будет высокоуровневый код, тем проще будет портировать его на новую платформу.
      • +1
        В ArduCopter ввели такое понятие как HAL (Hardware Abstract Layer), который как раз отвязывает (на сколько это возможно) логику прошивки от железа, на котором это реализуется. Если есть силы и возможности, прошу, не делайте еще один контроллер+прошивку, а помогите нынешним проектам, тем более что наконец то начался приличный переломный момент ухода от AVR.
        • 0
          Это, конечно, хорошо, но мы точно лучше знаем свою платформу и реализацию взаимодействия железа в ней, чем чужую. Когда отладим высокоуровневую логику, переключиться, если захотим, будет просто, и это не будет включать в себя постоянных сомнений из серии «кто же всё-таки виноват?».

          Планы к переходу есть, но делать его чисто из-за любви к пуризму нам кажется, на данном этапе развития проекта, неразумным.
          • 0
            Ваш проект — ваше право, просто судя по всем «начинателям своего» на форуме мультироторном, реально довели до конца всего один проект (и довольно успешно, но человек никак себя не показывал, а сразу вылез с офигенно летающей и всё умеющей машиной). А писателей прошивок каждую весну вылезает штук по 10-15, но от висения уровня старого multiwii мало кто уходил, хотя планы были по захвату мира.
            • 0
              Я кажется, даже знаю, о ком вы говорите.

              У нас основные скачки в разработке происходят ежегодно внутри двухнедельной летней сессии. Посмотрим, что будет в середине августа. Планов по захвату мира мы не ставим, но это как получится
        • +1
          HAL впервые реализовали ОпенПилоты :) жаль что они уже 2 раза раскололись и темпы разработки сейчас даже хуже чем раньше :(
          а ведь EKF у них был еще пару лет назад
  • +1
    Товарищи спасибо запост. Сам занимаюсь данной тематикой в научном плане. Но я иду по пути arm и «нечутких Калманов». Пока плата изготавливается, там свои ещё косяки, решил поиграться с arduino. И мне кажется или она не способна считать данные с 8 датчиков (MEMS) и передать по uart со скоростью 38400 или опрашиваю датчики слишком часто. Вообщем появляются какие-то всплески с непонятным интервалом. которые на несколько порядков превышают допустимые.

    • 0
      Мы сталкивались с подобной проблемы (и частично ее описали в посте). В общем случае, не зная какие у вас конкретно датчики, ничего сказать не получится, но думаю, что etoestja сможет рассказать что-то подробнее на эту тему.
      • 0
        имеется ввиду абзац с fifo? В плане железа, mpu 9150+HMC5883L+adxl345+l3g4200d+bmp085 и arduino Uno. А etoestja написать можно?
        • +1
          Да я про проблемы с fifo в mpu.

          Теоретически ему должны сыпаться письма об упоминаниях, скорее всего он включится в тред, когда будет свободнее. Отправил вам в личку информацию о том, как с ним связаться.
    • 0
      Наверняка у вас есть на примете ссылочка, где можно быстро и в общих словах прочитать и понять, кто это такие — нечуткие калманы и для чего применяются? :-) Их вы применяете для фильтрации гироскопов и акселей, или еще они как-то могут быть применены вместо PID-регуляторов?
      • 0
        Не уверен что совсем о том что имел ввиду автор коментария, но вот неплохая ссылка:
        Вместо ПИДов фильтр Калмана не применяется — он нужен для более точного определения состояния системы, чтобы уже потом, с помощью тех же ПИДов это состояние регулировать.
  • 0
    Первое видео — это в лагере под Дубной?
    • 0
      Да, лагерь Волга. Там проходит Летняя школа, в которой наша мастерская принимает активное участие.
      • 0
        Я знаю, что летняя школа была от РР, Гриша Тарасевич, вот это всё, а теперь она расширалсь на естественные науки? Или это какая-то другая?
        • 0
          это та самая Летняя Школа. TechnoWorks будет проходить в её рамках уже четвертый год. Журналисты и Гриша на ЛШ появились не сразу, изначально там были физики, медики и социологи. Сейчас направлений около тридцати, включая поведенческую экономику и нейролингвистику.
          • 0
            Летняя школа РР проводилась в Максатихе под Тверью и существует больше четырёх лет.
            • 0
              Летняя Школа проводилась и в Максатихе, и в деревнях Рождество, Ручки и некоторых других. Сейчас заключен договор с Объединенным институтом ядерных исследований и школа проходит на базе «Волга» под Дубной, принадлежащей ОИЯИ. И существует она больше десяти лет, каждый год список мастерских меняется. TechnoWorks принимает в ней участие четвертый год.
              letnyayashkola.org/about/history/
  • 0
    Техника безопасности для трусов? Летать на кустарном прототипе над детьми, конечно, смело, но очень глупо. Не говоря уже о том, чтобы настраивать на верёвке в маленькой комнате с людьми.
    • +1
      Начиная такой проект «в гараже» очень сложно сразу создать обстановку, в которой вся работа будет проводиться по-уму. Так что изначально техника безопасности имела не максимальный приоритет. Но сейчас, после нескольких опасных аварий, мы пересматриваем нашу позицию. Начинаем выделять на безопасность определённую часть бюджета, разрабатываем чек-листы для пилота и т. д. К сожалению, некоторые угрозы трудно устранимы: в той же Москве найти хорошую площадку без деревьев, столбов и детей довольно сложно.
      • +1
        Знакомая ситуация. В Лондоне сегодня уже не полетать именно из-за аварий. И спасибо ребятам из Discovery, которым очень хотелось полетать вокруг Big Ben. Сейчас обычно еду на поезде пол часа и потом ещё 15 минут на велосипеде, чтобы полетать. Или час на машине.

        Такие дела, не совершайте ту же ошибку в Москве.
  • 0
    Скажите, а с чем связана частота регуляции 66 Гц?
    На сколько мне известно, MPU6050 умеет отдавать обработанные данные с частотой 100 гц. Можно даже увеличить до 200, но, говорят, будут слишком шумные показания. Неужели цикл обработки не влез в 10 мсек?
    • +1
      Действительно цикл обработки не влез, подозреваем, что у нас есть серьезный баг в общении с компом, возможно сможем со временем улучшить этот показатель.
  • 0
    А как у вас организовано вычисление углов? Именно на этапе между данными с датчиков и ПИДом — используются ли показания всех датчиков и потом «сшиваются»/«усредняются» в некое финальное значение (фильтром Калмана или каким-то другим способом) или же берутся показания одного из датчиков, акселерометра например?
    • 0
      Мы использовали интегрированный датчик InvenSence MPU-6050, который по показаниям акселерометра, гироскопа и магнитометра вычисляет кватернион движения на встроенном примитивном процессоре (DMP). Это помогло нам разгрузить Arduino, которая может быть даже не Due (на ARM), а Uno (AVR 16MHz). Так что в нашем случае работы с фильтрами вообще не было — фактически готовые координаты мы получаем с самого датчика. Подозреваю, что внутри MPU-6050 сырые данные фильтруются для устранения дребезга.
      • 0
        Аа, это многое объясняет: и цену датчика, и ардуину… Жаль, ведь можно было бюджетнее и академичнее подойти ;)
        Спасибо!
  • 0
    Спасибо за статью! И за верные формулы для углов Эйлера отдельное спасибо! :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное