Создание собственной системы стабилизации
оказалось всё прозаично просто, баро тупил и не отпускал scl ( у слейва есть такая привилегия) и все - все хитромудрые алгоритмы коту под хвост!
СКЛ слейв удерживает если хочет захватить управление шиной. Серёг, зачем барику бунтовать на шине?
Давайте, думаю не помешает, мне там только порты переобозначить по идее.
Завтра выложу.
Но теперь коптером займусь только в следующем году.
Что так?
У меня тоже раньше вся обработка в прерываниях была, но дальше определенного предела так двигаться не получается, слишком нерационально процессорное время тратится.
То что масштабируется плохо это да, а насчет времени вряд ли.
Линеаризуются все уравнения связанные с переходом из локальной СК в глобальную (они ж нелинейные или я ошибаюсь?), а также все операции связанные с кватернионами.
Кватернионы - линейная алгебра, всё должно быть линейно, кроме преобразования угловой скорости в ориентацию (там тригонометрия), но за период отчета в переделе макс угловой скорости ДУС синус линеен.
А можно поподробнее? просто выход курсового ПИДа ограничен?
Да, и он весит в 2 раза меньше.
Что так?
Две работы, учеба
То что масштабируется плохо это да, а насчет времени вряд ли.
помню, что алгоритмы определения ориентации обсчитывались в прерывании 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. Но бывает ловля глитча и все в хлам, в идеале все случаи надо исследовать и по идее лишние взаимосвязи снижают устойчивость.