Привет, Хабр! Меня зовут Дмитрий Сенюшкин, на связи AIRI и команда «Автономное зрение». Наша научная группа активно интересуется темой беспилотных автомобилей и сегодня хотелось бы рассказать об одной из наших последний наработок в области симуляции для тестирования и обучения алгоритмов.
В этой области важную роль играет не только объём обучающих данных, но и их разнообразие. Эту проблему можно решить с помощью синтетики, которую производят реалистичные дорожные симуляторы. Мы пошли по этому пути и создали XSIM — новую технологию, для которой пришлось пересмотреть традиционные пайплайны представления объектов. Мы представили XSIM на недавно прошедшей IJCAI 2026, здесь же я перескажу суть нашей работы.
Начать я хотел бы с того, почему вообще эта тема сейчас актуальна и находится на переднем крае науки и технологии. Читатель, знакомый с областью, может свободно пропустить первые абзацы, если уже это все знает.
Разнообразие в данных
На дворе 2026, роботы наступают, ежедневно появляются все новые демки впечатляющих устройств. Автомобильная индустрия не обошла этот тренд, во всём мире компании типа Tesla и Waymo декларируют полный автопилот и запускают роботакси, которое уже сейчас можно потестировать. Ключом к такому успеху, как и всегда, являются данные, на которых учатся ml‑модели бортовых систем.
Но просто много данных иметь недостаточно, и этому есть несколько причин. Основная из них носит названия long‑tail problem и заключается вот в чем. Для безопасности автопилота первоочередное значение имеет разнообразие данных, а не только их количество. И тут возникает проблема — на дороге нечасто встретишь ситуации‑выбросы, когда водители ездят по тротуарам (в МСК по крайней мере), пересекают сплошные или вам под колеса прыгают люди или животные. Гораздо надежнее собирать такие данные в симуляции, где ты можешь контролировать общие условия и сценарии. К такому выводу пришло большинство гигантов индустрии и давно занялось этой темой. Тем не менее вопрос о том, как именно строить симуляторы и какие технологии использовать, остается открытым.
Сам вопрос построения симуляции для автопилота — очень многоуровневая задача. Самые ранние работы создавали упрощенные BEV (bird‑eye‑view) симуляции, где основной фокус отдавался реализму моделирования поведения агентов в сцене. Тем не менее редуцированное представление вряд ли можно назвать «матрицей» для алгоритмов, и вот почему.
Современные алгоритмы управления уже не опираются на системы восприятия, предсказания и планирования, а собирают все в единую модель aka end-2-end. Модели такого плана напрямую обрабатывают данные входных сенсоров, камер, лидаров, возможно, радаров и преобразуют в управляющий сигнал. Упрощенные симуляции не дают сенсорного входа, и в этом их основное ограничение. Для сенсоров нужен второй слой, рендеринг, который превратит коробки в BEV в картинку или лидарное облако.
Самым очевидным решением в таком случае является использование игровых движков — Unity, Unreal Engine, возможно, Unigine (респект ребятам за такие технологии внутри России!). Популярным представителем такого симулятора является CARLA. Это уже очевидный апгрейд, мы можем получать сенсоры для наших систем и учить на таких данных E2E‑модели. Тут на первый план выходит уже реализм синтетических сенсорных данных, который у CARLA невысок. Модели просто запоминают артефакты рендеринга и не переносятся на реальные ситуации.
Но и эта проблема не единственная, ведь такие симуляции банально очень дорого создавать. Для создания реалистичной сцены нужно вложить много труда дизайнера, что ограничивает подобный подход. И тут мы подходим к основной проблеме, которую сейчас решают многие группы — как получить реалистичные симуляции, да еще и в масштабе?
Трендовых подхода два — генеративные модели и нейронная/дифференцируемая графика. Мы в команде «Автономное зрение» пошли по второму пути. В качестве базовой технологии мы выбрали 3D Gaussian Splatting, который предлагает высокий реализм рендеринга и при этом опирается на данные, а не на ручное конструирование, что гарантирует требуемое масштабирование.
XSIM
Итак, встречайте XSIM — технологию симуляции дорожных сцен с возможностью рендеринга реалистичных сенсоров. “X” в названии намекает на симуляции чего‑то произвольного вроде камер и лидаров, но об этом позже.
В основе симуляции XSIM лежит записанный лог данных, собранных с бортовых сенсоров реальной платформы. XSIM восстанавливает сцену в виде облака цветных частиц, которые по правилам объемного рендеринга можно смешивать — отрисовывать — получая таким образом цвета, глубины и так далее, максимально похожие на реальные. Частицы в XSIM = явное представление (не нейросетка), с ними удобно работать, можно манипулировать. Это очень полезно для моделирования динамических сцен, коими являются дороги общего пользования.
Мы для себя выделили акторов нескольких типов:
автомобили — все что едет на ≥4 колесах и это не эго;
люди — пешеходы, которые двигаются по проезжей части (иногда в неожиданных местах);
другие участники (англ. VRU) — другие динамические участники, которые могут повлиять на безопасность движения.
Итого, вся сцена в нашем симуляторе состоит из нескольких групп частиц, большая часть из которых принадлежит статической части сцены, а другая ассоциируется с каким‑то из вышеперечисленных типов акторов. При рендеринге гауссиан мы просто собираем полное облако с учетом эволюции сцены во времени и штрафуем все типы сенсоров, если мы на этапе оптимизации. Просто же?
Да, но нет. Базовая эволюция сцены задается положением боксов объектов в пространстве‑времени через серию ригидных поз соответственно каждому актору. Но эволюция сцены усложняется тем, что часть объектов неригидные, то есть могут сжиматься/изгибаться отдельными частями, а не как целое (машины, к слову, мы считаем ригидными с некоторым допущением).
Мы не стали изобретать велосипед и просто сделали так, как делали до нас: завели SMPL‑модели для деформации людей, где каждой вершине привязали гауссиану, а для VRU просто обучили MLP на деформацию. Так как лог данных, из которого мы всё это получаем, — дискретный, точки между получаются интерполяцией соответствующих поз.
Такое представление сцены достаточно гибкое для моделирования большинства ситуаций на дороге. Тем не менее, оно вполне может быть расширено на новые произвольные типы объектов. Например, можно использовать сгенерированные модели в виде гауссиан для моделирования чего‑то совсем нестандартного, но об этом как‑нибудь расскажем в следующей статье.
Проблема скользящего затвора
Основные сложности начинаются при работе с данными логов. Тут стоит немного рассказать про то, что вообще устанавливают на автомобиль, чтобы записывать данные.
Итак, современные платформы «видят» посредством двух основных типов сенсоров: цветные камеры и LiDAR. Если с камерами каждый знаком — только в смартфоне их по несколько штук, — то с лидарами не все так однозначно (хотя в телефонах они тоже есть!). Большинство использующихся LiDAR‑датчиков имеют вращающуюся головку, которая испускает луч света и измеряет время возврата, из чего пересчитывается расстояние. Но вот незадача: вращается она медленно, всего 10 раз в секунду, поэтому мир успевает измениться за время одного оборота, так как машина может ехать быстро, да и у встречных автомобилей есть свои скорости (вспоминаем закон сложения скоростей!). На самом деле этому эффекту подвержен не только лидар, но и камера тоже. В литературе такой тип дисторсии называют эффектом скользящего затвора (rolling shutter).
В общем случае он говорит нам, что изображение регистрируется не единомоментно, а по строчкам/столбцам. Но почему это вообще проблема? Когда речь идет о компьютерной графике, проекция на камеру — это самая база, на основе которой строится изображение. Вспомним базовую перспективную проекцию:
или кратко 
. Тут 
— координаты точки в системе камеры, 
— поза камеры.
Функция проекции хорошо определена для статичного случая, мы для любой точки в пространстве можем посчитать её положение на камере. При rolling shutter 
принадлежат какой‑то строке (для определенности будем про строки, хотя столбцы тоже можно рассматривать), но вот незадача: строки у нас снимаются в разные моменты, а значит положение камеры и точки меняется. Значит 
будет другим в зависимости от того, куда мы спроецируем его. Замкнутый круг — для проекции нам нужно знать позу камеры, но мы можем её определить, только зная куда спроецировалась точка. Как быть?
Мы в работе по XSIM использовали численную модель проекции вместо аналитической. Чтобы разобраться в этом, вернёмся в начало.
Если камера снимает по строкам, а время, за которое она снимает одну строку, одинаково, то это время линейно растёт относительно индекса строки! В общем случае, конечно, будут еще и столбцы, поэтому полное выражение для времени будет выглядеть следующим образом:
где 
— параметры затвора, 
— координаты пикселя.
Напомню, в XSIM мы моделируем эволюцию, а потому точно знаем, как меняется положение каждой частицы во времени (изменение положения камеры тоже упаковано в 
). И такое уравнение уже разрешимо! Отметим только, что оно НЕЛИНЕЙНОЕ, поэтому солвер нужно брать соответствующий — для нелинейных систем. В уравнение можно подставлять разные типы проекций π, так как временная зависимость уже упакована в
. Это позволяет применять нашу модель к любому типу объективов камеры: fisheye, перспективным, f‑theta, сферическим. Неплохо, правда?
Но на этом сложности не заканчиваются. Дело в том, что в базовом сплаттинге на основе трёхмерных гауссианов 3DGS перспективную модель полностью захардкодили — и это проблема! Ведь спроецировать частицу != спроецировать точку, у частицы есть форма (задана ковариацией), которую тоже нужно уметь деформировать. В 3DGS гауссианы при рендеринге проецируются за счет линейной аппроксимации перспективной проекции (форма деформируется через якобиан). В нем нельзя так просто подменить проекцию, потому разные группы придумывают всякое, чтобы смоделировать всё тот же шаттер.
Вместо этого мы пришли к использованию другой версии сплаттинга — 3D Gaussian Unscented Transform (3DGUT). Его базовая идея как раз и лежит в том, чтобы убрать это досадное недоразумение с хардкодом… Вместо проецирования околоаналитически, частицы проецируются поточечно — что по сути означает численную оценку формы через проекцию точек. То, что доктор прописал — проецировать точки мы уже научились! Заинтересованному читателю предлагаю прочесть оригинал статьи.
Нюансы сферической проекции
К сожалению, для LiDAR это тоже не работает корректно. Тут нужно копнуть еще глубже. Сплаттинги — это техника, основанная на растеризации. Это буквально означает, что мы всё проецируем на полотно камеры, которое имеет размер (сравните с ray‑tracing, где мы вместо этого пускаем лучи в мир).
Сложности начинаются тогда, когда мы растеризуем сферические камеры. Почему? Потому что в этом случае получается панорамная развертка, которая должна быть замкнута по азимуту. Это явно учитывает проекция π(x), когда рассматривает только основное решение по азимуту (см вики, и помни, что тригонометрия периодичная! Но попробуй найти период на вики..)
В случае сферических камер со скользящим затвором, коей является LiDAR, поточечная оценка формы проекции частицы на границах становиться неверной. Что происходит в этот момент? На самом деле, исходные предположения сферической камеры и 3DGUT нарушаются.
Давайте разбираться. Статическая сферическая проекция по своей форме непрерывна по азимуту. Представьте себе глобус, который неподвижен, и вы проводите пальцем по его экватору. Да, путь замкнут, начав в одной точке, возвращаемся в неё же, пройдя полный круг.
Добавляем эффект затвора. Напоминаю, что мы в автомобиле, и он за время съёмки движется. Повторим эксперимент: поставим глобус в авто и нажмем газ. Как бы быстро мы не крутили глобус при движении, положение пальца в абсолютной системе координат никогда больше не совпадёт с тем, из которого вышло. Это и есть нарушение непрерывности, которое проявляет себя как скачок на границе.
Классический 3DGUT никак это не учитывает. Вместо этого он честно перешагнет через границу по непрерывности, и получит оценку формы неверно — как слева на картинке выше. Хотя на самом деле мы ведь видели одну и ту же гауссиану дважды!
Этот эффект мы предлагаем учитывать за счет фазы в решении сферической проекции. Вместо рассмотрения только основного решения мы добавляем сдвиги на ±1 период (на практике полпериода, шаттер не настолько силен, см картинку выше справа), что соответствует всё той же проекции, но сдвинутой по времени шаттера.
На пальцах идея простая: если наша частица попала на границу азимута (где мы знаем, что есть разрыв), то давайте просто сдвинем границу дальше по времени, чтобы она больше не пересекала её. Тогда форма будет корректной. Но ситуация симметрична с двух сторон, так как частица попала на границу и слева, и справа. Значит сделаем такое же расширение в другую сторону по времени. В результате мы получаем две частицы вместо одной, как и должно было быть (см. картинку ниже).
Моделирование этого разрыва чрезвычайно важно, когда мы смотрим на движущиеся объекты, которые выезжают с прилегающих территорий, — их мы часто наблюдаем дважды, и высок риск дефектов.
Собрав все эти идеи вместе, мы смогли добиться хорошего качества симуляции в XSIM. Конечно, в этой статье описано далеко не все. В графике вообще очень много деталей, которые не бросаются в глаза при первом рассмотрении, но оказываются очень важными. Так при создании реалистичной симуляции сенсоров проблема скользящего затвора и правильная оценка проекции выходят на передний план, поэтому их я осветил отдельно.
По нашему XSIM мы опубликовали статью и код, с которой и предлагаем ознакомиться всем заинтересовавшимся. А на этом у меня все, спасибо, что дочитали до конца и до новых встреч!
PS В качестве бонуса покажу вам видео работы XSIM на демонстрационном стенде с физическим рулём:
