Главная
Автопилот своими силами: sensor fusion с телефона и открытые обучающие данные

Автопилот своими силами: sensor fusion с телефона и открытые обучающие данные +30

25.05.2017 15:19

waiwnf 26 4800 Источник

Всем привет. Продолжаем собирать автомобильный автопилот на компьютерном зрении из гитхаба и палок (начало здесь). Сегодня подключаем к делу датчики движения смартфона (акселерометр, гироскоп и GPS приемник) на Android, осваиваем несложный sensor fusion и окончательно закрываем с кодом для сбора обучающей выборки. Бонусы — Android приложение для записи всех сенсоров синхронзированных с видео и больше часа размеченных данных в рамках импортозамещения иностранных конкурсов. Весь код по-прежнему на github.

Это трехосные MEMS акселерометр и гироскоп, они будут нам крайне полезны.

В двух словах напомню (за деталями добро пожаловать в предыдущий пост, что конечная цель — обучить систему, которая по кадрам видео с лобового стекла сможет выдавать управляющие воздействия для автомобиля (угол поворота руля и желаемую скорость или ускорение). Для этого нужна обучающая выборка — видео с заездов, где машиной управляет человек, и синхронизированная по времени информация об угле поворота и скорости. В современных автомобилях эти данные можно считывать через CAN шину, но надо во-первых покупать и подключать специальный CAN адаптер, а во-вторых разбираться с расшифровкой протокола и формата данных, которые у разных производителей разные. Вместо всей этой возни мы вычисляем управляющие воздействия косвенно — из сырых данных с обычного смартфона, ни к чему дополнительно не подключенного.

В прошлой серии мы научились определять угловую скорость поворота автомобиля в горизонтальной плоскости на основе только видео кадров с помощью библиотеки видео-SLAM. К сожалению, на практике эта библиотека очень неточно вычисляет поступательную скорость устройства. А не зная поступательную скорость, мы не можем обучить даже компонент поворота руля для автопилота по отдельности, так как угловая скорость $\omega$ зависит от комбинации степени поворота руля (эквивалентно, радиуса поворота ) и поступательной скорости автомобиля .

Чтобы получить поступательную скорость, сегодня переключаемся с обработки видео на датчики движения, которые есть почти в любом смартфоне: GPS приемник, акселерометр и гироскоп. Посмотрим на плюсы и минусы каждого, объединим информацию и получим мгновенную скорость для каждого кадра видео. Более того, информацию о вращениях тоже возьмём с гироскопа, что позволит отказаться от более капризного оптического SLAM и нужной ему калибровки камеры смартфона. В итоге новый процесс сбора данных усох до трех "нажатий кнопки": ставим приложение на телефон — записываем трек на заезде — обрабатываем одной командой на компьютере.

В итоге получаем покадровую аннотацию с поступательной скоростью и скоростью поворотов:

Доступные датчики движения

Работать будем с андроидом. Безотносительно платформы — для знающих английский интересное видео о том, как информация с разных сенсоров может дополнять улучшать калибровку и уменьшать ошибки. Нас интересуют сенсоры движения (акселерометр и гироскоп) и местоположения (GPS).

С точки зрения API всё просто — запрашиваем у пользователя разрешения, подписываемся на обновления, и получаем поток событий с показанием сенсора и временем измерения. Детали можно посмотреть в исходниках.

Рассмотрим плюсы и минусы сенсоров.

GPS

GPS — это, как выяснилось, 90% успеха в определении поступательной скорости, по крайней мере на относительно открытых пространствах. От GPS приходят в формате Location:

Оценка абсолютного положения (широта, долгота).
Оценка точности координат — радиус доверительного круга в 68% вокруг оценки. То есть в ~68% измерений настоящее положение устройства должно быть в пределах данного радиуса вокруг оценки. Как правило на более-менее открытом пространстве точность получается в пределах 3-4 м.
Абсолютная скорость (без направления), оцененная по прошлым замеренным GPS позициям.

Огромный плюс GPS данных — погрешности измерений независимы, то есть не накапливаются со временем: на новое измерение не влияет то, сколько измерений было до этого и скакими погрешностями. Это очень важное свойство, на которое опирается весь остальной подход.

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

Здесь подозрение вызывают первые 25 секунд (постоянное ускорение и вероятное запаздывание GPS измерений) и шум между 30 и 40 секундой. Для затравки, тот же график после обработки данных с акселерометра и гироскопа:

Как видно, есть улучшения по обоим показателям: на ускорения реагируем раньше, и выброс на 35 секунде заглажен.

Инерциальные датчики: акселерометр и гироскоп

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

Акселерометр выдает линейные ускорения вдоль трех осей устройства, гироскоп — угловые скорости вокруг тех же трех осей.

Плюс инерциальных датчиков — возможность очень частых измерений, в 400 Гц и выше, что на порядок перекрывает частоту видеокадров в ~30 Гц. Главный минус — отсутствие связи с неподвижной системой координат. Датчики сопособны измерить только изменение относительно предыдущего положения, поэтому для расчета результатов в неподвижной системе координат их показания нужно интегрировать по времени, а при этом ошибки измерений накапливаются — чем дольше период измерения, тем больше итоговая ошибка в следующий момент времени.

Как видно, GPS и инерциальные датчики имеют зеркально противоположные достоинства и недостатки, а значит нужно объединить сильные стороны обоих источников, к чему и приступаем.

Sensor fusion: объединяем информацию

Имея запись данных от GPS и инерциальных датчиков, требуется оценить:

Абсолютную поступательную скорость с высоким временным разрешением.
Угловую скорость вращения вокруг вертикальной оси автомобиля (т.е. в плоскости дороги в каждый момент времени).

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

Поступательная скорость

Казалось бы, чего уж проще. Из школьной физики мы знаем по определению

$\vec{v}(t_1) = \vec{v}(t_0) + \int_{t_0}^{t_1} \vec{a}(t) d t$

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

$\vec{v}(t_1) = \vec{v}(t_0) + \int_{t_0}^{t_1} R(t) \vec{a}_{D}(t) d t$

где $\vec{a}_{D}$ — ускорение по осям координат утсройства. В свою очередь матрицу поворота получаем просто проинтегрировав вращения, измеренные гироскопом ( — производная матрицы вращения, её можно рассчитать, зная угловые скорости вокруг трех осей):

$R(t_1) = R(t_0) + \int_{t_0}^{t_1} (I + W(t)) d t$

И всё? Не тут-то было, это только для сферического акселерометра в вакууме работает. Посмотрим на реальные данные со смартфона, неподвижно лежащего на столе:

Raw accelerometer readings per axis

Наблюдения:

Сила земного притяжения автоматически не вычитается, ведь акселерометр принципиально не может отличать эффект притяжения земли от эффекта ускорения телефона. Значит нужно вручную определять направление и делать поправку. Теоретически андроид предлагает такую поправку на уровне ОС, но на практике у меня оно толком не работало.
Суммарное ускорение/притяжение по трем осям переваливает за 10 м/с², что очень далеко от табличных 9.81 м/с² — за 10 минут набежит 0.2 * 600 = 120 м/с = 432 км/ч.

Второй эксперимент — запишем суммарное ускорение с телефона лежащего на столе экраном вверх, а потом — экраном вниз, и сравним:

Overall measured acceleration screen up and down comparison

Наблюдения:

Разница свыше 0.15 м/с² просто от смены ориентации, то есть присутствует заметная систематическая ошибка в локальной системе координат.
Постоянный шум измерений в районе 0.05 м/с², а как видим из интегралов выше — ошибки накапливаются со временем. А когда шумы суммируются, то даже при несмещенном шуме (т.е. когда математическое ожидание измерения совпадает с истинным значением), по центральной предельной теореме дисперсия суммы n измерений составит $O\left(\sqrt{n}\right)$ .

Модель шума и автокалибровка

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

$v(t_1) = v(t_0) + \int_{t_0}^{t_1} \left( \vec{g} + R(t) \cdot \left(\vec{a}^{RAW}(t) + \vec{h} \right) \right) dt$

где

$\vec{a}^{RAW}$ — сырое измерение акселерометра, в системе координат устройства.
$\vec{h}$ — компенсация систематической ошибки акселерометра, также в системе координат устройства.
— матрица вращения от системы координат устройства к неподвижной системе координат.
$\vec{g}$ — постоянная сила тяготения в неподвижной системе координат.

Матрицу вращения получим интеграцией угловых скоростей с гироскопа, а вот остальные параметры неизвестны (включая $\vec{g}$ , т.к. неизвестна начальная ориентация смартфона). Найти калибровочные параметры помогут данные с GPS. Вспомним, что измерения GPS довольно точны. А значит скорость, рассчитанная по инерциальным датчикам должна быть близка к скорости по данным GPS. Формализуем эту интуицию как задачу оптимизации. Для каждого интервала между соседними GPS измерениями (порядка 1 секунды) посчитаем дистанцию, пройденную по данным инерциальных данных, и по данным GPS, и целевой функцией назначим метрику L2 по всему времени записи:

$\min_{\vec{g}, \vec{h}, \vec{v}_0} \sum_{i=1}^n \left( \left \| \sum_{k=k_i}^{k_{i+1}} (\tau_k - \tau_{k-1} )\vec{v}_k^{IMU} \right \| - (t_i - t_{i-1})v^{GPS}_i \right )^2$

где

— индекс измерения GPS.
$k_i \dots k_{i+1}$ — индексы измерения инерциальных датчиков, попадающих в промежуток между измерениями GPS i и i+1.
$\tau_j$ время -го измерения инерциальных датчиков.

Также обозначим $\Delta \tau_j \equiv \tau_j - \tau_{j-1}$ и $\Delta t_i \equiv t_i - t_{i-1}$ , и подставляя поправки к сырым замерам акселерометра, получаем окончательный вид целевой функции:

$\min_{\vec{g}, \vec{h}, \vec{v}_0} \sum_{i=1}^n \left( \left \| \sum_{k=k_i}^{k_{i+1}} \Delta \tau_k \left( \vec{v}_0 + (\tau_k - \tau_0)\vec{g} + \sum_{j=1}^k \Delta \tau_j R_j \cdot (\vec{a}_j^{RAW} + \vec{h}) \right ) \right \| - v^{GPS}_i \Delta t_i \right )^2$

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

Для начала проверим на коротком отрезке в полминуты:

калибровка откалибровалась

Здесь "на глаз" не очень понятно, какой график более правильный, но можно объявить успех хотя бы в том смысле, что калибровкой удалось подобрать параметры поправок, с которыми оценки скорости с двух разных источников очень близки. Теперь попробуем тот же подход на более продолжительной записи, порядка 10 минут:

что-то пошло не так

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

Систематические ошибки ("уход") гироскопа.
Накопленный со временем белый шум акселерометра и гироскопа $O(\sqrt{t})$ по центральной предельной теореме.
Взаимодействие с вибрациями двигателя (через кузов автомобиля) при движении.

Локальная автокалибровка скользящим окном

Бороться с проблемами простой модели поправок для инерциальных датчиков можно по-разному. Возможные варианты:

Улучшать точность, моделируя неучтенные источники ошибок (уход гироскопа, накопление белого шума).
Схитрить.

Мы схитрим. Ведь в конечном итоге нам интересна не сама по себе калибровочная модель, а итоговые значения скорости. А раз на коротких отрезках калибровка справляется, можно применить стандартный прием со скользящим окном:

разбиваем полный временной интервал на перекрывающиеся короткие отрезки,
на каждом отрезке отдельно калибруем и вычисляем скорость интегрированием,
усредняем результат для каждого момента времени по тем отрезкам которые его включают:

скользящее окно

Конечный результат:

Final result - long-range time series calibrated with overlapping sliding windows

Объявляем успех с поступательной скоростью, возвращаемся к угловой скорости поворотов.

Угловая скорость поворотов

Угловая скорость поворота нужна, чтобы вычислить радиус поворота (и соответственно угол поворота руля): $r = v / \omega$ . Гироскоп замеряет угловую скорость напрямую, но в трехмерном пространстве: кроме вращения вокруг вертикальной оси (yaw — собственно поворотов), в данных отражаются еще и вращения вокруг попреречной (pitch — изменение уклона дороги, проезд лежачих полицейских) и продольной (roll — заезд одной стороной в колею или яму):

pitch-roll-yaw

Нам нужно выделить из трехмерных вращений только компоненту вокруг вертикальной оси (в системе координат автомобиля). Соответственно, нужно получить направление этой оси. Для этого воспользуемся наблюдением, что величина вращения вокруг вертикальной оси гораздо больше, чем вокруг продольной и поперечной (повороты по 90 градусов — норма, а вот смена уклона и колея — к счастью, нет). А значит можно просто принять ту ось, вокруг которой общее вращение было максимальным, за вертикальную.

Математически выделить доминантную ось вращения удобно, представив каждое элементарное вращение (т.е. измерение гироскопа) в виде кватерниона. Вращение вокруг единичной оси (x,y,z) на угол $\theta$ представляется кватернионом

$q((x,y,z), \theta) = \begin{pmatrix} x \sin (\theta /2) \\ y \sin (\theta /2)\\ z \sin (\theta /2)\\ \cos(\theta /2) \end{pmatrix}$

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

Rotations after PCA

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

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

Данные

Бонусом к коду хочу поделиться уже обработанными данными для тех, кому интересно поиграться с обучением своих моделей. В торренте больше часа сырых данных, записанных на подмосковных дорогах, плюс (в директориях postprocessed) результаты вычисления поступательной скорости и угловой скорости поворотов. Если воспользуетесь — будет интересно узнать о результатах!

На этом всё, в следующей серии — учимся предсказывать управляющие воздействия по видео.

Поделиться с друзьями

-->

Комментарии (26)

token
25.05.2017 18:38
#10234736
Нереально круто, спасибо за статью, буду ждать продолжения.
1. waiwnf
  25.05.2017 18:39
  #10234738
  Спасибо!

x893
25.05.2017 19:17
#10234790
Просто жемчужина! Дорогой товарищ — пишите — не стесняйтесь.
1. waiwnf
  25.05.2017 21:39
  #10234976
  спасибо :)

