Виявлення "відсутності руху" на пристрої GPS

Ми використовуємо GPS-пристрій для відстеження, встановлений у транспортних засобах, а пізніше відображаємо рухи в нашій програмі. Однак у нас невелика проблема з транспортними засобами, коли вони НЕ рухаються.

Незважаючи на те, що стоїть на місці, GPS-пристрій надсилатиме інформацію з різними положеннями, іноді навіть повідомляє про рух автомобіля (раз у раз він повідомляє про те, що транспортний засіб рухається досить швидко). Кінцевим результатом є потворне зображення руху в нашому додатку, і, що ще гірше, неправильні розрахунки щодо того, як довго автомобіль рухався і стояв нерухомо (у нас також триває статистичний аналіз).

Я знаю, що проблема не нова: Навігація Google на моєму телефоні Android також має проблеми, коли я раз і знову зупиняюся на перехресті, виявляючи, що я зараз їду в зворотному напрямку (адже насправді я стою нерухомо ).

Але нам дійсно потрібно мати якийсь спосіб сказати, що транспортний засіб не рухається, особливо на тривалий час.

Проблема ускладнюється в деяких транспортних засобах, які тримаються під дахами протягом ночі, що призводить до зникнення GPS через слабший сигнал (який все ще досить сильний, щоб отримати позицію, проте).

Ми можемо виявити, чи двигун транспортного засобу включений чи вимкнений, але ми не можемо припустити, що він не рухається з вимкненим двигуном (траплялися випадки, коли буксирували пошкоджений транспортний засіб ... і, звичайно, є випадок потенційної крадіжки, який також повинен повідомляться).

Який найкращий спосіб підійти до цієї проблеми?

Редагувати:

Щоб додати ще трохи інформації:

• Пристрій GPS має акселерометр, але він повертає лише двійкову інформацію (рухається / не рухається), і вона є чутливою до TOO або просто не працює.

• У нас є доступ до таких речей, як кількість супутників або якість, але ми не впевнені, як використовувати цю інформацію. Таким чином, моє питання. :)

• Проблема не в тому, щоб визначити, рухається чи ні транспортний засіб в режимі реального часу. Ми збираємо дані, а пізніше робимо статистичний аналіз та відображаємо їх. Ми показуємо поточне положення транспортного засобу, але це мало маємо значення. Таким чином, ми в основному повинні бути в змозі сказати, що транспортний засіб рухався чи не рухався, переглядаючи історичні дані.

