Aller au contenu principal
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

Voici la traduction/synthèse en français :

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

Entretien avec Eleanor Tang-Smith (OLO Robotics) : rendre la programmation des robots accessible à tous
1Robotics & 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
2arXiv 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
GMSL et l'écosystème croissant autour des systèmes de vision pour la robotique
3Robotics Business Review 

GMSL et l'écosystème croissant autour des systèmes de vision pour la robotique

Le standard GMSL (Gigabit Multimedia Serial Link), longtemps cantonné aux systèmes embarqués automobiles comme l'ADAS, s'impose progressivement dans les architectures de vision robotique industrielle. Selon Stephen Liu, responsable robotique chez Advantech, développeur de systèmes embarqués, environ un tiers des projets robotiques qu'il accompagne utilisent ou envisagent déjà des caméras GMSL. La technologie permet de transporter vidéo haute résolution, signaux de contrôle et synchronisation sur un unique câble léger, avec une latence déterministe et une résistance aux interférences électromagnétiques (EMI) significativement améliorée. Analog Devices (ADI), qui dispose d'un écosystème GMSL structuré -- modules caméra pré-validés, adaptateurs, BSP (Board Support Packages) et plateformes compatibles ROS -- positionne cette offre comme un raccourci entre preuve de concept et production de masse. L'adoption dépasse le stade POC : les plateformes AMR (robots mobiles autonomes) de logistique en sont les premiers utilisateurs en production, suivis par les robots humanoïdes, les stations de picking, les applications agricoles et certains usages en santé et construction. Ce glissement du GMSL vers la robotique répond à une contrainte système qui s'aggrave : à mesure que le nombre de capteurs embarqués augmente (caméras multiples, lidars, IMU), la gestion simultanée de la bande passante, de la latence et de la synchronisation devient le vrai goulot d'étranglement. Un décalage de quelques millisecondes entre les flux capteurs suffit à dégrader la précision de navigation. "Les robots ne font pas que voir, ils doivent décider et agir instantanément", résume Liu, ce qui impose une coordination serrée entre GPU, MPU et système d'exploitation temps réel. Dans des environnements difficiles -- vibrations, poussière, températures extrêmes, câblages longs dans des châssis compacts -- les contraintes d'ESD et d'intégrité de signal rendent les interfaces non-automotive-grade insuffisantes. Le GMSL apporte ici une robustesse éprouvée en conditions réelles, sans surcharger les équipes d'intégration d'une couche de développement bas niveau supplémentaire. La transition depuis l'automobile n'est pas anodine sur le plan industriel. Les chaînes d'outillage ADAS ont absorbé pendant une décennie les problèmes que la robotique affronte aujourd'hui : multiples caméras synchronisées, longues distances de câblage, tolérance zéro aux pannes de perception. ADI capitalise sur cet héritage pour proposer un écosystème directement transposable, réduisant les délais d'intégration de plusieurs mois à quelques semaines selon Advantech. Les concurrents directs sur ce segment -- notamment les acteurs proposant des solutions basées sur MIPI CSI-2 ou USB3 Vision -- restent pertinents pour les robots opérant en conditions contrôlées, mais peinent à répondre aux contraintes des déploiements extérieurs ou mobiles à longue durée. Les prochaines étapes portent sur l'extension vers les humanoïdes et les plateformes agricoles, segments où la densité sensorielle et la rugosité environnementale font du GMSL un candidat naturel face aux architectures plus conventionnelles.

UEL'adoption du GMSL dans les AMR et robots industriels concerne indirectement les intégrateurs et fabricants européens confrontés aux mêmes contraintes de synchronisation multi-capteurs dans leurs architectures de vision embarquée.

InfrastructureOpinion
1 source
Construction d'un jeu de données robotique modélisée comme un processus de build par artefacts
4arXiv cs.RO 

Construction d'un jeu de données robotique modélisée comme un processus de build par artefacts

Des chercheurs de l'Université de la Bundeswehr Munich (UniBwTAS) ont publié Bagzel, une extension open source pour le système de build Bazel qui modélise la construction de jeux de données robotiques comme un processus basé sur des artefacts et un graphe de dépendances. Présenté sur arXiv (référence 2606.00162), l'outil convertit des enregistrements ROS bag en jeux de données prêts pour l'entraînement ML, avec export natif au format nuScenes. Les auteurs évaluent Bagzel et une variante Bagzel-xattr (gestion des digests côté serveur) contre un pipeline séquentiel de référence rosbag2nuscenes, sur des volumes de 5,1 à 20,4 Go. En mode warm build (recalcul sur données déjà traitées), Bagzel atteint une accélération jusqu'à 386,26x par rapport au baseline séquentiel ; en mode incrémental (après modification partielle du dataset), le gain est de 7,21x. Bagzel-xattr réduit en outre le temps d'exécution de 5,9 % en moyenne par rapport à Bagzel standard. Le goulet d'étranglement que cible Bagzel est bien connu des équipes de robotique appliquée : les scripts séquentiels ad hoc imposent de recalculer l'intégralité du dataset à chaque modification, allongeant les cycles d'itération de plusieurs heures. En appliquant les principes de reproductibilité et de build incrémental du génie logiciel au traitement de données capteurs multimodales, Bagzel rend viable l'exploration rapide de paramètres de preprocessing, le débogage de pipelines de perception, et la maintenance de datasets versionnés de manière déterministe. Pour un intégrateur ou une équipe de recherche manipulant régulièrement des dizaines de gigaoctets de données capteurs, réduire le temps de rebuild d'un facteur plusieurs centaines change concrètement le rythme d'expérimentation. Le format ROS bag reste le standard de facto pour l'enregistrement de données capteurs (lidar, caméra, IMU) en conditions réelles, tant en recherche qu'en industrie, mais sa conversion vers des formats ML exploitables est généralement assurée par des scripts maison non maintenables. Bagzel s'inscrit dans une tendance de professionnalisation du MLOps en robotique, un espace où des outils comme DVC ou Foxglove Studio couvrent des parties du problème sans offrir la cohérence d'un système de build unifié. Le laboratoire TAS de l'UniBwM est actif sur les thématiques de conduite autonome et de perception embarquée. Les prochaines étapes naturelles pour Bagzel concernent l'intégration avec des pipelines d'entraînement continu et l'extension à d'autres formats standardisés comme le Waymo Open Dataset.

UEL'outil est développé par l'Université de la Bundeswehr Munich (Allemagne/UE), renforçant l'outillage MLOps open source européen pour les équipes de robotique et de conduite autonome manipulant des données capteurs ROS.

InfrastructureOpinion
1 source