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

Nesta apresentação gravada, o Dr. Hongin Won, que lidera a Equipe de Colaboração em IA para Manufatura no Instituto Coreano de Tecnologia Industrial (KITECH), e Woojin Park, Gerente de Contas Técnicas da Unity Korea, descrevem um projeto de 14 semanas que transformou uma fundição em um gêmeo digital . Eles explicam como a equipe construiu a cena a partir de dados de nuvem de pontos sem usar CAD, utilizando o Unity Industry , como usaram o Unity AI para acelerar a otimização e o trabalho de interface do usuário e como transformaram o gêmeo digital em um pipeline de dados sintéticos que treina a IA na colaboração entre humanos e robôs.

O que você aprenderá

• A equipe construiu uma réplica digital de uma fundição de metais a partir de dados de nuvem de pontos, sem arquivos CAD originais.
• Onde o Unity AI , o Asset Manager , o Asset Transformer e o Version Control se encaixam em um pipeline de produção?
• Como ancorar um gêmeo digital em medições do mundo real e calibrar as lacunas existentes.
• Como gerar dados de treinamento rotulados automaticamente em vez de anotar os frames manualmente.

Esta apresentação foi gravada na conferência Unite Seoul em julho de 2026.

Transcrição do vídeo

Palestrantes

• Woojin Park, Gerente de Contas Técnicas, Unity Coreia
• Dr. Hongin Won, Líder da Equipe de Colaboração em IA para Manufatura, Centro de Pesquisa em IA para Manufatura, Instituto Coreano de Tecnologia Industrial (KITECH)
• Jaehoon Hwang, Researcher, KITECH

Tempo de execução: 41 minutos

Sobre esta transcrição: Esta transcrição foi editada para facilitar a leitura.

Introdução: uma cena fabril esquelética que se transformou em um gêmeo digital vivo.

[00:00] Parque Woojin: Hoje, falarei sobre um pipeline de dados sintéticos baseado em gêmeos digitais Unity para IA na manufatura. Meu nome é Woojin Park e sou Gerente de Contas Técnicas na Unity Korea. Na Unity, sou responsável pelo suporte técnico a clientes industriais. Neste projeto, apresentarei o que fizemos ao longo de 14 semanas com a KITECH para apoiar a construção de um gêmeo digital de fábrica.

Se eu tivesse que resumir a apresentação de hoje em uma frase, seria esta. É a jornada de uma fábrica esquelética que se transformou em um gêmeo digital vivo.

[00:51] Vou falar sobre a jornada que o Instituto Coreano de Tecnologia Industrial e a Unity fizeram usando a Unity AI. Primeiramente, apresentarei o Unity AI e os produtos relacionados. Em seguida, abordarei o projeto em si, KITECH VPH-Metal.

Antes de começarmos, deixe-me mostrar o vídeo com o resultado final. A área que você está vendo agora é onde a máquina de moldagem fabrica os moldes de areia. Aqui, os canais de alimentação dos produtos fundidos são removidos, eles passam pela área de desmoldagem e seguem para a área final de retificação e pós-processamento. Ao final desta apresentação, acredito que você entenderá como esta cena foi construída no Unity.

[01:38] Já participei de várias sessões e seminários sobre IA física e tópicos relacionados. Normalmente, nessas sessões, você vê fotos, imagens ou vídeos de fábricas como essa e pensa: "Ok, entendi que é possível construir um gêmeo digital com o Unity ou outra ferramenta." Mas quantas pessoas são realmente necessárias, quanto tempo é preciso para o planejamento e quais ferramentas podem acelerar o processo? Sinceramente, esse tipo de informação costuma ser difícil de encontrar. Hoje, falarei sobre quais produtos utilizamos e como os desenvolvemos, além de como conseguimos acelerar o processo com IA.

O que o Unity AI inclui: Agente, servidor MCP e geradores

[02:23] O Unity AI é composto pelos seguintes elementos. O primeiro é o Unity Agent. Depois, há o Servidor MCP e também os Geradores. Por ora, basta ter em mente esses termos-chave.

O Unity Agent permite que você use IA baseada em Claude, por exemplo, ou Gemini, diretamente dentro do Editor. Quanto ao servidor MCP, muitos ambientes na Coreia funcionam em redes fechadas. Portanto, se sua empresa tiver um agente como o Claude ou o Codex configurado internamente, você poderá conectá-lo por meio do protocolo e usá-lo com o Unity.

Qual é, então, a maior diferença entre o Unity Agent e o MCP Server? O Unity Agent executa, em segundo plano, as funcionalidades que desenvolvemos internamente, cerca de 70 a 80 delas. Assim, pode acelerar ainda mais o desenvolvimento em Unity .

[03:12] O objetivo final da Unity é criar aplicações 3D em tempo real. Ao pensar em um aplicativo 3D em tempo real, você precisa de animação, som, objetos e muitas texturas e imagens. Portanto, não se trata apenas de escrever código. Se você usa o Unity Agent ou o MCP Server, também pode usar os recursos de IA que os geradores produzem para cada tipo de recurso.

