ORCESTRA: как мы создали универсальный интуитивный интерфейс для обучения роботов

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

Я Артем Лыков, руководитель R&D-направления Physical AI в MWS, и сегодня я расскажу вам о том, как мы вместе с командой придумали, разработали и протестировали универсальный интуитивный интерфейс для обучения роботов совершенно разных конструкций — от обычной тележки до человекоподобного робота. Для решения этой задачи мы решили скрестить смешанную реальность, цифровых двойников и VLM в одной системе — ORCESTRA. А еще про то, с какими проблемами мы столкнулись во время работы, про Mixed Reality, о том, чем отличается кинематика манипулятора от гуманоида, как VLM ищет точки захвата и почему робот с искусственным интеллектом без оператора может случайно уехать в закат стену.

О команде

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

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

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

• Михаил Коненков — специалист по визуально-языковым моделям и управлению роботами с помощью естественного языка. В проекте занимался интеграцией Qwen3-VL, обработкой голосовых и текстовых команд, формированием плана действий и взаимодействием модели с другими компонентами ORCESTRA.

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

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

Почему робота до сих пор не запрограммировать без робототехника

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

Представим простую цель: робот должен перенести предмет со стола и на другой стол. Для человека инструкция элементарна: «Возьми бутылку и поставь сюда». Для робота за этой фразой скрывается набор сложнейших задач: определить точные координаты объекта, выбрать точку захвата, рассчитать траекторию подхода, учесть ограничения своей конструкции, проверить препятствия. И это не учитывая, что «бутылка» для модели — просто пиксели на изображении, а не объект с известной 3D-моделью.

Еще и привязка к «железу» в робототехнике максимально высокая: код, идеальный для UR3, может оказаться бесполезен для KUKA KR 600 FORTEC. А мобильная платформа AgileX Scout V2 вообще работает в другой логике, чем манипулятор. А стандартные пульты от производителя для обучения роботов во первых предназначены только для конкретного типа робота, во вторых — это максимально проприетарный интерфейс, в котором разбирается только специально обученный человек.

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

Как мы улучшили программирование роботов

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

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

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

Следующая проблема — окей, мы проверим робота в виртуальном пространстве, но оно отличается от реального. А что, если поставить виртуального робота в реальный мир?

На этом строится наша концепция. Представьте: вы надеваете Quest 3, через камеры гарнитуры видите настоящий стол, настоящую комнату, настоящего робота. И поверх робота — его «призрак», то есть его виртуальная копия, пространственно совмещенная с реальностью.

Дальше начинается обучение — без единой строчки кода и без инструментов от производителя. Пользователь может показать виртуальному роботу задачу лучом контроллера или даже просто сказать голосом команду: «Перемести захват к бутылке, потом к молотку». VLM разбирает команду, привязывает к объектам в сцене, а система строит план для конкретного типа робота. Прежде чем что-то запускать, оператор видит предпросмотр — как именно робот собирается выполнить задачу на цифровом двойнике в реальном пространстве. Можно посмотреть, поправить, отменить. Двойник сдвинется только после явного подтверждения.

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

Управление контроллером: покажи роботу, что нужно, и система выстроит траекторию

Начну с самого понятного режима — где для оператора нет AI и языковых моделей, а только контроллер и смешанная реальность. Оператор надевает VR-гарнитуру Quest 3, выбирает робота из каталога, размещает его цифрового двойника в нужной точке MR-сцены и задает ключевые точки прямо в воздухе. Луч контроллера указывает направление, а 3D-маркер приближается или отдаляется джойстиком, чтобы задать точку. Для мобильной платформы пол превращается в плоскость обучения — оператор просто ставит на нем точки маршрута.

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

Обратная кинематика (inverse kinematics, IK) — это задача, где по желаемому положению рабочего органа, например захвата, нужно вычислить углы всех суставов робота. А обратная ей задача — прямая кинематика — наоборот, по углам суставов считает, где окажется захват. 

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

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

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

