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

Dans cette présentation enregistrée, le Dr. Hongin Won, qui dirige l'équipe de collaboration sur l'IA de la fabrication au Korea Institute of Industrial Technology (KITECH), et Woojin Park, responsable de compte technique chez Unity Korea, présentent un projet de 14 semaines qui a transformé une fonderie en un jumeau numérique. Ils expliquent comment l'équipe a construit la scène à partir de données de nuage de points sans utiliser de CAO avec Unity Industry, comment ils ont utilisé Unity AI pour accélérer l'optimisation et le travail d'interface utilisateur, et comment ils ont transformé le jumeau numérique en un pipeline de données synthétiques qui entraîne l'IA sur la collaboration homme-robot.

Ce que vous apprendrez

• Comment le jumeau numérique de la fonderie de moulage en métal a été construit à partir de données de nuage de points, sans fichiers sources CAO
• Où Unity AI, Asset Manager, Asset Transformer, et Version Control s'intègrent-ils dans un pipeline de production
• Comment ancrer un jumeau numérique par rapport aux mesures du monde réel, et calibrer les écarts qui subsistent
• Comment générer automatiquement des données d'entraînement étiquetées au lieu d'annoter les images manuellement

Cette présentation a été enregistrée lors de la conférence Unite Seoul en juillet 2026.

Transcription vidéo

Intervenants

• Woojin Park, Responsable de compte technique, Unity Corée
• Dr. Hongin Won, Chef de file, Équipe de collaboration IA de fabrication, Centre de recherche IA de fabrication, Korea Institute of Industrial Technology (KITECH)
• Jaehoon Hwang, Researcher, KITECH

Exécution 41 minutes

À propos de cette transcription: Cette transcription a été éditée pour la lecture.

Introduction : une scène d'usine squelettique qui est devenue un jumeau numérique vivant

[00:00] Woojin Park: Aujourd'hui, je vais parler d'un pipeline de données synthétiques basé sur un jumeau numérique Unity pour l'IA manufacturière. Je suis Woojin Park, responsable de compte technique chez Unity Corée. Chez Unity, je suis responsable du support technique pour les clients industriels. Dans ce projet, je présenterai ce que nous avons fait au cours des 14 semaines avec KITECH pour soutenir la construction d'un jumeau numérique d'usine.

Si je devais résumer la présentation d'aujourd'hui en une seule phrase, ce serait celle-ci. C'est le voyage d'une scène d'usine squelettique qui est devenue un jumeau numérique vivant.

[00:51] Je vais parler du parcours que le Korea Institute of Industrial Technology et Unity ont suivi en utilisant Unity AI. Je présenterai d'abord Unity AI et les produits associés. Puis je me tournerai sur le projet lui-même, KITECH VPH-Metal.

Avant de commencer, laissez-moi vous montrer la vidéo du résultat final. La zone que vous voyez maintenant est là où la machine de moulage fabrique les moules de sable. Ici, les produits moulés ont leurs supports retirés, passent par la zone de dégauchissage et passent à la zone de meulage final et de post-traitement. Au moment où cette présentation sera terminée, je pense que vous comprendrez comment cette scène a été construite dans Unity.

[01:38] J'ai assisté à de nombreuses sessions et séminaires sur l'IA physique et les sujets connexes. Habituellement, dans ces sessions, vous voyez des photos, des images ou des vidéos d'usines comme celle-ci, et vous pensez : « D'accord, je comprends que vous pouvez construire un jumeau numérique avec Unity ou un autre outil. » Mais combien de personnes cela demande-t-il réellement, combien de temps faut-il pour planifier, et quels outils peuvent accélérer le processus ? Honnêtement, ce genre d'informations est généralement difficile à trouver. Aujourd'hui, je vais parler des produits que nous avons utilisés et de la manière dont nous l'avons construit, ainsi que de la façon dont nous avons pu accélérer le processus avec l'IA.

Ce que Unity AI inclut : Agent, Serveur MCP et Générateurs

[02:23] Unity AI est composé de ce qui suit. Le premier est Unity Agent. Il y a ensuite le serveur MCP, et aussi les générateurs. Pour l'instant, il suffit de garder ces termes clés à l'esprit.

Unity Agent vous permet d'utiliser l'IA basée sur Claude, par exemple, ou Gemini, directement dans l'Éditeur. Quant au serveur MCP, de nombreux environnements en Corée fonctionnent sur des réseaux fermés. Donc, si votre entreprise dispose d'un agent comme Claude ou Codex configuré en interne, vous pouvez le connecter via le protocole et l'utiliser avec Unity.

Quelle est donc la plus grande différence entre Unity Agent et MCP Server ? L'agent Unity exécute les compétences que nous avons construites nous-mêmes, environ 70 à 80 d'entre elles, en arrière-plan. Ainsi, cela peut accélérer le développement Unity encore plus loin.

[03:12] Ce que Unity vise en fin de compte, ce sont les applications en temps réel en 3D. Lorsque vous pensez à une application en temps réel en 3D, vous avez besoin d'animation, vous avez besoin de son, vous avez besoin d'objets et vous avez besoin de beaucoup de textures et d'images. Donc, il ne s'agit pas seulement d'écrire du code. Si vous utilisez Unity Agent ou MCP Server, vous pouvez également utiliser les actifs IA que les Générateurs produisent pour chaque type d'actif.

