Aller au contenu principal
Le Fil Robotique
Le Fil RobotiqueHumanoïdes · IA physique · Industriel
ERUPT : une boîte à outils ouverte pour piloter les planificateurs de mouvement en réalité étendue
InfrastructurearXiv cs.RO 

ERUPT : une boîte à outils ouverte pour piloter les planificateurs de mouvement en réalité étendue

1 source couvre ce sujet·Source originale ↗·
Résumé IASource uniqueImpact UE

Des chercheurs du Parasol Lab publient ERUPT (Extended Reality Universal Planning Toolkit), un système de réalité étendue (XR) open source pour la planification interactive de mouvements robotiques, décrit dans un article arXiv mis à jour en version 2 (arXiv:2510.02464). L'outil s'interface avec MoveIt, le framework de planification de manipulation largement utilisé dans l'écosystème ROS, pour permettre à un opérateur de composer une requête de planification et de visualiser le chemin résultant directement en réalité virtuelle ou augmentée. Plutôt que de manipuler une scène 2D projetée sur un écran avec souris et clavier, l'utilisateur saisit et repositionne les objets de l'environnement à la main, dans l'espace, avant de lancer le calcul de trajectoire, puis de déployer le plan validé sur un robot physique. Le code source complet est disponible sur GitHub (parasollab/erupt), en libre accès pour quiconque souhaite construire une application d'interaction homme-robot immersive à partir de cette base.

Pour l'industrie robotique, l'apport n'est pas un robot ni un chiffre de performance mais un outil d'infrastructure: un moyen de tester et valider un plan de mouvement en réalité virtuelle, sans risque de collision, avant tout déploiement sur un robot physique. Cela répond à un besoin concret des intégrateurs et des équipes de R&D, qui doivent aujourd'hui itérer sur des scènes de manipulation via des interfaces 2D peu intuitives, un goulot d'étranglement connu dans la mise au point de cellules robotisées. En s'appuyant sur MoveIt plutôt qu'en réinventant un moteur de planification propriétaire, ERUPT vise l'adoption par une communauté déjà familière de cet outil, et illustre une tendance plus large: l'usage de la XR comme couche d'interaction pour la robotique manipulatrice, en complément du travail classique de simulation plutôt qu'en remplacement.

L'article se positionne explicitement comme une contribution académique ouverte plutôt qu'un produit commercial: aucun prix ni chiffre de déploiement industriel n'est communiqué, et l'objectif affiché par les auteurs est que d'autres équipes réutilisent ce socle logiciel pour leurs propres applications. ERUPT s'inscrit dans une lignée d'outils de visualisation et de téléopération en réalité virtuelle pour la robotique, mais se distingue en ciblant l'intégration native avec MoveIt et la reconfiguration dynamique de l'environnement pendant la planification elle-même. Aucune feuille de route de pilote industriel ou de partenariat n'est mentionnée dans le papier; sa diffusion dépendra désormais de l'adoption par la communauté ROS et robotique open source via le dépôt GitHub public.

Dans nos dossiers

arXiv cs.RO

À lire aussi

Planification à base d'agents en lots pour le service de politiques robotiques
1arXiv cs.RO 

Planification à base d'agents en lots pour le service de politiques robotiques