Ferramentas da Unity Industry : Asset Manager, Version Control e Asset Transformer

[03:45] Além disso, o Unity Industry inclui o Asset Manager, uma ferramenta para gerenciar ativos, o Version Control, uma ferramenta para gerenciamento de versões, e o Asset Transformer, que prepara seus ativos ou modelos CAD para uso direto na simulação. Essas são as três ferramentas.

Começando sem CAD: da nuvem de pontos à malha

[04:15] Tendo visto a versão final do projeto de hoje, muitos de vocês provavelmente estão se perguntando onde tudo começou. Em projetos como este, as pessoas que possuem dados CAD geralmente importam esses dados para o Unity e dão continuidade ao projeto. Mas não tínhamos um programa CAD para usar como base, então começamos com dados de nuvem de pontos.

Em seguida, convertemos essa nuvem de pontos em malhas simplificadas de baixa poligonagem e, depois disso, usando o Asset Transformer, o Asset Manager, o Unity Version Control, o Unity AI e várias outras ferramentas e pacotes, realizamos o projeto ao longo de 14 semanas. O que você está vendo agora é a nuvem de pontos visualizada no Unity a partir do mesmo ângulo.

[05:04] À esquerda, você tem os recursos e, em seguida, as diferentes ferramentas, como Asset Transformer, Asset Manager, automação, Editor e IA. Explicarei onde cada uma dessas ferramentas foi utilizada. A parte que provavelmente mais lhe interessa é a seção de treinamento, no canto direito, ou a parte de simulação e gêmeo digital. Por fim, explicarei como a nuvem de pontos foi conectada ao Asset Manager da Unity e a saídas como o gêmeo digital.

Asset Transformer: otimizando ativos e preparando-os para simulação.

[05:42] Vamos começar com o Asset Transformer e o Unity AI. As roupas do lado esquerdo estão mudando ligeiramente. Na parte inferior direita, você pode ver a mesma roupa renderizada com 11.000 polígonos e com 1,1 milhão, e como os formatos dos polígonos diferem em cada caso.

O Asset Transformer é uma ferramenta que, quando você tem um arquivo CAD ou um arquivo objeto, permite otimizá-lo e torná-lo mais leve com facilidade. Com as roupas da esquerda, quase não há diferença visível a olho nu. Assim, o Asset Transformer torna o modelo o mais leve possível para o computador renderizar, mantendo qualquer diferença visível ao mínimo.

[06:38] Se você observar os cubos girando na parte inferior, mesmo ao girar cubos com o mesmo código, o cubo branco gira exatamente em torno de seu próprio centro, enquanto o cubo amarelo parece estar girando em torno de algum outro ponto. Na modelagem CAD, isso corresponde ao conceito de origem. Dependendo se essa origem for definida como o que chamamos de centro de massa, o centro da caixa delimitadora ou apenas algum valor aleatório, mesmo que você escreva o código corretamente, o resultado pode ser completamente diferente. Portanto, essas partes precisavam ser corrigidas e aprimoradas, e chamamos esse processo de "preparação para simulação".

[07:26] Na Unity, usamos o Asset Transformer e trabalhamos em conjunto com a KITECH em como realizar a otimização. Nem todas as tarefas funcionaram perfeitamente. No caso da escada, por exemplo, ao mover o pivô, houve um problema em que ela ficou comprimida em linha reta. Neste caso, utilizamos a Unity AI para analisar a causa geométrica real e, em seguida, criamos um conjunto de habilidades que pôde ser aplicado em todo o projeto. Então, escrevemos códigos Markdown de habilidades e os aplicamos a toda a cena da fábrica na KITECH, transformando objetos estáticos como esses em objetos que podiam se mover, e então realizamos a primeira rodada de otimização.

Gerenciando versões no Asset Manager: De 627 arquivos de origem para 218

[08:25] Conforme fomos trabalhando no projeto, primeiro mostramos os dados da nuvem de pontos, depois os dados de baixa poligonagem gerados ao transformá-los em uma malha e, por fim, os dados prontos para simulação que acabamos de mostrar, que foram otimizados e aliviados. Existiam, portanto, essas três versões dos dados. Mas, para ser honesto, provavelmente existiram muito mais versões do que essas. Para evitar confusão com todas essas versões e para obter os dados de que precisávamos no momento certo, o controle de versão foi essencial.

[08:45] Então, a ferramenta que usamos foi o Asset Manager. Em arquivos CAD, normalmente não há suporte para visualização prévia. O CAD tem muitas vantagens, mas os objetos 3D são pesados ​​para renderizar e, sem pré-visualizações, pode ser difícil identificar qual elemento é o necessário.

[09:03] O Asset Manager fornece pré-visualizações para cada objeto. Você pode baixá-los diretamente no Editor ou carregá-los e usá-los imediatamente. Inclui também funcionalidades para conversão para outros formatos ou para otimização automática dos mesmos.

Em vez de simplesmente carregar cada arquivo de modelo um por um, definimos um conjunto de regras e criamos dados AAS baseados em ontologia, e então os carregamos no Asset Manager. Fizemos o upload em diversos formatos, não apenas no formato FBX, que é de uso geral, mas também em USD e outros formatos conforme necessário. Inicialmente, tínhamos um total de 627 arquivos de origem e, após aplicar um padrão único, reduzimos esse número para 218 arquivos, que foram então carregados.

Unity Version Control em URP, HDRP e USD

[10:07] A próxima parte em que trabalhamos foi o controle de versão. Para muitos de vocês, controle de versão provavelmente remete ao Git . Mas com o Git, é basicamente muito difícil gerenciar imagens ou arquivos grandes.

No nosso caso, executamos essa nuvem de pontos no pipeline de renderização URP da Unity e também no HDRP de maior fidelidade. Para manter ambas as versões e adicionar recursos, usamos o Unity Version Control. Ao longo de um período de 14 semanas, separamos as ramificações para URP, HDRP e USD, mantivemos o Editor sob gerenciamento de configuração integrado e lidamos com 77 versões com base em conjuntos de alterações.

Criando o painel de controle em tempo de execução com Unity AI

[11:18] Agora que os recursos estavam prontos e o controle de versão estava implementado, era hora de passar para o desenvolvimento real.

Quando as pessoas dizem pela primeira vez que querem um gêmeo digital, a primeira coisa que pedem é um painel de controle. No passado, construir esse painel significava contratar designers de UI e UX, e desenvolver cada recurso de forma organizada como uma classe, e assim por diante. Era isso que costumava ser necessário.

[11:32] Mas agora, se você fizer uma imagem dos dados que deseja mostrar nesta fábrica, ou fizer uma imagem conceitual, as habilidades dentro do Unity AI são executadas no back-end e transformam isso diretamente em um painel de interface do usuário interativo.

Normalmente, em campo, existem muitos casos em que os dados do PLC não podem ser conectados diretamente. No nosso caso também houve problemas relacionados ao firewall e à segurança, então trabalhamos com os pesquisadores e criamos uma espécie de conjunto de dados fictício de PLC, que depois conectamos ao painel de controle dentro do Unity. Realizamos todo esse processo juntos.

Ferramentas de edição personalizadas para o cenário do ímã.

[12:21] O que fizemos a seguir não foi apenas uma simulação visualmente convincente, mas um projeto genuinamente baseado em fatos. Após a criação do painel de controle em tempo de execução, também precisamos criar um painel de controle ou um editor personalizado dentro do próprio Editor.

Nessa fábrica, o primeiro cenário envolvia um ímã em movimento que utilizava a força magnética para atrair objetos. Para simular quanta força magnética é necessária para que pedaços de metal sejam atraídos ou não, em vez de codificar cada valor diretamente no código, nós os expusemos diretamente no Editor. Assim, elementos como o estado de cada carrinho e o estado do ímã, e até mesmo o comportamento da simulação física, foram todos desenvolvidos usando a Unity AI.

Criando o efeito de forno a partir de uma imagem conceitual.

[13:21] A próxima coisa sobre a qual falarei é o efeito de fornalha. Alguns de vocês podem estar pensando que precisam de efeitos visuais.

Uma das funcionalidades mais poderosas do Unity AI e do MCP é a capacidade de capturar a Scene View ou a Game View. Ao trabalhar em um projeto, assim como um telefone aplica correção de cores, as cores podem parecer diferentes dentro do Unity Editor ou da Game View. Para criar o impacto desejado com essas cores, você precisa de elementos como combinações de cores. No passado, essa era uma área que os artistas tinham que dominar.

[14:01] Mas agora você pode dizer à IA: "Crie quatro esferas na cena, aplique um efeito de forno a elas e continue atualizando até que fique o mais próximo possível do conceito ou da imagem conceitual que eu lhe der." A Unity AI encontra e cria o efeito mais adequado, aplicando-o à cena em si, tudo de uma só vez.

Convertendo URP para HDRP

[14:24] Depois disso, uma vez que criamos a versão URP, convertemos para HDRP. Durante o processo de conversão de URP para HDRP, eu estava ocupado com outra coisa e forneci à IA as configurações gráficas, conceitos e outros detalhes que eu havia preparado. As imagens que você vê aqui são o resultado da IA ​​aprimorando-as passo a passo ao longo do tempo para corresponder à imagem conceitual.

[14:51] No início, ou era uma tela preta ou excessivamente brilhante. Em seguida, voltou ao original, ficou um pouco mais brilhante e passou por essas etapas sozinha, de modo que a cena da fábrica continuou sendo atualizada. Foi melhorando gradualmente e, no final, posso dizer que se tornou a cena HDRP refinada que eu tinha em mente.