Outils Unity Industry : Asset Manager, Version Control et Asset Transformer

[03:45] De plus, Unity Industry comprend Asset Manager, un outil de gestion d'actifs, Version Control, un outil de gestion de version, et Asset Transformer, qui prépare vos actifs ou modèles CAO pour une utilisation directe dans la simulation. Ce sont les trois outils.

Commencer sans CAO : du nuage de points au maillage

[04:15] Ayant vu la version finale du projet d'aujourd'hui plus tôt, beaucoup d'entre vous se demandent probablement où tout a commencé. Dans des projets comme celui-ci, les personnes qui possèdent des données CAO importent généralement ces données CAO dans Unity et poursuivent le projet. Mais nous n'avions pas de CAO à partir de laquelle travailler, nous avons donc commencé à partir de données de nuage de points.

Nous avons ensuite converti ce nuage de points en maillages simplifiés low-poly, et après cela, en utilisant Asset Transformer, Asset Manager, Unity Version Control, Unity AI et un certain nombre d'autres outils et paquets, nous avons mené le projet pendant 14 semaines. Ce que vous voyez maintenant est le nuage de points visualisé dans Unity sous le même angle.

[05:04] À gauche, vous avez les assets, puis les différents outils, tels que Asset Transformer, Asset Manager, automatisation, Éditeur et IA. J'expliquerai où chacun de ces outils a été utilisé. La partie qui vous intéresse probablement le plus est la section de formation tout à droite, ou la partie simulation et jumeau numérique. Finalement, j'expliquerai comment le nuage de points a été connecté à l'Asset Manager d'Unity et à des sorties telles que le jumeau numérique.

Asset Transformer : optimiser les actifs et les rendre prêts pour la simulation

[05:42] Commençons par Asset Transformer et Unity AI. Le vêtement à gauche change légèrement. En bas à droite, vous pouvez voir le même vêtement rendu à 11 000 polygones et à 1,1 million, et comment les formes des polygones diffèrent dans chaque cas.

Asset Transformer est un outil qui, lorsque vous avez un fichier CAO ou un fichier d'objet, vous permet de l'optimiser et de l'alléger facilement. Avec le vêtement à gauche, il n'y a presque aucune différence visible à l'œil nu. Ainsi, Asset Transformer rend le modèle aussi léger que possible pour que l'ordinateur puisse le rendre, tout en gardant la différence visible au minimum.

[06:38] Si vous regardez les cubes qui tournent en bas, même lorsque les cubes avec le même code tournent, le cube blanc tourne vers la droite autour de son propre centre, tandis que le cube jaune semble tourner autour d'un autre point. En modélisation CAO, cela correspond au concept d'origine. Selon que cette origine est définie sur ce que nous appelons le centre de masse, le centre de la boîte englobante, ou juste une valeur aléatoire, même si vous écrivez le code correctement, le résultat peut être complètement différent. Donc ces parties ont dû être corrigées et améliorées, et nous avons appelé ce processus « prêt pour la simulation ».

[07:26] Chez Unity, nous avons utilisé Asset Transformer et travaillé avec KITECH sur la manière d'effectuer l'optimisation. Toutes les tâches n'ont pas fonctionné parfaitement. Dans le cas de l'échelle, par exemple, lors du déplacement du pivot, il y avait un problème où il se compressait en une ligne droite. Dans ce cas, nous avons utilisé Unity AI pour analyser la cause géométrique réelle, puis nous avons créé un ensemble de compétences qui pouvait être appliqué à l'ensemble du projet. Nous avons donc rédigé des descriptions de compétences et les avons appliquées à toute la scène d'usine chez KITECH, transformé des objets statiques comme ceux-ci en objets pouvant bouger, puis effectué la première série de travaux d'optimisation.

Gérer les versions dans Asset Manager : 627 fichiers sources réduits à 218

[08:25] Au fur et à mesure que nous avons travaillé sur le projet, ce que nous vous avons montré en premier était les données de nuage de points, puis les données low-poly qui ont été générées en le transformant en maillage, et les données prêtes pour la simulation que nous venons de montrer, qui avaient été optimisées et allégées. Il y avait donc ces trois versions des données. Mais pour être honnête, il y avait probablement beaucoup plus de versions que ça. Pour éviter d'être confus par toutes ces versions, et pour extraire les données dont nous avions besoin au bon moment, le Version Control était essentiel.

[08:45] Donc l'outil que nous avons utilisé était Asset Manager. Avec les fichiers CAO, les aperçus ne sont normalement pas pris en charge. Le CAO a de nombreux avantages, mais les objets 3D sont lourds à rendre, et sans aperçus, il peut être difficile de savoir quel actif est celui dont vous avez besoin.

[09:03] L'Asset Manager fournit des aperçus pour chaque objet. Vous pouvez les télécharger directement dans l'Éditeur, ou les télécharger et les utiliser immédiatement. Il comprend également des fonctionnalités pour convertir dans d'autres formats, ou les optimiser automatiquement.

