Der Aufbau eines Roboterdaten-Flugwheels: Von der ersten Demo bis zur kontinuierlichen Verbesserung
Wie führende Roboterteams Datenrollen bauen <unk> Sammeln, trainieren, einsetzen, Fehler erkennen, sammeln mehr. Ein praktischer Leitfaden für das kontinuierliche Roboterlernen.
[← Führer]
Die Teams, die beim Roboter-Lernen gewinnen, sind nicht die mit den meisten Daten
Was ist ein Roboter-Daten-Flugrad?
Ein Datenruder ist eine sich selbst verstärkende Schleife, in der der Einsatz Ihres Roboters die Daten erzeugt, die Sie benötigen, um ihn zu verbessern, was den Roboter fähiger macht, was mehr Einsatzmöglichkeiten erzeugt, was mehr Daten erzeugt.
Das Konzept ist von Softwareunternehmen geliehen
Unternehmen, die die fähigsten Roboter im Jahr 2026 bauen
Warum die meisten Labors beim Flywheel scheitern
Die meisten Robotiklabore sammeln Daten in einem Sprung, trainieren eine Politik, bewerten sie und erklären dann entweder Erfolg oder sammeln eine andere undifferenzierte Reihe von Demonstrationen. Der entscheidende Unterschied ist die Targeting: Ein Flugrad zielt speziell auf die durch den Einsatz enthüllten Fehlermodi ab, anstatt mehr Daten für Bedingungen zu sammeln, die die Politik bereits gut verarbeitet.
Der Flugradschleier
Das Roboter-Daten-Flugrad besteht aus sechs Stufen, die einen kontinuierlichen Zyklus bilden:
1. Sammeln
Die
Zug 2
Die
3. Ausrüstung
Die
4. Monitor
Die
- Erkennen von Ausfällen
Die
6. Sammeln Sie mehr
↑ Rückkehr in Stufe 2: Zug
Die Stufen 1
Phase 1: Samendataset (50200 Demonstrationen)
Die Datenbank der Saatgut-Anlage erstellt Ihre Basispolitik. Das Ziel ist keine Produktions-Reit-Politik
Wie "gut genug für die erste Ausbildung" aussieht
- ** Aufgabenbereich:** Beginnen Sie mit der einfachsten sinnvollen Version Ihrer Ziel Aufgabe. Wenn das Ziel ist "gemischte Gegenstände in Behälter sortieren", beginnen Sie mit "ein bekanntes Objekt auswählen und in einem Behälter platzieren". Entfernen Sie Variabilität: feste Positionen, kontrollierte Beleuchtung, einzelner Objekttyp.
- Demo-Zählung nach Algorithmus: ACT: 50
200 Demos. Diffusionspolitik: 100 300. VLA-Fein-Tune (OpenVLA/Octo): 50 100 mit vorgeübter Basis. Sammeln Sie bis zu Ihrem Validierungs-Erfolgsrate Plateaus, nicht bis Sie eine runde Zahl erreichen. - Betriebs-Konsistenz: Verwenden Sie 1
3 ausgebildete Betreiber, nicht verschiedene Crowdsourced-Betreiber. Vielfalt hilft später. - Quality Gate: Überprüfen Sie jede Episode, bevor Sie das Training einfügen. Ablehnen Sie Episoden mit: Betreiberzweifel > 2 Sekunden, fehlender Erfassung, die durch erneute Annäherung wiederhergestellt wird (es sei denn, speziell erhebt man Wiederherstellungsdaten), Kamera-Beschleierung des Manipulationspunkts oder unvollständige Aufgabenführung. Siehe unseren [Daten-Erhebung-Leitfaden]
T2 ) für das vollständige QA-Protokoll.
Zeitplan für die Samen-Daten-Satz
Bei einem erfahrenen Betreiber und einer validierten [Teleoperations-Einstellung] erwarten Sie 40
Phase 2: Erste Einführung und Überwachung
Nach dem Training auf dem Saatdatensatz, die Richtlinie in Ihrer Testumgebung zu implementieren. Dies ist keine Produktionsimplementierung
Teleoperationsschattenmodus
Bevor die vollständig autonome Bereitstellung, führen Sie die Politik im Schattenmodus: Die Politik prognostiziert Aktionen, aber der Betreiber behält eine Teleoperationsüberschrift. Wenn die Politik ist im Begriff, zu versagen, übernimmt der Betreiber und vollendet die Aufgabe. Log sowohl die vorhergesagten Aktionen der Politik und die Korrekturmaßnahmen des Betreibers
Der Schattenmodus dient zwei Zwecken: Er erzeugt Schulungsdaten aus der tatsächlichen Verteilung des Staates der Politik (die Staaten, in denen die Politik in Schwierigkeiten gerät) und bietet eine sichere Bewertung des Verhaltens der Politik, bevor das menschliche Sicherheitsnetz entfernt wird.
Leistungsüberwachung
Während der Bereitstellung, loggen Sie für jede Episode Folgendes:
- ** Vollständige Aufnahme der Folge:** Gemeinsame Positionen, Kamerabilder, Aktionen und Zeitstempeln
identisches Format wie die Trainingsdaten. - Ergebnisetikett: Erfolg, Ausfall oder Betreiberintervention. Wenn möglich, automatisch kennzeichnen (z.B. Erfolg = Objekt, das in der Zieltone durch eine Oberkamera erkannt wird).
- Fehlerkategorie: Wenn die Episode gescheitert ist, klassifizieren Sie die Fehlerkategorie: Greifenfehler, Platzierungsfehler, Kollision, Timeout, Wiederherstellungsfehler, Ausverteilungszustand. Diese Kategorien führen Phase 3 durch.
- Version der Richtlinie: Tag jede Episode mit dem Modell-Checkpoint, der sie erzeugt hat.
Verlust der Logging-Infrastruktur
Das minimal praktikable Fehlerprotokollsystem ist eine CSV-Datei mit Spalten: Episode_id, Timestamp, Policy_version, Outcome, Failure_category, Noten. Die RCSV Data Platform bietet ein visuelles Dashboard für die Episode-Tagging, die Fehlerkategorisierung und die Trendüberwachung, aber eine Tabelle funktioniert für frühe Teams.
Phase 3: Ausfall der Bergbau
Das Ausfall-Mining ist die Kerninnovation, die das Flugrad funktioniert. Anstatt weitgehend mehr Demonstrationen zu sammeln, identifizieren Sie die spezifischen Ausfallmodi, die die Leistung einschränken, und sammeln Daten, die sich direkt an diese Modi richten.
Die Prioritäten zu erkennen
Nach 50
- ** Häufigkeit:** Welcher Fehlermodus tritt am häufigsten auf?
- Fixbarkeit: Einige Fehler können mit Daten adressiert werden (die Politik hat diesen Zustand nie gesehen). Andere erfordern Hardwareänderungen (der Roboter kann das Ziel nicht physisch erreichen). Konzentrieren Sie sich auf die Datenerhebung auf Fehler, die mehr Demonstrationen beheben können.
- Impact: Ein Fehlermodus, der 100% der Versuche einer bestimmten Objektvariante blockiert, hat eine höhere Priorität als ein Fehlermodus, der auf allen Varianten zu intermittierenden Fehlern führt.
Annotationsstrategien
- Zeitstempel-Anmerkung: Für jede Ausfallphase markieren Sie den Zeitstempel, in dem der Ausfall begann.
- Status-Anmerkung: Beschreiben Sie den Zustand am Fehlerpunkt: "Objekt wurde 45 Grad gedreht, Griff aus dem falschen Winkel angeholt". Dies orientiert die Datenerhebungstrategie für Korrekturdemos.
- Clusteranalyse: Gruppenversagen durch visuelle Ähnlichkeit am Fehlerpunkt. Wenn 20 Versagen alle zeigen, dass der Roboter das Objekt auf die gleiche Weise fehlt, stellt dieser Cluster eine einzige adressierbare Lücke in der Trainingsverteilung dar.
Phase 4: Zielvorgabe der Datenerhebung
Anstatt 200 weitere generische Demonstrationen zu sammeln (die eine abnehmende Rendite bieten), sammeln Sie 30
Sammeln für bestimmte Fehlermodus
- Grasp-Fehler: Setzen Sie die Szene in Konfigurationen ein, in denen die Politik fehlgeschlagen ist. Teleoperate erfolgreiche Demonstrationen aus diesen spezifischen Zuständen. Verändern Sie den Ansatzwinkel und die Griffzeit, um die Fehlzonen zu decken.
- Platzierungsfehler: Beginnen Sie die Demonstration in einem Zustand, in dem das Objekt bereits erfasst ist (überspringen Sie die Ergreifphase).
- ** Wiederherstellungsdemonstrationen:** Laufen Sie die Politik, bis sie einen fast fehlerhaften Zustand erreicht (z.B. etwas falsch erfasstes Objekt). Übernehmen Sie die Aufgabe über Teleoperation und demonstrieren Sie die Wiederherstellung. Diese "Erholungsdemonstrationen" sind die hochwertigsten Daten pro Episode
eine Politik mit 50 Wiederherstellungsdemonstrationen plus 150 sauberen Demonstrationen übertreibt eine Politik mit 500 sauberen Demonstrationen auf Robustheitströmen. - Kanten-Fall-Abdeckung: Wenn Fehler an bestimmten Objektpositionen oder -orientierungen gruppiert werden, sammeln Sie Demonstrationen, die diese Positionen speziell abdecken. Verwenden Sie eine physische Vorlage oder ein Raster, um eine einheitliche Abdeckung der Fehlerregion zu gewährleisten.
Zielvorgaben und allgemeine Verbesserungen
Ein häufiger Fehler ist es, "mehr von allem" zu sammeln, anstatt Fehler zu zielen. Die Mathematik ist klar: 100 Demonstrationen gleichmäßig zu addieren, die die Politik bereits behandelt, bietet eine vernachlässigbare Verbesserung. 30 Demonstrationen in der spezifischen Region zu addieren, in der die Politik versagt, kann die Erfolgsrate für diesen Fehlermodus um 15
Infrastrukturanforderungen
Ein funktionierendes Flugrad erfordert eine Infrastruktur, die über die grundlegende Datenerhebung hinausgeht.
Datenpipeline
- Episode-Speicher: Alle Einsatz-Episoden (nicht nur Trainingsdaten) müssen mit vollständigen Aufnahmen und Metadaten gespeichert werden.
- **Episode-Tagging:**Episoden nach Typ: "Seed", "Targeted-recovery", "deployment-success", "deployment-failure", "autocollected". Ihr Trainings-Skript sollte das Filtern nach Tag unterstützen.
- Automatische Einnahme: Neue Episoden sollten ohne manuelle Dateikopierung vom Sammel- oder Bereitstellungsmaschinen zum Trainingsdatensatz fließen.
Modellversion
- Kennzeichnen Sie jeden ausgebildeten Kontrollpunkt mit: Datensatzversion, Hyperparametern, Ausbildungsdatum und Validierungsmessungen.
- Loggen Sie, welche Version der Richtlinie jede Einführungsepisode erzeugte. Diese Kette ist für die Debug-Performance-Regressionen unerlässlich ("Politik v3 war schlimmer als v2
was sich geändert hat?"). - Halten Sie mindestens die letzten 5 Kontrollpunkte zur Verfügung, um die Rückführung zu ermöglichen.
Automatisierte Weiterbildung
- Konfigureren Sie ein Skript, das das Verzeichnis Ihres Datensatzes auf neue Episoden überwacht und einen Traininglauf auslöst, wenn eine neue Reihe von N Episoden (typischerweise 25
50) verfügbar ist. - Verwenden Sie einen Arbeitsplaner (cron, Ray oder Modal) um über Nacht Umschulung durchzuführen, damit neue Richtlinien für die Einsatzsitzung des nächsten Morgens bereit sind.
- Nach jedem Training läuft automatisch eine standardisierte Bewertung (20 Rolls in Simulation oder Wiedergabe) und die Ergebnisse am Checkpoint.
Monitoring Dashboard
Verfolgen Sie diese Metriken im Laufe der Zeit:
- Erfolgsrate nach Politikversion (ist das Flugrad tatsächlich verbessert?)
- Verteilung des Ausfallmodus nach Richtlinienversion (wirken gezielte Lösungen funktionieren?)
- Die pro Rotation des Flugrads gesammelten Episoden (kürzen die Sammelanstrengungen?)
- Zeit von der Fehlererkennung bis zur erneuten Ausbildungspolitik (Ihre Zykluszeit)
Messwerte zu verfolgen
| Metric | What It Measures | Target | Red Flag |
|---|---|---|---|
| Success rate | % of deployment episodes that succeed | Increasing each rotation | Flat or decreasing after new data |
| Generalisierung score | Success rate on unseen conditions vs. seen conditions | >0.7 ratio | <0.5 (severe overfitting) |
| Data efficiency curve | Success rate improvement per N new episodes | Diminishing returns curve visible | No improvement despite more data |
| Cost per successful episode | Total collection cost / number of new successes | Decreasing each rotation | Increasing (flywheel is stalling) |
| Cycle time | Days from failure detection to retrained policy | <1 week | >2 weeks (pipeline bottleneck) |
| Failure mode coverage | % of identified failure modes with targeted data | >80% by rotation 3 | Same failure mode persists after 2 targeted collections |
Häufige Fallstricke
1. Verteilung Schicht Akkumulation
** Was passiert:** Bei jeder Rotation des Flugrads werden gezielte Daten für bestimmte Ausfallmodi hinzugefügt. Im Laufe der Zeit wird die Trainingsverteilung stark zu Randfällen und Wiederherstellungsszenarien verzerrt. Die Politik beginnt bei den "einfachen" Fällen, die sie verwendet hat, um gut zu handhaben, zu scheitern.
Fix: Halten Sie ein Verhältnis von 60
2. Annotationsunvereinbarkeit
** Was passiert:** Verschiedene Teammitglieder klassifizieren Versagen unterschiedlich. Eine Person bezeichnet einen fast miss-Griff als "Erfolg", ein anderer als "Griff-Fehler". Die Versagenstatistiken werden unzuverlässig, und gezielte Sammlung wird falsch geleitet.
Fix: Schreiben Sie explizite Anmerkungen mit Beispielfildern für jede Fehlerkategorie. Verwenden Sie binäre Erfolge/Niederlagen als primäre Kennzeichnung (schwieriger zu disagree), mit Fehlerunterkategorien als sekundäre Kennzeichnungen. Führen Sie monatlich die Vereinbarung zwischen den Anmerkern durch. Erfordern 90%+ Vereinbarung über Erfolge/Niederlagen Kennzeichnungen.
3. Hardware-Drift
** Was passiert:** Während der Wochen des Betriebs entwickeln sich die Robotergelenke eine Rückwirkung, das Greifergummi schwächt ab, die Kameraanlagen lockern sich leicht.
Fix: Führen Sie eine Kalibrierprüfung zu Beginn jeder Einsatzwoche durch: Befehle dem Roboter auf 5 bekannte Konfigurationen und überprüfe, ob die Gelenkpositionen innerhalb von 0,5 Grad übereinstimmen. Überprüfe die Griffkraft mit einem Kraftmessgerät. Überprüfe die Kamera-Extrinsics mit einem ArUco-Board. Protokoll Kalibrierungsergebnisse zusammen mit Episodendaten. Wenn Hardware-Wartung erfolgt, sammeln Sie 20
4.. Erhebung von mehr Daten für gelöste Aufgaben
** Was passiert:** Der häufigste Fehler des Flugrads. Das Team sammelt weitere 200 Demonstrationen für Bedingungen, die die Politik bereits mit einer Erfolgsrate von 90% behandelt, weil diese Demonstrationen leicht zu sammeln sind.
Fix: Bevor jede Sammelungssitzung beantwortet: "Welchen spezifischen Fehlermodus zielen ich auf?" Wenn Sie keinen nennen können, führen Sie zuerst 10 Richtlinien ein und identifizieren Sie den häufigsten Fehler.
Fallstudie: Manipulationsstart von 0 bis 10.000 Episoden
Diese hypothetische Fallstudie zeigt eine realistische Flugradprogression für ein Startup, das ein Müll-Pick-System baut:
Monat 1: Samendatensatz
Das Team verwendet einen einzigen ViperX-300 S2 mit Führungskräfte-Follower-Teleoperation. Ein erfahrener Operator sammelt 200 saubere Demonstrationen, ein einzelnes bekanntes Objekt aus einem Binn zu holen und auf einen Transportgerät zu legen. Aufgabe: kontrollierte Beleuchtung, ein einzelner Objekttyp, feste Binnposition. Sie trainieren eine ACT-Politik. Ergebnis: 55% Erfolgsrate im kontrollierten Setup.
Monat 2: Erste Mining-Rotation
Die Auswahl von Fehlern: 45%-Fehler (Objektorientierung variiert mehr als die von den Ausbildungsdaten abgedeckten Daten), 30%-Fehler bei der Platzierung (Toleranz zu eng für die Position des Transportbandes), 25%-Timeout (Politik bleibt im Ansatz fest). Sie sammeln 60 zielgerichtete Demo-Systeme: 30 für verschiedene Objektorientierungen, 20 für präzise Platzierung, 10 für Ansatzwiederherstellung.
Monat 3: Ausweitung der Allgemeinheit
Sie führen 5 zusätzliche Objekttypen (verschiedene Formen, Größen, Gewichte) ein. Die erste Erfolgsrate sinkt auf 35% auf neue Objekte. Sie sammeln 150 Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-Demo-D
Monat 4: Aktives Lernen
Sie implementieren Unsicherheitsschätzung (Sammlung von 3 Richtlinien). Bereiten mit Unsicherheitsprotokolle ein. Wenn Unsicherheit die Schwelle überschreitet, markieren Sie den Zustand für menschliche Demonstration. Sie sammeln 80 Unsicherheitszielte-Demos
Monat 56: Skalierung und automatische Sammlung
Die Politik ist jetzt oft genug erfolgreich für die autonome Sammlung. Sie laufen den Roboter 8 Stunden über Nacht mit automatischer Erfolgserkennung (Overhead-Kamera überprüft die Platzierung von Objekten). Der Mensch überprüft 20% der automatisch gekennzeichneten Episoden. Ergebnis: 91% Erfolgsrate bei bekannten Objekten, 78% bei neuartigen Objekten.
Monat 712: Produktion von Flywheel
Zwei Roboterstationen sammeln während der Auftaktzeiten kontinuierlich. Wöchentlich wird mit gezielten Daten aus den Fehlern dieser Woche neu ausgebildet. Monatlich wird es auf neue Objektkategorien ausgebaut. Bis zum Monat 12: 10.000+ Episoden, 95% Erfolg bei bekannten Objekten, 85% bei neuartigen Objekten derselben Kategorie. Das Flugrad ist mit ungefähr 5 Stunden menschlicher Aufsicht pro Woche selbstständig.
Wann man RCSV gegen In-House-Build verwendet
| Scenario | RCSV | In-House |
|---|---|---|
| Seed dataset (first 200 demos) | Faster — our operators are trained, hardware is calibrated | Good if your team needs to learn the data collection process |
| Targeted failure-mode data | Strong — we specialize in collecting edge-case data efficiently | Requires operator training for each failure mode |
| Scaling to 1,000+ episodes | Cost-effective — we provide shifts, QA, and infrastructure | Good if you have dedicated operators and hardware |
| Hardware you don't own yet | Lease from RCSV — try before buying | Requires capital outlay upfront |
| Bimanual or dexterous data | Specialized — we operate ALOHA and glove systems | Significant hardware and operator investment |
| Continuous flywheel operation | Hybrid: RCSV handles collection, you handle training/deployment | Best if you have a dedicated data ops team |
Zeitlinie: Von Bootstrap bis zum selbsttragbaren Flugrad
| Month | Phase | Activity | Expected Outcome |
|---|---|---|---|
| Month 1 | Seed | 200 clean demos, 3 training runs | 40–60% success on controlled setup |
| Month 2 | Failure mining | 100 deployment episodes, 60 targeted demos | 65–80% success, failure modes identified |
| Month 3 | Generalisierung | 150 demos with object/position variation | 70–80% success across 3x variation range |
| Month 4 | Active learning | 80 uncertainty-guided demos | >80% success, equivalent to 300 random demos |
| Month 5 | Auto-collection pilot | Autonomous collection, 20% human review | Validated auto-labeling; 200 episodes/day |
| Month 6+ | Self-sustaining | Continuous auto-collection + weekly retraining | 90%+ success; continuous improvement |
Beschleunigen Sie Ihr Daten-Flugrad mit RCSV
RCSV bietet zielgerichtete Datenerhebung, Fehler-Recovery-Demonstrationen, Episode-QA und Pipeline-Lieferung für Teams, die Daten-Flugrad-Programme betreiben. Wir sammeln die Demos, die Sie brauchen, nicht die Demos, die Sie bereits haben.