Exportação de USD em tempo de execução

[15:18] A última coisa que vou mencionar é que não paramos no URP e no HDRP. Também trabalho com projetos de gêmeos digitais para outras grandes empresas, e o que elas mais costumam dizer é: "Outras equipes ou outros departamentos da nossa empresa querem usar esses dados bem organizados e prontos para simulação em outras ferramentas ou em outras plataformas."

[15:44] Então, o que fizemos foi habilitar a exportação em USD em tempo de execução. Exportar em tempo de execução significa que, durante a execução de uma simulação, você pode alterar o layout até certo ponto, salvá-lo e exportar esse estado exato no formato USD. Dessa forma, em outra plataforma, as texturas, a geometria e tudo o mais podem ser preservados exatamente como estão e usados ​​imediatamente.

Alimentando os gêmeos em modelos mundiais

[16:18] Depois de ter um gêmeo digital como este, não se trata apenas de conectar as coisas e observar um painel de controle. Também quero falar sobre o assunto mais comentado da atualidade: modelos mundiais.

Com modelos de mundo como FLUX, Qwen ou NVIDIA Cosmos 3, você pode pegar a tela do gêmeo digital que construiu no Unity, inserir essa tela ou imagem e, a partir daí, mostrar coisas como o envelhecimento da fábrica, o vapor saindo, cenários de simulação para realidade ou até mesmo mudanças na hora do dia. Conseguimos obter diversos conjuntos de dados para essas áreas.

Resultados do projeto em números

[16:55] Para apresentar nossos resultados em números: o projeto durou 14 semanas desde o início. Organizamos 627 ativos, reduzindo-os a 218. Realizamos 77 commits de código-fonte e passamos de nuvens de pontos até o HDRP. Dos 39 conjuntos de dados que tínhamos, visualizamos 20 deles. Posteriormente, realizamos o aumento de dados com base em mais de 10 modelos mundiais baseados em princípios da física.

Comparação lado a lado e a lacuna no domínio da manufatura

[17:27] Fizemos um vídeo de comparação final. Aqui você pode ver primeiro a nuvem de pontos, depois o URP no meio e, por fim, o HDRP. Em seguida, realizamos difusão, simulação de modelo do mundo e aumento de dados.

Há um aspecto que eu gostaria de destacar neste processo. Modelos treinados com dados gerais têm pouca compreensão dos dados do domínio da manufatura. Por isso, dedicamos bastante tempo a estudar como colmatar essa lacuna de dados no domínio da produção. Esta parte será explicada a seguir pelo Dr. Hongin Won.

Gostaria de agradecer ao Dr. Hongin Won, o pesquisador Youngseok Han, o pesquisador Jaehoon Hwang e muitos outros que trabalharam neste projeto conosco.

KITECH: transformando um gêmeo digital em um ambiente onde a IA pode aprender

[18:47] Dr. Hongin Won: Meu nome é Hongin Won e sou do Instituto Coreano de Tecnologia Industrial.

Anteriormente, o gerente Woojin Park explicou como construir e expandir um gêmeo digital de uma fábrica no Unity, especificamente para uma fundição. Como próximo passo, falarei sobre como transformar esse gêmeo digital em um ambiente onde a IA possa aprender e ser testada.

O título da apresentação de hoje é um pipeline de dados sintéticos baseado em gêmeos digitais Unity para IA na manufatura. Como o título menciona um pipeline de dados sintéticos, você pode estar pensando: "Mas como exatamente eles sintetizam os dados?" Mas antes disso, a questão mais importante é: "O gêmeo digital foi realmente construído para corresponder ao sistema real?" Gostaria de me concentrar um pouco mais em como verificamos exatamente isso. Chamamos o processo de construção de um modelo de gêmeo digital que corresponda à realidade de "ancoragem", e explicarei isso a partir dessa perspectiva.

Direção da equipe e da pesquisa

[19:49] Sou Hongin Won e lidero a Equipe de Colaboração em IA para Manufatura no Centro de Pesquisa em IA para Manufatura da KITECH. Minhas áreas de especialização são IA para manufatura, gêmeos digitais e infraestrutura de dados industriais. Em particular, minha área de interesse em gêmeos digitais é a virtualização, ou seja, como transferir problemas do mundo real para um ambiente virtual; a geração, ou seja, como criar os dados necessários dentro desse ambiente; e a validação, ou seja, como trazer os resultados de volta para a verificação no mundo real.

[20:18] Os principais pesquisadores que participaram deste projeto são o pesquisador Jaehoon Hwang e o pesquisador Seungyeop Ha do nosso centro. O pesquisador Jaehoon Hwang foi responsável por medir e corrigir as diferenças restantes após a transferência dos sensores do ambiente real para o robô gêmeo, enquanto o pesquisador Seungyeop Ha cuidou da simulação e do movimento humano-robô, além de expandir os dados para uma ampla gama de condições.

