Привет, Хабр. Это пост-отчет-тьюториал про беспилотные автомобили — как (начать) делать свой без расходов на оборудование. Весь код доступен на github, и помимо прочего вы научитесь легко генерить такие класные картинки:
Вкратце
Краткое содержание для знакомых с темой: традиционно для набора обучающей выборки для автопилота на основе машинного обучения нужен был специально оборудованный автомобиль с достаточно информативной CAN шиной и интерфейсом к ней, что дорого. Мы поступим проще и бесплатно — будем набирать такие же по сути данные просто со смартфона на лобовом стекле. Подходит любой авто, никаких модификаций оборудования. В этой серии — вычисляем поворот руля в каждый момент времени по видео. Если в этом абзаце всё понятно, можно перепрыгивать через введение сразу к сути подхода.
Что-зачем-почему более подробно
Итак, ещё пару лет назад без серьёзных ресурсов большой корпорации в тему автопилотов было не сунуться — один только LIDAR сенсор стоил десятки тысяч долларов, но недавняя революция в нейросетях всё изменила. Стартапы из нескольких человек с простейшими наборами сенсоров из пары вебкамер на равных конкурируют по качеству результата со знаменитыми брендами. Почему бы не попробовать и нам, тем более столько качественных компонентов уже в открытом доступе.
Автопилот преобразует данные сенсоров в управляющие воздействия — поворот руля и требуемое ускорение/замедление. В системе с лазерными дальномерами, как у Google, это может выглядеть так:
Простейший же вариант сенсора — видеокамера, "смотрящая" через лобовое стекло. С ним и будем работать, ведь камера на телефоне уже есть у каждого.
Для вычисления управляющих сигналов из "сырого" видео хорошо работают сверточные нейросети, но, как и любой другой подход машинного обучения, предсказывать правильный результат их нужно научить. Для обучения нужно (а) выбрать архитектуру модели и (б) сформировать обучающую выборку, которая будет демонстрировать модели различные входные ситуации и "правильные ответы" (например, угол поворота руля и положение педали газа) на каждую из них. Данные для обучающей выборки обычно записывают с заездов, где машиной управляет человек. То есть водитель демонстрирует роботу, как надо управлять машиной.
Хороших архитектур нейросетей хватает в открытом доступе, а вот с данными ситуация более печальная: во-первых данных просто мало, во-вторых почти все выборки — из США, а у нас на дорогах много от тех мест отличий.
Дефицит открытых данных легко объясним. Во-первых данные — не менее ценный актив, чем экспертиза в алгоритмах и моделях, поэтому делиться никто не торопится:
The rocket engine is the models and the fuel is the data.
Andrew Ng
Во-вторых, процесс сбора данных недёшев, особенно если действовать "в лоб". Хороший пример — Udacity. Они специально подобрали модель автомобиля, где рулевое управление и газ/тормоз завязаны на цифровую шину, сделали интерфейс к шине и считывают оттуда данные напрямую. Плюс подхода — высокое качество данных. Минус — серьезная стоимость, отсекающая подавляющее большинство непрофессионалов. Ведь далеко не каждый даже современный авто пишет в CAN всю нужную нам информацию, да и с интерфейсом придется повозиться.
Мы поступим проще. Записываем "сырые" данные (пока что это будет просто видео) смартфоном на лобовом стекле как видеорегистратором, затем софтом "выжимаем" оттуда нужную информацию — скорость движения и поворотов, на которых уже можно будет обучать автопилот. В результате получаем почти бесплатное решение — если есть держалка для телефона на лобовое стекло, достаточно нажать кнопку, чтобы набирать обучающие данные по дороге на работу.
В этой серии — "выжималка" угла поворота из видео. Все шаги легко повторить своими силами с помощью кода на github.
Задача
Решаем задачу:
- Есть видео с камеры, жестко закрепленной к авто (т.е. камера не болтается).
- Требуется для каждого кадра узнать текущий угол поворота руля.
Ожидаемый результат:
Сразу чуть упростим — вместо угла поворота руля будем вычислять угловую скорость в горизонтальной плоскости. Это примерно эквивалентная информация если знать поступательную скорость, которой мы займемся в следующей серии.
Решение
Решение можно собрать из общедоступных компонент, немного их доработав:
Восстанавливаем траекторию камеры
Первый шаг — восстановление траекториии камеры в трехмерном пространстве с помощью библиотеки SLAM по видео (simultaneous localization and mapping, одновременная локализация и построение карты). На выходе для каждого (почти, см. нюансы) кадра получаем 6 параметров положения: 3D смещение и 3 угла ориентации.
В коде за эту часть отвечает модуль optical_trajectories
Нюансы:
- При записи видео не гонитесь за максимальным разрешением — дальше определенного порога оно только повредит. У меня хорошо работают настройки в окрестностях 720х480.
- Камеру нужно будет откалибровать (инструкции, теория — актуальны части 1 и 2) на тех же настройках, с которыми записывалось видео с заезда.
- Системе SLAM нужна "хорошая" последовательность кадров, за которую можно "зацепиться" как за точку отсчета, поэтому часть видео в начале, пока система не "зацепится" останется не аннотированным. Если на вашем видео локализация не работает совсем, вероятны либо проблемы с калибровкой (попробуйте откалибровать несколько раз и посмотрите на разброс результатов), либо проблемы с качеством видео (слишком высокое разрешание, слишком сильное сжатие и т.д.).
- Возможны срывы отслеживания SLAM системой, если между соседними кадрами потеряется слишком много ключевых точек например, стекло на мгновение залило всплеском из лужи). В этом случае система сбросится в исходное не локализованное состояние и будет локализовываться заново. Поэтому из одного видео можно получить несколько траекторий (не пересекающихся во времени). Системы координат в этих траекториях будут совершенно разными.
- Конкретная библиотека ORB_SLAM2, которой я воспользовался, дает не очень надежные результаты по поступательным перемещениям, поэтому их пока игнорируем, а вот вращения определяет неплохо, их оставляем.
Определяем плоскость дороги
Траектория камеры в трехмерном пространстве — это хорошо, но напрямую еще не дает ответа на конечный вопрос — поворачивать налево или направо, и насколько быстро. Ведь у системы SLAM нет понятий "плоскость дороги", "верх-низ", и т.д. Эту информацию тоже надо добывать из "сырой" 3D траектории.
Здесь поможет простое наблюдение: автомобильные дороги обычно протягиваются гораздо дальше по горизонтали, чем по вертикали. Бывают конечно исключения, ими придется пренебречь. А раз так, можно принять ближайшую плоскость (т.е. плоскость, проекция на которую дает минимальную ошибку реконструкции) нашей траектории за горизонтальную плоскость дороги.
Горизонтальную плоскость выделяем прекрасным методом главных компонент по всем 3D точкам траектории — убираем направление с наименьшим собственным числом, и оставшиеся два дадут оптимальную плоскость.
За логику выделения плоскости также отвечает модуль optical_trajectories
Нюанс:
Из сути главных компонент понятно, что кроме горных дорог выделение главной плоскости будет плохо работать если машина всё время ехала по прямой, — ведь тогда только одно направление настоящей горизонтальной плоскости будет иметь большой диапазон значений, а диапазон по оставшемуся перпендикулярному горизонтальному направлению и по вертикали будут сопоставимы.
Чтобы не загрязнять данные большими погрешностями с таких траекторий, проверяем, что разброс по последнему главному компоненту значительно (в 100 раз) меньше, чем по предпоследнему. Не прошедшие траектории просто выкидываем.
Вычисляем угол поворота
Зная базисные векторы горизонтальной плоскости v1 и v2 (два главных компонента с наибольшими собственными значениями из предыдущей части), проецируем на горизонтальную плоскость оптическую ось камеры:
Таким образом из трехмерной ориентации камеры получаем курсовой угол автомобиля (с точностью до неизвестной константы, т.к. ось камеры и ось автомобиля в общем случае не совпадает). Поскольку нас интересует только интенсивность поворота (т.е. угловая скорость), эта константа и не нужна.
Угол поворота между соседними кадрами дает школьная тригонометрия (первый множитель — абсолютная величина поворота, второй — знак, определяющий направление налево/направо). Здесь под at понимаем вектор проекции ahorizontal в момент времени t:
Эта часть вычислений тоже делается модулем optical_trajectories. На выходе получаем JSON файл следующего формата:
{
"plane": [
[ 0.35, 0.20, 0.91],
[ 0.94, -0.11, -0.33]
],
"trajectory": [
...,
{
"frame_id": 6710,
"planar_direction": [ 0.91, -0.33 ],
"pose": {
"rotation": {
"w": 0.99,
"x": -0.001,
"y": 0.001,
"z": 0.002
},
"translation": [ -0.005, 0.009, 0.046 ]
},
"time_usec": 223623466,
"turn_angle": 0.0017
},
.....
}
Значения компонент:
plane— базисные векторы горизонтальной плоскости.trajectory— список элементов, по одному на каждый успешно отслеженный системой SLAM кадр.
frame_id— номер кадра в исходном видео (начиная с 0).planar_direction— проекция отпической оси на горизонтальную плоскостьpose— положение камеры в 3D пространстве
rotation— ориентация оптической оси в формате единичного кватерниона.translation— смещение.
time_use— время с начала видео в микросекундахturn_angle— горизонтальное вращение относительно предыдущего кадра в радианах.
Убираем шум
Мы почти у цели, но остается еще проблема. Посмотрим на получившийся (пока что) график угловой скорости:
Визуализируем на видео:
Видно, что в общем направление поворота определяется правильно, но очень много высокочастотного шума. Убираем его Гауссовским размытием, которое является низкочастотным фильтром.
Сглаживание в коде производится модулем smooth_heading_directions
Результат после фильтра:
Это уже можно "скормить" обучаемой модели и рассчитывать на адекватные результаты.
Визуализация
Для наглядности по данным из JSON файлов траекторий можно наложить виртуальный руль на исходное видео, как на демках выше, и проверить, правильно ли он крутится. Этим занимается модуль render_turning.
Также легко построить покадровый график. Например, в IPython ноутбуке с установленным matplotlib:
import matplotlib
%matplotlib inline
import matplotlib.pyplot as plt
import json
json_raw = json.load(open('path/to/trajectory.json'))
rotations = [x['turn_angle'] for x in json_raw['trajectory']]
plt.plot(rotations, label='Rotations')
plt.show()На этом пока всё. В следующей серии — определяем поступательную скорость, чтобы обучить еще и управление скоростью, а пока что приветствуются pull-request'ы.
Комментарии (41)
imbasoft
05.04.2017 13:59Подскажите, при использовании SLAM, если камера видит зеркало или телевизор у нее сильно «башня» съезжает? и вообще что происходит
waiwnf
05.04.2017 14:27+1Хороший вопрос… Если они не очень большую часть кадра занимают, то ничего особенного не должно произойти.
Прямо в деталях не разбирался, но НЯП этот SLAM выделяет в кадре ключевые точки, вероятностно их сопоставляет с точками предыдущего кадра и считает локальную жесткую трансформацию старых точек, которая минимизирует дистанцию (в среднем) до соответствующих новых. Если большинство ключевых точек — на неподвижных объектах, то всё в целом хорошо. На дороге постоянно часть точек цепляется за встречные и попутные авто, и SLAM нормально работает при этом. В упор к зеркалу подносить не пробовал.
Есть проблема когда, например, едешь в пробке вплотную за маршруткой, которая половину кадра занимает. Тогда большинство точек — на движущейся маршрутке, и тут уже у SLAM едет крыша и он думает, что стоим на месте, что относительно маршрутки впереди на самом деле так. Но тут уже чудес ожидать нет смысла. Есть план прикрутить фильтрацию движущихся объектов. Например на yolo определять машины и пешеходов, и рядом с ними ключевые точки для SLAM игнорировать, но руки пока не дошли.
kostialopuhin
05.04.2017 14:35+1Вы как-нибудь проверяли, как соотносится угловая скорость или угол поворота полученные при помощи SLAM и реальные значения в тот же момент времени?
waiwnf
05.04.2017 14:47+1Пока что только на глаз — по крайней мере углы на траекториях очень похожи на то, что на местности, ну и руль на видосах крутится вроде разумно при объезде луж. Когда доковыряю запись акселерометра, можно будет оттуда еще попробовать независимый трек вытащить и сопоставить, но когда руки дойдут ещё не знаю.
А так есть стандартные датасеты и бенчмарки для видео SLAM систем:
http://www.cvlibs.net/datasets/kitti/eval_odometry.php — там гораздо более информативно. Но там камера другая была, а от камеры много зависит. Например видео SLAM любит широкоугольные объективы, а у смартфонов они более длиннофокусные обычно. Global shutter ещё желательно, что тоже далеко не везде есть.
DirectX
05.04.2017 15:07+1А не проще дооборудовать руль и педали датчиками на базе какого-нибудь Ардуино, что-нибудь быстро монтируемое на базе оптопар + наклеек со штрихкодами или переменных резисторов? Качество данных ведь должно быть сильно выше, особенно памятуя про то, что измеренные по видео скорость/ускорение это некая свертка из управляющих воздействий на педали газа и тормоза, а нужны именно они.
DirectX
05.04.2017 15:18Угловые энкодеры не так сложно приколхозить,
писать три угла на sd-карту, синхронизировать с видео примерно по времени + специальный звук.
waiwnf
05.04.2017 15:18Тоже вполне рабочий вариант, многие так делают. Но (а) я лично совсем не умею в железо к сож., поэтому мне точно не проще, и (б) хочется в итоге получить решение для масштабного краудсорса данных, а там каждый чих по покупке и монтажу/наклейке/настройке будет отсекать потенциальных пользователей толпами. Пока что рабочая гипотеза — что сильно хуже такие данные не будут.
Управляющие воздействия хотя и придется делать индивидуальными для каждой модели авто, деваться некуда, но пока что мне кажется, что это будет несложно (поступательная скорость + угол поворота колес + колесная база + сход-развал какой-нибудь должны давать достаточно, чтобы угловую скорость ту же посчитать нормально, ну и обратно из угловой скорости в поворот колес).
DirectX
05.04.2017 15:22Положение педалей также можно фиксировать с помощью инфракрасного датчика приближения, например TCRT5000 (установив в основании педали некую мишень)
waiwnf
05.04.2017 15:33Ага, спасибо за инфо, посмотрю! С педалями на самом деле проще, если есть желание возиться с доп железом — bluetooth адаптер на OBD2 разъем, и считываем всё с блока управления напрямую. С рулём сложнее, НЯП если усилитель гидравлический, то информации об угле поворота в CAN просто нет, и остается либо из видео тащить, либо датчики угловой скорости добавлять, либо метку + отслеживание на само рулевое колесо.
dimka890
05.04.2017 18:22На счет гидроусилителя не факт, у меня Е53, там гидроусилитель и датчик поворота руля есть, можно читать по OBD2 положения руля и педалей (по крайней мере педаль газа точно). Датчик положения руля, насколько я понимаю, необходим для системы стабилизации DSC. Так что в теории такой датчик должен присутствовать на множестве машин с такими системами стабилизации. Плюс в довесок, в такой старой машине есть CAN шина, но она только в моторной и коробочной проводке, но по идее к ней нет труда подключиться + сама приборка работает как «роутер» между шинами.
waiwnf
05.04.2017 18:23Интересно, спасибо за инфо!
dimka890
05.04.2017 18:33Кстати во многих старых BMW такое есть на этой платформе (e38,e39,e53,e83,e46), в принципе если дойдете до железных тестов это хороший вариант, насколько знаю в России (если Вы из России) они не дорогие, ну а в Украине тесты можно и на нерастаможке делать)
ubobrov
05.04.2017 23:06На моей 46-й датчика угла поворота руля нет, как и положения педали акселератора. Это, скорее всего, зависит от комплектации.
ser-mk
05.04.2017 20:07а почему бы не расположить так камеру что бы в её поле зрения попадал руль? или хотя бы часть руля?
На руль можно нанести контрастные метки и по ним определять положение руля.
Отлично будет если в поле зрении будет панель приборов ( в частности спидометр и одометр ), тогда и траектории можно будет более точно определять.waiwnf
06.04.2017 10:12Не пробовал, но тоже вполне вариант, да. Там свой набор задач придется решить, навскидку: экспозиция, если делать всё одной камерой — элементы в салоне обычно гораздо темнее, чем за окном; фокусировка, чтобы и условные метки на руле и дорога были четко видны; разрешение видео если пытаться смотреть на спидометр и по нему скорость определять — там будет хорошо если по 50 пикселей в каждом направлении. Если брать отдельную камеру для руля и приборки, становится проще с оптикой, но надо возиться с синхронизацией.
В общем очевидно халявного решения не видно, везде свои плюсы и минусы, остается вкусовщина, кому какой тип задач интереснее.
ShmaltS
06.04.2017 11:40Возможно тупой вопрос, но почему не взять видео с регистратора, например?
waiwnf
06.04.2017 11:50Просто у меня нет регистратора :)
Кроме шуток же, если нужен только угол поворота из видео, то хороший регистратор может быть даже лучше смартфона, т.к. в регистраторах обычно более широкоугольные объективы, а SLAM как раз любит широкое поле зрения. Но я хочу ещё и поступательную скорость получить, а с ней уже у SLAM сложности, поэтому нужно будет GPS и акселерометр подтягивать.
Есть конечно продвинутые регистраторы, где все эти датчики есть, но это уже далеко не каждый будет заморачиваться с покупкой, а телефон у всех и так есть.ShmaltS
06.04.2017 11:53У меня такой, вот и думаю, есть ли смысл ставить телефон или можно обойтись пережатым видео с регика.
waiwnf
06.04.2017 11:59Должно работать с пережатым (по разрешению) не хуже, чем с телефоном. Главное для калибровки видео записывать и пережимать с теми же настройками, ну и при пережатии битрейт не зажимать, чтобы артефактов кодека не добавлялось.
waiwnf
06.04.2017 12:04А, ещё если в регистраторе есть автофокусировка, то для калибровки её лучше выключить и поставить на бесконечность, т.к. в дороге предметы гораздо дальше от камеры, чем калибровочный лист в комнате, а мы хотим одинаковые настройки по возможности.
ser-mk
06.04.2017 13:11GPS вы тоже используете?
Тогда непонятно зачем использовать SLAM, я так понял она используется для построения трэка, хотя тот же трэк можно снять и с GPS. Или у SLAM точность выходит выше?
Еще навеяло мыслью про модуль optical_trajectories.
что кроме горных дорог выделение главной плоскости будет плохо работать если машина всё время ехала по прямой
Может имеет смысл так же для оценки положения дороги брать данные с геокарт, ведь если есть gps то координаты мы тоже знаем и направление дороги можно предсказыватьwaiwnf
06.04.2017 13:25GPS сейчас не используется, всё строится чисто из видео. У потребительских GPS приемников недостаточная точность и частота обновления (по кр. мере, насколько я видел что получается с телефона), для определения поворотов в нужном качестве. Особенно когда это не дорога за угол поворачивает и можно ещё что-то проинтерполировать, а машина колдобину размером в 50см объезжает. Для поворотов у SLAM точность явно выше.
С поступательной скоростью у этого SLAM есть проблемы. Если совсем на пальцах, после каждого серьезного поворота (в районе 90 градусов) набор ключевых точек быстро обновляется и происходит переоценка «характерной глубины кадра». И дальше пока мы едем по прямой «выжатая» SLAM скорость «привязана» к этой характерной глубине. Поэтому если глубину оценили неточно, что часто бывает, скорость будет отличаться от реальной на какой-то множитель, далекий от единицы. И после каждого поворота множитель меняется, т.е. его нельзя просто один раз откалибровать и забыть. Поэтому для поступательной скорости надо уже будет подключать GPS и акселерометр (это в процессе запиливания, пока выкладывать нечего).
К картам можно привязываться, Garmin кстати так делает для своих фитнес-трекеров. Правда не знаю, насколько картографическая подложка в наших краях качественная. Но как доп очистка данных после поднятия всего главного функционала вполне вариант.ser-mk
06.04.2017 14:19Интересно. Тогда получается для большей точности SLAM имеет смысл постоянно ехать за каким-нибудь объектом(авто) что бы при повороте не уходил набор ключевых точек связанный с этим объектом?
Не очень понял причем тут Garmin с фитнес-трекером. Я имел ввиду что с помощью карт можно предсказывать в текущей ситуации направление дороги, там где с этим возникают трудности (горные дороги допустим )waiwnf
07.04.2017 11:34Такой фокус к сож. не пройдет — ключевое предположение в SLAM — что окружающий мир статичен, и траектория вычисляется относительно этого статичного мира. Если ехать вплотную за другой машиной, траектория будет считаться относительно этой машины, получится что мы просто стоим на месте.
Garmin делает похожую концептуально вещь (пользуются картами для улучшения точности GPS данных), только не направление дороги предсказывают, а высоту над уровнем моря: тут вкратце можно посмотреть в секции «What are elevation corrections?». Но напрямую это конечно к нашей задаче не переносится, да.
cepera_ang
06.04.2017 19:30Вроде сейчас приличной точности visual odometry добиваются, после круга по району в несколько км только по видео расчётное положение отличается от реального в пределах единиц метров (или даже меньше метра, не смотрел последнюю литературу), значит и скорость и всё остальное довольно точно определяют, несмотря на повороты.
waiwnf
06.04.2017 21:52Это да, но чёрт как обычно в деталях. Во-первых помогают именно круги — этот SLAM очень круто замыкает циклы, а знание циклов в свою очередь позволяет исправить большую часть систематического дрифта, который в open loop мы не сможем заметить. К сож. в реальной жизни мало кому интересно ездить кругами, а краудсорса хочется. Во-вторых много зависит от камеры, завтра постараюсь ссылку нарыть, сейчас с утюга совсем не ищется. Но вкратце для оптимального результата надо широкоугольный объектив (что как правило не про смартфоны) и global shutter, что тоже НЯП не всегда есть. Без них деградация довольно резкая. В очереди висит эксперимент нацепить на объектив фишай клипсу за 300р и сравнить качество, убрать часть шумов оптикой было бы здорово.
cepera_ang
07.04.2017 17:15Спасибо за уточнение. Интересно, камеры global shutter'ом — это же сейчас вообще редкость, нет?
waiwnf
07.04.2017 18:23Редкость, да. Варианты есть за не прямо космические деньги, но надо заморачиваться.
waiwnf
07.04.2017 10:52Так и не нашел ту ссылку с цифрами, зато копнул чуть глубже про разные сламы. В целом rolling shutter больше вредит тем, кто на более плотных фичах по кадру работает: lsd-slam, dso-slam. ORB_SLAM относительно более устойчив, хотя и не полностью. Тут есть интересная картинка тоже на Figure 20 про деградацию в зависимости от локальной дисторсии.
Тут автор для ORB_SLAM2 советует тоже ширик и глобальный затвор.
cepera_ang
07.04.2017 20:08Ещё вопрос — а без калиброванной камеры совсем никак? Вроде делают какую-то самокалибровку находу. Было бы интересно на записях с видеорегистраторов применить — там как раз самые важные для обучения (потому что редкие в нормальной эксплуатации) события происходят — аварии, «пронесло», прочие нештатные ситуации и т.п.
Было бы круто извлекать управляющий сигнал без предварительных настроек, пусть и точность была бы меньше.waiwnf
08.04.2017 16:27Интересно, статьи точно есть. Comma похоже что-то тоже уже умеет. В принципе если сегментировать дорожное полотно deconvnet-ом каким-нибудь, найти там разметку и предположить, что дорога плоская, а разметка прямая, то для вычисления дисторсии должно хватить инфы, но повозиться придется серьезно.
Было бы круто конечно сделать самокалибровку и уменьшить барьер гемора для краудсорса. Насчет вытаскивания данных из прямо левых видео с регистраторов я не так оптимистичен. Пока есть ощущение, что без GPS и акселерометра нужной точности по скорости не будет всё равно. Ну и вопрос, что именно в итоге хотим получить. С одной камерой, какой бы там ни был ширик, про самостоятельные перестроения можно сразу забыть, т.к. слепые зоны огромные. Значит надо целиться в относительно простой ADAS, выдерживающий полосу и оттормаживающийся перед препятствиями, а там надеюсь требования к разнообразию данных полегче будет и примеров типа «подрезали — притормозил» можно будет набрать относительно легко.cepera_ang
08.04.2017 16:45Мне кажется можно много извлечь из одной камеры, как насчёт чего-нибудь такого
forcesh
Интересная статья!
Не пробовали искусственно расширять датасет: накладывать шумы, размывать, зеркально отражать по горизонтали?
waiwnf
Спасибо! За расширение пока не брался, но определённо буду пробовать. Шумы, размытие — точно. С отзеркаливанием сложнее, всё-таки движение правостороннее, а отзеркаливание даст картинку «едем вдоль левой обочины» — не факт что от таких примеров будет больше пользы, чем вреда.