Как эволюционировало машинное зрение автономного транспорта. Доклад Яндекса

Всеволод Орлов, руководитель службы восприятия в Автономном транспорте Яндекса, выступил на конференции «Я Железо 2024». Он рассказал, благодаря чему автономный транспорт видит окружающий мир, как его органы зрения менялись и эволюционировали и какой софт позволяет роботам и машинам успешно ездить без человека в кабине.

Переложили выступление в текст для удобства читателей Хабра.

Чтобы построить визуальную картину окружающего мира, люди используют глаза: рассматривают объекты и осознают их состояние, а затем уже решают, как и куда двигаться. Но как видит и действует автономный транспорт?

Сегодня я расскажу про эволюцию машинного зрения автономного транспорта: какие датчики помогают нашим автомобилям воспринимать окружающий мир и что именно они видят.

ML в автономном транспорте 

Вернёмся к окружающим нас объектам: чтобы взаимодействовать с ними, для начала нужно их осознать. В терминах машинного обучения это называется «задача 3D‑детекции». Чтобы решить эту задачу, мы работаем с трёхмерными объектами, которые делим на две большие группы:

• Агенты — объекты, которые принимают активное участие в движении транспорта и могут учитывать наше поведение. Например, люди, машины или мотоциклы.

• Статические препятствия — объекты, которые участвуют в дорожном движении пассивно и не могут взаимодействовать с нами по своей воле. Тем не менее учитывать их всё равно нужно.

Скрытый текст

Система планирования движения строит для автономного автомобиля маршрут: из начальной точки в конечную. Чтобы работать с маршрутом, его удобно интерпретировать как некоторый граф.

Помните, как выглядит интерфейс навигатора для автомобилистов или пешеходов? Местность и проложенный через неё маршрут отображаются в проекции «Вид сверху». Для автономного транспорта это тоже подходит — планирование из трёхмерного слегка упрощается до двумерного.

Про само планирование подробно рассказано в одной из предыдущих статей — «Нейронные сети для планирования движения беспилотных автомобилей». А сейчас речь пойдёт о том, что именно помогает автомобилю понять, что же перед ним такое — самолёт, птица, агент или статика, — и принять решение, как двигаться дальше.

Первый этап эволюции: камеры и появление лидара 

Сегодняшний набор датчиков и ПО — третий этап эволюции «зрения» нашего автономного транспорта. А первый этап начинался с камер.

Камеры

Собственно, это самый простой способ реализовать техническое зрение для автономного автомобиля — поставить на него камеру и запустить, например, сегментацию.

Заметно, что таким образом хорошо распознаются дорожное полотно и статические препятствия: тротуары и бордюры. Но, как я и говорил ранее, для планирования требуется перевести все изображения в вид сверху.

Для получения проекции сверху необходимо трёхмерное представление поверхности, но у нас его не было. Самое простое, что можно было получить быстро, — это гомография. Гомография — геометрическое преобразование, которое репроецирует одну плоскость в другую. Для наших задач нужно репроецировать плоскость камеры в плоскость дороги.

В результате такого преобразования все объекты, которые на картинке относятся к дороге, сохраняют свои линейные размеры в её плоскости — присмотритесь к треугольнику безопасности на картинке выше.

Но плоскость дороги плохо интерпретировать только одной плоскостью: чем дальше объект от камеры, тем больше накапливается искажений. Поэтому гомография из коробки хороша для распознавания объектов, которые находятся в радиусе не дальше 40 метров от камеры. Такое поле зрения приемлемо для движения со скоростью около 20 км/ч. Этого достаточно, чтобы автономный автомобиль мог ездить по закрытой территории.

Глубина из стереопары

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

Ожидания: прекрасная карта глубины, похорошевшее репроецирование статических препятствий на вид сверху, 60 км/ч — без проблем. 

Реальность: ни один из доступных на тот момент алгоритмов не помог нам улучшить качество репроецирования. Обученные на комнатных данных модели не были готовы к настоящей погоде и живым камерам.

Чтобы переобучить модель глубины, мы решили добавить новый сенсор, который бы дал нам возможность собрать ground-truth-данные для глубины.

Лидар

Лидар хорош тем, что может определить расстояние до объекта с точностью до сантиметра. Мы надеялись, что если репроецируем данные с лидара на картинку с камер, то получим ground truth для глубины.

И снова реальность не сошлась с ожиданиями. Многие из наших CV‑ и ML‑инженеров считали, что за два года на одних только камерах можно было сделать полностью автономный автомобиль. В итоге значимо улучшить статические препятствия только на камерах у нас не вышло. А лидар позволил одному разработчику за две недели сделать детектор статики, соизмеримый по качеству с тем, над которым толпа специалистов работала 4 месяца.

Итак, подведём итоги первого этапа эволюции. С одной стороны, лидар — отличный источник ground‑truth‑данных для глубины по камерам. С другой — лидар сам по себе отличный источник данных о статических препятствиях. С его помощью можно закрыть эту задачу и перейти к другим.

Второй этап эволюции: 3D-детекторы и расположение сенсоров

Для начала поподробнее остановлюсь на датчиках, с помощью которых можно реализовать техническое зрение.

Наши автономные автомобили оборудованы множеством разных сенсоров. Например, камеры установлены так, чтобы поле зрения машины достигало 360 градусов, без слепых зон.

Так, в первом приближении, автономный автомобиль видит мир с помощью камер. А лидары позволяют ему более точно оценивать расстояние до объектов.

Вот пример сцены из нашей визуализации — узнаёте автомобиль, который едет навстречу нашему автономному транспорту, в облаке серых точек на картинках слева? Лидары настолько хороши, что даже без визуализации, по одному облаку, можно понять, что происходит.

3D-детекторы

Есть камеры, есть лидары, есть данные с них. Как это всё объединить? С помощью ML‑CV‑моделей, работающих с 3D.

Один из классических подходов к работе с лидарными облаками — архитектура PointNet. Однако она не справляется с real‑time‑сегментацией больших лидарных облаков.

Наш первый 3D-детектор мы назвали YaBoxnet.

Мы представляем лидарное облако в виде сверху, режем его на кубики, которые называем вокселями, и запускаем в каждом из них тот самый PointNet. Из каждого кубика вытягиваем некоторые фичи. А дальше, если смотреть на результат обработки лидарного облака сверху, его можно интерпретировать как картинку — только вместо каналов RGB мы используем воксели и те самые фичи, которые вытащили с помощью PointNet.

А дальше достаточно запустить YOLO, SSD или любой другой 2D‑детектор, и — вжух! — получится детектор, который умеет раскрашивать картинку и делать 2D‑кропы.

YaBoxnet не использует картинку с камеры, поэтому теряет большую часть информации. Параллельный путь, где эта картинка используется (и к которому мы также обращаемся), — фрустумные детекторы.

Как это работает: запускаем на картинке стандартный 2D‑детектор, получаем 2D‑прямоугольник, в котором есть объект. Берём сектор, на который опирается этот прямоугольник, запускаем в нём PointNet и вытягиваем 3D‑объекты.

К сожалению, у обоих подходов есть недостатки:

• YaBoxnet хорошо работает с видом сверху и оценивает углы объектов. При этом, поскольку у него нет информации о картинке, он может легко перепутать, например, пихту, у которой две веточки торчат вправо и влево, с человеком. Или не отличить квадратную автобусную остановку от автобуса той же формы.

• Фрустум лучше работает с объектами, у которых есть какой‑то кластер, например с человеком. Но он хуже оценивает углы и искажает детекцию машин.

LaserNet

Нам захотелось получить более универсальный детектор, который решал бы задачу 3D‑детектирования и при этом обладал плюсами обоих подходов. Мы вдохновились одним из существующих решений — LaserNet.

LaserNet работает примерно так: берёт картинку с камер и репроецирует её в лидар. Данные с камеры и лидара конкатенируются. В итоге получается 2D‑представление, на котором запускаются детекция и сегментация.

Мы придумали, как усовершенствовать эту схему. Давайте представим, что вокруг автомобиля есть бесконечная сфера, на которую можно репроецировать все камеры и лидары.

Смотрим на первую схему. Есть камера. И есть луч, проходящий через какой‑либо пиксель этой камеры (первый красный квадрат). Он попадает в пиксель бесконечной сферы (второй красный квадрат). Таким образом мы смогли данные со всех камер перенести на бесконечную сферу.

