InfrastructurearXiv cs.RO6sem

ICAN-Deploy : déploiement canari à identité stable pour agents incarnés en environnements critiques

1 source couvre ce sujet·Source originale ↗·

Résumé IASource uniqueImpact UE

Des chercheurs présentent ICAN-Deploy (Identity-stable CANary Deployment), un middleware conçu pour faire évoluer le logiciel de robots certifiés sans invalider leur certification. Le principe du déploiement canary, router une fraction du trafic vers une nouvelle version, surveiller des métriques, puis rollback si régression, est standard en DevOps cloud. Problème : les contrôleurs du marché, Argo Rollouts, Spinnaker et Flagger, modifient l'identité cryptographique du système durant la fenêtre de transition. Ce drift est inoffensif pour des microservices sans état, mais rompt pour les robots l'assurance réglementaire centrale : "l'agent certifié est l'agent déployé". ICAN-Deploy sépare les noms de capacités, figés et hachés dans le manifeste, des versions de capacités, un état runtime mutable, maintenant ainsi le hash d'identité invariant tout au long du cycle. Les auteurs valident l'invariance par preuve formelle, lint AST et model-checking TLA+, puis corroborent sur N=100 cycles canary dans un environnement MuJoCo simulant un bras Franka Panda : zéro drift observé, latence d'entrée 95% BCa CI [1,52 ; 2,01] ms.

L'enjeu est structurel pour l'industrie. Dans les secteurs à certification obligatoire (médical, aérospatial, industrie lourde), chaque mise à jour logicielle d'un robot peut déclencher un cycle de revalidation de plusieurs semaines. ICAN-Deploy renverse la logique : certifier une architecture de déploiement plutôt que chaque version individuelle. Un système certifié une fois peut ensuite évoluer librement dans l'enveloppe nom-version définie, sans recertification formelle. C'est un déblocage potentiel pour le continuous delivery sur robots en environnement de production. Le "strawman" alternatif testé, qui incorpore les versions dans le manifeste d'identité, échoue systématiquement sur les mêmes workloads, renforçant la valeur de la comparaison.

La gestion du cycle de vie logiciel des agents physiques reste un angle mort du secteur robotique. Ce travail s'inscrit dans la tendance émergente du "runtime governance" pour LLMs et agents incarnés, cherchant à réconcilier l'agilité du software moderne et les contraintes de sûreté des systèmes physiques. Le Franka Panda, standard de fait en recherche sur la manipulation depuis le rachat d'Emika GmbH par Agile Robots, facilite la reproductibilité des résultats. Le papier est un preprint arXiv (arXiv:2605.28097v1), non encore peer-reviewed, et les métriques restent à confirmer sur hardware réel hors simulation. Les étapes naturelles : intégration dans ROS 2 ou OpenRMF, et validation du modèle "certifier l'architecture, pas la version" par des organismes de certification sectoriels.

Impact France/UE

L'approche pourrait alléger les cycles de recertification imposés aux robots opérant dans les secteurs réglementés européens (médical, aérospatial, machinerie) au regard de la Directive Machines et des dispositions à hauts risques du règlement IA.

Dans nos dossiers

arXiv cs.RO

À lire aussi

1arXiv cs.RO

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

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.

InfrastructureOpinion

1 source

2arXiv cs.RO

Kairos : un système de déploiement extensible pour l'IA physique

Une équipe de chercheurs publie sur arXiv (référence 2605.11381, mai 2025) les spécifications de Kairos, un système d'inférence conçu pour les flottes de robots pilotées par des modèles de fondation. Kairos se positionne comme le premier système de serving multi-robot à intégrer nativement la boucle generate-execute, soit l'enchaînement asynchrone entre les phases d'inférence et d'exécution motrice propre à l'IA physique. Sur un ensemble de modèles et de plateformes robotiques, le système annonce une réduction de la latence bout-en-bout de 31,8 à 66,5 % par rapport aux pratiques de serving issues du monde de l'IA digitale, avec des gains qui s'accroissent avec la taille de la flotte déployée. L'argument central des auteurs tient à une inadéquation structurelle. Les systèmes actuels comme vLLM, TensorRT-LLM ou Triton ont été conçus pour les LLM textuels : ils traitent une requête jusqu'à complétion, sans état intermédiaire. L'IA physique fonctionne différemment : le modèle génère des blocs d'actions (action chunks) à chaque round d'inférence, le robot commence à exécuter pendant que le bloc suivant est calculé, et plusieurs cycles se succèdent sur une même tâche. Cette asynchronicité, ignorée par les serveurs digitaux classiques, crée un goulot d'étranglement critique pour les flottes industrielles. Si les chiffres se confirment en conditions réelles, les intégrateurs y gagneraient des cycles de contrôle plus courts et une capacité de scaling horizontal sans surcoût infrastructure proportionnel. Le contexte explique l'urgence de cette contribution. Depuis 2024, les modèles de fondation pour robots prolifèrent : Pi-0 de Physical Intelligence, GR00T N2 de NVIDIA, Helix de Figure AI. Ces VLA (Vision-Language-Action) ont franchi des seuils de généralisation inédits, mais l'infrastructure de déploiement n'a pas suivi le même rythme. Kairos tente de combler ce fossé côté serving. Il s'agit néanmoins d'un preprint non revu par les pairs : les benchmarks ne sont pas détaillés dans l'abstract, les modèles et robots de test ne sont pas nommés, et aucun déploiement en production n'est déclaré. Les métriques annoncées méritent donc une lecture prudente en attendant une validation expérimentale indépendante.

InfrastructureOpinion

1 source

3Robotics Business Review

Robots avant déploiement : pourquoi les équipes de robotique ont besoin de salles d'entraînement virtuelles

Les robots industriels et humanoïdes butent aujourd'hui moins sur l'automatisation d'une tâche que sur l'adaptation à des environnements changeants, selon un article publié par le cabinet de conseil technologique SoftServe. Le marché mondial de la robotique devrait croître à un rythme de 19,6% par an entre 2026 et 2036, selon les chiffres cités de Future Market Insights. Pour combler l'écart entre simulation et réalité, un concept gagne du terrain dans l'industrie : le « virtual gym » (salle de sport virtuelle), un environnement de simulation haute fidélité où un robot peut s'entraîner, échouer, se corriger et être validé avant tout déploiement réel. Ces plateformes combinent jumeaux numériques, simulation physique poussée, données synthétiques, apprentissage par renforcement, modélisation de capteurs et tests hardware-in-the-loop, l'objectif étant de rendre les essais physiques plus ciblés et moins risqués. L'enjeu dépasse la technique pure : c'est un problème de mise en production. Un robot mobile évoluant en entrepôt doit composer avec un trafic qui change d'heure en heure ; un bras robotisé doit reconnaître un même produit sous des emballages, angles ou reflets lumineux différents de ceux vus à l'entraînement. Ces écarts, même mineurs, suffisent à transformer une simulation réussie en échec sur le terrain. L'apprentissage par imitation, souvent utilisé comme point de départ pratique pour la manipulation, reste dépendant de démonstrations de qualité et d'une variété suffisante de cas. Or collecter cette expérience sur du matériel réel coûte cher : arrêts de production, usure des équipements, risques pour la sécurité. Pire, les cas les plus utiles pour l'entraînement (blocages, objets lâchés, quasi-accidents, fuites, palettes endommagées, pannes de capteurs) surviennent trop rarement en conditions normales pour constituer un jeu de données exploitable. Le virtual gym permet de générer ces scénarios de façon contrôlée avant qu'ils ne se produisent en production. Reste que la fidélité de ces environnements doit être calibrée selon le mode de défaillance visé, pas maximisée par principe : un planificateur d'itinéraire pour robot mobile n'a pas besoin du même niveau de physique qu'une tâche de manipulation d'objets déformables ou qu'un robot d'inspection cherchant des défauts thermiques ou structurels. En usine, la modélisation portera sur la géométrie CAO, les fixations, le placement des caméras, l'outillage et les zones de sécurité ; en entrepôt, sur la géométrie des allées, la variabilité des références produits, les mouvements humains et le comportement de flotte. Les virtual gyms les plus aboutis combinent plusieurs approches de modélisation : physique de premiers principes pour le mouvement et les collisions, modèles résiduels pilotés par les données pour corriger les effets difficiles à capturer analytiquement, co-simulation pour coupler plusieurs solveurs (mouvement, thermique, contraintes matérielles), et modèles de substitution comme les réseaux de neurones physiquement informés pour approximer des comportements complexes plus rapidement qu'une simulation complète.

InfrastructureOpinion

1 source

4arXiv 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