Exécution d'une boucle DAgger sur un SO-100 avec une politique VLA

Votre policy s'exécute. Elle tend la main vers le cube, ferme le gripper un centimètre trop tôt, et continue comme si elle l'avait saisi. Rien ne génère d'erreur, et aucune quantité de fixation sur la perte d'entraînement ne l'explique. La solution n'est pas un autre 20 000 étapes de gradient sur les mêmes démonstrations. Elle est de remettre votre main sur le bras exactement où elle se trompe, enregistrer ce que vous avez fait à la place, et entraîner le prochain checkpoint sur les anciennes données plus cette correction. C'est une ronde DAgger, et voici comment en exécuter une sur un SO-100 avec une policy vision-language-action.

La théorie est ailleurs : pourquoi l'agrégation de données fonctionne du tout et ce que le contrôle humain change à ce sujet. C'est le manuel d'opération, et il suppose un checkpoint entraîné, un ensemble de caméras fonctionnel, et un bras qui bouge. Les six étapes ci-dessous sont la boucle telle qu'implémentée sur la page DAgger de cette plateforme, mais la séquence est la même à partir de vos propres scripts.

Pourquoi la deuxième ronde n'est pas juste plus de données

Le clonage de comportement s'entraîne sur les états qu'un humain a visités. Au moment du test, la policy visite les états qu'elle provoque, et les petites erreurs d'action se composent en états qu'aucune démonstration ne couvrait. Ross, Gordon et Bagnell ont formalisé cet échec pour AISTATS 2011 et y ont répondu avec un algorithme itératif qui entraîne une policy déterministe stationnaire et, sous leur réduction, doit performer bien sous la distribution d'états qu'elle induit : exécuter la policy actuelle, faire étiqueter par l'expert les états qu'elle a réellement atteints, les ajouter au dataset, réentraîner, répéter. Kelly et al. ont rendu la requête pratique avec HG-DAgger, où l'humain décide quand reprendre le contrôle au lieu d'étiqueter des états sans tenir les contrôles ; ils signalent des performances améliorées par rapport à DAgger et au clonage de comportement sur une tâche de conduite autonome simulée et réelle. Le contrôle humain est ce qui rend la boucle tolérable sur un bras de bureau - vous ne bougez les mains que quand quelque chose se trompe.

Deux conséquences importent plus en pratique que la théorie ne le fait. Les corrections ne sont pas des démonstrations ordinaires : elles se concentrent dans les régions de goulot d'étranglement que Mandlekar et al. décrivent, où une petite déviation fait tomber la policy dans des états que les démonstrations ne couvraient jamais. Et un dataset composé uniquement de ces parties difficiles est un dataset mal formé - Belkhale, Cui et Sadigh soutiennent du côté des données que la diversité d'état n'est pas toujours bénéfique, et que la divergence d'action et la diversité de transition décident ensemble de la qualité du dataset. Le dataset mixte n'est pas un compromis, c'est l'intérêt.

Geler ceux-ci avant la première ronde

Une ronde DAgger compare une policy à elle-même dans le temps. Tout ce que vous changez entre les rondes qui n'est pas le dataset rend cette comparaison sans sens.

• Positions et montages de caméra, caméra de poignet comprise. Desserrez un seul collier et vous avez changé la distribution d'observation, pas la policy.
• Exposition et balance des blancs, si votre pile de capture vous permet de les fixer. La dérive d'exposition automatique entre les rondes est un décalage de domaine lent et invisible.
• Étalonnage du bras et positions zéro des servos. Si vous devez ré-étalonner, traitez tout ce qui a été enregistré avant comme un dataset séparé.
• Le texte de la tâche. Chaque VLA ici se conditionne sur celui-ci ; le reformuler au cours de la boucle est une tâche différente.
• Éclairage, surface de la table, ensemble d'objets. Un nouvel objet est une nouvelle expérience, pas la ronde suivante.
• La fréquence d'images d'enregistrement. Comparer les taux d'intervention sur deux grilles d'échantillonnage produit des différences qui proviennent de la grille.

La ronde, de bout en bout