Аналогично и с лидаром: каждая точка, которую он возвращает, — тоже некоторый луч, который можно спроецировать на бесконечную сферу (синий квадрат).

А дальше — стандартная схема: камерный энкодер/декодер, в середину которого мы добавляем данные от лидара, чтобы обогатить 2D‑детекции. При этом, если в лидарных данных останутся X, Y и Z, то их вместе с фичами на выходе декодера можно репроецировать на вид сверху и получить энкодер/декодер, аналогичный Boxnet, но уже с камерными фичами.

И снова наши ожидания разбились о реальность.

К сожалению, сфера бесконечного радиуса — утопия, если сенсоры расположены неправильно.

Места, где панорама склеилась хорошо, отмечены на картинке выше зелёными стрелочками. В остальных областях всё просто ужасно: обратите внимание на синие стрелочки. Справа не сошёлся тротуар, слева — пешеходный переход. Такие артефакты возникают, когда камеры расположены слишком далеко друг от друга: для репроекции в одну панораму нужно, чтобы фокусные точки всех камер были близки.

Так как мы сами разрабатывали наш набор сенсоров, то у нас была возможность расположить камеры ближе к лидару, чтобы минимизировать ошибки репроекции.

Так мы перешли к третьему этапу эволюции. Но прежде подведём итоги второго.

Fuse данных связанных модальностей — непростая задача. Её можно решить машинным обучением, сложными моделями, но зачем? Если разрабатывать sensor set самостоятельно, можно расположить сенсоры так, чтобы упростить архитектуру ML‑модели, а значит, помочь ей лучше сходиться и обучаться.

Третий этап эволюции: GorynychNet

У архитектуры, которую мы обсуждали выше, есть существенные недостатки:

• Все камеры должны располагаться рядом с лидаром.

• В зонах перекрытия камер есть сигнал только от одной камеры.

• В слепой зоне лидара данные с камер бесполезны.

Следующий шаг эволюции — GorynychNet.

GorynychNet

Мы отказались от одной панорамы в пользу нескольких: для каждого лидара генерируем собственную бесконечную сферу и репроецируем на неё данные с самой близкой к этому лидару камеры. Этого оказалось достаточно: нам удалось улучшить распознавание в ближней зоне автомобиля. Например, теперь мы прекрасно видим людей, которые в него садятся.

Возврат к истокам

Лидары — это, конечно, прекрасно. Но нам не давал покоя вопрос: можно ли всё же обойтись одними камерами?

Попытка номер раз: мы запустили на всех камерах моноглубину, которая позволила нам уплотнить данные до 30 метров и даже решать с их помощью какие‑то задачи. Но тут у нас в руках очутился лидар получше, который решил те же задачи сильно проще.

Прошёл год или полтора. Мы придумали, как уплотнить лидар с помощью камеры для зоны до 60 метров. Снова решили какие‑то задачи. И опять появился новый лидар, который решал эти задачи лучше.

Казалось бы, не летит. Но, как сказал руководитель разработки лидаров, больше такого не произойдёт: скорость света увеличить пока что не получается. Поэтому с зоной от 120 метров сейчас можно работать только с камерами. Но это не единственный случай, когда без этого подхода не обойтись.

Ещё важный момент — гарантии безопасности. Представим, что какая‑то из систем автономного автомобиля вышла из строя. Для таких случаев должно быть предусмотрено резервирование, которое позволит безопасно припарковать автомобиль.

Чтобы обеспечить безопасность, сенсоры должны быть избыточными. Сами архитектуры, которые мы обсудили выше, хорошо работают в двух случаях:

• есть данные и с лидара, и с камер;

• есть данные хотя бы с лидара (например, ночью с камер много данных не получишь).

Но всё сломается, если лидар выйдет из строя. А значит, чтобы обеспечить безопасность, придётся обращаться исключительно к камерам.

Подведу итоги:

• Изначально у нас не вышло сделать всё только на камерах.

• Лидар оказался отличным сенсором, который ускорил наше развитие.

• Правильно расположение сенсоров также помогло улучшить техническое зрение.

Но, к сожалению, чтобы сделать по‑настоящему безопасный продукт, нам всё равно пришлось вернуться к подходу с использованием одних лишь камер.