Reprenez la main quand la policy se trompe, puis entraînez-la sur votre correction.
Une policy entraînée par behavior cloning ne connaît que les états visités par vos démonstrations. DAgger comble cet écart avec des données issues des états que la policy atteint elle-même. AY-Robots fait tourner la boucle complète sur un SO-100 : piloter un checkpoint, reprendre la main en cours de run, garder les épisodes corrigés, composer le mélange, puis poursuivre l'entraînement depuis le checkpoint que vous venez de piloter.
- HG-DAgger, à déclenchement humain
- SO-100 / SO-101
- ACT, SmolVLA, Pi0, GR00T N1.5 / N1.7
- Taux d'intervention par itération
Pourquoi une policy entraînée fait quelque chose qui n'a jamais été démontré
Le behavior cloning traite la commande comme un apprentissage supervisé ordinaire : une observation en entrée, une cible articulaire en sortie, ajustée sur les frames enregistrées par un humain. Cela ne tient que tant que le robot reste sur les états visités par cet humain, ce qui n'est pas le cas. Une pince qui se ferme quarante millisecondes trop tôt déplace le cube de deux millimètres par rapport à la pose démontrée. L'observation suivante ne figure alors dans aucun frame d'entraînement, l'action qui en découle est donc une extrapolation, et l'état d'après s'écarte encore davantage. La distribution d'entraînement et la distribution que la policy apprise induit réellement sont deux choses différentes, et la seconde s'éloigne de la première à mesure que l'épisode avance.
Ross, Gordon et Bagnell ont décrit exactement cet échec de réduction en 2011 et en ont chiffré l'ampleur : un classifieur qui se trompe avec une probabilité e sous la distribution de l'expert peut commettre de l'ordre de T au carré fois e erreurs sur un horizon de T pas sous la distribution qu'il induit lui-même, parce qu'une erreur produit des observations que l'expert n'a jamais générées et que les erreurs s'accumulent. Leur remède est l'algorithme dont traite cette page. Faire tourner la policy actuelle, recueillir des labels d'expert pour les états qu'elle visite, les agréger à tout ce qui a été collecté jusque-là, réentraîner, répéter. Plus de démonstrations du même genre n'aident pas, car elles rééchantillonnent la même distribution. Des labels sur les états atteints par la policy, si. La variante mise en œuvre ici est à déclenchement humain (HG-DAgger, Kelly et al.) : la policy garde le contrôle jusqu'à ce qu'une personne juge que ça tourne mal et reprenne la main, si bien que les corrections ne sont produites que là où elles sont nécessaires, et le bras n'est jamais amené à un état que l'opérateur n'autoriserait pas.
- Le behavior cloning n'est valide que sur la distribution d'états sur laquelle il a été entraîné.
- L'échec s'auto-amplifie : un petit écart produit un état inconnu, qui produit un écart plus grand.
- Le remède n'est pas plus de démonstrations, ce sont des labels sur les états que la policy atteint elle-même.
- À déclenchement humain signifie que c'est l'opérateur qui décide du moment d'intervenir, pas un score d'autonomie.
Pourquoi l'erreur s'accumule
Faites glisser l'horizon. Sous behavior cloning, le surcoût attendu croît à peu près avec le carré du nombre de pas, parce que chaque erreur produit des états que les démonstrations n'ont jamais couverts ; une boucle d'agrégation maintient cette croissance proche du linéaire (Ross et al., 2011).
Courbes illustratives tirées des bornes de Ross et al. (2011), pas des mesures de votre robot. Ce qui compte, c'est la forme, pas les chiffres.
Une itération DAgger en six étapes
Voici la boucle telle que la plateforme la fait tourner réellement, pas un schéma. Chaque étape ci-dessous correspond à un contrôle du cockpit.
Parcourir la boucle
Les six mêmes étapes, une par une, avec ce qui se passe sur le bras et dans le jeu de données à chacune d'elles.
Piloter la policy et l'enregistrer
Lancer un run d'inférence sur un checkpoint que vous avez entraîné. Le run est enregistré pendant qu'il se déroule, avec le texte de tâche du run lui-même, afin que les frames soient utilisables ensuite comme données d'entraînement plutôt que comme une simple vidéo à regarder.
Reprendre la main et corriger
Dès que le bras fait une erreur : appuyer sur Reprendre la main. Le runner se met en pause et le bras est à vous. Avec un leader arm, celui-ci se positionne d'abord sur la pose du follower avant de transmettre le contrôle ; avec une entrée clavier ou slider, choisie au début du run, la prise de contrôle est manuelle immédiatement. Corriger le mouvement, puis rendre le contrôle à la policy. Les frames enregistrées pendant la prise de contrôle sont marquées automatiquement comme interventions.
Trier le run
Décider, run par run, de ce qu'il était : le classer comme correction, le garder comme run d'évaluation, ou l'écarter. Les images figées autour d'une passation restent dans le répertoire raw et n'entrent jamais dans le jeu de données.
Synchroniser le jeu de données de corrections
Les corrections s'accumulent dans un jeu de données de corrections propre à chaque policy et partent vers votre bucket via la synchronisation cloud automatique. Rien n'est fusionné à ce stade ; les corrections forment simplement un jeu de données à part entière.
Composer le mélange vous-même
Utiliser Composer un jeu de données pour construire l'ensemble d'entraînement de l'itération suivante : le jeu de données d'origine plus les corrections, avec des épisodes choisis explicitement par source. Le résultat est un jeu de données ordinaire, qui se synchronise et s'entraîne comme n'importe quel autre. Rien n'est mélangé dans votre dos, et aucune donnée de simulation n'est ajoutée automatiquement.
Poursuivre l'entraînement depuis le checkpoint
Entraîner le jeu de données composé avec Poursuivre depuis un checkpoint plutôt que de repartir du modèle de base, de sorte que l'itération démarre depuis la policy que vous venez de piloter. Pour être précis sur ce que c'est : cela initialise les poids depuis ce checkpoint, ce n'est pas une reprise d'optimiseur.
Ce que la plateforme vous évite
Chaque point ici est une étape de la boucle que vous devriez sinon construire et maintenir vous-même.
Prise de contrôle sans leader arm
Choisissez une entrée clavier ou slider au début du run et un simple laptop suffit pour corriger. Les impulsions clavier sont bridées côté serveur à deux degrés par articulation et quatre sur la pince ; les cibles slider sont absolues, et le serveur ne déplace au plus que six degrés vers elles par appel. Les bridages sont appliqués par le serveur, pas par l'interface, donc une touche bloquée ne peut pas emballer le bras.
Docs de téléopérationInterventions marquées par frame
Chaque frame enregistrée pendant que vous tenez le bras porte un flag d'intervention, et la colonne action porte la pose commandée complète. Vous n'avez pas de colonne de flags à maintenir à la main ni à aligner après coup sur les index de frames.
Format de jeu de données LeRobotTri : correction, évaluation ou poubelle
Chaque run reçoit une décision sur la carte de sauvegarde. Les runs de correction alimentent l'itération d'entraînement suivante, les runs d'évaluation restent hors entraînement pour rester une mesure propre, et les mauvais runs disparaissent au lieu de polluer discrètement le mélange.
Sessions et épisodesComposer le mélange explicitement
L'ensemble d'entraînement de l'itération n est assemblé par vous : jeu de données d'origine plus corrections, épisodes sélectionnés par source. Pas de mélange automatique, pas de données de simulation cachées, et le résultat composé se comporte comme n'importe quel autre jeu de données.
Jeux de donnéesPoursuivre depuis un checkpoint
Pointez un run d'entraînement sur le checkpoint que vous venez de piloter plutôt que sur le modèle de base, pour que chaque itération démarre là où la précédente s'est arrêtée. Seuls les poids sont initialisés ; l'état de l'optimiseur n'est pas restauré, c'est pourquoi la première itération mérite d'être traitée comme un test de faisabilité.
EntraînementDes GPU loués à l'itération
ACT et SmolVLA sur une 4090, Pi0 et GR00T N1.5 ou N1.7 sur une A100 de 80 Go. Vous démarrez une itération, le pod se lève, les checkpoints atterrissent dans votre bucket, et vous payez les heures que l'itération a prises.
Tarifs GPUPlanifier vos itérations
Le taux d'intervention est la métrique de progression de la boucle : frames corrigées divisées par frames du run. Réglez votre point de départ et le gain de chaque itération, et voyez combien d'itérations il faut pour arriver où vous voulez.
| Itération | Taux d'intervention | Frames corrigées |
|---|---|---|
| 1 | 30.0 % | 900 |
| 2 | 22.5 % | 675 |
| 3 | 16.9 % | 506 |
| 4 | 12.7 % | 380 |
| 5 | 9.5 % | 285 |
| 6 | 7.1 % | 214 |
| Σ | 2 960 | |
Un modèle, pas une prévision. Les itérations réelles sont irrégulières, et une itération qui ne fait pas bouger le taux ne vous a rien apporté ; c'est exactement le signal à surveiller.
Construire la boucle soi-même ou la faire tourner ici
Rien de tout cela n'est impossible à la main. C'est une question du nombre de soirées englouties dans la plomberie plutôt que dans les itérations, et il y a une ligne où le faire soi-même est clairement la meilleure réponse.
| Étape de la boucle | Mis en place à la main | Sur AY-Robots |
|---|---|---|
| Reprendre la main en cours de run | Un leader arm, ou votre propre code sur le bus servo. La prise de contrôle clavier et slider, limites de sécurité comprises, c'est vous qui l'écrivez puis la déboguez sur du matériel réel. | Leader arm, clavier ou sliders, choisis au démarrage du run. Les bridages d'angle vivent dans le serveur. |
| Marquer les interventions | Vous ajoutez la colonne de flags, la maintenez alignée sur l'index des frames, et la revérifiez à chaque changement du format d'enregistrement. | Chaque frame enregistrée pendant une prise de contrôle est marquée automatiquement, avec la pose commandée dans la colonne action. |
| Trier les runs | Conventions de répertoires et scripts shell. Les images figées autour d'une passation, c'est à vous de les trouver et de les filtrer. | Une décision par run sur la carte de sauvegarde. Les frames de passation restent dans le répertoire raw. |
| Construire le jeu de données mélangé | Des scripts de fusion par version de format. Rendre cohérents les index d'épisodes, les métadonnées et les références vidéo, voilà la partie fastidieuse. | Composer à partir de l'original plus des corrections, avec sélection d'épisodes par source ; le résultat est un jeu de données normal. |
| Démarrer l'itération suivante depuis la dernière policy | Vous câblez vous-même le checkpoint dans le trainer, et vous pouvez aussi restaurer l'état de l'optimiseur si vous voulez une vraie reprise. | Un champ pour le checkpoint de base. Poids seulement : cela initialise depuis le checkpoint, ce n'est pas une reprise d'optimiseur. |
| Contrôle sur la boucle d'entraînement | Total. Votre loss, votre planning, vos ablations, votre instrumentation, aucune plateforme dans les pattes. Si la question de recherche est la boucle d'entraînement elle-même, faites-le à la main. | Un chemin fixe avec une liste arrêtée de policies et les hyperparamètres exposés par le formulaire, pas de code arbitraire. |
Les papiers sur lesquels ceci s'appuie
Lisez-les avant de contester la boucle. Chaque lien mène à la page de l'abstract, pas à une barrière payante.
- A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning
Stephane Ross, Geoffrey J. Gordon, J. Andrew Bagnell · 2011 · AISTATS 2011 (PMLR 15)
Le papier original de DAgger : il énonce le problème d'accumulation d'erreur, donne la borne en T au carré pour l'approche purement supervisée, et propose d'agréger des données issues des états visités par l'apprenant lui-même.
- HG-DAgger: Interactive Imitation Learning with Human Experts
Michael Kelly, Chelsea Sidrane, Katherine Driggs-Campbell, Mykel J. Kochenderfer · 2019 · arXiv:1810.02890, ICRA 2019
La variante à déclenchement humain : l'expert décide quand reprendre le contrôle au lieu d'être interrogé sur des états choisis par la policy, ce qui est le mode que cette plateforme met en œuvre.
- EnsembleDAgger: A Bayesian Approach to Safe Imitation Learning
Kunal Menda, Katherine Driggs-Campbell, Mykel J. Kochenderfer · 2019 · arXiv:1807.08364, IROS 2019
L'autre manière de déclencher les interventions : le désaccord d'un ensemble comme signal de confiance pour savoir quand l'apprenant peut agir seul. Un contraste utile avec le fait de laisser une personne en juger.
- ThriftyDAgger: Budget-Aware Novelty and Risk Gating for Interactive Imitation Learning
Ryan Hoque, Ashwin Balakrishna, Ellen Novoseller, Albert Wilcox, Daniel S. Brown, Ken Goldberg · 2021 · CoRL 2021
Traite l'attention humaine comme la ressource rare et ne demande de l'aide que sur des états nouveaux ou risqués, ce qui est le bon cadre quand une seule personne supervise le bras tout un après-midi.
- DART: Noise Injection for Robust Imitation Learning
Michael Laskey, Jonathan Lee, Roy Fox, Anca Dragan, Ken Goldberg · 2017 · CoRL 2017
L'alternative honnête : au lieu de corriger la policy en ligne, perturber les démonstrations pour que l'expert montre comment récupérer. Bon à savoir avant de s'engager dans les interventions.
- Interactive Imitation Learning in Robotics: A Survey
Carlos Celemin, Rodrigo Perez-Dattari, Eugenio Chisari, Giovanni Franzese, Leandro de Souza Rosa, Ravi Prakash, Zlatan Ajanovic, Marta Ferraz, Abhinav Valada, Jens Kober · 2022 · arXiv:2211.00600
La carte du domaine : quelles formes de retour humain existent, quelles interfaces les véhiculent, et où se situe l'intervention façon DAgger parmi elles.
- Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware
Tony Z. Zhao, Vikash Kumar, Sergey Levine, Chelsea Finn · 2023 · arXiv:2304.13705
Le papier ACT. L'action chunking est la raison pour laquelle un bras bon marché peut même être piloté par une policy d'imitation, et ACT est la policy la plus rapide pour boucler une itération DAgger.
- π0: A Vision-Language-Action Flow Model for General Robot Control
Kevin Black, Noah Brown, Danny Driess, Adnan Esmail, Michael Equi, Chelsea Finn et al. · 2024 · arXiv:2410.24164
Un VLA à flow matching construit sur un modèle vision-langage préentraîné, et l'un des checkpoints que vous pouvez fine-tuner ici ; le papier est explicite : les nouvelles compétences viennent du fine-tuning, pas du modèle de base seul.
Les questions qu'on pose vraiment
Faut-il un leader arm pour faire du DAgger ?
Non. Choisissez une entrée clavier ou slider au démarrage du run, et la prise de contrôle est manuelle dès la première frame, pilotée depuis le navigateur. Un leader arm est plus agréable pour les mouvements fins, et c'est le seul mode où le bras s'aligne lui-même avant la passation, mais la boucle tourne aussi sans.
Combien d'itérations DAgger faut-il ?
Il n'y a pas de chiffre fixe honnête. Surveillez le taux d'intervention : s'il ne baisse pas d'une itération à l'autre, cette itération ne vous a rien apporté, et le problème vient en général de la configuration de la tâche, des caméras ou du jeu de données d'origine, plutôt que du nombre d'itérations.
Est-ce du vrai DAgger ou une version plus relâchée ?
C'est HG-DAgger, la variante à déclenchement humain. Le DAgger classique interroge l'expert sur des états choisis par la policy, y compris des états dans lesquels aucun opérateur sain d'esprit ne laisserait aller un bras réel. Ici, c'est une personne qui décide du moment d'intervenir, et seuls ces segments deviennent des labels.
N'entraîne-t-on que sur les corrections ?
Non, et ce serait une mauvaise idée. Entraîner uniquement sur les corrections donne une policy qui ne sait que récupérer. Le jeu de données composé est constitué des données d'origine plus les corrections, avec les épisodes de chaque source choisis explicitement.
Poursuivre depuis un checkpoint reprend-il le run d'entraînement ?
Cela initialise les poids depuis ce checkpoint. L'état de l'optimiseur n'est pas restauré, ce n'est donc pas une reprise au sens strict. En pratique, ce sont les poids qui portent le comportement appris d'une itération à l'autre, mais il vaut mieux savoir lequel des deux vous obtenez.
Comment le taux d'intervention est-il calculé ?
Les frames marquées comme intervention divisées par le nombre total de frames du run. Il s'affiche dans le statut de prise de contrôle, et c'est le seul chiffre à noter par itération, à côté du checkpoint piloté et du mélange entraîné.
Avec quelles policies peut-on faire tourner cette boucle ?
ACT, SmolVLA, Pi0, et GR00T N1.5 ou N1.7. La boucle elle-même est indépendante de la policy, car elle ne produit que des jeux de données et des checkpoints ; la différence pratique tient à la durée d'une itération et au GPU qu'elle demande.
Peut-on faire cela sans posséder de robot ?
Vous pouvez enregistrer et entraîner sans robot en achetant des jeux de données sur la marketplace ou en commanditant des opérateurs, et vous pouvez piloter un vrai SO-100 dans le navigateur sur la page live. Une itération DAgger, c'est différent : il faut un bras que vous puissiez reprendre en main en cours de run, donc pour la boucle elle-même, mieux vaut avoir du matériel sur son propre bureau.
A real SO-100, live in the browser. No signup, no hardware needed.
Faites votre première itération cette semaine
Installez le client, pilotez un checkpoint que vous avez déjà, et reprenez la main la première fois que le bras dépasse le cube. Ce seul run est une itération DAgger en miniature : tout ce qui suit consiste à composer le mélange et à payer les heures de GPU.