Plutôt que de télécharger chaque fichier de modèle un par un, nous avons défini un ensemble de règles et créé des données AAS basées sur une ontologie, puis nous les avons téléchargées dans Asset Manager. Nous avons téléchargé dans une gamme de formats, pas seulement le FBX polyvalent, mais aussi le USD, et d'autres formats si nécessaire. Nous avions initialement un total de 627 fichiers sources, et après avoir appliqué une seule norme, nous les avons réduits à 218 fichiers et les avons téléchargés.

Unity Version Control à travers URP, HDRP et USD

[10:07] La prochaine partie sur laquelle nous avons travaillé était le Version Control. Pour beaucoup d'entre vous, le Version Control évoque probablement Git. Mais avec Git, il est fondamentalement très difficile de gérer des images ou de gros fichiers.

Dans notre cas, nous avons exécuté ce nuage de points dans le pipeline de rendu URP d'Unity, et nous l'avons également exécuté dans le HDRP à plus haute fidélité. Donc, pour maintenir les deux versions et ajouter des fonctionnalités, nous avons utilisé Unity Version Control. Sur la période de 14 semaines, nous avons séparé les branches pour URP, HDRP et USD, maintenu l'Éditeur sous gestion de configuration intégrée et géré 77 versions basées sur des changements.

Construire le tableau de bord d'exécution avec Unity AI

[11:18] Maintenant que les ressources étaient prêtes et que le Version Control était en place, il était temps de passer au développement réel.

Quand les gens disent pour la première fois qu'ils veulent un jumeau numérique, la première chose qu'ils demandent est un tableau de bord. Par le passé, construire ce tableau de bord signifiait faire appel à des concepteurs UI et UX, et construire chaque fonctionnalité proprement comme une classe, et ainsi de suite. C'est ce qu'il fallait autrefois.

[11:32] Mais maintenant, si vous faites une image des données que vous voulez montrer dans cette usine, ou si vous faites une image conceptuelle, les compétences à l'intérieur de Unity AI fonctionnent en arrière-plan, et cela se transforme directement en un tableau de bord d'interface utilisateur interactif.

Habituellement, sur le terrain, il y a de nombreux cas où les données PLC ne peuvent pas être connectées directement. Dans notre cas également, il y a eu des problèmes liés au pare-feu et à la sécurité, nous avons donc travaillé avec les chercheurs et créé une sorte d'ensemble de données PLC factice, puis l'avons connecté au tableau de bord dans Unity. Nous avons mené tout ce processus ensemble.

Outils d'édition personnalisés pour le scénario du aimant

[12:21] Ce sur quoi nous avons travaillé ensuite n'était pas seulement une simulation visuellement convaincante, mais un projet véritablement basé sur des faits. Après avoir créé le tableau de bord à l'exécution, nous avons également eu besoin de créer un tableau de bord ou un éditeur personnalisé à l'intérieur de l'Éditeur lui-même.

Dans cette usine, le premier scénario impliquait un aimant se déplaçant et utilisant la force magnétique pour ramasser des objets. Pour simuler la force magnétique nécessaire pour que des morceaux de métal soient ramassés ou non, au lieu de coder en dur chaque valeur, nous les avons exposées directement dans l'Éditeur. Ainsi, des choses comme le statut de chaque chariot et le statut de l'aimant, et même le comportement de la simulation physique, ont tous été développés à l'aide de Unity AI.

Créer l'effet de four à partir d'une image conceptuelle

[13:21] La prochaine chose dont je parlerai est l'effet de four. Certains d'entre vous pourraient penser qu'ils ont besoin d'effets visuels.

L'une des fonctionnalités les plus puissantes de Unity AI et de MCP est qu'ils peuvent capturer la vue scène ou la vue jeu. Lorsque vous travaillez sur un projet, tout comme un téléphone applique une correction de couleur, les couleurs peuvent paraître différentes dans l'éditeur Unity ou la vue de jeu. Pour créer l'impact que vous souhaitez dans ces couleurs, vous avez besoin de choses comme des combinaisons de couleurs. Par le passé, c'était un domaine que les artistes devaient gérer.

[14:01] Mais maintenant, vous pouvez dire à l'IA : « Crée quatre sphères dans la scène, applique un effet de fourneau, et continue de le mettre à jour jusqu'à ce qu'il ressemble le plus au concept ou à l'image de concept que je vous donne. » Unity AI trouve ensuite et crée l'effet le plus approprié, et l'applique même à la scène réelle en une seule fois.

Conversion d'URP à HDRP

[14:24] Après cela, une fois que nous avions créé la version URP, nous l'avons convertie en HDRP. Pendant le processus de conversion d'URP à HDRP, j'étais occupé avec autre chose et j'ai donné à l'IA les paramètres graphiques, les concepts et les autres détails que j'avais préparés. Les images que vous voyez ici sont le résultat de l'IA qui les améliore étape par étape au fil du temps pour correspondre à cette image conceptuelle.

[14:51] Au début, c'était soit un écran noir, soit un écran trop lumineux. Puis il est retourné à l'original, est devenu un peu plus lumineux et a suivi ces étapes tout seul, de sorte que la scène d'usine continuait de se mettre à jour. Il s'est progressivement amélioré, et au final, je peux dire que c'est la scène HDRP soignée que j'avais en tête.

