Как стать автором
Обновить

Машинное обучение в навигационных устройствах: определяем маневры машины по акселерометру и гироскопу

Время на прочтение10 мин
Количество просмотров26K
Всего голосов 67: ↑63 и ↓4+59
Комментарии77

Комментарии 77

Респект! Работа вызывает уважение!!!
Когда появятся open source автопилоты?)
Спасибо за отзыв.
Скоро, совсем скоро, я в этом уверен. :)
Проверяли как алгоритм AdaBoost влияет на результирующую точность для вашей нейросети прямого распространения?
пока что не успели этого сделать
голосование нескольких классификаторов дало порядка 5 процентов точности, нужно будет попробовать AdaBoost
Вы ведь читали про дурацкую первоапрельскую шутку в опенсорс-прошивке для кэнона?
Я бы очень серьезно задумался, стоит ли доверять опенсорсу в системе, которая может для лулзов уронить машину с моста.
Выдыхайте. Это всего лишь приложение для смартфона, оно не будет вырывать у вас руль из рук :)
Вы спорите с каким-то своим тезисом, похоже, а не с моим ответом на вполне конкретную реплику про автопилоты.
Всего лишь одна неудачная шутка в Open Source прошивке и тонны пасхальных яиц и не выявленных багов в закрытом ПО.
В проприетарном софте все бы долго думали что это баг или фича) А тут быстро нашли причину и того кто нагадил
Ну, вот например в Tesla автомобилях имеются «пасхалки» в ПО, какую они воткнут следующей — не известно и по большому счету никто об этом не узнает, пока не аукнется. Это не говоря о багах, которые есть в любом коде.

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

