Search in topic

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

Я вот потестировал платку с Гудлака. Со своим кодом пробовал отлаженный алгоритм по фильтрации баро с акселерометром. Алгоритм испытан на MPU6050 c MS5611. Так вот на этой платке из-за медленного акселя результат отрицательный. То есть сам баро с частотой считывания 40 Гц с алгоритмом - раз читаем температуру 4 раза баро работает лучше без акселерометра.

то работа, то здоровье шалит

tazhe fignya…

Во первых новость, что бывает 1G = 128

nu tak da, dlya kazhdogo akselya svoy acc_1g… seychas dlya adxl345 i bma180 eto 256 (dlya bma180 ranshe bilo 512), a dlya bma020 64 vsego, t.k. pri range 8g eto max resolushn dlya nego… a u menya dlya bma020 eto 128 (+ oversampling v IMU dlya podnyatiya razresheniya) t.k. 64 malo dlya ustoychivogo level mode…

с первыми же PID стабилизирует высоту отлично.

povtori kakie PID pls…

А что показывает барометр при этом? Сейчас фактически два набора внутренних PID - когда AltHold режим не включен, высота почти что чисто с барометра берется и следует за ним. Этого достаточно чтобы при включении и подлете устранить постоянную ошибку. Когда включается режим, то PID меняется и работает акселерометр уже более “чисто”. Т.е. коптер даже с сильной привязкой к высоте плавает медленно, и любое возмущеие отслеживает агрессивно.

barometr vrode ne prigaet pri etom… nado pereproverit’…

Выложи, я ужее давно просил. На SVN удобно.

nu da, svn rulit, sedlay mne branch pls…

Кстати я тоже планирую мержить, как новая версия, уже достаточно стабильна? прежняя 1.9 мне нравится, не хочется рисковать

proveryal level mode poka na MultiWii_dev_20120225 - vse ok,
no sudya po anonsu k 2.0pre1 tam ochen mnogo vkusnogo www.multiwii.com/forum/viewtopic.php?f=8&t=1290
mozhno podozhdat’ konechno nemnogo poka bagi utryasut

Но боюсь в таком виде не примут (и цикл надо уменьшать и оТ такого кол-ва float избавляться). Все в планах, но вот времени маловато.

esli budet 100% rabochiy algoritm to i s float prokatit dumayu, t.k. te komu nuzhen alt hold za cycle time ne gonyatsya… min cycle time principialen tol’ko dlya acro mode…

p.s. tut merzhe v MultiWii_dev_20120225

Только что отлетал 4 пака на улице, в целом все нормально - по барометру высоту держит в пределах метра иогда медленно дрейфует до 2.
При ускорениях, быстром полете, болтанке на месте, высота сильно не меняется.

Абсолютно необходимая доработка - сигнализация коррекции высоты. Т.е. когда выводим ручку газа из alt hold deadband, коптер должен мигать и пищать, чтобы было понятно. А то подруливая по курсу, сбивается газ, и из-за экспоненты на нем сразу не видно, что уже вышли из допуска и высота начала меняться… И когда необходимо поменять высоту, трудно вернуть газ в то же место.

С сонаром вообще сказка, на 10см можно летать с высокой скоростью, и до 2 метров держит практически любые маневры. На высоте 4 метра при переходе на барометр, заметил какую то нестабильность но были неподходящие уловия, чтобы отследить что не так, по GUI. Нужен второй человек 😃
Ещё сонар абсолютно не перенес цифровую серву, которая подруливала подвесом камеры. Выдает гребенку, когда она включается. Попробую перенести ее на другой BEC.

Раз всё так хорошо с сонаром, может пора автовзлет (увеличение высоты удержание несколько циклов)/автопосадку(аналогично, но уменьшать высоту) сделать? и подумать над ограничением высоты? =) скоро детальки дойдут - соберу пепелац и буду мучить его

В общем разобрался в чем проблема была с мержем в dev_20120225. Там изменили механизм вызова getEstimatedAltitude() на каждую четвертую итерацию цикла. Таким образом цикл тайм для алт-холд интегратора был в 4 раза больше и соот-но коэф. не подходили. В общем запустил, работает. В среднем держит +/-1м, но иногда прыгает до 2-х…
THROTTLE_ANGLE_CORRECTION только мешает. Точнее в началее движения компнсация правильная (только 100 для моего конфига оч. много), НО при маневрах (при смене направления двиения к примеру), его и так подкидывает по инерции, а если еще THROTTLE_ANGLE_CORRECTION включен, то скачки до 3-4м…
Остальное потом опишу… надо бежать…

Раз всё так хорошо с сонаром, может пора автовзлет (увеличение высоты удержание несколько циклов)/автопосадку(аналогично, но уменьшать высоту) сделать? и подумать над ограничением высоты? =) скоро детальки дойдут - соберу пепелац и буду мучить его

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

Раз всё так хорошо с сонаром, может пора автовзлет (увеличение высоты удержание несколько циклов)/автопосадку(аналогично, но уменьшать высоту) сделать? и подумать над ограничением высоты? =) скоро детальки дойдут - соберу пепелац и буду мучить его

Честно говоря не вижу смысла… Какие могу быть проблемы при взлете? С удержанием высоты есть один нюанс - нужно выставить газ на зависание и потом газ должен быть только в этой точке (это необходимо т.к. пр отключении режима коптер не должен рухнуть камнем вниз). Можно что то придумывать, но результат не стоит усилий - сама процедура взлета не проблемная.

А посадка в режиме alt hold и сейчас работает - просто начинаем медленное снижение и с сонаром оно проходит достаточно линейно до полного приземления. С барометром похуже - он может подпрыгнуть у земли, т.к. создается подушка, но тоже садиться можно.

Честно говоря не вижу смысла…

начало автономного полета, позицию по GPS говорят уже держит и домой летает, значит и до полета по маршруту не далеко

В общем разобрался в чем проблема была с мержем в dev_20120225. Там изменили механизм вызова getEstimatedAltitude() на каждую четвертую итерацию цикла. Таким образом цикл тайм для алт-холд интегратора был в 4 раза больше и соот-но коэф. не подходили. В общем запустил, работает. В среднем держит +/-1м, но иногда прыгает до 2-х…

Спасибо, учту. Ну если держит, то уже хорошо. У меня кстати, как только вышел на из дома на мороз и взлетел, тоже какая то фигня творилась. Перекалибровал аксель, дал время “остыть” - и тогда начал зависать нормально.

THROTTLE_ANGLE_CORRECTION только мешает. Точнее в начале движения компнсация правильная (только 100 для моего конфига оч. много), НО при маневрах (при смене направления двиения к примеру), его и так подкидывает по инерции, а если еще THROTTLE_ANGLE_CORRECTION включен, то скачки до 3-4м…

Думаю, что не в нем причина, я пробовал этот режим без alt hold в level mode - он практически не ощущается. Т.е. эффект от неправильной калибровки акселя намного сильнее. Но сегодня при правильной калибровке, провалов при начале и подскока в конце не было. Я гонял достаточно энергично вперед и назад на одном барометре на высоте 1.5 метра, а также вбок ±45градусов - тоже держит на месте. Но точно сказать, что помогло - THROTTLE_ANGLE_CORRECTION или новая калибровка, не могу.

начало автономного полета, позицию по GPS говорят уже держит и домой летает, значит и до полета по маршруту не далеко

Тогда это уже совсем другая история. Я честно говоря, не стал бы в Multiwii делать полет по точкам, тут нужен помощнее мозг, + переферии побольше типа OSD или линка с обратным каналом.

Спасибо, учту. Ну если держит, то уже хорошо. У меня кстати, как только вышел на из дома на мороз и взлетел, тоже какая то фигня творилась. Перекалибровал аксель, дал время “остыть” - и тогда начал зависать нормально.

