Search in topic

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

Что такое loiter?

Режим LOITER - удержание позиции.

В ардукоптере собираются заюзать аксель для Loiter’a, мот и вам пригодится

это акселем ускорение по всем осям чтоли будут смотреть и корректировать GPS?

В ардукоптере собираются заюзать аксель для Loiter’a, мот и вам пригодится

Это помогает, если сливать аксель с GPS (тут почти те же алгоритмы что и у меня для althold). Если сливать с optical flow - уже хуже и вряд ли аксель тут поможет (оба измерения относительные). Если чистый аксель - то абсолютно никакого смысла нет.

это акселем ускорение по всем осям чтоли будут смотреть и корректировать GPS?

Видимо - да. Jason Short сказал что тестирует эту фичу, но в GIT’e пока нету.

Потихоньку допиливаю свой алгоритм, с основном в плане быстродействия. Вот сегодня заснял “комнатные” тесты. Барометр, конечно, в помещении и близко к полу не очень хорошо работает - сказыватся воздушные потоки. Но все равно с достаточно высоким Alt-P и высоким D осцилляций не возникает. Если его уменьшить, то будет висеть на месте, но уж очень слабо тогда держит внешние возмущения.

www.youtube.com/watch?v=-3SmlnSyLcM

Осталось поправить одну ошибку при работе с сонаром и выложу.

Синализация коррекции высоты - это суперфункция 😃 Теперь высоту можно установить очень точно и не сбить установку при подруливании YAW.

пипец, как у вас получаются такие результаты? я тут на пару минут оставил барометр (085), EstAlt/100 (раз оно в сантиметрах, перевел в метры) уплывает потихоньку на ±5 метров, вожу платку вверх/вниз (около метра) - ничего особо не меняется, а у вас тут летает на барометре в помещении

Можно на ты 😃 По отзывам других владельцев, у барометра 085 высота плывет ±1 м. У меня также, ±1, при полете в этих пределах и гуляет.
О, я кажись понял прчину: если ты сморишь в GUI в перменных EstAlt или BaroAlt - то там она делится на 100 и отбражается в метрах.

Вот строчка из Serial.pde: serialize16(EstAlt/10);
И в GUI видимо ещё раз на 10 делят.

если ты сморишь в GUI в перменных EstAlt или BaroAlt - то там она делится на 100 и отбражается в метрах.

я себе вот так сделал (debug2 и 3, версия 2.0pre3, аксель bma020 как то приглушен в этой версии вернул 2G и acc_1G = 255;, вместо 8G и acc_1G = 63;)

      serialize16((EstAlt-AltGround)/100);
      serialize16(EstAlt/100);

AltGround=EstAlt при заводе моторов
лежит платка на столе - значение в GUI то вверх, то вниз ползет, туда/сюда поднимаю - толком ничего не меняется
еще и BaroAlt/10=EstAlt/100 (хотя не удивительно EstAlt = BaroHigh*10/(BARO_TAB_SIZE/2)😉

Потихоньку допиливаю свой алгоритм, с основном в плане быстродействия.

выложи код… на выходных будет время думаю… могу облетать…
ну и как обычно рекомендации по настройке и ПИДы ))

Выложил на SVN. В Readme.txt все нововведения описаны. Сегодня наконец хороший денек, тоже потестил немного. Вроде все ок, коррекция газа по углу тоже работает (я там ввел два коэффициента для настройки). Единственное, странный глюк - как только вылетаю из тени на солнце, коптер тут же падает 😦 Не хватило времени и батарей разобраться почему. Думаю из-за резкого прогрева датчиков, и решится установкой фольги на крышку.

По PID осталось прмерно также у меня, единственное D повысил, иначе остается склоность к осцилляциям: P=8, I=0 - 0.020, D=25. Если сонара нет, то I=0 можно смело ставить. Если есть, то I нужен - тогда переход с барометра на сонар при подъеме очень плавный (при плавном подъеме я даже не смог определить на какой высоте барометр подхватывается).

Выложил на SVN. В Readme.txt все нововведения описаны. Сегодня наконец хороший денек, тоже потестил немного. Вроде все ок, коррекция газа по углу тоже работает (я там ввел два коэффициента для настройки). Единственное, странный глюк - как только вылетаю из тени на солнце, коптер тут же падает 😦 Не хватило времени и батарей разобраться почему. Думаю из-за резкого прогрева датчиков, и решится установкой фольги на крышку.

По PID осталось прмерно также у меня, единственное D повысил, иначе остается склоность к осцилляциям: P=8, I=0 - 0.020, D=25. Если сонара нет, то I=0 можно смело ставить. Если есть, то I нужен - тогда переход с барометра на сонар при подъеме очень плавный (при плавном подъеме я даже не смог определить на какой высоте барометр подхватывается).

Кроче полеты как мин. на неделю откладываются. Вчера не вписался с маневром и поймал асфальт. Электронику пока не проверял… минус 2 движка , но вроде как можно восстановить. Так что пока код посмотрю…
По поводу провалов на солнце. Мот у тебя уже оптикал флоу подвешен? 😃 Если нет, то это еще раз говорит о большой чувствительности алгоритма к малейшим изменениям параметров сенсоров…
По поводу увеличения D и склоности к осцилляциям. Не пробовал ускорение использовать? Из-за подЪема фронта и увеличения крутизны спада будет более четкая отработка по D…

