Заключение¶

В диссертации решена задача разработки расширяемой программной платформы симуляции в Unity для проведения экспериментальных исследований в задачах обучения и sim-to-real-переноса моделей управления робототехнической платформой Keyestudio KS0223. Поставленная во введении цель достигнута: получен завершённый и воспроизводимый программный продукт, охватывающий контур симуляции, операторский контур, контур обучения и контур поставки, а также проведены экспериментальные проверки, демонстрирующие применимость платформы.

Результаты по разделам¶

В разделе 1 проведён обзор современного состояния области и выполнен сравнительный анализ существующих симуляционных платформ — CARLA, Gazebo, AirSim, Webots, Isaac Sim, Unity ML-Agents и игровых-движковых проектов. Показано, что промежуточная ниша — кросс-платформенный симулятор с descriptor-based-плагинами, разумным рендером и нативной поддержкой обучения, ориентированный на учебные роботы класса KS0223 и сопоставимые устройства, — слабо заполнена. Привлечена литература по sim-to-real-переносу — domain randomization, behavior cloning, pretrained-визуальные представления — и литература по плагинным архитектурам в робототехнических симуляторах. На основании выявленного пробела сформулирована задача диссертации.

В разделе 2 предложена архитектура платформы, состоящая из четырёх функциональных контуров — Unity-runtime, операторский стек, командная утилита rusim и Python-контур обучения. Введено разделение продуктовой и исследовательской частей; зафиксирован поток данных и управления между подсистемами; описана внутренняя структура Unity-runtime, ответственность SimulationManager как ядра жизненного цикла, роль PluginRegistry как каталога сущностей и поверхность SimulatorApiFacade. Обоснован выбор ASP.NET Core, SignalR и React в качестве технологического стека операторского контура.

В разделе 3 описана реализация ключевых компонентов платформы. Детализированы принципы декомпозиции по ответственности и применение DI на стороне backend; описаны состояния и переходы SimulationManager, логика ResetWithConfig и цикл Step. Описаны двухуровневый реестр плагинов с merge-логикой между built-in каталогом и устанавливаемыми плагинами, фабрика BuiltinPluginFactory, procedural-fallback для отсутствующих ассетов и механизм совместимости рендер-пайплайнов. Описана реализация модели транспортного средства Ks0223Vehicle — физический контур, сенсоры, маппинг команд и презентационные visual-режимы — и реализация трасс — BasicArenaTrack, CityPolygonTrack и подсистема светофоров.

В разделе 4 зафиксирована спецификация программных интерфейсов платформы. Описаны три уровня API — Unity HTTP JSON, операторский HTTP и SignalR, plugin SDK; перечислены маршруты /reset, /step, /state, /health и маршруты model lifecycle на стороне симулятора, сгруппированные по доменам маршруты на стороне backend, контракты SignalR-хаба для push-телеметрии. Зафиксированы форматы транспортных DTO — ControlCommand, VehicleState, CameraFrame, SensorDescriptor, ActuatorDescriptor, ConfigKeyValue — и принят политика версионирования API.

В разделе 5 описана разработка плагинов как самостоятельная инженерная задача. Описаны базовые классы plugin SDK — PluginDescriptorBase, VehiclePluginDescriptor и VehicleBase, TrackPluginDescriptor и TrackBase, DeviceContractDescriptor — и механизм совместимости версий через ContractVersion. Приведены два worked-примера — плагин транспортного средства vehicle.arcade.green.v1 и плагин трассы track.city_demo.v1, — каждый с подробным циклом «создать — собрать — валидировать — экспортировать — установить». Зафиксирован формат архива .rusim-plugin.zip и команды rusim plugin install, list, remove, new.

В разделе 6 описана программная обвязка обучения на стороне Python. Зафиксирована единственная точка получения наблюдений — SimClient поверх Unity HTTP API — и предложен набор обёрток сред: одиночная среда ABCorridorVisionEnv, multi-agent в одной Unity-инстанции, meta-multi-agent поверх N инстансов, Genesis-вариант для GPU-параллельной симуляции. Описаны вспомогательные wrapper-ы — дискретизация действий, аугментация изображений, моделирование задержек. Описан тренировочный пайплайн train_cardboard_corridor_v9.py на Stable-Baselines3 с алгоритмом PPO, обоснованы гиперпараметры, описан мониторинг через EvalCallback и приёмы курикулума. Описан режим heavy-DR, frame stacking и пост-обработка реальной камеры. Описан KPI-протокол evaluate_ab_policy.py — 20-эпизодный success rate — и структура evidence-папки. Описан экспорт обученной политики в формат ONNX.