[20:48] Nossa linha de pesquisa para a fabricação de gêmeos digitais se resume a uma única frase: gêmeos digitais para IA, IA para gêmeos digitais. Significa criar ambientes onde a IA possa aprender e ser testada, e usar a IA para reconstruir e atualizar gêmeos digitais. Também estamos pesquisando gêmeos digitais avançados baseados em sistemas multiagentes e LLMs (Modelos de Aprendizado de Máquina).

[21:09] Aqui está um pequeno vídeo sobre os modelos que o nosso centro construiu. O vídeo apresenta modelos que transformam linhas de montagem de veículos elétricos, logística urbana, fundições e muito mais em estruturas idênticas, conectando-as em uma única cadeia de suprimentos. Usamos bastante o simulador Unity , mas, nos bastidores, também modelamos cenários com simulações mais leves, e os resultados dessas simulações são então integrados a um pipeline do Unity . Essa é uma das principais linhas de nossa pesquisa.

[21:48] O vídeo também apresenta as tecnologias de simulação e validação desenvolvidas lá, incluindo fusão de sensores e estudos onde agentes baseados em LLM planejam trajetórias de robôs. Inclui também um exemplo de planejamento de trajetórias de robôs usando os recursos do Unity MCP.

Colaboração humano-robô e por que os dados de HRC são escassos.

[22:09] O tema de hoje é a construção de ambientes onde a IA possa aprender e ser testada. O cenário abordado nesta apresentação é o de uma fábrica onde humanos e robôs colaboram. Um ambiente onde humanos e robôs trabalham juntos no mesmo espaço é chamado de colaboração humano-robô, ou HRC.

[22:25] Quanto ao fluxo da apresentação, primeiro falarei sobre por que esse tipo de dados HRC é tão escasso no mundo real e por que ainda precisamos incorporá-lo completamente ao modelo de gêmeo digital. Em seguida, apresentarei a abordagem que adotamos para superar esse problema, bem como os métodos de síntese de dados que desenvolvemos. E ao construir um modelo de gêmeo digital, muitas partes não correspondem exatamente ao mundo real. Em outras palavras, ocorre uma discrepância entre o cenário real e a simulação, e também explicarei como calibramos e resolvemos essa discrepância.

[23:02] Vamos começar com o problema dos dados. Como todos sabem, a IA aprende com os dados. Mas alguns campos têm muitos dados disponíveis, enquanto outros não. Por exemplo, na condução autônoma, podemos obter facilmente milhões de quilômetros de registros de direção e, para dados de visão em geral, podemos extrair imagens e vídeos da internet ou do cotidiano. Os modelos de linguagem também podem usar dados de toda a internet para treinamento.

Mas, para locais de produção, especialmente para humanos e robôs trabalhando juntos, precisamos de dados sobre quando os trabalhadores se aproximam demais dos robôs, quando partes do corpo ficam obstruídas ou quando as pessoas entram e saem das zonas de segurança. Esse tipo de dado é extremamente difícil de encontrar em conjuntos de dados públicos.

Quatro razões para a escassez de dados

[23:54] Identificamos quatro razões para esta escassez de dados nos locais de produção.

Em primeiro lugar, a segurança. O momento em que uma pessoa entra na zona de perigo de um robô não é algo que se possa encenar repetidamente apenas para coletar dados.

Em segundo lugar está o custo. Montar uma linha de pesca real, instalar sensores e filmar durante mudanças de condições exige muito tempo e dinheiro.

A terceira parte foi aquela com a qual tivemos mais dificuldade: a rotulagem. Para o treinamento de IA, anotações e rótulos são necessários para criar a verdade fundamental. Mas alinhar as posições 3D de humanos e robôs, distâncias, informações de articulações, planos de fundo, objetos e regiões em nível de pixel em vários sensores ao mesmo tempo equivalia a puro trabalho manual.

[24:36] O último é a raridade. Para ser mais preciso, trata-se da raridade do cenário. É extremamente difícil obter dados sobre colisões entre pessoas e robôs em instalações de produção. Situações imediatamente anteriores a uma colisão são chamadas de eventos de cauda longa. Essas situações quase nunca acontecem na realidade e são extremamente difíceis de criarmos artificialmente. E em um site bem administrado, esses dados deveriam ocorrer com menos frequência, e não mais.

Dados de proximidade: o que realmente precisamos para treinar

[25:16] O que queríamos treinar não era simplesmente se uma pessoa está presente ou não, mas a que distância a pessoa está do robô, em que direção e em que postura ela está se aproximando. Esse tipo de informação é o que chamamos de dados de proximidade. Precisamos entender essa relação para que humanos e robôs possam colaborar e definir zonas seguras e, no caso dos robôs, para monitorar a proximidade de uma pessoa ou criar cenários em que eles possam diminuir a velocidade e parar.

