DROID, BridgeData V2 und Open X auf einem SO-100 verwenden

Es gibt einen öffentlichen Datensatz mit einer Million Trajektorien auf einem Google Cloud Bucket und einen SO-100 auf dem Schreibtisch, der 110 bis 150 EUR an Teilen gekostet hat. Warum kann der erste den zweiten nicht lehren? Teilweise schon, aber fast keine der Übertragungen geschieht dort, wo man es erwartet, und der Teil, der am einfachsten aussieht, funktioniert überhaupt nicht.

Was folgt: was sich in DROID, BridgeData V2 und Open X-Embodiment, wo jedes mit einem kostengünstigen 5-DoF-Arm kollidiert, und was stattdessen zu tun ist. Jede Zahl unten stammt aus dem Papier, der Datensatzkarte oder der Quelldatei, zu der sie gehört.

Was die drei Datensätze tatsächlich enthalten

DROID

Der standardisierteste der drei. Ein Aufbau überall: ein Franka Panda mit einem Robotiq 2F-85 Greifer, zwei einstellbaren ZED 2 Stereokameras und einer Handgelenk-ZED Mini, teleoperiert mit Meta Quest 2 Controllern, aufgezeichnet über Polymetis mit 15 Hz sowohl im Gelenk- als auch im Endeffektor Raum. Sprachlabels kamen später über tasq.ai, bis zu drei pro Episode.

• 76k Trajektorien, 350 Stunden, 564 Szenen, 84 Aufgaben, 50 Sammler auf drei Kontinenten.
• Das Hauptergebnis ist Co-Training, nicht eigenständiges Training: Batches, die 50/50 mit In-Domain-Demonstrationen gemischt wurden, übertreffen die nächstbeste Methode um 22 Prozent absoluten Erfolg in der Verteilung und 17 Prozent außerhalb davon.
• IPEC-COMMUNITY/droid_lerobot: 92,233 episodes, 27,044,326 frames, franka, 15 fps, codebase_version v2.0, three AV1 streams at 180x320, 392 GB.
• Ein 2 GB, 100-Episoden-Debugging-Sample befindet sich unter gs://gresearch/robotics/droid_100. Beginnen Sie dort.

BridgeData V2

Am nächsten an einem Hobby-Setup: ein WidowX 250 6-DoF Arm, 60,096 trajectories across 24 environments and 13 skills at 5 Hz. Beachten Sie die Zusammensetzung: 50,365 expert teleoperated demonstrations plus 9,731 from a randomised scripted pick-and-place policy, sodass etwa 16 Prozent keine menschliche Demonstration sind, was für die Imitationslernen Qualität. Der übliche Download, IPEC-COMMUNITY/bridge_orig_lerobot, meldet 53,192 episodes and 1,893,026 frames at 5 fps, robot_type widowx: weniger als die 60,096 des Papers, lesen Sie also die Anzahl aus meta/info.json, anstatt eine der beiden zu zitieren.

Open X-Embodiment

Kein Datensatz im herkömmlichen Sinne: 60 bestehende Roboter-Datensätze von 34 Laboren wurden zu einer RLDS-Sammlung zusammengeführt, die 22 Ausführungsformen und über eine Million Trajektorien umfasst. BridgeData V2 ist darin als bridge_orig enthalten; der google_robot-Ausschnitt, fractal20220817_data, wird in 87.212 Episoden mit 3 fps umgewandelt.

Die Zusammenführung birgt einen Vorbehalt, den das Papier ausdrücklich nennt. Für die RT-X-Experimente wandeln die Autoren jede Quelle in eine 7-DoF-Endeffektoraktion um, richten jedoch die Koordinatensysteme nicht über die Datensätze hinweg aus und erlauben, dass Aktionswerte absolute oder relative Positionen oder Geschwindigkeiten sein können, je nach dem ursprünglichen Steuerungsschema jedes Roboters. Ihre Schlussfolgerung: Derselbe Aktionsvektor kann bei verschiedenen Robotern sehr unterschiedliche Bewegungen hervorrufen.