Для мобильной тележки AgileX Scout V2 сценарий использования интерфейса будет выглядеть аналогично, только вместо маркера в воздухе — точки на полу для движения к цели с дифференциальным приводом.

Языковое управление: просто скажи роботу, что делать

No-code-режим снимает основные трудности — не нужно быть робототехником и писать код. Проще только сказать роботу: «Возьми молоко, поставь на стол, потом возьми молоток и положи на полку». Почему бы и нет?

Поэтому кроме визуального управления мы запилили в ORCESTRA режим языкового управления — голосом или текстом. Пользователь дает команду вроде «возьми объект» или «перемести сюда», а визуально-языковая модель интерпретирует ее, связывает слова с объектами сцены и формирует план действий. 

Технически выглядит так: при отправке команды ORCESTRA передает через шлюз FastAPI изображение с камер устройства, снимок текущей сцены с размещенными двойниками, саму команду и опционально — аудио. структурированный ответ возвращает VLM — в нашей конфигурации Qwen3-VL, доступная через OpenAI-совместимый endpoint на базе vLLM или SGLang. Ответ содержит: 

• извлеченные намерения (что пользователь хочет сделать), 

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

• промежуточный план PAI с типом задачи, целевым роботом, путевыми точками и флагом разрешения контакта, 

• а также диагностику — служебную информацию о возможных проблемах или неопределенностях.

Ключевой момент нашего решения: VLM не контроллер робота. Она не отправляет команды напрямую на исполняющие механизмы, как делала бы VLA-модель (vision-language-action). VLM только определяет объекты, точки и предлагает структурированный план. Дальше система занимается метрической привязкой, проверкой, предпросмотром и исполнением. Таково принципиальное архитектурное решение ORCESTRA: рассуждение модели отделено от точного выполнения в координатах. Поэтому языковой модуль можно заменить на другую модель, а галлюцинации нейтрализуются до того, как движение запустят.

Как мы превращаем виртуальную цель в реальные координаты

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

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

Общий бэкенд двух методов и интерфейс оператора

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

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

А вот планы, созданные VLM, сначала нужно привязать к сцене. То есть соотнести с объектами и координатами реального мира визуальные ссылки и превратить их в метрические 3D-цели — точки в трехмерном пространстве с координатами в метрах. Только после обработки траектория, сформированная VLM, становится такой же вводной для общего бэкенда, как и траектория от оператора.

Почему нельзя дать нейросети управлять роботом

Было бы классно просто сказать роботу «Поставь бутылку на стол», — и пусть сразу выполняет команду в реальном мире по аналогии с VLA. Но так как ИИ-модель считывает изображения по пикселям — она может ошибиться и неправильно определить как правильно захватить бутылку или где находится плоскость стола. Может построить неподходящую траекторию, выбрать неудачную точку захвата или предложить действие, которое для конкретного робота физически недостижимо. И если у текстовой модели ошибка — плохой ответ, то здесь неудачная точка может заставить робота изменить позу всего тела, задеть стол, столкнуться с самим собой или упасть. Поэтому мы не хотели, чтобы AI управлял физическим роботом напрямую.

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

1. Выбранный робот установлен в сцене как цифровой двойник — нельзя запустить план для UR3, если UR3 в сцене нет. 

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

3. Каждая визуальная ссылка привязана к сцене с уверенностью выше установленного порога. 

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

Если план прошел валидацию, он отправляется на предпросмотр. Оператор видит цели или путь на цифровом двойнике, осматривает траекторию в реальном пространстве, проверяет, не задевает ли робот стол или стену. И только явное подтверждение запускает исполнение — снова на двойнике, не на физическом железе.

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

Оператор управляет через меню в VR, как в игре:

Как один интерфейс работает с совершенно разными конструкциями роботов