alexbuyval
25.05.2017 21:51
#10234984
Для подобной задачи более эффективно использовать Extended Kalman Filter. Вот на этом видео как раз рассматривается применение EKF для оценки позиции автомобиля.
1. waiwnf
  26.05.2017 11:13
  #10235666
  Спасибо за ссылку! EKF было бы интересно попробовать, но руки не дошли — надо было составлять трехмерную motion model, где замеры ускорений и вращений приходят с IMU, я заленился.
  
  Ну и задачу EKF на самом деле решает почти перпендикулярную — тут бОльшая часть интересного в автокалибровке акселерометра. В EKF это соответствует модели шума, которая, насколько я понимаю, предполагается уже известной и заданной извне. То есть можно комбинировать: откалиброваться как я сделал и потом сверху прогнать EKF для сглаживания траектории. На глаз есть ощущение, что для скорости будет не очень большой эффект, а вот повороты пошумливают, там должно быть полезно.
  
  Хотя возможно умные люди научились уже и модель шума фитить на лету, не знаю, это было бы конечно идеально всё-в-одном.
  1. alexbuyval
    26.05.2017 11:55
    #10235760
    Это не совсем перпендикулярная задача. По-сути EKF умеет корректировать рассчитанное состояние, когда приходят более точные данные. В частности, пока нет GPS фильтр рассчитывает позицию интегрирую ускорения, которые с ошибкой, но с поступление данных от GPS он скорректирует рассчитанную позициию и т.о. сбросит набежавшую ошибку интегрирования.
    Если же мы хотим рассчитывать на лету постоянный сдвиг в данных датчика, то для этого нужно добавить дополнительное(ые) состояние(я) в фильтр, которое будет оценивать этот сдвиг (bias).
    
    waiwnf
    26.05.2017 13:05
    #10235892
    Отчасти, но полностью всё же не соглашусь. НЯП, концептуально, состояние — это те параметры, которые могут меняться со временем (скорость, угол поворота итд). Bias же по природе своей неизменен (хотя там есть свои приколы с зависимостью от температуры например). То есть чтобы всё было в модели правильно "по кинематике", надо не вычислять и обновлять значение сдвига в каждый момент времени, а как-то считать оптимальный фиксированный сдвиг на всю последовательность.
    
    Возможно это можно аппроксимировать, взяв для сдвига большую начальную неопределенность и очень "статическую" функцию переходов, но тогда по хорошему нужно будет делать forward-backward, чтобы оптимальное значение по последовательности найти, а насколько удобно forward-backward с нелинейным EKF не знаю, там есть какой-то итеративный процесс для этого? И нужно обратную по времени функцию переходов составлять?
    
    alexbuyval
    26.05.2017 13:38
    #10235988
    Когда bias является статическим параметром, то его, действительно, выгодней определить заранее путем калибровки. В случае же, если он меняется во времени, то его включают в состояние системы, хотя, конечно, по физическому смыслу он будет отличатся от других переменных состояния. Но это, как говорится, best practice. Например, в коде полетного контроллера PX4 примерно треть переменных состояния это bias.
    
    Никакой backward функции для получения оптимального bias не нужно, т.к. сам по себе EKF относится к классу optimal estimator и соответственно на каждой итерации оцененное состояние является оптимальным по отношению к полученным измерения, шумам и модели.
    
    waiwnf
    26.05.2017 14:10
    #10236060
    Спасибо за ссылку! Не очень понял навскидку, там bias — это калибровка или просто "увод" IMU со временем от белого шума, надо будет вчитаться.
    
    Насчет оптимального — нужно определиться с терминологией. Стандартный (E)KF без обратного прохода действительно дает оптимальную оценку состояния в момент t_i зная наблюдения в моменты t₁… t_i, т.е. только прошлое. Для задач оптимального управления, где мы не можем заглянуть в будущее, это действительно максимум, на что можно рассчитывать.
    
    Но у нас задача другая. Сначала записываем пачку данных в моменты t₁… t_N, потом всю пачку обрабатываем, чтобы потом скормить условной нейросетке в качестве обучающих данных.
    
    То есть мы хотим
    
    arg max P(s_i | o₁… o_N) для i = 1… N
    
    а EKF дает нам только оптимальное по прошлым данным
    
    arg max P(s_i | o₁… o_i).
    
    Чтобы "прицепить будущее" o_i+1… o_N и нужен обратный проход.
    
    В вики много текста и не особо наглядно, но на всякий случай ключевые слова forward-backward, Viterbi, Baum-Welch. Например в распознавании рукописного текста Viterbi стандартно применяли, чтобы учитывать следующие после текущей буквы в слове, а не только предыдущие.
    
    alexbuyval
    26.05.2017 16:53
    #10236416
    С терминологией согласен. Все так! :)
    В случае пакетной обработки лучше подойдет метод наименьших квадратов, который будет учитывать как неточности в данных IMU, так и неточности GPS и, конечно, саму модель движения.
    Рекомендую книгу "Advanced Kalman Filtering, Least-Squares and Modeling: A Practical Handbook", теория там конечно сложновата, но на примерах становится более-менее понятно.
    
    waiwnf
    26.05.2017 17:27
    #10236490
    Спасибо, книга точно лишней не будет!

abcdsash
26.05.2017 02:41
#10235274
отлично!!! просто нереальное удовольствие получил от прочтения!
1. waiwnf
  26.05.2017 10:34
  #10235558
  Спасибо!

Meklon
26.05.2017 10:00
#10235502
Восхитительно, продолжайте, пожалуйста?.
1. waiwnf
  26.05.2017 10:34
  #10235560
  Спасибо!

dubakov
26.05.2017 12:03
#10235772
+2
Ребят, берите скорость по OBD

Блютуз адаптер ELM стоит копейки. Легко работает с телефоном. И по крайней мере скорость брать очень легко, независимо от производителя.

Готовый код у меня есть. В свое время писал регистратор под андроид с отображением скорости с ELM.

Пример видео с моего регистратора https://www.youtube.com/watch?v=31HwBosxHR4

Скорость «с колёс» внизу справа. Опрашивать можно часто, хоть 1/10 сек, с точностью до 1 км/ч.

Легко поделюсь кодом, свяжитесь со мной если интересно. Тут отвечать не смогу.
1. token
  26.05.2017 16:23
  #10236344
  Это да, сам щас пишу опрос K-линии, только с блэкджэком и без ELMа, на мою задачу BlueTooth слишком медленный. Кстати если машина современная и там есть CAN, то в кане и угол поворота руля если чо есть )

IliaSafonov
26.05.2017 12:13
#10235794
Несколько лет назад игрался с записью данных с инерциальных датчиков на Android. Частота прихода данных была очень нестабильной. Экспериментировал с несколькими смартфонами. На каких-то лучше, на каких-то хуже, но при запросе данных на 100 Гц реальная частота иногда проваливалась до 5 Гц. Так что при разработке алгоритма советую смотреть на timestamp, а не верить в стабильность частоты.
1. waiwnf
  26.05.2017 12:18
  #10235796
  Да, там к счастью все данные приходят с временнЫми метками (они в json файлы тоже пишутся) поэтому предполагать фиксированную частоту нет необходимости. В коде половина всей возни — как раз работа с временем событий, ибо всё валится на вход асинхронно и независимо, приходится руками интерполировать, интервалы обрабатывать итд.

aboyev
26.05.2017 13:14
#10235928
А можно собирать данные видеорегистраторов, выложенные на youtube? Тогда можно например обучать сеть на экстренных ситуациях или при сложных погодных условиях (дождь, плохая видимость и т.д.).
1. waiwnf
  26.05.2017 13:35
  #10235982
  Было бы здорово, но я не знаю, как из сырых видео получать параметры движения. Есть проекты на эту тему, но насколько я знаю, там везде нужны калибровочные параметры камеры, а на случайных видосах с ютуба их естественно нет. В прошлом посте можно посмотреть пример вычисления вращения из видео, но там камера калибровалась предварительно, и работает не полностью надежно, периодически срывается. Так что в обозримом будущем придется специально ездить записывать.