Die Diskrepanz, in vier Teilen

Die Diskrepanz in der Verkörperung wird normalerweise als ein vages Problem behandelt. Es sind vier, sie versagen unterschiedlich, und zwei sind nicht durch Skripting behebbar.

1. Freiheitsgrade

Ein SO-100 hat fünf Armgelenke plus einen Greifer. Als Motoren gezählt ist es ein 6-DoF-Arm, und das SmolVLA-Paper nennt ihn so; als Positionierungsmechanismus gezählt ist es 5-DoF, und LeRobot nennt es so in seinem Inverse-Kinematik-Docstring, der eine weiche Orientierungs-IK am 5-DOF SO-101 beschreibt, bei der das Handgelenk die Orientierung nur teilweise verfolgt. Ein Franka hat sieben Positionierungsgelenke. Diese Lücke entscheidet, welche Posen existieren: Ein 5-DoF-Arm kann im Allgemeinen nicht gleichzeitig eine beliebige Position und Orientierung erreichen, daher gibt der Solver das Nächstmögliche zurück, eine andere Bewegung als die demonstrierte. Hintergrund: .

# src/lerobot/robots/so_follower/so_follower.py
motors = {
    "shoulder_pan":  Motor(1, "sts3215", norm_mode_body),
    "shoulder_lift": Motor(2, "sts3215", norm_mode_body),
    "elbow_flex":    Motor(3, "sts3215", norm_mode_body),
    "wrist_flex":    Motor(4, "sts3215", norm_mode_body),
    "wrist_roll":    Motor(5, "sts3215", norm_mode_body),
    "gripper":       Motor(6, "sts3215", MotorNormMode.RANGE_0_100),
}
# action keys are "<motor>.pos"; send_action sync_writes them to
# "Goal_Position"  ->  a 6-D ABSOLUTE JOINT POSITION command


# openpi/src/openpi/policies/droid_policy.py
def make_droid_example() -> dict:
    return {
        "observation/exterior_image_1_left": np.random.randint(256, size=(224, 224, 3), dtype=np.uint8),
        "observation/wrist_image_left":      np.random.randint(256, size=(224, 224, 3), dtype=np.uint8),
        "observation/joint_position":        np.random.rand(7),   # seven Franka joints
        "observation/gripper_position":      np.random.rand(1),
        "prompt": "do something",
    }
# state = concat(joint_position, gripper_pos)  ->  8-D

Ein vorgefertigter DROID-Checkpoint ist also keine Abkürzung. Physical Intelligence liefert pi05_droid unter gs://openpi-assets/checkpoints/pi05_droid aus, und dieselbe README-Datei, die seine Breite lobt, warnt davor, dass diese Experten-Checkpoints möglicherweise nicht auf Ihr Setup verallgemeinerbar sind. Sein Zustand sind acht Franka-Gelenknummern und seine Bildschlüssel sind exterior_image_1_left und wrist_image_left. Kein Flag wandelt dies in einen Sechs-Motor-SO-100-Befehl um.

2. Was der Aktionsvektor tatsächlich aussagt

Tiefer als Dimensionalität. Bei den LeRobot-Konvertierungen geben alle drei an, wohin der Greifer im kartesischen Raum gehen soll. Ein SO-100 gibt an, wohin sechs Servos gehen sollen. Die Konvertierung erfordert ein kinematisches Modell und einen Solver, keine Umformung.

LeRobot liefert das fehlende Teil: Der SO-Follower verfügt über einen Kinematikprozessor mit den Schritten InverseKinematicsEEToJoints und ForwardKinematicsJointsToEE. Seine Schlüssel sind ee.x, ee.y, ee.z plus ein Rotationsvektor ee.wx, ee.wy, ee.wz und ee.gripper_pos, sodass sich sogar die Orientierungskodierung von der Roll-Pitch-Yaw in den Dateien unterscheidet. Der IK-Schritt nimmt einen orientation_weight an, Standard 0.01, dessen Docstring besagt, dass 0.0 für positionsbasierte IK bei unteraktuierte Armen eingestellt werden soll. Sie können die Brücke bauen, aber die Orientierungshälfte jeder entliehenen Aktion bleibt approximiert.

