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

En esta presentación grabada, el Dr. Hongin Won, quien dirige el Equipo de Colaboración de IA para la Fabricación en el Instituto Coreano de Tecnología Industrial (KITECH), y Woojin Park, Gerente de Cuentas Técnicas en Unity Korea, explican un proyecto de 14 semanas que convirtió una planta de fundición en un gemelo digital . Explican cómo el equipo construyó la escena a partir de datos de nube de puntos sin CAD utilizando Unity Industry , cómo usaron Unity AI para acelerar la optimización y el trabajo de interfaz de usuario, y cómo convirtieron al gemelo en una canalización de datos sintéticos que entrena a la IA en la colaboración humano-robot.

Lo que aprenderás

• El equipo construyó un gemelo digital de una fundición de metales a partir de datos de nube de puntos, sin archivos CAD de origen.
• Cómo Unity AI , Asset Manager , Asset Transformer y Version Control se integran en un pipeline de producción.
• Cómo validar un gemelo digital con mediciones del mundo real y calibrar las brechas que aún persisten.
• Cómo generar automáticamente datos de entrenamiento etiquetados en lugar de anotar los fotogramas manualmente.

Esta presentación fue grabada en la conferencia Unite Seoul en julio de 2026.

Transcripción del video

Oradores

• Woojin Park, Gerente de Cuentas Técnicas, Unity Corea
• Dr. Hongin Won, Líder del Equipo de Colaboración en IA para la Fabricación, Centro de Investigación en IA para la Fabricación, Instituto Coreano de Tecnología Industrial (KITECH)
• Jaehoon Hwang, Investigador, KITECH

Tiempo de ejecución: 41 minutos

Acerca de esta transcripción: Esta transcripción ha sido editada para facilitar su lectura.

Introducción: una escena de fábrica esquelética que se convirtió en un gemelo digital viviente.

[00:00] Woojin Park: Hoy hablaré sobre una canalización de datos sintéticos basada en gemelos digitales de Unity para la IA en la fabricación. Soy Woojin Park, gerente de cuentas técnicas en Unity Korea. En Unity, soy responsable del soporte técnico para clientes industriales. En este proyecto, presentaré lo que hicimos durante 14 semanas con KITECH para apoyar la construcción de un gemelo digital de la fábrica.

Si tuviera que resumir la presentación de hoy en una sola frase, sería esta. Es el viaje de una escena de fábrica esquelética que se convirtió en un gemelo digital viviente.

[00:51] Voy a hablar sobre el viaje que hicieron el Instituto Coreano de Tecnología Industrial y Unity utilizando Unity AI. En primer lugar, presentaré Unity AI y los productos relacionados. A continuación, pasaré a hablar del proyecto en sí, KITECH VPH-Metal.

Antes de empezar, permítanme mostrarles el vídeo del resultado final. La zona que están viendo ahora es donde la máquina de moldeo fabrica los moldes de arena. Aquí, a los productos fundidos se les retiran los bebederos, pasan por la zona de desmoldeo y se dirigen a la zona de pulido final y postprocesamiento. Cuando termine esta presentación, creo que entenderán cómo se construyó esta escena en Unity.

[01:38] He asistido a bastantes sesiones y seminarios sobre IA física y temas relacionados. Normalmente, en esas sesiones se ven fotos, imágenes o vídeos de fábricas como esta, y uno piensa: "Vale, entiendo que se puede crear un gemelo digital con Unity u otra herramienta". Pero, ¿cuántas personas se necesitan realmente, cuánto tiempo hay que dedicar a la planificación y qué herramientas pueden agilizar el proceso? Sinceramente, ese tipo de información suele ser difícil de conseguir. Hoy hablaré sobre los productos que utilizamos y cómo los desarrollamos, así como sobre cómo pudimos acelerar el proceso con inteligencia artificial.

Qué incluye Unity AI : Agente, servidor MCP y generadores

[02:23] Unity AI se compone de lo siguiente. El primero es Unity Agent. Luego está el servidor MCP y también los generadores. Por ahora, basta con tener en cuenta estos términos clave.

Unity Agent te permite usar IA basada en Claude, por ejemplo, o en Gemini, directamente dentro del Editor. En cuanto a MCP Server, muchos entornos en Corea funcionan en redes cerradas. Así que, si su empresa tiene un agente como Claude o Codex configurado internamente, puede conectarlo a través del protocolo y usarlo con Unity.

¿Cuál es, entonces, la mayor diferencia entre Unity Agent y MCP Server? Unity Agent ejecuta en segundo plano las funcionalidades que hemos desarrollado nosotros mismos, entre 70 y 80 en total. De esta forma, puede acelerar aún más el desarrollo de Unity .

[03:12] Lo que Unity pretende lograr en última instancia son aplicaciones 3D en tiempo real. Cuando piensas en una aplicación 3D en tiempo real, necesitas animación, necesitas sonido, necesitas objetos y necesitas muchas texturas e imágenes. Así que no se trata solo de escribir código. Si utiliza Unity Agent o MCP Server, también puede usar los recursos de IA que generan los generadores para cada tipo de recurso.

Herramientas de Unity Industry : Asset Manager, Version Control y Asset Transformer

[03:45] Además, Unity Industry incluye Asset Manager, una herramienta para administrar activos, Version Control, una herramienta para la administración de versiones, y Asset Transformer, que prepara sus activos o modelos CAD para su uso directo en la simulación. Esas son las tres herramientas.

Comenzando sin CAD: de nube de puntos a malla

[04:15] Habiendo visto la versión final del proyecto de hoy, muchos de ustedes probablemente se estén preguntando dónde comenzó todo. En proyectos como este, las personas que tienen datos CAD normalmente los importan a Unity y continúan con el proyecto. Pero no teníamos un programa CAD con el que trabajar, así que partimos de datos de nube de puntos.

A continuación, convertimos esa nube de puntos en mallas simplificadas de baja poligonalidad y, posteriormente, utilizando Asset Transformer, Asset Manager, Unity Version Control, Unity AI y otras herramientas y paquetes, llevamos a cabo el proyecto durante 14 semanas. Lo que estás viendo ahora es la nube de puntos visualizada en Unity desde el mismo ángulo.

[05:04] A la izquierda tienes los activos y luego las diferentes herramientas, como Asset Transformer, Asset Manager, automatización, Editor e IA. Explicaré dónde se utilizó cada una de estas herramientas. La parte que probablemente más te interese es la sección de formación que se encuentra en el extremo derecho, o la sección de simulación y gemelos digitales. Finalmente, explicaré cómo se conectó la nube de puntos con el Asset Manager de Unity y con resultados como el gemelo digital.

Asset Transformer: optimización de activos y preparación para la simulación.

[05:42] Empecemos con Asset Transformer y Unity AI. La ropa de la izquierda está cambiando ligeramente. En la parte inferior derecha, se puede ver la misma prenda de vestir renderizada con 11.000 polígonos y con 1,1 millones, y cómo difieren las formas de los polígonos en cada caso.

Asset Transformer es una herramienta que, al disponer de un archivo CAD o un archivo de objeto, permite optimizarlo y aligerarlo fácilmente. Con la ropa de la izquierda, prácticamente no hay diferencia visible a simple vista. De esta forma, Asset Transformer hace que el modelo sea lo más ligero posible para que el ordenador lo renderice, manteniendo al mínimo cualquier diferencia visible.

[06:38] Si observas los cubos que giran en la parte inferior, incluso cuando se giran cubos con el mismo código, el cubo blanco gira justo alrededor de su propio centro, mientras que el cubo amarillo parece estar girando alrededor de algún otro punto. En el modelado CAD, esto se corresponde con el concepto de origen. Dependiendo de si ese origen se establece en lo que llamamos el centro de masa, el centro del cuadro delimitador o simplemente un valor aleatorio, incluso si escribes el código correctamente, el resultado puede ser completamente diferente. Así pues, estas partes debían corregirse y mejorarse, y a este proceso lo denominamos "listo para la simulación".

[07:26] En Unity, utilizamos Asset Transformer y trabajamos junto con KITECH en cómo realizar la optimización. No todas las tareas funcionaron a la perfección. En el caso de la escalera, por ejemplo, al mover el punto de pivote, se produjo un problema en el que se comprimió hasta convertirse en una línea recta. En este caso, utilizamos Unity AI para analizar la causa geométrica real y, a continuación, creamos un conjunto de habilidades que se podían aplicar a todo el proyecto. Así que escribimos definiciones de habilidades y las aplicamos a toda la escena de la fábrica en KITECH, convertimos objetos estáticos como estos en objetos que podían moverse y luego llevamos a cabo la primera ronda de trabajo de optimización.

Gestionar versiones en Asset Manager: 627 archivos fuente reducidos a 218

[08:25] A medida que avanzábamos en el proyecto, lo primero que les mostramos fueron los datos de la nube de puntos, luego los datos de baja poli que se generaron al convertirlos en una malla, y los datos listos para la simulación que acabamos de mostrar, que habían sido optimizados y aligerados. Así que existían estas tres versiones de los datos. Pero, sinceramente, probablemente existieron muchas más versiones. Para evitar confusiones con todas estas versiones y para obtener los datos que necesitábamos en el momento adecuado, el control de versiones era esencial.

[08:45] La herramienta que utilizamos fue Asset Manager. Normalmente, las vistas previas no son compatibles con los archivos CAD. El diseño asistido por ordenador (CAD) tiene muchas ventajas, pero los objetos 3D son difíciles de renderizar y, sin previsualizaciones, puede resultar complicado saber qué recurso es el que se necesita.

[09:03] Asset Manager proporciona vistas previas de cada objeto. Puedes descargarlos directamente en el editor o subirlos y usarlos de inmediato. También incluye funciones para convertirlos a otros formatos o para optimizarlos automáticamente.

En lugar de simplemente subir cada archivo de modelo uno por uno, definimos un conjunto de reglas y creamos datos AAS basados ​​en ontologías, y luego los subimos a Asset Manager. Subimos los archivos en una variedad de formatos, no solo en el formato FBX de uso general, sino también en USD y otros formatos según fuera necesario. Inicialmente teníamos un total de 627 archivos fuente, y tras aplicar un único estándar, los redujimos a 218 archivos y los subimos.

Unity Version Control en URP, HDRP y USD

[10:07] La ​​siguiente parte en la que trabajamos fue el control de versiones. Para muchos de ustedes, el control de versiones probablemente les haga pensar en Git . Pero con Git, básicamente es muy difícil gestionar imágenes o archivos grandes.

En nuestro caso, procesamos esta nube de puntos en el pipeline de renderizado URP de Unity, y también la procesamos en el HDRP de mayor fidelidad. Para mantener ambas versiones y añadir funcionalidades, utilizamos el Unity Version Control. Durante el período de 14 semanas, separamos las ramas para URP, HDRP y USD, mantuvimos el Editor bajo una gestión de configuración integrada y manejamos 77 versiones basadas en conjuntos de cambios.

Creación del panel de control en tiempo de ejecución con Unity AI

[11:18] Ahora que los recursos estaban listos y el control de versiones estaba implementado, era hora de pasar al desarrollo real.

Cuando la gente dice por primera vez que quiere un gemelo digital, lo primero que pide es un panel de control. En el pasado, crear este panel de control implicaba contratar diseñadores de interfaz de usuario (UI) y experiencia de usuario (UX), y desarrollar cada función de forma ordenada como una clase independiente, y así sucesivamente. Eso era lo que se necesitaba antes.

[11:32] Pero ahora, si creas una imagen de los datos que quieres mostrar en esta fábrica, o creas una imagen conceptual, las habilidades dentro de Unity AI se ejecutan en el back-end y lo convierten directamente en un panel de interfaz de usuario interactivo.

Normalmente, en la práctica, existen muchos casos en los que los datos del PLC no se pueden conectar directamente. En nuestro caso también hubo problemas relacionados con el firewall y la seguridad, así que trabajamos con los investigadores y creamos una especie de conjunto de datos PLC ficticio, y luego lo conectamos al panel de control dentro de Unity. Llevamos a cabo todo ese proceso juntos.

Herramientas de edición personalizadas para el escenario del imán

[12:21] En lo que trabajamos a continuación no fue solo una simulación visualmente convincente, sino un proyecto genuinamente basado en hechos. Tras crear el panel de control en tiempo de ejecución, también necesitábamos crear un panel de control o un editor personalizado dentro del propio Editor.

En esta fábrica, el primer escenario consistía en un imán que se movía y utilizaba la fuerza magnética para recoger objetos. Para simular cuánta fuerza magnética se necesita para que las piezas de metal se levanten o no, en lugar de codificar cada valor manualmente, los expusimos directamente en el Editor. Así pues, aspectos como el estado de cada carrito y el estado del imán, e incluso el comportamiento de la simulación física, se desarrollaron utilizando Unity AI.

Creación del efecto horno a partir de una imagen conceptual.

[13:21] Lo siguiente de lo que hablaré es del efecto horno. Algunos de ustedes tal vez piensen que necesitan efectos visuales.

Una de las características más potentes de Unity AI y MCP es que pueden capturar la vista de escena o la vista de juego. Al igual que un teléfono aplica corrección de color, cuando trabajas en un proyecto, los colores pueden verse diferentes dentro del Editor de Unity o la Vista del Juego. Para lograr el impacto deseado con esos colores, necesitas elementos como combinaciones de colores. En el pasado, esa era un área que los artistas tenían que abordar.

[14:01] Pero ahora puedes decirle a la IA: "Crea cuatro esferas en la escena, aplícales un efecto de horno y sigue actualizándolo hasta que se parezca lo más posible al concepto o imagen conceptual que te dé". La Unity AI encuentra y crea el efecto más adecuado, e incluso lo aplica a la escena en sí, todo en una sola operación.

Conversión de URP a HDRP

[14:24] Después de eso, una vez que creamos la versión URP, la convertimos a HDRP. Durante el proceso de conversión de URP a HDRP, estaba ocupado con otra cosa y le di a la IA la configuración gráfica, los conceptos y otros detalles que había preparado. Las imágenes que ven aquí son el resultado de la mejora gradual que la IA ha ido realizando con el tiempo para que coincidan con la imagen conceptual.

[14:51] Al principio, la pantalla era negra o demasiado brillante. Luego volvió a su estado original, se iluminó un poco más y siguió estos pasos por sí solo, por lo que la escena de la fábrica se fue actualizando constantemente. Fue mejorando gradualmente y, al final, puedo decir que se convirtió en la escena HDRP pulida que tenía en mente.

Exportación de USD en tiempo de ejecución