apro
26.05.2017 20:03
#10236782
Недостаток же в том, что измерения проводятся редко, примерно 1 раз в секунду
Точнее это не недостаток GPS, а Android, GPS может выдавать данные хоть 100 раз в секунду.
Можно подключить внешний gps bluetooth от Garmin например к телефону и получать данные
10 раз в секунду. Плюс в большинстве современных GPS приемников встроенных в смартфоны
включены разного рода фильтры на этапе после вычисления координат, что может плохо сказаться
на алгоритмах обработки GPS данных, а во внешнем bluetooth gps (в Garmin точно) можно командой
отключить фильтрацию.
1. waiwnf
  28.05.2017 18:58
  #10238416
  Спасибо за инфо! В телефонах конечно не самый огонь GPS приемники, но по точности тот же Garmin обещает 3м, а сантиметровой точности Piksi с RTK например стоит $600 в штатах, это уже другой порядок денег. И насколько я понял RTK работает не везде, а только где есть покрытие дополнительными передатчиками. В общем не всё так однозначно :)
  
  А обычный GPS без толку запрашивать 100 раз в секунду, там ошибки будут коррелированные же. Иначе никто бы не городил огород с RTK, а просто частоту опроса увеличивали и вуаля, ошибка по ЦПТ соответственно уменьшалась.

