1 Современное состояние области¶
Раздел посвящён обзору современного состояния области, в которой позиционируется разрабатываемая платформа uav-simulator. Тема диссертации сформулирована как разработка расширяемой Unity-платформы для исследовательских задач, связанных с роботом учебного класса KS0223 и схожими по уровню сложности устройствами; конкретные эксперименты по обучению с подкреплением и sim-to-real-переносу рассматриваются в работе как варианты использования платформы, а не как самостоятельный научный результат. По этой причине обзор построен в три слоя. В подразделе 1.1 рассматриваются основные симуляторы, на которые ориентируется исследовательское сообщество в задачах автономного наземного и воздушного транспорта; в подразделе 1.2 проводится сравнительный анализ и формулируется ниша платформы; подразделы 1.3 и 1.4 покрывают сопутствующую литературу — соответственно по sim-to-real-переносу и по плагинным архитектурам, к которым платформа прямо обращается на уровне реализации. Подраздел 1.5 формулирует задачу диссертации в терминах выявленного пробела.
При выборе аналогов автор опирался на собственный обзорный материал, выполненный ранее в форме конференционной статьи [1], и расширил его инструментами, которые не были учтены первоначально, но активно используются в современной робототехнической литературе — в первую очередь Webots и стек Isaac. Сравнение ведётся с позиции разрабатываемой платформы и ограничивается признаками, существенными для задачи: возможностью добавления нового робота и трассы без модификации ядра, наличием программного интерфейса для обучения, поддержкой sim-to-real-переноса, лицензионной моделью и совместимостью с распространённым тренировочным инструментарием.
1.1 Симуляторы для исследований автономного управления¶
1.1.1 CARLA¶
CARLA — открытый симулятор городского движения, представленный в работе Dosovitskiy и соавторов в 2017 году [2]. Изначально проект разрабатывался силами Computer Vision Center в Барселоне и Intel Labs как ответ на отсутствие воспроизводимой среды для исследований автономного вождения; впоследствии перешёл в открытое сообщество и поддерживается под лицензией MIT. Архитектурно CARLA построена поверх Unreal Engine (на момент актуальной ветки 0.9 — UE 4.26, в экспериментальной ветке 1.0 — UE 5), что определяет визуальное качество, но одновременно фиксирует требования к видеокарте и операционной системе.
Программный интерфейс CARLA состоит из двух частей. Первая — низкоуровневый клиент-серверный протокол, в котором симулятор является сервером, а сценарий — внешним Python-клиентом, обращающимся к нему через TCP. Это даёт богатые возможности по управлению миром: добавление транспортных средств и пешеходов, переключение погоды и времени суток, чтение нескольких типов сенсоров (RGB-камера, глубинная камера, семантическая сегментация, лидар, радар, GNSS, IMU). Вторая часть — расширения уровня сценария: фреймворк ScenarioRunner и язык Scenic для декларативного описания дорожных ситуаций. Интеграция с обучением выполняется через сторонние обвязки: gym-carla, carla-rllib, MACAD-Gym; собственного нативного интерфейса в семантике Gymnasium API проект не предоставляет.
Для задач настоящей диссертации CARLA не подходит сразу по нескольким причинам. Симулятор ориентирован на полноразмерные транспортные средства и городскую среду; перенесение на учебную платформу класса KS0223 потребовало бы существенной переработки физической модели и описания робота. Системные требования (рекомендуемые 8+ ГБ видеопамяти, операционная система Linux или Windows с поддержкой DirectX или Vulkan) и время сборки делают входной порог высоким для исследовательских команд, не имеющих кластера GPU. Лицензия Unreal Engine накладывает дополнительные ограничения на коммерческое использование производных продуктов. Тем не менее, CARLA остаётся стандартом сравнения для классов задач, связанных с городской автономией, и многократно цитируется в обзорах в этом качестве.
1.1.2 Gazebo и Ignition¶
Gazebo — старейший из активно развиваемых симуляторов в робототехнике; первая версия проекта появилась в 2002 году в составе работы Koenig и Howard, а с 2009 года симулятор тесно интегрирован с экосистемой ROS как референсный инструмент для тестирования алгоритмов на этапе до выхода на физический стенд. С 2019 года Open Robotics параллельно развивает преемника — Ignition Gazebo, переименованный в 2022 году обратно в Gazebo (поколение Garden, Harmonic). Такое разветвление сделало экосистему фрагментированной: исследователю при выборе приходится явно соотносить версию ROS, версию Gazebo и набор используемых плагинов.
Сильная сторона Gazebo — модельный обмен через формат URDF и SDF и зрелая плагинная архитектура. Поведение каждого робота описывается набором плагинов, написанных на C++ и подключаемых к движку через декларативные XML-файлы; это охватывает как кинематику и динамику, так и сенсоры (камеры, лидары, IMU) и контроллеры. Существуют сотни моделей публично доступных роботов, что заметно снижает входной порог для пользователей, работающих с уже описанными платформами. В то же время визуальное качество Gazebo заметно уступает игровым движкам: рендер построен на собственном движке OGRE, и графика остаётся на уровне начала 2010-х. Это делает Gazebo пригодным для отработки алгоритмов планирования, навигации и SLAM, но недостаточно реалистичным для обучения vision-based-policy с прицелом на sim-to-real-перенос.
Применительно к настоящей диссертации Gazebo рассматривался как один из претендентов на роль базового симулятора, однако был отклонён по двум причинам. Первая — низкое качество рендера, не позволяющее экспериментировать с тренировкой политик от изображения, что является целевым use case-ом разрабатываемой платформы. Вторая — жёсткая привязка к экосистеме ROS, требующая от конечного пользователя установки и сопровождения дистрибутива ROS даже для запуска базовых сценариев; для учебной аудитории и для лёгких исследовательских задач это избыточный накладной расход.
1.1.3 AirSim и Microsoft Project AirSim¶
AirSim — open-source-симулятор, разработанный Microsoft Research и впервые описанный в 2017 году в работе Shah и соавторов [3]. Изначально проект был ориентирован на квадрокоптеры; в более поздних версиях добавлена модель наземного транспортного средства. AirSim построен поверх Unreal Engine, что даёт визуальное качество, сопоставимое с CARLA, и одновременно — поддержку фотограмметрических сцен, сценариев со сложными погодными условиями и ночного режима. Внешний интерфейс представлен Python и C++ API, поддерживается базовая интеграция с ROS.
С точки зрения research-сообщества AirSim сыграл важную роль как первая широко доступная среда, позволявшая обучать политики управления беспилотным летательным аппаратом от изображения с реалистичным рендером. В частности, ряд работ по domain randomization и sim-to-real-переносу для дронов опирался именно на AirSim. Однако в 2022 году Microsoft объявила о прекращении активной разработки open-source AirSim в пользу коммерческого продукта Project AirSim, разворачиваемого как облачный сервис. Это разделение оставило open-source-ветку без активной поддержки и привело к фрагментации форков, что ослабило роль AirSim как лабораторного инструмента.
Для разрабатываемой платформы AirSim неприемлем по тем же причинам, что и CARLA: тяжёлый стек Unreal Engine, ориентация на полноразмерные транспортные средства и БПЛА, отсутствие удобной модели расширения для роботов учебного класса. Дополнительно ограничивает применимость закрытие основной open-source-ветки и неопределённый статус продолжения проекта.
1.1.4 Webots¶
Webots — симулятор, разработанный Cyberbotics, с 2018 года распространяемый под лицензией Apache 2.0. Webots ориентирован на образовательное и исследовательское применение и заметно отличается от Gazebo и CARLA архитектурой: симулятор поставляется как самостоятельное приложение с встроенным редактором сцен, модели роботов описываются на языке VRML97/PROTO, а контроллеры — на C, C++, Python, Java или MATLAB. Поддерживается также интеграция с ROS и ROS 2, но она реализуется опциональным мостом, а не как обязательный путь работы.
Сильные стороны Webots — низкий входной порог, кросс-платформенность (Linux, macOS, Windows), наличие большой библиотеки готовых роботов (более ста моделей, в том числе e-puck, Pioneer 3-AT, Khepera) и разумное визуальное качество, достаточное для обучения CNN-политик от изображения. Symbolic-link на учебное использование делает Webots удобным для лабораторных курсов, и именно в этой нише симулятор наиболее распространён.
Тем не менее в качестве базы для разрабатываемой платформы Webots не подходит. Расширяемость симулятора ограничена форматом PROTO, который описывает геометрию и кинематику, но не позволяет полноценно интегрировать произвольную игровую логику; отсутствует современный механизм shader-based-рендера, необходимый для качественной симуляции освещения и материалов; а интеграция с тренировочным инструментарием (Stable-Baselines3, RLlib) опирается на сторонние обёртки и требует индивидуальной настройки для каждого нового сценария. Webots остаётся ценным академическим инструментом, но не закрывает потребности, сформулированные в задаче настоящей работы.
1.1.5 Isaac Sim и Isaac Lab¶
Isaac Sim — симулятор от NVIDIA, построенный поверх платформы Omniverse и движка PhysX 5. Первый публичный релиз состоялся в 2021 году; с 2023 года NVIDIA развивает поверх Isaac Sim фреймворк Isaac Lab (ранее Orbit), специализированный на крупномасштабных тренировках в семантике обучения с подкреплением. Симулятор поддерживает фотограмметрический рендер уровня RTX, физику жёстких и мягких тел, дифференцируемый pipeline для оптимизации параметров среды, GPU-параллелизацию рендера и физики (несколько тысяч агентов одновременно).
В исследовательской среде стек Isaac получил репутацию инструмента, на котором достижимы качественно более высокие скорости обучения за счёт массовой параллелизации; в работах по обучению локомоции квадрупедов (ANYmal, Spot) и манипуляторов на нём был получен ряд заметных результатов. Программный интерфейс реализован через Python (фреймворк omni.isaac.gym), поддерживается работа в семантике Gymnasium API, а Isaac Lab дополнительно предоставляет шаблоны сцен и benchmark-задачи.
Однако порог входа в Isaac Sim чрезвычайно высок. Симулятор требует видеокарты NVIDIA RTX поколения Ampere и новее, операционной системы Linux или Windows со специфичными версиями драйверов, дискового пространства порядка десятков гигабайт и активной интернет-связи для подгрузки ассетов. Лицензионная модель опирается на проприетарную RTX и привязывает производные работы к экосистеме NVIDIA Omniverse. Для исследовательских команд, работающих с роботами учебного класса на ноутбуках и небольших лабораторных машинах, такой стек неуместен. Isaac остаётся релевантен для крупных проектов с серьёзной аппаратной базой, но не для ниши, в которой позиционируется uav-simulator.
1.1.6 Игровые движки как симуляционная платформа: Unity ML-Agents, Trackmania-RL¶
Отдельный класс симуляционных сред образуют игровые движки, используемые исследователями напрямую. Здесь выделяются два направления. Первое — Unity ML-Agents, официальное расширение Unity Technologies, представленное в 2018 году и описанное в работе Juliani и соавторов [4]. ML-Agents предоставляет готовый Python API для обучения политик в произвольной Unity-сцене: разработчик пишет компонент Agent на C#, описывающий наблюдения и действия агента, а Python-сторона запускает тренировку через предоставленный mlagents-learn или собственный скрипт поверх Stable-Baselines3 или RLlib. ML-Agents отличается от Gazebo и CARLA подходом к расширяемости: поведение мира описывается компонентами Unity, а не плагинами симулятора, что снимает необходимость в собственной DSL для сцен и наследует все возможности Unity Editor — визуальный редактор, систему ассетов, prefab-механизм.
Второе направление — Trackmania-RL и подобные исследовательские проекты, использующие коммерческие гоночные игры в качестве среды обучения. Работа Wirth, Voigt и соавторов 2022 года [5] продемонстрировала, что качественный рендер игрового движка и наличие хорошо структурированных трасс позволяют обучить vision-based-policy на гоночную трассу за время, сопоставимое с CARLA, но с заметно меньшим инженерным накладным расходом. Концептуально это подтверждает гипотезу, на которой строится uav-simulator: игровые движки представляют разумный компромисс между визуальным качеством и стоимостью разработки расширений.
Unity ML-Agents наиболее близок к разрабатываемой платформе по технологической базе, но решает другую задачу: ML-Agents — это framework для обучения, а не симуляционная платформа с операторской поверхностью, плагинной системой роботов и трасс, реестром моделей и поддержкой записи демо. Архитектурное различие подробнее обсуждается в подразделе 1.2.3.
1.2 Сравнительный анализ¶
1.2.1 Критерии сравнения: расширяемость, ROS-интеграция, обучение, sim-to-real, доступность¶
Для систематизации обзора и обоснования собственной разработки сформулирован набор из шести критериев. Критерии выбраны таким образом, чтобы отражать те свойства симулятора, которые непосредственно влияют на возможность использования его в задачах настоящей диссертации, и одновременно были фиксируемы по публичной документации проектов. Критерии перечислены ниже, и для каждого приведено уточнение, как его следует понимать в контексте сравнения.
Расширяемость рассматривается как способность добавить новый робот, новую трассу или новый сенсор без модификации ядра симулятора. Высокий уровень расширяемости предполагает наличие документированного механизма плагинов, форматов описания сущностей и инструментов их регистрации; промежуточный уровень — возможность переопределения конкретных классов через наследование с пересборкой проекта; низкий уровень — необходимость править исходный код симулятора для каждого нового устройства.
ROS-интеграция оценивается по факту наличия и зрелости моста с экосистемой ROS или ROS 2. Симулятор может быть либо встроен в ROS как реферeнсный инструмент (Gazebo), либо предоставлять опциональный мост (Webots, AirSim, Isaac), либо не предоставлять ROS-интеграции вовсе (Unity ML-Agents). Для разрабатываемой платформы критерий важен прежде всего как индикатор инженерной зрелости, а не как обязательное требование.
Поддержка обучения определяется наличием встроенного или зрелого внешнего интерфейса для обучения с подкреплением и обучения по демонстрациям. Высокая поддержка предполагает наличие нативного API в семантике Gymnasium и совместимость с распространёнными RL-фреймворками без существенного усилия. Низкая поддержка означает, что обучение возможно, но требует написания собственной обвязки уровня тренировочного цикла.
Sim-to-real-перенос рассматривается через два индикатора: качество рендера, достаточное для обучения vision-based-policy с переносом на реальный стенд, и наличие механизмов domain randomization (вариация освещения, текстур, физических параметров). Симуляторы с фотограмметрическим рендером (CARLA, AirSim, Isaac) формально соответствуют требованию по качеству; симуляторы с упрощённым рендером (Gazebo, Webots) — нет.
Доступность объединяет три практических признака: лицензионную модель, требования к аппаратуре и сложность установки. Симулятор с открытой лицензией, кросс-платформенной сборкой и установкой в один скрипт расценивается как высокодоступный; симулятор, требующий специализированной видеокарты и проприетарного стека — как низкодоступный.
Целевая ниша симулятора — наименее формализованный, но содержательно важный критерий. Указывает, для какого класса задач симулятор изначально проектировался: городская автономия, БПЛА, манипуляторы, локомоция, обучающие задачи, гонки. Понимание ниши помогает корректно интерпретировать сильные и слабые стороны: то, что для одной ниши является ограничением, для другой может быть осознанным компромиссом.
1.2.2 Сводная таблица аналогов¶
Таблица 1.1 сводит результаты сравнения по сформулированным критериям. Оценки заданы качественно — «высокий / средний / низкий» — и опираются на документацию проектов, опыт автора и публикации, цитируемые в подразделах 1.1 и 1.3. Таблица не претендует на полноту охвата всех симуляторов, существующих в литературе, и ограничивается шестью аналогами, разбираемыми выше, с добавлением строки разрабатываемой платформы для прямого сопоставления.
Таблица 1.1 — Сводное сравнение симуляторов
| Симулятор | Расширяемость | ROS | Обучение | Sim-to-real | Доступность | Целевая ниша |
|---|---|---|---|---|---|---|
| CARLA | Средняя (Python API + Scenic) | Опциональный мост | Внешние обвязки (gym-carla) | Высокая, фотограмметрия | Низкая, тяжёлый UE | Городская автономия, полноразмерный транспорт |
| Gazebo / Ignition | Высокая (URDF/SDF + C++ плагины) | Реферeнсная интеграция | Внешние обвязки (gym-gazebo) | Низкая, рендер OGRE | Средняя, требует ROS-стек | Манипуляторы, навигация, SLAM |
| AirSim | Низкая (форки, заморожен) | Опциональный мост | Python API, нет Gym | Высокая, фотограмметрия | Низкая, UE + статус заморожен | БПЛА, частично наземные |
| Webots | Низкая (PROTO/VRML) | Опциональный мост | Внешние обвязки | Средняя, упрощённый рендер | Высокая, кросс-платформенный | Образовательное использование, малые роботы |
| Isaac Sim / Lab | Средняя (USD + Python) | Опциональный мост | Высокая (Isaac Lab + Gym) | Высокая, RTX-рендер | Низкая, требует RTX и Linux | Локомоция, манипуляторы, массовый RL |
| Unity ML-Agents | Высокая (Unity-компоненты) | Отсутствует | Высокая (нативный API) | Средняя, зависит от сцены | Высокая, кросс-платформенный | Framework для обучения в Unity-сценах |
uav-simulator (настоящая работа) |
Высокая (descriptor-based plugins, hot install) | Опциональный мост (ROS 2) | Высокая (HTTP API + Gym-обёртка) | Средняя, Unity 6 + DR-механизмы | Высокая, кросс-платформенный | Учебные роботы класса KS0223 + sim-to-real |
Таблица обнаруживает несколько содержательных закономерностей. Высокая расширяемость в большинстве случаев достигается ценой либо привязки к экосистеме (Gazebo и ROS), либо отсутствия операторской поверхности (ML-Agents). Высокое качество рендера, в свою очередь, типично достигается ценой тяжёлого стека Unreal или RTX и низкой доступности. Промежуточная ниша — кросс-платформенный симулятор с descriptor-based-плагинами, разумным рендером Unity и нативной поддержкой обучения — оказывается слабо заполненной, что и определяет позиционирование разрабатываемой платформы.
1.2.3 Ниша платформы uav-simulator¶
Платформа uav-simulator позиционируется в нише, образованной пересечением трёх требований: лёгкий вход для учебных и небольших исследовательских команд, расширяемость через descriptor-based-плагины без модификации ядра, и встроенная поддержка обучения политик от изображения с прицелом на sim-to-real-перенос на физический стенд KS0223. Каждое из трёх требований по отдельности удовлетворяется тем или иным существующим симулятором; их совместная комбинация не закрывается ни одним из рассмотренных аналогов. Название платформы исторически связано с её первой версией, ориентированной на БПЛА; в текущей реализации платформа сосредоточена на наземных роботах класса KS0223, но архитектурно остаётся применимой к более широкому классу устройств.
Лёгкий вход подразумевает кросс-платформенную сборку (Linux, macOS, Windows) с однострочной установкой через CLI rusim, отсутствие зависимости от ROS на стороне конечного пользователя, скромные системные требования (платформа работает на ноутбуках без выделенной видеокарты в режиме deferred-рендера) и наличие операторской поверхности на основе web-интерфейса, не требующей программирования для типовых задач — настройки сценария, запуска тренировки, проигрывания записанного демо. Среди рассмотренных симуляторов аналогичный профиль доступности обеспечивает только Webots, но без поддержки обучения и без descriptor-based-плагинов.
Расширяемость через descriptor-based-плагины означает, что новый робот или трасса описываются текстовым манифестом и набором сборочных артефактов Unity, упакованных в архив .rusim-plugin, и устанавливаются в runtime через CLI без перекомпиляции движка. Подробное описание плагинной модели приведено в разделах 4 и 5 настоящей работы. Концептуально такой подход ближе всего к плагинам Gazebo и расширениям CARLA, но реализован с акцентом на простоту: автору плагина не требуется знание C++ или специализированных инструментов сборки, достаточно работы в Unity Editor и заполнения декларативного манифеста.
Поддержка обучения с прицелом на sim-to-real-перенос обеспечивается тремя механизмами. Первый — нативный HTTP-интерфейс симулятора в семантике, близкой к Gymnasium API, и Python-обёртка в python/sim_client/, позволяющая использовать uav-simulator как стандартную среду для Stable-Baselines3 без сторонних адаптеров. Второй — встроенные механизмы domain randomization на уровне сценария: вариация освещения, текстур, начальных позиций, физических параметров робота. Третий — единый интерфейс провайдера среды (IKs0223RuntimeProvider), реализованный для симулятора и для физического робота KS0223 через Raspberry Pi и допускающий перенос обученной модели между двумя средами без модификации обвязки. Эта архитектурная особенность подробнее раскрывается в разделе 9.
Тем самым позиция uav-simulator определяется не за счёт превосходства по какому-либо одному критерию, а за счёт сбалансированной комбинации, отвечающей задачам учебной и небольшой исследовательской аудитории, для которой существующие тяжёлые стеки избыточны, а лёгкие учебные симуляторы — недостаточны.
1.3 Литература по sim-to-real transfer¶
Sim-to-real-перенос — задача, в которой политика управления, обученная в симуляторе, применяется к реальному роботу без существенной потери качества. С 2017 года по настоящее время вокруг этой задачи сложилась обширная литература; ниже приведены три направления, наиболее существенные для разрабатываемой платформы и непосредственно учитываемые при проектировании тренировочной обвязки.
1.3.1 Domain randomization¶
Подход domain randomization сформулирован в работе Tobin и соавторов 2017 года [6] на примере задачи захвата объекта манипулятором. Гипотеза работы состоит в том, что если в процессе обучения варьировать визуальные и физические параметры симулируемой среды в диапазоне, заведомо более широком, чем разброс параметров реального мира, то обученная политика будет вынуждена опираться на инвариантные относительно этих вариаций признаки и тем самым окажется устойчивой к отличиям симуляции от реальности. Авторы продемонстрировали, что простой CNN, обученный исключительно в симуляторе с рандомизацией текстур, освещения и позиций камеры, успешно переносится на физический манипулятор без какой-либо дообучающей фазы.
Развитие подхода представлено в работе Peng и соавторов 2018 года [7], где domain randomization применён к задаче локомоции; авторы расширили рандомизацию на физические параметры — массу, трение, демпфирование сочленений — и показали, что результирующие политики устойчивы к ошибкам идентификации модели реального робота. В работе Sadeghi и Levine 2017 года [8] аналогичный приём использован для обучения политики уклонения квадрокоптера от препятствий по монокулярной камере, с переносом на реальный квадрокоптер без сборки физического датасета.
Для разрабатываемой платформы domain randomization является базовым механизмом, заложенным в формат сценария: каждое поле манифеста сценария может быть задано либо детерминированным значением, либо распределением с указанием границ. На уровне runtime вариация выполняется при каждом вызове ResetSimulation, что обеспечивает разнообразие наблюдений в обучающей выборке без модификации тренировочного скрипта. Такой подход согласован с описанной литературой и рассматривается как стартовая точка экспериментов, описанных в разделе 7 настоящей работы.
1.3.2 Behavior cloning и offline RL для прогрева policy¶
Параллельно с domain randomization активно развивается направление, в котором перенос симуляции в реальность опирается не только на обучение с подкреплением, но и на использование демонстраций оператора. Базовая работа здесь — обзор Argall и соавторов 2009 года по обучению по демонстрациям, и более современная серия работ по behavior cloning. В работе Codevilla и соавторов 2018 года [9] показано, что простое behavior cloning поверх большого набора оператор-собранных эпизодов даёт конкурентоспособную политику городской автономии в CARLA, особенно при условии правильного представления контекста (целевого направления движения).
Развитием направления является переход к offline RL — алгоритмам, обучающимся на фиксированной выборке без интерактивного взаимодействия со средой. В работе Fujimoto и соавторов 2019 года предложен алгоритм Batch-Constrained Q-learning (BCQ), решающий проблему смещения распределения; в работе Kumar и соавторов 2020 года — Conservative Q-Learning (CQL). Для задачи sim-to-real-переноса offline RL рассматривается как метод прогрева политики на демонстрациях оператора с последующим дообучением в симуляторе или на физическом стенде.
Применительно к разрабатываемой платформе данное направление отражено в наличии встроенной операции записи и проигрывания демо: DemoReplayService фиксирует операторские последовательности команд в журнал, что делает возможным сбор демонстрационных датасетов как в симуляторе, так и на физическом роботе через единый интерфейс. Использование собранных данных для прогрева политики через behavior cloning рассматривается как один из исследовательских сценариев, поддержанных платформой, но не реализованных в рамках настоящей работы.
1.3.3 Vision-based policies: CNN, frame stacking, R3M¶
Третье направление литературы относится к выбору архитектуры визуальной политики. Со времени работы Mnih и соавторов 2015 года по DQN-обучению на Atari устоявшаяся практика заключается в использовании небольшой свёрточной сети поверх входного изображения и подачи на вход не одного, а нескольких последовательных кадров (frame stacking) для извлечения временных признаков. В большинстве RL-обвязок (Stable-Baselines3, RLlib) frame stacking реализован как стандартная wrapper-обёртка над средой.
Современные исследования стремятся уйти от обучения CNN с нуля и опираются на pretrained-визуальные представления. Работа Nair и соавторов 2022 года [10] предложила R3M — представление, обученное на крупном датасете манипуляционных видео и пригодное в качестве замороженного encoder-а для обучения политик на разных задачах. Аналогичные мотивы заложены в работу VC-1 (Majumdar и соавторы, 2023 [11]), CLIP-based визуальные представления и линию работ по masked autoencoder. Главный практический вывод этих работ — pretrained-encoder заметно сокращает выборочную сложность обучения и нередко улучшает качество переноса, поскольку извлекаемые им признаки менее зависят от конкретного рендера симулятора.
В тренировочной обвязке python/training/ разрабатываемой платформы реализованы оба варианта: тренировка CNN с нуля поверх стека кадров (используется как baseline) и тренировка policy-head поверх замороженного R3M-encoder. Первоначальные эксперименты, описанные в разделе 7 настоящей работы, показывают, что R3M-вариант менее чувствителен к вариации текстур, что согласуется с заявленными в литературе свойствами представления. Окончательная оценка sim-to-real-переноса остаётся открытым вопросом, выходящим за рамки задачи диссертации, но платформа предоставляет достаточный инструментарий для его постановки.
1.4 Плагинные архитектуры в робототехнических симуляторах¶
Плагинная модель — центральная архитектурная идея разрабатываемой платформы. Чтобы корректно сформулировать предъявляемые к ней требования, ниже рассматриваются три способа организации расширений, наблюдаемые в существующих симуляторах. Каждый из подходов обсуждается с точки зрения того, что в нём пригодно для переноса, а что — нет.
1.4.1 ROS plugins и URDF model exchange¶
Экосистема ROS опирается на два связанных механизма расширения. Первый — формат URDF (Unified Robot Description Format), описывающий кинематику, динамику и визуальные свойства робота в виде XML-документа. URDF-файл задаёт дерево связей и сочленений, инерционные параметры, столкновительную геометрию и ссылки на mesh-файлы; такой документ может быть прочитан произвольной частью ROS-стека, что обеспечивает обмен моделями между визуализатором RViz, симулятором Gazebo и стеком планирования MoveIt. Развитие формата — SDF (Simulation Description Format), специфичный для Gazebo и расширяющий URDF описанием сцены и сенсоров.
Второй механизм — динамически загружаемые плагины Gazebo, реализующие модели сенсоров и контроллеров. Плагин представляет собой разделяемую библиотеку C++, скомпилированную против ABI Gazebo и подключаемую к URDF-описанию через декларативный тег. Такой подход даёт высокую гибкость и подтверждён сотнями моделей роботов в публичных репозиториях, но имеет два существенных недостатка для целей разрабатываемой платформы. Первый — необходимость компиляции под конкретную версию Gazebo и операционной системы, что затрудняет распространение плагинов между пользователями. Второй — высокий порог входа для автора плагина: требуется знание C++, инструментов сборки CMake и внутренних API Gazebo. Это делает экосистему ROS-плагинов мощной, но малоприменимой в учебной среде.
Из этого подхода в разрабатываемой платформе заимствована идея декларативного манифеста, описывающего плагин на формате, не зависящем от языка реализации; идея же C++-разделяемых библиотек — отвергнута в пользу платформо-независимой упаковки артефактов Unity AssetBundle.
1.4.2 CARLA plugins (PythonAPI, Scenic)¶
CARLA не имеет плагинной модели в строгом смысле — добавление нового транспортного средства или сенсора требует модификации исходного кода ядра и пересборки, что фактически исключает CARLA из категории расширяемых платформ на уровне runtime. Расширяемость симулятора обеспечивается на двух смежных уровнях. На уровне внешнего клиента — через PythonAPI: пользователь подключается к серверу CARLA, инстанцирует объекты мира из готовой библиотеки blueprint-ов и управляет ими в собственном цикле. Такой подход подходит для исследовательских сценариев, но не позволяет добавлять принципиально новые типы сущностей в мир.
На уровне сценариев расширяемость реализуется через ScenarioRunner и язык Scenic, описанный в работе Fremont и соавторов 2019 года [12]. Scenic — декларативный язык для вероятностного описания дорожных ситуаций: сценарий задаёт распределение начальных позиций агентов, типы транспортных средств, профили поведения и условия завершения. Это даёт CARLA выразительную систему генерации сценариев, на которой построен ряд бенчмарков (Bench2Drive, NuPlan).
Из подхода CARLA в разрабатываемой платформе перенесена идея отдельного слоя сценариев, существующего поверх плагинной системы и описывающего параметры симуляции декларативно. Реализация в uav-simulator использует JSON-формат сценария вместо собственной DSL, что снижает порог входа и согласуется с общей архитектурой платформы. Идея же закрытого ядра с blueprint-библиотекой — отвергнута: новые роботы и трассы в uav-simulator поставляются как полноценные плагины, а не как записи в фиксированной библиотеке.
1.4.3 Unity ML-Agents и расширяемость через ScriptableObject¶
Подход ML-Agents принципиально отличается от двух рассмотренных. Расширяемость в ML-Agents совпадает с расширяемостью самой Unity: разработчик создаёт компоненты на C#, prefab-объекты, ScriptableObject-ассеты и собирает из них сцену в Unity Editor. Никакого специализированного механизма плагинов поверх Unity не предлагается, и в этом — одновременно сила и слабость подхода. Сила состоит в нулевом дополнительном входном пороге для разработчика, уже знакомого с Unity, и в наследовании всей экосистемы ассет-стора, prefab-механизма и инструментов отладки. Слабость — отсутствие механизма распространения готовых extensions между пользователями: чтобы поделиться новым роботом или сценой, автор обычно публикует архив с проектом или Unity-пакет, и установка такого артефакта требует Unity Editor на стороне получателя.
Концепция ScriptableObject в Unity, описанная в документации платформы и широко применяемая в коммерческих играх, представляет собой подход к декларативному описанию данных как ассетов: разработчик создаёт класс, наследующий ScriptableObject, и инстанцирует его в редакторе как файл-ассет с произвольными настройками. Это даёт удобный способ описывать конфигурации без жёсткого кодирования.
В разрабатываемой платформе подход ML-Agents переосмыслен следующим образом: расширяемость на уровне самих сцен и компонентов наследуется от Unity (что делает плагины принципиально легче в авторстве, чем плагины Gazebo), но поверх этого добавлен слой descriptor-based-плагинов с упаковкой в архив .rusim-plugin, что закрывает пробел ML-Agents в части распространения. Тем самым архитектурное решение uav-simulator представляет собой синтез: лёгкость авторства Unity + декларативный манифест + переносимая упаковка в архив, устанавливаемая через CLI на стороне любого пользователя без Unity Editor.
1.5 Постановка задачи диссертации¶
1.5.1 Невыявленный пробел: расширяемая платформа для класса KS0223-подобных роботов¶
Проведённый обзор показывает, что ниша, в которой одновременно выполнены три условия — низкий порог входа, расширяемость через переносимые плагины и встроенная поддержка обучения политик от изображения с прицелом на sim-to-real-перенос, — слабо заполнена существующими симуляторами. CARLA, AirSim и стек Isaac закрывают требования по качеству рендера и обучению, но имеют тяжёлый стек и ориентированы на крупные транспортные средства; Gazebo обеспечивает плагинную расширяемость, но не даёт качественного рендера и плотно связан с экосистемой ROS; Webots отвечает требованиям доступности, но ограниченно расширяем и не имеет встроенной поддержки RL-обучения; Unity ML-Agents даёт нативную расширяемость и обучение, но является фреймворком, а не платформой с операторской поверхностью и плагинной упаковкой.
Конкретно для роботов учебного класса — двухколёсных платформ с дифференциальным или car-like-приводом, лидаром или камерой и недорогой одноплатной вычислительной системой типа Raspberry Pi — отдельного зрелого симулятора с описанным сочетанием свойств в литературе не выявлено. Существующие проекты для подобных роботов либо ограничены отдельными сценами в Gazebo, либо реализованы как одноразовые Unity-проекты без операторской поверхности и без описанной модели расширения. Это и определяет пробел, к закрытию которого направлена настоящая работа.
1.5.2 Требования к платформе по результатам обзора¶
Из обзора непосредственно выводятся следующие требования к разрабатываемой платформе. Их формулировка важна тем, что фиксирует критерии успеха работы и одновременно ограничивает её предметную область, отсекая задачи, которые корректно решаются существующими инструментами и не нуждаются в дублировании.
Платформа должна поддерживать добавление нового робота и трассы в виде самостоятельного плагина без модификации ядра; описание плагина должно быть декларативным и не требовать пересборки runtime у конечного пользователя. Платформа должна предоставлять единый программный интерфейс симулятора и физического стенда KS0223 на стороне backend, чтобы один и тот же сценарий обучения и оценки выполнялся в обеих средах без модификации обвязки. Платформа должна предоставлять нативную обёртку среды в семантике Gymnasium API и совместимость со Stable-Baselines3, что снимает с исследователя необходимость писать собственные адаптеры. Платформа должна включать механизмы domain randomization на уровне сценария и не препятствовать использованию pretrained-визуальных представлений типа R3M в качестве encoder-а политики.
Дополнительные требования формулируются из соображений практической применимости. Установка платформы должна выполняться через единый CLI и не требовать ручной настройки ROS, специализированных видеокарт или проприетарных стеков. Операторская поверхность должна быть представлена web-интерфейсом, доступным локально или по сети, и не требовать программирования для типовых задач. Сборка плагинов должна быть посильна разработчику, владеющему Unity Editor на базовом уровне; работа с C++ не должна быть обязательной.
1.5.3 Связь с целями и задачами работы¶
Перечисленные требования отражены в целях и задачах работы, сформулированных в разделе «Введение» настоящей диссертации, и определяют предмет последующих разделов. Раздел 2 описывает архитектуру платформы как ответ на функциональные требования; раздел 3 раскрывает реализацию ключевых компонентов ядра runtime; раздел 4 фиксирует спецификацию HTTP-интерфейса; раздел 5 описывает плагинную модель и worked-примеры разработки плагинов; раздел 6 — Python-обвязку обучения; раздел 7 — sim-to-real-эксперимент с физическим роботом KS0223 как иллюстрацию пригодности платформы; раздел 8 — инструменты тестирования, сборки и поставки. Тем самым настоящий раздел задаёт исходную точку для оценки результатов: платформа считается удовлетворительной, если она закрывает выявленный в литературе пробел и одновременно обеспечивает воспроизводимый запуск use case-ов, перечисленных в разделе 6.
Положения, вынесенные в обзор, не претендуют на полноту охвата всех симуляторов и всей литературы по обучению с подкреплением — задача такой полноты лежит за пределами магистерской работы и потребовала бы самостоятельного систематического review. Вместо этого обзор опирается на инструменты и работы, непосредственно повлиявшие на проектные решения платформы или образующие референсные точки для её сравнения. Этого достаточно для того, чтобы зафиксировать положение разрабатываемой платформы в сложившемся ландшафте и обосновать целесообразность её разработки.