[15:18] Lo último que mencionaré es que no nos detuvimos en URP y HDRP. También gestiono proyectos de gemelos digitales para otras grandes empresas, y lo que suelen decir es: "Otros equipos u otros departamentos de nuestra empresa quieren utilizar estos datos bien organizados y listos para la simulación en otras herramientas o en otras plataformas".

[15:44] Así que en lo que trabajamos fue en habilitar la exportación a USD en tiempo de ejecución. La exportación en tiempo de ejecución significa que, mientras se ejecuta una simulación, se puede modificar el diseño hasta cierto punto, guardarlo y exportar ese estado exacto en formato USD. De esta forma, en otra plataforma, las texturas, la geometría y todo lo demás se pueden conservar tal cual y utilizarse de inmediato.

Alimentando al gemelo en los modelos mundiales

[16:18] Una vez que tienes un gemelo digital como este, no se trata solo de conectar cosas y mirar un panel de control. También quiero hablar del tema más candente de hoy: las modelos internacionales.

Con modelos de mundo como FLUX, Qwen o NVIDIA Cosmos 3, puedes tomar la pantalla del gemelo digital que creaste en Unity, introducir esa pantalla o imagen y, a partir de ahí, mostrar cosas como el envejecimiento de la fábrica, el vapor que sale, escenarios de simulación a la realidad o incluso cambios en la hora del día. Pudimos obtener diversos conjuntos de datos para estas áreas.

Resultados del proyecto en cifras

[16:55] Para poner nuestros resultados en cifras: el proyecto duró 14 semanas desde su inicio. Reorganizamos 627 activos y los redujimos a 218. Tuvimos 77 confirmaciones de código fuente y pasamos desde nubes de puntos hasta HDRP. De los 39 conjuntos de datos que teníamos, visualizamos 20 de ellos. Posteriormente, realizamos un aumento de datos basado en más de 10 modelos del mundo basados ​​en la física.

Comparación lado a lado y la brecha en el dominio de la fabricación

[17:27] Hicimos un video comparativo final. Aquí se puede ver primero la nube de puntos, luego URP en el medio y después HDRP. Después de eso, realizamos simulaciones de difusión, modelos del mundo y aumento de datos.

Hay una cosa que me gustaría señalar en este proceso. Los modelos entrenados con datos generales tienen poca comprensión de los datos del dominio de la fabricación. Por lo tanto, dedicamos bastante tiempo a estudiar cómo subsanar esa falta de datos en el ámbito de la fabricación. Esta parte será explicada a continuación por el Dr. Hongin Won.

Me gustaría agradecer al Dr. Hongin Won, el investigador Youngseok Han, el investigador Jaehoon Hwang y muchos otros que trabajaron con nosotros en este proyecto.

KITECH: convertir un gemelo digital en un entorno donde la IA pueda aprender.

[18:47] Dr. Hongin Won: Soy Hongin Won, del Instituto Coreano de Tecnología Industrial.

Anteriormente, el gerente Woojin Park explicó cómo construir y ampliar un gemelo digital de fábrica en Unity, específicamente para una planta de fundición. Como siguiente paso, hablaré sobre cómo convertir ese gemelo digital en un entorno donde la IA pueda aprender y ser probada.

El título de la presentación de hoy es "Un flujo de datos sintéticos basado en gemelos digitales de Unity para la IA en la fabricación". Dado que el título menciona una canalización de datos sintéticos, es posible que te estés preguntando: "¿Cómo sintetizan exactamente los datos?". Pero antes de eso, la pregunta más importante es: "¿Se ha construido realmente el gemelo digital para que coincida con el sistema real?". Me gustaría centrarme un poco más en cómo verificamos exactamente eso. Denominamos "puesta en tierra" al proceso de creación de un modelo gemelo digital que se ajustara a la realidad, y lo explicaré desde esa perspectiva.

Dirección del equipo y de la investigación

[19:49] Soy Hongin Won y dirijo el Equipo de Colaboración de IA para la Fabricación en el Centro de Investigación de IA para la Fabricación de KITECH. Mis áreas de especialización son la IA aplicada a la fabricación, los gemelos digitales y la infraestructura de datos industriales. En concreto, mi área de interés en gemelos digitales es la virtualización, es decir, cómo trasladar problemas del mundo real a un entorno virtual; la generación, cómo crear los datos necesarios dentro de ese entorno; y la validación, cómo volver a verificar los resultados en el mundo real.

[20:18] Los principales investigadores que participaron en este proyecto son el investigador Jaehoon Hwang y el investigador Seungyeop Ha de nuestro centro. El investigador Jaehoon Hwang fue el responsable de medir y corregir las diferencias restantes después de trasladar los sensores del entorno real al gemelo, mientras que el investigador Seungyeop Ha se encargó de la simulación y el movimiento humano-robot, así como de ampliar los datos a una amplia gama de condiciones.

[20:48] Nuestra línea de investigación para la fabricación de gemelos digitales se reduce a una sola frase: gemelos digitales para IA, IA para gemelos digitales. Significa crear entornos donde la IA pueda aprender y ser probada, y utilizar la IA para reconstruir y actualizar gemelos digitales. También estamos investigando gemelos digitales avanzados basados ​​en sistemas multiagente y modelos LLM.

[21:09] Aquí hay un breve video sobre los modelos que ha construido nuestro centro. El vídeo presenta modelos que transfieren las líneas de montaje de vehículos eléctricos, la logística urbana, las fundiciones y otros elementos a sistemas gemelos, conectándolos como una única cadena de suministro. Utilizamos mucho el simulador de Unity , pero en la parte posterior también modelamos escenarios con simulaciones más ligeras, y los resultados de estas se incorporan posteriormente a un proceso de integración de Unity . Esa es una de las principales líneas de nuestra investigación.

[21:48] El vídeo también presenta las tecnologías de simulación y validación desarrolladas allí, incluyendo la fusión de sensores y estudios donde agentes basados ​​en LLM planifican trayectorias de robots. También incluye un ejemplo de planificación de trayectorias de robots utilizando las funciones de Unity MCP.

Colaboración humano-robot y por qué los datos del HRC son escasos

[22:09] El tema de hoy es la creación de entornos donde la IA pueda aprender y ser probada. El escenario que se aborda en esta presentación es una planta de fabricación donde colaboran humanos y robots. Un entorno donde humanos y robots trabajan juntos en el mismo espacio se denomina colaboración humano-robot, o HRC.

[22:25] En cuanto al desarrollo de la presentación, primero hablaré sobre por qué este tipo de datos de HRC son tan escasos en el mundo real y por qué todavía necesitamos incorporarlos completamente en el modelo de gemelo digital. A continuación, presentaré el enfoque que adoptamos para superar este problema, así como los métodos de síntesis de datos que desarrollamos. Y al construir un modelo gemelo digital, muchas partes no coinciden del todo con el mundo real. En otras palabras, se produce una discrepancia entre la realidad y la simulación, y también explicaré cómo calibramos y resolvimos esa discrepancia.

[23:02] Empecemos con el problema de los datos. Como todos sabéis, la IA aprende de los datos. Pero algunos campos disponen de gran cantidad de datos, mientras que otros no. Por ejemplo, en la conducción autónoma, podemos obtener fácilmente millones de kilómetros de registros de conducción, y para datos de visión general, podemos extraer imágenes y vídeos de la web o de la vida cotidiana. Los modelos de lenguaje también pueden utilizar datos de toda Internet para su entrenamiento.

Pero en las plantas de fabricación, especialmente cuando trabajan juntos humanos y robots, necesitamos datos sobre situaciones en las que los trabajadores se acercan a los robots, partes del cuerpo quedan ocultas o las personas entran y salen de zonas de seguridad. Ese tipo de datos es extremadamente difícil de encontrar en conjuntos de datos públicos.

Cuatro razones para la escasez de datos

[23:54] Identificamos cuatro razones para esta escasez de datos en los sitios de fabricación.

Lo primero es la seguridad. El momento en que una persona entra en la zona de peligro de un robot no es algo que se pueda recrear una y otra vez solo para recopilar datos.

El segundo es el costo. Montar una línea de producción, instalar sensores y filmar mientras cambian las condiciones requiere mucho tiempo y dinero.

La tercera parte fue la que más dificultades tuvo: el etiquetado. Para el entrenamiento de la IA, se necesitan anotaciones y etiquetas para crear la verdad fundamental. Pero alinear las posiciones 3D de humanos y robots, las distancias, la información de las articulaciones, los fondos, los objetos y las regiones a nivel de píxel en múltiples sensores al mismo tiempo supuso un trabajo manual arduo.

[24:36] Lo último es la rareza. Rareza del escenario, para ser precisos. Resulta extremadamente difícil obtener datos sobre colisiones entre personas y robots en instalaciones de fabricación. Las situaciones que preceden inmediatamente a una colisión se denominan eventos de cola larga. Esas situaciones casi nunca ocurren en la realidad, y nos resulta extremadamente difícil crearlas artificialmente. Y en un sitio web bien gestionado, este tipo de datos deberían aparecer con menos frecuencia, no con más.

Datos de proximidad: lo que realmente necesitamos para entrenar

[25:16] Lo que queríamos entrenar no era simplemente si una persona está presente o no, sino a qué distancia está la persona del robot, en qué dirección y en qué postura se acerca. Este tipo de información es lo que llamamos datos de proximidad. Necesitamos comprender esta relación para que los humanos y los robots puedan colaborar y determinar zonas seguras, y en el caso de los robots, para vigilar la proximidad de una persona o para crear escenarios en los que puedan reducir la velocidad y detenerse.

[25:43] En pocas palabras, la situación era la siguiente. Había muy pocos datos. Así que, si no podemos recopilarlo, generémoslo. Eso es lo que nos propusimos hacer. Pero para generar datos, el modelo que los genera necesita datos sólidos propios. En primer lugar, tomamos como referencia los valores medidos en el mundo real y creamos un flujo de datos sintéticos para el gemelo digital de Unity .

Por qué elegimos Unity: cuatro tecnologías en un único entorno de ejecución.

[26:09] Nos pareció relativamente fácil conectar cuatro tecnologías dentro de un único entorno de ejecución, así que usamos Unity.

En primer lugar, está la simulación física, donde robots, personas y objetos interactúan de una manera físicamente válida. En segundo lugar, está la renderización HDRP , que ajusta la iluminación, los materiales, etc., a la realidad para reducir la brecha entre dominios. En tercer lugar, está la simulación de sensores, que reproduce virtualmente varios tipos de sensores. En cuarto lugar, están las tecnologías aplicadas que generan datos a partir del gemelo, de modo que se puedan realizar anotaciones y etiquetados sin que las personas tengan que marcar todo manualmente.

[26:48] Si estos cuatro se hubieran mantenido separados, no habríamos podido producir datos para el entrenamiento de la IA. Al integrarlos en el mismo entorno de ejecución y en el mismo eje temporal, pudimos generar los datos que necesitábamos.

El conjunto de datos Industrial HRC-Bench

[27:03] El proceso de obtención de esos datos de entrenamiento tuvo que seguir una metodología profesional y confiable para la construcción de conjuntos de datos. Para ello, contamos con expertos del sector manufacturero y diseñamos conjuntamente escenarios reales de colaboración entre humanos y robots. Creamos un entorno experimental de referencia en el Centro de Pruebas y Certificación de Robots del Laboratorio de Pruebas de Corea.

[27:33] Como resultado de estos experimentos, creamos el conjunto de datos Industrial HRC-Bench. Los escenarios de HRC recopilados hasta el momento, que están listos para su publicación, se dividen en dos tipos: paletización e inspección de piezas de producción. El conjunto de datos consta de un total de 17 episodios. De estas, nueve se llevaron a cabo con humanos y robots trabajando juntos, y las ocho restantes con el robot solo.

[28:02] El sistema de sensores utilizado aquí integra cámaras RGB , LiDAR, vídeo de 360 ​​grados y un sistema de captura de movimiento. Todas estas modalidades de sensores estaban sincronizadas a 20 Hz, lo que nos proporcionó más de 100.000 fotogramas de datos sin procesar. Calculado en términos de tiempo puro, esto corresponde a más de 80 minutos.

Lo que nos importaba aquí no era solo la magnitud de los datos, sino también su estructura. Todos estos datos compartían el mismo eje temporal para las observaciones y las etiquetas, lo que hizo posible una comparación precisa y una generación de datos significativa. Tenemos previsto publicar próximamente el conjunto de datos Industrial HRC-Bench a través de Hugging Face o un repositorio externo.

El proceso en tres palabras: puesta en tierra, calibración, generación

[28:53] Creo que el flujo general se puede resumir en tres palabras: base, calibración, generación.

Lo primero no consiste simplemente en crear un gemelo digital, sino en vincular a él valores medidos en el mundo real. Eso es la conexión a tierra, que alinea al gemelo con la realidad. Luego está la calibración, que reduce la diferencia entre la realidad y la simulación. Y a partir de ahí, la fase de generación de datos.

Conexión a tierra: entorno, sensores, robots y etiquetas

[29:35] Jaehoon Hwang: Soy Jaehoon Hwang y estuve a cargo de la implementación de la conversión de la realidad a la simulación. En la fase de puesta en marcha, incorporamos cuatro elementos de la realidad: el entorno, los sensores, los robots y las etiquetas.

Ambiente

[29:49] Medimos las dimensiones espaciales y la disposición de los equipos principales del banco de pruebas KTL y, basándonos en esos valores, hicimos coincidir los equipos y las áreas de trabajo uno a uno dentro de Unity. Además, aplicamos HDRP para que los materiales y la iluminación coincidieran con el entorno real. Para el fondo, utilizando imágenes panorámicas de 360 ​​grados capturadas in situ, creamos una escena fotorrealista de dispersión gaussiana en 3D para reducir la brecha entre la realidad y la simulación.

Nuestro objetivo final era crear una celda de referencia donde la estructura y las oclusiones que ve la cámara, la posición relativa de los objetos entre sí y cómo la luz y los materiales afectan a lo que se observa pudieran compararse directamente con el mundo real. En la imagen que aparece en la pantalla, el lado izquierdo muestra la escena real y el lado derecho, la réplica digital desde el mismo punto de vista.

Plataforma de sensores

[30:34] Para el experimento, utilizamos cámaras RGB y de profundidad, LiDAR, una cámara de 360 ​​grados, captura de movimiento y datos de los estados de los dos robots. Dentro del entorno virtual que creamos, no simplificamos esto a una sola cámara. Tras comprobar dónde estaba instalado cada sensor en el banco de pruebas real y qué datos registraba, construimos sensores virtuales con la misma estructura.