Export USD à l'exécution

[15:18] La dernière chose que je mentionnerai est que nous ne nous sommes pas arrêtés à URP et HDRP. Je gère également des projets de jumeaux numériques pour d'autres grandes entreprises, et ce qu'elles disent le plus souvent est : « D'autres équipes ou d'autres départements de notre entreprise veulent utiliser ces données bien organisées et prêtes pour la simulation dans d'autres outils ou sur d'autres plateformes. »

[15:44] Donc ce sur quoi nous avons travaillé était d'activer l'exportation USD à l'exécution. L'exportation en cours d'exécution signifie que pendant l'exécution d'une simulation, vous pouvez modifier la disposition dans une certaine mesure, l'enregistrer et exporter cet état exact au format USD. De cette façon, sur une autre plateforme, les textures, la géométrie et tout le reste peuvent être préservés exactement tels quels et utilisés immédiatement.

Nourrir le jumeau dans les modèles du monde

[16:18] Une fois que vous avez un jumeau numérique comme celui-ci, il ne s'agit pas seulement de tout connecter et de regarder un tableau de bord. Je veux aussi parler du sujet le plus chaud d'aujourd'hui : les modèles du monde.

Avec des modèles du monde tels que FLUX, Qwen ou NVIDIA Cosmos 3, vous pouvez prendre l'écran du jumeau numérique que vous avez construit dans Unity, saisir cet écran ou cette image, et à partir de là montrer des choses comme le vieillissement de l'usine, la vapeur qui s'échappe, des scénarios sim-to-real, ou même des changements dans l'heure de la journée. Nous avons pu obtenir une variété d'ensembles de données pour ces domaines.

Résultats du projet en chiffres

[16:55] Pour mettre nos résultats en chiffres : le projet a duré 14 semaines à partir du lancement. Nous avons organisé 627 actifs à 218. Nous avons eu 77 soumissions de code source, et nous sommes passés des nuages de points jusqu'à HDRP. Parmi les 39 ensembles de données que nous avions, nous avons visualisé 20 d'entre eux. Plus tard, nous avons effectué une augmentation des données basée sur plus de 10 modèles de monde basés sur la physique.

Comparaison côte à côte et l'écart du domaine de la fabrication

[17:27] Nous avons fait une vidéo de comparaison finale. Ici, vous voyez le nuage de points en premier, puis URP au milieu, et ensuite HDRP. Après cela, nous avons exécuté la diffusion, la simulation de modèle du monde et l'augmentation des données.

Il y a une chose que j'aimerais souligner dans ce processus. Les modèles entraînés sur des données générales ont peu de compréhension des données du domaine manufacturier. Nous avons donc passé beaucoup de temps à étudier comment combler ce fossé de données dans le domaine de la fabrication. Cette partie sera expliquée ensuite par le Dr. Hongin Won.

Je voudrais remercier le Dr. Hongin Won, le chercheur Youngseok Han, le chercheur Jaehoon Hwang et beaucoup d'autres qui ont travaillé sur ce projet avec nous.

KITECH : transformer un jumeau numérique en un environnement où l'IA peut apprendre

[18:47] Dr. Hongin Won: Je suis Hongin Won de l'Institut coréen de technologie industrielle.

Auparavant, le responsable Woojin Park a expliqué comment construire et étendre un jumeau numérique d'usine dans Unity, spécifiquement pour une fonderie. Comme prochaine étape, je parlerai de la manière de transformer ce jumeau numérique en un environnement où l'IA peut apprendre et être testée.

Le titre de la présentation d'aujourd'hui est un pipeline de données synthétiques basé sur un jumeau numérique Unity pour l'IA manufacturière. Puisque le titre mentionne un pipeline de données synthétiques, vous pourriez vous demander : « Alors, comment synthétisent-ils exactement les données ? » Mais avant cela, la question la plus importante est : « Le jumeau numérique a-t-il vraiment été construit pour correspondre au système réel ? » J'aimerais me concentrer un peu plus sur la manière dont nous vérifions exactement cela. Nous avons appelé le processus de construction d'un modèle de jumeau numérique pour correspondre à la réalité « ancrage », et je l'expliquerai sous cet angle.

Équipe et direction de la recherche

[19:49] Je suis Hongin Won, et je dirige l'équipe de collaboration sur l'IA de fabrication au Centre de recherche sur l'IA de fabrication de KITECH. Mes domaines d'expertise sont l'IA de fabrication, les Digital Twins et l'infrastructure de données industrielles. En particulier, mon domaine d'intérêt dans les Digital Twins est la virtualisation, ou comment transférer des problèmes du monde réel dans un environnement virtuel ; la génération, comment créer les données nécessaires dans cet environnement ; et la validation, comment ramener les résultats pour une vérification dans le monde réel.

[20:18] Les principaux chercheurs qui ont participé à ce projet sont le chercheur Jaehoon Hwang et le chercheur Seungyeop Ha de notre centre. Le chercheur Jaehoon Hwang était responsable de la mesure et de la correction des différences restantes après avoir déplacé les capteurs de l'environnement réel vers le jumeau, tandis que le chercheur Seungyeop Ha s'occupait de la simulation homme-robot et du mouvement, ainsi que de l'élargissement des données sur une large gamme de conditions.

[20:48] Notre orientation de recherche pour les jumeaux numériques de fabrication se résume à une seule ligne : des jumeaux numériques pour l'IA, l'IA pour les jumeaux numériques. Cela signifie créer des environnements où l'IA peut apprendre et être testée, et utiliser l'IA pour reconstruire et mettre à jour les Digital Twins. Nous faisons également des recherches sur les Digital Twins avancés basés sur des systèmes multi-agents et des LLM.

[21:09] Voici une courte vidéo sur les modèles que notre centre a construits. La vidéo présente des modèles qui transfèrent les chaînes d'assemblage de véhicules électriques, la logistique urbaine, les fonderies, et plus encore, dans des jumeaux numériques et les connectent comme une chaîne d'approvisionnement unique. Nous utilisons beaucoup le simulateur Unity, mais en arrière-plan, nous modélisons également des scénarios avec des simulations plus légères, et les résultats de celles-ci sont ensuite intégrés dans un pipeline d'intégration Unity. C'est une direction majeure de nos recherches.

[21:48] La vidéo présente également les technologies de simulation et de validation développées là-bas, y compris la fusion de capteurs et des études où des agents basés sur des LLM planifient des trajectoires de robots. Il comprend également un exemple de planification de trajectoires de robot à l'aide des fonctionnalités Unity MCP.

Collaboration homme-robot et pourquoi les données sur la collaboration homme-robot sont rares

[22:09] Le sujet d'aujourd'hui est de construire des environnements où l'IA peut apprendre et être testée. Le scénario abordé dans cette présentation est un site de fabrication où les humains et les robots collaborent. Un environnement où les humains et les robots travaillent ensemble dans le même espace est appelé collaboration homme-robot, ou HRC.

[22:25] En ce qui concerne le déroulement de la présentation, je vais d'abord parler de la raison pour laquelle ce type de données HRC est si rare dans le monde réel, et pourquoi nous devons toujours le construire entièrement dans le modèle de jumeau numérique. Ensuite, j'introduirai l'approche que nous avons adoptée pour surmonter cela, ainsi que les méthodes de synthèse de données que nous avons développées. Et lors de la construction d'un modèle de jumeau numérique, beaucoup de parties ne correspondent pas tout à fait au monde réel. En d'autres termes, un écart réalité-simulation se produit, et j'expliquerai également comment nous avons calibré et résolu cet écart.

[23:02] Commençons par le problème des données. Comme vous le savez tous, l'IA apprend à partir de données. Mais certains champs disposent de beaucoup de données disponibles, et d'autres non. Par exemple, dans la conduite autonome, nous pouvons facilement obtenir des millions de kilomètres d'enregistrements de conduite, et pour les données de Vision générales, nous pouvons extraire des images et des vidéos du web ou de la vie quotidienne. Les modèles de langage peuvent également utiliser des données provenant de l'ensemble d'Internet pour leur entraînement.

Mais pour les sites de fabrication, en particulier pour les humains et les robots travaillant ensemble, nous avons besoin de données où les travailleurs approchent près des robots, où des parties du corps sont occultées, ou où les personnes entrent et sortent des zones de sécurité. Ce genre de données est extrêmement difficile à trouver dans les ensembles de données publics.

Quatre raisons de la rareté des données

[23:54] Nous avons identifié quatre raisons de cette rareté de données sur les sites de fabrication.

D'abord, la sécurité. Le moment où une personne entre dans la zone de danger d'un robot n'est pas quelque chose que vous pouvez mettre en scène encore et encore juste pour collecter des données.

Deuxième est le coût. Mettre en place une ligne réelle, installer des capteurs et filmer en changeant les conditions demande beaucoup de temps et d'argent.

Le troisième est la partie avec laquelle nous avons le plus eu du mal : l'étiquetage. Pour l'entraînement de l'IA, des annotations et des étiquettes sont nécessaires pour créer la vérité terrain. Mais l'alignement des positions 3D des humains et des robots, des distances, des informations articulaires, des arrière-plans, des objets et des régions au niveau des pixels à travers plusieurs capteurs au même instant équivalait à un travail purement manuel.

[24:36] Le dernier est la rareté. Rareté de scénario, pour être précis. Il est extrêmement difficile d'obtenir des données sur les collisions entre les personnes et les robots dans les sites de fabrication. Les situations juste avant une collision sont appelées événements de queue longue. Ces situations n'arrivent presque jamais dans la réalité, et elles sont extrêmement difficiles à créer artificiellement pour nous. Et sur un site bien géré, de telles données devraient survenir moins souvent, pas plus.

Données de proximité : ce dont nous avons réellement besoin pour entraîner

[25:16] Ce que nous voulions entraîner n'était pas simplement si une personne était présente ou non, mais à quelle distance la personne se trouvait du robot, dans quelle direction, et dans quelle posture elle s'approchait. Ce type d'information, c'est ce que nous appelons des données de proximité. Nous devons comprendre cette relation afin que les humains et les robots puissent collaborer et juger les zones de sécurité, et dans le cas des robots, pour surveiller la proximité d'une personne, ou pour créer des scénarios où ils peuvent ralentir et s'arrêter.

[25:43] Pour faire simple, la situation était la suivante. Il y avait beaucoup trop peu de données. Alors si nous ne pouvons pas le collecter, générez-le. C'est ce que nous nous étions donné pour objectif de faire. Mais pour générer des données, le modèle qui génère a besoin de données solides par lui-même. Nous avons donc d'abord pris des valeurs mesurées dans le monde réel comme référence et construit un pipeline de données synthétiques de jumeau numérique Unity.

Pourquoi nous avons choisi Unity : quatre technologies en un seul runtime

[26:09] Nous avons trouvé qu'il était relativement facile de connecter quatre technologies au sein d'un seul runtime, nous avons donc utilisé Unity.

Premièrement, il y a la simulation physique, où les robots, les personnes et les objets interagissent d'une manière physiquement valide. Le second est le rendu HDRP, qui correspond à l'éclairage, aux matériaux, etc., à la réalité afin de réduire l'écart de domaine. Le troisième est la simulation de capteurs, qui reproduit plusieurs types de capteurs virtuellement. La quatrième est les technologies appliquées qui génèrent des données à partir du jumeau afin que l'annotation et l'étiquetage puissent être effectués sans que des personnes ne marquent tout manuellement.

[26:48] Si ces quatre avaient resté séparés, nous n'aurions pas pu produire de données pour l'entraînement de l'IA. En les intégrant dans le même environnement d'exécution et le même axe temporel, nous avons pu générer les données dont nous avions besoin.

Le jeu de données Industrial HRC-Bench

[27:03] Le processus d'obtention de ces données d'entraînement a dû suivre une méthodologie professionnelle et fiable pour la construction des ensembles de données. Pour ce faire, nous avons fait appel à des experts du domaine de la fabrication et nous avons conçu conjointement des scénarios de collaboration homme-robot réels. Nous avons créé l'environnement expérimental faisant autorité au Centre d'essais et de certification robotique du Laboratoire de test de Corée.

[27:33] Suite à ces expériences, nous avons construit le jeu de données Industrial HRC-Bench. Les scénarios HRC recueillis jusqu'à présent, à un niveau prêt pour publication, se présentent en deux types : le palettisation et l'inspection des pièces de production. L'ensemble de données se compose d'un total de 17 épisodes. Parmi ceux-ci, neuf ont été réalisés avec des humains et des robots travaillant ensemble, et les huit autres avec le robot seul.

[28:02] Le système de capteurs utilisé ici intègre des caméras RGB, du LiDAR, de la vidéo à 360 degrés et un système de capture de mouvement. Ces modalités de capteurs étaient toutes synchronisées à 20 Hz, ce qui nous a donné plus de 100 000 images brutes de données. Lorsqu'il est calculé en temps pur, cela correspond à plus de 80 minutes.

Ce qui comptait pour nous ici, ce n'était pas seulement l'ampleur des données, mais leur structure. Toutes ces données partageaient le même axe temporel pour les observations et les étiquettes, ce qui a permis une comparaison précise et une génération de données significative. Nous prévoyons de publier le jeu de données Industrial HRC-Bench bientôt via Hugging Face ou un dépôt externe.

Le pipeline en trois mots : mettre à la terre, calibrer, générer

[28:53] Je pense que le flux général peut être résumé en trois mots : ancrer, calibrer, générer.

Le premier n'est pas simplement de créer un jumeau, mais d'ancrer des valeurs mesurées dans le monde réel à celui-ci. C'est l'ancrage, qui aligne le jumeau avec la réalité. Il y a ensuite l'étalonnage, qui réduit l'écart entre le réel et le simulé. Et à partir de là, la phase de génération de données.

Ancrage : environnement, capteurs, robots et étiquettes

[29:35] Jaehoon Hwang: Je suis Jaehoon Hwang, et j'étais responsable de l'implémentation du réel au simulé. Dans l'étape de mise à la terre, nous avons apporté quatre choses de la réalité : l'environnement, les capteurs, les robots et les étiquettes.

Environnement

[29:49] Nous avons mesuré les dimensions spatiales et la disposition des équipements principaux du banc d'essai KTL, et sur la base de ces valeurs, avons apparié les équipements et les zones de travail un par un à l'intérieur de Unity. En plus de cela, nous avons appliqué HDRP pour faire correspondre les matériaux et l'éclairage à l'environnement réel. Pour l'arrière-plan, en utilisant des images panoramiques à 360 degrés capturées sur site, nous avons construit une scène de splatting gaussien 3D photoréaliste pour réduire l'écart entre le réel et le simulé.

Notre objectif ultime était de créer une cellule de référence où la structure et les occlusions que la caméra voit, la manière dont les objets sont positionnés les uns par rapport aux autres, et comment la lumière et les matériaux affectent ce qui est observé pourraient être comparés côte à côte avec le monde réel. Dans l'image à l'écran, le côté gauche est la scène réelle et le côté droit est le jumeau numérique du même point de vue.

Système de capteurs

