Comments 26
Спасибо за ссылку! EKF было бы интересно попробовать, но руки не дошли — надо было составлять трехмерную motion model, где замеры ускорений и вращений приходят с IMU, я заленился.
Ну и задачу EKF на самом деле решает почти перпендикулярную — тут бОльшая часть интересного в автокалибровке акселерометра. В EKF это соответствует модели шума, которая, насколько я понимаю, предполагается уже известной и заданной извне. То есть можно комбинировать: откалиброваться как я сделал и потом сверху прогнать EKF для сглаживания траектории. На глаз есть ощущение, что для скорости будет не очень большой эффект, а вот повороты пошумливают, там должно быть полезно.
Хотя возможно умные люди научились уже и модель шума фитить на лету, не знаю, это было бы конечно идеально всё-в-одном.
Если же мы хотим рассчитывать на лету постоянный сдвиг в данных датчика, то для этого нужно добавить дополнительное(ые) состояние(я) в фильтр, которое будет оценивать этот сдвиг (bias).
Отчасти, но полностью всё же не соглашусь. НЯП, концептуально, состояние — это те параметры, которые могут меняться со временем (скорость, угол поворота итд). Bias же по природе своей неизменен (хотя там есть свои приколы с зависимостью от температуры например). То есть чтобы всё было в модели правильно "по кинематике", надо не вычислять и обновлять значение сдвига в каждый момент времени, а как-то считать оптимальный фиксированный сдвиг на всю последовательность.
Возможно это можно аппроксимировать, взяв для сдвига большую начальную неопределенность и очень "статическую" функцию переходов, но тогда по хорошему нужно будет делать forward-backward, чтобы оптимальное значение по последовательности найти, а насколько удобно forward-backward с нелинейным EKF не знаю, там есть какой-то итеративный процесс для этого? И нужно обратную по времени функцию переходов составлять?
Никакой backward функции для получения оптимального bias не нужно, т.к. сам по себе EKF относится к классу optimal estimator и соответственно на каждой итерации оцененное состояние является оптимальным по отношению к полученным измерения, шумам и модели.
Спасибо за ссылку! Не очень понял навскидку, там bias — это калибровка или просто "увод" IMU со временем от белого шума, надо будет вчитаться.
Насчет оптимального — нужно определиться с терминологией. Стандартный (E)KF без обратного прохода действительно дает оптимальную оценку состояния в момент ti зная наблюдения в моменты t1… ti, т.е. только прошлое. Для задач оптимального управления, где мы не можем заглянуть в будущее, это действительно максимум, на что можно рассчитывать.
Но у нас задача другая. Сначала записываем пачку данных в моменты t1… tN, потом всю пачку обрабатываем, чтобы потом скормить условной нейросетке в качестве обучающих данных.
То есть мы хотим
arg max P(si | o1… oN) для i = 1… N
а EKF дает нам только оптимальное по прошлым данным
arg max P(si | o1… oi).
Чтобы "прицепить будущее" oi+1… oN и нужен обратный проход.
В вики много текста и не особо наглядно, но на всякий случай ключевые слова forward-backward, Viterbi, Baum-Welch. Например в распознавании рукописного текста Viterbi стандартно применяли, чтобы учитывать следующие после текущей буквы в слове, а не только предыдущие.
В случае пакетной обработки лучше подойдет метод наименьших квадратов, который будет учитывать как неточности в данных IMU, так и неточности GPS и, конечно, саму модель движения.
Рекомендую книгу "Advanced Kalman Filtering, Least-Squares and Modeling: A Practical Handbook", теория там конечно сложновата, но на примерах становится более-менее понятно.
Блютуз адаптер ELM стоит копейки. Легко работает с телефоном. И по крайней мере скорость брать очень легко, независимо от производителя.
Готовый код у меня есть. В свое время писал регистратор под андроид с отображением скорости с ELM.
Пример видео с моего регистратора https://www.youtube.com/watch?v=31HwBosxHR4
Скорость «с колёс» внизу справа. Опрашивать можно часто, хоть 1/10 сек, с точностью до 1 км/ч.
Легко поделюсь кодом, свяжитесь со мной если интересно. Тут отвечать не смогу.
Да, там к счастью все данные приходят с временнЫми метками (они в json файлы тоже пишутся) поэтому предполагать фиксированную частоту нет необходимости. В коде половина всей возни — как раз работа с временем событий, ибо всё валится на вход асинхронно и независимо, приходится руками интерполировать, интервалы обрабатывать итд.
Было бы здорово, но я не знаю, как из сырых видео получать параметры движения. Есть проекты на эту тему, но насколько я знаю, там везде нужны калибровочные параметры камеры, а на случайных видосах с ютуба их естественно нет. В прошлом посте можно посмотреть пример вычисления вращения из видео, но там камера калибровалась предварительно, и работает не полностью надежно, периодически срывается. Так что в обозримом будущем придется специально ездить записывать.
Недостаток же в том, что измерения проводятся редко, примерно 1 раз в секунду
Точнее это не недостаток GPS, а Android, GPS может выдавать данные хоть 100 раз в секунду.
Можно подключить внешний gps bluetooth от Garmin например к телефону и получать данные
10 раз в секунду. Плюс в большинстве современных GPS приемников встроенных в смартфоны
включены разного рода фильтры на этапе после вычисления координат, что может плохо сказаться
на алгоритмах обработки GPS данных, а во внешнем bluetooth gps (в Garmin точно) можно командой
отключить фильтрацию.
Спасибо за инфо! В телефонах конечно не самый огонь GPS приемники, но по точности тот же Garmin обещает 3м, а сантиметровой точности Piksi с RTK например стоит $600 в штатах, это уже другой порядок денег. И насколько я понял RTK работает не везде, а только где есть покрытие дополнительными передатчиками. В общем не всё так однозначно :)
А обычный GPS без толку запрашивать 100 раз в секунду, там ошибки будут коррелированные же. Иначе никто бы не городил огород с RTK, а просто частоту опроса увеличивали и вуаля, ошибка по ЦПТ соответственно уменьшалась.
А обычный GPS без толку запрашивать 100 раз в секунду, там ошибки будут коррелированные же. Иначе никто бы >не городил огород с RTK, а просто частоту опроса увеличивали и вуаля, ошибка по ЦПТ соответственно >уменьшалась.
Не совсем точно,
во-первых, да инструментальная погрешность определения положения во всемирной системе координат GPS/GLONASS не сантиметровая, и отсюда всякие диф. методы, но это погрешность определения
координат, скорости считаются с неплохой точностью, навскидку 0.3 м/с, вам ведь нужны скорости?
во-вторых при скорости 100 км/ч за секунду машина проезжает примерно 28м, что значительно больше
погрешности определения координат, т.е. хотя бы 2-3 измерения можно использовать для улучшения точности.
Интересно про скорости, не знал, спасибо! Сейчас хочется закрыть диапазон 20-60 км/ч, но и там +-1 км/ч вполне хватит.
Другое дело, что потребности по ходу дела меняются. Например осознал, что помимо скоростей ещё нужно будет продольное направление камеры относительно оси авто (т.к. телефон висит на креплении с шарниром, каждый раз закрепить-снять телефон оно чуть поворачивается, получается в итоге систематическая ошибка угла ориентации авто в каждом новом заезде, которую надо убирать). И там тоже появляется вкусовщина, кому-то проще сделать полноценное неподвижное крепление без люфта, взять скорость с GPS и закрыть вопрос. Я буду видимо делать опять в софте, раз уж весь код написан (просто чуть репараметризовать калибровку), это уже на вкус и цвет каждому.
Автопилот своими силами: sensor fusion с телефона и открытые обучающие данные