А какую программу-видеорегистратор бы вы порекомендовали для этого?
Мы используем видеорегистратор DailyRoads Voyager и программу для записи показаний датчиков Sensor Recording Pro. Последняя платная, но хорошо работающая.
Для того, чтобы собрать данные, нужно запускать их параллельно, при этом качество видео должно быть не самым хорошим. Разрешение порядка 640 на 480 и общий поток не более 100 мегабайт за 5 минут. Это позволяет разглядеть маневры машины и, при этом, не занимать очень много места в облачных хранилищах. Звук стоит отключать из соображений приватности, по умолчанию он там выключен.
Нужны именно эти две программы, поскольку мы используем их формат в наших скриптах и приложениях.
Было бы полезно для увеличения точности читать CAN bus автомобиля. Встроенные навигаторы (мой, во всяком случае) это делают, поэтому довольно корректно работают в условиях отсутствия покрытия gps, например в тоннелях. Дрейф есть, разумеется, самый большой я получил на 11-километровом тоннеле, но он, по счастью был прямой без вариантов. А вот когда навигатор корректно подсказывает повороты в относительно коротких тоннелях, это дорогого стоит.
Это хорошая идея и должна работать действительно точно, но мы пошли таким путем для массовости продукта. Мы хотели, чтобы этим мог воспользоваться любой человек, у которого есть мобильный телефон. :)
вы же понимаете, что bluetooth-донгл для диагностического разъема стоит копеек и выдает весьма формализованные данные?
попробуйте его включить, как опцию, заодно и сможете учинить экстра-сервис с сообщениями об ошибках в оборудовании автомобиля
кстати, искренне мечтаю о видеорегистраторе, который будет писать не только gps-треки, но еще и состояния педалей, поворотников и фар из кан-шины.
это же просто получится практически черный ящик :)
ну и лишнее доказательство, что не затормозил внезапно (стоп-сигналы горели достаточно долго для принятия решения тем орлом, что въехал мне в задницу, поворотник был заблаговременно включен и т.п.)
Подозреваю что у разработчиков может не быть автомобиля с диагностическим разъемом (по крайней мере доступного или личного). Тут нужны добровольцы.
Таковых автомобилей вроде бы уже не выпускается. Даже в нынешних жигулях он есть.
Для этого нужно условие — купить автомобиль.
Сомневаюсь, что у студентов есть своей новый авто. Преподаватель может вообще не иметь или иметь несовременный. Часто люди консервативны и пользуются тем что есть. Недавно столкнулся с амаксофобией и людьми, которые отказались от авто в пользу велосипедов (авто осталось — используется женой).
Ход Ваших рассуждений безусловно интересен. Тем не менее в статье есть картинки, которые демонстрируют нам наличие как минимум постоянного доступа к автомобилю (ну ведь как-то графики ускорений ребята поснимали, и вряд ли они ездили в трамвае для этого, да?).
Что же до наличия у студентов автомобиля вообще — даже в моё студенчество у двоих моих одногруппников были машины, а уж теперь-то…
Мы ушли в оффтоп. Мода меняется. Имхо мощный фитнес велокомпьютер будет не менее востребован среди поколения разработчиков этого «устройства». Опять же могут быть региональные особенности или «тут совпало», что доступен был только один авто на котором один день удалось поездить и пособирать данные.
Простите, а на какие данные с OBD разъема Вы расчитываете, как на помощь (увеличение точности) в определении маневров?
скорость автомобиля
GPS это средняя скорость, а спидометр показывает мгновенную. Хотя для каких целей это пригодится…
Скорость на спидометре и скорость из OBD порта — это, в общем случае, разные источники. Наблюдал, как после остановки машины, скорость, получаемая из OBD порта, «таяла» в течении пары секунд с 10 км/ч до 0.
Спидометр покеазывает не скорость автомобиля, а нечно пропорциональное скорости вращения колеса и его радиуса. При этом еще и имеет искусственно заданную погрешность.
Насчет доступа к данным на CAN-шине: их во первых может быть две, а во вторых протокол общения устройств проприетарный проприетарный. Автопроизводитель не заинтересован в публикации этого протокола. Он может меняться даже в зависимости от года выпуска модели. Плюс доступ к управлению двигателем/аппаратурой/электронным газом/электроусилителем. Плюс проблемы с электрическим подключением к не самым дешевым устройствам чревато потерей гарантии…
Нет спасибо — не надо ничего такого подключать к моей машине.
пропорциональное скорости вращения колеса и его радиуса

Именно
image

Например, искры из-под точильного станка двигаются, повторяя направление мгновенной скорости.
Я это к тому что спидометр откалиброван ± лапоть для некого стандартного размера профиля колес/шины (от которого зависит реальная скорость авто относительно земли). Он кстати может меняться в достаточно широких пределах tyres.spb.ru/tirecalc

Сюда мы еще можем записать проскальзывание колес / юз и работу дифференциалов.

Вообще сюдя по десятку страниц «куча замечаний, когда автопарковка может работать не правильно» в руководстве на мою машинку — не такое это плевое дело определить положение машинки в пространстве.
да, при смене заводских колесных дисков и покрышек на нестандартные, показания будут убегать. Как вариант ввести калибровку по GPS. Заодно можно будет определять, что давление в колесах снизилось и предупреждать.
А что, в смартфоне мало датчиков для того, чтобы померять мгновенные скорость/ускорение по всем осям?
При равномерном прямолинейном движении автомобиля ускорение отсутствует.
Если отсутсвует сигнал со спутников, то надо решать задачу определения местоположения совершенно иными методами: Dead Reckoning и Map Matching (в идеальном случае с обратной связью в DR модуль).
Если сигнал со спутников есть, то скорость лучше брать с GNSS модуля. Да и что-то мне подсказывает (особенно глядя на графики) что скорость роли особой не играет в определении событий.
Угол поворота руля, и если есть — поворотники

0x1E Turn Signal Status
Return Value of 0 = Turn Signal Off
Return Value of 1 = Left Turn On
Return Value of 2 = Right Turn On
Return Value of 3 = Both Signals On
NOTE: On some vehicles the turn signal reports on and off periodically as the signal
flashes. Polling may have to be done more frequently from the Streamer to catch the
changing signal.

www.rvdstreamer.com/assets/files/manuals/OBDII_Streamer_Command_and_Response_V2.07.pdf
Я более чем уверен, что это устройство:
— нестандартный OBD юнит, подходящий только для некоторых (америанцы) машин и не устанавливаемое по умолчанию;
— если позиционируется как стандартное, то это разводка.

Ну и пункт номер 2: как эти алгоритмы, даже имея угол поворота руля и знание о включенных поворотниках определят полосу после поворота на картинке ниже?
картинка


Возращаясь к теме статьи, технология интересная, но:
— не пременима для уточнения позиции
— не пременима как lane detection механизм
Есть такой сервис Wayjournal.com, как раз то, что Вам надо. Пишите видео, одновременно пишется трек основных параметров ECU автомобиля.
А можно подробнее? что это за навигатор, и как именно он использует CAN?
Попробуйте поставить RNN на выходе DNN — должно повысить точность.
А видео-данные вы и дальше планируете использовать только для ручной разметки показаний с приборов, или будете расширять свою систему и на обработку видео?
Не уверен, что до конца понял вопрос, поправьте, если понял не так.
Я так понял вопрос в том, не планируем ли мы в дальнейшем определять маневры по видео. Если так, то пока что не планируем и основной мотив — потому, что люди не смогут располагать в своем автомобиле телефоны таким образом, чтобы не загораживать видеокамеру держателем и она смотрела на дорогу. Плюс ко всему, обработка видео сейчас занимает много процессорного времени.
С сенсорами все несколько проще, телефон может быть расположен как угодно.
Да, вопрос был именно в этом. А вы только на мобилы ориентируетесь? (не обратил внимания на этот момент). Тогда да, на этом железе сложно запустить что-то сложнее детектора линий…
На мобильные телефоны, устройства для мониторинга транспорта, возможно другие
Каким образом нормализатор определяет направление оси X, связанное с продольной осью машины? Это же невозможно в статике.

У меня была подобная задача — в теоретической проработке я сначала приводил ось Z по модулю ускорения в статике (или брал с API мобильного устройства, которое дает направление вектора G, подсчитанное видимо так же), а потом анализировал статистику карты ускорений в плоскости XY, и определял ось X как направление, в котором двумерная карта интегрированных по мгновенным ускорениям скоростей имела наибольшую дисперсию, а направление оси X (то есть ускорение/торможение) — по наличию/отсутствию признака движения в условиях малых модулей ускорения по приведенной оси Х. GPS при этом не использовался
я отвечу чуть позже, нужно посмотреть в код, но у нас для оси Х используется gps
Там общая идея примерно такая: вначале мы делаем такое вращение, чтобы ось z стала перпендикулярна Земле. Это понятно как делать и достаточно просто.
Это делается тут github.com/blindmotion/normalizer/blob/master/src/main.cpp#L167

После того как мы это сделали, уже в динамике при движении машины, основываясь на ускорении и вращении по оси Z в момент этого ускорения мы строим новую матрицу поворота, по которым выравниваем оси y и x
github.com/blindmotion/normalizer/blob/master/src/main.cpp#L174

