Search in topic

MultiWii - обсуждаем и отлаживаем Alt Hold

Ну он же всегда проваливается при наклоне и начале движения, и всегда подпрыгивает при остановке. Есть какая-то закономерность, обусловленная физикой.

Спорный вопрос - во первых, два набора пидов усложнят настройку. А во вторых, сонар не всегда точен, и в некоторых условиях может очень сильно лажать… Вот почему его также надо корректировать ускорением:

Я это не сам придумал.
Коррекция газа от угла наклона введена в Арду 2.0 давно.

Два набора Пидов в Арду были более года еще в ArducopterNG. Можно летать и на одном - но тогда с сонаром больше плавать будет по высоте. Это проверено. Если на настройках сонара летать по баро излишне дергается.

Корректировать сонар по акселерометру - простым алгоритмом не обойдешся. Там проще отбрасывать некорректные результаты измерений.

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

Но намного легче будет с хорошим баро. При высокой частоте измерений и меньшем уровне шума его легче фильтровать, а медленный дрейф баро можно компенсировать измерениями по сонару - при желании, но алгоритм оценки достоверности и пригодности для коррекции тоже вопрос не тривиальный. Если на поле, то просто, а если на горбатой местности-? 😃

как я уже писал, мысль-идея-решение витает в воздухе в параллели… www.multiwii.com/forum/viewto...3&p=8871#p8840

• еще один рабочий алгоритм www.multiwii.com/forum/viewtopic.php?f=7&t=363&sta…
  BMP085

MS5611

-Самое главное - он СТАБИЛЕН. Т.е. он ни разу за время облета 4-х паков не приложился об землю и не улетел выше 4-х метров.

Результат очень хороший. Я приятно удивлен. Я не верил, что из 085 можно такое выжать.
Мне в прошлом году времени для дотошного изучения баро не хватило (были более интересные проблемы). В этом году вернулся к баро, но уже с MS5611. Судя по результатам на столе с MS5611 получится. Но я поражен Вашими результатами с 085. Я думаю , что китайцев с NAZA вы уже догнали.

Был бы благлдарен,если бы Вы расписали математику, но без привлечения векторов. Не в обиду и скалярного произведения нет там.
Свои результаты я выше привел. Код полностью в соседней теме "High end Low cost Quatrocopter"Саму стабилизацию по высоте чуть позже добавлю в программу.До этого при стабилизации по высоте я использовал газ висения, но на этой платформе нужен алгоритм как его измерять. В Арду просто, там есть лог и полетавши берутся данные из лога. Использовать значение газа в момент переключения не очень здорово. Каждый раз аппарат точно вывешивать хлопотно.
​
А дальше появляется любопытная возможность повозится и с горизонтальной составляющей акселерометра и компенсировать воздействия от порывов ветра и прочее.

Результат очень хороший. Я приятно удивлен. Я не верил, что из 085 можно такое выжать

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

Был бы благлдарен,если бы Вы расписали математику, но без привлечения векторов. Не в обиду и скалярного произведения нет там

Без векторов я не смогу объяснить 😦 В коде “в лоб” взято определение скалярного произведения и длины вектора (из википедии)