В разделе 7 описаны sim-to-real-эксперименты на физическом стенде KS0223. Сформулирована постановка задачи и природа sim-to-real-разрыва; описана эволюция базовой модели — CNN с frame stacking — от revision rev16 к revision rev29, развитие функции вознаграждения и приёмы anti-spin-shaping. Описан критерий выбора между mild-DR и heavy-DR, зафиксирован эффект heavy-DR-variance — шесть нулевых попыток обучения на revisions rev30—rev35, — и описаны меры борьбы с ним через многосидовые sweeps. Зафиксированы результаты на реальном коридоре — проезд rev29 и анализ телеметрии — и описаны характерные расхождения между симом и реальностью. Указан текущий статус: воспроизводимый sim-успех на L-corridor (75 процентов) и нерешённая задача обобщения на random tracks при heavy-DR.

В разделе 8 описаны средства тестирования, сборки и поставки платформы. Зафиксировано тестовое покрытие — Unity EditMode-тесты, backend xUnit-тесты, Python pytest для wrapper-ов и launch-скриптов; описаны workflow-ы непрерывной интеграции ci.yml, pages.yml и release-workflows; описаны многоэтапный Dockerfile, Makefile-цели и bind-mount конфигов сценариев; описана сборка Unity-runtime в headless-режиме и поставка плагинов через UPM и каталог dist/plugins/. Описана документация проекта в формате MkDocs Material и её автоматический деплой на GitHub Pages.

Оценка полноты решения задач¶

Поставленные во Введении восемь задач решены в полном объёме.

Задача 1 — анализ предметной области и формулирование пробела — закрыта разделом 1; пробел зафиксирован как отсутствие открытой кросс-платформенной descriptor-based-платформы для класса учебных мобильных роботов с нативной поддержкой обучения и sim-to-real-цикла.

Задача 2 — проектирование архитектуры — решена в разделе 2; платформа декомпозирована на четыре функциональных контура с явно зафиксированными границами ответственности и потоком данных, продуктовая и исследовательская части разделены.

Задача 3 — реализация ключевых компонентов — решена в разделе 3; ядро жизненного цикла симуляции, реестр плагинов, модель транспортного средства KS0223 и базовые трассы реализованы и работают в составе единого runtime.

Задача 4 — формулирование программных контрактов — решена в разделе 4; три уровня API специфицированы, форматы транспортных DTO зафиксированы, принята политика версионирования.

Задача 5 — обеспечение расширяемости — решена в разделах 3 и 5; descriptor-based плагины устанавливаются через CLI без модификации ядра и без перекомпиляции Unity-runtime, hot-install цикл подтверждён worked-примерами для транспортного средства и трассы.

Задача 6 — программная обвязка обучения — решена в разделе 6; единый VecEnv-интерфейс, тренировочный пайплайн на Stable-Baselines3, средства domain randomization, KPI-оценка и экспорт ONNX реализованы и применены к серии revisions модели.

Задача 7 — экспериментальная проверка sim-to-real — решена в разделе 7; перенос политики на физический стенд выполнен, проезд revision rev29 на реальном картонном коридоре подтверждён, характер расхождений между симом и реальностью проанализирован, ограничения heavy-DR-обучения зафиксированы как наблюдательный результат.

Задача 8 — инструменты тестирования, сборки и поставки — решена в разделе 8; тестовое покрытие по трём языкам (C#, .NET, Python), непрерывная интеграция через GitHub Actions, многоэтапная сборка backend и Unity-runtime, поставка плагинов и документация на MkDocs Material функционируют в штатном режиме.

Преимущества принятых решений¶

Принятые в работе решения обладают рядом преимуществ, существенных для сформулированной ниши платформы.

Descriptor-based плагинная архитектура обеспечивает добавление новых транспортных средств, трасс и сценариев без модификации ядра и без пересборки runtime. По сравнению с Unity ML-Agents, в котором поведение мира описывается компонентами Unity-сцены, и с CARLA, в которой плагины распространяются как Python-модули поверх Unreal Engine, предложенный механизм даёт инженерно более простой путь распространения расширений: автор плагина собирает архив .rusim-plugin.zip в собственном Unity-проекте и распространяет его как самодостаточный артефакт.

Унификация работы с симуляцией и реальным роботом на уровне операторского контура позволила переиспользовать один и тот же web-интерфейс и один и тот же набор контрактов в двух режимах исполнения — unity-sim и real-robot, — что снимает дублирование инженерных решений между исследовательской и эксплуатационной частями работы и облегчает воспроизведение sim-to-real-цикла на стороне пользователя.

Выбор Unity 6 в качестве симуляционной среды позволил совместить разумное визуальное качество (Universal Render Pipeline, динамическое освещение, материалы) с кросс-платформенной поставкой и низким порогом входа для разработчиков плагинов. По сравнению с Unreal-стеком и RTX-стеком Isaac, выбранная среда оказалась пригодной к запуску на разработческом узле без дискретного GPU, что соответствует исходным условиям работы.

Программный контур обучения, реализованный поверх Stable-Baselines3 и Gym-совместимых обёрток, опирается на широко распространённый инструментарий и упрощает воспроизведение результатов. Применение ONNX в качестве формата экспорта политики обеспечивает совместимость с произвольным runtime-инференсом, в том числе на стороне Raspberry Pi.

Технико-экономическая эффективность¶

Технико-экономическая эффективность принятых решений определяется тремя факторами. Во-первых, кросс-платформенная поставка операторского контура и Unity-runtime позволяет использовать платформу на разработческих узлах без специализированного оборудования (дискретного GPU, RTX, Linux), что снижает стоимость входа в исследовательский процесс. Во-вторых, descriptor-based-плагины снимают необходимость в дублировании ядра при разработке расширений: один runtime, поставляемый централизованно, обслуживает произвольный каталог плагинов; распределённость инженерных усилий между ядром и расширениями уменьшает общее количество кода, необходимого для покрытия класса задач. В-третьих, унификация двух режимов исполнения — unity-sim и real-robot — устраняет дублирование операторских и серверных компонентов, снижает совокупную сложность системы и уменьшает накладные расходы на поддержку.

Теоретическая и практическая ценность¶

Теоретическая ценность результатов работы состоит в систематизации требований к расширяемой симуляционной платформе для класса учебных мобильных роботов и в обосновании архитектурно-программных решений, удовлетворяющих этим требованиям; в формулировании трёхуровневой системы программных контрактов (Unity HTTP, операторский, plugin SDK) как способа изоляции продуктовой и исследовательской частей; в фиксации методики sim-to-real-проверки в условиях ограниченного оборудования и в описании наблюдательного режима heavy-DR-variance.

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

Направления продолжения¶

Дальнейшее развитие платформы связано с несколькими направлениями.

Первое направление — расширение каталога плагинов: подключение альтернативных мобильных роботов (TurtleBot, Jetbot, образовательные дронные платформы), новых трасс (полигон, городская среда, indoor-сценарии), новых сценариев (multi-agent racing, follow-leader, маневрирование на трассе с препятствиями). Второе направление — углубление контура обучения: подключение pretrained-визуальных представлений (R3M, VC-1) в качестве замороженных encoder-ов, исследование behavior cloning поверх оператор-собранных эпизодов, развитие многосидовых sweeps как обязательной части тренировочного протокола. Третье направление — преодоление наблюдаемого heavy-DR-variance: исследование альтернативных архитектур policy (frame stacking разной глубины, рекуррентные политики, attention-механизмы), исследование зависимости стабильности обучения от размера пакета и нормализации advantages. Четвёртое направление — развитие интеграционного контура: углублённая поддержка ROS 2, подключение rosbridge-моста, экспериментальная интеграция со стеком Isaac Lab для GPU-параллельного обучения. Пятое направление — методическое: оформление учебных модулей на основе платформы, описание лабораторных работ, разработка обучающих материалов для подготовки магистрантов и студентов старших курсов по направлению «Программная инженерия».

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