Сегодня, на мой взгляд, одна из проблем навигационных устройств – это то, что они не ведут пользователя по полосам. Эта проблема увеличивает время в пути, пробки и аварийность. Недавно google maps начали отображать разметку дороги перед поворотом, что уже хороший результат, но и тут можно многое улучшить. Карты не знают на какой полосе сейчас находится машина, средствами gps узнать это проблематично, у gps слишком большая погрешность для этого. Если бы мы знали текущую полосу, то знали бы скорость движения по полосами и могли бы задолго подсказывать пользователю в явном виде, на какую полосу и когда ему лучше перестроиться. Например, навигатор говорил бы “Продолжайте держаться этой полосы до перекрестка” или “Перестройтесь на крайнюю левую полосу”.
В этой статье мы попробуем рассказать, как мы пытаемся определять перестроения, текущую полосу движения автомобиля, повороты, обгоны, а также другие маневры с помощью машинного обучения по данным акселерометра и гироскопа.
Рекомендовать перестроения, можно не только в случае, если движение по полосе медленное, скажем, из-за того, что с левой полосы поворачивают машины. Также, рекомендовать перестроиться можно в том случае, если на текущей полосе авария. Сейчас аварии и дорожные проблемы наносятся пользователями вручную. Можно было бы сделать алгоритм, который бы наносил их на карту автоматически, смотря на маневры машин. Если автомобили в одном и том же месте массово совершают объезд, то, видимо, там произошла какая-то проблема. Зная это, система могла бы предупреждать водителей, перестроиться на другую полосу заранее, если они ее уже не занимают.
Еще одна проблема, связанная с достаточно низкой точностью gps во дворах, это то, что на извилистых дорожках придомовых территорий достаточно сложно определить положение машины. Положение выдается с точностью плюс минус 10 метров и непонятно прошла ли уже машина поворот или нет. А в незнакомом дворе это критично, ведь мы ориентируемся на навигатор, а он по сути не всегда знает, где мы находимся сейчас. Если бы могли достоверно точно определять поворот, то могли бы вести пользователя не только по gps, а помогать системе позиционирования данными о поворотах и точно знали бы где находится пользователь.
Gps также не сразу может определить разворот машины. Она должна проехать несколько метров назад перед тем, как будет понятно, что был совершен маневр. Если бы мы могли определить разворот сразу, то новый перестроенный маршрут был бы у пользователя намного быстрее.
Перестроение в карман с основной дороги также в случае Gps является спорным моментом, только по ее данным сейчас сложно сказать, перестроился ли пользователь или нет, особенно если карман не глубокий. Если бы был алогоритм, который бы альтернативным способом сообщал эту информацию, то комбинируя ее с Gps, точность можно было бы заметно повысить.
Как предполагается решить эти проблемы?
В свободное время я и несколько студентов Computer Science Center делаем проект с открытым исходным кодом по определению дорожных событий с помощью акселерометра и гироскопа. В итоге мы хотим сделать доступную библиотеку с открытой лицензией, которая позволит, принимая на вход данные от сенсоров мобильного телефона или какого то другого устройства, выдавать на выходе такие события как перестроение на другую полосу, обгон, объезд препятствия, поворот и разворот. Пользователю библиотеки останется реализовать switch в своей программе и правильным образом реагировать на те или иные события.
Использовать библиотеку, по идее, могут не только телефоны, но и, скажем, устройства на базе микроконтроллеров, осуществляющие мониторинг транспорта. Скажу сразу, что мы в середине пути и пока нет уверенности, что мы сможем определять все события, но кажется, у нас может что-то получиться.
Как вообще выглядят различные события, если их отобразить на графике?
События обозначены прерывистыми вертикальными линиями:
Оставим активными только ось y для акселлерометра (боковые перегрузки, верхний график) и ось z гироскопа (вращение машины, вид сверху, нижний график), можно заметить как повороты и развороты сопровождаются увеличенными боковыми перегрузками и увеличивающимся вращением вокруг оси Z. При перестроении гироскоп и акселерометр быстро меняют свои показатели с положительного на отрицательное.
Кажется, что человек, глядя на эти графики, может более менее понять, какой тип события имел место, соответственно, у классификтора на базе алгоритма машинного обучения проблем также возникнуть не должно.
Что было уже реализовано
Мы собрали первоначальные данные: это около 1000 километров видеозаписей и телеметрии, собранной с телефона по дорогам Санкт-Петербурга и Москвы.
Сделали окружение для удобной работы с видео и данными, которое выглядит вот так:
Оно состоит из трех частей. В самом верху просмотр видео с движением машины. В центре располагается график, на котором можно смотреть данные с акселерометра, гироскопа и текущую скорости. В окне внизу можно модифицировать данные скриптом (coffescript) налету для отображения на графике (например, нам нужен сглаженный график).
Помимо этого дэшбоард предоставляет возможность размечать события на видео, сохранять их в файл и видеть их потом отмеченными на графике с аннотациями.
Возможно, кто-то из вас в своих задачах также сопоставляет видеоряд с данными сенсоров, либо просто смотрит на данные сенсоров. Если это так, вам может пригодится дэшборд, в котором мы работаем github.com/blindmotion/dashboard. Он достаточно удобен, позволяет масштабировать, видоизменять данные налету скриптом и у него открытая лицензия, а значит его можно свободно использовать и модифицировать.
Мы также сделали нормализатор для акселерометра и гироскопа
Телефон может быть расположен как угодно в салоне машины, при этом его положение может меняться. Нам нужно привести все данные к одному знаменателю для передачи нашей модели. Для этого человек из нашей команды написал нормализатор, библиотеку, которая вне зависимости от ориентации устройства всегда выдает ось z перпендикулярно Земле, ось x совпадает с направлением движения автомобиля, а ось y перпендикулярна направлению движения является касательной к Земле. Выглядит это как то так:
Для того, чтобы это работало мы вначале ориентируемся на вектор земного притяжения и строим матрицу поворота таким образом, чтобы наша ось z после поворота совпадала с этим вектором. Матрица вращения для правильной ориентации x и y строится чуть более сложным способом.
До нормализации данные выглядят так:
На графике акселлерометра мы видим, что ось X (на графике ax; a – акселлерометр, g — гироскоп) имеет почти постоянно значение примерно равное 10g, что неправильно, так как ось Х — параллельна Земле. Выполняем нормализацию и получаем такой график:
Теперь все на своих местах, значение по оси Z (az) равно 10g, а X и Y соответствующие значения для движения автомобиля.
Нормализатор может пригодиться также в других проектах, не связанных с классификацией событий на дороге, но связанных с обработкой данных от сенсоров.
Сдалали классификатор
Сейчас для классификации используется feedforward neural network с тремя hidden layers и выглядит все это примерно так:
На вход подаются 66 элементов:
20 – показания акселерометра по нормализованной оси Х (боковое ускорение)
20 – показания акселерометра по нормализованной оси Y (продольное ускорение)
20 – показания гироскопа по нормализованной оси Z (вращение вокруг оси перпендикулярной Земле)
5 – показания спидометра gps
1 – время всего маневра
В такой конфигурации, на первый взгляд, получается оптимальное соотношение входных данных и результата, хотя добавление других осей совсем немного улучшает точность.
Более подробно о том, как организовано обучение
Как я уже говорил, на вход подаются показания акселерометра и гироскопа и их ровно по 20 элементов каждого. То есть берем промежуток времени, для этого промежутка берем показания акселерометра по оси Х, по оси Y и гироскопа по оси Z. У нас получается три массива данных и в них не обязательно 20 элементов изначально. К 20 же мы приводим их экстраполяцией или интерполяцией.
Я говорил про промежуток времени. Как его выбрать? Вот есть у нас данные за день. Выше я говорил про дэшборд, в котором мы делаем разметку событий. То есть, говоря простым языком, указываем там, что с 12:00:34 по 12:00:41 у нас было перестроение налево. Так указываем все произошедшие события и получаем некоторое множество событий (events). Помимо событий, все остальное простанство занимает idle, то есть те отрезки времени, в течение которых не было ни перестроений, ни поворотов, ни каких-либо других событий.
Получив множество событий таким образом мы потом последовательно каждым из этих событий обучаем модель. Передаем ей данные события и говорим, что вот это был обгон, скажем.
Модель также учится тому, что такое отсутствие событий. Весь оставшийся промежуток времени, где нет событий, мы делим на какие-то промежутки и также даем модели, говоря, что вот тут ничего нет.
На рисунке изображен этот процесс. Вверху линия – это данные по оси времени. Вот у нас ничего не было (idle), потом пошло событие (event), потом снова ничего, еще одно событие, и снова ничего. Ниже этой линии семплы (желтые квадраты), которые передаются модели для обучения.
Допустим обучили, что дальше? Перейдем к определению событий на новых данных, то есть, классификации.
Имея уже обученную сеть мы можем классифицировать события с ее помощью. Мобильный телефон передает нам постоянный поток данных от датчиков. Мы храним историю всех показаний за последние 30 секунд и передаем эту историю нашей модели в надежде на то, что она сможет там что то найти. Передаются отрезки длиной 2, 4, 6, 8, 10, 15, 20, 25, 30 секунд (образно) и для каждого из отрезков определяется вероятность того или иного события предсказанного моделью.
Например, отрезки:
[с “текущее время” по “2 секунды назад”] – вероятности: idle 51%, поворот налево 23%, поворот направо 52%
[текущее время — 4 секунды назад] – idle 62%, поворот налево 21%, поворот направо 60%
[текущее время — 6 секунды назад] – idle 50%, поворот налево 27%, поворот направо 91%
[текущее время — 8 секунды назад] – idle 52%, поворот налево 17%, поворот направо 72%
Здесь для отрезка времени с текущего момента до 6 секунд назад модель выдает вероятность 91% для поворота направо. Скажем, это больше нашего threshold 90% и мы добавляем на карту событий событие поворот направо для этого времени.
В итоге у нас получается карта отклассифицированных событий, из которой мы можем попробовать сделать вывод о том, какие события все же происходили. На практике одно и то же событие, если делать измерения с шагом в пол секунды по каждому из интервалов (то есть через каждые пол секунды мы повторяем изложенный выше алгоритм с отрезками) может быть определено несколько раз (на рисунке изображено 2 раза, два зеленых event в центре рисунка). Чтобы разобраться с ними воспользуемся алгоритмом кластеризации. Я использовал density-based clustering (DBSCAN). Идея его примерно такая:
То есть, если нам предсказали в какой-то точке 8 раз то, что тут есть перестроение налево то мыпонимаем, что да, перестроение действительно было. На рисунке горизонтальная ось – это скажем время, а красные точки – это определенное моделью перестроение налево для разных отрезков близких друг к другу.
Результаты работы классификатора
Результаты работы можно визуально сравнить, увидев разметку событий, сделанную человеком и алгоритмом.
События, размеченные человеком:
И моделью:
Тут видно, что модель пропустила перестроение налево после первого поворота направо и добавила перестроение налево после поворота налево. Но, посмотрев видео, там эта ситуация кажется спорной, траектория действительно похожа на перестроение налево. Ну и дальше пропустила поворот и в момент парковки машины решила, что я поворачиваю.
Вот видео этого участка (лучше смотреть в hd, чтобы было видно график):
Какова же точность классификатора? Для test set цифры следующие
Тут приводятся цифры для всех событий, которые были сделаны машиной за два часа: все перестроения, повороты, обгоны. Число правильно и неправильно определенных событий.
Test set – это данные, на которых мы не учились и по которым не корректировали никак нашу модель и алгоритм кластеризации.
Correct type:
59 – столько событий было определено корректно
Wrong type:
16 – столько событий было определено, но не корректно
False positive:
17 – столько событий нейронная сеть выдумала сама, на самом деле их быть не должно
False negative:
26 – события, которые не были определены моделью, но которые на самом деле есть
Correct percent
0.5 – процент точности включая False negative
0.6413043478260869 – процент точности не включая False negative. Метрика с таким подходом: “пропустила что-то и бог с ним, лишь бы неправильно не говорила”
В целом неплохо, учитывая что всего событий 10 (5 разных, которые делятся на левые и правые), то генератор случайных чисел выдавал бы нам точность порядка, скажем 10 процентов точности. А тут 50, что уже хорошо.
Конечно, цифры пока не позволяют говорить об использовании библиотеки в реальном времени, но уже позволяет собирать аггрегированную статистику и на ее основе делать какие-то выводы, но в плане реального времени ошибок пока еще много.
Под реальным временем я понимаю то, что работая на телефоне или другом устройстве, алгоритм надежно сможет говорить программе, что только что было произведено перестроение. Под агрегированной статистикой я понимаю некий алгоритм на сервере, который собирает эти события со всех устройств и делает на основе этого какие-то выводы.
Есть большое поле для улучшений и думаю что месяцев через 6-9 алгоритм может стать вполне пригодным и для использования в реальном времени.
Как выглядят разные события глазами нейронной сети
Вот так обобщенно выглядят события глазами нейронной сети. Это сильно обобщенное представление, на самом деле внутри оно намного более многогранно, но приведя к одной плоскости получается примерно такая картина:
Это графики бокового ускорения (помним, ось Y). Верхний ряд — это перестроения: налево и направо. Можно увидеть что при перестроении ускорение меняется от одной строны к другой.
Нижний ряд – повороты налево и направо, ускорение возрастает до какого-то значения и потом к концу маневра убывает.
Где посмотреть на проект
Проект находится здесь github.com/blindmotion/docs/wiki и мы были бы рады, если бы он пригодился вам. Он состоит из достаточно большого количества частей, каждая из них в отдельном репозитории, документация же по вышеобозначенной ссылке.
Что дальше
Дальше мы планируем улучшать классификатор, чтобы он мог точнее определять события. Когда это произойдет, то, наверное, мы попробуем сделать простое приложение для андроида, которое будет проговаривать произошедшее событие. Скажем, вы перестроились или повернули и приложение сообщило об этом.
Как вы можете помочь
Наш проект – это проект с открытым исходным кодом. Прежде всего вы можете помочь нам данными. Если вы можете установить на свой телефон видеорегистратор и программу для записи значений датчиков и включать их тогда, когда вы едете, мы были бы очень признательны и добавили бы вас в список контрибьюторов данных на гитхабе. Данные от других людей нам сильно нужны, потому что у вас скорее всего другой телефон, другая машина и другой стиль вождения. Это позволит модели учиться на различных данных.
Также нам можно помочь с разметкой этих данных в нашем дэшборде, это не самое увлекательное занятие, нужно на видео размечать такие события как перестроения, повороты и прочее, но если у вас есть желание помочь таким образом – то welcome.
Ну и конечно же вы можете принять участие в разработке самой модели и конечной библиотеки. Для работы над моделью порог вхождения – это возможность самостоятельно сделать модель, которая бы работала примерно так же как существующая или лучше по параметрам точности. Откуда брать уже размеченные данные для собственной модели я, естественно, расскажу.
Если вы хотите помочь каким то из способов – смело пишите в приват или на гитхаб.
Буду рад ответить на ваши вопросы в комментариях. Спасибо за внимание.
FAQ.
Мы не ставим перед собой цель определять ямы и неровности на дорогах, это уже было сделано до нас. Но в целом на базе этой платформы, кажется, что это делается несложно.
Комментарии (77)
nomadmoon
03.04.2015 09:15> Если вы можете установить на свой телефон видеорегистратор и программу для записи значений датчиков
А какую программу-видеорегистратор бы вы порекомендовали для этого?
lamerman Автор
03.04.2015 09:27+1Мы используем видеорегистратор DailyRoads Voyager и программу для записи показаний датчиков Sensor Recording Pro. Последняя платная, но хорошо работающая.
Для того, чтобы собрать данные, нужно запускать их параллельно, при этом качество видео должно быть не самым хорошим. Разрешение порядка 640 на 480 и общий поток не более 100 мегабайт за 5 минут. Это позволяет разглядеть маневры машины и, при этом, не занимать очень много места в облачных хранилищах. Звук стоит отключать из соображений приватности, по умолчанию он там выключен.
Нужны именно эти две программы, поскольку мы используем их формат в наших скриптах и приложениях.
Yurich
03.04.2015 09:26+2Было бы полезно для увеличения точности читать CAN bus автомобиля. Встроенные навигаторы (мой, во всяком случае) это делают, поэтому довольно корректно работают в условиях отсутствия покрытия gps, например в тоннелях. Дрейф есть, разумеется, самый большой я получил на 11-километровом тоннеле, но он, по счастью был прямой без вариантов. А вот когда навигатор корректно подсказывает повороты в относительно коротких тоннелях, это дорогого стоит.
lamerman Автор
03.04.2015 09:29Это хорошая идея и должна работать действительно точно, но мы пошли таким путем для массовости продукта. Мы хотели, чтобы этим мог воспользоваться любой человек, у которого есть мобильный телефон. :)
Yurich
03.04.2015 10:17+4вы же понимаете, что bluetooth-донгл для диагностического разъема стоит копеек и выдает весьма формализованные данные?
попробуйте его включить, как опцию, заодно и сможете учинить экстра-сервис с сообщениями об ошибках в оборудовании автомобиля
кстати, искренне мечтаю о видеорегистраторе, который будет писать не только gps-треки, но еще и состояния педалей, поворотников и фар из кан-шины.
это же просто получится практически черный ящик :)
ну и лишнее доказательство, что не затормозил внезапно (стоп-сигналы горели достаточно долго для принятия решения тем орлом, что въехал мне в задницу, поворотник был заблаговременно включен и т.п.)Rumlin
03.04.2015 10:42Подозреваю что у разработчиков может не быть автомобиля с диагностическим разъемом (по крайней мере доступного или личного). Тут нужны добровольцы.
Yurich
03.04.2015 10:44+2Таковых автомобилей вроде бы уже не выпускается. Даже в нынешних жигулях он есть.
Rumlin
03.04.2015 10:56Для этого нужно условие — купить автомобиль.
Сомневаюсь, что у студентов есть своей новый авто. Преподаватель может вообще не иметь или иметь несовременный. Часто люди консервативны и пользуются тем что есть. Недавно столкнулся с амаксофобией и людьми, которые отказались от авто в пользу велосипедов (авто осталось — используется женой).Yurich
03.04.2015 11:14+1Ход Ваших рассуждений безусловно интересен. Тем не менее в статье есть картинки, которые демонстрируют нам наличие как минимум постоянного доступа к автомобилю (ну ведь как-то графики ускорений ребята поснимали, и вряд ли они ездили в трамвае для этого, да?).
Что же до наличия у студентов автомобиля вообще — даже в моё студенчество у двоих моих одногруппников были машины, а уж теперь-то…Rumlin
03.04.2015 11:42Мы ушли в оффтоп. Мода меняется. Имхо мощный фитнес велокомпьютер будет не менее востребован среди поколения разработчиков этого «устройства». Опять же могут быть региональные особенности или «тут совпало», что доступен был только один авто на котором один день удалось поездить и пособирать данные.
vershov
03.04.2015 11:22+1Простите, а на какие данные с OBD разъема Вы расчитываете, как на помощь (увеличение точности) в определении маневров?
Yurich
03.04.2015 11:56скорость автомобиля
lamerman Автор
03.04.2015 12:03данные о скорости сейчас доступны из Gps :)
Rumlin
03.04.2015 12:35GPS это средняя скорость, а спидометр показывает мгновенную. Хотя для каких целей это пригодится…
vershov
03.04.2015 12:47+1Скорость на спидометре и скорость из OBD порта — это, в общем случае, разные источники. Наблюдал, как после остановки машины, скорость, получаемая из OBD порта, «таяла» в течении пары секунд с 10 км/ч до 0.
FYR
03.04.2015 12:53Спидометр покеазывает не скорость автомобиля, а нечно пропорциональное скорости вращения колеса и его радиуса. При этом еще и имеет искусственно заданную погрешность.
Насчет доступа к данным на CAN-шине: их во первых может быть две, а во вторых протокол общения устройств проприетарный проприетарный. Автопроизводитель не заинтересован в публикации этого протокола. Он может меняться даже в зависимости от года выпуска модели. Плюс доступ к управлению двигателем/аппаратурой/электронным газом/электроусилителем. Плюс проблемы с электрическим подключением к не самым дешевым устройствам чревато потерей гарантии…
Нет спасибо — не надо ничего такого подключать к моей машине.Rumlin
03.04.2015 17:10пропорциональное скорости вращения колеса и его радиуса
Именно
Например, искры из-под точильного станка двигаются, повторяя направление мгновенной скорости.
FYR
03.04.2015 18:03Я это к тому что спидометр откалиброван ± лапоть для некого стандартного размера профиля колес/шины (от которого зависит реальная скорость авто относительно земли). Он кстати может меняться в достаточно широких пределах tyres.spb.ru/tirecalc
Сюда мы еще можем записать проскальзывание колес / юз и работу дифференциалов.
Вообще сюдя по десятку страниц «куча замечаний, когда автопарковка может работать не правильно» в руководстве на мою машинку — не такое это плевое дело определить положение машинки в пространстве.Rumlin
03.04.2015 19:58да, при смене заводских колесных дисков и покрышек на нестандартные, показания будут убегать. Как вариант ввести калибровку по GPS. Заодно можно будет определять, что давление в колесах снизилось и предупреждать.
vershov
03.04.2015 12:43Если отсутсвует сигнал со спутников, то надо решать задачу определения местоположения совершенно иными методами: Dead Reckoning и Map Matching (в идеальном случае с обратной связью в DR модуль).
Если сигнал со спутников есть, то скорость лучше брать с GNSS модуля. Да и что-то мне подсказывает (особенно глядя на графики) что скорость роли особой не играет в определении событий.
imwode
03.04.2015 16:28Угол поворота руля,
и если есть— поворотники
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.pdfvershov
03.04.2015 21:00Я более чем уверен, что это устройство:
— нестандартный OBD юнит, подходящий только для некоторых (америанцы) машин и не устанавливаемое по умолчанию;
— если позиционируется как стандартное, то это разводка.
Ну и пункт номер 2: как эти алгоритмы, даже имея угол поворота руля и знание о включенных поворотниках определят полосу после поворота на картинке ниже?
картинка
AlexRoch
03.04.2015 15:44Есть такой сервис Wayjournal.com, как раз то, что Вам надо. Пишите видео, одновременно пишется трек основных параметров ECU автомобиля.
BelBES
03.04.2015 10:20А видео-данные вы и дальше планируете использовать только для ручной разметки показаний с приборов, или будете расширять свою систему и на обработку видео?
lamerman Автор
03.04.2015 10:25Не уверен, что до конца понял вопрос, поправьте, если понял не так.
Я так понял вопрос в том, не планируем ли мы в дальнейшем определять маневры по видео. Если так, то пока что не планируем и основной мотив — потому, что люди не смогут располагать в своем автомобиле телефоны таким образом, чтобы не загораживать видеокамеру держателем и она смотрела на дорогу. Плюс ко всему, обработка видео сейчас занимает много процессорного времени.
С сенсорами все несколько проще, телефон может быть расположен как угодно.BelBES
03.04.2015 10:32Да, вопрос был именно в этом. А вы только на мобилы ориентируетесь? (не обратил внимания на этот момент). Тогда да, на этом железе сложно запустить что-то сложнее детектора линий…
lamerman Автор
03.04.2015 12:07На мобильные телефоны, устройства для мониторинга транспорта, возможно другие
gleb_l
03.04.2015 13:03+1Каким образом нормализатор определяет направление оси X, связанное с продольной осью машины? Это же невозможно в статике.
У меня была подобная задача — в теоретической проработке я сначала приводил ось Z по модулю ускорения в статике (или брал с API мобильного устройства, которое дает направление вектора G, подсчитанное видимо так же), а потом анализировал статистику карты ускорений в плоскости XY, и определял ось X как направление, в котором двумерная карта интегрированных по мгновенным ускорениям скоростей имела наибольшую дисперсию, а направление оси X (то есть ускорение/торможение) — по наличию/отсутствию признака движения в условиях малых модулей ускорения по приведенной оси Х. GPS при этом не использовалсяlamerman Автор
03.04.2015 15:02я отвечу чуть позже, нужно посмотреть в код, но у нас для оси Х используется gps
lamerman Автор
04.04.2015 16:23Там общая идея примерно такая: вначале мы делаем такое вращение, чтобы ось 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
realbtr
03.04.2015 13:09Рассматривали ли Вы такой сценарий — водитель берет смартфон в руки, для каких-нибудь целей (выбрать другой адрес, ответить на звонок или позвонить, сделать снимок и т.п.?
Ведь это движение не связано с движением автомобиля и будет вносить искажения в собираемую телеметрию?lamerman Автор
03.04.2015 13:14Да, в тот момент, когда телефон находится у него в руках мы не можем собирать точные данные, потому что он скорее всего будет постоянно вращаться, но как только он его положит на место нормализатор определит это и поменяет вектора вращения и данные снова начнут поступать.
ProLimit
03.04.2015 14:25+1Самое главное не понял: из вступления к статье прослеживалось, что глобальная цель — показать навигацию по полосам, для этого нужно знать в какой полосе сейчас машина. Но как ваша разработка, с достаточно низкой (даже теоретически) точность определения событий, поможет определить это? Пропустили одно перестроение и все, вся дальнейшая информация неверная. А повороты и с помощью низкой точности GPS определяются замечательно, с привязкой к карте.
Обозначьте, пожалуйста, практическую пользу, которую может принести это приложение в будущем.
PS: Проделанная работа вызывает уважение.lamerman Автор
03.04.2015 15:30+1Хороший вопрос.
Из статьи действительно не так очевидно, как в дальнейшем все это будет превращаться в навигацию по полосам. Навигацию мы сможем сделать в том случае, если нам удастся повысить точность определения событий с нынешних 50 процентов. Поэтому, предположим, что перестроения мы определяем достаточно точно.
Умея определять перестроения, мы можем, запустив этот алгоритм на тысячах устройств, попробовать определить полосность всех дорог (то есть сколько полос есть у дороги). Устройства будут передавать информацию о перестроениях на сервер и агрегируя эту информацию можно попытаться понять, сколько где полос.
Если мы будем знать полосность дороги, то, кажется что можно будет определить по действиям пользователя, на какой полосе он находится. Эту задачу лучше решать компьютеру, мне кажется он лучше составит алгоритм, чем человек. Можно попробовать обучить, например, какую-нибудь разновидность classification tree на большом объеме данных, где факторами будут выступать наличие перестроений, полосность дороги, что-то еще. Но если бы я сам составлял такой алгоритм, то например, на дороге с двумя полосами, вычислить полосу после перестроения налево не представляется сложным. Вариант только один — машина на левой полосе. В этом случае пропуск одного перестроения не критичен, всегда можно начать с чистого листа.
Повороты на открытой местности — да, но уходы в карман, думаю, намного сложнее, особенно если он не глубокий. Повороты же во дворах — совсем другая история, там у gps очень большой разброс.
MagicWolf
03.04.2015 15:05Добавил на Hacker News — Blind Motion detects car turns, overtakes, etc. using mobile sensor data
lamerman Автор
03.04.2015 15:08Спасибо, я думал чуть позже разместить на HN перевод статьи :) нужно ее перевести только. Но это тоже не лишнее :)
buriy
03.04.2015 15:17И ещё, кстати: в iphone вроде бы есть компас, а это значит, что вы можете отказаться от ручной разметки данных для поворотов, да и смена полосы тоже основывается на временном изменении направления движения.
Предполагаю, что таким образом с помощью Machine Learning можно научиться получать показания виртуального компаса на основании данных других датчиков, используя размеченные данные с реальным компасом.
Ну а с компасом и данными о текущей скорости определение полосы и всего прочего уже достаточно простая задача.
utya
03.04.2015 18:31Спасибо за работу ребята. Занимаюсь именно такой проблемой(правда один), поэтому понимаю какая работа была проделано. После прочтения поста не совсем понял, точнее не до конца понял, что есть основная цель. Но сейчас вроде вижу посты выше, и понимаю. В кругах мапперов проскакивал такой термин как Dead Reckoning, данный алгоритм решал похожую задачу навигация внутри туннелей, парковочных площадок и т.д. Базой для алгоритма являлся фильтр Калмана, он комплексировал данный с инерциалки и gps, у вас что является фундаментом алгоритма?
Насчёт CAN шины, идея хорошая, избыточная информация не повредит в любом случаи никак. Но полезная инфа обычно дешевыми китайскими can-bluetooth не поддерживается.lamerman Автор
03.04.2015 18:39Тут несколько иное, мы не предсказываем позицию, дополняя gps, мы стараемся определять маневры машины. То есть сейчас, нам все равно в какой точке пространства окажется автомобиль после перестроения или обгона, для нас важно определить сами факты перестроения или поворота скажем.
У нас было проект номер два инерциальное дополнение gps, но мы вряд ли когда то будем заниматься им как сейчас поняли :)utya
03.04.2015 18:44У нас было проект номер два инерциальное дополнение gps, но мы вряд ли когда то будем заниматься им как сейчас поняли :)
почему?
Вы собираете статистику потом её скармливаете нейросети, она в будущем будет фильтровать и понимать произведен поворот или разворот, а дальше что?
Кстати что за нейросеть?lamerman Автор
03.04.2015 18:48Я писал об этом в своем посте и частично в этом комментарии habrahabr.ru/post/254707/#comment_8359769 :)
нейросеть — Сеть прямого распространения, я также описывал это в постеutya
03.04.2015 18:52Есть какие нибудь публикации по данной теме?
lamerman Автор
03.04.2015 18:56Из наших публикация — это первая публичная, а остальные я не смог найти, когда искал. Вот хотел как-нибудь перевести статью на английский язык и запостить, тогда может быть найдутся те, кто тоже этим занимаются.
utya
03.04.2015 19:00Если вам нужны статьи по данной тематике я могу вам скинуть, конечно они полностью не повторяют вашу методику, но звучат аля «использование методов искусственого интеллекта в (нужное подставить) навигации». А в вопросе имел ввиду ВАШИ публикации
lamerman Автор
03.04.2015 20:41Да, можно сюда приаттачить ссылки. Думаю тем кто будет читать тоже может быть интересно
roller
04.04.2015 13:30Эх, жаль нет у вас софтинки для телефона (самописной). Очень бы хотелось принимать и записать данные по блютусу с пары датчиков внешних, ну и чтобы сразу ппосмотреть их на красивом графике и кластеризовать события.
mahowik
04.04.2015 18:27А не пробовали FFT прикрутить? Если правильно выделить период события (размер выборки) и фазу (старт точку периода) то на выходе будет довольно четкая картинка независимая от периода и скорости маневра соот-но. Т.е. спектральная картинка будет одинаковой для однотипных маневров выполненных с разной скоростью. И как бы получится нормализация по временной оси. Таким образом на вход нейронной сети уже будут подаваться однотипные картинки спектра маневров, что значительно упростит, как саму сеть (кол-во входных элементов), так и повысит точность распознавания… по идее… ))
lamerman Автор
05.04.2015 15:17Не совсем понимаю, что будет подаваться на вход FFT? :) у нас есть оси xyz для гироскопа и акселерометра. Продолжительность события отличается очень сильно от события к событию, если это имеется ввиду под периодом. Не мог бы немного подробнее описать? :)
mahowik
06.04.2015 00:13+1Да, под периодом я имел ввиду продолжительность события.
вижу я это так примерно:
— Выделяем период (у вас я так понял уже есть механизм для этого)
— Для каждой из осей прогоняем самплы (все точки пероида) через fft
— Получаем три картинки спектра на выходе. 6-10 гармоник будет вполне достаточно по идее
— Отдаем их на вход сети…
Таким образом сразу двух зайцев ловим. Первый — компресия выборки в 6 -10 значений/гармоник спектра, второй — фильтрация шумов сенсоров и не интересных в данном контексте высших гармоник.lamerman Автор
06.04.2015 08:27Звучит интересно, я правда не представляю как это будет работать в жизни в плане эффективности :) Можно попробовать занести в чек лист.
alman
07.04.2015 17:49Насколько сложен алгоритм? Насколько реально реализовать его в просто микроконтроллере? Какие требования по памяти и быстродействию?
lamerman Автор
07.04.2015 17:53Пока что нет финальной версии алгоритма, только эксперименты. Если эксперимент будет удачным, то тогда начнется его оптимизация по памяти и cpu. Сейчас про требования сложно говорить, но вообще это делается для телефонов по крайней мере.
OverQuantum
07.04.2015 22:09А траекторию можно записывать? Т.е. получать GPS-трек, уточнённый по акселерометру и гироскопу.
lamerman Автор
07.04.2015 22:33нет :)
OverQuantum
07.04.2015 22:41Ну… подумайте над этим. Для уточнения карт очень пригодилось бы. Отрисовки полос на дорог, например.
igor_suhorukov
Респект! Работа вызывает уважение!!!
Когда появятся open source автопилоты?)
lamerman Автор
Спасибо за отзыв.
Скоро, совсем скоро, я в этом уверен. :)
igor_suhorukov
Проверяли как алгоритм AdaBoost влияет на результирующую точность для вашей нейросети прямого распространения?
lamerman Автор
пока что не успели этого сделать
lamerman Автор
голосование нескольких классификаторов дало порядка 5 процентов точности, нужно будет попробовать AdaBoost
Yurich
Вы ведь читали про дурацкую первоапрельскую шутку в опенсорс-прошивке для кэнона?
Я бы очень серьезно задумался, стоит ли доверять опенсорсу в системе, которая может для лулзов уронить машину с моста.
nomadmoon
Выдыхайте. Это всего лишь приложение для смартфона, оно не будет вырывать у вас руль из рук :)
Yurich
Вы спорите с каким-то своим тезисом, похоже, а не с моим ответом на вполне конкретную реплику про автопилоты.
Black_Shadow
Всего лишь одна неудачная шутка в Open Source прошивке и тонны пасхальных яиц и не выявленных багов в закрытом ПО.
igor_suhorukov
В проприетарном софте все бы долго думали что это баг или фича) А тут быстро нашли причину и того кто нагадил
BelBES
Ну, вот например в Tesla автомобилях имеются «пасхалки» в ПО, какую они воткнут следующей — не известно и по большому счету никто об этом не узнает, пока не аукнется. Это не говоря о багах, которые есть в любом коде.
з.ы. к слову говоря, уже давно существуют альтернативные прошивки например для автоматических коробок переключения передач…