Комментарии 20
Простите что немного не в тему.
Глядя на последнее фото, стало интересно: а сегодня устанавливает кто-либо камеры заднего вида на такие длинные прицепы?
Upd. Спасибо за статью!
Глядя на последнее фото, стало интересно: а сегодня устанавливает кто-либо камеры заднего вида на такие длинные прицепы?
Upd. Спасибо за статью!
Тоже пришлось и устройство делать и софт, так как подходящего не было в продаже.
Но это обычный процесс. Что надо, то и делаешь — или используешь, то что другие сделали.
История примерно как в баре за пивом.
Но это обычный процесс. Что надо, то и делаешь — или используешь, то что другие сделали.
История примерно как в баре за пивом.
Интересно, спасибо! С большим FIFO после перерыва связи коллеги тоже сталкивались. Теперь после восстановления канала сначала отправляется самый свежий пакет и только потом накопленный буфер.
частота сбора данных увеличивается пропорционально скорости
Не имеет ли смысла по умолчанию регулировать частоту сбора обратно пропорционально скорости? По идее как раз если машина находится на трассе, то сразу бы получались прямые отрезки между точками которых было бы достаточно на трассе, а при замедлении уже шёл бы более подробный трек (в случае съезда с трассы или даже при движении по городу).
А вы где-то реализовали контроль скорости в реальном времени по геозонам?
Какие по вашему подводные камни могут быть?
Нет, такого не было. Но чисто умозрительно я вижу два подводных камня
1) Контроль по скорости необходимо делать через CAN-Bus, так как скорость от GPS не слишком точная и может сильно прыгать, особенно если приёмник старый. Если нет такой возможности, то будет очень много ложных срабатываний.
2) Геозона для контроля скорости скорее всего будет намного более сложной, чем круг или квадрат. Я в своё время начал делать полигональные геозоны, но для них процессору считать больше, а все вычисления — выполнение этого алгоритма для каждой имеющейся геозоны — должны происходить в течении примерно двух секунд (время от получения одной координаты с GPS до получения следующей). На том железе, которое у меня есть, скорости процессора не хватало. На современном андроид-планшете с мощным процессором может и хватит, если геозон не слишком много.
1) Контроль по скорости необходимо делать через CAN-Bus, так как скорость от GPS не слишком точная и может сильно прыгать, особенно если приёмник старый. Если нет такой возможности, то будет очень много ложных срабатываний.
2) Геозона для контроля скорости скорее всего будет намного более сложной, чем круг или квадрат. Я в своё время начал делать полигональные геозоны, но для них процессору считать больше, а все вычисления — выполнение этого алгоритма для каждой имеющейся геозоны — должны происходить в течении примерно двух секунд (время от получения одной координаты с GPS до получения следующей). На том железе, которое у меня есть, скорости процессора не хватало. На современном андроид-планшете с мощным процессором может и хватит, если геозон не слишком много.
Спасибо.
1) К сожалению у нас нет подключения к CAN-Bus. Будем усреднять данные GPS.
2) Мы решили считать уже на сервере после получения данных.
2) Геозона для контроля скорости скорее всего будет намного более сложной, чем круг или квадрат. Я в своё время начал делать полигональные геозоны
А нельзя ли «оптимизировать» полигональные геозоны в набор кругов/квадратов?
Ведь грузовики ездят по дорогам, и как выглядит граница зоны на поле или в реке рядом с ней — неважно: главное, чтобы граница круга совпадала с границей сложной фигуры в каждой точке, где дорога входит в геозону. А для ряда кругов вроде бы считать проще — последовательно проверяем расстояние от центра каждого и сравниваем с радиусом.
Показал на примере родного города: чёрные круги — центры условно тех точек, где разрешенные 60 превращаются в разрешенные 90. Красным — сложный полигон, в котором нам надо контролировать скорость, граница которого совпадает с границей города. Синим — круги, в которые входят все дороги полигона (города) и не входит ни одна загородная, а их границы совпадают с выездом из города.
Картинка с кругами
И вместо одной проверки вхождения в регион получаете множество (не сильно более «дешёвых») проверок вхождения в простые фигуры.
И совсем весело станет проверять скоростной режим на участке дороги.
Зря паритесь.
Алгоритм вхождения точки в полигон совсем несложный и не особо затратный по ресурсам.
И совсем весело станет проверять скоростной режим на участке дороги.
Зря паритесь.
Алгоритм вхождения точки в полигон совсем несложный и не особо затратный по ресурсам.
Проще для геозон предварительно вычислить габаритные прямоугольники, для точки делаем быструю выборку подходящих, из найденного искать уже по полигону.
В одной и той же геозоне может быть несколько ограничений скорости — это я как водитель говорю.
Может быть трасса с ограничением 90 и рядом городская дорога с ограничением 60. А расстояние между ними 10 метров.
Стоит ли входить в GPS-мониторинг как некий сервис собирающий данные онлайн и предоставляющий определенное API для разработчиков, ну и плюс веб и все остальное?
или все места под солнцем уже заняты аля Wialon?
А какая киллер-фича может быть востребована, которая не реализуется гигантами рынка? :)
или все места под солнцем уже заняты аля Wialon?
А какая киллер-фича может быть востребована, которая не реализуется гигантами рынка? :)
Киллер-фича, которая не реализуется гигантами рынка, это разработка GPS-мониторинга для какой-то определённой ниши. Как я уже писал в статье, помимо стандартного мониторинга мусоровозам требуется одни специфические функции, бензовозам другие, развозчикам посылок третие. Чем больше такой специфики, тем интереснее такой сервис клиентам.
Для этого правда необходимо привязывать мониторинг транспорта к системе, которая обрабатывает логистику для этой конкретной ниши, соответственно кроме API может быть вариант найти разработчиков такой системы и предложить им прямое сотрудничество.
Для этого правда необходимо привязывать мониторинг транспорта к системе, которая обрабатывает логистику для этой конкретной ниши, соответственно кроме API может быть вариант найти разработчиков такой системы и предложить им прямое сотрудничество.
По моему разработчики логистики сами способны создать сервер, который принимает данные GPS (они же разработчики).Т.о. сотрудничества тут не получится. Есть много опенсурс решений, которые они могут взять и допилить. Меня больше интересует вопрос, где найти таких «прямых» клиентов, которые были бы заинтересованы в создании специфического мониторинга под себя. С учетом, конечно, того факта что система не будет им принадлежать, и за которую они будут платить на общих основаниях.
Эта статья напомнила мне мою первую работу — гос. контору, которую как раз только открыли для установки трекеров на автомобили спецслужб и прочее. Сам ставил трекеры, сам администрировал систему мониторинга. Что только ни делали водители с трекерами — и в воде топили, и 220 на вход подавали, и антены откручивали, и потом, когда был риск спалиться, не в той последовательности прикручивали… Веселое время было.
Немного странно слышать от вас в комментарии, что скорость по GPS неточна. По спецификации на старых приемниках погрешность по скорости 0.4 км/ч, на новых 0.2 км/ч. Я даже сделал прибор гоночной GPS-телеметрии, которая собирает данные 10 раз в секунду чисто по GPS. Точность получилась на очень высоком уровне, гонщикам нравится.
Немного странно слышать от вас в комментарии, что скорость по GPS неточна. По спецификации на старых приемниках погрешность по скорости 0.4 км/ч, на новых 0.2 км/ч. Я даже сделал прибор гоночной GPS-телеметрии, которая собирает данные 10 раз в секунду чисто по GPS. Точность получилась на очень высоком уровне, гонщикам нравится.
Ага, было дело. Клиент постоянно ругался, что ничего у него не работает месяцами. А когда наш представитель (бывший водила) приехал, чтобы сам посмотреть на грузовики, внезапно всё заработало.
Насчёт неточной скорости от GPS — наверное это сильно зависит от приёмника и мне с теми, что были, очень не везло — часто большие прыжки (к примеру с 70 км/ч вдруг на 120 км/ч, хотя у грузовика аппаратно заперто всё, что выше 80 км/ч), приходилось делать фильтры.
Самые большие проблемы были со старыми ublox TIM.
Насчёт неточной скорости от GPS — наверное это сильно зависит от приёмника и мне с теми, что были, очень не везло — часто большие прыжки (к примеру с 70 км/ч вдруг на 120 км/ч, хотя у грузовика аппаратно заперто всё, что выше 80 км/ч), приходилось делать фильтры.
Самые большие проблемы были со старыми ublox TIM.
В нашей компании мы как раз и пошли по пути использования обычных планшетов (после небольшой модификации) в качестве основы для системы сбора/мониторинга данных о грузовике. Отсутствие необъодимых промышленых интерфейсов нивелируется наличием беспроводных интерфейсов у планшета. Правда, периодически наталкиваемся на аппаратные ограничеиния/баги подобного рода устройств, которые приходится обкладывать костылями. Сейчас начали менять архитектуру системы таким образом, чтобы планшет выступал в роли дисплея с программным обеспичением, а все критически выжные модули (GSM, GPS) работали независимо от планшета.
Misra12345 knows bugger all about logistics by the way
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Шпионим за грузовиками