именно по этому я пока не пробовал и не планирую скорее всего использовать 3-х осевую калибровку, т.к. если уж и bma180 (с внутренней t-компесацией) педалит, то что говорить про остальные аксели, хотя летом может и имеет смысл…

Думаю, что не в нем причина, я пробовал этот режим без alt hold в level mode - он практически не ощущается. Т.е. эффект от неправильной калибровки акселя намного сильнее. Но сегодня при правильной калибровке, провалов при начале и подскока в конце не было. Я гонял достаточно энергично вперед и назад на одном барометре на высоте 1.5 метра, а также вбок ±45градусов - тоже держит на месте. Но точно сказать, что помогло - THROTTLE_ANGLE_CORRECTION или новая калибровка, не могу.

Я вешал THROTTLE_ANGLE_CORRECTION на тумблер с аппы и тестил его без аль-холд. Если выкл, то на старте снижение ~30гр. и при описанном маневре (смена направления движения) подлетает на 1-2м. Проверял в Феникс СИМе, так и есть, при смене направления движения его подкидывает по инерции, т.е. тут все ок. Включаем с пульта THROTTLE_ANGLE_CORRECTION. В начале движения набор высоты ~30гр. Т.е. для моего конфига 100 многовато… со значениями не игрался. Далее при маневре смены направления движения: инерция+компенсация=скачки 3-4м.

Теперь по новому алгоритму:

1. зачем вычислять ошибку для каждой из осей, а потом при расчете accZ “собирать” ее обратно (применение описанное в TODO в расчет не берем)? Визуально без трех осевой калибровки и без разложения ошибки по осям (старая версия алгоритма), кривая скорости и ускорения более плавная (или красивая чтоль) + время вычисления меньше, что актуально при интегрировании не в каждой итерации цикла…

tmp = err*ACC_BARO_I*InvG;
  for(axis=0; axis<3; axis++) {
      errI.A[axis]+= EstG.A[axis] * tmp;
  }

  // Project ACC vector A to 'global' Z axis (estimated by gyro vector G) with I term taked into account
  // Math: accZ = (A + errI) * G / |G| - 1G
  accZ = get_accZ(&(errI.V));

2. есть идея ITerm (PID “I”) составляющую ПИД регуля отключать в баро режиме, т.к. она довольно медленная и только вносит путаницу в результат AltPID, т.к. даже на выходе интегратора высота шумит в диапазоне метра (с bmp085) и шумит гораздо быстрее результата ITerm. В итоге I стремится непонятно к чему и имеет неактуальное значение, т.к. целевая величина прыгает постоянно… В общем я занулил ее и вроде как диапазон плавания уменьшился…
   Второй вариант пробовать повысить “скорость” I составляющей…
   з.ы. для сонара или более точного баро I безусловно полезна, т.к. целевая величина явно присутствует 😃

3. P=10 слишком много, т.к. опять же вычисленная высота постоянно плавает +/- полметра-метр и это дает оч. большую компенсацию, хотя физически высота не меняется, отсюда большое беспричинное упр-е воздействие на моторы и дерганье постоянное вниз-вверх. На моем конфиге Р=2-3 получилось оптимально… Интересно если поставить НЧ фильтр в ПИД регуле уже на вычисленную высоту?

4. с D параметром дела обстоят получше и я отвязал его от P8[PIDALT] для более понятно тюнинга.

//DTerm = ((int32_t)D8[PIDALT]) * P8[PIDALT] * constrain(EstVelocity, -100, 100) / 1000;
DTerm = D8[PIDALT] * constrain(EstVelocity, -100, 100) / 10;

D=6-10 оптимально

вот текущая версия если интересно:

именно по этому я пока не пробовал и не планирую скорее всего использовать 3-х осевую калибровку, т.к. если уж и bma180 (с внутренней t-компесацией) педалит, то что говорить про остальные аксели, хотя летом может и имеет смысл…

Но без калибровки, на акселе можно только висеть неподвижно. Если его показаниям нелзя верить пр наклоне, это плохо и для обычного полета - будет постоянно уходить level после долгого пролета и остановки.

