Перейти к содержанию
    

Использование гироскопа/акселерометра MPU-6050

Использую MPU-6050. Назначение его в устройстве - датчик наклона по 2-м осям (X и Y).

Подключил, реализовал работу с ним. От датчика нужна только собственно информация о наклонах по двум осям. И желательно - быстрая реакция на наклон.

Нашёл в сети простой пример обработки данных акселерометра/гироскопа от MPU-6050 выдающий как результат два угла: по оси X и по оси Y. С использованием фильтра Калмана:

https://arduinoplus.ru/podkluchaem-akselerometr-k-arduino/

Вроде всё нормально работает, но есть сомнения:

MPU-6050 кроме гироскопа/акселерометра имеет в своём составе Motion-процессор (DMP). И на сайте InvenSense для работы с MPU-6050 выложен стек, который грузит прошивку в DMP. Этот DMP как я понимаю сам обрабатывает показания гироскопа/акселерометра (и датчика температуры) и выдаёт на выход готовые показания.

И стек работает уже с этими данными.

Это позволяет разгрузить от вычислений основной процессор (что для меня не важно), а также как я понимаю - получить более качественные данные, чем я сейчас получаю. Указанный стек, как я понял, может автоматически проводить калибровку гироскопа/акселерометра в процессе работы, проводит их температурную компенсацию (что для меня важно - устройство будет работать не в комнатных условиях), вычисляет перемещения не только по X,Y, но и по Z (пока не нужно, но мало-ли?).

Сейчас доступна версия motion_driver_6.12.

 

Я хотел портировать этот стек в свой проект. Но он очень большой - несколько сотен КБ (написан под кучу платформ до Андроида и линуха). И, как я понял, требует кроме прочих ресурсов, ещё и возможность хранения текущих данных в энергонезависимой памяти (core\mllite). Портирование всего этого добра займёт много времени.

И возникает сомнение в необходимости этого: насколько будут качественнее данные с этого стека, чем простая реализация на фильтре Калмана? Какие реально дополнительные возможности можно получить от этого стека? Уменьшение нагрузки на основной процессор меня не интересует - драйвер на Калмане сейчас грузит МК незначительно. А интересует именно качество данных.

У меня есть подозрения, что моя реализация может поплыть в температуре или может быть дрейф показаний при длительной работе. А в штатном стеке этой проблемы может не быть. Но чтобы хотя-бы сравнить, надо проделать кучу работы по портированию, которая может оказаться ненужной.

К тому-же - пока устройство в разработке, работает на столе в тепличных условиях. Как оно поведёт себя в поле, при колебаниях температуры, тряске, длительной работе и т.п. - сейчас не могу проверить заранее. На столе и Калман вполне нормально работает.

 

Хотелось бы услышать мнение тех, кто использовал MPU-6050 (или его собратьев): как именно работали с ним? Использовали ли стек от InvenSense? Если да, то какие получили преимущества?

А может можно пойти по другому пути: загрузить прошивку в DMP (её нетрудно выдрать из указанного стека), а дальше работать с этим DMP самостоятельно? Чтобы не портировать весь гигантский стек и в то же время получить преимущества обработки на DMP? Кто-нибудь так делал? Имеет смысл?

Заранее спасибо!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кто-нибудь так делал? Имеет смысл?

На свою платформу я портировал и запускал DMP.

Тут важно знать, что DMP работает максимум до 200 Гц.

Вторая проблема в неизвестности их алгоритма (калман, не калман.., если калман то какой? ) и соответственно недоступности ключевых коэффициентов.

Выдрать бинарник то вы выдерете, только откуда ж вы знаете какое там ядро у них, и как дизассебмблировать.

 

Калибровку от них я правда позаимствовал, но там по сути она примитивна и сводится к усреднению,

некоторая хитрость заключается в коде расчета проверочных констант для определения качества работы чипа.

Короче в сторонних проектах под Arduino на Github-е калибровка не хуже.

 

У меня есть рабочая версия библиотеки Invensense для своего модуля которая взаимодействует с их питоновским скриптом на компе.

Но я отрефакторил их код так что сам автор не узнает, либа теперь заточена под мой фреймворк в части прерываний, многозадачности и потоков ввода-вывода, все типы и переменные и названия файлов переименованы.

Поэтому предложить для анализа не могу.

Вывод такой, что DMP использовать по Cortex-M3..7 нет никакого резона.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...