Utilizzo di DROID, BridgeData V2 e Open X su un SO-100

C'è un dataset pubblico di un milione di traiettorie su un Google Cloud bucket e un SO-100 sulla scrivania che è costato da 110 a 150 EUR in parti. Perché il primo non può insegnare al secondo? In parte può, ma quasi nessuno del trasferimento avviene dove le persone si aspettano, e la parte che sembra più facile non funziona affatto.

Cosa segue: cosa c'è dentro DROID, BridgeData V2 e Open X-Embodiment, dove ciascuno si scontra con un braccio 5-DoF a basso costo, e cosa fare invece. Ogni numero riportato di seguito proviene dal documento, dalla scheda del dataset o dal file sorgente a cui appartiene.

Cosa contengono realmente i tre dataset

DROID

Il più standardizzato dei tre. Un unico setup ovunque: un Franka Panda con una pinza Robotiq 2F-85, due telecamere stereo ZED 2 regolabili e una ZED Mini da polso, teleoperato con controller Meta Quest 2, registrato tramite Polymetis a 15 Hz sia nello spazio articolare che in quello dell'end-effector . Le etichette linguistiche sono arrivate in seguito tramite tasq.ai, fino a tre per episodio.

• 76k traiettorie, 350 ore, 564 scene, 84 compiti, 50 raccoglitori su tre continenti.
• Il risultato principale è il co-training, non l'addestramento autonomo: i batch miscelati 50/50 con dimostrazioni in-domain superano il metodo successivo migliore del 22 percento di successo assoluto nella distribuzione, e del 17 percento fuori di essa.
• 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.
• Un campione di debug di 2 GB e 100 episodi si trova su gs://gresearch/robotics/droid_100. Inizia da lì.

BridgeData V2

Il più vicino a una configurazione amatoriale: un braccio WidowX 250 a 6 DoF, 60,096 traiettorie attraverso 24 ambienti e 13 abilità a 5 Hz. Si noti la composizione: 50,365 dimostrazioni esperte teleoperate più 9,731 da una politica di pick-and-place scriptata randomizzata, quindi circa il 16 percento non è una dimostrazione umana, il che è importante per la apprendimento per imitazione qualità. Il download usuale, IPEC-COMMUNITY/bridge_orig_lerobot, riporta 53,192 episodes e 1,893,026 frames a 5 fps, robot_type widowx: meno dei 60,096 del paper, quindi leggere il conteggio da meta/info.json piuttosto che citare l'uno o l'altro.

Open X-Embodiment

Non un dataset nello stesso senso: 60 dataset di robot esistenti da 34 laboratori raggruppati in un'unica collezione RLDS che copre 22 implementazioni e oltre un milione di traiettorie. BridgeData V2 si trova al suo interno come bridge_orig; la sezione google_robot, fractal20220817_data, si converte in 87.212 episodi a 3 fps.

Il raggruppamento comporta un'avvertenza che il documento dichiara apertamente. Per gli esperimenti RT-X, gli autori convertono ogni sorgente in un'azione dell'end-effector a 7-DoF, ma non allineano i sistemi di coordinate tra i dataset e consentono che i valori di azione siano posizioni o velocità assolute o relative, secondo lo schema di controllo originale di ciascun robot. La loro conclusione: lo stesso vettore di azione può indurre movimenti molto diversi per robot diversi.

La discrepanza, in quattro parti

La discrepanza di incarnazione è solitamente trattata come un unico problema vago. Sono quattro, falliscono in modi diversi, e due non sono risolvibili tramite scripting.

1. Gradi di libertà

