Создание собственной системы стабилизации

alexeykozin

я все понял, понятно что речь про обратную связь, но это не исключает что причиной больших значений этого интегратора может служить неверная калибровка акселя… или вибрации…

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

DChernov

Алексей, а не может ли быть отсутствие “коробочки” следствием неточностей в компенсации наклонов?

alexeykozin
DChernov:

Алексей, а не может ли быть отсутствие “коробочки” следствием неточностей в компенсации наклонов?

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

SergDoc
rual:

Я говорил об интеграторе ИНС ускорение-скорость-расстояние, что надо не “притягивать” скорость и расстояние ИНС к ЖПС скорости-расстоянию, а подавать ошибку ИНС-ЖПС непосредственно на вход интегратора ИНС.

про это я Алексею дня 3-4 назад говорил)))

alexeykozin:

я все понял, понятно что речь про обратную связь, но это не исключает что причиной больших значений этого интегратора может служить неверная калибровка акселя… или вибрации…

причина как раз в том, что ты не исправляешь саму ошибку интегратора, а корректируешь её позже. Ошибка остаётся и нарастает… я же тебе формулу писал - скорость конечная (исправленная) подставляется в интегрирование, а не скорость предыдущая чисто с акселя…

rual
DChernov:

не может ли быть отсутствие “коробочки” следствием неточностей в компенсации наклонов?

совершенно верно.

alexeykozin:

переместить калькуляцию инав ближе к расчету ahrs
но для этого придется опустить стабилизацию и управление моторами вниз.

Алексей, в ИНС нельзя отдельно считать ахрс и отдельно линию, точнее можно , но нужно чтоб гира и аксели были на 3-4 порядка точнее. И система должна иметь устойчивость длиной минимум в минуты. На МЕМСах АХРС и линейный экстраполятор (интегратор) ускорений должны быть внутри ИНС и взаимосвязаны.
Работает это как то так: если есть неравновесный сигнал акселя, то ИНС предполагает, что от части он вызван наклоном, отчасти линейным перемещением; смотрит на ДУС (гиру) был ли соответствующий акселю сигнал наклона, и “отбирает” у акселя пропорцию этого наклона, остаток считает линейным и интегрирует до перемещения экстраполятором; после чего сравнивает перемещение с “абсолютным” датчиком (ГНСС), разницу с обратным знаком добавляет с коэффициентом на вход к акселю. В общих чертах так…
Если не понятно завтра нарисую.

SergDoc:

про это я Алексею дня 3-4 назад говорил)))

)))
Ты сам расскажи как у тебя ИНС без ГНСС работает?

SergDoc
rual:

Ты сам расскажи как у тебя ИНС без ГНСС работает?

не работает, а тестируется ))) тут словей не хватит - тут рисовать надо, плюс я где-то потерял данные с барометра- ищу второй день - куда-то не туда ссыпаются как только инс запускаю… да и компас в 9250 - г@вно, экстренно запускаю 5883 через мпу. В защиту 9250 скажу - фильтры дус и акселя настраиваются отдельно (не верте драйверам в интернете - они слизаны с 6000) что очень мне нравится, как вариант можно ставить 6500 - тоже самое что и 9250 но без компаса, ну и к нему вешать 5X83

alexeykozin
rual:

Если не понятно завтра нарисую

наверное лучше нарисовать .
ведь в программировании все формально и не столько важно разделены ли инс и ахрс на раздельные программные модули.
по идее ахрс может определять положение координат для инс а линейные и центрифугальные ускорения могут исправлять горизонт в ахрс
в самом деле у арду весьма точно работает 3д гирскоп, к примеру народ пробовал включать на север носом без компаса и утверждают что в полете уход не более пары градусов в минуту. кроме того коэфициент коррекции гироскопа горизонта от “акселя” регулируется коэфициентом
собственно к вектору акселя логично сумировать горизонтальные ускорения для вычисления “надира” и уже к этому надиру тянуть горизонт.
в принципе в беседе с вами родилось ряд гипотез которые нетерпится проверить. но для теста нужен стенд чтобы поставить контроллер на рельсовые направляющие и погонять в ускорениях не нарушая горизонтальности

DChernov
alexeykozin:

рельсовые направляющие и погонять в ускорениях не нарушая горизонтальности

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

alexeykozin
SergDoc:

Неужели ST гироаксели делать научились? www.st.com/web/catalog/sense_...C1946/PF261361 - это анонс…

а каие там ADC? раздельные или переключаемые? разрешение?

MPU6000
features three 16 bit analog to digital converters (ADCs) for digitizing the gyroscope
outputs and three 16 bit ADCs for digitizing the accelerometer outputs

SergDoc

нее… мпу я изменять не собираюсь))) разве что только с adxrs )))

alexmos
SergDoc:

нее… мпу я изменять не собираюсь))) разве что только с adxrs )))

А какой из MPU?
Я слышал мнение, что самый продвинутые сенсоры у Frescale, по датащиту так и есть. Кто-нибудь сравнивал с MPU6500 и гирами от ST?

rual
alexeykozin:

наверное лучше нарисовать .

Картинку приложил, взята из неплохой методички kafpson.kpi.ua/bins1.pdf
Красным выделена как раз схема коррекции положения от ГНСС, а ты Алексей, как я понял говорил про блок 5, тот что осредняет смещение осей акселя, включая g.

При этом сигналы скорости и радиус вектор, которые входят в блок 2 влияют на вычисление ориентации.

alexeykozin:

по идее ахрс может определять положение координат для инс а линейные и центрифугальные ускорения могут исправлять горизонт в ахрс

Да, если АХРС представляет собой только угловой интегратор сигналов с гиры, я же не хочу разделять ахрс и инс, ибо там много взаимосвязей, и для меня это идеологически единая система, а ахрс и инс это только выходные функции ориентации и кинематики соответсвенно. Чистая ахрс дает истинную ориентацию только ограниченное время или длительно в состоянии покоя.

alexeykozin:

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

дык при длительных поворотах истинный курс легко привязывается к вектору движения через отслеживание центростремительного ускорения. Для висящего коптера не актуально, с другой стороны для него актуально использовать инерциалку и при мелких перемещениях не так важен истинный курс.

alexeykozin:

кроме того коэфициент коррекции гироскопа горизонта от “акселя” регулируется коэфициентом
собственно к вектору акселя логично сумировать горизонтальные ускорения для вычисления “надира” и уже к этому надиру тянуть горизонт.

Да, всё верно.

SergDoc
alexmos:

А какой из MPU? Я слышал мнение, что самый продвинутые сенсоры у Frescale, по датащиту так и есть. Кто-нибудь сравнивал с MPU6500 и гирами от ST?

