Übernehmen, wenn die Policy danebengreift, und genau diese Korrektur trainieren.
Eine per Behavior Cloning trainierte Policy kennt nur die Zustände, die in den Demonstrationen vorkamen. DAgger schließt diese Lücke mit Daten aus den Zuständen, die die Policy selbst erreicht. AY-Robots fährt die vollständige Schleife am SO-100: Checkpoint fahren, mitten im Lauf übernehmen, korrigierte Episoden behalten, den Mischdatensatz zusammenstellen und vom gefahrenen Checkpoint weitertrainieren.
- HG-DAgger, menschlich getort
- SO-100 / SO-101
- ACT, SmolVLA, Pi0, GR00T N1.5 / N1.7
- Interventionsrate je Runde
Warum eine trainierte Policy etwas tut, das nie demonstriert wurde
Behavior Cloning behandelt Regelung als gewöhnliches überwachtes Lernen: Beobachtung hinein, Gelenkziel heraus, angepasst an die Frames, die ein Mensch aufgenommen hat. Das trägt nur, solange der Roboter auf den Zuständen bleibt, die dieser Mensch besucht hat, und das tut er nicht. Ein Greifer, der vierzig Millisekunden zu früh schließt, schiebt den Würfel zwei Millimeter aus der demonstrierten Lage. Die nächste Beobachtung steht so in keinem Trainingsframe, die Aktion dort ist eine Extrapolation, und der Zustand danach liegt noch weiter außerhalb. Trainingsverteilung und die Verteilung, die die gelernte Policy selbst erzeugt, sind zwei verschiedene Dinge, und die zweite entfernt sich im Lauf der Episode immer weiter von der ersten.
Ross, Gordon und Bagnell haben genau dieses Versagen 2011 beschrieben und beziffert: Ein Klassifikator, der unter der Expertenverteilung mit Wahrscheinlichkeit e irrt, kann über einen Horizont von T Schritten unter seiner eigenen Verteilung in der Größenordnung von T zum Quadrat mal e Fehler machen, weil ein Fehler Beobachtungen erzeugt, die der Experte nie hervorgebracht hat, und sich die Fehler dadurch aufschaukeln. Ihre Antwort darauf ist der Algorithmus, um den es hier geht: die aktuelle Policy fahren, für die dabei besuchten Zustände Expertenlabels sammeln, sie mit allem bisher Gesammelten zusammenlegen, neu trainieren, wiederholen. Mehr Demonstrationen derselben Art helfen nicht, denn sie ziehen aus derselben Verteilung. Labels aus den Zuständen, die die Policy erreicht, helfen. Die hier umgesetzte Variante ist menschlich getort (HG-DAgger, Kelly et al.): Die Policy behält die Kontrolle, bis ein Mensch entscheidet, dass es schiefgeht, und übernimmt. So entstehen Korrekturen nur dort, wo sie gebraucht werden, und der Arm wird nie in einen Zustand geschickt, den der Bediener nicht zulassen würde.
- Behavior Cloning gilt nur auf der Zustandsverteilung, auf der es trainiert wurde.
- Der Fehler verstärkt sich selbst: eine kleine Abweichung erzeugt einen unbekannten Zustand, der eine größere Abweichung erzeugt.
- Das Gegenmittel sind nicht mehr Demonstrationen, sondern Labels aus den Zuständen, die die Policy selbst erreicht.
- Menschlich getort heißt: der Bediener entscheidet über den Eingriff, nicht ein Unsicherheitswert.
Warum sich der Fehler aufschaukelt
Den Horizont verschieben. Unter Behavior Cloning wächst der erwartete Zusatzaufwand etwa mit dem Quadrat der Schrittzahl, weil jeder Fehler Zustände erzeugt, die die Demonstrationen nie abgedeckt haben; eine Aggregationsschleife hält das Wachstum nahe an linear (Ross et al., 2011).
Veranschaulichung der Schranken aus Ross et al. (2011), keine Messung an Ihrem Roboter. Es geht um die Form der Kurve, nicht um die Zahlen.
Eine DAgger-Runde in sechs Schritten
So läuft die Schleife tatsächlich auf der Plattform, nicht als Schema. Jeder Schritt entspricht einem Bedienelement im Cockpit.
Die Schleife Schritt für Schritt
Dieselben sechs Schritte, einzeln, mit dem, was dabei am Arm und im Datensatz passiert.
Policy fahren und mitschneiden
Einen Inferenzlauf gegen einen selbst trainierten Checkpoint starten. Der Lauf wird während der Fahrt mitgeschnitten, mit dem Aufgabentext des Laufs selbst, damit die Frames später als Trainingsdaten taugen und nicht nur als Video zum Anschauen.
Übernehmen und korrigieren
Sobald der Arm das Falsche tut: Übernehmen drücken. Der Runner pausiert, der Arm gehört Ihnen. Mit Leader-Arm fährt dieser zuerst auf die Follower-Pose und übergibt dann; mit Tastatur- oder Slider-Eingabe, beim Start des Laufs gewählt, ist die Übernahme sofort manuell. Bewegung korrigieren, dann zurück an die Policy geben. Die während der Übernahme aufgenommenen Frames werden automatisch als Intervention markiert.
Episoden sichten
Je Lauf eine Entscheidung: als Korrektur ablegen, als Evaluationslauf behalten oder verwerfen. Die Standbilder rund um die Übergabe bleiben im raw-Verzeichnis und landen nie im Datensatz.
Korrektur-Datensatz syncen
Die Korrekturen sammeln sich in einem eigenen Datensatz je Policy und gehen über den automatischen Cloud-Sync in Ihren Bucket. An dieser Stelle wird noch nichts vermischt; die Korrekturen sind zunächst schlicht ein Datensatz für sich.
Mischung selbst zusammenstellen
Über Datensatz zusammenstellen entsteht das Trainingsmaterial der nächsten Runde: Originaldatensatz plus Korrekturen, mit expliziter Episodenauswahl je Quelle. Das Ergebnis ist ein ganz normaler Datensatz. Nichts wird im Hintergrund beigemischt, und Simulationsdaten kommen nicht von allein dazu.
Vom Checkpoint weitertrainieren
Den zusammengestellten Datensatz mit Weitertrainieren von Checkpoint trainieren statt vom Basismodell, damit die Runde bei der gerade gefahrenen Policy beginnt. Präzise gesagt: Die Gewichte werden aus diesem Checkpoint initialisiert, ein Optimizer-Resume ist es nicht.
Was die Plattform Ihnen abnimmt
Jeder Punkt hier ist ein Schritt der Schleife, den Sie sonst selbst bauen und pflegen müssten.
Übernahme ohne Leader-Arm
Beim Start des Laufs Tastatur- oder Slider-Eingabe wählen, dann genügt ein Laptop zum Korrigieren. Tastatur-Nudges klemmt der Server hart auf zwei Grad je Gelenk und vier Grad am Greifer; Slider-Ziele sind absolut, und der Server fährt je Aufruf höchstens sechs Grad in ihre Richtung. Die Klemmung sitzt im Server, nicht in der Oberfläche, eine hängende Taste kann den Arm also nicht werfen.
Teleoperation in den DocsInterventionen je Frame markiert
Jedes Frame, das während Ihrer Übernahme entsteht, trägt die Interventionsmarkierung, und die action-Spalte enthält die vollständige Sollpose. Sie pflegen keine Flag-Spalte von Hand und richten sie hinterher nicht an Frame-Indizes aus.
LeRobot-DatensatzformatSichten: Korrektur, Evaluation oder Tonne
Jeder Lauf bekommt genau eine Entscheidung auf der Speichern-Karte. Korrekturläufe speisen die nächste Trainingsrunde, Evaluationsläufe bleiben aus dem Training heraus und damit eine saubere Messung, missratene Läufe verschwinden, statt die Mischung still zu verderben.
Sessions und EpisodenMischung explizit zusammenstellen
Das Trainingsmaterial für Runde n stellen Sie zusammen: Originaldatensatz plus Korrekturen, Episoden je Quelle ausgewählt. Kein automatisches Beimischen, keine versteckten Simulationsdaten, und das Ergebnis verhält sich wie jeder andere Datensatz.
DatensätzeVom Checkpoint weitertrainieren
Ein Trainingslauf startet beim gerade gefahrenen Checkpoint statt beim Basismodell, jede Runde beginnt also dort, wo die letzte endete. Initialisiert werden nur die Gewichte, der Optimizer-Zustand wird nicht wiederhergestellt; deshalb ist Runde eins am besten als Machbarkeitstest zu behandeln.
TrainingGPUs stundenweise je Runde
ACT und SmolVLA auf einer 4090, Pi0 und GR00T N1.5 oder N1.7 auf einer A100 mit 80 GB. Sie starten eine Runde, der Pod fährt hoch, die Checkpoints landen in Ihrem Bucket, und bezahlt werden die Stunden, die die Runde gebraucht hat.
GPU-PreiseRunden planen
Die Interventionsrate ist die Fortschrittsmetrik der Schleife: korrigierte Frames geteilt durch Frames des Laufs. Startwert und Verbesserung je Runde einstellen und sehen, wie viele Runden bis zum Ziel nötig wären.
| Runde | Interventionsrate | Korrigierte Frames |
|---|---|---|
| 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 | |
Ein Modell, keine Prognose. Echte Runden verlaufen sprunghaft, und eine Runde, die die Rate nicht bewegt, hat nichts gebracht; genau darauf lohnt sich der Blick.
Selbst bauen oder hier fahren
Nichts davon ist von Hand unmöglich. Es ist eine Frage, wie viele Abende in Infrastruktur statt in Runden fließen, und es gibt eine Zeile, in der die Handarbeit klar vorn liegt.
| Schritt der Schleife | Von Hand aufsetzen | Über AY-Robots |
|---|---|---|
| Mitten im Lauf übernehmen | Leader-Arm oder eigener Code auf dem Servo-Bus. Tastatur- und Slider-Übernahme samt sicherer Begrenzung schreiben und debuggen Sie an echter Hardware. | Leader-Arm, Tastatur oder Slider, beim Start des Laufs gewählt. Die Winkelklemmen sitzen im Server. |
| Interventionen markieren | Sie legen die Flag-Spalte an, halten sie am Frame-Index ausgerichtet und prüfen sie nach jeder Formatänderung erneut. | Jedes während der Übernahme aufgenommene Frame ist automatisch markiert, mit der Sollpose in der action-Spalte. |
| Läufe sortieren | Verzeichniskonventionen und Shell-Skripte. Die Standbilder rund um die Übergabe müssen Sie selbst finden und aussortieren. | Eine Entscheidung je Lauf auf der Speichern-Karte. Übergabe-Frames bleiben im raw-Verzeichnis. |
| Mischdatensatz bauen | Merge-Skripte je Formatversion. Episodenindizes, Metadaten und Videoverweise konsistent zu halten, ist die mühsame Arbeit. | Zusammenstellen aus Original plus Korrekturen mit Episodenauswahl je Quelle; das Ergebnis ist ein normaler Datensatz. |
| Nächste Runde bei der letzten Policy beginnen | Sie verdrahten den Checkpoint selbst im Trainer und können dabei auch den Optimizer-Zustand wiederherstellen, also echt fortsetzen. | Ein Feld für den Basis-Checkpoint. Nur Gewichte: initialisiert aus dem Checkpoint, kein Optimizer-Resume. |
| Kontrolle über die Trainingsschleife | Vollständig. Eigener Loss, eigener Zeitplan, eigene Ablationen, eigene Instrumentierung, keine Plattform dazwischen. Wenn die Forschungsfrage die Trainingsschleife selbst ist, bauen Sie es von Hand. | Ein fester Weg mit einer festen Liste von Policies und den Hyperparametern, die das Formular anbietet, kein beliebiger Code. |
Die Arbeiten, auf denen das steht
Vor dem Streit über die Schleife bitte diese lesen. Jeder Link führt auf die Abstract-Seite, nicht hinter eine Bezahlschranke.
- 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)
Die DAgger-Originalarbeit: benennt das Problem der Fehlerakkumulation, gibt die T-Quadrat-Schranke für den rein überwachten Ansatz an und schlägt vor, Daten aus den vom Lerner selbst besuchten Zuständen zu aggregieren.
- HG-DAgger: Interactive Imitation Learning with Human Experts
Michael Kelly, Chelsea Sidrane, Katherine Driggs-Campbell, Mykel J. Kochenderfer · 2019 · arXiv:1810.02890, ICRA 2019
Die menschlich getorte Variante: Der Experte entscheidet, wann er übernimmt, statt zu Zuständen befragt zu werden, die die Policy gewählt hat; genau dieser Modus ist hier umgesetzt.
- EnsembleDAgger: A Bayesian Approach to Safe Imitation Learning
Kunal Menda, Katherine Driggs-Campbell, Mykel J. Kochenderfer · 2019 · arXiv:1807.08364, IROS 2019
Der andere Weg, Eingriffe zu steuern: Uneinigkeit im Ensemble als Vertrauensmaß dafür, wann der Lerner allein fahren darf. Lehrreicher Gegenentwurf dazu, das einen Menschen entscheiden zu lassen.
- 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
Behandelt die Aufmerksamkeit des Menschen als knappe Ressource und fragt nur bei neuartigen oder riskanten Zuständen nach; die passende Sicht, wenn eine Person den Arm einen ganzen Nachmittag betreut.
- DART: Noise Injection for Robust Imitation Learning
Michael Laskey, Jonathan Lee, Roy Fox, Anca Dragan, Ken Goldberg · 2017 · CoRL 2017
Die ehrliche Alternative: statt die Policy im Betrieb zu korrigieren, die Demonstrationen stören, damit der Experte das Zurückfinden vorführt. Kennenswert, bevor man sich auf Eingriffe festlegt.
- 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
Die Landkarte des Felds: welche Formen menschlichen Feedbacks es gibt, über welche Schnittstellen sie laufen und wo Eingriffe nach DAgger-Art darin stehen.
- Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware
Tony Z. Zhao, Vikash Kumar, Sergey Levine, Chelsea Finn · 2023 · arXiv:2304.13705
Die ACT-Arbeit. Action Chunking ist der Grund, warum ein günstiger Arm überhaupt von einer Imitationspolicy gefahren werden kann, und ACT ist die Policy, mit der sich eine DAgger-Runde am schnellsten durchspielen lässt.
- π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
Ein VLA auf Basis von Flow Matching und einem vortrainierten Vision-Language-Modell, hier als Checkpoint zum Finetunen verfügbar; die Arbeit sagt ausdrücklich, dass neue Fähigkeiten aus dem Finetuning kommen, nicht aus dem Basismodell allein.
Häufige Fragen
Brauche ich für DAgger einen Leader-Arm?
Nein. Beim Start des Laufs Tastatur- oder Slider-Eingabe wählen, dann ist die Übernahme ab dem ersten Frame manuell und läuft im Browser. Ein Leader-Arm ist für feine Bewegungen angenehmer und der einzige Modus, in dem der Arm sich vor der Übergabe selbst angleicht; die Schleife läuft aber auch ohne.
Wie viele DAgger-Runden brauche ich?
Eine ehrliche feste Zahl gibt es nicht. Maßgeblich ist die Interventionsrate: Fällt sie von einer Runde zur nächsten nicht, hat die Runde nichts gebracht, und die Ursache liegt meist im Aufbau der Aufgabe, in den Kameras oder im Originaldatensatz und nicht in der Rundenzahl.
Ist das echtes DAgger oder nur so ähnlich?
Es ist HG-DAgger, die menschlich getorte Variante. Klassisches DAgger befragt den Experten zu Zuständen, die die Policy gewählt hat, darunter Zustände, in die niemand einen echten Arm fahren lassen würde. Hier entscheidet ein Mensch über den Eingriff, und nur diese Segmente werden zu Labels.
Trainiere ich nur auf den Korrekturen?
Nein, und das wäre auch keine gute Idee. Nur auf Korrekturen trainiert, entsteht eine Policy, die ausschließlich das Zurückfinden beherrscht. Der zusammengestellte Datensatz besteht aus den Originaldaten plus den Korrekturen, mit expliziter Episodenauswahl je Quelle.
Setzt Weitertrainieren von Checkpoint den Trainingslauf fort?
Es initialisiert die Gewichte aus diesem Checkpoint. Der Optimizer-Zustand wird nicht wiederhergestellt, im strengen Sinn ist es also kein Fortsetzen. In der Praxis tragen die Gewichte das gelernte Verhalten über die Runde, aber man sollte wissen, welches von beidem man bekommt.
Wie wird die Interventionsrate berechnet?
Als Intervention markierte Frames geteilt durch die Gesamtzahl der Frames des Laufs. Sie steht im Takeover-Status und ist die eine Zahl, die je Runde notiert gehört, zusammen mit dem gefahrenen Checkpoint und der trainierten Mischung.
Mit welchen Policies läuft die Schleife?
ACT, SmolVLA, Pi0 sowie GR00T N1.5 und N1.7. Die Schleife selbst ist von der Policy unabhängig, weil sie nur Datensätze und Checkpoints erzeugt; praktisch unterscheiden sich die Modelle in der Dauer einer Runde und in der nötigen GPU.
Geht das auch ohne eigenen Roboter?
Aufnehmen und trainieren geht ohne: über gekaufte Datensätze auf dem Marktplatz oder über beauftragte Operatoren, und einen echten SO-100 können Sie auf der Live-Seite im Browser fahren. Eine DAgger-Runde ist etwas anderes, sie braucht einen Arm, den Sie mitten im Lauf übernehmen können. Für die Schleife selbst gehört also Hardware auf den eigenen Tisch.
A real SO-100, live in the browser. No signup, no hardware needed.
Die erste Runde diese Woche fahren
Client installieren, einen vorhandenen Checkpoint fahren und beim ersten Danebengreifen übernehmen. Dieser eine Lauf ist eine DAgger-Runde im Kleinen; alles danach ist Mischung zusammenstellen und GPU-Stunden bezahlen.