3. Regelrate

DROID ist 15 Hz, BridgeData V2 5 Hz, der google_robot-Slice 3 fps; die Autoren von pi0 beschreiben den Open-Source-Teil ihrer Mischung als niederfrequente Steuerung zwischen 2 und 10 Hz. LeRobot's DatasetRecordConfig hat standardmäßig fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50. Eine die auf 5-Hz-Daten trainiert wurde, lernte, dass eine Aktion 200 ms abdeckt. Spielt man sie mit 30 Hz ab, kriecht der Arm; resampelt man naiv, verschmiert man den Frame, in dem der Greifer schließt. Es interagiert auch schlecht mit : ein 100-Schritt-Chunk ist 20 Sekunden bei 5 Hz, 3.3 bei 30 Hz.

4. Kameras

BridgeData V2 randomisierte alle 50 Trajektorien zwei Kameraposen, und auf der Projektseite wird vermerkt, dass die meisten Daten ohnehin nur die feste Ansicht enthalten. DROID verwendete verstellbare ZED 2 Halterungen sowie eine Handgelenk-ZED Mini. Sie haben zwei USB-Webcams, die nach Augenmaß positioniert sind. Die Kamerapose ist keine Störvariable für ein ; sie ist ein Großteil dessen, worauf der visuelle Encoder basierte, und nichts im Dateiformat sagt Ihnen, dass sich die Posen unterscheiden.

Was passiert, wenn Sie versuchen, die Daten trotzdem zusammenzuführen

Der offensichtliche Plan ist zu verketten: ein paar tausend DROID-Episoden plus Ihre 50. LeRobot lehnt ab, und die Ablehnung nennt die drei Dinge, die sich unterscheiden.

1. 1
   Ziehen Sie die 100-Episoden-Stichprobe, nicht die vollen 1,7 TB

   2 GB reichen aus, um die Struktur zu sehen.

   bash

   pip install gsutil tensorflow tensorflow-datasets
   gsutil -m cp -r gs://gresearch/robotics/droid_100 ~/tensorflow_datasets/

2. 2
   RLDS in LeRobot-Form konvertieren

   openx2lerobot kapselt die OXE-Standardtransformationen und annotiert Robotertyp und Steuerfrequenz. Die README legt dies in convert.sh ab.

   bash

   git clone https://github.com/Tavish9/any4lerobot.git
   cd any4lerobot/openx2lerobot
   
   python openx_rlds.py \
       --raw-dir ~/tensorflow_datasets/droid_100/1.0.0 \
       --local-dir ~/lerobot_droid100 \
       --repo-id you/droid100_lerobot \
       --use-videos

3. 3
   Lesen Sie meta/info.json vor allem anderen

   Diese Datei entscheidet, ob der Rest Ihres Tages funktioniert.

   bash

   python -c "import json;d=json.load(open('meta/info.json'));\
   print(d['codebase_version'], d['robot_type'], d['fps']);\
   print(d['features']['action']['shape'], d['features']['observation.state']['shape'])"

4. 4
   Versuchen Sie den Merge und lesen Sie den Fehler

   merge lädt jeden Datensatz, dann prüft validate_all_metadata fps, robot_type und Features gegen den ersten in der Liste und löst beim ersten Konflikt einen Fehler aus.

   bash

   lerobot-edit-dataset \
       --new_repo_id you/mixed \
       --operation.type merge \
       --operation.repo_ids "['you/droid100_lerobot', 'you/my_so100_task']"
   
   # ValueError: Same fps is expected, but got fps=30 instead of 15.

Die Referenzwerte stammen von dem Datensatz, den Sie zuerst aufgelistet haben, weshalb die Meldung Ihre 30 fps bemängelt und nicht die 15 von DROID. Beheben Sie die fps, und Sie stoßen auf die robot_type-Prüfung; beheben Sie diese, und Sie stoßen auf die Feature-Prüfung, 7 gegen 6 für die Aktion. Keine Reihenfolge kommt durch, und dieselbe Schutzfunktion läuft zur Aufnahmezeit über sanity_check_dataset_robot_compatibility.