1. 1
   Exécuter l'inférence et l'enregistrer

   Démarrer l'exécution par rapport au checkpoint que vous voulez améliorer, puis démarrer l'enregistrement dans la racine d'inférence. Enregistré de cette façon, il hérite du texte de la tâche de l'exécution elle-même, qui est ce sur quoi la policy a été entraînée, plutôt que l'étiquette de téléopération par défaut. Sans l'enregistrement, vous pouvez regarder l'échec mais pas l'entraîner.

   bash

   # two calls, not one: the run, then its recording
   POST /inference/start      # model_id, and hf_repo_id = the checkpoint to drive
   POST /recording/start      # root=inference
   # root=inference also makes the recording inherit the run's task text

2. 2
   Reprendre le contrôle quand c'est mal

   Appuyez sur Reprendre le contrôle et choisissez le mode d'entrée : bras leader, clavier ou curseurs. Le runner pause, vous corrigez, vous remettez. Les images enregistrées pendant que vous conduisiez sont marquées comme interventions automatiquement.

   bash

   POST /inference/takeover/start   # input = leader | keyboard | sliders
   POST /inference/takeover/nudge   # keyboard, relative delta per call
   POST /inference/takeover/set     # sliders, absolute target
   POST /inference/takeover/stop    # back to the policy

3. 3
   Trier les épisodes

   Décidez par épisode : classer comme correction, conserver comme évaluation, ou supprimer. Une exécution que la policy a complétée sans aide est une donnée d'évaluation.

4. 4
   Synchroniser le dataset de correction

   Les corrections s'accumulent dans un dataset local par policy et vont au stockage en cloud via la synchronisation automatique. Rien n'est mélangé que ce que vous n'avez pas mis là.

5. 5
   Composer le dataset mixte

   Combiner le dataset original avec le dataset de correction, en choisissant les épisodes explicitement par source. Le résultat est un dataset ordinaire à partir de là.

   bash

   POST /training/datasets/compose
     sources  = [ original_dataset, korrekturen_<policy> ]
     episodes = explicit selection per source

6. 6
   Continuer l'entraînement à partir du checkpoint

   Entraîner le mélange à partir du checkpoint précédent plutôt que du modèle de base. Notez quel checkpoint et quel mélange ; sans cette paire, la ronde n'est pas reproductible.

   bash

   # field on the training job
   base_checkpoint = s3://ay-robots/checkpoints/<run>/<checkpoint>
   # the platform passes it to the training pod as BASE_CKPT_S3

Étape 2 en détail : les deux façons de reprendre le contrôle

Avec un bras leader

En mode leader-follower, la reprise est une reprise entre deux bras qui ne sont pas dans la même pose. Appuyer sur Reprendre le contrôle met en pause le runner et conduit le leader sur la pose actuelle du follower, donc rien ne saute quand le couple se transfère. Si ce lecteur d'alignement dépasse, vous alignez le leader à la main et ne relâchez que si les deux sont dans cinq degrés. À partir de là, vous téléopérez normalement et la colonne d'action enregistre ce que vous avez commandé.

Soyez honnête à ce sujet : le lecteur d'alignement et la reprise du couple sont la partie la moins testée de la boucle sur le matériel réel. Testez la reprise sur une pose lente et inoffensive avant de vous y fier dans une exécution qui vous importe. Un bras leader produit les corrections les plus lisses des trois modes, et a aussi le plus qui peut mal tourner mécaniquement.

Sans bras leader : clavier et curseurs

La plupart des gens lisant ceci possèdent un bras. C'est assez. Choisissez clavier ou entrée curseur au moment où vous appuyez sur Reprendre le contrôle, et la reprise est immédiate et manuelle - il n'y a pas de deuxième bras pour s'aligner, donc il n'y a pas d'étape d'alignement. Le follower tient sa pose et attend l'entrée.

Les serrages sont appliqués côté serveur, pas dans l'interface, car un delta mal tapé sur un bras à servos de bus est une collision. Les corrections au clavier sont par étapes et légèrement grossières ; les corrections par curseurs sont plus lisses, car le serveur marche vers la cible tandis que l'interface garde le streaming. Dans les deux cas, la colonne d'action reçoit le vecteur de pose complète commandée et le marquage d'intervention est identique au chemin leader, donc les corrections au clavier sont dans le même dataset sans différence de format.

Q / A   joint 1      R / F   joint 4
W / S   joint 2      T / G   joint 5
E / D   joint 3      Z / X   gripper

Quand appuyer sur le bouton