Вот здесь можно посмотреть функцию, которая это делает:
github.com/blindmotion/normalizer/blob/master/src/utils.cpp#L189
Рассматривали ли Вы такой сценарий — водитель берет смартфон в руки, для каких-нибудь целей (выбрать другой адрес, ответить на звонок или позвонить, сделать снимок и т.п.?

Ведь это движение не связано с движением автомобиля и будет вносить искажения в собираемую телеметрию?
Да, в тот момент, когда телефон находится у него в руках мы не можем собирать точные данные, потому что он скорее всего будет постоянно вращаться, но как только он его положит на место нормализатор определит это и поменяет вектора вращения и данные снова начнут поступать.
Самое главное не понял: из вступления к статье прослеживалось, что глобальная цель — показать навигацию по полосам, для этого нужно знать в какой полосе сейчас машина. Но как ваша разработка, с достаточно низкой (даже теоретически) точность определения событий, поможет определить это? Пропустили одно перестроение и все, вся дальнейшая информация неверная. А повороты и с помощью низкой точности GPS определяются замечательно, с привязкой к карте.
Обозначьте, пожалуйста, практическую пользу, которую может принести это приложение в будущем.
PS: Проделанная работа вызывает уважение.
Хороший вопрос.
Из статьи действительно не так очевидно, как в дальнейшем все это будет превращаться в навигацию по полосам. Навигацию мы сможем сделать в том случае, если нам удастся повысить точность определения событий с нынешних 50 процентов. Поэтому, предположим, что перестроения мы определяем достаточно точно.
Умея определять перестроения, мы можем, запустив этот алгоритм на тысячах устройств, попробовать определить полосность всех дорог (то есть сколько полос есть у дороги). Устройства будут передавать информацию о перестроениях на сервер и агрегируя эту информацию можно попытаться понять, сколько где полос.
Если мы будем знать полосность дороги, то, кажется что можно будет определить по действиям пользователя, на какой полосе он находится. Эту задачу лучше решать компьютеру, мне кажется он лучше составит алгоритм, чем человек. Можно попробовать обучить, например, какую-нибудь разновидность classification tree на большом объеме данных, где факторами будут выступать наличие перестроений, полосность дороги, что-то еще. Но если бы я сам составлял такой алгоритм, то например, на дороге с двумя полосами, вычислить полосу после перестроения налево не представляется сложным. Вариант только один — машина на левой полосе. В этом случае пропуск одного перестроения не критичен, всегда можно начать с чистого листа.
Повороты на открытой местности — да, но уходы в карман, думаю, намного сложнее, особенно если он не глубокий. Повороты же во дворах — совсем другая история, там у gps очень большой разброс.
Спасибо, я думал чуть позже разместить на HN перевод статьи :) нужно ее перевести только. Но это тоже не лишнее :)
Можно написать в треде «Author is here, be sure to ask if you have any questions», если есть желание отвечать на вопросы.
Пока что не надо, я думал потом разместить там перевод статьи.
И ещё, кстати: в iphone вроде бы есть компас, а это значит, что вы можете отказаться от ручной разметки данных для поворотов, да и смена полосы тоже основывается на временном изменении направления движения.
Предполагаю, что таким образом с помощью Machine Learning можно научиться получать показания виртуального компаса на основании данных других датчиков, используя размеченные данные с реальным компасом.
Ну а с компасом и данными о текущей скорости определение полосы и всего прочего уже достаточно простая задача.
Спасибо за работу ребята. Занимаюсь именно такой проблемой(правда один), поэтому понимаю какая работа была проделано. После прочтения поста не совсем понял, точнее не до конца понял, что есть основная цель. Но сейчас вроде вижу посты выше, и понимаю. В кругах мапперов проскакивал такой термин как Dead Reckoning, данный алгоритм решал похожую задачу навигация внутри туннелей, парковочных площадок и т.д. Базой для алгоритма являлся фильтр Калмана, он комплексировал данный с инерциалки и gps, у вас что является фундаментом алгоритма?
Насчёт CAN шины, идея хорошая, избыточная информация не повредит в любом случаи никак. Но полезная инфа обычно дешевыми китайскими can-bluetooth не поддерживается.
Тут несколько иное, мы не предсказываем позицию, дополняя gps, мы стараемся определять маневры машины. То есть сейчас, нам все равно в какой точке пространства окажется автомобиль после перестроения или обгона, для нас важно определить сами факты перестроения или поворота скажем.
У нас было проект номер два инерциальное дополнение gps, но мы вряд ли когда то будем заниматься им как сейчас поняли :)
У нас было проект номер два инерциальное дополнение gps, но мы вряд ли когда то будем заниматься им как сейчас поняли :)
почему?
Вы собираете статистику потом её скармливаете нейросети, она в будущем будет фильтровать и понимать произведен поворот или разворот, а дальше что?
Кстати что за нейросеть?
Я писал об этом в своем посте и частично в этом комментарии habrahabr.ru/post/254707/#comment_8359769 :)
нейросеть — Сеть прямого распространения, я также описывал это в посте
Есть какие нибудь публикации по данной теме?
Из наших публикация — это первая публичная, а остальные я не смог найти, когда искал. Вот хотел как-нибудь перевести статью на английский язык и запостить, тогда может быть найдутся те, кто тоже этим занимаются.
Если вам нужны статьи по данной тематике я могу вам скинуть, конечно они полностью не повторяют вашу методику, но звучат аля «использование методов искусственого интеллекта в (нужное подставить) навигации». А в вопросе имел ввиду ВАШИ публикации
Да, можно сюда приаттачить ссылки. Думаю тем кто будет читать тоже может быть интересно
Эх, жаль нет у вас софтинки для телефона (самописной). Очень бы хотелось принимать и записать данные по блютусу с пары датчиков внешних, ну и чтобы сразу ппосмотреть их на красивом графике и кластеризовать события.
А не пробовали FFT прикрутить? Если правильно выделить период события (размер выборки) и фазу (старт точку периода) то на выходе будет довольно четкая картинка независимая от периода и скорости маневра соот-но. Т.е. спектральная картинка будет одинаковой для однотипных маневров выполненных с разной скоростью. И как бы получится нормализация по временной оси. Таким образом на вход нейронной сети уже будут подаваться однотипные картинки спектра маневров, что значительно упростит, как саму сеть (кол-во входных элементов), так и повысит точность распознавания… по идее… ))
Не совсем понимаю, что будет подаваться на вход FFT? :) у нас есть оси xyz для гироскопа и акселерометра. Продолжительность события отличается очень сильно от события к событию, если это имеется ввиду под периодом. Не мог бы немного подробнее описать? :)
Да, под периодом я имел ввиду продолжительность события.