У коментарях під вашим запитанням з’являються деякі хороші моменти, особливо щодо інтерпретації якості супутникових даних (# супутників, потужність сигналу), і ви можете використовувати цю інформацію або на мобільному пристрої, або на сервері, щоб відфільтрувати «погані» значення GPS. Питання зводиться до двох частин: 1) як визначити помилкове зчитування GPS, і 2) як визначити стаціонарний стан.

Почнемо з пари параметрів:

• stationary_speed = якщо мобільний блок йде повільніше, ніж це, то він нерухомий
• too_fast = якщо мобільний блок працює швидше за це, він дав помилкове зчитування GPS

Складно обчислити ці швидкості з точністю. Скажіть, що ви обчислюєте швидкість як / між попереднім читанням (при t0) і поточним читанням (при t1). Якщо дельта часу велика, і одиниця проходить навколо кривої, то фактична пройдена відстань буде більшою, ніж обчислена відстань. Крім того, якщо ви отримаєте два помилкових читання підряд, і вони досить близькі один до одного, то ви можете отримати непередбачувані результати.

Отримавши швидкість, просто порівняйте її з вашими параметрами, щоб побачити, чи є зчитування GPS несправедливим чи пристрій нерухомим.

Можна зробити більш складну фільтрацію за допомогою фільтрів Kalman , але це може бути значно більше.

Нам вдалося налаштувати дані датчика руху.

Використовуючи дані датчика руху, дані запалення та швидкість, про які повідомляє GPS-трекер, ми повинні мати можливість визначити, коли транспортний засіб рухається чи ні з досить хорошою точністю.

Також ми подивилися на кількість супутників, і це не виглядало добре. Хоча кількість супутників була меншою для транспортного засобу під дахом, вона все ще була відносно високою. 9-10 - це звичайне значення для такого транспортного засобу, тоді як під дахом воно опускається до 7 (але час від часу може отримати сигнал і піднятися вгору). Потрібно сказати, що кількість супутників виявилася менш ніж корисною.

Ви можете використовувати кількість сатів, використаних для останнього виправлення, а не ті, що переглядаються. Напр. View = 11, Fix = 5 І використовуйте значення Max DB сигналу найсильнішого sat. Це має бути понад 30Db, щоб отримати гідний сигнал.

Пристрої, якими ми користуємось, мають поняття рухомого / нерухливого, датчиками є: прискорення, вібрація, вхідна напруга, вхідний сигнал (від ключа контакту), дані GPS. Щоб повідомляти про такі позиції, як старт / стоп (це на основі подій) та події / відстані, пристрій повинен знаходитись у режимі переміщення (це лічильник зворотного відліку, який можна налаштувати).

Датчики мають можливість комбінувати. Ні про події / відстані, ні про таймери не повідомляється, поки трекер визначає, що він не перебуває в рухомому режимі. Коли задіяні датчики припиняють звітувати, таймер відлічується до нуля і тоді генерується подія зупинки + прилад переходить у нерухливий режим. До наступного разу. Таким чином, ви можете розділити початкові значення прискорення двигуна, щоб "перевести" його в рух, а також окремий нижній поріг для "утримання" його в рухомому режимі, оскільки обидва є дуже чіткими схемами прискорення.

Підрозділи, які ми використовуємо, повідомлять, якщо точка взята з недобрими даними, не впевнені, чи це робить ваше обладнання. У нас є або SV_Position, або SV_KeepAlive або SV_TimeAlive. Keepalive повторить точне останнє значення, оскільки GPS не може оновити свої таблиці, ані отримати точне виправлення, навіть не погане. TimeAlive - це те, що ви побачите, коли переходите тунель чи хтось припаркувався в гаражі.

Один із способів також контролювати, хоча це частково робить освічені здогадки, і це залежить від виду активів, які ви відстежуєте, - це джерело живлення. напр. пристрій, що працює в 12.30V - це автомобіль, який не працює двигуном. Якщо ви бачите таку, яка повідомляє 14.2v, ви знаєте, що генератор обертається. Для транспортних засобів на 24 В є аналогічна картина.

Сподіваюсь, це дає вам певну ідею. Все трохи залежить від того, наскільки гарне обладнання. Джерело ваших даних починається там, а все інше після цього лише настільки добре, наскільки воно є. Але я б настійно закликав вас використовувати можливості одиниць, щоб робити якісну відмінність, а не робити це на всіх серверах (заднім числом). Після того, як вам подобається 3000 одиниць, вам знадобиться надійний сервер для постійного аналізу всіх даних відстеження, тож тоді ви зрозумієте, що він не буде масштабуватися.

У мене була подібна проблема при використанні GPS-реєстратора для відстеження скутера. Що я робив, це накладання GPS-доріжки на дорожній шар і видалення вручну помилкових місць у перехресті чи світлофорі або поблизу. Я впевнений, що є автоматизовані інструменти для вирішення цього питання, ймовірно, буфери навколо перехресть, і обчислення мінімального та максимального часу в цьому буфері і поза ним.

Термін мистецтва для цього - павук . Поширений підхід полягає в тому, щоб просто вибирати вибірку лише тоді, коли виправлення знаходиться на відстані 10 м від попереднього виправлення. Наприклад, кишенькові апарати Garmin фіксують виправлення на основі відстані, тоді як фітнес спостерігає за виправленнями фіксованих даних за часом . КПК не дуже павукує, але годинник.