[25:43] Resumindo, a situação era a seguinte. Havia muito poucos dados. Portanto, se não pudermos coletar, vamos gerar. Foi isso que nos propusemos a fazer. Mas para gerar dados, o modelo que realiza a geração precisa de dados sólidos próprios. Primeiramente, utilizamos como referência valores medidos no mundo real e construímos um pipeline de dados sintéticos de gêmeo digital na Unity .

Por que escolhemos o Unity: quatro tecnologias em um único ambiente de execução.

[26:09] Achamos que era relativamente fácil conectar quatro tecnologias em um único ambiente de execução, então usamos o Unity.

A primeira é a simulação física, onde robôs, pessoas e objetos interagem de uma forma fisicamente válida. Em segundo lugar está a renderização HDRP , que ajusta a iluminação, os materiais e outros elementos à realidade, a fim de reduzir a discrepância entre os domínios. Em terceiro lugar está a simulação de sensores, que reproduz virtualmente vários tipos de sensores. Em quarto lugar, estão as tecnologias aplicadas que geram dados a partir do gêmeo digital, permitindo que a anotação e a rotulagem sejam realizadas sem que seja necessário que pessoas marquem tudo manualmente.

[26:48] Se estes quatro tivessem permanecido separados, não teríamos conseguido produzir dados para o treino de IA. Ao integrá-los no mesmo ambiente de execução e no mesmo eixo temporal, conseguimos gerar os dados de que precisávamos.

O conjunto de dados Industrial HRC-Bench

[27:03] O processo de obtenção desses dados de treinamento teve que seguir uma metodologia profissional e confiável para a construção de conjuntos de dados. Para isso, contamos com a participação de especialistas da área de manufatura e, em conjunto, desenvolvemos cenários reais de colaboração entre humanos e robôs. Criamos um ambiente experimental de referência no Centro de Testes e Certificação de Robôs do Laboratório de Testes da Coreia.

[27:33] Como resultado desses experimentos, construímos o conjunto de dados Industrial HRC-Bench. Os cenários HRC coletados até o momento, em um nível pronto para divulgação pública, são de dois tipos: paletização e inspeção de peças de produção. O conjunto de dados consiste em um total de 17 episódios. Destes, nove foram realizados com humanos e robôs trabalhando juntos, e os oito restantes apenas com o robô.

[28:02] O sistema de sensores usado aqui integra câmeras RGB , LiDAR, vídeo de 360 ​​graus e um sistema de captura de movimento. Todas essas modalidades de sensores foram sincronizadas a 20 Hz, o que nos forneceu mais de 100.000 quadros de dados brutos. Calculando em termos de tempo puro, isso corresponde a mais de 80 minutos.

O que nos importava aqui não era apenas a escala dos dados, mas também a sua estrutura. Todos esses dados compartilhavam o mesmo eixo temporal para observações e rótulos, o que possibilitou uma comparação precisa e a geração de dados significativos. Planejamos disponibilizar em breve o conjunto de dados Industrial HRC-Bench através do Hugging Face ou de um repositório externo.

O pipeline em três palavras: aterramento, calibração, geração.

[28:53] Acho que o fluxo geral pode ser resumido em três palavras: terra, calibrar, gerar.

A primeira não é simplesmente criar um gêmeo digital, mas sim ancorar nele valores mensurados no mundo real. Isso é o que nos conecta com a realidade, alinhando o gêmeo com ela. Em seguida, vem a calibração, que reduz a diferença entre o cenário real e o simulado. E a partir daí, inicia-se a fase de geração de dados.

Fundamentação: ambiente, sensores, robôs e rótulos

[29:35] Jaehoon Hwang: Meu nome é Jaehoon Hwang e eu fui o responsável pela implementação da conversão do mundo real para a simulação. Na fase de contextualização, trouxemos quatro elementos da realidade: o ambiente, os sensores, os robôs e as etiquetas.

Ambiente

[29:49] Medimos as dimensões espaciais e o layout dos principais equipamentos do banco de testes KTL e, com base nesses valores, combinamos os equipamentos e as áreas de trabalho um a um dentro do Unity. Além disso, aplicamos o HDRP para que os materiais e a iluminação correspondessem ao ambiente real. Para o plano de fundo, utilizando imagens panorâmicas de 360 ​​graus capturadas no local, construímos uma cena de dispersão gaussiana 3D fotorrealista para reduzir a diferença entre a realidade e a simulação.

Nosso objetivo final era criar uma célula de referência onde a estrutura e as oclusões captadas pela câmera, a posição dos objetos em relação uns aos outros e a influência da luz e dos materiais no que é observado pudessem ser comparadas lado a lado com o mundo real. Na imagem na tela, o lado esquerdo representa a cena real, e o lado direito representa a réplica digital do mesmo ponto de vista.

Plataforma de sensores

[30:34] Para o experimento, usamos câmeras RGB e de profundidade, LiDAR, uma câmera de 360 ​​graus, captura de movimento e dados dos estados dos dois robôs. Dentro do ambiente virtual que construímos, não simplificamos isso a uma única câmera. Após verificarmos onde cada sensor estava instalado na plataforma real e o que ele observava, construímos sensores virtuais com a mesma estrutura.

[30:59] Dentro do ambiente de execução Unity , criamos componentes de sensores personalizados para que todas as observações compartilhassem o mesmo relógio de simulação. Também conectamos os estados do robô e os movimentos humanos para que ficassem sincronizados no mesmo instante. A razão pela qual essa sincronização é importante é que a proximidade não pode ser resumida com apenas uma única imagem. Ao mesmo tempo, vídeo, profundidade, articulações do robô e pose humana precisam coexistir para calcular a distância e as zonas de segurança de forma consistente.

Robô

[31:27] Tínhamos um padrão. Tinha que ser um movimento fisicamente válido, não um movimento que apenas parecesse plausível. Importamos trajetórias conjuntas gravadas no ambiente de teste real e as configuramos para serem reproduzidas quadro a quadro em sua ordem temporal original. Utilizando o Articulation Body do Unity, configuramos as ligações e juntas do robô, os graus de liberdade e a estrutura física, e então executamos os estados articulares gravados sobre essa configuração. Como a inércia e o contato são calculados em conjunto, conseguimos lidar com a interação entre o movimento do robô e os objetos ao redor dentro de uma única estrutura física.

Etiquetas

[32:02] A partir do mesmo estado de simulação, quatro tipos de informações de verdade fundamental são gerados simultaneamente: Caixas delimitadoras 2D e 3D com as posições de pessoas, robôs e peças; segmentação semântica e de instância que separa objetos no nível do pixel; coordenadas articulares usadas para estimativa de pose; e dados de profundidade reais usados ​​como referência para distância de proximidade. A tela exibe uma cena com caixas delimitadoras 3D aplicadas.

Essas etiquetas não foram produzidas por alguém que marcou cada quadro à mão. Eles vêm diretamente do estado de simulação do Unity . Isso reduz simultaneamente o custo da rotulagem e o erro de anotação.

A diferença entre a realidade e a simulação na câmera

[32:52] Em seguida, explicarei a discrepância entre o real e o simulado que encontramos ao construir o modelo de gêmeo digital e como a resolvemos. Essas são as lacunas residuais, as diferenças entre o real e o virtual que permanecem mesmo após a transferência. Entre eles, identificamos dois fatores que afetam diretamente os valores de proximidade e a fonte de dados reais.

A primeira ocorreu na câmera. Ao construir o ambiente virtual, definimos o mesmo modelo de sensor e o mesmo campo de visão tanto para as configurações reais quanto para as virtuais. Mas o mesmo objeto não apareceu nos mesmos pixels.

[33:20] Se você olhar para a sobreposição de borda à direita, poderá ver que os limites da mesma estrutura estão ligeiramente desalinhados dependendo da posição. Nem mesmo aplicar a ficha técnica real da lente ao ambiente Unity resolveu o problema. Isso ocorre porque as especificações do produto e os modelos de lentes padrão, por si só, não conseguem explicar as diferenças resultantes do ângulo de instalação e de cada lente.

Na HRC, mesmo um desalinhamento tão pequeno quanto esse faz diferença. Se a fronteira entre uma pessoa e um robô se deslocar por apenas alguns pixels, a correspondência entre os rótulos de pixels gerados na simulação e as observações reais também se torna instável. Por isso, decidimos medir diretamente o resíduo da câmera exata instalada nesta plataforma de testes.

Medir a distorção da lente em vez de modelá-la.

[34:01] O método que escolhemos é simples. Não modele a lente diretamente. Meça.

Este processo consiste em três etapas. Primeiramente, utilizando uma visão gaussiana 3D gerada a partir de múltiplos pontos de vista, obtivemos cenas correspondentes nos ambientes real e virtual. Em seguida, calculamos as diferenças entre essas imagens emparelhadas no nível do pixel e as registramos como um mapa de distorção por pixel. Por fim, aplicamos esse mapa ao shader de distorção da câmera do Unity para que a câmera virtual seja corrigida durante o processo de renderização da imagem.

[34:35] A chave é este loop. Criamos cenas correspondentes, medimos a diferença restante e enviamos esse valor de volta para o ambiente de execução do Unity .

Eis o resultado. À esquerda está a observação do sensor real, no centro está o gêmeo digital corrigido e à direita está a sobreposição das bordas das duas imagens. Observe as linhas de demarcação à direita e você poderá notar uma melhora significativa em relação ao período anterior. Ao aplicar um mapa de distorção específico, conseguimos confirmar que o alinhamento de pixels entre as imagens reais e virtuais melhorou adequadamente.

[35:09] Isto não é pós-processamento externo, mas um componente que é executado quando a câmera virtual gera imagens, para que as observações corrigidas e a verdade fundamental possam ser produzidas no mesmo ambiente de execução.