Я вешал THROTTLE_ANGLE_CORRECTION на тумблер с аппы и тестил его без аль-холд. Если выкл, то на старте снижение ~30гр. и при описанном маневре (смена направления движения) подлетает на 1-2м. Проверял в Феникс СИМе, так и есть, при смене направления движения его подкидывает по инерции, т.е. тут все ок. Включаем с пульта THROTTLE_ANGLE_CORRECTION. В начале движения набор высоты ~30гр. Т.е. для моего конфига 100 многовато… со значениями не игрался. Далее при маневре смены направления движения: инерция+компенсация=скачки 3-4м.

Да, все верно эта коререкция при торможении работает неправильно. Сложный аэродинамичский эффект. Но я знаю как его скомпенсировать правильно - ведь информация, ускоряемся ли мы или тормозим, у нас есть по углу между акселем и гирой. При торможении надо даже обращать знак у коррекции по углу, т.к. выброс тяги очень сильный.

Эта фича конечно не так важна для полетов, но интересно с ней все же разобраться.

1. зачем вычислять ошибку для каждой из осей, а потом при расчете accZ “собирать” ее обратно (применение описанное в TODO в расчет не берем)? Визуально без трех осевой калибровки и без разложения ошибки по осям (старая версия алгоритма), кривая скорости и ускорения более плавная (или красивая чтоль) + время вычисления меньше, что актуально при интегрировании не в каждой итерации цикла…

Это мое ноу-хау, и оно очень полезно на самом деле. Только с ней я получил полную инвариантность высоты при наклонах на НЕ ОТКАЛИБРОВАННОМ акселерометре.
Смысл в том, что при наклоне например на 90 град. уже нет смысла отнимать I-часть от оси Z - она уже не участвует в опредении высоты. Зато участвет ось X, у которой ноль может быть смещен с гораздо большей вероятностью (из-за специфики старой процедуры калибровки).

А откалибровать нули с этой штукой очень просто - включи питание и наклони на 90гр на одну из осей. Подожди секунд 10 - ноль выставится по барометру сам. Потом наклони на другуй ось. Потом опять в центр. И все, все три I-части у нас содержат ошибку по нулям! Правда она не сохранится в EEPROM и нужно будет при замене батареи повторять.

2. есть идея ITerm (PID “I”) составляющую ПИД регуля отключать в баро режиме, т.к. она довольно медленная и только вносит путаницу в результат AltPID, т.к. даже на выходе интегратора высота шумит в диапазоне метра (с bmp085) и шумит гораздо быстрее результата ITerm. В итоге I стремится непонятно к чему и имеет неактуальное значение, т.к. целевая величина прыгает постоянно… В общем я занулил ее и вроде как диапазон плавания уменьшился…
   Второй вариант пробовать повысить “скорость” I составляющей…
   з.ы. для сонара или более точного баро I безусловно полезна, т.к. целевая величина явно присутствует

Ты неправильно понмаешь смысл алгоритма. Основная цель внутреннего PID - найти I и не трогать ее! Это и будет истинный ноль акселерометра. Перечитай абзац выше. Если бы мы имели абсолютно точный акселерометр - внутренний PID не нужн вообще и достаточно комплементарного фильтра.

3. P=10 слишком много, т.к. опять же вычисленная высота постоянно плавает +/- полметра-метр и это дает оч. большую компенсацию, хотя физически высота не меняется, отсюда большое беспричинное упр-е воздействие на моторы и дерганье постоянное вниз-вверх. На моем конфиге Р=2-3 получилось оптимально… Интересно если поставить НЧ фильтр в ПИД регуле уже на вычисленную высоту?

У меня на одном аппарате P=10 было замечателно (я видео выкладывал), на втором оказалось много - были осцилляции. Нормально стало с 5…7 и более меньшим I. guru_florida писал что P=10 у него тоже заработало сразу. Тут все зависит от характеристик ESC, моторов и винтов, и ручную настройку нкто не отменял.

