Intrinsic Core, un ensemble de fonctionnalités compatibles ROS pour développer des applications robotiques, est désormais disponible en open source. Intrinsic, le groupe de robotique et d'IA de Google, publie une partie de sa plateforme sous la forme du package open source Intrinsic Core, que les développeurs peuvent télécharger sur GitHub. Cette publication couvre la commande, la perception, la planification, la simulation et les drivers.
Parallèlement au package, Intrinsic a publié l'Open Machine Tending Solution, ou OMTS. Il s'agit d'une architecture de référence prête à l'emploi pour un cas d'usage industriel concret, conçue pour offrir aux développeurs un point de départ plutôt qu'une page blanche.
Ce que contient le package
La publication recense sept fonctionnalités. La première est Intrinsic Control, un framework de commande temps réel, indépendant du matériel, qui assure une commande asservie aux capteurs. Il permet à un robot de modifier son comportement en cours de trajectoire lorsque l'environnement change. Il est conçu pour produire des trajectoires efficaces et sans collision. L'objectif affiché : permettre de remplacer bras robotisés, préhenseurs, capteurs et autres composants sans avoir à réécrire les drivers.
L'estimation de pose arrive en deuxième position. Elle fournit des estimations de pose à six degrés de liberté pour des pièces 3D. Savoir précisément où se trouve une pièce et comment elle est orientée est la donnée d'entrée dont dépendent la plupart des tâches de manipulation.
La planification de mouvement est la troisième fonctionnalité. Sa logique génère automatiquement des trajectoires efficaces et évite les collisions. Vient ensuite la planification de préhension. Elle est conçue pour que différents préhenseurs s'adaptent automatiquement et dynamiquement à la position et à l'orientation d'une pièce, et la saisissent avec une probabilité de réussite plus élevée.
Le package comprend également des services de simulation. Ils visent à offrir aux développeurs un moyen simple de tester et de dépanner des solutions robotiques, et ils se mettent à jour au fil de la construction de la solution. L'étalonnage de caméra automatise le calibrage de la caméra d'un robot ainsi que son alignement physique.
Le dernier élément est un ensemble de drivers Intrinsic-ROS. Ce sont des drivers préconfigurés et compatibles ROS pour les robots, préhenseurs et caméras 3D pris en charge.
L'architecture de référence pour l'alimentation de machines
L'OMTS cible le chargement et le déchargement de machines (machine tending), une tâche dans laquelle un robot alimente une machine et en retire les pièces. Cette architecture est proposée comme référence, et non comme un produit fini. Les développeurs peuvent la reprendre et l'adapter à leur propre cellule, ce qui leur évite de développer toute l'application de zéro.
Cette architecture de référence montre aussi comment les différentes fonctionnalités sont censées s'articuler. La perception, la planification, la préhension et la commande figurent comme des entrées distinctes dans la liste, mais une application opérationnelle a besoin que toutes fonctionnent comme un seul système. Un exemple concret sur un cas d'usage réel est un moyen pratique de montrer cette intégration.
Comment les briques s'assemblent
La publication s'organise autour d'un flux de travail. Un robot doit repérer une pièce, planifier une trajectoire jusqu'à elle, la saisir et la déplacer sans collision. Le package fournit un composant pour chaque étape. La simulation et l'étalonnage de caméra accompagnent le travail autour de ces étapes, et les drivers relient le logiciel au matériel.
La compatibilité ROS traverse l'ensemble du package. Les fonctionnalités sont présentées comme compatibles ROS, et les drivers sont préconfigurés pour ROS. Les développeurs qui travaillent déjà sous ROS n'ont donc pas à changer leurs outils pour essayer ces composants.
Analyse : ce que cela change, et ce qui reste à démontrer
L'affirmation la plus lourde de conséquences de cette publication est l'indépendance vis-à-vis du matériel. Les cellules robotisées sont souvent liées aux drivers spécifiques de leurs bras, préhenseurs et capteurs, et changer un composant peut obliger à réécrire l'intégration. Si Intrinsic Control tient sa promesse de remplacer des composants sans réécrire les drivers, cela réduirait un vrai poste de coût dans le développement et la maintenance des applications robotiques. Ce bénéfice reste conditionnel, car la publication ne précise pas quels robots, préhenseurs et caméras sont pris en charge par les drivers.
Le choix de la compatibilité ROS est lui aussi raisonné. ROS est l'environnement que de nombreux développeurs en robotique utilisent déjà, de sorte qu'un package qui s'y intègre demande moins de migration qu'une plateforme distincte. Cela devrait abaisser la barrière pour tester les composants un par un. Cela ne rend pas le package unique pour autant. Des packages open source de planification de mouvement et de drivers existent déjà dans l'écosystème ROS ; Intrinsic Core sera donc jugé face à eux sur la qualité de sa planification, de sa préhension et de sa commande, et non sur le simple fait d'être ouvert.
Ce qui distingue cette publication d'un simple assemblage de bibliothèques, c'est son périmètre et son architecture de référence. Elle couvre ensemble la perception, la planification, la commande, la simulation et les drivers, et l'OMTS les montre à l'œuvre dans une même application. Un développeur peut ainsi évaluer toute la chaîne sur une tâche concrète, ce qui est plus utile que d'évaluer chaque composant isolément.
Plusieurs questions restent ouvertes. Intrinsic indique ouvrir une partie de sa plateforme, ce qui laisse entendre que d'autres parties ne le sont pas. La publication ne précise ni ce qui reste fermé, ni comment les deux se articulent. Elle n'indique pas non plus les conditions de licence, la liste du matériel pris en charge, ni de chiffres de performance pour l'estimation de pose, le taux de réussite de la préhension ou la qualité des trajectoires. La mention d'une probabilité de réussite de préhension plus élevée est un objectif de conception, et non un résultat mesuré, et aucune référence n'est donnée pour la comparaison.
L'adoption sera le véritable test. Le package comptera si les développeurs utilisent l'OMTS comme point de départ et l'étendent à leurs propres machines, et si des contributeurs externes ajoutent la prise en charge de nouveaux matériels. Ces résultats dépendent de la documentation, de la couverture des drivers et de la maintenance, aucune de ces dimensions n'étant décrite dans l'annonce. Pour l'instant, la publication met à disposition des roboticiens un ensemble de composants à tester sur GitHub, et c'est de ces tests que viendra la preuve de leur efficacité.