Ранжирование траекторий для системы автономного вождения

НачалоВводныеАрхитектура планераСценарий для генератораДатасетРанжирующая модельМетрики проектаИтог

В Яндекс Беспилотные Технологии сделали шаг к следующему поколению систем планирования движения для автономного вождения.

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

Прежде чем рассказать, как мы создаём систему планирования движения, объясню, какие компоненты поставляют для неё данные:

  • Карта. Показывает точную разметку полос на дороге, знаки дорожного движения, светофоры и их расположение на полосах. Её рисуют картографы.
  • Локализация. Даёт координаты с точностью до сантиметра.
  • Персепшен. Играет роль глаз: получает «сырые» данные с сенсоров, лидаров, радаров и камер. Затем возвращает положение всех участников дорожного движения вокруг — агентов. Персепшен сообщает нам об их точном положении, размерах, скорости, ускорении и других свойствах.
  • Предикшен. Умеет предсказывать будущее участников дорожного движения на 8–10 секунд вперёд. Он возвращает данные о том, с какой вероятностью агент окажется в том или ином месте в следующий момент.

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

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

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

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

1. Качественный ML-персепшен и универсальная логика — ни в кого не врезаться и соблюдать ПДД. После реализации это не сработало. Всё потому, что планеру нужно не только видеть агентов вокруг, но и предсказывать их местоположение, а наивные классические алгоритмические предсказания плохо работают на достаточно длинном горизонте, например от двух секунд и больше. В итоге хорошо и безопасно водить не получается.

2. Персепшен, ML-предикшен и универсальная логика — не врезаться и соблюдать ПДД. У такой системы тоже есть трудности. Оказалось, что будущее многообразно: в одном и том же сценарии у водителя есть несколько вариантов действий. Он может повернуть направо, поехать прямо, разогнаться или притормозить — от всех этих вариантов не отыграть. Ещё в некоторых случаях варианты зависят от наших действий, а они зависят не только от агентов, но и от сложного контекста. Например, в плотном потоке водитель может создать помеху другим, чтобы встроиться, но в разрежённом всех с запасом пропустит.

3. ML-планер. End-to-end учится водить ML-моделью на основании логов других водителей. Это направление у нас развивается параллельно, но задача там сложная, в продакшене пока использовать не получается.

4. Генерация траекторий и ранжирование. Пока развивается ML-планер, мы решили сделать промежуточный шаг. В этом варианте планер генерирует несколько разных траекторий, а лучшую выбирает ранжирующая модель. Она учится автоматически на размеченных данных и заменяет часть логик, которые вручную создавали разработчики.

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

Остановились на сценарии нерегулируемых перекрёстков, на которые мы выезжаем со второстепенной дороги.

Мы сделали простую логику генератора:

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

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

Мы перебрали несколько разных подходов к ground truth для ранжирования, но в конечном счёте остановились на асессорской разметке. Первый её плюс — это понятный контроль качества. Например, можно показать обучающий момент не одному асессору, а трём разным. Затем посмотреть, согласованно ли они отвечают или нет, и анализировать причины несогласованности. Может, пример сложный, а может, асессоры неоднозначно понимают инструкцию. Второй плюс подхода заключается в том, что человек даёт обучающий сигнал для модели. Это соответствует одной из наших целей — научить автономный автомобиль ездить не хуже человека.

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

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

Когда проект передавали фронтендерам, выбрали две группы людей для разметки:

  • Асессоры. Их ответы являются основой подхода, но мы решили не полагаться на них полностью. Асессоры могут обманывать метрики и не вникать в показанную ситуацию, потому что они получают оплату за количество размеченных траекторий. Также им может быть сложно разобрать визуализацию для разработчиков и тестировщиков. Помимо этого, неизвестен уровень вождения асессоров.
  • Водители-тестировщики. Мы решили учитывать их ответы, потому что они уже давно работают в проекте и заинтересованы в его улучшении, поэтому не стали бы обманывать. У них есть опыт работы с визуализацией — им можно сразу показывать сложные кейсы. Наконец, мы уверены в их знаниях, потому что они проходят отбор по уровню вождения и дополнительно обучаются.

Так у нас появились первые данные и визуализации. Мы отгрузили их в разметку и измерили согласованность в ответах — это процент случаев, когда люди отвечали одинаково. Оказалось, что асессоры соглашались друг с другом в 60% случаев, водители — в 70%. При этом у нас не было пока никакого обучения, экзаменов и контроля качества.

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

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

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

Так мы за несколько месяцев пришли к согласованности асессоров в 80% случаев, водителей — в 90%. При этом смогли измерить точность: на простых контрольных заданиях асессоры выдавали точность 95%, на потоковой выборке — 84%. С такими цифрами мы начали обучение ранжирующей модели.

При создании ранжирующей модели мы понимали, что траектории не существуют в вакууме — всегда есть контекст. У нас его считывает технология Kraken. Это тушка-трансформер, которая принимает выход персепшена, карту, маршрут, предыстории агентов. Она умеет выдавать эмбеддинги агентов и сцены, а также числовые интенты. Например, вероятность того, что агент не пустит или пустит нас. Вместе с Kraken мы использовали ручные фичи агентов и траектории, потому что пока не умеем эмбедить такое.

Разместили всё перечисленное в программную библиотеку CatBoost. В итоге собрали базу данных из 30 000 пар траекторий, у нас появилась тестовая выборка и качество на ней.

Чтобы объяснить, как мы тестируемся до выхода в реальность, расскажу, как работает наша симуляция.

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

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

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

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

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

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

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

Таким образом, мы движемся к будущему нашей компоненты: планированию движения через генерацию траекторий и ранжирование, а затем — через ML-планер.

Поделитесь увиденным

Скопировать ссылку
ТелеграмВКонтакте