Search in topic

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

Меня вчера осинило вдруг!
А почему не отнимать длину вектора 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АТмегой?

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

По GUI у вас по двум осям 255… а должно быть только по одной. Какая у вас схема расположения моторв? на рисунке для QUADX - т.е. оси датчика должны смотреть ровно под 90 градусов по горизонту. Сорри если по схеме это не очень понятно 😃 Порядок не имеет значения, да и точность расположения не надо выерять до 1 градуса- удерживать в руках вполне достаточно.

Возник вопрос такого характера. А на какие пины подключать сонар на Ардуине с 2560АТмегой?

Не знаю, дело в том что мегу я в глаза не видел, и писать для нее код вслепую смысла нет. Trig можно на любую ногу вешать, а вот Echo - только там где есть свободное прерывание. Попробуйте разобраться в Sonar.pde как правильно настроить прерывания на мегу и на каком порту/ноге, а я включу в основной код…

видно как несколько раз “чихает” по высоте, а так все отлично

Это плохой симптом - на такой высоте как на видео сонар должен работать идеально. У меня при висении до 2-х метров никаких намеков нет на провалы. Если быстро носиться туда сюда с наклонами 45 град. - тогда да, начинает слегка подергивать по высоте.
Очень важно свободное пространство в угле 120 градусов от датчиков сонара, а также не должно быть наводок (типа проводов от ESC и моторов вблизи платы, серв на той же линии питания и т.д.), т.к. сонар имеет очень чувствителен к питанию, там же микрофонные усилители по сути.

По GUI у вас по двум осям 255

Теперь только по Z 255

Какая у вас схема расположения моторв? на рисунке для QUADX - т.е. оси датчика должны смотреть ровно под 90 градусов по горизонту. Сорри если по схеме это не очень понятно Порядок не имеет значения

Схема расположения моторов QUAD X, пробовал менять последовательность, добился правильной калибровки в такой последовательности по Вашей схеме : 1 , 2 , 5 , 4 , 3 , 6. Не знаю почему , но в моем случае именно эта последовательность сработала, перепроверял три раза.
Если завтра позволит погода, проверю работу барометра, пропадут рывки по высоте после правильной калибровки акселя или нет.

чень важно свободное пространство в угле 120 градусов от датчиков сонара

С этим все в порядке.

а также не должно быть наводок (типа проводов от ESC и моторов вблизи платы, серв на той же линии питания и т.д.)

Попробую поменять на провода в изоляции.

на такой высоте как на видео сонар должен работать идеально

Может быть причиной небольших провалов то что мой квадрик более тяжелый, моторы относительно медленные 750кв, т.е он более вялый , не такой резкий, и ему нужны другие пиды ALT?

Схема расположения моторов QUAD X, пробовал менять последовательность, добился правильной калибровки в такой последовательности по Вашей схеме : 1 , 2 , 5 , 4 , 3 , 6. Не знаю почему , но в моем случае именно эта последовательность сработала, перепроверял три раза.
Если завтра позволит погода, проверю работу барометра, пропадут рывки по высоте после правильной калибровки акселя или нет.

Хм, похоже баг где то в алгоритме. Последовательность не должна играть никакой роли, кроме того что Z всегда в начале. Подумаю…

Может быть причиной небольших провалов то что мой квадрик более тяжелый, моторы относительно медленные 750кв, т.е он более вялый , не такой резкий, и ему нужны другие пиды ALT?

Нет, по видео очень похоже на кратковременные лаги сонара. От веса конечно зависит, но просто будет чуть медленне стабилизация - а тут из стабилного состояния рывки в нестабильное. Попробуйте запустить моторы на рабочую мощность с подключением в ГУИ и гляньте что показывает сонар. Высота не должна прыгать.

Вообще с сонаром надо быть осторожнее, т.к. если он начнет выдавать неправильные данные (например от наводок решит что высота всегда равна 1 метру) - коптер может как свалиться, так и в небеса улететь. Я сделал ограничитель по барометру для крайних случаев, но не проверял его работу. Так что при испытаниях надо руку всегда держать на ручке отключения режима Alt Hold 😃

Изменил пару параметров в config.h
#define MINTHROTTLE 1130
#define INTERNAL_I2C_PULLUPS
#define DEADBAND 20
#define MAXTHROTTLE 1900
#define THROTTLE_HOVER 1440
#define SHIFT_HOVER 1450
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = -Y; magADC[PITCH] = X; magADC[YAW] = Z;}
Откалибровал по шести точкам и подлетнул на метровой высоте - дергается при включении Alt Hold по высоте как припадошный каждые 2-3 секунды, что то из того что я сделал ему явно не понравилось, нужно цеплять блютус и смотреть что кажет в полете.

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

Скачет примерно + - 0.1-0.3

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

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

Правильный ответ - зависит от сонара. Как у него определено в датащите для таких случаев, то и должен выдавать.
Но к примеру тот, что я использую - ему плевать на датащит и он выдает при потере сигнала 1 метр (все 4 штуки что я тестил - по разному). Но при этом время измерения подскакивает до 250мс, и вот так можно распознать ошибку.

Частота измерений зависит от расстояния… При нулевом - близко к нулю, +50мс на паузу между измерениями.

Угол охвата также зависит от сонара, на практике градусов 60. В датащите приводится диаграмма направленности.

5 метров это для идеальных условий. Реально в условиях зашумленного питания, ненулевого угла наклона будет меньше. Я ставлю с 2 до 3 метров плавный переход на барометр. При наклонах лимит опускается (я заложил примерную диаграмму направленности в алгоритм).

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

Попробовал. По графикам пока очень нравится. Выводил одновременно 2 графика: ускорение “с минус acc_1G” и “c минус 1/InvG”. В ГУИ они практически совпадают.
Профит:

1. скорость не шумит
2. высота соот-но шумит меньше, а если повысить коэф. компл. фильтра до 200-300, то вообще меедленно плавает +/-0.2…0.4 м
3. простота настройки, т.к. нет зависимых параметров типа ПИДы в интеграторе и коэф. компл. фильтра

но это все теория пока 😃 облетать не могу, т.к. еще не починился после последнего краша…