(accADC[0]*EstG.V.X + accADC[1]*EstG.V.Y + accADC[2]*EstG.V.Z) *  InvSqrt(fsq(EstG.V.X) + fsq(EstG.V.Y) + fsq(EstG.V.Z),  

что соответсвует A_B_projection = (Ax*Bx + Ay*By + Az*Bz)/sqrt(Bx*Bx + By*By + Bz*Bz)

Каждый раз аппарат точно вывешивать хлопотно.

Точное вывешивание не нужно, можно при любом газе включить удержание. Разница будет только во времени стабилизации PID-регулятором.

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

А дальше появляется любопытная возможность повозится и с горизонтальной составляющей акселерометра и компенсировать воздействия от порывов ветра и прочее.

Я уже пробовал, результаты тут: www.multiwii.com/forum/viewtopic.php?f=7&t=685
Тогда у меня было чуть меньше опыта, но со своим выводом в конце темы согласен и теперь.

еще один рабочий алгоритм www.multiwii.com/forum/viewto...start=90#p8876

Занятно, человек вообще отказался от акселерометра 😃 Сразу предположу, что он не сможет выставить более-менее рабочий PID, т.к. D-часть брать неоткуда. Судя по видео, у него стоит очень слабый PID, и вряд ли он удержит коптер реалных ситуациях.

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

Опять таки все просто. Ставится ограничение на Пид регулятор (у меня +(100-150) -(40-60) мкс. И высоту держит точно и не подпрыгивает особо. Но газ при этом точно выставлять нужно.
По І составляющей ±30 мкс.

Предлагаете ограничивать управляющее воздействие (то есть коррекцию газа)? Не выход, мне кажется… Иначе регулятор будет работать в нерасчетном режиме. И регулятору нужна свобода действий, особено сильному и быстрому 😃

К посту rcopen.com/forum/f123/topic265409/28 - не могли бы вы побьольше комментариев расставлять? Самое главное в нашем общении тут не код, а идеи. И константы лучше выносить в #define и обзывать осмысленными именами и подписывать, чтобы проще было понять потом логику и физический смысл алгоритма.

Предлагаете ограничивать управляющее воздействие (то есть коррекцию газа)? Не выход, мне кажется… Иначе регулятор будет работать в нерасчетном режиме. И регулятору нужна свобода действий, особено сильному и быстрому 😃

К посту rcopen.com/forum/f123/topic265409/28 - не могли бы вы побьольше комментариев расставлять? Самое главное в нашем общении тут не код, а идеи. И константы лучше выносить в #define и обзывать осмысленными именами и подписывать, чтобы проще было понять потом логику и физический смысл алгоритма.

Просто указываю диапазон изменения длительности управляющего импульса на регулятор в микросекундах. У нас разные программы и я пытаюсь свести к сравнимым величинам.
В части свободы регулятора . Без ограничения у меня не получалось получить жесткое удержание без болтанки и быстрое достижение заданной высоты.

И вопрос - EstG.V.Z -это проекция G на ось Z.

Уже есть пара идей насчет улучшения. Сейчас явно не хватает силы PID-регулятору высоты

высадил кучу паков на выходных… при П более 2-х начинает колбасить вверх вниз, т.е. можно смело уменшать делитель в ПИД регуле…

Hекоторые идеи по улучшению:

1. пробовал добавлять ПД регуль по скорости… Точнее Д из ПИД по высоте переехал в П по скорости (что одно и тоже) + в качестве Д по скорости взял ускорение как описывал выше + поставил деадбенд на ПД +/20, но не просто обрубил значения менее 20-ти, а с вычитанием в 20, если ПД более 20-ти (т.е. смещение значений к ценру… типа как вишном ролл/питч деадбенде на аппу)… шум сразу пропал, что отлично и при довольно высоких коэф. чувствительность ПД регулятора не падает…
   Далее занулял ПИ по высоте, а ПД по скорости брал довольно агрессивными. При рывке вверх и движении с вертикалной скоростью 1-2м/с практически мгновенно (~0.5сек) тормозит коптер при активировании альт-холд… но при движенни вниз результат немного хуже. Это скорее всего из-за явной нелинейности моего акселя по оси Z (+128/-152)…
   За счет ускорения поднимается фронт скорости, а также получяется более крутой спад. В отрицателную часть уходит лишь немного в конце… так что можно смело исползовать ускорение, тем более что ускорение гораздо меньше шумит в сравнении со скоростью…

где зеленым-скорость, синим-ускорение, красным-сумма.

для демо: вниз рукой получалось протолкнуть макс. на 40-50см! Также думаю это даст огромный плюс при порывах ветра…

2. т.к. “быстрые” составляющие (ускорение и скорость) высчитываются из акселя, думаю можно смело уменьшать частоту алт-холд интегратора/эстиматора и отталкиваться от частоты среза ФНЧ акселерометра. Теоритически конечно чем выше самплинг raw данных с акселя, тем точнее будут показания скорости после интегратора, но при этом придется поднять ФНЧ (к примеру с 20гц на 50 гц), чтобы не получать усредненные raw данные с акселя и не делать “пустых” вычислений. НО с поднятием частоты среза получим чвствительность к вибро. И результат будет только хуже как в алт холд, так и стаб/левел моде.
   Золотая середина тут на мой взгляд - это 20-25гц ФНЧ акселя и 40-50гц частота интегратора соот-но… я как то убедил в этом АлексаВПариже (главный разработчик вии) и он для бма180 выставил 20гц, для бма020 25гц (уже был, т.к. это нижний предел) и для адхл345 тоже 25 гц, чтобы привести все аксели к частоте алт-холд интегратора…

www.multiwii.com/forum/viewtopic.php?f=8&t=849&sta…
www.multiwii.com/forum/viewtopic.php?f=8&t=849&sta…

тут тоже писал об этом:
rcopen.com/blogs/83206

также при таком подходе съэкономим ресурс процессора…

Так что надо ещё сильнее сглаживать вычисленную высоту

в догонку ко второму пункту, еще один плюсик… т.к. цикл вии ~300гц, а интегратор будет настроен на 40-50гц, то между итерациями интегратора можно собрать 6-7 raw самплов с баро и отдать их медианному фильтру… т.е. собираем 7 значений, сортируем, берем 4-е (середину). Шума определенно станет меньше…

Самое главное - он СТАБИЛЕН. Т.е. он ни разу за время облета 4-х паков не приложился об землю и не улетел выше 4-х метров.

а я много раз приложился пока ПИДы крутил… особенно когда сколол кончик пропеллера и пошли вибрации, стаб. мод еще кое как устоял (т.к. у меня в иму точный флоат фильтр на аксель с большим LPF фактором на 0.3-1гц), а вот аль-холд сразу направил коптер в планету 😃 но тут вполне известная проблема, было скорее всего просядание по оси Z от вибраций не смотря на выставленный диапазон 8g…

А коптер летает хорошо. Только по сонару Пиды побольше поставить. Лучше стабилизироваться будет. По моему опыту в 2 раза больше чем по баро.

общая теория такова: чем точнее сенсор, тем агрессивнее могут быть ПИДы… а сонары ведь разные бывают 😉

Спорный вопрос - во первых, два набора пидов усложнят настройку.

Можно летать и на одном - но тогда с сонаром больше плавать будет по высоте. Это проверено. Если на настройках сонара летать по баро излишне дергается.

когда устаканятся ПИДы для баро, можно подобрать коэф. для вычисления ПИДов сонара по ПИДам баро, либо проще - один коэф. для сонар from баро ПИД.

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

высадил кучу паков на выходных… при П более 2-х начинает колбасить вверх вниз, т.е. можно смело уменшать делитель в ПИД регуле…

На оба вопроса ответ один - надо D увеличивать. (т.е. коэффициент при скорости изменения ошибки). Но тут как раз к нему высокие требования, если он сильно шумит и сам прыгает, то только хуже будет. Поэтому я сейчас думаю над тем как сделать максимально полезным акселерометр в связке с барометром.
У меня на видео D=50 и я бы поставил выше, но в ГУИ это предел. умножу на два и посмотрю что будет.

И вопрос - EstG.V.Z -это проекция G на ось Z.

Да, это Z- компонент вектора ориентации, т.е. настоящий G (а не тот что акселерометр меряет)

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

Ага, хороший пример. Добавлю Vel-D и себе, но надо будет провести читсый эксперимент с ним и без.

поставил деадбенд на ПД +/20

Тоже интересное решение, но оно отключает Vel-PD при медленном приближении к цели. Т.е. если ли смысл убирать совсем уж мелкий шум (если ты говоришь что коэффициенты высокие и чувствительность не падает)?

2. т.к. “быстрые” составляющие (ускорение и скорость) высчитываются из акселя, думаю можно смело уменьшать частоту алт-холд интегратора/эстиматора и отталкиваться от частоты среза ФНЧ акселерометра

А в чем смысл делать дискретным вычисления? Только для экономи времени? Да, экономим, но также рвем время цикла (каждый 10-й длится дольше при работе алгоритма), и неизвестно что хуже.

И второе, я точно не знаю как работает датчик. Лучше сразу учеть все варианты его настройки (ну и разные типы датчиков, вот барометр получше уже на 100Hz запускается). Если в дачике настроен фильтр 25Hz, разве из этого следует, что в течение 40мс показания не меняются с него? Это как взять слегка размытую картинку (Гаусс ~ LPF) и разбить на большие пиксели - разница все равно будет заметна глазу.
А у нас интеграторы, там каждая мелочь важна.

а вот аль-холд сразу направил коптер в планету но тут вполне известная проблема, было скорее всего просядание по оси Z от вибраций не смотря на выставленный диапазон 8g…

Это важный момент, попробуй разобраться. Если действительно быстро проседает ACC - весь алгортм летит к чертям. ACC должен быть надежным. Виброизолируй его что ли наконец 😃

когда устаканятся ПИДы для баро, можно подобрать коэф. для вычисления ПИДов сонара по ПИДам баро, либо проще - один коэф. для сонар from баро ПИД.

Да, так проще всего. Вынести множитель в конфиг и все.

Ещё я долго думал как отделаться от скачков высоты сонара при облете препятствий - ведь по акселю мы точно знаем, что высота так быстро прыгнуть не может, и можем точно вычислить высоту препятсвия (по моему так сделано в Parrot Ar.Drone - если ему перекрыть сонар, он не прыгает вверх, а стоит на месте).
Но вот потом любая попытка подстроиться под новую высоту приведет к непрятностям, четкого решения не вижу. Но есть пара идей которые надо попробовать.

предложение-пожелание althold мастерам, для fpv полетов не хватает ограничения высоты, т.к. по камере не всегда понятно как близко земля и можно сильно шлепнуться, поэтому хочется (но не можется) дополнительный мод ограничения высоты полета:

• где то в прошивке (а потом и в GUI) вставлять минимальную высоту (допустим 2 метра), до которой коптер может снижаться
• так как высота явно маленькая то тут будет достаточно одного сонара (хотя не факт)
• повесить режим на тумблер, чтоб сесть можно было =)

имхо можно даже автопосадку (да и взлет, как у AR.drone) сделать, медленно уменьшая пороговое значение снижения и газ

Я пока по FPV не летаю, но планирую 😃 Действительно было бы удобно. Я так понимаю, это ограничение не должно быть связано с AltHold.
В ГУИ лезть неохота. Можно для начала сделать в конфиге, но вот как его выключать, чтобы можно было сесть?
Крутилки у меня на 6-канальном пульте зкончились уже (одна на режимы другая на камеру).

Я так понимаю, это ограничение не должно быть связано с AltHold.

не должно - это как отдельный режим, сотвествено вкл/выкл как любой другой режим, хз где каналов найти под всё и сразу =)

Вот ещё момент: сонар штука такая что может внезапно “потерять сигнал”, и что тогда делать? слушаться газа (и тогда все зависит от скорости реакции пилота), или оставить газ в том положении что было до потери сигнала, и слушаться газа только “вверх”? Тогда войдем в цикл бесконечного полета в космос, если сигнал с радара так и не вернется. Думаю тут надо и барометр привлекать, на случай сбоев сонара, так как на низкой высоте любой просчет алгоритма будет критическим.

идея в том что когда потеря сигнала - код как раз и не работает (т.е. улетели метров на 20 - сонар явно потеряет сигнал), а вот начали снижаться и сонар почуял высоту - тормозим если меньше 2 метров
косяк вылезает: как узнать - потеря сигнала из-за неисправности (или сигнал рассеялся) или из-за высоты - вот видимо без баро никак тут
а с другой стороны - какова вероятность что сигнала долго нет из-за глюка/поверхности?

как вариант:

1. считать высоту такой же, пока нет сигнала N циклов,
2. если N>порог_ошибок, то считаем что улетели и забиваем на код ограничения высоты,
3. если сигнал вылез, N=0 и go to 1

т.е. если летим над странной поверхностью низко, то высота всегда есть, хоть и примерная, если давно нет данных - значит высоко и так летим или плюхнулись давно =)

А в чем проблема ориентироваться на высоту Сонар+баро. Просто должен включатся AltHold, как только высота становится меньше 2м. Поднялись выше - отключается (включается предыдущий режим).

альхолд как я понимаю игнорит газ, а тут надо чтобы вниз - игнорил, а вверх поднимался, пока низко находимся

альхолд как я понимаю игнорит газ, а тут надо чтобы вниз - игнорил, а вверх поднимался, пока низко находимся

Можно управлять не газом ,а заданной высотой (полуавтоматический режим)

а с другой стороны - какова вероятность что сигнала долго нет из-за глюка/поверхности?

Вероятность большая. Например при определенном угле наклона сигнал уже не вернется. Ещё mahovik говорил, что шум моторов может сонар забивать (может на какой-то резонансной частоте, непредсказуемо). Так что тут однозначно нужна связка сонар+баро.

AltHold может управляться газом, но по другому алгоритму (подстройка высоты идет, а коптер старается ей соотвествовать). Но в данном случае подстраивать вниз нельзя, а вверх можно сколько угодно резко, так что этот режим - не AltHold.

А если сделать такой режим, что до X высоты летем как хочешь, ниже X - огранчиваем скорость снижения, напрмер 10см/сек. Тогда и посадка возможна без выхода из этого режима, и большие просчеты пилотирования будет время скорректировать.