[30:34] Pour l'expérience, nous avons utilisé des caméras RGB et de profondeur, un LiDAR, une caméra à 360 degrés, la capture de mouvement et des données des états des deux robots. Dans l'environnement virtuel que nous avons construit, nous n'avons pas simplifié cela en une seule caméra. Après avoir vérifié où chaque capteur était installé sur le vrai montage et ce qu'il observait, nous avons construit des capteurs virtuels avec la même structure.

[30:59] À l'intérieur du runtime Unity, nous avons construit des composants de capteur personnalisés afin que toutes les observations partagent la même horloge de simulation. Nous avons également connecté les états du robot et les mouvements humains afin qu'ils soient synchronisés au même moment. La raison pour laquelle cette synchronisation est importante est que la proximité ne peut pas être résumée par une seule image. Au même moment, la vidéo, la profondeur, les articulations du robot et la pose humaine doivent tous exister ensemble afin de calculer les étiquettes de distance et de zone de sécurité de manière cohérente.

Robot

[31:27] Nous avions une norme. Il fallait que ce soit un mouvement physiquement valide, pas un mouvement qui semble seulement plausible. Nous avons intégré des trajectoires conjointes enregistrées dans le banc d'essai réel et les avons configurées pour les rejouer image par image dans leur ordre temporel d'origine. En utilisant l'Articulation Body de Unity, nous avons configuré les maillons et les articulations du robot, les degrés de liberté et la structure physique, puis nous avons exécuté les états d'articulation enregistrés par-dessus. Parce que l'inertie et le contact sont calculés ensemble, nous avons pu gérer l'interaction entre le mouvement du robot et les objets environnants au sein d'une seule structure physique.

Étiquettes

[32:02] À partir du même état de simulation, quatre types d'informations de vérité terrain sont générés ensemble : Boîtes englobantes 2D et 3D avec les positions des personnes, des robots et des pièces ; segmentation sémantique et par instance qui sépare les objets au niveau du pixel ; coordonnées articulaires utilisées pour l'estimation de la pose ; et vérité terrain de profondeur utilisée comme référence pour la distance de proximité. L'écran affiche une scène avec des boîtes englobantes 3D appliquées.

Ces étiquettes n'ont pas été produites par quelqu'un qui a marqué chaque image à la main. Ils proviennent directement de l'état de simulation Unity. Cela réduit à la fois le coût d'étiquetage et l'erreur d'annotation en même temps.

L'écart du réel au simulé dans la caméra

[32:52] Ensuite, j'expliquerai l'écart entre le réel et le simulé que nous avons rencontré lors de la construction du modèle de jumeau numérique, et comment nous l'avons résolu. Ce sont les écarts résiduels, les différences réel-virtuel qui subsistent même après le transfert. Parmi eux, nous avons identifié deux facteurs qui affectent directement les valeurs de proximité et la source de vérité terrain.

Le premier est survenu dans l'appareil photo. Lors de la construction de l'environnement virtuel, nous avons défini le même modèle de capteur et le même champ de vision pour les configurations réelles et virtuelles. Mais le même objet n'est pas apparu sur les mêmes pixels.

[33:20] Si vous regardez la superposition de bordure à droite, vous pouvez voir que les limites de la même structure sont légèrement désalignées en fonction de la position. Même en appliquant la fiche technique de l'objectif réel à l'environnement Unity, cela n'a pas résolu le problème. C'est parce que les spécifications du produit et les modèles d'objectifs standard seuls ne peuvent pas expliquer les différences laissées par l'angle d'installation et chaque objectif.

En HRC, même un désalignement aussi petit compte. Si la frontière entre une personne et un robot se décale de quelques pixels seulement, la correspondance entre les étiquettes de pixels générées en simulation et les observations réelles devient également instable. Nous avons donc décidé de mesurer directement le résidu de la caméra exacte installée dans ce banc d'essai.

Mesurer la distorsion de l'objectif au lieu de la modéliser

[34:01] La méthode que nous avons choisie est simple. Ne modélisez pas l'objectif directement. Mesurez-le.

Ce processus se compose de trois étapes. Premièrement, en utilisant une vue gaussienne 3D générée à partir de multiples points de vue, nous avons obtenu des scènes correspondantes dans les environnements réels et virtuels. Nous avons ensuite calculé les différences entre ces images appariées au niveau du pixel et les avons enregistrées sous forme de carte de distorsion par pixel. Enfin, nous avons appliqué cette carte au shader de distorsion de caméra d'Unity afin que la caméra virtuelle soit corrigée pendant le processus de rendu de l'image.

[34:35] La clé est cette boucle. Nous créons des scènes correspondantes, mesurons la différence restante et renvoyons cette valeur au runtime Unity.

Voici le résultat. À gauche se trouve l'observation du capteur réel, au centre le jumeau numérique corrigé, et à droite la superposition de bordure des deux images. Regardez les lignes de démarcation à droite et vous pouvez voir une amélioration marquée par rapport à avant. En appliquant une carte de distorsion spécifique, nous avons pu confirmer que l'alignement des pixels entre les images réelles et virtuelles s'est amélioré correctement.

[35:09] Il ne s'agit pas d'un post-traitement externe, mais d'un composant qui s'exécute lorsque la caméra virtuelle génère des images, de sorte que les observations corrigées et la vérité terrain peuvent être produites dans le même environnement d'exécution.

