KITECH: Building a factory digital twin and synthetic data pipeline for manufacturing AI

В этой записанной презентации доктор... Хонгин Вон, руководитель группы по сотрудничеству в области искусственного интеллекта в производстве Корейского института промышленных технологий (KITECH), и Уджин Пак, технический менеджер по работе с клиентами в Unity Korea, рассказывают о 14-недельном проекте, в рамках которого литейный завод был преобразован в цифровой двойник . Они рассказывают о том, как команда создала сцену из данных облака точек без использования САПР, применяя Unity Industry , как они использовали Unity AI для ускорения оптимизации и работы над пользовательским интерфейсом, и как они превратили двойника в конвейер обработки синтетических данных, который обучает ИИ взаимодействию человека и робота.
Что вы узнаете
- Как команда создала цифровую модель литейного цеха: она была построена на основе данных облака точек, без использования исходных файлов САПР.
- Где Unity AI , Asset Manager , Asset Transformer и Version Control вписываются в производственный процесс
- Как сопоставить цифровой двойник с реальными измерениями и устранить оставшиеся расхождения.
- Как автоматически генерировать размеченные обучающие данные вместо ручной разметки кадров.
“В грядущую эпоху фабрик, где роботы и человекоподобные существа смогут сосуществовать, мы считаем, что конвейер может служить слоем моделирования и данных.”
Dr. Hongin Won - Korea Institute of Industrial Technology
Manufacturing AI Collaboration Team Lead
Данная презентация была записана на конференции Unite Seoul в июле 2026 года.
Текст видео
Докладчики
- Уджин Пак, технический менеджер по работе с клиентами, Unity Korea
- Доктор Хонгин Вон, руководитель группы по сотрудничеству в области искусственного интеллекта в производстве, Научно-исследовательский центр искусственного интеллекта в производстве, Корейский институт промышленных технологий (KITECH).
- Джехун Хван, научный сотрудник KITECH.
Время выполнения: 41 минута
Об этой стенограмме: Данная расшифровка отредактирована для удобства чтения.
Введение: скелетная модель фабрики, превратившаяся в живой цифровой двойник.
[00:00] Уджин Пак: Сегодня я расскажу о конвейере обработки синтетических данных на основе цифрового двойника Unity для искусственного интеллекта в производстве. Меня зовут Уджин Пак, я технический менеджер по работе с клиентами в Unity Korea. В компании Unity я отвечаю за техническую поддержку промышленных клиентов. В рамках этого проекта я представлю результаты нашей 14-недельной работы с компанией KITECH по созданию цифрового двойника завода.
Если бы мне нужно было в одном предложении подытожить сегодняшнюю презентацию, это звучало бы так. Это история превращения обветшавшего заводского цеха в его живой цифровой двойник.
[00:51] Я расскажу о том, как Корейский институт промышленных технологий и Unity использовали Unity AI. Сначала я представлю Unity AI и сопутствующие продукты. Затем я перейду к самому проекту, KITECH VPH-Metal.
Прежде чем мы начнём, позвольте мне показать вам видео с окончательным результатом. То место, которое вы сейчас видите, — это зона, где формовочная машина изготавливает песчаные формы. Здесь с отлитых изделий удаляются литники, они проходят через зону удаления литников и поступают в зону окончательной шлифовки и постобработки. Думаю, к концу этой презентации вы поймете, как эта сцена была создана в Unity.
[01:38] Я прослушал немало сессий и семинаров по физическому искусственному интеллекту и смежным темам. Обычно на таких сессиях вы видите фотографии, изображения или видео подобных заводов и думаете: «Хорошо, я понимаю, что можно создать цифровой двойник с помощью Unity или другого инструмента». Но сколько людей для этого действительно нужно, сколько времени потребуется на планирование и какие инструменты могут ускорить этот процесс? Честно говоря, такую информацию обычно трудно достать. Сегодня я расскажу о том, какие продукты мы использовали и как мы это создавали, а также о том, как нам удалось ускорить этот процесс с помощью ИИ.
Что включает в себя Unity AI : Агент, сервер MCP и генераторы
[02:23] Unity AI состоит из следующих компонентов. Первый — это Unity Agent. Затем есть MCP-сервер, а также генераторы. На данный момент достаточно помнить об этих ключевых терминах.
Unity Agent позволяет использовать ИИ, основанный, например, на Claude или Gemini, непосредственно в редакторе. Что касается MCP Server, то в Корее очень многие сети работают в закрытом режиме. Таким образом, если в вашей компании уже настроен внутренний агент, например, Claude или Codex, вы можете подключить его через протокол и использовать с Unity.
В чём же основное различие между Unity Agent и MCP Server? В Unity Agent на бэкэнде работают разработанные нами самими навыки, которых насчитывается от 70 до 80. Таким образом, это может значительно ускорить разработку на Unity .
[03:12] В конечном итоге Unity стремится к созданию 3D приложений в реальном времени. Когда речь заходит о 3D приложении, работающем в реальном времени, необходимы анимация, звук, объекты, а также множество текстур и изображений. Так что речь идёт не только о написании кода. Если вы используете Unity Agent или MCP Server, вы также можете использовать ресурсы ИИ, создаваемые генераторами для каждого типа ресурсов.
Инструменты Unity Industry : Asset Manager, Version Control и Asset Transformer
[03:45] Кроме того, Unity Industry включает в себя Asset Manager— инструмент для управления активами, Version Control— инструмент для управления версиями, и Asset Transformer— инструмент, который подготавливает ваши активы или CAD-модели для непосредственного использования в симуляции. Это три инструмента.
Начинаем без САПР: от облака точек к сетке
[04:15] Увидев ранее готовую версию сегодняшнего проекта, многие из вас, вероятно, задаются вопросом, с чего все началось. В подобных проектах люди, имеющие данные САПР, обычно переносят эти данные в Unity и продолжают работу над проектом. Но у нас не было САПР-модели, поэтому мы начали с данных облака точек.
Затем мы преобразовали это облако точек в упрощенные низкополигональные сетки, и после этого, используя Asset Transformer, Asset Manager, Unity Version Control, Unity AI и ряд других инструментов и пакетов, мы выполнили проект в течение 14 недель. То, что вы видите сейчас, — это облако точек, визуализированное в Unity под тем же углом.
[05:04] Слева расположены ресурсы, а затем различные инструменты, такие как Asset Transformer, Asset Manager, автоматизация, Editor и AI. Я объясню, где использовался каждый из этих инструментов. Вероятно, вас больше всего заинтересует раздел обучения в крайнем правом углу, или раздел, посвященный моделированию и цифровым двойникам. В заключение я объясню, как облако точек было связано с Asset Manager Unity и с такими выходными данными, как цифровой двойник.
Asset Transformer: оптимизация активов и подготовка их к моделированию.
[05:42] Давайте начнём с Asset Transformer и Unity AI. Одежда слева немного меняется. В правом нижнем углу вы можете увидеть одну и ту же одежду, отрисованную с использованием 11 000 полигонов и 1,1 миллиона полигонов, а также разницу в форме полигонов в каждом случае.
Asset Transformer — это инструмент, который позволяет легко оптимизировать и уменьшить размер CAD-файла или объектного файла. Одежда слева практически не видна невооруженным глазом. Таким образом, Asset Transformer максимально облегчает рендеринг модели на компьютере, сводя при этом к минимуму любые видимые различия.
[06:38] Если вы посмотрите на вращающиеся кубики внизу, даже при вращении кубиков с одинаковым кодом, белый кубик вращается вокруг своего центра, в то время как желтый кубик выглядит так, будто вращается вокруг какой-то другой точки. В САПР-моделировании это соответствует концепции начала координат. В зависимости от того, где установлена точка отсчета — в центре масс, центре ограничивающего прямоугольника или в какой-либо случайной точке, — даже при правильном написании кода результат может оказаться совершенно разным. Поэтому эти части необходимо было исправить и улучшить, и мы назвали этот процесс «готовностью к моделированию».
[07:26] В Unity мы использовали Asset Transformer и совместно с KITECH работали над оптимизацией. Не все задачи были выполнены идеально. В случае с лестницей, например, при перемещении точки опоры возникла проблема: она сжималась в прямую линию. В данном случае мы использовали Unity AI для анализа фактической геометрической причины, а затем создали набор навыков, который можно было применять во всем проекте. Поэтому мы написали описания навыков в формате Markdown и применили их ко всей сцене фабрики в KITECH, превратили статические объекты, подобные этим, в объекты, которые могут двигаться, а затем провели первый этап оптимизации.
Управление версиями в Asset Manager: 627 исходных файлов сокращены до 218
[08:25] В ходе работы над проектом мы сначала показали вам данные облака точек, затем данные с низким количеством полигонов, полученные путем преобразования их в сетку, и, наконец, данные, готовые к моделированию, которые мы только что показали, — оптимизированные и облегченные. Таким образом, существовало три варианта этих данных. Но, честно говоря, версий, вероятно, было гораздо больше. Чтобы избежать путаницы из-за множества версий и получать необходимые данные в нужный момент, система контроля версий была крайне важна.
[08:45] Итак, инструментом, который мы использовали, был Asset Manager. В случае с файлами САПР предварительный просмотр обычно не поддерживается. САПР обладает множеством преимуществ, но рендеринг 3D объектов требует больших ресурсов, и без предварительного просмотра сложно определить, какой именно объект вам нужен.
[09:03] Asset Manager предоставляет предварительный просмотр для каждого объекта. Вы можете скачать их прямо в редакторе или загрузить и использовать сразу же. Он также включает функции для преобразования в другие форматы или автоматической оптимизации.
Вместо того чтобы просто загружать каждый файл модели по отдельности, мы определили набор правил и создали данные AAS на основе онтологии, а затем загрузили их в Asset Manager. Мы загружали файлы в различных форматах, не только в универсальный FBX, но и в формате USD, а также в других необходимых форматах. Изначально у нас было 627 исходных файлов, а после применения единого стандарта мы сократили их до 218 и загрузили их.
Unity Version Control для URP, HDRP и USD.
[10:07] Следующим этапом нашей работы стал контроль версий. Многим из вас, вероятно, под системой контроля версий приходит на ум Git . Но с Git управлять изображениями или большими файлами крайне сложно.
В нашем случае мы обработали это облако точек в конвейере рендеринга URP в Unity, а также в более качественном HDRP. Поэтому для поддержки обеих версий и добавления новых функций мы использовали Unity Version Control. В течение 14 недель мы разделили ветки для URP, HDRP и USD, сохранили интегрированное управление конфигурацией редактора и обработали 77 версий на основе наборов изменений.
Создание панели мониторинга в режиме реального времени с помощью Unity AI
[11:18] Теперь, когда ресурсы были готовы и система контроля версий была настроена, пришло время перейти к реальной разработке.
Когда люди впервые заявляют о желании получить цифрового двойника, первое, что они спрашивают, — это информационная панель. Раньше для создания этой панели мониторинга требовалось привлечь дизайнеров пользовательского интерфейса и пользовательского опыта, а также аккуратно разработать каждую функцию в виде отдельного класса и так далее. Раньше для этого требовалось именно это.
[11:32] Но теперь, если вы создадите изображение данных, которые хотите отобразить на этой фабрике, или концептуальное изображение, навыки внутри Unity AI будут работать на бэкэнде, и это сразу же превратится в интерактивную панель управления пользовательского интерфейса.
Как правило, в реальных условиях часто возникают ситуации, когда данные с ПЛК невозможно подключить напрямую. В нашем случае также возникли проблемы, связанные с брандмауэром и безопасностью, поэтому мы сотрудничали с исследователями и создали своего рода фиктивный набор данных ПЛК, а затем подключили его к панели управления внутри Unity. Мы вместе прошли весь этот процесс.
Настраиваемые инструменты редактора для сценария с магнитом.
[12:21] Далее мы работали не просто над визуально убедительной симуляцией, а над проектом, основанным на реальных фактах. После создания панели мониторинга во время выполнения нам также потребовалось создать панель мониторинга или пользовательский редактор внутри самого редактора.
На этом заводе в первом сценарии использовался магнит, который двигался и с помощью магнитной силы захватывал предметы. Чтобы смоделировать, какая величина магнитной силы необходима для того, чтобы металлические предметы были подняты или не подняты, вместо того, чтобы жестко задавать каждое значение, мы предоставили к ним прямой доступ в редакторе. Таким образом, такие вещи, как состояние каждой тележки и магнита, и даже то, как ведет себя физическая симуляция, были разработаны с использованием Unity AI.
Создание эффекта печи на основе концептуального изображения.
[13:21] Далее я расскажу об эффекте печи. Некоторые из вас, возможно, думают, что вам нужны визуальные эффекты.
Одна из самых мощных функций Unity AI и MCP заключается в том, что они могут захватывать вид сцены или игровой вид. При работе над проектом, подобно тому как телефон выполняет цветокоррекцию, цвета могут выглядеть по-разному в редакторе Unity или окне игры. Чтобы добиться желаемого эффекта с помощью этих цветов, вам понадобятся такие вещи, как цветовые сочетания. Раньше этим занимались сами художники.
[14:01] Но теперь вы можете сказать ИИ: «Создай четыре сферы на сцене, примени к ним эффект печи и продолжай обновлять их, пока они не будут выглядеть как можно ближе к концепции или концептуальному изображению, которое я тебе дам». Затем Unity AI находит и создает наиболее подходящий эффект и даже применяет его к самой сцене за один раз.
Преобразование URP в HDRP
[14:24] После этого, создав версию URP, мы преобразовали её в HDRP. В процессе конвертации URP в HDRP я был занят другим делом и передал ИИ графические настройки, концепции и другие подготовленные мной детали. Представленные здесь кадры — результат поэтапного улучшения, которое произошёл с помощью искусственного интеллекта, чтобы они соответствовали концептуальному изображению.
[14:51] Сначала это был либо черный экран, либо слишком яркий. Затем изображение вернулось к исходному состоянию, стало немного ярче и самопроизвольно прошло все эти этапы, так что сцена на заводе продолжала обновляться. Постепенно ситуация улучшалась, и в итоге, могу сказать, что система HDRP стала именно той отполированной, которую я себе представлял.
Экспорт долларов США в режиме реального времени
[15:18] И последнее, что я упомяну, это то, что мы не остановились на URP и HDRP. Я также занимаюсь проектами по созданию цифровых двойников для других крупных предприятий, и чаще всего они говорят: «Другие команды или другие отделы в нашей компании хотят использовать эти хорошо организованные, готовые к моделированию данные в других инструментах или на других платформах».
[15:44] Итак, мы работали над тем, чтобы обеспечить возможность экспорта в долларах США во время выполнения программы. Экспорт в режиме реального времени означает, что во время выполнения симуляции вы можете в некоторой степени изменить конфигурацию, сохранить ее и экспортировать это же состояние в формате USD. Таким образом, на другой платформе текстуры, геометрия и все остальное могут быть сохранены в точности как есть и использованы сразу же.
Внедрение двойника в мировые модели.
[16:18] Когда у вас есть такой цифровой двойник, дело не только в подключении устройств и наблюдении за панелью управления. Я также хочу поговорить о самой обсуждаемой сегодня теме: моделях мира.
С помощью таких моделей мира, как FLUX, Qwen или NVIDIA Cosmos 3, вы можете взять изображение с экрана цифрового двойника, созданного в Unity, загрузить это изображение и отобразить такие вещи, как старение фабрики, выходящий пар, сценарии перехода от симуляции к реальности или даже изменения времени суток. Нам удалось получить разнообразные наборы данных по этим областям.
Результаты проекта в цифрах
[16:55] Чтобы представить наши результаты в цифрах: проект длился 14 недель с момента начала. Мы сократили количество активов с 627 до 218. Мы внесли 77 изменений в исходный код и прошли путь от облаков точек до HDRP. Из 39 имеющихся у нас наборов данных мы визуализировали 20 из них. Позже мы провели расширение данных на основе более чем 10 физических моделей мира.
Сравнительный анализ и разрыв в производственной сфере.
[17:27] Мы сделали заключительное сравнительное видео. Здесь вы видите сначала облако точек, затем URP посередине, а затем HDRP. После этого мы провели моделирование распространения, моделирование мировой модели и расширение данных.
В этом процессе я хотел бы отметить один момент. Модели, обученные на общих данных, плохо понимают данные, характерные для производственной сферы. Поэтому мы потратили немало времени на изучение того, как устранить этот пробел в данных в производственной сфере. Далее эту часть объяснит доктор. Хонгин Вон.
Я хотел бы поблагодарить доктора. Хонгин Вон, исследователь Ёнсок Хан, исследователь Чжэхун Хван и многие другие, кто работал над этим проектом вместе с нами.
KITECH: превращение цифрового двойника в среду, в которой искусственный интеллект может обучаться.
[18:47] Доктор Хонгин Вон: Меня зовут Хонгин Вон, я из Корейского института промышленных технологий.
Ранее менеджер Уджин Пак объяснил, как создать и расширить цифровую модель завода в Unity, в частности, для литейного цеха. На следующем этапе я расскажу о том, как превратить этот цифровой двойник в среду, где ИИ сможет обучаться и проходить тестирование.
Тема сегодняшней презентации — конвейер обработки синтетических данных на основе цифрового двойника Unity для искусственного интеллекта в производственной сфере. Поскольку в заголовке упоминается конвейер синтеза данных, вы, возможно, задаетесь вопросом: «Так как же именно они синтезируют данные?» Но прежде чем перейти к этому, необходимо задать важнейший вопрос: «Действительно ли цифровой двойник создан в соответствии с реальной системой?» Я хотел бы подробнее остановиться на том, как именно мы это проверяем. Мы назвали процесс создания модели цифрового двойника, соответствующей реальности, «привязкой к реальности», и я объясню его именно с этой точки зрения.
Команда и направление исследований
[19:49] Меня зовут Хонгин Вон, и я возглавляю группу по сотрудничеству в области искусственного интеллекта в производстве в Центре исследований искусственного интеллекта в производстве при KITECH. Сфера моей компетенции включает искусственный интеллект в производстве, цифровые двойники и промышленную инфраструктуру данных. В частности, в области цифровых двойников меня интересует виртуализация, или способы переноса реальных задач в виртуальную среду; генерация, то есть создание необходимых данных в этой среде; и валидация, то есть способы проверки результатов в реальных условиях.
[20:18] Главными исследователями, принявшими участие в этом проекте, являются исследователь Чжэхун Хван и исследователь Сынёп Ха из нашего центра. Исследователь Чжэхун Хван отвечал за измерение и коррекцию оставшихся различий после перемещения датчиков из реальной среды в модель-близнец, а исследователь Сынёп Ха занимался моделированием взаимодействия человека и робота, а также расширением данных в широком диапазоне условий.
[20:48] Наше направление исследований в области создания цифровых двойников сводится к одному: цифровые двойники для ИИ, ИИ для цифровых двойников. Это означает создание сред, в которых ИИ может обучаться и тестироваться, а также использование ИИ для восстановления и обновления цифровых двойников. Мы также проводим исследования в области передовых цифровых двойников на основе многоагентных систем и LLM-моделей.
[21:09] Вот короткое видео о моделях, которые построил наш центр. В видеоролике представлены модели, которые объединяют сборочные линии электромобилей, городскую логистику, литейные цеха и многое другое в единую цепочку поставок, связывая их между собой. Мы часто используем симулятор Unity , но на бэкэнде мы также моделируем сценарии с помощью более простых симуляций, а результаты этих симуляций затем передаются в конвейер интеграции Unity . Это одно из главных направлений наших исследований.
[21:48] В видеоролике также представлены разработанные там технологии моделирования и проверки, включая объединение данных с датчиков и исследования, в которых агенты на основе LLM планируют траектории движения роботов. В нем также приведен пример планирования траектории движения робота с использованием возможностей Unity MCP.
Взаимодействие человека и робота и почему данных по управлению персоналом так мало.
[22:09] Сегодняшняя тема – создание сред, в которых ИИ может учиться и проходить тестирование. В данной презентации рассматривается сценарий работы производственного предприятия, где происходит взаимодействие людей и роботов. Среда, в которой люди и роботы работают вместе в одном пространстве, называется взаимодействием человека и робота, или HRC (human-robot collaboration).
[22:25] Что касается структуры презентации, я сначала расскажу о том, почему такого рода данные о человеческом развитии так редки в реальном мире и почему нам все еще необходимо встраивать их в модель цифрового двойника. Затем я расскажу о подходе, который мы использовали для преодоления этой проблемы, а также о разработанных нами методах синтеза данных. При создании цифровой модели-двойника многие её элементы не совсем соответствуют реальному миру. Другими словами, возникает разрыв между реальными и симуляционными данными, и я также объясню, как мы откалибровали и устранили этот разрыв.
[23:02] Давайте начнем с проблемы с данными. Как вы все знаете, искусственный интеллект учится на основе данных. Но по некоторым областям доступно достаточно данных, а по другим — нет. Например, в системах автономного вождения мы можем легко получить данные о поездках на миллионы километров, а для получения общих данных визуального восприятия мы можем извлекать изображения и видео из интернета или из повседневной жизни. Языковые модели также могут использовать для обучения данные со всего интернета.
Но для производственных площадок, особенно где люди и роботы работают вместе, нам нужны данные о ситуациях, когда рабочие приближаются к роботам вплотную, когда части тела закрыты для движения, или когда люди входят и выходят из зон безопасности. Подобные данные крайне сложно найти в общедоступных базах данных.
Четыре причины дефицита данных
[23:54] Мы выявили четыре причины нехватки данных на производственных площадках.
Первым делом — безопасность. Момент попадания человека в опасную зону робота — это не то, что можно многократно имитировать лишь для сбора данных.
Второй фактор — стоимость. Прокладка трубопровода, установка датчиков и съемка в условиях меняющейся обстановки требуют значительных временных и финансовых затрат.
Третий аспект, с которым у нас возникли наибольшие трудности, — это маркировка. Для обучения ИИ необходимы аннотации и метки для создания эталонных данных. Однако одновременное совмещение 3D положений людей и роботов, расстояний, информации об суставах, фона, объектов и областей на уровне пикселей по нескольким датчикам представляло собой сплошной ручной труд.
[24:36] Последнее – редкость. Если быть точнее, редкость сценария. Получить данные о столкновениях людей и роботов на производственных площадках крайне сложно. Ситуации, происходящие непосредственно перед столкновением, называются событиями с «длинным хвостом». Подобные ситуации практически никогда не происходят в реальности, и нам крайне сложно создать их искусственно. А на хорошо организованном сайте подобные данные должны появляться реже, а не чаще.
Данные о близости: что нам действительно нужно для обучения.
[25:16] Мы хотели обучить не просто тому, присутствует ли человек или нет, а тому, как далеко человек находится от робота, в каком направлении и в какой позе он приближается. Такую информацию мы называем данными о близости. Нам необходимо понимать эти взаимоотношения, чтобы люди и роботы могли сотрудничать и определять безопасные зоны, а в случае роботов — следить за тем, насколько близко находится человек, или создавать сценарии, в которых они могут замедлиться и остановиться.
[25:43] Проще говоря, ситуация была такова. Данных было слишком мало. Поэтому, если мы не можем это собрать, мы можем это сгенерировать. Именно это мы и стремились сделать. Но для генерации данных модели, которая их генерирует, необходимы собственные достоверные данные. Итак, сначала мы взяли за эталон значения, измеренные в реальном мире, и создали конвейер обработки синтетических данных в виде цифрового двойника на платформе Unity .
Почему мы выбрали Unity: четыре технологии в одной среде выполнения.
[26:09] Мы посчитали, что относительно легко объединить четыре технологии в одной среде выполнения, поэтому мы использовали Unity.
Первый метод — это физическое моделирование, в котором роботы, люди и объекты взаимодействуют физически корректным образом. Второй метод — это рендеринг HDRP , который синхронизирует освещение, материалы и так далее с реальностью, чтобы уменьшить разрыв между предметной областью и реальностью. Третий метод — моделирование датчиков, которое виртуально воспроизводит несколько типов датчиков. Четвертый аспект – это применение технологий, позволяющих генерировать данные из двойника, благодаря чему аннотирование и разметка могут выполняться без ручной разметки всего вручную.
[26:48] Если бы эти четверо остались порознь, мы не смогли бы получить данные для обучения ИИ. Интегрировав их в одну и ту же среду выполнения и на одну и ту же временную ось, мы смогли сгенерировать необходимые нам данные.
Набор данных Industrial HRC-Bench
[27:03] Процесс получения этих обучающих данных должен был соответствовать профессиональной, надежной методологии построения наборов данных. Для этого мы привлекли экспертов из производственной сферы и совместно разработали реальные сценарии взаимодействия человека и робота. Мы создали авторитетную экспериментальную среду в Центре тестирования и сертификации роботов Корейской испытательной лаборатории.
[27:33] В результате этих экспериментов мы создали набор данных Industrial HRC-Bench. Собранные на данный момент сценарии HRC, готовые к публичному выпуску, делятся на два типа: укладка на поддоны и проверка производственных деталей. Набор данных состоит из 17 эпизодов. Из них девять проводились с участием людей и роботов, а остальные восемь — только с участием робота.
[28:02] Используемая здесь сенсорная система объединяет RGB камеры, LiDAR, 360-градусное видео и систему захвата движений. Все эти датчики были синхронизированы с частотой 20 Гц, что позволило нам получить более 100 000 необработанных кадров данных. Если рассчитать это в чистом временном выражении, то это соответствует более чем 80 минутам.
Для нас здесь важен был не только масштаб данных, но и их структура. Все эти данные имели одну и ту же временную ось для наблюдений и меток, что позволило проводить точное сравнение и генерировать осмысленные данные. Мы планируем в ближайшее время опубликовать набор данных Industrial HRC-Bench через Hugging Face или внешний репозиторий.
Конвейер в трех словах: заземление, калибровка, генерация
[28:53] Я думаю, что общий ход событий можно резюмировать тремя словами: заземление, калибровка, генерация.
Во-первых, речь идёт не просто о создании двойника, а о привязке к нему ценностей, измеряемых в реальном мире. Это и есть заземление, которое приводит близнеца в соответствие с реальностью. Затем следует калибровка, которая уменьшает разрыв между реальными и симуляционными данными. А затем начинается этап генерации данных.
Обоснование: окружающая среда, датчики, роботы и маркировка
[29:35] Джехун Хван: Меня зовут Джехун Хван, и я отвечал за внедрение реалистичных характеристик в симулятор. На этапе подготовки мы перенесли из реальности четыре элемента: окружающую среду, датчики, роботов и этикетки.
Среда
[29:49] Мы измерили пространственные размеры и расположение основного оборудования испытательного стенда KTL и, основываясь на этих значениях, точно сопоставили оборудование и рабочие зоны внутри Unity. Кроме того, мы применили HDRP для того, чтобы материалы и освещение соответствовали реальной обстановке. Для фона, используя панорамные изображения с обзором 360 градусов, снятые на месте, мы создали фотореалистичную 3D сцену с гауссовым распределением частиц, чтобы уменьшить разрыв между реалистичностью и симуляцией.
Наша конечная цель заключалась в создании эталонной ячейки, в которой структуру и перекрытия, видимые камерой, положение объектов относительно друг друга, а также влияние света и материалов на наблюдаемые явления можно было бы сравнивать с реальным миром. На изображении на экране слева показана реальная сцена, а справа — её цифровой двойник, снятый с той же точки зрения.
Сенсорная установка
[30:34] Для эксперимента мы использовали RGB камеры и камеры глубины, LiDAR, 360-градусную камеру, систему захвата движений и данные о состоянии двух роботов. В созданной нами виртуальной среде мы не сводили все к одной камере. После проверки расположения каждого датчика на реальной установке и того, что он наблюдал, мы создали виртуальные датчики с аналогичной структурой.
[30:59] Внутри среды выполнения Unity мы создали пользовательские компоненты датчиков, чтобы все наблюдения использовали одни и те же часы моделирования. Мы также связали состояния робота и движения человека таким образом, чтобы они синхронизировались в один и тот же момент. Важность этой синхронизации заключается в том, что близость нельзя описать одним-единственным изображением. В то же время, для согласованного расчета расстояния и обозначений зон безопасности необходимо одновременное наличие видеоданных, данных о глубине, информации о суставах робота и позе человека.
Робот
[31:27] У нас был один стандарт. Это должно было быть движение, имеющее физическую обоснованность, а не просто выглядящее правдоподобно. Мы загрузили траектории движения суставов, записанные на реальном испытательном стенде, и настроили их на покадровое воспроизведение в исходном временном порядке. Используя модуль Articulation Body в Unity, мы настроили звенья и суставы робота, степени свободы и физическую структуру, а затем запустили записанные состояния суставов на основе этих настроек. Поскольку инерция и контакт рассчитываются совместно, мы смогли учесть взаимодействие движения робота с окружающими объектами в рамках единой физической структуры.
Метки
[32:02] Из одного и того же состояния моделирования одновременно генерируются четыре типа эталонной информации: 2D и 3D ограничивающие рамки с указанием положения людей, роботов и их частей; семантическая и экземпляровая сегментация, разделяющая объекты на пиксельном уровне; координаты суставов, используемые для оценки позы; и эталонные значения глубины, используемые в качестве ориентира для определения расстояния близости. На экране отображается сцена с примененными 3D ограничивающими рамками.
Эти этикетки не были изготовлены кем-то, кто вручную размечал каждый кадр. Они берутся непосредственно из состояния симуляции Unity . Это позволяет одновременно снизить затраты на маркировку и количество ошибок при аннотировании.
Разница между реальным и симуляционным изображением в камере
[32:52] Далее я объясню разрыв между реальным и симуляционным, с которым мы столкнулись при создании модели цифрового двойника, и как мы его решили. Это остаточные пробелы, различия между реальным и виртуальным миром, которые сохраняются даже после переноса. Среди них мы выделили два фактора, которые напрямую влияют на значения близости и источник истинных данных.
Первый случай произошёл в камере. При создании виртуальной среды мы задаем одну и ту же модель датчика и одно и то же поле зрения как для реальной, так и для виртуальной среды. Но тот же самый объект отображался на разных пикселях.
[33:20] Если вы посмотрите на наложение краев справа, вы увидите, что границы одной и той же структуры слегка смещены в зависимости от положения. Даже применение фактических данных о линзах к среде Unity не решило проблему. Это объясняется тем, что технические характеристики изделия и стандартные модели линз сами по себе не могут объяснить различия, возникающие из-за угла установки и особенностей каждой линзы.
В сфере управления персоналом даже такое незначительное отклонение имеет значение. Если граница между человеком и роботом смещается всего на несколько пикселей, соответствие между метками пикселей, сгенерированными в симуляции, и реальными наблюдениями также становится нестабильным. Поэтому мы решили напрямую измерить остаточное излучение именно той камеры, которая была установлена на этом испытательном стенде.
Измерение искажений линзы вместо их моделирования.
[34:01] Выбранный нами метод прост. Не моделируйте линзу напрямую. Измерьте это.
Этот процесс состоит из трех этапов. Сначала, используя 3D гауссово изображение, сгенерированное с нескольких точек зрения, мы получили соответствующие сцены в реальной и виртуальной средах. Затем мы вычислили разницу между этими парами изображений на уровне пикселей и записали ее в виде карты искажений для каждого пикселя. Наконец, мы применили эту карту к шейдеру искажения камеры Unity, чтобы виртуальная камера корректировалась в процессе рендеринга изображения.
[34:35] Ключевой момент — этот цикл. Мы создаём соответствующие сцены, измеряем оставшуюся разницу и передаём это значение обратно в среду выполнения Unity .
Вот результат. Слева — изображение, полученное с реального датчика, в центре — скорректированный цифровой двойник, а справа — наложение краев двух изображений. Взгляните на границы справа, и вы увидите заметное улучшение по сравнению с тем, что было раньше. Применив специальную карту искажений, мы смогли подтвердить, что выравнивание пикселей между реальным и виртуальным изображениями улучшилось должным образом.
[35:09] Это не внешняя постобработка, а компонент, который запускается при генерации изображений виртуальной камерой, поэтому скорректированные наблюдения и эталонные данные могут быть получены в одной и той же среде выполнения.
Исправление нестабильных движений человека с помощью обратной кинематики.
[35:16] Вторая проблема возникла в движении человека. На экране отображаются движения человека, записанные с помощью системы захвата движений, которые воспроизводятся с использованием маркеров и скелета. Это участок, где часть тела была скрыта роботом и рабочим столом во время захвата. Обратите внимание, как начинают дрожать суставы стопы. По мере увеличения окклюзии оценки скрытых суставов становятся нестабильными, поэтому стопа скользит по полу, а суставы перемещаются в физически невозможные положения.
[35:47] Эта тряска напрямую искажает расстояние между человеком и роботом, близость каждой части тела и обозначения зон безопасности. Поэтому мы применили физические ограничения и к движениям человека. Это диапазон движений в полу и в суставах.
Это та же самая сцена, что и раньше. На этот раз следует обратить внимание всего на две вещи. Остается ли стопа на полу, и сохраняют ли суставы естественное положение?
[36:14] Во-первых, с помощью Foot IK мы повторно прикрепили стопу к измеренной реальной геометрии пола. Затем, используя Humanoid IK, мы ограничили движение скрытых суставов в пределах допустимых границ суставов. Инверсная кинематика пересчитывает положение суставов между ними на основе целевых положений кистей или стоп. Цель этой коррекции — уменьшить влияние нефизических движений, которые нарушают работу маркировки приближения и безопасности.
Воспроизведение сценария: укладка на поддоны и проверка деталей.
[36:40] Доктор Хонгин Вон: Я хотел бы поблагодарить исследователя Джехуна Хвана за изложение ключевых технологий для сокращения разрыва между реальными и симуляционными данными, от построения конвейера обработки данных до коррекции сенсоров и обратной кинематики. Я кратко покажу вам, как работает созданная нами цифровая модель, а затем завершу нашу презентацию.
[37:21] Два сценария, которые мы создали в виде цифровых моделей, основаны на одной и той же среде HRC, но различаются по своим техническим характеристикам. Первый этап — это укладка на поддоны, а второй — поверхностный контроль. Оба сценария были разработаны таким образом, чтобы максимально полно отражать возможные ситуации на производственном предприятии. Подробные сведения будут опубликованы отдельно позже в аннотации.
[37:44] Это ящик для паллетирования. В модели для укладки паллет данные, полученные ранее от реального робота через шарнирный узел, интегрированы в эту цифровую модель-двойник. Как вы только что видели, два типа данных с датчиков — информация о состоянии робота, маски экземпляров и маски сегментации — синхронизируются и воспроизводятся одновременно.
[38:10] Второй сценарий предназначен для проверки деталей. Также моделируется ситуация тесного контакта между рабочим и роботом, и она очень хорошо синхронизирована с данными моделирования и данными робота, поэтому мы можем воспроизводить данные, в которых все четыре элемента находятся на земле. Если присмотреться, то даже когда человек перекрывает какую-либо часть тела, можно увидеть, что сегментация работает очень хорошо.
[38:41] Ценность этого конвейера обработки данных не ограничивается созданием разового набора данных. Его также можно расширить и воспроизвести на многих других промышленных объектах.
Рандомизация домена с помощью пакета Unity Perception
[39:15] То, что мы показали ранее, — это не столько одноразовый набор данных, сколько генеративный конвейер данных, который может непрерывно расширять данные. На основе пакета Unity Perception мы создали модель рандомизации домена и определили диапазоны параметров и правила выборки для освещения, материалов, камер и так далее, чтобы генерировать реалистичные вариации вокруг этой точно выровненной базовой линии.
Краткое описание системы и заключение
[39:39] Думаю, мы можем подвести итог всему с помощью этой цифры. Такова структура всей системы в целом. Слева отображаются целевые объекты, движение человека, траектории роботов и так далее. Это входные элементы, которые можно заменить в любой момент, а центр является ядром.
[39:53] Модель местности, которая устанавливает базовый уровень, используя измерения с фактического участка, калибровочная модель, которая исправляет ошибки по задачам, и справа — модель, которая автоматически извлекает многомодальные данные для проверки на местности, модель генерации. Вот три из них, которые мы построили.
Мы продемонстрировали, как создаём двойника на основе реального испытательного стенда и калибруем ключевые различия в задачах, вплоть до генерации синхронизированных данных.
[40:29] Данные, которые мы сегодня показали, были HRC, но на самом деле мы представили их как приложение для доказательства принципов проектирования нашего конвейера. В грядущую эпоху фабрик, где роботы и человекоподобные существа смогут сосуществовать, мы считаем, что наш конвейер может служить слоем моделирования и обработки данных.
Мы выражаем благодарность Центру тестирования и сертификации роботов KTL, который предоставил испытательный полигон и провел с нами эксперименты, а также компании Unity Technologies, которая была с нами с самого начала и оказывала нам всестороннюю поддержку.