apro
28.05.2017 22:06
#10238568
А обычный GPS без толку запрашивать 100 раз в секунду, там ошибки будут коррелированные же. Иначе никто бы >не городил огород с RTK, а просто частоту опроса увеличивали и вуаля, ошибка по ЦПТ соответственно >уменьшалась.
Не совсем точно,

во-первых, да инструментальная погрешность определения положения во всемирной системе координат GPS/GLONASS не сантиметровая, и отсюда всякие диф. методы, но это погрешность определения
координат, скорости считаются с неплохой точностью, навскидку 0.3 м/с, вам ведь нужны скорости?

во-вторых при скорости 100 км/ч за секунду машина проезжает примерно 28м, что значительно больше
погрешности определения координат, т.е. хотя бы 2-3 измерения можно использовать для улучшения точности.

waiwnf
29.05.2017 12:10
#10239126
Интересно про скорости, не знал, спасибо! Сейчас хочется закрыть диапазон 20-60 км/ч, но и там +-1 км/ч вполне хватит.

Другое дело, что потребности по ходу дела меняются. Например осознал, что помимо скоростей ещё нужно будет продольное направление камеры относительно оси авто (т.к. телефон висит на креплении с шарниром, каждый раз закрепить-снять телефон оно чуть поворачивается, получается в итоге систематическая ошибка угла ориентации авто в каждом новом заезде, которую надо убирать). И там тоже появляется вкусовщина, кому-то проще сделать полноценное неподвижное крепление без люфта, взять скорость с GPS и закрыть вопрос. Я буду видимо делать опять в софте, раз уж весь код написан (просто чуть репараметризовать калибровку), это уже на вкус и цвет каждому.