Tôt plutôt que tard. Une correction qui commence après que le gripper ait fermé sur rien enseigne la récupération d'un échec que la policy ne devrait pas avoir entré, et les données de récupération valent bien moins que les données d'évitement. Interrompez au premier moment où vous êtes confiant que la trajectoire est fausse, corrigez à travers la partie difficile, remettez dès que l'état en est un que la policy a géré auparavant. ThriftyDAgger automatise cette décision en gâtant les interventions sur la nouveauté et le risque estimé sous un budget humain fixe, mais sur un seul bras avec un humain déjà observant, la porte humaine est moins chère et mieux calibrée que tout ce que vous accorderez.

Étape 3 en détail : le tri décide de la qualité

Après l'exécution, vous avez un enregistrement avec des images marquées comme interventions. Trois destinations existent, et la mauvaise empoisonne silencieusement la ronde suivante.

• Classer comme correction quand l'intervention était une correction réelle : la policy se dirigeait quelque part de mal et votre entrée a montré le bon à partir d'un état que la policy elle-même a produit.
• Garder comme évaluation pour les exécutions autonomes propres et pour les exécutions sur lesquelles vous avez repris le contrôle par prudence. Les épisodes d'évaluation sont comment vous mesurez le prochain checkpoint, et ils ne doivent jamais être entraînés.
• Supprimer les exécutions ruinées par quelque chose d'indépendant - une image de caméra lâchée, un servo bloqué, un objet que vous avez heurté. Une correction désordonnée est pire que pas de correction.

Étape 5 en détail : composer le mélange

La composition prend le dataset original plus le dataset de correction et produit un nouveau, ordinaire dataset LeRobot qui entraîne comme tout autre. La propriété importante est que la sélection d'épisode est explicite par source - rien n'est mélangé automatiquement. Cela semble mineur jusqu'à la première fois qu'une policy se comporte étrangement et vous devez reconstruire sur quoi elle a été entraînée.

La question ouverte est le ratio, et personne n'a de nombre qui transfère. Ce que la littérature convient est que les corrections doivent compter pour plus que leur partage d'image. Mandlekar et al. réentraînent de manière itérative sur les données que leur système d'intervention collecte, donc la policy apprend à traverser les goulots d'étranglement, et signalent que les agents entraînés de cette façon surpassent les agents entraînés sur un nombre équivalent d'échantillons de démonstrateurs non-interventionnels. Sirius va plus loin et ré-pèse les échantillons d'entraînement par confiance humaine approximée, signalant un gain de 8 % en simulation et 27 % sur matériel réel dans le taux de succès de la policy par rapport aux méthodes avec lesquelles il se compare, à deux fois la vitesse de convergence. Aucun des points d'entrée d'entraînement ici n'expose un bouton de pondération d'échantillon, donc le substitut brut est de garder chaque épisode de correction tout en sous-échantillonnant les démonstrations originales - et d'écrire ce que vous avez fait.

Étape 6 en détail : ce que continuer à partir d'un checkpoint signifie vraiment

Entraîner le mélange à partir du modèle de base fonctionne mais jette la ronde précédente et coûte une exécution complète. Continuer à partir du checkpoint précédent est plus rapide et généralement meilleur. C'est aussi plus limité que la phrase ne le suggère.

La latence se compose dans une boucle DAgger d'une manière qu'elle ne le fait pas pendant une démo : à environ 485 ms par étape d'action, vous reprenez le contrôle parce que le bras a hésité, pas parce que c'était faux, et les données de récupération d'hésitation ne sont pas utiles pour l'entraînement. Si vous itérez sur des données plutôt que de chasser un taux de succès final, itérez sur un modèle rapide. Shukor et al. décrivent SmolVLA comme conçu pour entraîner sur un seul GPU et déployer sur des GPUs de consommateur ou des CPUs, avec une pile d'inférence asynchrone qui découple la prédiction d'action de l'exécution pour permettre des taux de contrôle plus élevés - la propriété qui maintient une boucle de reprise sensible.

Les formats de dataset ne sont pas interchangeables non plus. GR00T prend LeRobot v2.0 ou v2.1, et le dépôt Isaac-GR00T décrit son entrée comme une saveur du format LeRobot v2 avec un fichier de description de modalité ajouté ; les entraîneurs plus récents ici s'attendent à v3.0. Un mélange composé dans la mauvaise version échoue au chargement plutôt que de produire une mauvaise policy - le meilleur mode d'échec, toujours une fente de file d'attente gaspillée. Le documentation du dataset liste quel format chaque entraîneur prend.