вижу я это так примерно:
— Выделяем период (у вас я так понял уже есть механизм для этого)
— Для каждой из осей прогоняем самплы (все точки пероида) через fft
— Получаем три картинки спектра на выходе. 6-10 гармоник будет вполне достаточно по идее
— Отдаем их на вход сети…

Таким образом сразу двух зайцев ловим. Первый — компресия выборки в 6 -10 значений/гармоник спектра, второй — фильтрация шумов сенсоров и не интересных в данном контексте высших гармоник.
Звучит интересно, я правда не представляю как это будет работать в жизни в плане эффективности :) Можно попробовать занести в чек лист.
Насколько сложен алгоритм? Насколько реально реализовать его в просто микроконтроллере? Какие требования по памяти и быстродействию?
Пока что нет финальной версии алгоритма, только эксперименты. Если эксперимент будет удачным, то тогда начнется его оптимизация по памяти и cpu. Сейчас про требования сложно говорить, но вообще это делается для телефонов по крайней мере.
А траекторию можно записывать? Т.е. получать GPS-трек, уточнённый по акселерометру и гироскопу.
нет :)
Ну… подумайте над этим. Для уточнения карт очень пригодилось бы. Отрисовки полос на дорог, например.
Добрый день!

Как с вами можно связаться? Есть вопросы по тематике статьи :)
Добрый день.

Да как угодно в целом, можно в комментариях, можно приватным сообщением на Хабре.
Может, какие-то еще способы есть? Вопрос не очень публичный, а личные сообщения почему-то недоступны.
можно еще по электронной почте alexander996 yandex.ru
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории