MultiWii - обсуждаем и отлаживаем Alt Hold
Предлагаете ограничивать управляющее воздействие (то есть коррекцию газа)? Не выход, мне кажется… Иначе регулятор будет работать в нерасчетном режиме. И регулятору нужна свобода действий, особено сильному и быстрому 😃
К посту rcopen.com/forum/f123/topic265409/28 - не могли бы вы побьольше комментариев расставлять? Самое главное в нашем общении тут не код, а идеи. И константы лучше выносить в #define и обзывать осмысленными именами и подписывать, чтобы проще было понять потом логику и физический смысл алгоритма.
Предлагаете ограничивать управляющее воздействие (то есть коррекцию газа)? Не выход, мне кажется… Иначе регулятор будет работать в нерасчетном режиме. И регулятору нужна свобода действий, особено сильному и быстрому 😃
К посту rcopen.com/forum/f123/topic265409/28 - не могли бы вы побьольше комментариев расставлять? Самое главное в нашем общении тут не код, а идеи. И константы лучше выносить в #define и обзывать осмысленными именами и подписывать, чтобы проще было понять потом логику и физический смысл алгоритма.
Просто указываю диапазон изменения длительности управляющего импульса на регулятор в микросекундах. У нас разные программы и я пытаюсь свести к сравнимым величинам.
В части свободы регулятора . Без ограничения у меня не получалось получить жесткое удержание без болтанки и быстрое достижение заданной высоты.
И вопрос - EstG.V.Z -это проекция G на ось Z.
Уже есть пара идей насчет улучшения. Сейчас явно не хватает силы PID-регулятору высоты
высадил кучу паков на выходных… при П более 2-х начинает колбасить вверх вниз, т.е. можно смело уменшать делитель в ПИД регуле…
Hекоторые идеи по улучшению:
- пробовал добавлять ПД регуль по скорости… Точнее Д из ПИД по высоте переехал в П по скорости (что одно и тоже) + в качестве Д по скорости взял ускорение как описывал выше + поставил деадбенд на ПД +/20, но не просто обрубил значения менее 20-ти, а с вычитанием в 20, если ПД более 20-ти (т.е. смещение значений к ценру… типа как вишном ролл/питч деадбенде на аппу)… шум сразу пропал, что отлично и при довольно высоких коэф. чувствительность ПД регулятора не падает…
Далее занулял ПИ по высоте, а ПД по скорости брал довольно агрессивными. При рывке вверх и движении с вертикалной скоростью 1-2м/с практически мгновенно (~0.5сек) тормозит коптер при активировании альт-холд… но при движенни вниз результат немного хуже. Это скорее всего из-за явной нелинейности моего акселя по оси Z (+128/-152)…
За счет ускорения поднимается фронт скорости, а также получяется более крутой спад. В отрицателную часть уходит лишь немного в конце… так что можно смело исползовать ускорение, тем более что ускорение гораздо меньше шумит в сравнении со скоростью…
где зеленым-скорость, синим-ускорение, красным-сумма.
для демо: вниз рукой получалось протолкнуть макс. на 40-50см! Также думаю это даст огромный плюс при порывах ветра…
- т.к. “быстрые” составляющие (ускорение и скорость) высчитываются из акселя, думаю можно смело уменьшать частоту алт-холд интегратора/эстиматора и отталкиваться от частоты среза ФНЧ акселерометра. Теоритически конечно чем выше самплинг 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 при медленном приближении к цели. Т.е. если ли смысл убирать совсем уж мелкий шум (если ты говоришь что коэффициенты высокие и чувствительность не падает)?
- т.к. “быстрые” составляющие (ускорение и скорость) высчитываются из акселя, думаю можно смело уменьшать частоту алт-холд интегратора/эстиматора и отталкиваться от частоты среза ФНЧ акселерометра
А в чем смысл делать дискретным вычисления? Только для экономи времени? Да, экономим, но также рвем время цикла (каждый 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 метров
косяк вылезает: как узнать - потеря сигнала из-за неисправности (или сигнал рассеялся) или из-за высоты - вот видимо без баро никак тут
а с другой стороны - какова вероятность что сигнала долго нет из-за глюка/поверхности?
как вариант:
- считать высоту такой же, пока нет сигнала N циклов,
- если N>порог_ошибок, то считаем что улетели и забиваем на код ограничения высоты,
- если сигнал вылез, 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.
А вот и тесты новой версии:
www.youtube.com/watch?feature=player_detailpage&v=…
www.youtube.com/watch?v=nuJkHBdoO3U&feature=player…
После подстройки PID сонар работает просто идеально: высоту держит ±5 см и стабилизируется за 2-3сек без осцилляций вообще.
По барометру вроде тоже неплохо, в пределах расчетного метра и тоже без осцилляций.
А вот и тесты новой версии:
Судя по видео Супер.Алексей,а не могли бы вы выложить готовую прошивку,так сказать для простых смертных)))
А вот и тесты новой версии:
не, всё… завтра впаиваю bmp085 и сонар и то же так попробую (нашел заначку с пропами - 2 пакета - ^_^ можно экспериментить снова)
Выложил все наработки, все протестировал в GUI.
code.google.com/p/multiwii-al...unc%2FMultiWii
или я чето не то делаю или у меня косяк с DNSками
$ svn checkout multiwii-alexmos.googlecode.com/svn/trunk/ multiwii-alexmos-read-only
svn: E170000: URL ‘multiwii-alexmos.googlecode.com/svn/trunk’ doesn’t exist
upd: скачалось… транк надо было стереть
не могли бы вы выложить готовую прошивку
nekaka.com/folder/view/fflQygFI - папка с multiwii вещами и ссылка на прошивку nekaka.com/d/goCWk9pImD
Я сделал zip-архивчик, для тех у кого нет svn: code.google.com/p/multiwii-alexmos/…/detail?name=M…
этот конфиг я заливаю себе. Только я закоментил сонар (навряд ли у кого он есть) и отдладку в GUI. Все остальное “нестандартное” подписано в config.h
Кстати сонар я брал у этого продавца: www.ebay.com/itm/280778106586 (цена вопроса 4$ с доставкой), взял 4 штуки про запас все рабочие.
Совет: откалибруйте акселерометр по моему алгоритму www.multiwii.com/forum/viewtopic.php?f=7&t=1247 (повернуть и откалиброватья по всем 6-ти направлениям), и проверьте что в GUI с него действительно идут даные 255 (±5) в предельных положениях для всех осей.
И очень желательно тестировать “с рук” для начала, т.к. толком не протестил все, а разные сетапы могут себя вести непредсказуемо (особенно это касается акселерометра). У меня он почти не уплывает со временем, и мало плывет от вибраций, поэтому его показания позволяют сильно повысить точность стабилизации.
Кстати, с сонаром посадка намного упрощается. И раньше проблем не было благодаря моду ThrottleExpo, но теперь в режиме AltHold как перышко опускается 😃 С барометром так не прокатывает - все таки подкидывает немного возле земли из-за более слабых настроек PID.
На видео видна разница.
После подстройки PID сонар работает просто идеально: высоту держит ±5 см и стабилизируется за 2-3сек без осцилляций вообще. По барометру вроде тоже неплохо, в пределах расчетного метра и тоже без осцилляций.
Алексей, если не трудно впиши свои демо-ПИДы в EEPROM.pde или выложи их сюда pls…