Платформы у нас, мягко говоря, отличаются. Universal Robots UR3 и KUKA KR 600 FORTEC — это шестиосевые манипуляторы на фиксированном основании, но если UR3 — компактный настольный робот, то KR 600 FORTEC — промышленная махина весом больше тонны. AgileX Scout V2 — мобильная платформа с дифференциальным приводом, которая поворачивает за счет разной скорости колес по бортам. Unitree G1 — человекоподобный робот. У этих платформ совершенно разная механика, разная кинематика, разное количество степеней свободы и разные ограничения. Как управлять ими всеми из одного интерфейса?

Ответ — разделить задачу и управление. ORCESTRA не сводит механику к универсальному контроллеру. Вместо этого каждый размещенный робот предоставляет общую абстракцию цифрового двойника — единый интерфейс к виртуальной копии робота, которым пользуются и no-code-интерфейс, и планировщик под управлением VLM. А вот низкоуровневое выполнение отдельных команд передается собственному контроллеру конкретной платформы, который знает ее конструктивные особенности.

Когда меняешь UR3 на AgileX Scout V2, пользовательский интерфейс практически не меняется — те же панели, та же логика размещения, тот же способ задания точек. Разница только в том, что вместо точек движения рабочего органа в воздухе мы задаем точки маршрута на полу. Остальное система берет на себя. Ради этого мы и строили общую архитектуру: чтобы один и тот же интерфейс работал для совершенно разных роботов, не заставляя оператора переучиваться при смене платформы. В итоге все четыре платформы приводятся к единому представлению цифрового двойника и общему интерфейсу: сложность механики остается внутри, а наружу торчит понятный и одинаковый пользовательский сценарий.

Как мы тестировали решение

Мы оценивали ORCESTRA как полностью интегрированный MR-прототип на гарнитуре Quest 3 с промежуточным сервером, который связывает клиент с VLM, работающей на GPU рабочей станции. Наша цель была не в том, чтобы сравнить нашу разработку с программированием роботов через стандартные инструменты от производителя. Наша задача состояла в том, чтобы проверить, что система действительно работает end-to-end для всех поддерживаемых типов роботов: манипуляторов, мобильной тележки и человекоподобного. Причем в обоих режимах — в no-code-обучении по ключевым точкам и в языковом управлении через VLM. В эксперименте участвовали UR3, KUKA KR 600 FORTEC, AgileX Scout V2 и Unitree G1.

Сначала мы прогнали полный рабочий процесс на UR3, KUKA KR 600 FORTEC и AgileX Scout V2. Для манипуляторов система поддерживает размещение, создание путевых точек с обратной связью по зоне досягаемости, отображение доступности точки, генерацию сплайна, предварительный расчет обратной кинематики, предпросмотр действия, сохранение, загрузку и воспроизведение из записанного фрагмента в системе координат робота. Scout V2 использует тот же интерфейс для создания маршрута на плоскости пола, который потом исполняется контроллером тележки. Таким образом один пайплайн поддерживает и траектории манипулятора, и маршруты передвижной тележки — пользователь взаимодействует с системой одинаково.

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

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

1. простые геометрические (куб или шар), 

2. бытовые (бутылка воды), 

3. нестандартные (ручной инструмент) 

4. и крупные объемные (коробка). 

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

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

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

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

Что мы планируем

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

Планы на будущее мы разбили на три направления: 

1. Глубина: данные о расстоянии через камеры и 3D-сетки сцены заменят запасную горизонтальную плоскость. 

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

3. Экспорт записей действий на реальные контроллеры и полноценное пользовательское исследование — сравнить наконец-то с программированием через фирменные пульты обучения роботов.

Что мы сделали и кому это пригодится

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

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

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

• Лабораторная автоматизация, где нужно быстро перенастроить робота под новую серию экспериментов. 

• Склады, где мобильные платформы должны оперативно перестраивать маршруты. 

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

• И отдельно — обучение робототехнике: студенты создают и проверяют поведение на пространственно-совмещенных двойниках, не рискуя оборудованием. 

• Плюс в более широком смысле это недорогая среда для прототипирования и быстрой проверки идей на разных роботах и вариантах платформ.

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