Des chercheurs du Georgia Tech (laboratoire RL2) publient un article intitulé "Action Chunk Scheduling for Batched Robot Policy Serving" (arXiv:2608.00337v1), qui pose un problème encore peu formalisé dans la robotique : comment servir un même modèle de politique robotique, hébergé sur un GPU distant, à plusieurs robots simultanément. Les auteurs présentent Armory, un système de service ("serving") conçu pour cet usage et validé à la fois sur des flottes de robots simulés et sur des robots réels. Leurs expériences montrent que les heuristiques de scheduling classiques (les méthodes de batching habituelles en inférence LLM) fonctionnent correctement tant que tous les robots de la flotte sont identiques et consomment les actions au même rythme. Mais dès que les robots consomment leurs "action chunks" (blocs d'actions produits par les modèles Vision-Language-Action) à des vitesses différentes, ces heuristiques échouent : elles ne tiennent pas compte des contraintes en boucle fermée ("closed-loop") propres à l'exécution de politiques robotiques. Pour corriger ce défaut, l'équipe propose un nouvel algorithme de scheduling qui intègre cette hétérogénéité de rythme entre robots, avec un gain de débit système mesuré jusqu'à 18 % lors d'essais réels. Le code et les détails sont disponibles sur gatech-rl2.github.io/actionchunkscheduling. Le résultat touche un point aveugle du déploiement à grande échelle des modèles fondation pour la robotique (VLA type Pi-0, GR00T N2, Helix ou autres) : le calcul embarqué est limité en puissance et en encombrement, ce qui pousse naturellement vers une inférence déportée sur GPU distant, mutualisée entre plusieurs robots pour amortir les coûts. Or les architectures de batching héritées du monde LLM, pensées pour du texte asynchrone, ignorent la contrainte physique du temps réel robotique : un robot qui épuise son buffer d'actions avant d'être resservi s'arrête ou dégrade sa trajectoire. Ce papier démontre empiriquement que cette mécanique de service compte autant que la qualité du modèle lui-même pour faire fonctionner une flotte hétérogène en production, un enjeu direct pour les intégrateurs qui veulent mutualiser l'inférence entre robots de générations ou de tâches différentes plutôt que de multiplier les cartes embarquées. Ce travail s'inscrit dans la vague récente de modèles VLA génériques (Pi-0 de Physical Intelligence, GR00T N2 de NVIDIA, Helix de Figure) qui cherchent à démontrer un contrôle robotique à l'échelle d'une flotte plutôt qu'à l'unité, un terrain où l'infrastructure de service devient aussi critique que l'entraînement. En formalisant le problème comme un scheduling explicite et en le testant sur du matériel réel plutôt que seulement en simulation, les auteurs positionnent Armory comme une brique d'infrastructure réutilisable, potentiellement comparable aux serveurs d'inférence LLM (type vLLM) mais adaptée aux contraintes temps réel de la robotique. L'article ne précise pas de partenariat industriel ni de déploiement commercial annoncé ; il s'agit pour l'instant d'un résultat de recherche académique, avec du code ouvert, plutôt que d'un produit prêt à l'emploi.

InfrastructureActu
1 source
AWS lance une boîte à outils open source d'IA physique pour la robotique
2Robotics Business Review 

AWS lance une boîte à outils open source d'IA physique pour la robotique

AWS a lancé aujourd'hui une Physical AI Toolchain en open source, qui doit permettre aux roboticiens de passer de la collecte de données à l'entraînement, la simulation, la validation et le déploiement de modèles d'IA sur leurs robots. Elle assemble des services AWS et la pile logicielle Physical AI de NVIDIA dans un flux de développement unique, articulé autour de cinq briques : génération de données synthétiques, entraînement de modèles, simulation et validation, déploiement en périphérie (edge) et amélioration continue. AWS fournit Amazon SageMaker pour l'entraînement et AWS IoT Greengrass pour distribuer les modèles vers les appareils embarqués. NVIDIA apporte Isaac Sim, Isaac Lab, Isaac GR00T et Cosmos. Les composants peuvent être utilisés séparément ou combinés de bout en bout. Un industriel peut ainsi collecter des démonstrations d'une tâche, générer des scénarios supplémentaires de façon synthétique, entraîner ou affiner un modèle, le tester en simulation, puis le charger sur le robot physique. Les données remontées du terrain alimentent ensuite le cloud pour améliorer le modèle. Sri Elaprolu, directeur Frontier AI Science and Engineering chez AWS, parle d'un « easy button » censé épargner aux équipes la gestion de l'infrastructure. Pour les intégrateurs et les décideurs industriels, l'enjeu est le maillon manquant entre un modèle entraîné et un système fiable en conditions réelles. Aujourd'hui, chaque équipe assemble sa propre chaîne d'outils, ce qui coûte du temps et fragmente les pratiques. AWS cible aussi la rareté des données : contrairement aux LLM, il n'existe pas de corpus massif de données robotiques sur Internet, d'où le pari sur la donnée synthétique et la simulation, dont la fidélité au monde réel reste la question ouverte du sim-to-real. La toolchain est volontairement neutre vis-à-vis du matériel, ce qui la rend utilisable avec des humanoïdes, des bras ou des mobiles. À ce stade, il s'agit d'une offre d'infrastructure annoncée, sans chiffres de performance ni client de production nommé pour la chaîne complète : l'argument repose sur la promesse d'intégration plutôt que sur des résultats mesurés. Le lancement s'inscrit dans la stratégie d'AWS, qui revendique plus d'un million de robots dans les opérations d'Amazon et dit y avoir puisé des enseignements pour la toolchain. Elle ne remplace pas directement RoboMaker, la plateforme de simulation robotique dans le cloud fermée en 2025, que Sri Elaprolu présente comme un composant parmi d'autres de la pile robotique d'AWS. Les entrepôts d'Amazon restant des environnements contrôlés, il cite Telexistence, société japonaise qui déploie des humanoïdes dans des supérettes, avec plus de 300 unités selon lui et d'autres à venir. Ces lieux imposent une tolérance aux pannes plus faible et des temps de réaction plus courts. Face à NVIDIA, qui pousse sa propre pile, et aux fournisseurs cloud concurrents, AWS se positionne en couche d'orchestration plutôt qu'en constructeur. Le calendrier de déploiement et les premiers clients de la chaîne complète n'ont pas été précisés.

UEPas d\'impact direct sur la France/UE

InfrastructureActu
1 source
XPolicyLab : une norme unifiée et un écosystème ouvert pour l'évaluation et le déploiement de politiques robotiques
3arXiv cs.RO 

XPolicyLab : une norme unifiée et un écosystème ouvert pour l'évaluation et le déploiement de politiques robotiques

Un article publié sur arXiv (2608.09892v1) présente XPolicyLab, un standard unifié et un écosystème ouvert pour l'évaluation et le déploiement de politiques robotiques. Il ramène le coût d'intégration entre N modèles de politique et M environnements, jusqu'ici de O(N×M), à O(N+M), grâce à des schémas communs d'observation, d'action et de trajectoire et à une architecture client/serveur séparant l'inférence de la politique de l'exécution de l'environnement. L'écosystème intègre 42 politiques robotiques et normalise leur installation, leur débogage et leur évaluation ; le respect du standard fait passer l'effort d'intégration d'une politique type de plus de cinq heures à deux heures, puis à trente minutes avec des modules d'agent prêts à l'emploi. Les mêmes adaptateurs font tourner les simulateurs RoboTwin et RoboDojo ainsi que des protocoles d'évaluation sur robot réel via une seule interface, le tout publié sur xpolicylab.github.io. Cette fragmentation logicielle freine depuis longtemps la comparaison reproductible des politiques robotiques, notamment des modèles vision-langage-action (VLA) qui se multiplient sans convention commune de dépendances. Pour les intégrateurs et laboratoires qui testent plusieurs politiques sur plusieurs plateformes, ce coût quadratique explique pourquoi tant de comparatifs publiés restent partiels ou difficiles à reproduire. Les auteurs montrent que le code propre à chaque politique varie d'un ordre de grandeur alors que la boucle côté environnement reste quasi identique à une référence fixe, preuve que la complexité peut être confinée au seul modèle. Le fait que les mêmes adaptateurs couvrent simulation et robot physique constitue un argument concret, mais limité à l'ingénierie logicielle, pour atténuer l'écart entre démonstration et déploiement réel. Ce travail s'inscrit dans la multiplication récente des modèles de politique généralistes pour la robotique, chacun livré avec sa propre pile logicielle et ses propres simulateurs, ce qui rendait les comparaisons indépendantes coûteuses et rares. XPolicyLab se positionne comme une couche d'infrastructure neutre plutôt qu'un produit commercial, un rôle comparable à celui des formats d'échange communs adoptés ailleurs en machine learning. L'article ne mentionne aucun déploiement industriel ni partenariat avec un fabricant de robots : il s'agit d'une publication de recherche, pas d'une annonce produit, présentée comme une infrastructure partagée destinée à être étendue par la communauté avec de nouvelles politiques et de nouveaux environnements.

InfrastructureActu
1 source
28 failles zero-day découvertes en moins de deux jours : ce que la découverte à vitesse d'IA signifie pour la robotique
4Robotics Business Review 

28 failles zero-day découvertes en moins de deux jours : ce que la découverte à vitesse d'IA signifie pour la robotique

VicOne, société de cybersécurité spécialisée dans l'automobile et la robotique, annonce avoir identifié 28 vulnérabilités zero-day en moins de deux jours, grâce à une recherche assistée par IA sur des logiciels et outils de l'écosystème dit « Physical AI ». Les projets touchés sont développés ou maintenus notamment par Google, NVIDIA et Meta. Ces outils servent à entraîner, simuler, tester et piloter des robots. Les 28 failles sont classées zero-day après une validation initiale, mais ce décompte peut évoluer après examen par les éditeurs et les autorités de référencement, et certaines n'ont pas encore de numéro CVE. Elles se répartissent sur trois étapes du cycle de vie : développement et entraînement, simulation et validation, déploiement et exécution. Au total, 75 % concernent des outils d'entraînement, de simulation ou de validation, donc des risques qui apparaissent avant même le déploiement du robot. Dans une démonstration séparée, les chercheurs ont exploité une faille pour empêcher le fonctionnement de la commande d'arrêt à distance d'un robot. L'intérêt tient moins au chiffre qu'au point d'entrée. Un modèle pré-entraîné piégé pourrait donner accès au système d'entraînement et altérer les données ou le modèle. Il pourrait se comporter normalement lors des tests de routine, puis réagir mal à un objet, une scène ou une commande précise une fois en service. Une scène ou un modèle de robot compromis, importé en simulation, pourrait fausser les capteurs simulés ou les résultats, et un robot approuvé sur la foi de tests faussés. En exploitation, des fichiers de planification de mouvement modifiés, des cartes malveillantes qui plantent l'affichage de supervision ou un poste de téléopération compromis peuvent altérer les mouvements ou priver les opérateurs de visibilité. Pour les intégrateurs et les responsables industriels, cela déplace la question de sécurité de la machine vers la chaîne d'outils qui la produit et la valide. VicOne précise toutefois que ce sont des conséquences potentielles, non démontrées pour chaque faille, et qu'elles dépendent de l'accès de l'attaquant, de l'architecture et des garde-fous qui empêchent ou non une modification d'atteindre le comportement physique. Aucune attaque réelle n'est signalée. Ce travail s'inscrit dans une double dynamique. D'un côté, les piles logicielles ouvertes de la robotique (simulateurs, frameworks d'entraînement, middlewares, modèles partagés) se sont généralisées avec la montée des modèles VLA et des humanoïdes, souvent sans la maturité en sécurité des systèmes industriels classiques. De l'autre, l'IA accélère l'analyse de code, le suivi des communications entre composants et la validation d'exploitabilité, ce qui profite aussi bien aux défenseurs qu'aux attaquants et laisse peu de temps de réaction face à une faille sans correctif. Il s'agit d'un communiqué d'un éditeur de sécurité, dont la méthode, le détail des failles et la gravité individuelle ne sont pas ici documentés, et le décompte reste provisoire. La suite dépendra des confirmations des éditeurs concernés, de l'attribution des CVE et des correctifs. En attendant, les équipes robotiques doivent d'abord vérifier si elles utilisent les logiciels affectés, puis évaluer ce qu'un attaquant pourrait y lire ou modifier.

InfrastructureActu
1 source