НЧ фильтр уже стоит - обрати внимание на работу алгоритма когда ВКЛЮЧЕН Alt Hold. Тогда PID сразу ослабляется и график высоты становится пологим (шум барометра уже не виден практически). Но вообще, можно попробовать добавить опционально несильный фильтр, если из-за высоты идет сильный шум на моторы., по идее хуже не будет.

4. с D параметром дела обстоят получше и я отвязал его от P8[PIDALT] для более понятно тюнинга

Я тоже отвяжу. Все таки все остальные PID сделаны несвязными в MultiWii, не буду нарушать традицию 😃

Но без калибровки, на акселе можно только висеть неподвижно. Если его показаниям нелзя верить пр наклоне, это плохо и для обычного полета - будет постоянно уходить level после долгого пролета и остановки.

почему левел будет плыть? если ты про температурный дрейф, то да, а так не вижу причин… т.е. вектор вычисленный по гиро будет скоректирован акселем, который четко видит землю после остановки…

Да, все верно эта коререкция при торможении работает неправильно. Сложный аэродинамичский эффект. Но я знаю как его скомпенсировать правильно - ведь информация, ускоряемся ли мы или тормозим, у нас есть по углу между акселем и гирой. При торможении надо даже обращать знак у коррекции по углу, т.к. выброс тяги очень сильный. Эта фича конечно не так важна для полетов, но интересно с ней все же разобраться.

все верно. по идее знак тяги нужно менять, когда детектим торможение… осталось правильно задетектить 😃

Смысл в том, что при наклоне например на 90 град. уже нет смысла отнимать I-часть от оси Z - она уже не участвует в опредении высоты. Зато участвет ось X, у которой ноль может быть смещен с гораздо большей вероятностью (из-за специфики старой процедуры калибровки).

в теории да, тут все верно. у каждой оси акселя свой ноль и коректировка должна быть раздельная. НО на парактике макс. рабочие углы 30-45гр. с погрешностью в ~10-20%. Т.е. как ты увидел профит от этого в динамике я не понимаю 😃

А откалибровать нули с этой штукой очень просто - включи питание и наклони на 90гр на одну из осей. Подожди секунд 10 - ноль выставится по барометру сам. Потом наклони на другуй ось. Потом опять в центр. И все, все три I-части у нас содержат ошибку по нулям! Правда она не сохранится в EEPROM и нужно будет при замене батареи повторять.

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

if(baroMode && avgError < 5000 && sonarUsed == 0) {
err/= (6 - avgError/1000); // CMPF multiplyer 1…5
}

Ты неправильно понмаешь смысл алгоритма. Основная цель внутреннего PID - найти I и не трогать ее! Это и будет истинный ноль акселерометра. Перечитай абзац выше. Если бы мы имели абсолютно точный акселерометр - внутренний PID не нужн вообще и достаточно комплементарного фильтра.

я специално писал ITerm (PID “I”) т.к. говорил об основном/конечном PID регуляторе (который в MultiWii.ino файле), а не внутреннем. Т.е. там по делу написанно 😉
посмотри еще раз плз.

НЧ фильтр уже стоит - обрати внимание на работу алгоритма когда ВКЛЮЧЕН Alt Hold. Тогда PID сразу ослабляется и график высоты становится пологим (шум барометра уже не виден практически). Но вообще, можно попробовать добавить опционально несильный фильтр, если из-за высоты идет сильный шум на моторы., по идее хуже не будет.

Ну с этим все понятно. Я давольно подробно изучил алгоритм и просидел ни один час с графиками в ГУИ… Тут сглаживание барометра идет за счет использования компл. филтра, НО в вычисленной высоте все равно есть немалый шум, т.к. исползуется вн. пид регулятор, где его ошибка (разность баро и выч. высота) довольно сильно шумит, что накладывает шум на вычесленную скорость и на вычесленную высоту на выходе соот-но…
В общем я имелл ввиду НЧ фильтр на высоту в конечном пид регуле…

