я часть стояночных точек отбрасываю - если нет изменяющихся параметров - сохраняю только раз в 20 минут (если машина стоит и двигатель заглушен), чтобы БД не забивать. но сейчас подумал, что это может вредить очистки стоянки от дрейфа - честных точек получается меньше чем могло быть - бедная база для фильтра дрейфа.
конечно попробуйте. ради этого статья и писалась - проблема есть, но никто о ней не говорит, только если в общих чертах. Как попробуете - напишите - что сработало, что нет - думаю многим было бы интересно.
Проект посмотрел - масштабный и интересный. Вы предикторскую модель для предсказания неисправностей самосвалов не пробовали реализовать?
Нет, не встроенные - обычные навесные телематические трекеры (Galileosky, Vega и пр). В этом проблема - сырых данных приёмника (1PPS, фаза, C/N0, AGC) прошивка трекера мне не отдаёт. Часть производителей начинают в новые прошивки добавлять флаги спуфинга - но верить им пока однозначно нельзя. Точность этих флагов я бы оценил процентов в 60.
думаю, моя борьба с подменой времени, по сути тот же принцип, перенесённый на сервер: детекция расхождения временных шкал. Только опорным генератором вместо 1PPS выступает одометр - единственная монотонная шкала, до которой спуфер не дотягивается. Дискретность только получается огромная - 1 км. У некоторых машин в CAN шине можно найти одометр в метрах - это бы повысило точность детекции на порядок, но это улучшит ситуацию не глобально, а только для частных случаев.
это можно настраивать. Как правило - раз в три минуты на стоянке, раз в 20 секунд в движении + дополнительно пишутся точки при изменения курса - чтобы трек на карте не срезал повороты.
не сколько от региона, сколько от конкретного места - как правило зона работы рэб - это круг радиусом от 2 до 15 км. причём работать она может не постоянно. Исключение - центр Москвы - там покрыто почти всё и постоянно. Если в пределах ТТК работает навигатор, то это заслуга позиционирования по wifi сетям.
Тут без вопросов - ели машина целый день простояла в зоне работы РЭБ - максимум что можно сделать - показать примерную точку по LBS. если весть трек в зоне подавление - ничего не сделать - не за что "зацепиться". есть api от яндекса - восстанавливают координаты по wifi. но стоит это не дёшево. Можно было бы насобирать базу самостоятельно, через работающие машины, но сами трекеры, которые работаю с wifi стоят раза в 4 дороже обычных.
да всё правильно триангуляция по вышкам хорошо бы помогла, но железо такое, что даёт только id вышки с которой работает. может быть ограничения в протоколах. Один из производителей недавно выкатил прошивку, которая до записи точки делает запрос на сторонний сервер и подменяет при необходимости gps координаты результатом триангуляции. Но прошивка пока кривовата и на часть трекеров не встаёт, на других - отваливается часть функционала. Но когда этот метод заработает - есть шанс, что большая часть фильтров окажется не нужна.
смотреть не только на граф, но ещё на скорость - это мысль. нужно только зазор оставить, чтобы если машина чуть мимо дороги едет (метров до 20) - не срезать - это погрешность трекера, а не РЭБ. Вопрос только полноты базы дорожных графов нужно исследовать.
А ещё идея - сверять направление движения - с направлением дорожного графа.
Когда от восьми кругов, остаётся островок с несколькими точками, которые уложились во все окна и пороги - это, согласен, обидно. Иногда, в моменты творческого кризиса, у меня появляется идея, что нужно попробовать трек два раза через фильтры прогонять)
ещё признак спуфа - часто скорость почти одинаковая на петле: 98 -102 км/ч, а иногда вообще залипает. но как отличить от движения по трассе на круиз контроле? и второе - нет гарантии, что так будет всегда.
По LBS - когда координаты берутся из своей БД - я пока не заметил проблем (но поток данных пока не такой большой), внешнее api - точно нельзя ждать - только записывать на будущее.
без CAN работает хорошо дельта по высоте и медиана расстояния между точками. остальное - да, вычистить сложно - я пробовал разные геометрические фильтры - на круги и зигзаги, но они режут заезды на эстакады и развороты.
У жесткой привязки к дорожной сети есть проблема - можно срезать заезды в пром зоны, склады и пр. У меня крутится идея - на вычищенном треке иногда остаются островки от согласованных участков, вызванных спуфингом - проверять их на достижимость в сравнении одометра и дорожного графа.
из анализа геометрии - если точка является вершиной поворота так, что угол больше определенного значения - не верить. например если поворот был на 90 градусов, а скорость при этом 70+ - то не верить. но это я пока не пробовал. Вот может быть угол поворота руля как советовали выше сравнивать со скоростью?
про компас - спасибо - изучу вопрос - бывает ли в терминалах, есть ли внешние устройства, которые можно подключить - простое сравнение двух направлений может дать хороший и быстрый результат.
в идеи что то есть, но напрямую её, наверное, не получится использовать - точки дискретны, - т.е. это снимок - раз в 20 секунд (при манёвре чуть чаще). Только если писать алгоритм для трекера, чтобы анализировал вращение руля между точками и на основании этих данных делать анализ - возможно ли было произошедшее изменение курса. Тут есть над чем подумать. И если идти дальше - график работы с педалью газа и, возможно, тормоза - тоже могут что то дать.
я часть стояночных точек отбрасываю - если нет изменяющихся параметров - сохраняю только раз в 20 минут (если машина стоит и двигатель заглушен), чтобы БД не забивать. но сейчас подумал, что это может вредить очистки стоянки от дрейфа - честных точек получается меньше чем могло быть - бедная база для фильтра дрейфа.
конечно попробуйте. ради этого статья и писалась - проблема есть, но никто о ней не говорит, только если в общих чертах. Как попробуете - напишите - что сработало, что нет - думаю многим было бы интересно.
Проект посмотрел - масштабный и интересный. Вы предикторскую модель для предсказания неисправностей самосвалов не пробовали реализовать?
Нет, не встроенные - обычные навесные телематические трекеры (Galileosky, Vega и пр). В этом проблема - сырых данных приёмника (1PPS, фаза, C/N0, AGC) прошивка трекера мне не отдаёт. Часть производителей начинают в новые прошивки добавлять флаги спуфинга - но верить им пока однозначно нельзя. Точность этих флагов я бы оценил процентов в 60.
думаю, моя борьба с подменой времени, по сути тот же принцип, перенесённый на сервер: детекция расхождения временных шкал. Только опорным генератором вместо 1PPS выступает одометр - единственная монотонная шкала, до которой спуфер не дотягивается. Дискретность только получается огромная - 1 км. У некоторых машин в CAN шине можно найти одометр в метрах - это бы повысило точность детекции на порядок, но это улучшит ситуацию не глобально, а только для частных случаев.
это можно настраивать. Как правило - раз в три минуты на стоянке, раз в 20 секунд в движении + дополнительно пишутся точки при изменения курса - чтобы трек на карте не срезал повороты.
не сколько от региона, сколько от конкретного места - как правило зона работы рэб - это круг радиусом от 2 до 15 км. причём работать она может не постоянно. Исключение - центр Москвы - там покрыто почти всё и постоянно. Если в пределах ТТК работает навигатор, то это заслуга позиционирования по wifi сетям.
Тут без вопросов - ели машина целый день простояла в зоне работы РЭБ - максимум что можно сделать - показать примерную точку по LBS. если весть трек в зоне подавление - ничего не сделать - не за что "зацепиться". есть api от яндекса - восстанавливают координаты по wifi. но стоит это не дёшево. Можно было бы насобирать базу самостоятельно, через работающие машины, но сами трекеры, которые работаю с wifi стоят раза в 4 дороже обычных.
да всё правильно триангуляция по вышкам хорошо бы помогла, но железо такое, что даёт только id вышки с которой работает. может быть ограничения в протоколах. Один из производителей недавно выкатил прошивку, которая до записи точки делает запрос на сторонний сервер и подменяет при необходимости gps координаты результатом триангуляции. Но прошивка пока кривовата и на часть трекеров не встаёт, на других - отваливается часть функционала. Но когда этот метод заработает - есть шанс, что большая часть фильтров окажется не нужна.
смотреть не только на граф, но ещё на скорость - это мысль. нужно только зазор оставить, чтобы если машина чуть мимо дороги едет (метров до 20) - не срезать - это погрешность трекера, а не РЭБ. Вопрос только полноты базы дорожных графов нужно исследовать.
А ещё идея - сверять направление движения - с направлением дорожного графа.
Когда от восьми кругов, остаётся островок с несколькими точками, которые уложились во все окна и пороги - это, согласен, обидно. Иногда, в моменты творческого кризиса, у меня появляется идея, что нужно попробовать трек два раза через фильтры прогонять)
ещё признак спуфа - часто скорость почти одинаковая на петле: 98 -102 км/ч, а иногда вообще залипает. но как отличить от движения по трассе на круиз контроле? и второе - нет гарантии, что так будет всегда.
жму руку в ответ)
По LBS - когда координаты берутся из своей БД - я пока не заметил проблем (но поток данных пока не такой большой), внешнее api - точно нельзя ждать - только записывать на будущее.
без CAN работает хорошо дельта по высоте и медиана расстояния между точками. остальное - да, вычистить сложно - я пробовал разные геометрические фильтры - на круги и зигзаги, но они режут заезды на эстакады и развороты.
У жесткой привязки к дорожной сети есть проблема - можно срезать заезды в пром зоны, склады и пр. У меня крутится идея - на вычищенном треке иногда остаются островки от согласованных участков, вызванных спуфингом - проверять их на достижимость в сравнении одометра и дорожного графа.
из анализа геометрии - если точка является вершиной поворота так, что угол больше определенного значения - не верить. например если поворот был на 90 градусов, а скорость при этом 70+ - то не верить. но это я пока не пробовал. Вот может быть угол поворота руля как советовали выше сравнивать со скоростью?
про компас - спасибо - изучу вопрос - бывает ли в терминалах, есть ли внешние устройства, которые можно подключить - простое сравнение двух направлений может дать хороший и быстрый результат.
в идеи что то есть, но напрямую её, наверное, не получится использовать - точки дискретны, - т.е. это снимок - раз в 20 секунд (при манёвре чуть чаще). Только если писать алгоритм для трекера, чтобы анализировал вращение руля между точками и на основании этих данных делать анализ - возможно ли было произошедшее изменение курса. Тут есть над чем подумать. И если идти дальше - график работы с педалью газа и, возможно, тормоза - тоже могут что то дать.