Aller au contenu principal
Le Fil Robotique
Le Fil RobotiqueHumanoïdes · IA physique · Industriel
EVA-Client : framework unifié de collecte, d'inférence et de déploiement pour politiques incarnées sur robots réels
InfrastructurearXiv cs.RO 

EVA-Client : framework unifié de collecte, d'inférence et de déploiement pour politiques incarnées sur robots réels

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

Un nouveau framework open-source baptisé EVA-Client vient formaliser une brique jusqu'ici bricolée maison par chaque laboratoire de robotique manipulatrice : le pont entre un serveur d'inférence de politique et le robot physique. Publié sur arXiv début juillet 2026, l'outil unifie en un seul code base les trois étapes critiques de la boucle d'itération sur robot réel, déploiement, collecte de données et évaluation. Son architecture découple explicitement trois couches orthogonales, les backends robots, les stratégies d'inférence et les middlewares de transport, de sorte qu'ajouter un nouveau bras ou un nouvel algorithme ne touche qu'une seule couche du système. EVA-Client propose aussi trois modes d'exécution inspectables, Debug, Collect et Eval, allant de la simulation en boucle ouverte au contrôle temps réel continu. Surtout, chaque run d'évaluation enregistre automatiquement des rollouts complets au format prêt pour l'entraînement, avec logs exhaustifs et un visualiseur de comparaison côte à côte, transformant chaque test en donnée réutilisable plutôt qu'en simple observation perdue. Le framework consolide enfin les principales stratégies d'inférence temps réel du secteur, exécution synchrone et asynchrone, lissage temporel façon ACT, Real-Time Chunking, et une base asynchrone naïve servant de référence, derrière une seule interface de configuration.

Pour les équipes qui entraînent des politiques d'imitation ou des modèles VLA (vision-language-action), ce type d'infrastructure comble un angle mort réel : la littérature regorge de nouvelles architectures de politiques, mais la mise en production sur robot réel reste souvent un patchwork non reproductible, ce qui complique les comparaisons équitables entre méthodes et ralentit le passage du prototype au déploiement en série. En traitant chaque évaluation comme une collecte de données, EVA-Client attaque directement le problème du volume de données réelles, goulot d'étranglement classique face aux modèles génératifs entraînés sur des corpus web massifs.

Ce travail s'inscrit dans une vague plus large d'outillage d'infrastructure pour l'IA incarnée, à mesure que des modèles fondation comme Pi-0, GR00T N2 ou Helix gagnent en maturité et que le goulot se déplace de l'algorithme vers l'ingénierie de déploiement. Contrairement aux piles propriétaires fermées de certains acteurs commerciaux, une approche ouverte et modulaire pourrait faciliter les comparaisons inter-laboratoires et accélérer l'adoption par des équipes académiques ou industrielles ne disposant pas de stack maison.

Dans nos dossiers

IA physique & VLANVIDIA GR00TarXiv cs.RO

À lire aussi

ORICF : un framework ouvert pour l'inférence et le contrôle en robotique
1arXiv cs.RO 

ORICF : un framework ouvert pour l'inférence et le contrôle en robotique

Des chercheurs ont publié le 12 mai 2026 sur arXiv (identifiant 2605.09656v1) un framework open source baptisé ORICF (Open Robotics Inference and Control Framework), conçu pour réduire le coût computationnel du déploiement de modèles d'IA sur robots mobiles. La plateforme, modulaire et agnostique aux modèles, permet de composer des pipelines d'inférence multimodaux via de simples fichiers de configuration YAML, sans modification du code source. Son mécanisme central, l'edge offloading, consiste à délocaliser les tâches d'inférence vers des machines externes proches du robot plutôt que de les exécuter en embarqué. Validé sur un robot mobile équipé de ROS2, le système combinait reconnaissance automatique de la parole (ASR), un grand modèle de langage (LLM) et un réseau de neurones convolutif (CNN) pour répondre à des questions orales sur les personnes détectées par sa caméra. Par rapport à une exécution entièrement embarquée, ORICF réduit l'utilisation des ressources de calcul côté robot de 83,16% et la consommation énergétique estimée de 65,8%, tout en préservant la modularité et la reproductibilité du pipeline. Ces résultats adressent l'un des freins les plus concrets au déploiement de modèles fondamentaux sur robots de service ou industriels : la contrainte matérielle embarquée. En déchargeant dynamiquement l'inférence sur des serveurs edge locaux ou des postes de travail voisins, ORICF rend envisageable l'utilisation de modèles lourds (LLM, VLM) sur plateformes à faible puissance de calcul. La spécification déclarative YAML simplifie également les changements de modèles ou de cibles matérielles, avantage concret pour les équipes intégration qui gèrent plusieurs configurations de déploiement. À noter cependant : la validation ne porte que sur un prototype unique en laboratoire, et les métriques de latence de bout en bout en conditions réelles ne sont pas détaillées dans le preprint, ce qui limite l'extrapolation aux environnements industriels. ORICF s'inscrit dans un mouvement plus large d'outillage de la robotique embarquée avec des modèles fondamentaux, alors que ROS2 s'est imposé comme infrastructure standard pour les robots de recherche et de plus en plus industriels. Plusieurs approches concurrentes ciblent le même problème : Isaac ROS de NVIDIA propose une pile d'inférence optimisée pour hardware Jetson, tandis que des acteurs comme Hailo adressent le déploiement sur puces dédiées. Le preprint ne cite pas d'affiliation universitaire ni d'entreprise sponsor visible, ce qui reste un signal à surveiller pour évaluer la maturité et la continuité du projet. Les prochaines étapes logiques seraient une validation sur des plateformes robotiques hétérogènes et une évaluation de latence en conditions opérationnelles réelles.

InfrastructureOpinion
1 source
XPolicyLab : une norme unifiée et un écosystème ouvert pour l'évaluation et le déploiement de politiques robotiques
2arXiv 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
Embodied.cpp : un moteur d'inférence portable pour modèles d'IA incarnée sur robots hétérogènes
3arXiv cs.RO 

Embodied.cpp : un moteur d'inférence portable pour modèles d'IA incarnée sur robots hétérogènes

Des chercheurs publient sur arXiv (référence 2607.02501v1) un runtime d'inférence baptisé Embodied.cpp, conçu pour exécuter des modèles d'IA incarnée directement sur des robots physiques. Écrit en C++, il cible spécifiquement les modèles vision-langage-action (VLA) et les modèles monde-action (WAM), deux familles d'architectures qui équipent aujourd'hui la plupart des humanoïdes et bras robotiques pilotés par apprentissage. Le système s'organise en cinq couches, des adaptateurs d'entrée jusqu'aux adaptateurs de déploiement, en passant par la construction de séquences, l'exécution du backbone et des modules de tête interchangeables. Les auteurs l'ont testé sur deux modèles VLA, HY-VLA et pi0.5, obtenant des taux de réussite de tâches en boucle fermée de 100,0% et 91,0% respectivement. Sur un benchmark préliminaire de modèle WAM utilisant un bloc Transformer LingBot-VA, la mémoire consommée par bloc chute de 312,2 MiB à 88,1 MiB. Cette publication s'attaque à un problème très concret pour les intégrateurs robotiques: le déploiement des modèles d'IA incarnée reste aujourd'hui fragmenté entre piles Python spécifiques à chaque modèle, hypothèses matérielles disparates et code de liaison écrit à la main pour chaque robot. Les runtimes d'inférence existants sont pensés pour du serving requête-réponse classique, pas pour les contraintes réelles du contrôle robotique: exécution multi-fréquence dans une boucle fermée, inférence batch-1 en priorité latence sur du matériel hétérogène, et interfaces au-delà du simple flux de tokens. Si les résultats se confirment à plus grande échelle, un runtime portable unique capable de faire tourner plusieurs familles de VLA et de WAM sur des appareils edge variés réduirait significativement le travail d'ingénierie nécessaire pour passer d'un prototype en simulation à un déploiement réel sur robot, un des goulots d'étranglement les plus cités du secteur. Le travail s'inscrit dans la course actuelle autour des modèles génériques de contrôle robotique, aux côtés d'architectures comme Pi-0 de Physical Intelligence ou GR00T N2 de Nvidia, qui cherchent toutes à unifier perception, langage et action dans un seul modèle déployable sur du matériel varié. En proposant une couche d'abstraction backend commune plutôt qu'un modèle de plus, Embodied.cpp se positionne comme brique d'infrastructure plutôt que comme concurrent direct, un signe que la standardisation de l'inférence embarquée devient un enjeu aussi important que la performance des modèles eux-mêmes.

InfrastructureActu
1 source
Planification à base d'agents en lots pour le service de politiques robotiques
4arXiv 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