Создание собственной системы стабилизации
соственно просьба помочь советом
Нужно весь интегратор обвязать петлей ОС через ПД-регулятор, т.е. velocity_increase.x = accel_ef.x * dt + _position_correction.x *p - delta(_position_correction.x) *d ;
без промежуточной коррекции скорости, петля сама её выровняет пропорционально dt, p и d
спасибо Александр, возможно имеет смысл сделать обратную связь, но я глубоко убежден, без дополнительной коррекции от жпс не обойтись.
я анализировал множество логов полета ардукоптера где изза отсутствия корекции скорости от жпс присходила сильнейшая деградация в случае минимальных ошибок компаса или ошибки определения магнитного склонения.
тоесть ошибка компаса в 5-7 градусов приводит к сильнейшей деградации инерциальной скорости. и в результате получается “унитазинг”
в результате “мастера” конечно же сделают коптер чтобы он летел стабильно, но при применении в широких массах “это не летит”
без дополнительной коррекции от жпс не обойтись.
Дык я и не призываю отказаться от коррекции, я говорил что петля коррекции должна начинаться с интеграции ускорения, а скорость и позицию ОТДЕЛЬНО корректировать не надо, коррекция должна входить в интегратор ВМЕСТЕ С АКСЕЛЕМ. _position_correction.x - вот это как я понял как раз есть разность между жпс и ИНС
для коптера тоже важна аэродинамика расположения датчика
Под брюшком лучше?
Ещё пеной залепляют, видел…
delta(_position_correction.x)
float delta( float position_correctionx)
{
static float position_correctionx_old;
float ret;
ret = position_correctionx - position_correctionx_old;
position_correctionx_old = position_correctionx;
return ret;
}
это имелось в виду?
каков может быть диапазон p,d для начала?
это имелось в виду?
да, диффошибка положения = скорость (изменения положения)
каков может быть диапазон p,d для начала?
у меня p=d =0.1f , только само d = kd/dt. увеличение kd добавляет ВЧ на выходе фильтра, т.е. мгновенную ошибку, уменьшение приводит к “болтанию” положения. Всё как с обычным ПИД.
поскольку на высокой скорости инерциалка нужна существенно меньше, а сама скорость жпс более достоверна, решил пока попробовать увеличивать подтяг в зависимости от скорости
// speed 0-100 cm per second spd_kff = 1 200=2 300 and above = 3
float spd_kff =mapf(constrain(fabs(pythagorous2(_velocity.x, _velocity.y)), 100.f, 300.f) ,100.f ,300.f , 1.f , 3.f );
т.е. для 0-100 см надбавка “1” от метра в секунду до 3 пропорционально от1 до 3. свыше 3 мс подтяг утраивается.
ставил эксперимент - идеально калибровал аксели по уровню в неподвижности.
отключил подтяг и наблюдал как уплывает позиция. на одном боку в одну сторону плывет на другом в другую…
собственно - это мотив к интегратору с обратной связью, но возможно общее значение интегратора следует ограничить каким нибудь IMAX ибо слишком большой накопленный интегратор может негативно сказываться при переваливании с одного боку на другой
собственно - это мотив к интегратору с обратной связью, но возможно общее значение интегратора следует ограничить каким нибудь IMAX ибо слишком большой накопленный интегратор может негативно сказываться при переваливании с одного боку на другой
Алексей, ты меня не понял. Я имел ввиду не интегратор ошибки, который даст среднее смещение акселя. Я говорил об интеграторе ИНС ускорение-скорость-расстояние, что надо не “притягивать” скорость и расстояние ИНС к ЖПС скорости-расстоянию, а подавать ошибку ИНС-ЖПС непосредственно на вход интегратора ИНС.
я все понял, понятно что речь про обратную связь, но это не исключает что причиной больших значений этого интегратора может служить неверная калибровка акселя… или вибрации…
результаты расчтета ускорений, скорости, перемещений вывел в телеметрию но…
пока нахожу странным что несмотря на то что аксель достаточно точный неполучается у меня нарисовать “проход по коробочке” при перемещении по комнате по квадрату метр на метр
Алексей, а не может ли быть отсутствие “коробочки” следствием неточностей в компенсации наклонов?
Алексей, а не может ли быть отсутствие “коробочки” следствием неточностей в компенсации наклонов?
думал Дим.
и даже идея одна есть!
переместить калькуляцию инав ближе к расчету ahrs
но для этого придется опустить стабилизацию и управление моторами вниз.
при этом изменятся пиды изза задержки команды моторам от изменения угла, но в принципе должно быть летабельно т.к. и на 50 гц сигнале можно настроить а тут весь луп с частотой 100гц идет
Я говорил об интеграторе ИНС ускорение-скорость-расстояние, что надо не “притягивать” скорость и расстояние ИНС к ЖПС скорости-расстоянию, а подавать ошибку ИНС-ЖПС непосредственно на вход интегратора ИНС.
про это я Алексею дня 3-4 назад говорил)))
я все понял, понятно что речь про обратную связь, но это не исключает что причиной больших значений этого интегратора может служить неверная калибровка акселя… или вибрации…
причина как раз в том, что ты не исправляешь саму ошибку интегратора, а корректируешь её позже. Ошибка остаётся и нарастает… я же тебе формулу писал - скорость конечная (исправленная) подставляется в интегрирование, а не скорость предыдущая чисто с акселя…
не может ли быть отсутствие “коробочки” следствием неточностей в компенсации наклонов?
совершенно верно.
переместить калькуляцию инав ближе к расчету ahrs
но для этого придется опустить стабилизацию и управление моторами вниз.
Алексей, в ИНС нельзя отдельно считать ахрс и отдельно линию, точнее можно , но нужно чтоб гира и аксели были на 3-4 порядка точнее. И система должна иметь устойчивость длиной минимум в минуты. На МЕМСах АХРС и линейный экстраполятор (интегратор) ускорений должны быть внутри ИНС и взаимосвязаны.
Работает это как то так: если есть неравновесный сигнал акселя, то ИНС предполагает, что от части он вызван наклоном, отчасти линейным перемещением; смотрит на ДУС (гиру) был ли соответствующий акселю сигнал наклона, и “отбирает” у акселя пропорцию этого наклона, остаток считает линейным и интегрирует до перемещения экстраполятором; после чего сравнивает перемещение с “абсолютным” датчиком (ГНСС), разницу с обратным знаком добавляет с коэффициентом на вход к акселю. В общих чертах так…
Если не понятно завтра нарисую.
про это я Алексею дня 3-4 назад говорил)))
)))
Ты сам расскажи как у тебя ИНС без ГНСС работает?
Ты сам расскажи как у тебя ИНС без ГНСС работает?
не работает, а тестируется ))) тут словей не хватит - тут рисовать надо, плюс я где-то потерял данные с барометра- ищу второй день - куда-то не туда ссыпаются как только инс запускаю… да и компас в 9250 - г@вно, экстренно запускаю 5883 через мпу. В защиту 9250 скажу - фильтры дус и акселя настраиваются отдельно (не верте драйверам в интернете - они слизаны с 6000) что очень мне нравится, как вариант можно ставить 6500 - тоже самое что и 9250 но без компаса, ну и к нему вешать 5X83
Если не понятно завтра нарисую
наверное лучше нарисовать .
ведь в программировании все формально и не столько важно разделены ли инс и ахрс на раздельные программные модули.
по идее ахрс может определять положение координат для инс а линейные и центрифугальные ускорения могут исправлять горизонт в ахрс
в самом деле у арду весьма точно работает 3д гирскоп, к примеру народ пробовал включать на север носом без компаса и утверждают что в полете уход не более пары градусов в минуту. кроме того коэфициент коррекции гироскопа горизонта от “акселя” регулируется коэфициентом
собственно к вектору акселя логично сумировать горизонтальные ускорения для вычисления “надира” и уже к этому надиру тянуть горизонт.
в принципе в беседе с вами родилось ряд гипотез которые нетерпится проверить. но для теста нужен стенд чтобы поставить контроллер на рельсовые направляющие и погонять в ускорениях не нарушая горизонтальности
рельсовые направляющие и погонять в ускорениях не нарушая горизонтальности
Может быть, просто повозить по периметру прямоугольной коробки, прижимая к дну и последовательно к стенкам?
Неужели ST гироаксели делать научились? www.st.com/web/catalog/sense_power/…/PF261361 - это анонс…
Неужели 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
нее… мпу я изменять не собираюсь))) разве что только с adxrs )))
нее… мпу я изменять не собираюсь))) разве что только с adxrs )))
А какой из MPU?
Я слышал мнение, что самый продвинутые сенсоры у Frescale, по датащиту так и есть. Кто-нибудь сравнивал с MPU6500 и гирами от ST?
наверное лучше нарисовать .
Картинку приложил, взята из неплохой методички kafpson.kpi.ua/bins1.pdf
Красным выделена как раз схема коррекции положения от ГНСС, а ты Алексей, как я понял говорил про блок 5, тот что осредняет смещение осей акселя, включая g.
При этом сигналы скорости и радиус вектор, которые входят в блок 2 влияют на вычисление ориентации.
по идее ахрс может определять положение координат для инс а линейные и центрифугальные ускорения могут исправлять горизонт в ахрс
Да, если АХРС представляет собой только угловой интегратор сигналов с гиры, я же не хочу разделять ахрс и инс, ибо там много взаимосвязей, и для меня это идеологически единая система, а ахрс и инс это только выходные функции ориентации и кинематики соответсвенно. Чистая ахрс дает истинную ориентацию только ограниченное время или длительно в состоянии покоя.
в самом деле у арду весьма точно работает 3д гирскоп, к примеру народ пробовал включать на север носом без компаса и утверждают что в полете уход не более пары градусов в минуту.
дык при длительных поворотах истинный курс легко привязывается к вектору движения через отслеживание центростремительного ускорения. Для висящего коптера не актуально, с другой стороны для него актуально использовать инерциалку и при мелких перемещениях не так важен истинный курс.
кроме того коэфициент коррекции гироскопа горизонта от “акселя” регулируется коэфициентом
собственно к вектору акселя логично сумировать горизонтальные ускорения для вычисления “надира” и уже к этому надиру тянуть горизонт.
Да, всё верно.