Correction du mouvement humain instable avec IK

[35:16] Le deuxième problème est apparu dans le mouvement humain. L'écran montre un mouvement humain enregistré avec capture de mouvement, rejoué avec des marqueurs et un squelette. Ceci est une section où une partie du corps a été occultée par le robot et l'établi lors de la capture. Regardez comment les articulations du pied commencent à trembler. À mesure que l'occlusion augmente, les estimations des articulations cachées deviennent instables, le pied glisse sur le sol et les articulations se mettent dans des positions physiquement impossibles.

[35:47] Ce tremblement déforme directement la distance entre l'humain et le robot, la proximité de chaque partie du corps et les étiquettes de zone de sécurité. Nous avons donc appliqué des contraintes physiques au mouvement humain également. C'est l'amplitude de mouvement du sol et des articulations.

C'est la même scène qu'avant. Cette fois, il n'y a que deux choses à surveiller. Le pied reste-t-il au sol, et les articulations restent-elles naturelles ?

[36:14] Premièrement, avec le IK du pied, nous avons rattaché le pied à la géométrie réelle du sol mesurée. Ensuite, en utilisant l'IK Humanoïde, nous avons contraint les articulations occultées à se déplacer dans les limites d'articulation valides. IK recalcule les positions des articulations intermédiaires, en fonction des positions cibles pour les mains ou les pieds. Cette correction vise à réduire le mouvement non physique qui perturbe les étiquettes de proximité et de sécurité.

Lecture de scénario : palettisation et inspection des pièces

[36:40] Dr. Hongin Won: Je voudrais remercier le chercheur Jaehoon Hwang pour avoir exposé les technologies clés pour réduire l'écart entre le réel et le simulé, de la construction du pipeline à la correction des capteurs et de l'IK. Je vais vous montrer brièvement comment se comporte le modèle numérique que nous avons construit, puis nous conclurons notre présentation.

[37:21] Les deux scénarios que nous avons construits comme modèles numériques sont basés sur le même environnement HRC, mais diffèrent par leurs caractéristiques de tâche. Le premier est le palettisation, et le second est l'inspection de surface. Les deux ont été conçus comme des scénarios qui pourraient se produire de manière plausible sur un site de fabrication. Nous publierons les détails spécifiques séparément plus tard dans le résumé.

[37:44] C'est le cas de palettisation. Dans le modèle de palettisation, ce que nous avons enregistré du robot réel précédemment via le Corps d'Articulation est intégré dans ce modèle de jumeau numérique. Comme vous l'avez vu, deux types de données de capteurs, les informations d'état du robot, les masques d'instance et les masques de segmentation sont tous synchronisés et joués ensemble.

[38:10] Le second est un scénario pour l'inspection des pièces. La situation de contact rapproché entre l'opérateur et le robot est également modélisée, et elle est très bien synchronisée avec les données de simulation et de robot, nous pouvons donc rejouer des données dans lesquelles les quatre éléments sont ancrés. Si vous regardez attentivement, même lorsque la personne chevauche une partie, vous pouvez voir que la segmentation fonctionne très bien.

[38:41] La valeur de ce pipeline de données ne se limite pas à la création d'un jeu de données ponctuel. Il peut également être étendu et reproduit sur de nombreux autres sites industriels.

Randomisation du domaine avec le Unity Perception Package

[39:15] Ce que nous avons montré plus tôt est moins un ensemble de données ponctuel qu'un pipeline de données génératif qui peut étendre les données en continu. Sur la base du Unity Perception Package, nous avons construit un modèle de randomisation de domaine et défini des plages de paramètres et des règles d'échantillonnage pour l'éclairage, les matériaux, les caméras, etc., afin que des variations réalistes soient générées autour de cette base précisément alignée.

Résumé du système et clôture

[39:39] Je pense que nous pouvons tout résumer avec cette figure. Ceci est la structure du système global. À gauche se trouvent les objets cibles, le mouvement humain, les trajectoires de robot, et ainsi de suite. Ce sont des éléments d'entrée qui peuvent être remplacés à tout moment, et le centre est le noyau.

[39:53] Un modèle de base qui établit la référence à l'aide de mesures du site réel, un modèle de calibration qui corrige les erreurs par tâche, et à droite, un modèle qui extrait automatiquement des données de vérité terrain multimodales, le modèle de génération. Ce sont les trois que nous avons construits.

Nous avons montré comment nous créons un jumeau basé sur le banc d'essai réel et calibrons les différences de tâches clés, jusqu'à la génération de données synchronisées.

[40:29] Les données que nous avons présentées aujourd'hui étaient HRC, mais en fait, nous les avons présentées comme une application pour prouver les principes de conception de notre pipeline. Dans la prochaine ère des usines d'IA, où les robots et les humanoïdes peuvent coexister, nous pensons que notre pipeline peut servir de couche de simulation et de données.

Nos remerciements vont au KTL Robot Testing and Certification Center, qui a fourni l'environnement de banc d'essai et a mené les expériences avec nous, et à Unity Technologies, qui nous a accompagnés depuis le début et nous a entièrement soutenus.