[30:59] Dentro del entorno de ejecución de Unity , creamos componentes de sensores personalizados para que todas las observaciones compartieran el mismo reloj de simulación. También conectamos los estados del robot con los movimientos humanos para que estuvieran sincronizados al mismo tiempo. La razón por la que esta sincronización es importante es que la proximidad no se puede resumir con una sola imagen. Al mismo tiempo, el vídeo, la profundidad, las articulaciones del robot y la postura humana deben coexistir para calcular de forma coherente la distancia y las etiquetas de la zona de seguridad.

Robot

[31:27] Teníamos un estándar. Tenía que ser un movimiento físicamente válido, no un movimiento que simplemente pareciera plausible. Importamos las trayectorias conjuntas grabadas en el banco de pruebas real y las configuramos para que se reprodujeran fotograma a fotograma en su orden temporal original. Utilizando Articulation Body de Unity, configuramos los eslabones y las articulaciones del robot, los grados de libertad y la estructura física, y luego ejecutamos los estados articulares registrados sobre esa configuración. Gracias a que la inercia y el contacto se calculan conjuntamente, pudimos gestionar la interacción entre el movimiento del robot y los objetos circundantes dentro de una única estructura física.

Etiquetas

[32:02] A partir del mismo estado de simulación, se generan simultáneamente cuatro tipos de información de referencia: Cuadros delimitadores 2D y 3D con las posiciones de personas, robots y piezas; segmentación semántica y de instancias que separa objetos a nivel de píxel; coordenadas articulares utilizadas para la estimación de la pose; y datos de profundidad reales utilizados como referencia para la distancia de proximidad. La pantalla muestra una escena con cuadros delimitadores 3D aplicados.

Estas etiquetas no fueron producidas por alguien que marcara cada fotograma a mano. Provienen directamente del estado de simulación de Unity . Esto reduce simultáneamente el coste del etiquetado y los errores de anotación.

La diferencia entre la realidad y la simulación en la cámara

[32:52] A continuación, explicaré la brecha entre la realidad y la simulación que encontramos al construir el modelo gemelo digital y cómo la abordamos. Estas son las brechas residuales, las diferencias entre lo real y lo virtual que persisten incluso después de la transferencia. Entre ellos, identificamos dos factores que afectan directamente a los valores de proximidad y a la fuente de datos de referencia.

El primero ocurrió en la cámara. Al construir el entorno virtual, configuramos el mismo modelo de sensor y el mismo campo de visión tanto para la configuración real como para la virtual. Pero el mismo objeto no aparecía en los mismos píxeles.

[33:20] Si observas la superposición de bordes de la derecha, puedes ver que los límites de la misma estructura están ligeramente desalineados dependiendo de la posición. Ni siquiera aplicar la hoja de datos del objetivo al entorno de Unity solucionó el problema. Esto se debe a que las especificaciones del producto y los modelos de lentes estándar por sí solos no pueden explicar las diferencias que generan el ángulo de instalación y cada lente en particular.

En HRC, incluso una discrepancia tan pequeña como esta importa. Si el límite entre una persona y un robot se desplaza tan solo unos pocos píxeles, la correspondencia entre las etiquetas de píxeles generadas en la simulación y las observaciones reales también se vuelve inestable. Así que decidimos medir directamente el residuo de la cámara exacta instalada en este banco de pruebas.

Medir la distorsión de la lente en lugar de modelarla.

[34:01] El método que elegimos es simple. No manipules la lente directamente. Mídelo.

Este proceso consta de tres pasos. En primer lugar, utilizando una vista gaussiana 3D generada a partir de múltiples puntos de vista, obtuvimos escenas correspondientes en los entornos reales y virtuales. Luego calculamos las diferencias entre esas imágenes emparejadas a nivel de píxel y las registramos como un mapa de distorsión por píxel. Finalmente, aplicamos ese mapa al sombreador de distorsión de la cámara de Unity para que la cámara virtual se corrija durante el proceso de renderizado de la imagen.

[34:35] La clave es este bucle. Creamos las escenas correspondientes, medimos la diferencia restante y volvemos a introducir ese valor en el entorno de ejecución de Unity .

Aquí está el resultado. A la izquierda se muestra la observación del sensor real, en el centro la imagen digital corregida y a la derecha la superposición de los bordes de ambas imágenes. Fíjese en los límites de la derecha y podrá apreciar una mejora notable con respecto a antes. Mediante la aplicación de un mapa de distorsión específico, pudimos confirmar que la alineación de píxeles entre las imágenes reales y virtuales mejoró correctamente.

[35:09] Esto no es un posprocesamiento externo, sino un componente que se ejecuta cuando la cámara virtual genera imágenes, de modo que las observaciones corregidas y la verdad fundamental se pueden producir dentro del mismo entorno de ejecución.

Corrección de movimientos humanos inestables con cinemática inversa

[35:16] El segundo problema apareció en el movimiento humano. La pantalla muestra movimientos humanos grabados mediante captura de movimiento, reproducidos con marcadores y un esqueleto. Esta es una sección donde parte del cuerpo quedó ocluida por el robot y la mesa de trabajo durante la captura. Por favor, observe cómo comienzan a temblar las articulaciones del pie. A medida que aumenta la oclusión, las estimaciones de las articulaciones ocultas se vuelven inestables, por lo que el pie se desliza sobre el suelo y las articulaciones se mueven a posiciones físicamente imposibles.

[35:47] Este temblor distorsiona directamente la distancia entre el humano y el robot, la proximidad de cada parte del cuerpo y las etiquetas de la zona de seguridad. Así pues, también aplicamos restricciones físicas al movimiento humano. Esos son el suelo y el rango de movimiento de las articulaciones.

Esta es la misma escena que antes. Esta vez, solo hay dos cosas a las que prestar atención. ¿El pie permanece en contacto con el suelo y las articulaciones se mantienen en su posición natural?

[36:14] Primero, con Foot IK, volvimos a unir el pie a la geometría real del suelo medida. Luego, utilizando Humanoid IK, restringimos las articulaciones ocluidas para que se movieran dentro de los límites articulares válidos. La cinemática inversa (IK) recalcula las posiciones de las articulaciones intermedias, basándose en las posiciones objetivo de las manos o los pies. Esta corrección tiene como objetivo reducir el movimiento no físico que altera las etiquetas de proximidad y seguridad.

Reproducción del escenario: paletización e inspección de piezas

[36:40] Dr. Hongin Won: Me gustaría agradecer al investigador Jaehoon Hwang por exponer las tecnologías clave para reducir la brecha entre la realidad y la simulación, desde la construcción de tuberías hasta la corrección de sensores y cinemática inversa. Les mostraré brevemente cómo se comporta el modelo digital que hemos creado y, a continuación, daremos por finalizada nuestra presentación.

[37:21] Los dos escenarios que construimos como modelos digitales se basan en el mismo entorno HRC, pero difieren en las características de sus tareas. La primera es la paletización y la segunda, la inspección de la superficie. Ambos fueron diseñados como escenarios que podrían ocurrir de manera plausible en una planta de fabricación. Publicaremos los detalles específicos por separado más adelante en el resumen.

[37:44] Este es el caso de paletización. En el modelo de paletización, la información que registramos previamente del robot real a través del cuerpo articulado se integra en este modelo digital gemelo. Como acabas de ver, dos tipos de datos de sensores (información sobre el estado del robot, máscaras de instancia y máscaras de segmentación) se sincronizan y se reproducen simultáneamente.

[38:10] El segundo es un escenario para la inspección de piezas. También se modela la situación de contacto cercano entre el trabajador y el robot, y está muy bien sincronizada con la simulación y los datos del robot, por lo que podemos reproducir datos en los que los cuatro elementos están fundamentados. Si te fijas bien, incluso cuando la persona se superpone con una parte, puedes ver que la segmentación funciona muy bien.

[38:41] El valor de esta canalización de datos no se limita a la creación de un conjunto de datos único. También puede ampliarse y reproducirse en muchos otros emplazamientos industriales.

Aleatorización de dominios con el paquete Unity Perception.

[39:15] Lo que mostramos anteriormente no es tanto un conjunto de datos único, sino más bien una canalización de datos generativa que puede expandir los datos de forma continua. Basándonos en el paquete Unity Perception, creamos un modelo de aleatorización de dominio y definimos rangos de parámetros y reglas de muestreo para la iluminación, los materiales, las cámaras, etc., de modo que se generen variaciones realistas en torno a esta línea base alineada con precisión.

Resumen del sistema y cierre

[39:39] Creo que podemos resumir todo con esta figura. Esta es la estructura del sistema general. A la izquierda se muestran los objetos objetivo, el movimiento humano, las trayectorias del robot, etc. Son elementos de entrada que se pueden intercambiar en cualquier momento, y el centro es el núcleo.

[39:53] Un modelo terrestre que establece la línea base utilizando mediciones del sitio real, un modelo de calibración que corrige errores por tarea y, a la derecha, un modelo que extrae automáticamente datos de verdad de campo multimodales, el modelo de generación. Esos son los tres que construimos.

Mostramos cómo creamos un gemelo digital basado en el banco de pruebas real y calibramos las diferencias clave entre las tareas, hasta generar datos sincronizados.

[40:29] Los datos que mostramos hoy eran HRC, pero de hecho, los presentamos como una aplicación para demostrar los principios de diseño de nuestro oleoducto. En la próxima era de las fábricas de IA, donde robots y humanoides podrán coexistir, creemos que nuestro sistema puede servir como capa de simulación y datos.

Nuestro agradecimiento al Centro de Pruebas y Certificación de Robots KTL, que nos proporcionó el entorno de pruebas y realizó los experimentos con nosotros, y a Unity Technologies, que nos acompañó desde el principio y nos brindó su apoyo incondicional.