Jumeau numérique d'un robot industriel

Pourquoi la géométrie se saisit à la main

La décision qui soutient tout le projet est que l'on modélise la chaîne cinématique, quel que soit le bras. L'interface pose deux questions avant de dessiner quoi que ce soit : combien d'axes possède le bras, de deux à six, et combien mesure chaque segment en centimètres. Avec ces deux réponses, le logiciel assemble la chaîne et résout les équations, et c'est là que vit le travail difficile : la cinématique directe dit où se trouve la pointe quand on tourne les axes, et l'inverse dit de combien chaque axe doit tourner pour que la pointe atteigne un point que vous avez choisi. La seconde est celle qui n'a pas une réponse unique, et c'est celle qu'il faut résoudre en respectant la limite de rotation de chaque axe.

Écrire ces équations nous-mêmes, au lieu de les hériter du logiciel du fabricant, est ce qui fait qu' adapter le jumeau à un autre bras revient à ressaisir des chiffres, sans reprogrammer. Sur la capture du produit livré, le même code soutient deux bras qui ne se ressemblent pas : l'UR5 d'Universal Robots, un cobot fin aux articulations rondes, et le GP8 de Yaskawa, un industriel compact avec une autre proportion et une autre portée.

La plage de deux à six axes n'est pas non plus un chiffre rond choisi au hasard. Le client avait un Yaskawa à six axes dans son laboratoire et a demandé par écrit de commencer par là plutôt que par le cas facile, avec l'argument que descendre de six axes à deux est plus simple que monter de deux à six. Résoudre d'abord le cas difficile est ce qui a laissé le reste de la plage résolu au passage.

Les deux façons de définir le mouvement

Le jumeau se pilote à la main, sans joystick ni console de coordonnées. Le premier mode déplace l'effecteur final : un cône apparaît pour marquer la destination, on l'attrape, on le place là où l'on veut que la pointe arrive et le bras résout la posture pour l'atteindre. Le second mode enchaîne des points pour définir un trajet complet.

Posé à l'échelle réelle sur le sol où irait la cellule, cela répond en quelques secondes à la question qui coûte normalement une visite : si la portée du bras suffit, si l'espace lui convient et par où il va passer. La capture montre le bras avec le maillage spatial de la pièce et la marque de ruban au sol où s'ancre la base.

La connexion au robot : ce qui a été prouvé et ce qui ne l'a pas été

C'est la partie qu'il faut raconter avec précision, parce que c'est celle qu'un ingénieur en automatisation demandera en premier. L'architecture était pensée pour boucler la boucle : le jumeau génère la trajectoire, l'exporte en angles par axe et le robot physique l'exécute. Le pont a été laissé fonctionnel d'Unity vers le simulateur de Yaskawa et vers Gazebo, via ROS, et la couche vers le contrôleur a été spécifiée sur OPC UA, avec la norme DIN EN IEC 62541-5 et le profil OPC UA for Robotics de la VDMA.

La mise en service sur la cellule physique n'a pas eu lieu. Alors qu'il restait cette étape, le client est entré en insolvabilité, en septembre 2024, et le projet s'est arrêté là. Nous le disons parce qu'un cas qui insinue une conclusion qui n'a pas eu lieu ne résiste pas à la première question technique : ce qui est prouvé, c'est le configurateur, la cinématique et le pont contre simulateur, et c'est la partie qui coûte à construire. L'étape qui manquait était la mise en service sur le terrain.

Questions fréquentes