Беспилотный автомобиль: оживляем алгоритмы. Доклад Яндекса
Подробная расшифровка еще одного доклада со встречи Яндекс.Железо — про разработку устройств для беспилотника.
— Всем привет, меня зовут Виталий Подколзин, я руководитель разработки встраиваемых систем проекта беспилотного автомобиля. И сегодня я хотел бы с вами поговорить о том, что такое беспилотный автомобиль, какие компоненты входят в его состав, как заставить машину двигаться и как работа автопилота и его компонентов зависят от применяемых устройств.
Чтобы понять, куда дальше ехать, человеку сначала надо выяснить, где он находится. Беспилотному автомобилю — тоже. За это у нас отвечает подсистема локализации. Потом нужно понять, что творится вокруг нас. За наше зрение, за восприятие мира отвечает система восприятия или perception. На основе данных о местоположении, об объектах вокруг нас, мы можем строить прогнозы по дорожной обстановке, по ее развитию, по поведению участников дорожного движения. И выбирать оптимальный маршрут движения, траектории, далее превращая это в управляющее воздействие.
Но все перечисленное — это, в общем случае, алгоритмы. И вы могли бы запустить эти алгоритмы на своем компьютере, будь он достаточно мощным. Конечно, это не сделало бы из компьютера беспилотный автомобиль. Не хватает двух важных вещей.
Первая — достаточно богатый набор сенсоров, основные из которых перечислены на слайде. И конечно, нам нужна платформа, которая будет исполнять наши команды. С ней нужно взаимодействовать.
Давайте подробнее остановимся на вопросе взаимодействия с автомобилем. Автопилоту, как и человеку, для управления автомобилем нужно делать простые вещи: крутить рулем, ускорять, тормозить. Логичным решением может показаться использование актуаторов для управления этими органами.
Ссылка со слайда
Но такой подход имеет ряд существенных трудностей. Развитие беспилотного автомобиля все равно предполагает наличие водителя на тех или иных этапах — нужно отвозить машину на сервис или следить за автопилотом, когда мы тестируем разные особенности, особенно на ранних стадиях. Данные устройства существенно усложняют жизнь водителю.
Конечно, вся система сложная, и в целом такая механика может вносить неприятные задержки в органы управления. Это отрицательно сказывается на контуре управления автомобилем.
Да, нам еще на старте проекта требовалась простая платформа, но нужен был какой-то другой подход для взаимодействия с этой платформой. И мы начали копать вглубь автомобиля.
Изучив особенности разных платформ, мы обнаружили, что многие современные автомобили имеют возможности контроля собственных органов автомобиля. К примеру, ассистент управляет рулем во время парковки. Круиз-контроль воздействует на ускорение автомобиля, адаптивный круиз-контроль или система ограничения скорости могут воздействовать на систему торможения.
Все эти системы, как правило, в автомобилях закрыты. И чтобы взаимодействовать с ними, потребовалась разработка ряда специализированных устройств. Кроме взаимодействия с автомобилем, от системы требовалось предоставление удобного, понятного для автопилота интерфейса управления автомобилем. И конечно, система должна была быть простой, понятной и очень гибкой.
Мы пришли к такой платформе, где в зависимости от автомобиля разрабатываются небольшие платы контроля, которые взаимодействуют с конкретным узлом. Состав и функциональность этих плат отличаются от платформы к платформе, но все они объединяются в одну сеть, где есть головное устройство, которое мы у себя условно назвали gateway. Оно осуществляет контроль за этими устройствами. Кроме того, gateway предоставляет интерфейс для автопилота по удобным устройствам. Тут мы видим Ethernet, удобный для нашей инфраструктуры, и CAN, самый популярный автомобильный интерфейс. Помимо этого, наше головное устройство постоянно взаимодействует с автомобилем, производит мониторинг состояния узлов и агрегатов. Если обнаруживаются какие-то отклонения, то в зависимости от их природы совместно с автопилотом принимается решение о дальнейших шагах.
Реализовывать плату мы решили на достаточно популярных и зарекомендовавших себя микроконтроллерах. Мы взяли их с запасом по производительности и выбирали такие, которые поддерживают необходимые для работы интерфейсы: CAN, Ethernet и аналоговые цифровые входы-выходы.
Мы получили решение, которое для нас действительно оказалось гибким и позволило с меньшими проблемами переходить от платформы к платформе.
Поговорим о сенсорах. Каждый беспилотный автомобиль имеет богатый набор сенсоров. У каждого беспилотного автомобиля Яндекса четыре лидара на крыше и три во фронтальной части, шесть камер, которые ставятся на крышу, а также шесть радаров: два в задней части и четыре во фронтальной, два из которых расположены по бокам.
Берем радары, лидары, камеры, соединяем, загоняем в вычислитель. Но не все так просто. Очень важно добиться того, чтобы данные с сенсоров были адекватные и качественные. Мы провели большое количество экспериментов, чтобы понять, где располагать сенсоры, чтобы мы могли видеть мир лучше и четче.
Кроме того, нашим конструкторам пришлось хорошо поработать, чтобы все изменения в автомобиле, связанные с сенсорами, удовлетворяли требованиям сертифицирующих органов.
Вот что получилось. Шесть камер на крыше дают хороший обзор на 360 градусов с существенным перекрытием — темные зоны отмечены на слайде. Эти камеры также дают хороший вертикальный обзор. Камера — единственный сенсор, который видит светофоры, потому что они могут располагаться разных частях, в зависимости от перекрестка и прочего.
Радары — еще один важный сенсор каждого автомобиля. Они интересны тем, что имеют не очень широкий угол обзора, но хорошую дальность. Два фронтальных радара выполняют функцию мониторинга того, что творится впереди, задние радары в наших алгоритмах используются, как правило, при перестроении, обгоне и подобных маневрах. Радары, которые смотрят вбок, необходимы для проезда достаточно сложных перекрестков, где информации со стороны сенсоров может быть недостаточно.
Наверное, наиболее интересным сенсором является лидар. Он интересен информацией, которая с него приходит. Перед вами облако точек, point cloud, это данные с лидаров. На них видно пешеходов, автомобили, дорогу, даже края проезжей части и другие объекты. Коробочки — это уже результат работы наших алгоритмов распознавания.
В сумме все сенсоры дают примерно такую картину. Как видите, невозможно не заметить что-либо вокруг автомобиля с таким набором сенсоров.
Я хотел бы остановиться на двух примерах, с которыми мы столкнулись, когда нам потребовалась разработка аппаратной части. Начну с кейса локализации.
Основным источником являются карты высокой четкости. В каждый момент времени беспилотный автомобиль сравнивает данные с лидаров с этими картами. На основе такого сравнения он получает свое местоположение с сантиметровой точностью. GPS, Глонасс или любая другая спутниковая навигация просто не подходит для работы с беспилотным автомобилем ввиду низкой стабильности работы, высокой зависимости от внешних условий, от погоды, шумов, помех. В городе все это существенно осложняется перекрытиями сигнала, переотражениями от зданий и т. д. Но откуда нам взять эти карты? Карты строим мы сами, используя наши беспилотные автомобили с набором сенсоров.
Для построения этих карт нам нужны лидары и какая-то привязка на местности. Нужно как-то получить свою координату. GPS изначально мог бы дать координату, но его точность не очень высокая. Как я уже говорил, на точность GPS влияют атмосферные условия, помехи, а в городе еще и переотражения.
Тут на помощь приходит технология Realtime kinematic. Суть в следующем: где-то на местности ставится неподвижная базовая станция с таким же приемным устройством, как и на автомобиле. Если расстояние между автомобилем и базовой станцией не превышает 30 км (в некоторых случаях 50 км), то данные со спутников, получаемые автомобилем и базовой станцией, будут примерно похожи. Но базовая станция, зная свою точную координату (она неподвижна) и рассчитывая координату по данным со спутника, получает, условно, ошибку вычисления. На основе этой ошибки вырабатываются поправки, которые через интернет отправляются на автомобиль. Автомобиль, учитывая полученные поправки при расчете координаты по спутникам, получает свою координату с сантиметровой точностью. Конечно, для работы с этой системой нужен хороший канал интернета и хорошая погода, чтобы сигнал GPS был стабильным.
Чтобы получить работающее устройство с поддержкой RTK на автомобиле или базовой станции, нужен софт. Библиотеки, предоставляющие возможности RTK RTKLib, находятся в открытом доступе. Есть разные вариации с разными особенностями. Библиотеки, как правило, требуют окружение Linux и модули спутниковой навигации, которые выдают сырые данные.
Проведя пару экспериментов, запрототипировав пару вещей, мы получили структурную схему блока локализации, которую мы назвали GeoHub.
Кроме указанного модуля спутниковой навигации, там еще стоит модуль инерционных измерений, который мы используем в системе локализации. Интернет сейчас приходит по удобному для нашей инфраструктуры интерфейсу Ethernet.
Перед вами второе устройство, его второе поколение и основные технические характеристики.
Мы сделали заменяемым модуль инерциальных измерений и модуль спутниковых сигналов. Это в итоге позволило поставить ряд экспериментов на автомобиле и выбрать оптимальный с точки зрения различных параметров модуль инерциальных измерений, а что касается модуля спутниковых сигналов, мы в процессе смогли перейти на двухдиапазонный приемник, что существенно улучшило качество определения местоположения.
А зачем разрабатывать свое устройство, когда наверняка можно пойти на рынок и купить что-то похожее? Ответ в том, что для нас одним из самых важных параметров является гибкость устройства. В связи с быстро меняющимися требованиями в проекте, появляющимся новым функционалом, нам нужно иметь возможность очень быстро реагировать на это. Только имея внутри проекта, in-house, разработку железа и софта, мы получаем действительно высокую скорость отработки этих изменений.
Другим интересным сенсором с точки зрения беспилотного автомобиля является камера. Окей, камера есть в каждом телефоне b ноутбуке. Что тут может быть сложного? Но давайте посмотрим, с какими проблемами можно столкнуться, используя камеру в беспилотнике.
Первая проблема — мерцание источников светодиодного света. Большинство светофоров — это как раз такие источники. Видео остановилось на моменте, когда из-за мерцания красный сигнал практически пропал.
Для этой проблемы есть аппаратные решения, заложенные в сенсор, но чтобы с ними хорошо и качественно работать, нужно уметь активно взаимодействовать с сенсором.
Вторым требованием для камер является высокий динамический диапазон, то есть возможность работы в условиях любой освещенности, как ночью, так и при ярком солнце. Также важно наличие HDR, то есть возможности совмещения кадров с разной освещенностью в один для получения более качественной картинки.
Слева пример картинки, где где функция HDR используется, а справа — где она отключена.
Кроме этого, мы, конечно, должны получить картинку с достаточным разрешением и достаточной частотой кадров. На слайде выделены еще пара моментов, присущие в том числе беспилотным автомобилям. Камера должна выдавать несжатый видеопоток, желательно формата RGB888, потому что наши сети, алгоритмы работают с этим форматом, хотят получать кадры в этом формате.
Большинство камер, готовых решений на рынке, выдают данные в сжатом виде — H264, MPEG. Проблемы тут простые: мы теряем качество при сжатии и вносим задержку на сжатие и разжатие. Задержка может быть недетерминированной, особенно при высокой нагрузке системы. Камера с разрешением Full HD и частотой 30 кадров в секунду при битности 16 бит на пиксель выдает поток около гигабита в секунду чистых видеоданных.
Кроме этого, камеры, как правило, расположены на удалении от приемного устройства, а в машине, особенно при каких-то экспериментах, они могут располагаться вообще на другом конце автомобиля. Нам нужны были камеры, которые позволяют весь несжатый видеопоток передать на расстояние 6–8 метров с учетом прокладки кабелей. Для Full HD-камеры c 16 битами на пиксель видеопоток составляет 1 гигабит, что уже не дает использовать гигабитный Ethernet, так как в передаче участвуют различные служебные данные и прочее. Десятигигабитный Ethernet использовать не совсем целесообразно. Это дорого, высокое энергопотребление, высокий теплоотвод, повышенная сложность сетевой инфраструктуры.
Да, есть другие интересные интерфейсы. Я хотел бы рассказать о двух из них, с которыми мы поработали. Их предоставляют компании Maxim Integrated и Texas Instruments. Особенность в том, что видеопоток сериализуется в данные, которые идут по простому физическому уровню, в данном случае через коаксиальный кабель, на скорости 3–4, иногда 6 гигабит в секунду. Кроме того, данный интерфейс позволяет использовать обратный канал для управления камерой по этому же коаксиальному кабелю. И по нему же может идти питание камеры. Все перечисленное делает этот интерфейс очень привлекательным.
Когда мы начинали, то нашли решение на рынке, которое в принципе удовлетворяло большинству требований. Его мы какое-то время использовали на старте проекта.
Структурная схема решения перед вами. Это сенсор, данные из которого сериализуются в интерфейс GMSL/FPD-Link. На приемной части, которая может быть удалена на 15 метров, данные десериализуются и передаются в ресивер. В нашем решении этот ресивер далее выдавал данные по интерфейсу USB 3.0.
Но начав использовать это решение, мы столкнулись с рядом неприятных проблем. Главная проблема — решение работало крайне нестабильно, «отваливалось» в процессе работы, камеры плохо запускались при старте автопилота. Вдобавок решение не позволяло подстраивать параметры самих сенсоров с целью улучшения качества картинки. Был и еще ряд проблем. Например, было сложно получить точный timestamp камеры, время съемки, что достаточно важно, ведь на скорости 15 м/с при задержке в 100 мс машина уже проезжает полтора метра, и это может очень негативно сказаться на алгоритмах восприятия.
Был еще один интересный момент. Выходным интерфейсом выбранного решения был USB 3.0, и мы обнаружили, что он крайне шумный. Как мы это поняли? У нас стояло два не подключенных ни к чему автомобиля. На одном запустили камеру, на обоих очень сильно просел сигнал спутниковой навигации. Тогда мы начали изучать, что же происходит.
Проанализировав все эти недостатки в целом, изучив структурную схему перед вами и прочее, мы пришли к выводу, что проблема в приемной части. Дальше начали думать, что с этим делать. Посмотрели, что есть на рынке, решения других команд, и пришли к выводу, что нам нужно делать собственное приемное устройство, которое будет работать с камерой по интерфейсу GMSL или FPD-Link.
Мы взяли десериализаторы, которые, как правило, имеют на выходе интерфейс MIPI CSI2, и начали поиск модуля или процессора, который смог бы поддержать данный интерфейс. И мы нашли интересное решение с шестью интерфейсами MIPI CSI2, а также с высокой производительностью и богатой периферией. Это позволило нам в итоге использовать удобный для нашей сетевой инфраструктуры интерфейс Ethernet 10 гигабит в качестве выходного интерфейса этого устройства. Получив данные по GMSL/FPD-Link с 6 камер (или, в некоторых случаях, с 12 камер), обработав их, устройство по 10-гигабитному Ethernet передает уже обработанный видеопоток дальше — на вычислитель.
Перед вами само решение и его основные характеристики. Разработав такую штуку, мы научились не только надежно работать с 6 или 12 камерами, но также получили возможность тонкой настройки камер. Это позволило улучшить качество картинки, что положительно сказалось на работе алгоритмов восприятия. Мы также получили четкое понимание о времени съемки кадра, научились управлять этим временем. И высокопроизводительные ЦПУ, вычислительные мощности модуля позволили нам производить первичную обработку видео с минимальными задержками прямо на модуле.
Аппаратный кодек этого модуля позволил еще и сжимать видеоданные для последующего сохранения в логах.
Нам пришлось поработать не только с сенсорами локализации и с камерами. Аппаратные решения пришлось разрабатывать практически для всех сенсоров, что мы применяем. Все это было сделано для решения повышения надежности и качества данных, от которых зависят алгоритмы детекции, восприятия. А от них зависит то, насколько оптимальным будет решение, выдаваемое автопилотом.
Окей, мы научились управлять автомобилем, поработали над сенсорами, расположили их хорошо, научили их выдавать нам качественную картинку. Какую еще работу делают инженеры встраиваемых систем, «железячники» на нашем проекте? Мы следим не только за развитием сенсоров, ставших уже обыденными, но и за альтернативными источниками получения информации. Постоянно исследуем альтернативные ускорители нейросетей, других алгоритмов, в том числе с применением ПЛИС. И сложно представить развитие проекта без взаимодействия с опытным автопроизводителем.
Новая платформа — это всегда вызов для разработчиков встраиваемых систем, конструкторов, разработчиков ПО высокого уровня.
Сфера беспилотных автомобилей сейчас находится на очень активном этапе развития. Мне как инженеру очень приятно наблюдать за этим, но гораздо более приятно участвовать. И не за горами то время, когда для нас станет совсем обычным садиться в автомобиль и, направляясь к нужному нам месту, заниматься своими делами в комфорте и безопасности. На этом все, спасибо за внимание.