Un SO-100 ha cinque giunti del braccio più una pinza. Contato come motori, è un braccio a 6-DoF, e il paper SmolVLA lo definisce così; contato come meccanismo di posizionamento è a 5-DoF, e LeRobot lo definisce così nella sua docstring di cinematica inversa, che descrive l'IK a orientamento morbido sul SO-101 a 5-DOF dove il polso traccia l'orientamento solo parzialmente. Un Franka ha sette giunti di posizionamento. Questo divario decide quali pose esistono: un braccio a 5-DoF non può generalmente raggiungere una posizione e un orientamento arbitrari contemporaneamente, quindi il risolutore restituisce il più vicino possibile, un movimento diverso da quello dimostrato. Contesto: gradi di libertà.

# 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

Quindi un checkpoint DROID già pronto non è una scorciatoia. Physical Intelligence distribuisce pi05_droid all'indirizzo gs://openpi-assets/checkpoints/pi05_droid, e lo stesso README che ne loda l'ampiezza avverte che questi checkpoint esperti potrebbero non generalizzare alla tua configurazione. Il suo stato è composto da otto numeri di giunto Franka e le sue chiavi immagine sono exterior_image_1_left e wrist_image_left. Nessun flag lo trasforma in un comando SO-100 a sei motori.

2. Cosa dice realmente il vettore di azione

Più profondo della dimensionalità. Nelle conversioni LeRobot, tutti e tre indicano dove dovrebbe andare la pinza, nello spazio cartesiano. Un SO-100 indica dove dovrebbero andare sei servomotori. La conversione richiede un modello cinematico e un risolutore, non un semplice rimodellamento.

LeRobot fornisce il pezzo mancante: il follower SO ha un processore cinematico con i passaggi InverseKinematicsEEToJoints e ForwardKinematicsJointsToEE. Le sue chiavi sono ee.x, ee.y, ee.z più un vettore di rotazione ee.wx, ee.wy, ee.wz e ee.gripper_pos, quindi anche la codifica dell'orientamento differisce dal rollio-beccheggio-imbardata nei file. Il passaggio IK accetta un orientation_weight, predefinito 0.01, il cui docstring indica di impostare 0.0 per IK solo di posizione su bracci sotto-attuati. Puoi costruire il ponte, ma la metà dell'orientamento di ogni azione presa in prestito rimane approssimata.

3. Frequenza di controllo

DROID è a 15 Hz, BridgeData V2 a 5 Hz, la slice google_robot a 3 fps; gli autori di pi0 descrivono la parte open-source della loro miscela come controllo a bassa frequenza tra 2 e 10 Hz. DatasetRecordConfig di LeRobot ha come valori predefiniti fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50. Una addestrata su dati a 5 Hz ha imparato che un'azione copre 200 ms. Riproducendola a 30 Hz il braccio si muove lentamente; ricampionando ingenuamente si sfoca il frame in cui il gripper si chiude. Interagisce anche male con : un chunk di 100 passi è di 20 secondi a 5 Hz, 3.3 a 30 Hz.

4. Telecamere

BridgeData V2 ha randomizzato due pose della telecamera ogni 50 traiettorie, e la sua pagina di progetto nota che la maggior parte dei dati contiene comunque solo la vista fissa. DROID ha utilizzato supporti ZED 2 regolabili più una ZED Mini da polso. Hai due webcam USB posizionate a occhio. La posa della telecamera non è una variabile di disturbo per un ; è gran parte di ciò su cui l'encoder visivo si è basato, e nulla nel formato del file indica che le pose differiscono.

Cosa succede quando provi comunque a unire i dati

Il piano ovvio è concatenare: qualche migliaio di episodi DROID più i tuoi 50. LeRobot si rifiuta, e il rifiuto elenca le tre cose che differiscono.

1. 1
   Scarica il campione di 100 episodi, non l'intero 1.7 TB

   2 GB sono sufficienti per vedere la struttura.

   bash

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

2. 2
   Converti RLDS nel formato LeRobot

   openx2lerobot incapsula le trasformazioni standard OXE e annota il tipo di robot e la frequenza di controllo. Il README lo inserisce in convert.sh.

   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
   Leggi meta/info.json prima di ogni altra cosa

   Questo file decide se il resto della tua giornata funzionerà.

   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
   Prova l'unione e leggi l'errore

   merge carica ogni dataset, quindi validate_all_metadata controlla fps, robot_type e features rispetto al primo nell'elenco, sollevando un errore al primo disallineamento.

   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.

I valori di riferimento provengono da qualsiasi dataset tu abbia elencato per primo, motivo per cui il messaggio si lamenta dei tuoi 30 fps anziché dei 15 di DROID. Correggi gli fps e incontrerai il controllo robot_type; correggi quello e incontrerai il controllo delle feature, 7 contro 6 per l'azione. Nessun ordinamento funziona, e la stessa protezione viene eseguita al momento della registrazione tramite sanity_check_dataset_robot_compatibility.

Quindi cosa si trasferisce effettivamente?

Pesi, non episodi. Ogni moderna policy generalista ne ha assorbito una parte nel pre-addestramento, e quando si da un rilasciato, lo si eredita già riconciliato da persone con la potenza di calcolo necessaria per farlo correttamente. Il paper di pi0 è esplicito sulla proporzione: il 9,1 percento della sua miscela di pre-addestramento, contata in passi temporali, è costituito da dati open-source inclusi OXE, Bridge v2 e DROID. Questa cifra è di pi0; la miscela di ogni fornitore differisce.

Questo è il motivo per cui SmolVLA si comporta in modo diverso su un braccio a basso costo. Il suo articolo seleziona 481 dataset della community da Hugging Face, filtrati per tipo di embodiment, numero di episodi, qualità dei dati e copertura dei frame: 22.9K episodi, 10.6M frame, valutati su bracci reali SO-100 e SO-101. Piccolo e corrispondente batte grande e non corrispondente. Confronta ACT contro SmolVLA.

Tre percorsi che vale la pena intraprendere

Percorso A: fine-tuning da un checkpoint che ha già assimilato i dati

La maggior parte delle persone dovrebbe scegliere questo. Non si toccano mai DROID o Open X-Embodiment: scegli una policy il cui pre-training ha già assorbito dati cross-embodiment, registra i tuoi episodi, esegui il fine-tuning.

ACT è il caso limite onesto: nessun modello di base, quindi nessuno dei dati pubblici lo raggiunge mai. Non è automaticamente uno svantaggio, poiché a 20 ms per passo d'azione è l'unico dei cinque che può chiudere un ciclo veloce, come la pagina di ACT illustra. Scegli in base al compito usando tutti e cinque confrontati, GR00T N1.7 contro Pi0.5, e i 332 risultati di benchmark su 85 modelli in l'arena.

Percorso B: usa DROID come banco di prova

Il campione di 100 episodi è il miglior 2 GB che scaricherai questo mese, e non per l'addestramento. È un dataset che sai essere corretto. Esegui il tuo convertitore, loader e un breve lavoro GPU su di esso; qualsiasi cosa fallisca è un bug dell'infrastruttura trovato quando era economico. NVIDIA fa lo stesso su larga scala: la scheda GR00T N1.7 elenca quattro varianti post-addestrate, per Bridge e Fractal in SimplerEnv, DROID e LIBERO.

Percorso C: registra il tuo, deliberatamente

Da trenta a cinquanta sembra poco rispetto a 76.000 finché non ricordi che i tuoi sono gli unici con il tuo braccio, le tue telecamere e il tuo tavolo. Con le impostazioni predefinite di LeRobot, 50 episodi equivalgono a 100 minuti di tempo effettivo. Vedi , e .

Due modi per passare dai dati pubblici a una policy funzionante

Costo di ogni percorso

L'asimmetria è il punto: il percorso che prende in prestito più dati è il più costoso e meno propenso a muovere il tuo braccio. Meno di due ore della tua stessa teleoperazione battono un terabyte della Franka di qualcun altro. Nessun braccio ancora? /live trasmette in streaming un SO-100 fisico senza registrazione. Poi addestra la tua prima policy, e SmolVLA su SO-100 per la guida specifica.