Was wird also tatsächlich übertragen?

Gewichte, nicht Episoden. Jede moderne Generalisten-Policy hat einen Teil davon im Vortraining absorbiert, und wenn Sie von einem veröffentlichten erben Sie es bereits von Personen mit der Rechenleistung, um es richtig zu machen, abgestimmt. Das Papier von pi0 ist offen bezüglich des Anteils: 9,1 Prozent seiner Vortrainingsmischung, in Zeitschritte gezählt, sind Open-Source-Daten, einschließlich OXE, Bridge v2 und DROID. Diese Zahl stammt von pi0; die Mischung jedes Anbieters unterscheidet sich.

Deshalb SmolVLA verhält sich auf einem kostengünstigen Arm anders. Sein Paper wählt 481 Community-Datensätze von Hugging Face aus, gefiltert nach Verkörperungstyp, Episodenanzahl, Datenqualität und Frame-Abdeckung: 22.9K Episoden, 10.6M Frames, evaluiert an echten SO-100 und SO-101 Armen. Klein und passend schlägt groß und unpassend. Vergleichen Sie auf ACT gegen SmolVLA.

Drei lohnende Wege

Weg A: Feinabstimmung von einem Checkpoint, der die Daten bereits verarbeitet hat

Die meisten Leute sollten diesen Weg wählen. Sie berühren niemals DROID oder Open X-Embodiment: wählen Sie eine Policy, deren Vortraining bereits Cross-Embodiment-Daten absorbiert hat, zeichnen Sie Ihre eigenen Episoden auf, führen Sie eine Feinabstimmung durch.

ACT ist der ehrliche Grenzfall: kein Basismodell, daher erreichen keine der öffentlichen Daten es jemals. Dies ist nicht automatisch ein Nachteil, da es mit 20 ms pro Aktionsschritt das einzige der fünf ist, das einen schnellen Regelkreis schließen kann, wie die ACT-Seite darlegt. Wählen Sie nach Aufgabe unter Verwendung von alle fünf im Vergleich, GR00T N1.7 gegen Pi0.5, und den 332 Benchmark-Ergebnissen über 85 Modelle in der Arena.

Pfad B: DROID als Testvorrichtung verwenden

Die 100-Episoden-Stichprobe ist die besten 2 GB, die Sie diesen Monat herunterladen werden, und nicht zum Training. Es ist ein Datensatz, von dem Sie wissen, dass er korrekt ist. Führen Sie Ihren Konverter, Loader und einen kurzen GPU-Job darauf aus; alles, was fehlschlägt, ist ein Infrastrukturfehler, der gefunden wurde, als es noch günstig war. NVIDIA macht dasselbe im großen Maßstab: Die GR00T N1.7-Karte listet vier nachtrainierte Varianten auf, für Bridge und Fractal in SimplerEnv, DROID und LIBERO.

Pfad C: Eigene Daten gezielt aufzeichnen

Dreißig bis fünfzig klingt wenig im Vergleich zu 76.000, bis man bedenkt, dass Ihre die einzigen sind, die mit Ihrem Arm, Ihren Kameras und Ihrem Tisch aufgenommen wurden. Bei den Standardeinstellungen von LeRobot entsprechen 50 Episoden 100 Minuten Echtzeit. Siehe , und .

Zwei Wege, um von öffentlichen Daten zu einer funktionierenden Policy zu gelangen

Was jeder Pfad kostet

Die Asymmetrie ist der Punkt: Der Pfad, der die meisten Daten ausleiht, ist der teuerste und am wenigsten wahrscheinlich, Ihren Arm zu bewegen. Weniger als zwei Stunden Ihrer eigenen Teleoperation schlagen ein Terabyte einer fremden Franka. Noch keinen Arm? /live streamt einen physischen SO-100 ohne Anmeldung. Dann trainieren Sie Ihre erste Policy, und SmolVLA auf SO-100 für die spezifische Anleitung.