Quatre façons de gaspiller une ronde

1. Entraîner uniquement sur les corrections

L'échec le plus courant et le raccourci le plus tentant. Un dataset correction-only est presque entièrement le milieu difficile de la tâche, avec l'approche et la retraite manquantes ; la policy s'améliore dans la partie difficile et oublie comment y arriver. L'agrégation n'est pas un détail d'implémentation de la méthode, c'est le mécanisme : les anciennes données sont ce qui maintient le reste du comportement en place tandis que les corrections bougent une partie de celui-ci.

2. Déplacer une caméra entre les rondes

Une caméra qui se déplace de deux centimètres entre les rondes produit une policy pire que celle avec laquelle vous avez commencé, et un diagnostic qui coûte une journée. Chaque VLA ici se conditionne sur les images ; l'état articulaire seul ne désambigu pas où se trouve l'objet. Photographiez la configuration avant la première ronde et vérifiez cette photographie avant chacune ultérieure.

3. Laisser les artefacts de reprise dans l'entraînement

Couvert ci-dessus, et sur la liste parce qu'il est invisible. Le symptôme est une policy qui stalle pour une fraction de seconde exactement où l'opérateur de la ronde précédente a repris le contrôle. Cela ressemble à de l'hésitation ; c'est de l'imitation.

4. Appeler un démarrage chaud une reprise

Si vous croyez que l'état d'optimiseur s'est transmis, le pic de perte initial se lit comme un bug et vous allez chasser les données corrompues. Si vous savez que l'optimiseur a commencé frais, le pic est attendu et vous regardez ce qui vient après. Mêmes chiffres, conclusions opposées.

Mesurer la ronde

La métrique pour une boucle pilotée par humain est le taux d'intervention : images enregistrées tandis que vous étiez en contrôle, divisées par les images totales de l'exécution. C'est dans l'état de reprise, et c'est le seul nombre qui répond à la question que la ronde a posée. La perte d'entraînement baisse, que la policy s'améliore ou non ; le taux de succès est binaire et bruyant aux tailles d'échantillon qu'un bras de bureau produit. Le taux d'intervention est continu, mesuré sur les états que la policy elle-même a causés, et il baisse tandis que la policy a besoin de vous de moins.

Comparez-la uniquement sur les exécutions enregistrées dans des conditions identiques. L'argument complet, et comment construire un ensemble d'évaluation qui survit plus de deux rondes, est dans l'article sur la mesure d'une boucle DAgger. La première ronde est réalistement un test de faisabilité : vous vérifiez que la reprise fonctionne sur votre matériel, que les corrections arrivent avec leurs drapeaux, et que l'exécution continuée a chargé le checkpoint que vous avez nommé. Les deuxième et troisième rondes sont où le taux devrait commencer à bouger. S'il n'a pas bougé à la quatrième ronde, le problème est en amont de DAgger.

Si vous n'avez pas encore de checkpoint

La boucle n'a pas de point d'entrée sans celui-ci. Enregistrez un premier dataset, entraînez une première policy, exécutez-la - l'enregistrement, l'entraînement et l'exécution de la policy couvrent ce chemin. Le client d'enregistrement est sur la page de téléchargement, les niveaux GPU et les taux horaires sur la page de tarification, et à quoi un épisode utilisable ressemble dans le guide de collecte de données SO-100. Obtenez les démonstrations justes avant les corrections : DAgger est un mécanisme de réparation, et il fonctionne bien mieux sur quelque chose qui était presque correct déjà.

Rien de tout cela n'est un problème résolu et rien n'est un clic. L'apprentissage par imitation interactif est un domaine de recherche actif précisément parce que ses questions - quand intervenir, comment peser ce que l'humain a fait, combien de données anciennes garder - n'ont pas de réponses établies ; l'enquête de Celemin et al. cartographie ce qui est toujours ouvert. Ce que la boucle a est une convergence mesurable quand elle est exécutée soigneusement, sur du matériel qui coûte quelques centaines d'euros. Geler la configuration, intervenir tôt, trier honnêtement, composer délibérément, et enregistrer le taux d'intervention à chaque fois.