как вариант можно ограничить угол наклона на малой высоте, что уменьшит скорость (опасно гонять у земли) и не даст пропасть сигналу из-за сильного наклона
опять же как вариант: повесить 2 сонара под углом (например 10*) и поочередно их мучить - это конечно усложнит конструкцию, но добавит надежности и при наклонах и при потери сигнала

скорость снижения сложно сделать 10см/сек, при том что баро показывает ±1м, а сонар может врать или вообще пропадать

Выложил все наработки, все протестировал в GUI.
code.google.com/p/multiwii-alexmos/…/browse/?r=15#…

Улучшения:

• Мягкий старт - сенсоры согласуются сразу при инициализации и не требуется время на стабилизацию
• Автоматическая подстройка внутреннего PID-регулятора сенсоров
  (позволяет автоматически усилить влияние акселерометр в случае его корректной работы, и быстрее корректировать его ошибку в случае некорректной)
• Более точная процедура калибровки акселерометра по 3-м осям (для улучшения точности удержания высоты в движении + для улучшения полетов в level mode)
  www.multiwii.com/forum/viewtopic.php?f=7&t=1247
• Настраиваемая коррекция газа по углу наклона (как в ардукоптере, для улучшения точности удержания высоты в движении) - THROTTLE_ANGLE_CORRECTION
• улучшен алгоритм управления высотой в режиме AltHold по стику газа (более плавный чем был)
• плавный переход с сонара на барометр на заданной высоте (начиная с SONAR_MAX_DISTANCE - 1м)
• добавлен коэффициент усиления Alt PID при использвании сонара - SONAR_BARO_PID_GAIN (для более агрессивной стабилизации при полете по сонару)
• улучшен алгоритм авто-калибровки акслерометра в полете (теперь калибруется по всем 3-м осям, а не только по Z, что дает бОльшую точность AltHold в движении)
  • в теории эту автокалибровку можно брать и для level-mode, даже если не включен AltHold.