Strands Robots, LeRobot et Hugging Face : une boucle de données robotique en streaming

En robotique, le problème n’est pas seulement de collecter des démonstrations ou d’entraîner un modèle. C’est de répéter ce cycle sans déplacer sans cesse des volumes croissants de données entre le poste de collecte, le stockage et les GPU. AWS propose une réponse avec Strands Robots, LeRobot et les Hugging Face Storage Buckets : un agent unique qui enregistre, synchronise, lit les données à distance pour l’entraînement, puis redéploie une politique sur le matériel.

Le principe présenté par AWS est simple : conserver le format LeRobot de bout en bout et utiliser un bucket Hugging Face comme couche de travail partagée. L’intérêt est moins de promettre une automatisation complète de la recherche robotique que de réduire les frictions techniques dans une boucle de collecte et d’itération fréquente.

Le coût caché des boucles de collecte et d’entraînement

Une campagne de données robotique génère rapidement un cycle répétitif : enregistrer des épisodes, les déposer dans un dépôt distant, télécharger le jeu complet sur une machine d’entraînement, produire un checkpoint, le transférer vers le robot, puis recommencer. À mesure que le dataset grossit, les mêmes octets peuvent circuler plusieurs fois.

La démonstration d’AWS vise précisément cette situation. Les épisodes sont enregistrés au format LeRobotDataset, puis synchronisés vers un Hugging Face Storage Bucket. Selon la source, les synchronisations suivantes n’envoient que les octets modifiés. Le dataset peut ensuite être relu depuis le Hub, image par image, avec décodage vidéo à la demande, sans copie locale complète.

Cette architecture s’appuie sur les Storage Buckets de Hugging Face, décrits dans la source comme un type de dépôt de stockage objet mutable, non versionné et fondé sur Xet. Ils vivent dans le même espace de noms hf:// que les autres dépôts Hugging Face et s’utilisent avec le CLI hf.

Un même objet Robot() pour enregistrer, relire et déployer

Strands Robots est un SDK open source d’AWS sous licence Apache 2.0. Il expose des abstractions robotiques, la simulation et la pile LeRobot sous forme d’outils composables dans un agent Strands. Dans l’exemple, Robot("so100") crée l’objet utilisé tout au long de la boucle.

Ce même objet peut servir à enregistrer une démonstration en simulation, à relire le dataset distant, puis à exécuter une politique. Le catalogue évoqué par la source ne se limite pas au bras SO-100 : la fabrique Robot() résout des noms via un registre comprenant notamment des bras, des humanoïdes, des bases mobiles et des mains. L’article s’appuie toutefois sur le SO-100, et mentionne aussi le déploiement sur un SO-101 dans le billet précédent de la série.

from strands import Agent
from strands_robots import Robot

sim = Robot("so100")
agent = Agent(tools=[sim])

agent("Record a pick-the-cube demo and sync it to my-org/robot-fave.")

for batch in sim.stream_dataset(
    "my-org/robot-fave/cube_pick",
    repo_type="bucket"
).dataloader(batch_size=64):
    ...

Le code illustre bien la promesse d’interface : l’agent reçoit une consigne en langage naturel pour lancer une démonstration et sa synchronisation. Ensuite, stream_dataset() fournit les données au chargeur de lots pour l’entraînement. L’extrait ne détaille pas la fonction d’entraînement elle-même, ni les critères permettant à l’agent de décider qu’un nouveau modèle est suffisamment bon pour être déployé.

Le streaming évite le téléchargement intégral, pas le travail de gouvernance

La lecture distante est l’élément le plus concret pour les équipes qui entraînent régulièrement. Au lieu de rapatrier l’intégralité du dataset avant chaque run, le chargeur lit les frames depuis le Hub et décode la vidéo au fil de l’eau. Cela peut limiter les copies locales et les transferts redondants sur les jeux de données qui évoluent progressivement.

Mais cette optimisation ne remplace pas les décisions opérationnelles. La source souligne elle-même qu’il faut déterminer quels épisodes conserver, quand les conditions de scène ont suffisamment dérivé pour justifier de nouvelles captures, si le volume collecté permet un entraînement, et quel checkpoint doit remplacer celui déployé sur le bras.

L’agent est proposé comme couche de coordination pour enchaîner ces décisions et les actions associées. Il faut néanmoins rester précis : l’article décrit un mécanisme et un exemple de boucle, pas une méthode validée pour garantir la qualité des démonstrations, la sûreté d’un déploiement physique ou la performance d’une politique. Ces sujets dépendront du robot, de la tâche, des données et des règles de validation mises en place par l’équipe.

Simulation par défaut : utile pour intégrer, insuffisant pour valider une politique

Le chemin minimal fonctionne sur Linux ou macOS, y compris sur Apple Silicon pour le backend MuJoCo, avec Python 3.12 ou plus. Il faut également un fournisseur de modèles compatible avec Strands : Amazon Bedrock, Anthropic, OpenAI ou Ollama en local sont cités. L’installation indiquée est la suivante :

uv pip install -U "strands-robots[sim-mujoco,lerobot]>=0.5.1"

D’après la source, l’extra lerobot installe notamment LeRobot, datasets, av et torchcodec, afin de permettre l’enregistrement et le décodage vidéo. La voie par défaut tourne sur un ordinateur portable et en simulation.

Attention toutefois : AWS précise que cette configuration utilise une politique simulée (« mock policy »). Elle produit un dataset valide, mais pas une politique utile. Pour les buckets, le matériel réel et les politiques réelles, la source indique qu’un compte Hugging Face, un jeton doté des droits d’écriture et le CLI Hugging Face sont nécessaires. L’extrait fourni ne donne pas davantage de détails sur la configuration matérielle ou sur le protocole de mise en production.

Comment évaluer cette boucle dans ton propre stack

Si tu veux tester l’approche sans surinterpréter la démonstration, commence par un flux limité : une tâche simulée, un dataset identifiable, un bucket isolé et une lecture en streaming vérifiable. Contrôle ensuite les éléments qui comptent réellement dans ton contexte :

• la compatibilité de ton pipeline d’entraînement avec le format LeRobot ;
• le comportement réseau et le débit de lecture avec tes vidéos et ta taille de batch ;
• la stratégie de sélection, d’annotation et d’archivage des épisodes ;
• les critères mesurables qui autorisent un checkpoint à passer sur le matériel ;
• les garde-fous nécessaires avant toute exécution sur un robot réel.

La proposition est intéressante pour unifier une chaîne aujourd’hui souvent fragmentée : agent, robot, données et stockage parlent le même format et sont accessibles depuis les mêmes primitives. Sa valeur dépendra surtout de la discipline ajoutée autour : qualité des données, évaluation des politiques et contrôle du déploiement. Le streaming réduit les déplacements inutiles ; il ne dispense pas de piloter rigoureusement la boucle d’apprentissage.