Подробный спидометр для мобильного приложения Опции

[Альварез]

Добрый день,
во время разработки мобильного приложения возникла сложность со спидометром.
Приложение не автомобильное, скорости планируются небольшие, возможно использование в закрытых пространствах, крайне важно точно измерять разгон и торможение в реальном времени, и самое главное - смартфон не обязательно будет зафиксирован в одном положении, так как, возможно, будет лежать в кармане или в сумке, например, велосипедиста.
Сейчас спидометр работает только на показателях GPS, но это очень грубое представление, которое годится больше для автомобилистов, перемещающихся по относительно ровным дорогам на больших скоростях.
Нужно подключить акселерометр, но пока не получается, потому что для его корректной работы смартфон нужно четко фиксировать креплением в одном положении, чтобы не сбивались оси X, Y и Z, только тогда он будет работать корректно.
В нашем же случае предполагаются небольшие погрешности в положении в пространстве, которые будут эти оси постоянно сбивать, значит нужен алгоритм, который будет учитывать эти погрешности и выдавать честный результат.
Вдруг кто то сталкивался с подобной проблемой, подскажите пожалуйста как быть?
Заранее спасибо.

[Rst7]

Нужно подключить акселерометр, но пока не получается, потому что для его корректной работы смартфон нужно четко фиксировать креплением в одном положении, чтобы не сбивались оси X, Y и Z, только тогда он будет работать корректно.

Что-то мне подсказывает, что Вы еще даже не пробовали интегрировать данные с акселерометров даже лежащего на столе телефона. Иначе бы вопрос звучал совсем по другому.

В общем случае все выглядит примерно так. Интегрируя угловые скорости гироскопов получается матрицу преобразования координат из системы координат телефона в систему координат неподвижных звезд. Она же DCM (direct cosine matrix, это Вам ключевое слово для поиска будет). Потом вектор ускорения с акселерометров умножаете на эту матрицу перехода, и уже в системе неподвижных координат интегрируете. Не забывая что-то сделать с тем, что есть гравитация и сила реакции опоры (в том смысле, что гравитация есть, а ускорение равно 0, потому что пол мешает лететь человеку в тартарары)

Только шум и дрейфы нулей у MEMS-акселерометров такие, что за десяток секунд человек может в космос улететь по данным такой ИНС. Вот потому я и говорю, что кажется мне, что Вы еще ничего не пробовали.

И да, интегрирование угловых скоростей всех этих MEMS-гироскопов тоже нифига не банальное суммирование. Надо компенсировать огромные дрейфы нулей. Ну некие решения там есть. Ну вот, например, чтение по теме для новичка -  DCMDraft2.pdf ( 329.87 килобайт ) Кол-во скачиваний: 112

[Альварез]

Что-то мне подсказывает, что Вы еще даже не пробовали интегрировать данные с акселерометров даже лежащего на столе телефона. Иначе бы вопрос звучал совсем по другому.
 DCMDraft2.pdf ( 329.87 килобайт ) Кол-во скачиваний: 112

пытались взяться, но программист сопротивлялся.
Спасибо за ответ!

[AlexandrY]

Ну вот, например, чтение по теме для новичка -  DCMDraft2.pdf ( 329.87 килобайт ) Кол-во скачиваний: 112

Какое же это для новичка. Это туфта мягко говоря.

На самом деле все проще. Берем акселерометр и измеряем и все!
Ну или почти все. Надо из измерений вычесть вектор притяжения земли.
Для этого надо знать точную ориентацию микросхемы относительно земли.
Вот тут заваруха и начинается.
Есть три известных подхода к определению этой ориентации:
-Метод Махони ( про него в вышепереведенной ссылке). И он самый плохой, но да, его понимают даже ардуинщики.
-Метод Мадгвика. На мой взгляд лучший по ряду показателей.
-Метод Калмана. Вычислительно трудный, но самый правильный.

[Rst7]

Какое же это для новичка. Это туфта мягко говоря.

Обоснуйте.

На самом деле все проще. Берем акселерометр и измеряем и все!
Ну или почти все. Надо из измерений вычесть вектор притяжения земли.

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

Для этого надо знать точную ориентацию микросхемы относительно земли.
Вот тут заваруха и начинается.
Есть три известных подхода к определению этой ориентации:
-Метод Махони ( про него в вышепереведенной ссылке). И он самый плохой, но да, его понимают даже ардуинщики.
-Метод Мадгвика. На мой взгляд лучший по ряду показателей.
-Метод Калмана. Вычислительно трудный, но самый правильный.

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

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

