company_banner

Беспилотный автомобиль: оживляем алгоритмы. Доклад Яндекса

    Подробная расшифровка еще одного доклада со встречи Яндекс.Железо — про разработку устройств для беспилотника.



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

    Чтобы понять, куда дальше ехать, человеку сначала надо выяснить, где он находится. Беспилотному автомобилю — тоже. За это у нас отвечает подсистема локализации. Потом нужно понять, что творится вокруг нас. За наше зрение, за восприятие мира отвечает система восприятия или 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, разработку железа и софта, мы получаем действительно высокую скорость отработки этих изменений.

    Другим интересным сенсором с точки зрения беспилотного автомобиля является камера. Окей, камера есть в каждом телефоне и ноутбуке. Что тут может быть сложного? Но давайте посмотрим, с какими проблемами можно столкнуться, используя камеру в беспилотнике.



    Первая проблема — мерцание источников светодиодного света. Большинство светофоров — это как раз такие источники. Видео остановилось на моменте, когда из-за мерцания красный сигнал практически пропал.

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

    Вторым требованием для камер является высокий динамический диапазон, то есть возможность работы в условиях любой освещенности, как ночью, так и при ярком солнце. Также важно наличие 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 камерами, но также получили возможность тонкой настройки камер. Это позволило улучшить качество картинки, что положительно сказалось на работе алгоритмов восприятия. Мы также получили четкое понимание о времени съемки кадра, научились управлять этим временем. И высокопроизводительные ЦПУ, вычислительные мощности модуля позволили нам производить первичную обработку видео с минимальными задержками прямо на модуле.

    Аппаратный кодек этого модуля позволил еще и сжимать видеоданные для последующего сохранения в логах.

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

    Окей, мы научились управлять автомобилем, поработали над сенсорами, расположили их хорошо, научили их выдавать нам качественную картинку. Какую еще работу делают инженеры встраиваемых систем, «железячники» на нашем проекте? Мы следим не только за развитием сенсоров, ставших уже обыденными, но и за альтернативными источниками получения информации. Постоянно исследуем альтернативные ускорители нейросетей, других алгоритмов, в том числе с применением ПЛИС. И сложно представить развитие проекта без взаимодействия с опытным автопроизводителем.


    Новая платформа — это всегда вызов для разработчиков встраиваемых систем, конструкторов, разработчиков ПО высокого уровня.

    Сфера беспилотных автомобилей сейчас находится на очень активном этапе развития. Мне как инженеру очень приятно наблюдать за этим, но гораздо более приятно участвовать. И не за горами то время, когда для нас станет совсем обычным садиться в автомобиль и, направляясь к нужному нам месту, заниматься своими делами в комфорте и безопасности. На этом все, спасибо за внимание.
    Яндекс
    533,88
    Как мы делаем Яндекс
    Поделиться публикацией

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

      0
      Каждый беспилотный автомобиль имеет богатый набор сенсоров. У каждого беспилотного автомобиля Яндекса четыре лидара на крыше и три во фронтальной части, шесть камер, которые ставятся на крышу, а также шесть радаров: два в задней части и четыре во фронтальной, два из которых расположены по бокам.

      Как между собой синхронизируются все эти устройства(не только камеры)?
        0

        Скорее всего не синхронизируются — все "говорят в общую сеть одновременно".

          0
          Как тогда вычислитель соотносит информацию с разных сенсоров, если он не в какой момент времени они сняты? Как делать круговой обзор?
            0

            эээ, что сейчас в сети — то и актуальное :)

          0
          Камеры обычно делают с внешним триггером.
          Лидары имеют вход для информации с автомобильной GPS-станции, которая генерит импульсы PPS. Как правило лидары выдают точки в пакете, в заголовке которого лежит точное время сканирования.
          Что с радарами, не могу сказать, ибо специфично и непопулярно, но, вероятно, там тоже есть вход наподобие того, что есть у лидара.
          Может разве что возникнуть проблема, как распределить PPS импульсы по всем сенсорам. Ее можно решить покупкой специального девайса, который, размножает сигнал времени, а можно этот девайс и самим собрать на какой-нибудь CPLD.
            0
            Это Вы теоретический рассуждаете или наверняка знаете как у них устроено?
              0

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

            0

            Вобщем то никак не синхронизированы, информация с датчиков выкидывается в общую CAN шину без таймстемпов, кому надо тот эту информацию обрабатывает и таймстемпирует по моменту получения

              0
              Какую информацию? Какая пропускная способность шины CAN?
                0
                да какую угодно… сейчас в кане/флексрее вы найдете всё — от поворотников до ивентов радаров и обьектов с мобилаевских камер. пропускную способность загуглите :)
                  0
                  Это не то, что меня интересовало.
            +2
            Если у вас столько лидаров, я так понимаю вы не согласны с позицией теслы про них?
            Если дорога будет полна машин с лидарами, они друг другу помехи не будут создавать?
              0
              Справедливости ради, радары тоже будут друг друга засвечивать.
              Камеры хороши тем, что они пассивны и не смогут друг другу помешать, но, к сожалению, ночью от них толка маловато (да и видят они не очень далеко (а еще точность позиционирования по камере невелика)).
              Так что скоро возникнет большая проблема, когда на дорогах появится больше одного беспилотника, как не засветить соседу и самому оказаться незасвеченным.
                0
                Ну с радаром оно давно используется и наработались решения. Летает же ежесекундно тьма самолётов с метеорадарами, плюс облучается наземными радарами.
                  +1

                  Всё-таки у ADAS радаров есть своя специфика.
                  Во-первых, самолётов в небе явно меньше, чем машин на дороге.
                  Во-вторых, метеорадары могут работать в разных диапазонах с наземными.
                  В-третьих, для самолётного метеорадара не так критична даже минутная внешняя помеха, как для автомобильного полусекундная.
                  В-четвёртых, много докладчиков с "микроволновой недели", что была в Париже на прошлой неделе, с вами не согласятся.

                  0

                  Ну радар то всё таки один у Теслы и светит прямо, что значительно снижает помехи по сравнению с круговыми лидарами

                0
                для коптера с таким набором датчиков провода незаметны, сможет автомобильный автопилот заметить растяжку?
                  0
                  Интересно как обстоят у вас дела с safety? Без этого будет сложно выйти на международный рынок.
                    0

                    Вам какой из многих safety интересен? ;)

                      0
                      Раз тут про селфдрайвинг, то очевидно, что интересует safety из automotive, тобишь ISO 26262.
                        0

                        Просто очень многие и не знают об этом "классическом" ISO :)


                        Кстати, ЕМНИП, под робомобили уже есть своё отдельное safety-ISO

                      0

                      Да какой выход на рынок, они хакают машину чужого производителя(там даже написано что они встраивают свои девайсы и гейтвэй) с таким подходом им выход на внешний рынок закрыт навсегда. Единственный вариант договорится с Вазом.

                        0
                        Они в этом году уже договорились с Hyundai чтобы поставлять им решение для селфдрайвинга.
                          0

                          Вот с решением я не уверен, скорее всего они договорились сделать POC проект. И какого уровня автономности это будет стстема пока не понятно.

                            0

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

                      0
                      А кто контролирует автопилот? Есть ли дублирование главных управляющих систем? что произойдет если он зависнет? Не захочетли он встать прямо по среди полосы в плотном потоке, предупредитли водителя, как обрабатываются такие исключительныеситуации?
                        0
                        Я так понимаю это типичная задача для софта в множестве отраслей. Авиация, хирургия, космос.
                          0

                          В международных ISO-стандартах многое в общем прописано — при сертификации производитель обязан будет предоставить контролирующим органам (соответствующего государственного или надгосударственного образования) подтверждения соответствия стандартам и непосредственно сами приборы для тестирования.


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


                          Моё описание просьба воспринимать как попытку объяснить квантовую физику на пальцах в двух предложениях. ;)

                            0

                            Этого как раз в статье и не написано, не хватает описания модуля принятия решений. Складывается впечатление что пока задачей у них стояло оснастить машину датчиками и научится как-то двигаться. А самое интересное оставили на потом

                            0
                            А как обстоят дела с сертификацией (например, соответствие с ISO 26262) критически важных компонентов (аппаратных и программных), влияющих на безопасность?
                            И как планируется подтверждать соответствие конечного продукта (автономной платформы или всего автомобиля) стандартам безопасности (здесь очень интересно узнать, как эти процессы устроены в РФ)?
                              0
                              Я так понимаю, что в снег и дождь авто работать не будет, раз основной сенсор у вас лидар?
                              Как планируете с этим бороться?
                              В каком режиме используются радары? С них получаете облако точек или просто обнаружения?
                              Камеры используются только для оценки дорожной ситуации на «нейросетевом уровне» или с них тоже строите облака точек?
                                0

                                В автомобиле используются различные типы сенсоров (камеры, лидары и т.д.). По сути они дополняют друг друга для создания единой информации об окружающей обстановке. Как организована приоритетность этих датчиков и есть ли она? И как обрабатывается ситуация, когда, например, один датчик видит препятствие, а другие — нет.
                                И еще, проводите ли вы консультации с профессионалами в медицинской отрасли при проектировании системы? Например очень полезно понимать как устроен сам глаз и как он работает, мозг и его работа. По сути ведь система и ИИ копируются с живого организма?

                                  0

                                  Я конечно понимаю, что многое осталось за кадром, но где же описание CPU или главного компьютера? И он у вас что, общается со всеми устройствами через Ethernet?

                                    0
                                    Скорее всего такой же модуль, как у конкурентов — выбора на рынке на самом деле не так много…
                                      0

                                      Да вроде по картинке видно что это NVidia TX2...

                                      +3
                                      Какое увлекательное обсуждение с сотрудниками яндекса сложилось.
                                      0
                                      не понятно, как с такой сложной задачей справляется всего пару глаз.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое