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

SovGVD

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

alexmos

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

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

SovGVD
alexmos:

если ты сморишь в 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)😉

mahowik
alexmos:

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

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

alexmos

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

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

mahowik
alexmos:

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

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

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

alexmos

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

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

Sir_Alex
alexmos:

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

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

mahowik

Меня вчера осинило вдруг! 😃
А почему не отнимать длину вектора 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 соот-но станет менее шумной.
В конечном ПИД регуле в итоге при высоких Д не будет лишних дерганий (при переусиленни шума)

alexmos
mahowik:

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

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

mahowik
alexmos:

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

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

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

alexmos
mahowik:

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

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

mahowik:

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

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

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

mahowik:

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

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

skyrider

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

gensek

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

[IMG][/IMG]

alexmos

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

soliada

Аналогичная ситуация.Та же ошибка при компиляции.

alexmos:

Выложил по той же ссылке исправленную версию.

Спасибо,теперь компилируется.

У меня вопрос по GPS,какие настройки для модуля нужны МультиВи?
Если я правильно понимаю,то они отличны от настроек для Мегапирата?

skyrider

Подлетнул, видимо нужно настраивать (правда не знаю что), явно видно что пытается держать высоту, но в итоге рывками либо уходит в низ либо в верх, правда не понял сонар это или барометр т.к. включаются вместе с одного тумблера. Заметил в GUI такую штуку, если смотрим debug1 без активации баро и сонара - высоту показывает идеально, стоит щелкнуть тумблер (активация баро и сонара) - начинает шуметь. Квадрик весит примерно 1.5 кг, моторы 750кв, винты 12х4.7, пиды ALT ставил как на скрине выше, аксель по шести точкам не калибровал, куда копать?

alexmos

Сонар отключается в режиме Passthru - проверьте не включается ли у вас этот режим по тумблеру. Аксель желательно окалибровать по 6 точкам, делов 30 сек (это для парвильной работы барометра). По идее сонар не должен выключаться в режиме удержания высоты. Он отключается, если начнет терять сигнал, также при углах наклона больше 60.

soliada:

У меня вопрос по GPS,какие настройки для модуля нужны МультиВи?

по ЖПС - это не ко мне, никогда с им дела не имел.

gensek
alexmos:

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

Спасибо, залил, в гуи все крутится правильно, по блютусу изменений нет с версией r15? помнится там не мог подцепится, а сейчас на r18 проверить нет возможности.

skyrider
alexmos:

Сонар отключается в режиме Passthru - проверьте не включается ли у вас этот режим по тумблеру.

шорт побьери, т.е. если я активирую Passthru сонар отключается? я думал он в таком режиме включается…
У меня на одном тумблере включение BARO и включение Passthru, получается в GUI на чекбоксах просто нужно оставить активацию BARO а Passthru не трогать вообще, при этом сонар по умолчанию будет постоянно активным?

После калибровки по этой методике ROLL почемуто стоит ровно под 45 градусов, что то делаю не так…