Comments 26
CAN (одометр, OBD‑скорость)
Угол поворота руля ещё можно использовать - много где есть
Тогда уж лучше компас. Внутри метал. кабины некоторые сенсоры показывают неплохие результаты.
А еще CV на дорожные знаки населенных пунктов.
в идеи что то есть, но напрямую её, наверное, не получится использовать - точки дискретны, - т.е. это снимок - раз в 20 секунд (при манёвре чуть чаще). Только если писать алгоритм для трекера, чтобы анализировал вращение руля между точками и на основании этих данных делать анализ - возможно ли было произошедшее изменение курса. Тут есть над чем подумать. И если идти дальше - график работы с педалью газа и, возможно, тормоза - тоже могут что то дать.
О, жму руку, коллега по борьбе. Некоторые мысли:
LBS на каждую точку резолвить может быть накладно, особенно при большом потоке данных.
без CAN/OBD самая ценная часть фильтров превращается в тыкву.
Думал над привязкой к дорожной сети - всякие круги на полях хорошо бы фильтровало, но тоже может быть ресурсоёмко.
Анализ формы трека, но пока не придумал.
жму руку в ответ)
По LBS - когда координаты берутся из своей БД - я пока не заметил проблем (но поток данных пока не такой большой), внешнее api - точно нельзя ждать - только записывать на будущее.
без CAN работает хорошо дельта по высоте и медиана расстояния между точками. остальное - да, вычистить сложно - я пробовал разные геометрические фильтры - на круги и зигзаги, но они режут заезды на эстакады и развороты.
У жесткой привязки к дорожной сети есть проблема - можно срезать заезды в пром зоны, склады и пр. У меня крутится идея - на вычищенном треке иногда остаются островки от согласованных участков, вызванных спуфингом - проверять их на достижимость в сравнении одометра и дорожного графа.
из анализа геометрии - если точка является вершиной поворота так, что угол больше определенного значения - не верить. например если поворот был на 90 градусов, а скорость при этом 70+ - то не верить. но это я пока не пробовал. Вот может быть угол поворота руля как советовали выше сравнивать со скоростью?
если точка является вершиной поворота так, что угол больше определенного значения - не верить.
ну в целом это работает, фильтр острых углов в целом помогает, не панацея конечно.
У жесткой привязки к дорожной сети есть проблема
я думал скорее не о жесткой привязке, а о фильтрации ситуаций когда машина прёт 100км/ч по лесу/озеру/домам
работает хорошо дельта по высоте и медиана расстояния между точками
по моим наблюдениям когда спуфинг рисует круги на полях много, конечно, аномалий по высоте и скорости, но иногда - бац и кусок спуфинга идеально проходит этот фильтр, немного, но трек - в говно.
смотреть не только на граф, но ещё на скорость - это мысль. нужно только зазор оставить, чтобы если машина чуть мимо дороги едет (метров до 20) - не срезать - это погрешность трекера, а не РЭБ. Вопрос только полноты базы дорожных графов нужно исследовать.
А ещё идея - сверять направление движения - с направлением дорожного графа.
Когда от восьми кругов, остаётся островок с несколькими точками, которые уложились во все окна и пороги - это, согласен, обидно. Иногда, в моменты творческого кризиса, у меня появляется идея, что нужно попробовать трек два раза через фильтры прогонять)
ещё признак спуфа - часто скорость почти одинаковая на петле: 98 -102 км/ч, а иногда вообще залипает. но как отличить от движения по трассе на круиз контроле? и второе - нет гарантии, что так будет всегда.
Извините, но может мои знания по нетмониторингу устарели и неправильное Но есть триангуляция , кажется можно определять расстояния до БС с точностью ~500метров/ что мешает купить симки пару операторов , анализировать расстояния до разных БС и рисовать круги пересечений , точность до 1 км точно будет
Еще раз: сейчас вы меряете расстояние до одной БС, так меряйте до трех. И будет у вас треугольник рассеивания составленный из окружностей
да всё правильно триангуляция по вышкам хорошо бы помогла, но железо такое, что даёт только id вышки с которой работает. может быть ограничения в протоколах. Один из производителей недавно выкатил прошивку, которая до записи точки делает запрос на сторонний сервер и подменяет при необходимости gps координаты результатом триангуляции. Но прошивка пока кривовата и на часть трекеров не встаёт, на других - отваливается часть функционала. Но когда этот метод заработает - есть шанс, что большая часть фильтров окажется не нужна.
При усиленном спуфинге и джаминге абсолютно всё уйдет в мусор и позиции не будет. Использование специализированных же антенн обходящих это не оправдано слишком большой ценой
Тут без вопросов - ели машина целый день простояла в зоне работы РЭБ - максимум что можно сделать - показать примерную точку по LBS. если весть трек в зоне подавление - ничего не сделать - не за что "зацепиться". есть api от яндекса - восстанавливают координаты по wifi. но стоит это не дёшево. Можно было бы насобирать базу самостоятельно, через работающие машины, но сами трекеры, которые работаю с wifi стоят раза в 4 дороже обычных.
Интересно, что во многих случаях, гармины, в мультидиапазрнном режиме пишут реальный трек и никуда не летают. Только время старта стало побольше. Может от региона к региону правда еще отличается результат, не могу сказать.
не сколько от региона, сколько от конкретного места - как правило зона работы рэб - это круг радиусом от 2 до 15 км. причём работать она может не постоянно. Исключение - центр Москвы - там покрыто почти всё и постоянно. Если в пределах ТТК работает навигатор, то это заслуга позиционирования по wifi сетям.
Я немного не про это. Я именно что про “качество работы” рэб (может где то не будет работать то что работает у нас).
У нас в городе GPS как таковой не ловит, все летают по кругу за городом (но карта ОТ как то более менее отрисовывает положение вменяемо кстати).
Но именно у бегунов с гарминами, у которых в спеках есть “All-Systems GNSS Mode + Multi-Band” (265, 955) пишется трек как надо, если включить ловить сигнал от всех видов спутников, в отличии от моделей где нет. бывает что первые несколько минут немного повихляет, но дальше становится норм. просто поддержка работы в мультидиапазонном режиме не решает, проверял на amazfit balance, у гарминов там явно какие то свои алгоритмы под это дело заточены.
интересная статья, сколько точек в минуту снимается трек?
это можно настраивать. Как правило - раз в три минуты на стоянке, раз в 20 секунд в движении + дополнительно пишутся точки при изменения курса - чтобы трек на карте не срезал повороты.
я работаю в проекте https://oespulse.ru/
рамках проекта мы собираем телеметрию самосвалов, если телеметрия приходит раз в 3 минуты на стоянках, то параметров для расчета иных состояний и операций не хватит, при такой редкой отсылке данных,
идея ваша понравилась, не против будите если принципы и алгоритмы попробую на своих данных?
так как тоже прострелы и перелеты присутствуют и мы их фильтруем как не валидные а хотелось бы рассчитать.
я часть стояночных точек отбрасываю - если нет изменяющихся параметров - сохраняю только раз в 20 минут (если машина стоит и двигатель заглушен), чтобы БД не забивать. но сейчас подумал, что это может вредить очистки стоянки от дрейфа - честных точек получается меньше чем могло быть - бедная база для фильтра дрейфа.
конечно попробуйте. ради этого статья и писалась - проблема есть, но никто о ней не говорит, только если в общих чертах. Как попробуете - напишите - что сработало, что нет - думаю многим было бы интересно.
Проект посмотрел - масштабный и интересный. Вы предикторскую модель для предсказания неисправностей самосвалов не пробовали реализовать?
Да у нас есть целая служба которая занимается предектикой https://oespulse.ru/roc
Есть хорошие успешные сценарии
Но как показывает практика в этом вопросе главное правильно сформулировать вопрос и понять его, что бы правильно интерпретировать бизнесу.
Занятная статья. Я так понимаю речь про исключительно встроенные приемники в авто? Для отдельных модулей, даже примитивных, можно организовывать детектирование спуфинга мониторя скачки времени приемника и сигнала 1pps.
Нет, не встроенные - обычные навесные телематические трекеры (Galileosky, Vega и пр). В этом проблема - сырых данных приёмника (1PPS, фаза, C/N0, AGC) прошивка трекера мне не отдаёт. Часть производителей начинают в новые прошивки добавлять флаги спуфинга - но верить им пока однозначно нельзя. Точность этих флагов я бы оценил процентов в 60.
думаю, моя борьба с подменой времени, по сути тот же принцип, перенесённый на сервер: детекция расхождения временных шкал. Только опорным генератором вместо 1PPS выступает одометр - единственная монотонная шкала, до которой спуфер не дотягивается. Дискретность только получается огромная - 1 км. У некоторых машин в CAN шине можно найти одометр в метрах - это бы повысило точность детекции на порядок, но это улучшит ситуацию не глобально, а только для частных случаев.
Перечитаю статью ещё раз, но первое, что хотелось бы посоветовать - это узнать какие навигационные модули стоят в блоках мониторинга. Купить, установить и самому потом записать голый NMEA лог. В Unicore модулях, например, есть спец сообщение, что идёт глушение, со спуфинглм не прокатит. Сравнить с данными, которые приходят по протоколу мониторинга, найти зацепку в NMEA, может GSV даст четкий признак и обратиться к разработчику блоков мониторинга для помощи.
Как фильтровать GPS‑треки от ложных точек: спуфинг, заморозка координат, подмена времени