почему левел будет плыть? если ты про температурный дрейф, то да, а так не вижу причин… т.е. вектор вычисленный по гиро будет скоректирован акселем, который четко видит землю после остановки…

Сложно объяснить. Если аксель калиброван только по оси Z, то при наклоне он не будет точно указывать землю. А гироскоп под него подстроится. Но когда наклон кончится, гироскоп покажет неправильный уровень и опять понадобится время на подстройку.

все верно. по идее знак тяги нужно менять, когда детектим торможение… осталось правильно задетектить

Уже сделал, оказалась простая формула - взаимная проекция ACC на GYRO по осям X,Y: Ax*Gx + Ay*Gy. Очень приблизительно отражает аэродинамику коптера в боковом ветре при движении в разных фазах. Если выводить точную формулу - то это кандидатскую писать 😃 В руках погонял - работает вроде, надо только пропорцию подогнать.

Т.е. как ты увидел профит от этого в динамике я не понимаю

Ну вот ты писал у тебя коптер на 5 метров улетает когда наклоняется. Это как раз из-за неточных нулей по X, Y. Профит небольшой но есть, а сложности не сильно добавляет (на четтыре вычисления больше).

я специално писал ITerm (PID “I”) т.к. говорил об основном/конечном PID регуляторе (который в MultiWii.ino файле), а не внутреннем. Т.е. там по делу написанно
посмотри еще раз плз.

Да, извини не понял. Я тоже заметил, что с большим I осцилляции сильнее. Согласен насчет баро, но подумай, может его вообще убрать - сонару он тоже не сильно нужен. Iterm нужен для достижения точного целевого значения, но у нас целевое значение не так важно, можно зафиксироваться и чуть выше/ниже. Я оставлю код, а занулить его можно в GUI. Ещё он важен, если изменится отдача моторов или масса в режиме удержания. Например на коптер рюмку водки поставить 😃 Без I просядет сильно и не вернется 😃

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

if(baroMode && avgError < 5000 && sonarUsed == 0) {
err/= (6 - avgError/1000); // CMPF multiplyer 1…5
}

этого не понял. Наоброт при калибровке нужен сильный PID чтоы быстро найти Iterm, а при реалном исползовании уже надо ослаблять барометр. Сонар можно оставить на сильном PID, т.к. он достаточно точен (точнее акселерометра).

В общем я имелл ввиду НЧ фильтр на высоту в конечном пид регуле…

А насколько НЧ? Например при начале движения или порыве ветра, а также пр турбуленциях на посадке, надо достаточно быстро отрабатывать высоту, а НЧ внесет задержку фазы.

Сложно объяснить. Если аксель калиброван только по оси Z, то при наклоне он не будет точно указывать землю. А гироскоп под него подстроится. Но когда наклон кончится, гироскоп покажет неправильный уровень и опять понадобится время на подстройку.

При высоком GYR_CMPF_FACTOR (у меня 400) КФ почти не смотрит на аксель. И после долгих “крутых пике” погрешность будет практически полностью обусловленна дрейфом гиро… всего 2-5гр обычно, что корректится в итоге за 2-3 сек в покое по акселю…
А если уж говорить сугубо про погрешность, которая вносится акселем, то при сложных и затяжных маневрах серия ускорений (которая будет восприниматься в ИМУ как наклон) может дать гораздо больший эффект. Хотя и от этого эффекта есть защита в ИМУ:

  // Apply complimentary filter (Gyro drift correction)
  // If accel magnitude >1.4G or <0.6G and ACC vector outside of the limit range => we neutralize the effect of accelerometers in the angle estimation.
  // To do that, we just skip filter, as EstV already rotated by Gyro
  if ( ( 36 < accMag && accMag < 196 ) || smallAngle25 )

но даже она вроде как не нужна при высоком GYR_CMPF_FACTOR…
Помнится когда мы с ziss_dm давили бенефитами использования флоат фильтра для акселя на АлексаВПариже, смотрел его (ziss_dm) версию ИМУ. Он убрал эту защиту за ненадобностю при GYR_CMPF_FACTOR=500…

