Wie man die Roboter-Daten-Sammlung auf mehr als 10.000 Demonstrationen skaliert

[← Forschung]

Von Pilotprojekten mit einer einzigen Station bis zu Flotten mit mehreren Laboren die für die gesamte Politikbildung erforderliche Infrastruktur, Betriebsmanagement und Qualitätssysteme.

Warum es schwer ist, zu skalieren

Die Sammlung von 200 Demonstrationen ist ein Ingenieurprojekt. Die Sammlung von 10.000 ist ein Betriebsproblem. Die Engpässe verschieben sich vollständig: Sie debuggen auf kleinem Maßstab Hardware und Aufgabenspezifikation; auf großem Maßstab verwalten Sie Operator-Durchsatz, Datenpipeline-Verlässlichkeit und Cross-Lab-Konsistenz.

Die Robotik-Community lernte dies auf die harte Weise, Datenmengen wie DROID (76.000 Flugbahnen, 22 Roboter, 13 Labore) und Open X-Embodiment (1M+ Episoden, 22 Robotertypen) zu bauen.

Durchsatz von Betriebsmitteln

Die größte Einschränkung für die Datenerfassungsschnelligkeit ist der Betriebsleistung. Ein qualifizierter Betriebsleiter, der eine mittelständische Aufgabe (L2L3 auf unserer [Schwierigkeitsskala] T1)) durchführt, führt täglich 3080 Demonstrationen durch. Um 10.000 Demo-Demos in 8 Wochen (40 Arbeitstage) zu erreichen, benötigen Sie:

• Bei 50 Demo-Sendungen/Betreiber/Tag: 5 Betreiber, die 40 Tage lang gleichzeitig laufen
• Bei 30 Demo-/Betreiber-/Tag (schwieriger Aufgabe): 9 Betreiber für 40 Tage
• Plus 2030% Puffer für die Ablehnung der Qualitätssicherung: 12 weitere Betreiber hinzufügen

Die Herausforderung ist die Beschaffung, Ausbildung und Aufrechterhaltung von 512 gleichzeitigen Betreibern, während die Qualität hoch gehalten wird.

Verteilte Sammlung Architektur

