Aller au contenu principal
Retriever : composer des programmes robotiques asynchrones en boucle fermée
InfrastructurearXiv cs.RO 

Retriever : composer des programmes robotiques asynchrones en boucle fermée

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

Une équipe de recherche publie Retriever, un framework pour construire des agents robotiques à horizon long qui enchaînent perception, mise à jour des croyances, planification et contrôle, des composants qui tournent à des cadences différentes avec des latences variables. Décrit dans un article arXiv (2607.17213v1), le système représente un agent comme un graphe de fonctions de flux causales et stateful, exécutées sur des horloges d'exécution explicites. Retriever couvre toute la pile technique : un modèle de décision asynchrone, un modèle de programmation, un runtime compilant ces graphes vers plusieurs backends, et un pipeline d'agent en boucle fermée fourni en exemple. Les auteurs formalisent cette approche via une boucle environnement-agent asynchrone sur des flux en temps continu, et démontrent que des politiques causales à mémoire finie peuvent être représentées par composition de ces opérateurs. Le système a été évalué à travers une étude de cas sur robot réel, complétée par des mesures contrôlées du surcoût du runtime et du comportement de rejeu déterministe.

Le problème que Retriever cherche à résoudre est bien connu des équipes qui déploient des robots autonomes en conditions réelles : aujourd'hui, ces pipelines sont souvent assemblés avec des conventions de concurrence et de publication/abonnement ad-hoc, rendant implicite la sémantique de timing et de consommation des entrées. Résultat, un comportement dépendant de l'ordonnancement, difficile à reproduire, déboguer et réutiliser, un frein direct à la fiabilité des systèmes en production. En proposant un débogage systématique et un rejeu déterministe à partir de données asynchrones journalisées, Retriever s'attaque directement à un angle mort de l'ingénierie robotique actuelle, où la plupart des solutions traitent soit la couche algorithmique soit la couche systèmes, rarement les deux ensemble.

Ce travail s'inscrit dans une tendance de fond de la recherche en robotique appliquée, cherchant à industrialiser les architectures d'agents complexes plutôt qu'à empiler des modèles plus puissants. Il fait écho aux efforts autour des architectures VLA (vision-language-action) et des pipelines multi-composants déployés sur des plateformes comme les humanoïdes ou les AMR, où la robustesse logicielle devient aussi critique que la performance des modèles eux-mêmes. Les auteurs ne précisent pas de partenariat industriel ni de calendrier de diffusion publique de l'outil, mais positionnent explicitement Retriever comme une brique d'infrastructure réutilisable, destinée aux équipes de recherche et développement construisant des agents robotiques à long horizon.

Dans nos dossiers

À 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
Entretien avec Eleanor Tang-Smith (OLO Robotics) : rendre la programmation des robots accessible à tous
2Robotics & Automation News 

Entretien avec Eleanor Tang-Smith (OLO Robotics) : rendre la programmation des robots accessible à tous

Eleanor Tang-Smith, directrice des opérations d'OLO Robotics, a accordé une interview détaillant l'approche de la société pour démocratiser la programmation robotique. Alors que le marché connaît une accélération notable côté matériel -- robots mobiles autonomes (AMR), robots quadrupèdes, bras articulés et humanoïdes -- la plupart des organisations se heurtent à un frein persistant du côté logiciel. Programmer un robot industriel exige aujourd'hui une maîtrise pointue de plateformes comme ROS 2 (Robot Operating System 2), un écosystème puissant mais dont la courbe d'apprentissage reste dissuasive pour des équipes sans ingénieurs roboticiens dédiés. Ce goulet d'étranglement logiciel est désormais reconnu comme le principal obstacle à l'adoption à grande échelle de la robotique en entreprise, davantage que le coût du matériel lui-même. Pour les intégrateurs et les décideurs B2B, cela se traduit par des délais de déploiement longs, une dépendance aux profils rares, et un risque opérationnel élevé. OLO Robotics positionne son offre comme une couche d'abstraction qui permettrait à des techniciens non spécialisés de configurer et d'adapter des cellules robotiques sans toucher à ROS 2 directement. Si cette promesse se confirme à l'échelle, elle pourrait redistribuer les cartes dans la compétition entre intégrateurs spécialisés et solutions clé-en-main. OLO Robotics s'inscrit dans une tendance plus large de "no-code/low-code" robotics qui voit émerger plusieurs acteurs cherchant à réduire la friction logicielle : Wandercraft côté exosquelettes en France, ou encore des initiatives autour de VLA (Vision-Language-Action models) pour simplifier la programmation par démonstration. Le marché des AMR et de la cobotique reste dominé par des solutions nécessitant un paramétrage expert, ce qui laisse un espace significatif à qui saurait proposer une expérience développeur réellement simplifiée. Les prochaines étapes pour OLO Robotics -- pilotes industriels, partenariats intégrateurs, levées de fonds éventuelles -- seront déterminantes pour valider si l'accessibilité annoncée résiste au contact de contraintes de production réelles.

UELa tendance no-code/low-code en programmation robotique pourrait réduire la dépendance aux profils ROS 2 rares en Europe, mais OLO Robotics n'est pas un acteur européen et aucun déploiement EU n'est mentionné.

InfrastructureOpinion
1 source
ORICF : un framework ouvert pour l'inférence et le contrôle en robotique
3arXiv 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
Robot low-cost, banc de test ArmnetBench v0.1 pour évaluer des politiques de manipulation en parallèle
4arXiv cs.RO 

Robot low-cost, banc de test ArmnetBench v0.1 pour évaluer des politiques de manipulation en parallèle

Des chercheurs ont publié ArmnetBench v0.1, un benchmark d'évaluation en conditions réelles pour les politiques de manipulation robotique, exécuté sur une flotte de bras low-cost SO-101 sous supervision humaine légère sur site. Cette première version compare 7 politiques sur 12 tâches, en configuration bras unique et bimanuelle. Chaque politique est entraînée ou affinée sur 50 démonstrations par tâche. Le benchmark comptabilise 2 518 rollouts de politiques et 600 démonstrations de référence, soit 3 118 épisodes au total, chacun annoté selon une échelle à trois niveaux (réussite, sous-optimal, échec). Les rollouts sont notés manuellement, tandis que les démonstrations sont par construction considérées comme réussies. L'ensemble des 3 118 épisodes est publié en deux formats standards, LeRobot v3.0 et RoboMeter, pour faciliter la réutilisation par la communauté. L'évaluation en conditions réelles reste le principal goulot d'étranglement du développement de politiques de manipulation généralistes : chaque rollout nécessite du matériel physique et un opérateur pour installer, réinitialiser et noter la tentative, ce qui limite fortement le volume de tests réalisables face aux simulateurs. En s'appuyant sur des bras SO-101 peu coûteux et une supervision réduite, ArmnetBench propose un compromis entre le coût d'un banc d'essai physique et la scalabilité recherchée pour comparer des politiques à grande échelle. Au-delà du classement, la valeur du jeu de données tient surtout à son étiquetage qualité par épisode : ces trajectoires annotées peuvent nourrir l'entraînement de modèles de récompense, de modèles du monde prédictifs, ou de politiques apprises sur des données de qualité mixte, un axe distinct de la simple mesure de performance. Ce travail s'inscrit dans la lignée des efforts communautaires autour de l'écosystème LeRobot et des bras robotiques abordables comme le SO-101, popularisés notamment par Hugging Face pour démocratiser la recherche en manipulation hors des laboratoires équipés de bras industriels coûteux. Il fait écho aux benchmarks existants bâtis en simulation ou sur du matériel plus onéreux, en offrant une alternative reproductible à bas coût. Les auteurs présentent ce classement initial comme un point de départ sous budget partagé plutôt qu'une évaluation définitive, cette v0.1 servant avant tout à valider l'infrastructure de la ferme de bras de bout en bout. Les suites attendues incluent l'élargissement du nombre de tâches et de politiques comparées, ainsi que l'exploitation des données mixtes pour entraîner de nouveaux modèles.

InfrastructureActu
1 source