roboforum.ru

Добрый день.
Копаю похожую проблему, уже несколько дней бьюсь не знаю с какой стороны подступиться. Может подскажет кто чего.
Итак имею китайский датчик MPU-9250, под него немного модифицировал код DMP MotionApps v4.1 чтобы можно было из буфера забирать данные магнитометра. Как бонус кватернионы из DMP после около 20 с. начинают вести себя стабильно - очень большой тест не делал но за 10 мин в спокойном состоянии по оси Z кватернион уезжает на несколько градусов.
Есть так же данные от магнитометра, которые после преобразования и фильтра низких частот совместно с акселерометром при спокойном положении довольно уверенно показывает на север (+Pi:-Pi), никак не могу придумать каким образом полученный мною угол рысканья совместить с полученным кватернионом.
Толкните в нужном направлении, тут многие "собаку съели" в датчиках положения в пространстве.

Ну вроде получилось совместить, осталась проблема корректного отображения при движении датчика и убрать "тряску" по оси Z.
https://youtu.be/7PBFrxIRjGU

секрет смешивания кроется в том какие данные считать более верными и в какой момент времени.
как я понял под тряской вы подразумеваете девиацию значений оси Z в статическом положении?
Этот эффект связан с тем что гироскоп сильно врёт, и чтобы компенсировать ось Z используют компас, который тоже врёт.
Если уберёте тряску в статическом положении, будет заторможенная реакция в движении.
Можете попробовать пропустить выходные данные через небольшой медианный фильтр.

расскажите по подробнее как меняли код DMP MotionApps v4.1? правильно ли я понял, речь о коде который загружается в MPU-9250?

проблема компаса в том что в разных местах пространства у него будут разные критические значения магнитного поля, т.е. откалибровав в одном месте если перенести в другое получим неверное направление.
вот мои эксперименты https://www.youtube.com/watch?v=SXrsKto ... 77ZN7tLhV1
поэтому безоговорочно показаниям компаса верить нельзя.

_________________
R3 forum87/topic15337.html
R2 roboforum.ru/forum102/topic13980.html
R4 roboforum.ru/post336339.html#p336339
Делать надо хорошо - плохо получится само!

Прошу прощения за несколько несвоевременный ответ, у меня чего-то не получается подписаться на тему, чтобы вовремя получать уведомления.
1. Да, под "тряской" подразумевалось именно вот то, что Вы написали (слово "девиация" пришлось загуглить - первый раз встречаю его)
2. Применил обычный низкочастотный фильтр - "тряска" ушла. Да, появилась задержка в корректировке.
3. Про DMP MPU-9250 отдельная интересная история. Перепробовав кучу всевозможных скетчей и фильтров, вдоволь набаловавшись с калибровками всего и вся на одном корейском сайте нашелся код, который (О чудо!) корректно залился в 9250 и начал выдавать кватернионы, но без учета компаса. Перелопатив очень много документации по датчику и просмотрев много кода для него, немного поправил найденный код и получаемый кватернион начал вести себя более стабильно. Код на GitHub. Мои комментарии на русском, думаю там все понятно, но в исходном коде очень много "магии" и до конца разобраться что делать и как - непонятно.
4. Ваше видео очень познавательно. В принципе что-то такое я ожидал увидеть, особенно после этой картинки с хабра:


А я в настоящее время после того как применил фильтр к данным, понял что неправильно я мыслил - а подсказать некому. Так как при вращениях не только вокруг оси Z, у меня кубик ведет себя очень некорректно. Сейчас методом "научного тыка" пытаюсь понять необходимую математику правильности вычислений корректировки угла рысканья. Пока ничего лучше не придумал, чем корректировка когда кватернион горизонтален...

Добавлено спустя 1 час 45 минут 2 секунды:
Специально сделал видео получения кватерниона в спокойном положении на протяжении 5 минут без корректировки компаса:
https://youtu.be/cLF15Tmqx68
Видно как к 10 секундам кватернион стабилизируется и ведет себя достаточно стабильно. Начальные значения кватерниона по q.w/q.z составляют примерно 0,9165/0,3887, через 5 минут (300 секунд) эти же значения составляют 0,9103/0,4028, что равняется углу поворота вокруг Z примерно по q.w в начале 0,3043 и 0,3068 в конце и примерно по q.z 0.1895/0.196. Разумеется если датчик довольно сильно двигать - плаванье по оси Z будет гораздо сильнее.

почему он в эту точку стабилизировался у вас понимание есть?

если компаса нет, то можно попробовать стабилизировать данные через интегрирование акселерометра по оси Z, но там тоже много камней.
если есть иные датчики, например камера, лидар, то можно брать с них данные для компенсации оси Z. т.е. кода камера или лидар говорят что угловая скорость 0 то компенсировать ошибку гироскопа, это если в лоб, а можно и калманом.

за код спасибо.

для андроида есть приложение https://play.google.com/store/apps/deta ... .sitesin3d
насколько я понял оно использует стандартные данные андроида, но ведёт себя очень стабильно, я пока не копал почему оно так работает.

_________________
R3 forum87/topic15337.html
R2 roboforum.ru/forum102/topic13980.html
R4 roboforum.ru/post336339.html#p336339
Делать надо хорошо - плохо получится само!

Не очень оно и стабильно там всё ЭТО работает, можно помотать несколько раз головой и ещё сделать несколько оборотов с возвратом обратно. Будет видно как всё уплывает относительно реальных координат. Это всё игрушки: дешевые, быстрые решения.

Согласен с kharlashkin, тоже использовал этот алгоритм. На мой взгляд самый адекватный из всех найденных в сети. Все остальные точно игрушки. Также покопался в коде, допилил извлечение данных магнитометра из пакета. Так же столкнулся с дрейфом оси Z. Озадачился согласованием кватерниона с данными магнитометра. По дрейфу обратил внимание на постоянство направления и величины дрейфа. Несколько раз наблюдал. За 10 минут уходит примерно на 2,5 градуса, за час примерно на 15. Пришел к выводу, что по оси Z датчик чувствует вращение Земли, был немало удивлён ) Ближе к сути. На сайте Invensens (производитель MPU9255/65) не нашел ничего про Motion Apps 4.1. Нашел описание invensense-embedded-motion-api-specifications 5.1.1 на каком-то зарубежном форуме и пакет invensense-motion-driver-6.1 на сайте Invensens. Пакет MD 6.1 оказался довольно "тяжелым" по сравнению с MA 4.1, но из описания стало понятно, что DPM, выполняющий бинарный код из библиотеки пакета, вычисляет только 6-ти осевой кватернион, грузит его в пакет вместе с отфильтрованными показаниями всех 9-ти датчиков, из которого потом вычисляются углы Эйлера. И засунуть в этот готовый кватернион показания магнитометра невозможно. По крайней мере в DMP. Если у кого-то есть предложения на этот счет буду рад услышать (прочитать).