Über die einzelne Laborskala hinaus (~ 200 Demo's/Woche) benötigen Sie eine verteilte Sammlung über mehrere Stationen oder Labore hinweg.

• Geteilte Datensehe: Alle Labors schreiben Episode-Dateien in einen gemeinsamen S3-Eimer mit einem standardisierten HDF5-Schema. Episode-Metadaten (Betriebs-ID, Roboter-Serial, Zeitstempel, Aufgaben-ID, Erfolgs-Label) werden bei Abschluss der Episode atomar geschrieben. Vermeiden Sie pro Lab-Schema, die eine Post-Hoc-Normalisierung erfordern.
• Hardware-Standardisierung: Die Verwendung identischer Kamera-Modelle, Montagepositionen und Roboterkonfigurationen auf allen Standorten. Auch geringfügige Kamera-Positionsunterschiede (510 cm) schwächen die politische Ausbildung zwischen den Standorten. Veröffentlichen Sie ein Kalibrierprotokolldokument und führen Sie Fernüberprüfungssitzungen durch.
• Task-Anweisungsprotokoll: Standardisierte Aufgabenkarten mit Fotos, Objekte-Platzierungsschablonen (lasergeschnittener Acryl-Träger funktionieren gut) und Videobeispiele für richtige und falsche Ausführung. Ohne diese entwickeln Betreiber an verschiedenen Standorten subtil unterschiedliche Interpretationen der Aufgabe.
• Echtzeitüberwachungs-Dashboard: Verfolgen Sie Demo-/Stunden, Erfolgsrate und aktive Betreiber pro Standort auf einem geteilten Dashboard. Dies stellt Probleme auf Standortebene (Hardware-Fehler, Betreiberverwirrung) vor, bevor sie ein erhebliches Budget verbrauchen.

Qualitätsmanagement des Betreibers im Rahmen

Das Qualitätsmanagement ist der Unterschied zwischen einem Datensatz, der eine Arbeitspolitik ausbildet, und einem, der es nicht tut.

• Demonstrationen des Goldstandards: Sammeln Sie 2050 "Gold" Demos pro Aufgabe von Ihrem besten Betreiber. Verwenden Sie diese als Qualitätsreferenz. Berechnen Sie automatisch die Ähnlichkeitswerte (DTW auf gemeinsamen Bahnen, Erfolgsquote Korrelation) zwischen neuen Betreiberdemos und Goldstandards.
• ** Inter-Rater-Verlässlichkeit:** Für subjektive Erfolgs-Labels, haben zwei Rezensenten unabhängig 10% der Episoden zu label. Messen Sie Cohen's Kappa. Ziel κ > 0,8. Wenn Kappa unter 0,7 ist, sind Ihre Erfolgskriterien zweideutig und müssen verfeinert werden.
• Betriebsnehmer-Scorecards: Überwachen Sie die Erfolgsrate, Ablehnungsrate und Durchsatz pro Betreiber wöchentlich.
• Incentivstrukturen: Bonusse pro Qualität (nicht pro Volumen) verhindern, dass die Betreiber sich beeilen. Ein Bonus von 0,10€ zu 0,25€ pro akzeptierten Demo (über einer Qualitätsschwelle) übertrifft die Stundenkompensation für Datenqualität.

Datenpipeline-Infrastruktur

Bei mehr als 10.000 Episoden ist manuelles Datenverarbeiten nicht möglich. Sie benötigen eine automatisierte Pipeline von der Episode-Fassung bis hin zu trainierbaren Tensoren.

• Episodeformat: HDF5 mit einem standardisierten Schema (Beobachtungsgruppe: Kamerabilder, proprioception; Aktionsgruppe: gemeinsame Geschwindigkeiten oder Endefektor-Delta; Metadatengruppe: Aufgabe, Operator, Zeitstempel).
• Automatische Validierung: Bei Einnahme laufen: (1) Schemavalidierung, (2) Dauerprüfung (Verweigerung von Episoden <2 oder >120 für die meisten Aufgaben), (3) Kontrollen der Verletzung der gemeinsamen Grenzwerte, (4) Abfall der Kamera (Schwarze Rahmen).
• Versioning: Verwenden Sie DVC (Data Version Control) oder ein benutzerdefiniertes Manifest-System, um Datenversionen zu taggen.
• Vorverarbeitung: Beim Training sollten Bildgrößenumbau, Normalisierung und Erweiterung aus dem Roh HDF5 angewendet werden, die nicht in die gespeicherten Daten gebacken werden.

Qualitätsfilterung im Maßstab

Selbst bei gutem Betreibermanagement haben Sie 20~40% der Episoden, die nicht in den Trainingsatz gehen sollten.

• ** Erfolgsklassifikator:** Trainieren Sie einen leichten binären Klassifikator (ResNet-18 oder ähnlich) auf einem manuell gekennzeichneten Teilstück von 5001,000 Episoden, um den Erfolg/Fehler aus dem letzten Rahmen zu prognostizieren.
• Trajektorie outlier detection: Berechnen Sie Statistiken pro Episode (maximale Gelenkschnelligkeit, Trajektorie-Länge, Aktionsentropie).
• Verschiedenheitsprobe: Nach dem Filtern überprüfen Sie, ob Ihr Trainingsset über alle Aufgabenvarianten, Objektpositionen und Operatorstile verfügt.

Wirkliche Zahlen aus der Industrie

Dataset	Trajectories	Labs / Sites	Robot Types	Collection Period
DROID (Stanford)	76,000	13 labs	1 (Franka)	~8 months
Open X-Embodiment	1,000,000+	22 institutions	22 types	Aggregated 2016–2023
ALOHA-2 (Stanford)	1,500	1 lab	1 (ALOHA-2)	3 months
BridgeData V2	60,000	4 lab configs	1 (WidowX)	~12 months
RoboSet (UT Austin)	20,000	1 lab	1 (Franka)	4 months

Der DROID-Datensatz ist die Goldstandardreferenz für die verteilte Datenerhebung. Ihr [Technischer Bericht] T2) dokumentiert das Kalibrierungsprotokoll, das Datenformat und die Qualitätsfilterleitung im Detail. Für Teams, die ein Multi-Lab-Programm erstellen, ist es erforderlich, es zu lesen.

Die [Daten-Sammelplattform] T3 von RCSV implementiert die in diesem Artikel beschriebene Architektur Episode-Streaming, automatisiertes QA, Operator-Dashboards und S3-gestütztes Versionen-Speicher als verwalteter Dienst verfügbar.

Skalieren Sie Ihr Datenerhebungsprogramm

RCSV betreibt eine verteilte Datenerhebung mit mehr als 50 geschulten Betreibern, automatisierten QA-Pipelines und verwalteter Infrastruktur. Wir liefern 10K+ Demonstrationen in 48 Wochen.

Erforschung der Datendienste →