6500 он же 9250-9255 (компАс в расчёт не берём), 6000 - как бы он не был хорош но устаревает, корпус большой и у 6500 - 9255, как уже говорил фильтры дус и акселей раздельные…
Freescale - это который в кролике, mma-чего-то там - 12-14 битные аксели для иму зажатые фильтрами может и да но не для ins, немцы вон до сих пор летают на аналоговом от ST, но у них ДУС-ы на несколько порядков лучше, но покупать 1 по цене всего моего контроллера (а их нужно 3) как-то страшновато))) можно конечно так: docs.google.com/spreadsheets/d/…/pubhtml но это уже совсем другая история (

alexmos:

Кто-нибудь сравнивал с MPU6500 и гирами от ST?

примерно одинаково, а вот с акселями ST как-то накосячили (но не со всеми - аналоговые работают хорошо, значит в обработке и фильтрации напортачили), компасы тоже ничего - можно сказать содраны с HMC

rual:

Да, всё верно.

ты хотел ответ - вот по твоей картинке выкидываем ГНСС, перед первым интегратором всовываем адаптивный фильтр (раньше нет смысла петля иму будет медленная) с учётом вектора управления (обратная связь с ПИД-а)…
фильтр примерно так работает:
получили данные - предсказали положение, получили следуюшие данные - ух-ты ёпрст - промахнулись с предсказанием - поменяли коэффициенты, вектор управления тоже обязателен иначе не будем знать или это мы полетели или сам…

alexeykozin

мануал и схему буду тщательно изучать, сходу проникнуться неполучилось.

Тимур облетывает мои эксперименты по построению инерциалки (за что ему преогромнейшее спасибо)
вот что он обнаружил - что достаточно спокойное поведение при входе в удержание позиции из нулевой скорости
но очень плохой эффект если в режиме удержания позиции попробовать разогнаться и резко тормознуть - начинается раскачка.
мои наблюдения таковы- у данной системы есть частота собственных колебаний!
причем ка не меняй коэфициенты притяжки частота меняется мало.
приблизительная частота 1/5 герца . тоесть цикл за 5 секунд.

идея в том что неспроста в родном арду коде хранится история ошибки учитывающая задержку жпс данных.
чтто получается - у меня идет подтяг к отстающей позиции жпс (как минимум переодически ошибка сотсавляет 0,2 сек т.к. используется частота обновления жпс 5 гц) при этом подтяг к устаревшей позиции приводит к нарастанию обратной скорости инав, за это время жпс дает отставшие данные по позиции “вперед” но коптер уже удетел назад и подтяг начинает обратную работу - отсюда источник раскачки…

пока не разобрался в принципе работы интегратора Александра Русакова, возможно он и позвляет корректировать позицию не к чистым жпс данным а к данным жпс + краткосрочный прогноз инав за короткое время определенное временем задержки данных жпс модуля.
поскольку основное свойство инерциалки - достоверность результата обратно пропорциональна времени измерения,
т.е. гипербола где по оси икс время а по игреку - достоверность.
поскольку за короткое время задержки жпс данных данные инерциалки не успеют устареть то думаю попробовать такой вариант подтяга

вместо
инав_позиция = инав_позиция * 0.998 + жпс_позиция * 0.002

на
инав_позиция = инав_позиция * 0.998 + (жпс_позиция + прогноз_инав_за_время_задержки_жпс) * 0.002

аналогично со скоростью
пока вопрос в выборе незатратного алгоритма.
решение в лоб - сохранять ускорения и dt в массиве,
считать прогноз за константу времени задержки жпс (константу определить экспериментально)
т.е
суммировать ускорения из массива истории пока DT не достигнет времени задежки жпс
дельта позиция = at**2
дельта скорость = at
но имхо просядет производительность

SergDoc
alexeykozin:

но очень плохой эффект если в режиме удержания позиции попробовать разогнаться и резко тормознуть - начинается раскачка.

вот о чём я говорил выше - нет обратной связи с управлением==ошибка расчёта… ты реально предсказываешь положение для команды на ПИД - но ты не знаешь предыдущей реакции ПИД

alexeykozin

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

SergDoc

Амортизатором служит только дифференциальная часть - всё остальное это по сути управление… Так вот вернёмся к КУК-у там как раз угловая скорость служит пропорцией угол- интегральной составляющей - развивая дальше мысль, можно пересмотреть пид для инерциалки, где скорость будет служить пропорцией, путь - интегральной составляющей, а ускорение дифференциальной! Главное в этом то, что нет лишних интеграторов!

alexeykozin

ИМХО
если говорить о “идеальной инерциалке” должны быть не P I D смешивания датчиков а коэфициенты к лагам компонетов системы.
к примеру знаем что жпс запаздывает на 0,1 или 0,2 сек и компенсируем это
знаем скорость деградации инерциальной скорости по времени - принимаем ее изменения в пропорции с достоверностью

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

SergDoc

лаг ЖПС у тебя перекрывается уже здесь: инав_позиция = инав_позиция * 0.998 + жпс_позиция * 0.002 и служит это дело для долгосрочной коррекции “уплывания” интегратора и совершенно пофиг, что оно лагает пока ЖПС “доплывёт” до пределов способных существенно влиять на интегратор - оно усреднится так, что мама не горюй… короче показания будут правдоподобны…

rual
SergDoc:

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

Вот, золотые слова!

alexeykozin:

знаем скорость деградации инерциальной скорости по времени - принимаем ее изменения в пропорции с достоверностью

Как раз “угадывающие” фильтры с этим борятся, экстраполируя первообразные из производных, полученных с “быстрых” датчиков (ускорение, угловая сскорость/ускорение), подбирают коэффициенты экстраполятора по результатам сравнения с “медленными” датчиками абсолютных величин (скрость, путь, высота). В ПИДе экстраполятором является компонент И, демпфером Д.