Создание собственной системы стабилизации
Что так?
Две работы, учеба
То что масштабируется плохо это да, а насчет времени вряд ли.
помню, что алгоритмы определения ориентации обсчитывались в прерывании SPI от MPU6500, от этого страдали прерывания по i2c, а когда понадобилось еще записывать буферы для логов, то пришлось разделять весь процесс на 2 части, плодить флаги, проверки. Может и стоило изобрести свой велосипед, но у этого решения больше минусов, чем использовать ОСРВ.
Кватернионы - линейная алгебра, всё должно быть линейно, кроме преобразования угловой скорости в ориентацию (там тригонометрия), но за период отчета в переделе макс угловой скорости ДУС синус линеен
Ну допустим есть вектор состояния {q0, q1, q2, q3, Vx, Vy, Vz}, где q0, q1, q2, q3 - кватернион ориентации, Vx, Vy, Vz - это проекции вектора скорости в глобальной СК. Допустим у нас есть датчик скорости, но он измеряет скорость в локальной СК vx, vy, vz. Вот с помощью каких матриц F(которая еще A) и B(при управлении) нам из кватерниона и вектора скорости локальной СК получить вектор скорости в глобальной СК? Нет таких матриц в данном контексте задачи, значит это уже нелинейная зависимость.
В принципе работа с кватернионами - не линейна, а скорее тригонометрическая, просто она красиво выражается без использования тригонометрических функций, но основание именно тригонометрия, что уже не линейно
Серёг, зачем барику бунтовать на шине?
а фиг его знает - дефект, отказался я от этой шины в мини совсем… скорей бы её запустить, а то уж больше года в “подвешенном” состоянии - нет времени домашние проблемы 😦 мини сейчас как винда 3.1.1 лежит на столе - ПО почти готово но не собираемо…
когда понадобилось еще записывать буферы для логов, то пришлось разделять весь процесс на 2 части, плодить флаги, проверки
Ну да, маневрирование задачами весьма удобно, но, повторюсь, время не экономит.
Ну допустим есть вектор состояния {q0, q1, q2, q3, Vx, Vy, Vz}, где q0, q1, q2, q3 - кватернион ориентации, Vx, Vy, Vz - это проекции вектора скорости в глобальной СК. Допустим у нас есть датчик скорости, но он измеряет скорость в локальной СК vx, vy, vz. Вот с помощью каких матриц F(которая еще A) и B(при управлении) нам из кватерниона и вектора скорости локальной СК получить вектор скорости в глобальной СК? Нет таких матриц в данном контексте задачи, значит это уже нелинейная зависимость.
Насколько я понял, речь шла о преобразовании скорости в одной СК в скорость в другой СК? А то написано из глобальной в глобальную?
Если преобразование из одной в другую, то это линейное преобразование - умножение поворачивающего кватерниона на кватернион от вектора и на обратный вращающий кватернион (V’ = qvq–1). Все это линейные матричные преобразования.
Код приложил.
Спасибо за код.
Насколько я понял, речь шла о преобразовании скорости в одной СК в скорость в другой СК? А то написано из глобальной в глобальную?
Поняли правильно, но у меня нет ошибки.
линейное преобразование - умножение поворачивающего кватерниона на кватернион от вектора и на обратный вращающий кватернион (V’ = qvq–1)
Я понимаю, но оно может и линейно в общем виде, в контексте задачи Xk = A*Xk-1 + B*U, это нелиненая зависимость и простыми матрицами A и B ее не решить. К тому же это не матричное умножение,а кватернионное.
Друзья, поздравляю всех с Наступающим! Всего самого наилучшего! Интересных проектов!
Интересных проектов!
Что там у Вас с проектами ?
От себя поздравляю всех с праздником, мира всем, здоровья, и исполнения желаний в Новом году…
Всех с наступившим. Подскажите как сделать удержание по жпс.
Делать пид по растоянию ? Алгоритм куда рулить написал , вопрос в выработке уровня и продолжительности сигнала на наклон в нужную сторону. К примеру ушли на 1 метр , надо дать короткий импульс а если 10 метров. Когда будет подлетать к точке как затормозить чтоб не перелетел ?
вопрос философский, вобщем то вся тема об этом. все модели жпс работают с некоторой задержкой поэтому данных жпс для удержания не достаточно
нужна инерциалка прогнозирующаяя и компенсирующая этот лаг.
что касается вопросов пилотирования аппарата то наклоны определяют ускорение
тоесть не перемещение и даже не скорость
грубо: считываем ускорение с акселя, высчитываем скорость и путь, корректируем их более медленным GPS - рисуем пид…
можно пофилософствовать на эту тему - берём это всё упаковываем в фильтр новомодный, только со всеми приблудами типа вектора управления с обратной связью и пытаемся отказаться от ПИД-а, потом плюём на это дело и делаем комплиментарник+ПИД)))
Привет, с наступившим! Я тут свободный денек поймал и переписал один момент в UKF, у меня GPS стоит не в центре, а немного вынесено на 20 см примерно. Вот эти самые казалось бы 20 см по сравнению с погрешностью GPS 1-5 м не должны повлиять, но они очень сильно влияют, особенно при поворотах по курсу. Так вот до этого у меня все показания с GPS корректировались проекцией на центр коптера, а потом использовались в UKF, было не очень. Сейчас что то я внезапоно подумал, и решил, что это неправильно. Надо с показаниями датчиков ничего не делать, а исправлять модель датчика то есть само уравнение h(x). то есть теперь вынос GPS учитывается в модели датчика, а сами показания поступают в UKF непостредственно. И это был решающий момент, сразу убил несколько зайцев. Во-первых теперь не надо парится о том, что GPS не находится в центре вращения вместе с акселерометром и ДУСом. GPS можно хоть на отдельную штангу вынести, надо только посчитать расстояния по всем осям и занести в модель. То есть все повороты и маневры отрабатываются с учетом новой правильной модели. Во-вторых очень важное и крутое свойство - это то что для коррекции ориентации теперь не нужно движение, как раньше, коррекция ориентации происходит через показания GPS всегда, даже когда коптер стоит на земле или завис. И это свойство я нигде не видел, а оно оказалось очень полезным. Все стараются поставить GPS в центр, а оказывается вынести его подальше становится очень полезным. Я полагаю, что я первый кто догадался использовать вынос GPS для улучшения качества стабилизации. Раньше ориентация коптера зависела от GPS только когда есть движение и коррекция происходила когда коптер двигался. Сейчас коррекция происходит всегда и даже когда движения нет. Компас теперь почти не нужен.
Раньше при резких поворотах по курсу было слышно пятигерцовые стуки от тмоторов при коррекции по GPS и было небольшое уплывание по горизонтали. Также при зависании в одной точке спусти несколько минут коптер начинал гулять, так как ориентация не корректировалась без движения. Теперь коптер четко крутится вокруг своей оси и висит в точке, просто фантастика. Короче я рад.
Но есть скользкий момент - по идее я добавил еще одну зависимость между перемнными, тем самым снизив устойчивость, если раньше некоторые переменные могли позволить себе быть некорректными и при этом коптер вел себя нормально, то сейчас косяк с одной переменной убьет всю систему. Вопрос только на сколько сильно я снизил устойчивость и как часто эти косяки будут происходить и как UKF будет их обрабатывать.
Я полагаю, что я первый кто догадался использовать вынос GPS для улучшения качества стабилизации.
Огорчу - джедаи…
А есть док-ва? просто если это казалось очевидным, и DJI давно юзают, то почему никто это больше не использует?
то сейчас косяк с одной переменной убьет всю систему
или я не о том думаю или тогда не понимаю - “кривые” данные должны автоматом выводиться из уравнения…
А есть док-ва?
ну диджейских приблуд у меня нет, но на сколько помнится есть у них настройка установки gps относительно полётника…
а никто не использует по простой причине - у каждых “контор”, так скажем, своя религия и новшества предлагаемые не очень они хотят внедрять, внедряют толко то что на слуху типа ваншотов-дэшотов всяких там полётов по кругу или следование… короче, что юзверь хочет и готов перепрыгнуть к другому производителю…
или я не о том думаю или тогда не понимаю - “кривые” данные должны автоматом выводиться из уравнения…
В идеале да, но предварительные фильтры нужно строить самому разработчику и постараться обыграть все ситуации с датчиками и их комбмнациями.
ну диджейских приблуд у меня нет, но на сколько помнится есть у них настройка установки gps относительно полётника…
Вот это уже интересно, еще интересно бы проверить используют ли они компас во время полета.
используют ли они компас во время полета
используют - это можно сказать самая больная тема у них - компас…
используют - это можно сказать самая больная тема у них - компас…
Хм, тогда я не понимаю зачем он нужен в полете. Для использования данных с компаса в полете нужно в вектор состояния вводить дополнительные биасы для компаса, что еще больше увеличит время просчета. Если использовать такую схему как я описал, то компас нужен только в начале, перед полетом, чтобы соотнести системы координат, а дальше коррекция идет по GPS.
Скользкий момент будет, когда GPS будет тупить, например близи зданий и тогда коптер может совсем с ума сойти.
Хм, тогда я не понимаю зачем он нужен в полете.
им виднее - я тоже не знаю их алгоритмов))) но инспаеры ой как тупили - был период… даже откат прошивки делали…
а когда жпс будет тупить надо как раз добавить доверия инс и компасу? думаю несколько секунд инс выдержит и без жпс…
А ещё, хорошие идеи я бы рекомендовал держать при себе и не выкладывать их на всеобщее обозрение…
А ещё, хорошие идеи я бы рекомендовал держать при себе и не выкладывать их на всеобщее обозрение…
а что мне стоит, я на этом деньги не зарабатываю, идей еще хватает.
И это был решающий момент, сразу убил несколько зайцев.
Если добавить ещё один датчик ГНСС и так же прописать его в матмодель, то при достаточном разносе можно вообще от компаса отказаться. Да, когда то на форуме обсуждали использование разнесенных акселей в качестве единственного источника инфы для стаба.))
Также при зависании в одной точке спусти несколько минут коптер начинал гулять, так как ориентация не корректировалась без движения. Теперь коптер четко крутится вокруг своей оси и висит в точке, просто фантастика.
Илья, хотел попросить объяснение как это работает, но вроде сам догадался 😃
Но есть скользкий момент - по идее я добавил еще одну зависимость между перемнными, тем самым снизив устойчивость, если раньше некоторые переменные могли позволить себе быть некорректными и при этом коптер вел себя нормально, то сейчас косяк с одной переменной убьет всю систему.
Если зависимость жесткая, а она такая, то на устойчивость это не повлияет.
чтобы матмодель не вырождалась, нужно поверх наложить маску с контролем граничных условий типа: нельзя чтобы фильтр не доверял одновременно всем абсолютным датчикам, если такое произошло меняем коэффициенты доверия к простому алго ДУС-аксель.
Если добавить ещё один датчик ГНСС и так же прописать его в матмодель, то при достаточном разносе можно вообще от компаса отказаться
В принципе можно и щас отказаться, просто при старте все время направлять нос на север.
Если зависимость жесткая, а она такая, то на устойчивость это не повлияет.
чтобы матмодель не вырождалась, нужно поверх наложить маску с контролем граничных условий типа: нельзя чтобы фильтр не доверял одновременно всем абсолютным датчикам, если такое произошло меняем коэффициенты доверия к простому алго ДУС-аксель.
По идее часть этой маски есть, но не все случаи рассмотрены. Например если в начале компас не правильно скалиброван, то он повлияет на всю систему, и в том числе на всю ориентацию (и крен и тангаж), тогда как раньше без учета выноса GPS, такого не происходило, был неверен только курс. То есть снижение устойчивости на первый взгляд происходит. А что будет если коптер подлетел к дому или просто сигнал стал врать, хорошо если при этом hAcc и vAcc подскачут, тогда UKF поймет, что не стоит доверять GPS. Но бывает ловля глитча и все в хлам, в идеале все случаи надо исследовать и по идее лишние взаимосвязи снижают устойчивость.
Но бывает ловля глитча и все в хлам, в идеале все случаи надо исследовать и по идее лишние взаимосвязи снижают устойчивость.
Есть возможность всё попробовать безопасно: Xplane + Симулинк, могу выложить примитивы. Или даже “проигрывать” алго в железе, а Хплан будет гнать данные.