Уже сделал, оказалась простая формула - взаимная проекция ACC на GYRO по осям X,Y: Ax*Gx + Ay*Gy. Очень приблизительно отражает аэродинамику коптера в боковом ветре при движении в разных фазах.

тут мало что понял… распиши подробнее… при торможении/резком маневре по идее невозможно распознать где угол наклона, а где ускорение… этож вроде известная нерешаемая задача… или не так?

Да, извини не понял. Я тоже заметил, что с большим I осцилляции сильнее. Согласен насчет баро, но подумай, может его вообще убрать - сонару он тоже не сильно нужен. Iterm нужен для достижения точного целевого значения, но у нас целевое значение не так важно, можно зафиксироваться и чуть выше/ниже. Я оставлю код, а занулить его можно в GUI. Ещё он важен, если изменится отдача моторов или масса в режиме удержания. Например на коптер рюмку водки поставить Без I просядет сильно и не вернется

ну с сонаром как раз таки имеет смысл на мой взгляд, т.к. целевая велечина довольно точна… а если точна, тогда и применение можно легко найти… например рюмку зафиксировать на удобной высоте для принятия на грудь! 😃

этого не понял. Наоброт при калибровке нужен сильный PID чтоы быстро найти Iterm, а при реалном исползовании уже надо ослаблять барометр. Сонар можно оставить на сильном PID, т.к. он достаточно точен (точнее акселерометра).

согласен… терь понял… спасибо

А насколько НЧ? Например при начале движения или порыве ветра, а также пр турбуленциях на посадке, надо достаточно быстро отрабатывать высоту, а НЧ внесет задержку фазы.

ну с макс. задержкой в 0.3-0.5 сек, т.е. частота среза 1-3гц…

• для таких порывов у нас Д есть (+ в него можно добавить ускорение для крутизниы и более резкого спада… как писал ранее), а П с учетом того что оно шумит (на bmp085) можно сделать доволно плавним и тормозным…

При высоком GYR_CMPF_FACTOR (у меня 400) КФ почти не смотрит на аксель. И после долгих “крутых пике” погрешность будет практически полностью обусловленна дрейфом гиро… всего 2-5гр обычно, что корректится в итоге за 2-3 сек в покое по акселю…

Этот высокий фактор хорошо отвязывает гиру, у меня тодже 500 стоит. Но если лететь достаточно долго - 3-4 сек, то гира все равно совместится с акселем. А тут уж все зависит от его калибровки. Если реальный ноль по XY не совпал с калиброванным, то его “сфера” возможных перемещений смещена и наклонена, и совпадает с реальностью только в точке калибровки по Z. Но стоит отметить, что для угла это не столь критично, а вот для длины вектора - ошибка калибровки по оси X,Y вылазит с пропорцией ~ err*Cos(angle). (при условии совпадения чувствительностей по осям и точной калибровки по Z). В реальности и чувтвителность не совпадает и ноль по Z плывет, что делает ошибку ещё больше.

Из-за несовпадения измеренной и истинной сфер при наклоне ускорение вылазит ±5 (мои реалные оптыты), что дает большой дрейф высоты пока не
стабилизируется.

тут мало что понял… распиши подробнее… при торможении/резком маневре по идее невозможно распознать где угол наклона, а где ускорение… этож вроде известная нерешаемая задача… или не так?

Это пока только предположение. Я разложил все векторы сил на трех этапах (ускорение - равномерное движение - торможение) и посморел, что показывает акселерометр и что гироскоп. Оказалось, что их проекции на локальную XY различаются на каждом этапе. А перемножение дает нужную коррекцию (по крайней мере совпадают 0, + и -). Я потом нарисую картинку как время будет.

ну с сонаром как раз таки имеет смысл на мой взгляд, т.к. целевая велечина довольно точна… а если точна, тогда и применение можно легко найти… например рюмку зафиксировать на удобной высоте для принятия на грудь!

