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

Cимуляция — это не просто бесконечные поездки в виртуальной среде

На странице с описанием технологий Waymo говорится:

«Мы проехали более 20 миллиардов миль в симуляции, чтобы выявить самые сложные ситуации, с которыми наши автомобили столкнутся на дорогах общего пользования. Мы можем либо воспроизвести реальные сценарии и изменить их, либо создать совершенно новые виртуальные сценарии, чтобы наше программное обеспечение для автономного вождения могло отрабатывать их снова и снова».

На странице о безопасности компании Cruise встречаются похожие утверждения:

«Прежде чем выйти на дороги общего пользования, автомобили Cruise проходят более 250 000 симуляций и тестов на закрытых трассах в обычных и экстремальных условиях».

Основные выводы из этих обзоров таковы: (1) симуляция позволяет тестировать множество сценариев вождения, и (2) все будут впечатлены, если вы будете использовать её часто.

Если копнуть глубже и обратиться к постам, блогам и выступлениям с яркими GIF-анимациями, можно сделать вывод, что симуляция похожа на видеоигру для автономных автомобилей, чем-то напоминающую Grand Theft Auto (GTA): полностью созданная 3D-среда с текстурами, освещением и неигровыми персонажами (NPC). Подобно игрокам в GTA, автономный автомобиль может ехать, как ему заблагорассудится, не боясь реальных последствий.

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

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

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

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

Наш воображаемый беспилотный автомобиль

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

Представьте, что на дворе 2015 год, когда интерес к беспилотным автомобилям на пике, и наша команда привлекла огромные средства для разработки автономного транспортного средства. Подобно человеку-водителю, наше программное обеспечение выполняет несколько базовых задач:

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

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

Интерфейс сенсоров: Получает данные с датчиков, таких как изображения с камер и облака точек с лидара.
Распознавание: Обнаруживает объекты, такие как автомобили, пешеходы, дорожные полосы и бордюры.
Поведение: Определяет оптимальную траекторию (маршрут) для движения автомобиля.
Интерфейс автомобиля: Преобразует траекторию в команды для управления рулем, акселератором и тормозом через систему drive-by-wire (DBW).

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

Вот конкретный пример того, как работает наша система, основанная на модулях:

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

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

Наша полная система выглядит так:

Упрощенная схема архитектуры автономного транспортного средства

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

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

Симуляция с воспроизведением (Replay simulation)

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

Как следует из названия, симуляция с воспроизведением работает именно так:

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

Модифицированная схема архитектуры автономного транспортного средства

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

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

Мы получили эти важные возможности для тестирования с относительно небольшими усилиями. Вместо того чтобы создавать сложную полностью сгенерированную 3D-среду, мы обошлись лишь несколькими изменениями в нашей системе публикации и подписки (pubsub).

Интерактивность и проблема расхождения позиций

Простота симулятора с чистым воспроизведением также приводит к его основному недостатку: полное отсутствие интерактивности. Всё в симулируемой среде загружено дословно из журнала. Поэтому окружающая среда не реагирует на поведение симулированного автомобиля, что может привести к нереалистичным взаимодействиям с другими участниками дорожного движения.

Этот классический пример демонстрирует, что может произойти, когда поведение симулированного автомобиля изменяется слишком сильно:

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

Итак, мы едем... бам. Что случилось?

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

Основная идея заключается в том, что в симуляции наши действия влияют на окружающую среду, и это необходимо учитывать».

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

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

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

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

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

Синтетическая симуляция

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

Агенты: полностью интерактивные персонажи (NPC), которые реагируют на поведение нашего автомобиля.
Окружение: 3D-модели дорог, знаков, зданий, погодных условий и т.д., которые могут быть отображены с любой точки зрения.

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

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

Модифицированная схема архитектуры для запуска синтетического моделирования с использованием сгенерированных датчиков

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

Высокая стоимость реалистичных изображений

Симуляции, которые генерируют искусственные данные с датчиков, могут быть довольно дорогостоящими как в разработке, так и в эксплуатации. Разработчику необходимо создать высококачественную 3D-среду с реалистичными моделями объектов и освещением, сопоставимыми с играми уровня AAA.

Пример синтетической симуляции Cruise, показывающей ту же сцену, отображённую в виде синтетических данных с камеры, лидаров и радаров. Источник: Cruise

В блоге Cruise упоминаются некоторые элементы их дорожной карты для синтетической симуляции:

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

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

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

Преобразования туда и обратно в пиксели

По своей природе симуляция синтетических датчиков выполняет круговое преобразование туда и обратно в синтетическое изображение для тестирования системы восприятия. Игровой движок сначала рендерит описание сцены в синтетическое изображение для каждого датчика на симулируемом транспортном средстве, сжигая при этом множество ценных часов работы GPU, только для того, чтобы система восприятия выполнила обратное действие при обнаружении объектов в сцене, создавая внутреннее представление сцены для автономного автомобиля. Каждый раз, когда вы запускаете симуляцию синтетических датчиков, NVIDIA, Intel и/или AWS счастливы.

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

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

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

Пропуск данных с датчиков

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

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

Модифицированная схема архитектуры для выполнения синтетической симуляции с генерируемыми агентами

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

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

Создание умных агентов

Можно начать разрабатывать политику управления для умного агента, аналогично дизайну NPC (неигровых персонажей) в ранних видеоиграх.

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

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

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

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

Генерация описаний сцен

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

Описания сцен обычно берутся из нескольких источников:

Автоматическая конвертация из реальных дорожных сценариев: мы можем написать программу, которая берет зафиксированную поездку в реальном мире, предполагает намерения других участников дорожного движения и сохраняет эти намерения в виде сценария синтетической симуляции.
Ручное проектирование: аналогично редактору уровней в видеоигре. Человек либо полностью создает сценарий с нуля, либо вносит ручные правки в автоматически конвертированный сценарий. Например, можно разработать сценарий на основе полицейского отчета о столкновении между двумя водителями, чтобы смоделировать, как автомобиль мог бы действовать в данной ситуации.
Генеративный ИИ: недавняя работа компании Zoox использует диффузионные модели, обученные на большом наборе дорожных сценариев.

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

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

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

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

Пример размывания времени реакции агрессора. Источник: Waymo

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

Ограничения чистой синтетической симуляции

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

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

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

Если наш автомобиль справляется блестяще, значит, он хорошо работает? Или в библиотеке сценариев не хватает сложных ситуаций просто потому, что мы не предполагали, что они могут возникнуть?

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

Гибридная симуляция

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

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

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

Модифицированная диаграмма архитектуры, объединяющая части воспроизводящей и синтетической симуляции

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

Заключение

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

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

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

Как работает симуляция автономных транспортных средств? Разбираемся в виртуальных тест-драйвах