[krux 6]

энкодеры на оси приделайте

[alexPec 1]

Вы возьмете вектор [cos(a-va),sin(a-va),0], где а - референсный курс, а va - курс по результатам интегрирования, то это будет вектор ошибки по курсу в звездной системе координат. Преобразовав этот вектор в систему координат IMU как раз и получатся ошибки по каждой из осей. Дальше PI-регулятор и добавка к данным с гироскопа. Все.

 

Хорошо, рефренсный курс равен 0, va - курс по результатам интегрирования. Но повторюсь, если бы механика лежала на столе, это бы сработало, но сама механика на корабле тоже вращается, поэтому курс по результатам интегрирования - это сумма: поворот корабля + уплывание гироскопа. Как отсюда выделить уплывание чтобы вычислить собственно разницу между курсом механики и курсом по результатам интегрирования?

 

энкодеры на оси приделайте

 

Так они есть, что это дает?

[Rst7 5]

Как отсюда выделить уплывание чтобы вычислить собственно разницу между курсом механики и курсом по результатам интегрирования?

 

Да не надо ничего выделять. Оно просто будет всегда в нулевой курс утягивать. Это тоже самое, что просто с занулением данных гироскопа, но более культурно (меньше ошибка, если одновременно с креном происходит поворот по курсу). А рамка никуда у Вас не повернется. Углы Эйлера по крену и дифференту не зависят от курса, так что просто поворачиваете рамку на обратные углы и все.

[alexPec 1]

Да не надо ничего выделять. Оно просто будет всегда в нулевой курс утягивать. Это тоже самое, что просто с занулением данных гироскопа, но более культурно (меньше ошибка, если одновременно с креном происходит поворот по курсу). А рамка никуда у Вас не повернется. Углы Эйлера по крену и дифференту не зависят от курса, так что просто поворачиваете рамку на обратные углы и все.

 

Да, спасибо! Действительно если утягивать в нулевой курс проблема с рассинхронизацией вроде должна решиться. Все оказывается просто... Проверю на реальной железке.

[Prizrak_Kommunizma 0]

Чтобы не плодить новые темы, напишу тут. Я работаю уже продолжительное время с датчиком BNO055, реализую получение информации об абсолютной ориентации изделия на карте. У него есть возможность выдавать на выход кватернионы и углы Эйлера. Все пишут везде, что с углами Эйлера могут быть проблемы из-за эффекта "складывания рамок" и от того, что углы Эйлера зависят от выбора очерёдности поворота по углам. Мне с этим не всё ясно, не могу понять следующее:

1. Актуальна ли проблема Gimbal Lock (Складывание рамок) для MEMS гироскопов? Там же другая конструкция и рамок по сути нет.

2. Если ответ на 1 вопрос - да, то могу ли я надеяться, что Bosh уже решили эту проблему за меня внутри своего датчика с помощью данных магнетометра и акселерометра? Находил патенты, что такие алгоритмы есть, но разбираться в формулах нет времени, нужно делать изделие. Сам Bosh почему-то об этом в ДШ молчит.

3. Почему углы Эйлера это такая проблема, если можно узнать заранее в какой последовательности датчик и записывает и воспроизводить так же? Мы же не рандомно каждый раз их применяем, а по алгоритму. Почему обязателен переход на кватернионы?

[alexPec 1]

21.10.2021 в 16:17, Prizrak_Kommunizma сказал:

1. Актуальна ли проблема Gimbal Lock (Складывание рамок) для MEMS гироскопов? Там же другая конструкция и рамок по сути нет.

2. Если ответ на 1 вопрос - да, то могу ли я надеяться, что Bosh уже решили эту проблему за меня внутри своего датчика с помощью данных магнетометра и акселерометра? Находил патенты, что такие алгоритмы есть, но разбираться в формулах нет времени, нужно делать изделие. Сам Bosh почему-то об этом в ДШ молчит.

3. Почему углы Эйлера это такая проблема, если можно узнать заранее в какой последовательности датчик и записывает и воспроизводить так же? Мы же не рандомно каждый раз их применяем, а по алгоритму. Почему обязателен переход на кватернионы?

1. Актуальна. Это не проблема конкретных датчиков, а математическая проблема при использовании математики углов Эйлера. Если вы свое устройство повернете на неправильные углы, то и возникнет проблема складывания рамок - у вас 2 угла эйлера будут принимать одинаковые значения (это конечно так, в общем и целом).  

2. Будет видно из того как их вычисляют (сам не смотрел, лень). А с математикой все равно придется разобраться, если хотите точно знать как будет вести себя ваше устройство.

3. Тот же ответ что и п.1.

 

[Prizrak_Kommunizma 0]

1, А если моя цель просто показывать юзеру текущие углы крена, рысканья и тангажа без необходимости воспроизводить по ним положение датчика на компе или где-то ещё, то проблема сохраняется? Или она только при воспроизведении и пересчёте координат будет возникать?

Edited November 1, 2021 by Prizrak_Kommunizma

[amaora 2]

On 11/1/2021 at 2:48 PM, Prizrak_Kommunizma said:

1, А если моя цель просто показывать юзеру текущие углы крена, рысканья и тангажа без необходимости воспроизводить по ним положение датчика на компе или где-то ещё, то проблема сохраняется? Или она только при воспроизведении и пересчёте координат будет возникать?

Проблема складывания рамок только тогда когда эти рамки физически существуют. Значения углов могут меняться сколько угодно быстро в окрестности сингулярной точки (тангаж ±90°) и по отдельности не отражать угловой скорости датчика. То есть если медленно провернуть ось X вокруг оси Y, то в нижней/верхней точке два других угла "мгновенно" сменят значения на 180°. Конкретные оси и углы могут меняться, в зависимости от принятых систем координат и последовательности поворотов.