Corrigindo movimentos humanos instáveis ​​com cinemática inversa.

[35:16] O segundo problema surgiu no movimento humano. A tela mostra movimentos humanos gravados por meio de captura de movimento, reproduzidos com marcadores e um esqueleto. Esta é uma seção onde parte do corpo foi ocultada pelo robô e pela bancada durante a captura da imagem. Observe como as articulações do pé começam a tremer. À medida que a oclusão aumenta, as estimativas das articulações ocultas tornam-se instáveis, fazendo com que o pé deslize no chão e as articulações se movam para posições fisicamente impossíveis.

[35:47] Essa vibração distorce diretamente a distância entre o humano e o robô, a proximidade de cada parte do corpo e as etiquetas da zona de segurança. Assim, também aplicamos restrições físicas ao movimento humano. Esses são os movimentos do chão e das articulações.

Esta é a mesma cena de antes. Desta vez, há apenas duas coisas a observar. O pé permanece em contato com o chão e as articulações mantêm sua posição natural?

[36:14] Primeiro, com o Foot IK, reconectamos o pé à geometria real do piso medida. Em seguida, usando a cinemática inversa humanoide (Humanoid IK), restringimos as articulações ocluídas para que se movessem dentro de limites articulares válidos. O IK recalcula as posições das articulações intermediárias, com base nas posições alvo das mãos ou dos pés. Esta correção visa reduzir movimentos não físicos que interferem na leitura das etiquetas de proximidade e segurança.

Reprodução do cenário: paletização e inspeção de peças

[36:40] Dr. Hongin Won: Gostaria de agradecer ao pesquisador Jaehoon Hwang por apresentar as principais tecnologias para reduzir a discrepância entre a realidade e a simulação, desde a construção de dutos até a correção de sensores e cinemática inversa. Vou mostrar brevemente como o modelo digital que construímos se comporta e, em seguida, concluiremos nossa apresentação.

[37:21] Os dois cenários que construímos como modelos digitais são baseados no mesmo ambiente HRC, mas diferem nas características das tarefas. A primeira é a paletização e a segunda é a inspeção de superfície. Ambos foram concebidos como cenários que poderiam plausivelmente ocorrer em uma unidade fabril. Divulgaremos os detalhes específicos separadamente mais adiante no resumo.

[37:44] Este é o caso da paletização. No modelo de paletização, o que registramos anteriormente do robô real por meio do Corpo Articulado é integrado a este modelo de gêmeo digital. Como você acabou de ver, dois tipos de dados de sensores, informações sobre o estado do robô, máscaras de instâncias e máscaras de segmentação, são todos sincronizados e reproduzidos simultaneamente.

[38:10] O segundo é um cenário para inspeção de peças. A situação de contato próximo entre o trabalhador e o robô também é modelada e está muito bem sincronizada com a simulação e os dados do robô, de modo que podemos reproduzir dados nos quais todos os quatro elementos estão presentes. Se você observar atentamente, mesmo quando a pessoa se sobrepõe a uma parte, poderá ver que a segmentação funciona muito bem.

[38:41] O valor deste pipeline de dados não se limita à construção de um conjunto de dados único. Também pode ser expandido e reproduzido em muitos outros locais industriais.

Randomização de domínio com o pacote Unity Perception

[39:15] O que mostramos anteriormente não é tanto um conjunto de dados único, mas sim um pipeline de dados generativo que pode expandir continuamente os dados. Com base no pacote Unity Perception, construímos um modelo de randomização de domínio e definimos intervalos de parâmetros e regras de amostragem para iluminação, materiais, câmeras e assim por diante, de modo que variações realistas sejam geradas em torno dessa linha de base precisamente alinhada.

Resumo e encerramento do sistema

[39:39] Acho que podemos resumir tudo com esta figura. Esta é a estrutura do sistema como um todo. À esquerda estão os objetos-alvo, o movimento humano, as trajetórias do robô e assim por diante. São elementos de entrada que podem ser trocados a qualquer momento, sendo o centro o núcleo.

[39:53] Um modelo de base que define a linha de base usando medições do local real, um modelo de calibração que corrige erros por tarefa e, à direita, um modelo que extrai automaticamente dados de verdade terrestre multimodais, o modelo de geração. Esses são os três que construímos.

Mostramos como criamos um gêmeo digital baseado no ambiente de teste real e calibramos as principais diferenças entre as tarefas, até a geração de dados sincronizados.

[40:29] Os dados que mostramos hoje foram HRC, mas na verdade, apresentamos como uma aplicação para provar os princípios de design do nosso pipeline. Na era vindoura das fábricas de IA, onde robôs e humanoides podem coexistir, acreditamos que nosso sistema pode servir como camada de simulação e dados.

Nossos agradecimentos ao Centro de Testes e Certificação de Robôs da KTL, que forneceu o ambiente de testes e realizou os experimentos conosco, e à Unity Technologies, que esteve conosco desde o início e nos apoiou integralmente.