Это если рассматривать сонар на идеальной плоскости. А если лететь над пересеченной местностью (что обычно и бывает), он также будет выдавать шум непредсказуемого спектралного состава… И рассматривать I-часть можно также как и для барометра - есть свои плюсы и минусы. Надо затестить, ведь его достаточно просто в ГУИ обнулить.

ну с макс. задержкой в 0.3-0.5 сек, т.е. частота среза 1-3гц…

• для таких порывов у нас Д есть (+ в него можно добавить ускорение для крутизниы и более резкого спада… как писал ранее), а П с учетом того что оно шумит (на bmp085) можно сделать доволно плавним и тормозным…

Т.е. предлагаешь фильтровть только P (т.е. фактически EstAlt), а EstVel оставить? Минусов вроде не вижу, но и плюсов тоже. Нужно точно определить, зачем это нужно. У меня с барометром на графике EstAlt довольно плавная, и никакой паразитной перекомпенсаци в +/- на моторы не идет (гораздо сильнее например обычная стабилизаия угла их дергает). Пришли скриншот или видео своего GUI в момент стабилизации по барометру.

2. есть идея ITerm (PID “I”) составляющую ПИД регуля отключать в баро режиме, т.к. она довольно медленная и только вносит путаницу в результат AltPID, т.к. даже на выходе интегратора высота шумит в диапазоне метра (с bmp085) и шумит гораздо быстрее результата ITerm. В итоге I стремится непонятно к чему и имеет неактуальное значение, т.к. целевая величина прыгает постоянно… В общем я занулил ее и вроде как диапазон плавания уменьшился…

Повисев сегодня ещё минут 30, выяснил пользу от I - она нужна для перехода с соанара на барометр. Из-за разных PID
P-часть может достаточно сильно увеличиваться при проседании батаери со временем, и при переходе и смене коэффициента усиления, проиcходит прыжок вверх или вниз.
Если будет I, то P останется в районе 0 даже при падении напряжения, только I-часть не надо умножать на SONAR_BARO_PID_GAIN. Ещё разделил её на 5, чтобы сделать её достаточно медленной (тогда она вроде не будет осциллировать).

Долго не мог понять, почему при полете по барометру при посадке или приближении к земле на 30 см начинает кобасить вверх-вниз до полутора метров… Сегодня посмотрел, что же показывает барометр у земли - он думает, что высота падает на 1м ниже пола 😃 Это из-за зоны повышенного давления под коптером при приближении к земле. Так что взлет и посадка - только по сонару.

Ещё нашел проблемку с сонаром: чем выше высота, тем больше вероятность подлянки с его стороны. Если сонар начнет выдавать постояную высоту скажем в 1 метр на высоте в три метра, то коптер очень бодро устремится в небо и ничего его не остановит 😦 Буду делать ограничитель “земли по барометру”, т.е. барометр по прежнему необходимо корректировать сонаром, но в ограниченных пределах (+/-1 метр) от точки отсчета при старте.

в кролике прошивке до 1.101 сонар работает до 1500см, в 1.200 2000, дальше вырубается)

начал лепить OSD Сайбериановый в MultiWii, и не пойму откуда взять высоту от земли и в каких она попугаях (EstAlt?) и есть ли она вообще?

начал лепить OSD Сайбериановый в MultiWii, и не пойму откуда взять высоту от земли и в каких она попугаях (EstAlt?) и есть ли она вообще?

В оригинале высота - это показания барометра в см (вроде бы). Но высота не выверена по земле, и может быть например -70м. Так что при старте моторов нужно сохранить текущее значение EstAlt и потом отнимать его от новых показаний. Это и будет высота над землей. www.multiwii.com/forum/viewtopic.php?f=8&t=1351

В моей версии, EstAlt в см. Она обнуляется при запуске системы, только если включен сонар. Если сонара нет, от и смысла не было барометр к чему то привязывать.