[Doka]

Сейчас спидометр работает только на показателях GPS, но это очень грубое представление, которое годится больше для автомобилистов, перемещающихся по относительно ровным дорогам на больших скоростях.

видимо это ограничение конкретной модели смартфона (либо API к данным GNSS)
даже в старом-добром NMEA есть отдельное сообщение со скоростью движения антенны, высчитанную baseband-процессором.
какая точность нужна по условиям задачи?

[a123-flex]

Обоснуйте.

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

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

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

Калман как раз хорошо фильтрует шумы. Но вот о проблеме смены базовой системы координат я раньше не задумывался.
В проектах мозгов для БПЛА комплексные многоканальные ИНС используются, там все описанные проблемы решаются.

На выходе получаются динамические коэффициенты точности для каждого из источников координаты, и собсно координаты объекта, причем они получаются на порядок точнее, чем точность составляющих компонентов компаса. В системе с 6 акселерометрами, магнитометром, датчиком давления и gps приемником)

ТС-у: у Вас проблемы)

[Rst7]

В проектах мозгов для БПЛА комплексные многоканальные компасы используются, там все описанные проблемы решаются.

Все, что я видел в интернетах не содержит попыток интегрирования данных акселерометров.

На выходе получаются динамические коэффициенты точности для каждого из источников координаты, и собсно координаты объекта, причем они получаются на порядок точнее, чем точность составляющих компонентов компаса.

Компас - это компас. ИНС - это ИНС. У них задачи разные. Ну и не дает компас координат, только направление.

Ну пока что самый писк в самолетиках - это камера, смотрящая вниз, дальше считается optic flow, в пачке с GPS на выходе вполне уверенные координаты с хорошей динамикой.

А идеализировать Калмановский фильтр не надо. Всегда можно найти/придумать/сделать ситуацию, в которой он, например, станет неустойчивым. Я, естественно, про реальный объект типа самолетика, а не про упрощенные варианты из учебника.

[a123-flex]

Все, что я видел в интернетах не содержит попыток интегрирования данных акселерометров.

Точно не могу сейчас в архиве статейку найти. Но вот нашел конкретно по вашему вопросу: NASA-TM-74839 от 1977 года)
А вот что выпадает по поиску про NASA:
http://edge.rit.edu/edge/P07106/public/Doc...Kong_Thesis.pdf

Компас - это компас. ИНС - это ИНС. У них задачи разные. Ну и не дает компас координат, только направление.

Вы правы. Но ИНС трудное слово)

А идеализировать Калмановский фильтр не надо. Всегда можно найти/придумать/сделать ситуацию, в которой он, например, станет неустойчивым. Я, естественно, про реальный объект типа самолетика, а не про упрощенные варианты из учебника.

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

Вопрос фильтрации совсем не двадцать пятый: шумы акселерометров действительно большие.

[Rst7]

Вопрос фильтрации совсем не двадцать пятый: шумы акселерометров действительно большие.

На самом деле там выше обсуждение про фильтрацию - это для устранения дрейфа нулей MEMS-гироскопов в тех самых псевдо-ИНС для БПЛА (псевдо - потому что разговор там только в основном про ориентацию в пространстве идет, а про интегрирование линейных ускорений - нет). Там проблема в дрейфе нулей.

А вот что выпадает по поиску про NASA:
http://edge.rit.edu/edge/P07106/public/Doc...Kong_Thesis.pdf

Там про то, что при помощи данных с IMU с невысокими параметрами интерполируется положение в пространстве между отсчетами GPS (раз в секунду). Так да, так работает, если раз в секунду корректировать. Только вот если перестать отсчеты от GPS получать, то очень скоро "улетит" все. Разве что более-менее будет известны крен и тангаж (курс - только если в IMU есть, скажем, магнитный компас, тогда еще можно как-то удержать дрейф гироскопа (-пов в случае ненулевых кренов/тангажа) по курсу).

[a123-flex]

Там про то, что при помощи данных с IMU с невысокими параметрами интерполируется положение в пространстве между отсчетами GPS (раз в секунду). Так да, так работает, если раз в секунду корректировать. Только вот если перестать отсчеты от GPS получать, то очень скоро "улетит" все. Разве что более-менее будет известны крен и тангаж (курс - только если в IMU есть, скажем, магнитный компас, тогда еще можно как-то удержать дрейф гироскопа (-пов в случае ненулевых кренов/тангажа) по курсу).

Именно так. Поэтому я и написал ТС-у, что у него проблемы)