MultiWii - обсуждаем и отлаживаем Alt Hold
Залил, настроил, в GUI все работает отлично, аксель по шести точкам показывает примерно ±255, сонар точно показывает высоту, при запуске в руках и небольшом газе задний левый мотор пуляет и ставит коптер под 45 градусов и успокаивается, онлайн в GUI посмотреть в чем дело не могу, с этой прошивкой почему то не работает блютус. Похоже на неправильную калибровку акселя, но в статике в гуи то все нормально , рол и питч стоят ровно.
вылазит ошибка ( echo повесил на D12) , как вернуть работу второго тумблера?
Видимо Aux2 заведен через неиспользуемое ранее прерывание, которое нужно сонару. У меня использует SumPPM и прерывание свободно, я его и взял на сонар. Насколько я знаю, на 328p больше их не осталось. Давайте посмотрим как зарулят сонар в официальной версии. Сейчас - либо SumPPM либо отказаться от AUX2
Залил, настроил, в GUI все работает отлично, аксель по шести точкам показывает примерно ±255, сонар точно показывает высоту
Тут все правильно.
при запуске в руках и небольшом газе задний левый мотор пуляет и ставит коптер под 45 градусов и успокаивается, онлайн в GUI посмотреть в чем дело не могу, с этой прошивкой почему то не работает блютус. Похоже на неправильную калибровку акселя, но в статике в гуи то все нормально , рол и питч стоят ровно.
А зачем блютус, я тестирую через кабель (если держать в руках). Если AltHold не включен, то все остальные алгоритмы работают как и в стандртной прошивке, туда я не лез. Если ROLL и PITCH ровно стоят и отражают реальные налоны, то и аксель откалиброван верно. Нужно обязательно смотреть что происходит в GUI при включенных моторах.
Видимо Aux2 заведен через неиспользуемое ранее прерывание, которое нужно сонару. У меня использует SumPPM и прерывание свободно, я его и взял на сонар
Понял, приемник с РРМ имеется, воткну его, ну а блютус как бы уже установлен и прекрасно работает, с ним гораздо удобней!
Давайте посмотрим как зарулят сонар в официальной версии.
Сонар будет в официалке?! Барометр до сих пор в официалке никакой, почувствовал работу барометра пока что только в MultiWii_1_9_a2 от mahowik.
блютус как бы уже установлен и прекрасно работает, с ним гораздо удобней!
И заливать прошивку с ним научился? Я тоже прикрутил блютус для отладки, но на поле когда отошел подальше от ноута, коптер пару раз сходил с ума (хорошо что в руках был на тот момент). Подозреваю что при увеличенни дистанции блютус увеличивает мощность и забиавает р/у канал (частоты то одинаковые). Так что очень настороженно теперь к нему отношусь.
Сонар будет в официалке?! Барометр до сих пор в официалке никакой, почувствовал работу барометра пока что только в MultiWii_1_9_a2 от mahowik.
Рано или поздно будет, сейчас на оф.форуме обсуждается активно.
И заливать прошивку с ним научился? Я тоже прикрутил блютус для отладки, но на поле когда отошел подальше от ноута, коптер пару раз сходил с ума (хорошо что в руках был на тот момент). Подозреваю что при увеличенни дистанции блютус увеличивает мощность и забиавает р/у канал (частоты то одинаковые). Так что очень настороженно теперь к нему отношусь.
Нее, когда лью прошивку выдергиваю блютус из Crius MultiWii и пихаю USB-UART FT232RL , на поле не знаю как (холодно и не удобно с нотиком), в помещении отпускал не более чем на 5 метров, блютус не дурил.
Чет не получается у меня с акселем в MultiWii_r15, коптер встает криво и все тут, кстати заметил что после калибровки по шести точкам в GUI тоже стоит криво, нужно прогнать еще кажется по двум-трем дополнительно, наверно в этом дело, буду ждать официалку, очень понравилось как сонар точно выдает высоту в GUI.
Можете не калибровать по 6 точкам, можно как и раньше, по Z один раз. Попробуйте так и напишите что получится.
Можете не калибровать по 6 точкам, можно как и раньше, по Z один раз. Попробуйте так и напишите что получится.
Отцепил я уже сонар, пришло недостающее крепление к давно собранному подвесу, буду экспериментировать с ним.
Привет Алексей!
Сорри за паузу… выпал немного из контекста…
Неделю назад вмержил r15 в MultiWii_dev_20120225, но без калибровки по 6-ти осям…
в ГУИ скрость ведет себя не стабильно, т.е. при полном покое (0, 0, +128) иногда плавно уходит в +/-60…100. Такое ощущение что ПИД регулятор в интеграторе не может стабилизироваться. Предположив что в динамике/полете этого не будет, чуть не улетел в небо пару раз )), т.е. примерно тоже поведение, как описывал чел на офф. форуме…
Я когда ранее переводил твой интегратор (его более раннюю и простую версию) на 50гц, наблюдал похожее поведение “по скорости” при определенних сочетаниях коэф-в. Т.е. я к тому что вероятно коэф-ы интегратора не оптимальны сейчас, либо у тебя сейчас жесткая привязка к +/-255, т.к. у меня acc_1g=128.
Могу выложить результат мержа, не исключено что я накосячил гдето…
Вообще если не трудно, опиши изменения в алгоритме, т.к. ты его значительно усложнил (сейчас он менее прозрачен) и возможно там бомба в коде… ))
з.ы. твои идеи однозначно сильны, потому есть смысл довести до конца… марбалоновский альт холд у меня вообще не работает, при малейшем ветерке носит коптер как Г в проруби…
т.е. доведем до конца тогда мот и в офф. прошиву пропихнем, т.к. “для себя” это круто конечно, но отдача будет многократной, когда на этом будет летать все вии сообщество 😉
Я тоже выпал - то работа, то здоровье шалит, то новый квадрик делал помельче (чтоб в ограниченном пространстве летать). Сейчас все готово и даже камеру прикрутил, так что скоро будет видео, как погода наладится.
в ГУИ скрость ведет себя не стабильно, т.е. при полном покое (0, 0, +128) иногда плавно уходит в +/-60…100
Во первых новость, что бывает 1G = 128. Надо посмотреть код, может я где константу 255 (или что то подразумевающее 255) использую.
Я залил на новую платформу прошивку, там все абсолютно другое, датчики и электроника (Crius MWC) но так же с первого раза с первыми же PID стабилизирует высоту отлично.
иногда плавно уходит в +/-60…100
А что показывает барометр при этом? Сейчас фактически два набора внутренних PID - когда AltHold режим не включен, высота почти что чисто с барометра берется и следует за ним. Этого достаточно чтобы при включении и подлете устранить постоянную ошибку. Когда включается режим, то PID меняется и работает акселерометр уже более “чисто”. Т.е. коптер даже с сильной привязкой к высоте плавает медленно, и любое возмущеие отслеживает агрессивно.
Могу выложить результат мержа, не исключено что я накосячил гдето…
Выложи, я ужее давно просил. На SVN удобно.
Кстати я тоже планирую мержить, как новая версия, уже достаточно стабильна? прежняя 1.9 мне нравится, не хочется рисковать 😃
Вообще если не трудно, опиши изменения в алгоритме, т.к. ты его значительно усложнил (сейчас он менее прозрачен) и возможно там бомба в коде… ))
Изменения описывал: rcopen.com/forum/f123/topic265409/53 Новых пока нет.
з.ы. твои идеи однозначно сильны, потому есть смысл довести до конца… марбалоновский альт холд у меня вообще не работает, при малейшем ветерке носит коптер как Г в проруби…
Неудивительно, неоткуда взять D-часть. хотя может силная привязка и не всем нужна.
т.е. доведем до конца тогда мот и в офф. прошиву пропихнем
Ну это было бы здорово т.к. чем меньше различий тем мне проще потом мержиться 😃 Но боюсь в таком виде не примут (и цикл надо уменьшать и оТ такого кол-ва float избавляться). Все в планах, но вот времени маловато.
Я вот потестировал платку с Гудлака. Со своим кодом пробовал отлаженный алгоритм по фильтрации баро с акселерометром. Алгоритм испытан на 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м.
Теперь по новому алгоритму:
- зачем вычислять ошибку для каждой из осей, а потом при расчете 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));
-
есть идея ITerm (PID “I”) составляющую ПИД регуля отключать в баро режиме, т.к. она довольно медленная и только вносит путаницу в результат AltPID, т.к. даже на выходе интегратора высота шумит в диапазоне метра (с bmp085) и шумит гораздо быстрее результата ITerm. В итоге I стремится непонятно к чему и имеет неактуальное значение, т.к. целевая величина прыгает постоянно… В общем я занулил ее и вроде как диапазон плавания уменьшился…
Второй вариант пробовать повысить “скорость” I составляющей…
з.ы. для сонара или более точного баро I безусловно полезна, т.к. целевая величина явно присутствует 😃 -
P=10 слишком много, т.к. опять же вычисленная высота постоянно плавает +/- полметра-метр и это дает оч. большую компенсацию, хотя физически высота не меняется, отсюда большое беспричинное упр-е воздействие на моторы и дерганье постоянное вниз-вверх. На моем конфиге Р=2-3 получилось оптимально… Интересно если поставить НЧ фильтр в ПИД регуле уже на вычисленную высоту?
-
с 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м.
Да, все верно эта коререкция при торможении работает неправильно. Сложный аэродинамичский эффект. Но я знаю как его скомпенсировать правильно - ведь информация, ускоряемся ли мы или тормозим, у нас есть по углу между акселем и гирой. При торможении надо даже обращать знак у коррекции по углу, т.к. выброс тяги очень сильный.
Эта фича конечно не так важна для полетов, но интересно с ней все же разобраться.
- зачем вычислять ошибку для каждой из осей, а потом при расчете accZ “собирать” ее обратно (применение описанное в TODO в расчет не берем)? Визуально без трех осевой калибровки и без разложения ошибки по осям (старая версия алгоритма), кривая скорости и ускорения более плавная (или красивая чтоль) + время вычисления меньше, что актуально при интегрировании не в каждой итерации цикла…
Это мое ноу-хау, и оно очень полезно на самом деле. Только с ней я получил полную инвариантность высоты при наклонах на НЕ ОТКАЛИБРОВАННОМ акселерометре.
Смысл в том, что при наклоне например на 90 град. уже нет смысла отнимать I-часть от оси Z - она уже не участвует в опредении высоты. Зато участвет ось X, у которой ноль может быть смещен с гораздо большей вероятностью (из-за специфики старой процедуры калибровки).
А откалибровать нули с этой штукой очень просто - включи питание и наклони на 90гр на одну из осей. Подожди секунд 10 - ноль выставится по барометру сам. Потом наклони на другуй ось. Потом опять в центр. И все, все три I-части у нас содержат ошибку по нулям! Правда она не сохранится в EEPROM и нужно будет при замене батареи повторять.
- есть идея ITerm (PID “I”) составляющую ПИД регуля отключать в баро режиме, т.к. она довольно медленная и только вносит путаницу в результат AltPID, т.к. даже на выходе интегратора высота шумит в диапазоне метра (с bmp085) и шумит гораздо быстрее результата ITerm. В итоге I стремится непонятно к чему и имеет неактуальное значение, т.к. целевая величина прыгает постоянно… В общем я занулил ее и вроде как диапазон плавания уменьшился…
Второй вариант пробовать повысить “скорость” I составляющей…
з.ы. для сонара или более точного баро I безусловно полезна, т.к. целевая величина явно присутствует
Ты неправильно понмаешь смысл алгоритма. Основная цель внутреннего PID - найти I и не трогать ее! Это и будет истинный ноль акселерометра. Перечитай абзац выше. Если бы мы имели абсолютно точный акселерометр - внутренний PID не нужн вообще и достаточно комплементарного фильтра.
- P=10 слишком много, т.к. опять же вычисленная высота постоянно плавает +/- полметра-метр и это дает оч. большую компенсацию, хотя физически высота не меняется, отсюда большое беспричинное упр-е воздействие на моторы и дерганье постоянное вниз-вверх. На моем конфиге Р=2-3 получилось оптимально… Интересно если поставить НЧ фильтр в ПИД регуле уже на вычисленную высоту?
У меня на одном аппарате P=10 было замечателно (я видео выкладывал), на втором оказалось много - были осцилляции. Нормально стало с 5…7 и более меньшим I. guru_florida писал что P=10 у него тоже заработало сразу. Тут все зависит от характеристик ESC, моторов и винтов, и ручную настройку нкто не отменял.
НЧ фильтр уже стоит - обрати внимание на работу алгоритма когда ВКЛЮЧЕН Alt Hold. Тогда PID сразу ослабляется и график высоты становится пологим (шум барометра уже не виден практически). Но вообще, можно попробовать добавить опционально несильный фильтр, если из-за высоты идет сильный шум на моторы., по идее хуже не будет.
- с 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 сразу ослабляется и график высоты становится пологим (шум барометра уже не виден практически). Но вообще, можно попробовать добавить опционально несильный фильтр, если из-за высоты идет сильный шум на моторы., по идее хуже не будет.
Ну с этим все понятно. Я давольно подробно изучил алгоритм и просидел ни один час с графиками в ГУИ… Тут сглаживание барометра идет за счет использования компл. филтра, НО в вычисленной высоте все равно есть немалый шум, т.к. исползуется вн. пид регулятор, где его ошибка (разность баро и выч. высота) довольно сильно шумит, что накладывает шум на вычесленную скорость и на вычесленную высоту на выходе соот-но…
В общем я имелл ввиду НЧ фильтр на высоту в конечном пид регуле…