MultiWii - обсуждаем и отлаживаем Alt Hold
если ты сморишь в 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
Аналогичная ситуация.Та же ошибка при компиляции.
Выложил по той же ссылке исправленную версию.
Спасибо,теперь компилируется.
У меня вопрос по GPS,какие настройки для модуля нужны МультиВи?
Если я правильно понимаю,то они отличны от настроек для Мегапирата?
Подлетнул, видимо нужно настраивать (правда не знаю что), явно видно что пытается держать высоту, но в итоге рывками либо уходит в низ либо в верх, правда не понял сонар это или барометр т.к. включаются вместе с одного тумблера. Заметил в GUI такую штуку, если смотрим debug1 без активации баро и сонара - высоту показывает идеально, стоит щелкнуть тумблер (активация баро и сонара) - начинает шуметь. Квадрик весит примерно 1.5 кг, моторы 750кв, винты 12х4.7, пиды ALT ставил как на скрине выше, аксель по шести точкам не калибровал, куда копать?
Сонар отключается в режиме Passthru - проверьте не включается ли у вас этот режим по тумблеру. Аксель желательно окалибровать по 6 точкам, делов 30 сек (это для парвильной работы барометра). По идее сонар не должен выключаться в режиме удержания высоты. Он отключается, если начнет терять сигнал, также при углах наклона больше 60.
У меня вопрос по GPS,какие настройки для модуля нужны МультиВи?
по ЖПС - это не ко мне, никогда с им дела не имел.
На первом скриншоте непонятная ошибка, а на втором - прошу прощения, есть такая. Выложил по той же ссылке исправленную версию. Компилировал в IDE 0023
Спасибо, залил, в гуи все крутится правильно, по блютусу изменений нет с версией r15? помнится там не мог подцепится, а сейчас на r18 проверить нет возможности.
Сонар отключается в режиме Passthru - проверьте не включается ли у вас этот режим по тумблеру.
шорт побьери, т.е. если я активирую Passthru сонар отключается? я думал он в таком режиме включается…
У меня на одном тумблере включение BARO и включение Passthru, получается в GUI на чекбоксах просто нужно оставить активацию BARO а Passthru не трогать вообще, при этом сонар по умолчанию будет постоянно активным?
После калибровки по этой методике ROLL почемуто стоит ровно под 45 градусов, что то делаю не так…
Заработал сонар, почти отлично, на видео ручку газа не трогал вообще, видно как несколько раз “чихает” по высоте, а так все отлично! Браво Алексей!
Получается до этого я летал с отключенным сонаром, и рывки по высоте до этого были по барометру, как и сейчас если подняться метров на 5 и включить удержание, видимо для правильной работы калибровка по шести точкам обязательна, у меня почему то по ROLL становится криво. Алексей, последовательность калибровки не имеет значения (естественно кроме позиции №1)
Возник вопрос такого характера. А на какие пины подключать сонар на Ардуине с 2560АТмегой?