Сочуствую, я вот пока не рискую на маневры 😃 Нет запчастей.
Optical Flow был включен, но он не мог влиять на высоту никак, он углы корректирует. Засветка просто приведет к отсутвию данных какое то время. Тут какая-то более серьезная проблема, прям интересно что это такое.

Вечером опять сходил погонял по двору, в общем все стабильно, летать можно и по сонар и по барометру. Серву подвеса переключил на другой BEC, вроде и помехи сонара ушли. Так что осталось смержиться с 2.0 и подкорректировать коэффициенты для пониженного цикла (30 гц должно хватить), а то сейчас с OptFlow время цикла непрлично большое, 4500.

Тут какая-то более серьезная проблема, прям интересно что это такое.

Попробуй просто феном погреть датчики. Как минимум аксель серьезно плывет при нагреве.

Меня вчера осинило вдруг! 😃
А почему не отнимать длину вектора EstG вместо acc_1G, тогда и статическую ошибку искать не надо! Т.к. EstG вектор “плавно” корректируется по акселю (и уже содержит нужную нам коррекцию ошибки), в переходных процессах при ускоренни/торможении его длинна как раз acc_1G минус ошибка (дрейф акселя, неточная калибровка и т.д.), т.е.

accZ = (accADC[0] * EstG.V.X + accADC[1] * EstG.V.Y + accADC[2] * EstG.V.Z) * InvG - 1/InvG;

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

vel+= accZ*accVelScale*cycleTime - vel * VEL_DAMP;

Скорость станет меньше шуметь, т.к. в ней не будет ошибки (alt - sensorAlt). И EstAlt соот-но станет менее шумной.
В конечном ПИД регуле в итоге при высоких Д не будет лишних дерганий (при переусиленни шума)

Меня вчера осинило вдруг!
А почему не отнимать длину вектора EstG вместо acc_1G, тогда и статическую ошибку искать не надо! Т.к. EstG вектор “плавно” корректируется по акселю (и уже содержит нужную нам коррекцию ошибки), в переходных процессах при ускоренни/торможении его длинна как раз acc_1G минус ошибка (дрейф акселя, неточная калибровка и т.д.), т.е.

Я это тоже пробовал 😃 Не рабоатет. Вернее, работает но намного хуже поиска статичной I-части. Эта операция равнозначна дампингу ускорения в 0, что означает сначала ошибку в определении скорости и ещё большую в определении расстояния (это проявляется как выбросы на графиках скорости в минус и меньшее расстояние чем пройдено)

Я это тоже пробовал Не рабоатет. Вернее, работает но намного хуже поиска статичной I-части. Эта операция равнозначна дампингу ускорения в 0, что означает сначала ошибку в определении скорости и ещё большую в определении расстояния (это проявляется как выбросы на графиках скорости в минус и меньшее расстояние чем пройдено)

но тут ведь допущение что EstG вполне статичен на переходных процессах (при высоком GYR_CMPF_FACTOR) т.е. при ускорениях и потому будет содержать именно acc_1G минус дрейф/ошибку акселя… мы ведь исходя из этого допущения используем EstG в качестве Z оси для получения проекции вектора ускорения…

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

но тут ведь допущение что EstG вполне статичен на переходных процессах (при высоком GYR_CMPF_FACTOR) т.е. при ускорениях и потому будет содержать именно acc_1G минус дрейф/ошибку акселя…

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

мы ведь исходя из этого допущения используем EstG в качестве Z оси для получения проекции вектора ускорения…

В этом случае есть существенная разница - мы использует только НАПРАВЛЕНИЕ вектора гиры. Его длина нам не интересна при проекции. А направление хорошо совпадает с направлением акселя при вертикальных перемещениях под любым углом. И даже если совпадает плохо - разница в Cos малого угла, что является бесконечно малой величиной.

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

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

Неверное допущение. Комплементарный фильтр не зависит от амплитуды сигнала, только от разницы. Т.е. если ускорение будет 10G в течение 0.1 сек, то и ошибка будет большой. Если ускорение будет 0.1G в течение 100 сек, то ошибка будет малой, но в итоге при интегрировании ошибка в скорости в обоих случаях будет одинаковой. Поэтому неважно затяжные это или быстрые процессы.

Плата у меня тоже Crius SE, сонар есть, если прошивка с работающим сонаром не опасна для коптера ,меня и окружающего мира, можно выложить готовый скетч для Crius SE 😃, и если можно , Алексей, скрин работающих пидов.
Если на выходные не будет дождя попробую подлетнуть.

Нет, сонар не опасен 😃 Проверьте только в GUI что он выдает правильно высоту и при включении моторов не сбоит.
В Readme.txt все отличия от официальной версии 1.9, а все настройки моих модов в конце config.h

Скетч: …googlecode.com/…/MultiWii_r18.zip
GUI: …googlecode.com/…/MultiWiiConf_1_9_r15.zip

Не компилируется, в папке лежат и MultiWii.ino и MultiWii.pde

[IMG][/IMG]

На первом скриншоте непонятная ошибка, а на втором - прошу прощения, есть такая. Выложил по той же ссылке исправленную версию. Компилировал в IDE 0023