Utilizarea DROID, BridgeData V2 și Open X pe un SO-100

Există un set de date public cu un milion de traiectorii pe un bucket Google Cloud și un SO-100 pe birou care a costat 110 to 150 EUR în piese. De ce primul nu-l poate învăța pe al doilea? Parțial poate, dar aproape niciun transfer nu se întâmplă acolo unde se așteaptă oamenii, iar partea care pare cea mai ușoară nu funcționează deloc.

Ce urmează: ce se află în DROID, BridgeData V2 și Open X-Embodiment, unde fiecare se ciocnește cu un braț 5-DoF cu cost redus, și ce să faceți în schimb. Fiecare număr de mai jos provine din lucrarea, fișa setului de date sau fișierul sursă căruia îi aparține.

Ce conțin de fapt cele trei seturi de date

DROID

Cel mai standardizat dintre cele trei. Un singur echipament peste tot: un Franka Panda cu un gripper Robotiq 2F-85, două camere stereo ZED 2 reglabile și un ZED Mini la încheietură, teleoperat cu controlere Meta Quest 2, înregistrat prin Polymetis la 15 Hz atât în spațiul articulațiilor, cât și în spațiul efector final . Etichetele lingvistice au venit mai târziu prin tasq.ai, până la trei per episod.

• 76k traiectorii, 350 ore, 564 scene, 84 sarcini, 50 colectori pe trei continente.
• Rezultatul principal este co-antrenarea, nu antrenarea independentă: loturile amestecate 50/50 cu demonstrații în domeniu au depășit următoarea cea mai bună metodă cu 22 procente succes absolut în distribuție, 17 procente în afara acesteia.
• IPEC-COMMUNITY/droid_lerobot: 92,233 episoade, 27,044,326 cadre, franka, 15 fps, codebase_version v2.0, trei fluxuri AV1 la 180x320, 392 GB.
• Un eșantion de depanare de 2 GB, 100 de episoade, se află la gs://gresearch/robotics/droid_100. Începeți de acolo.

BridgeData V2

Cel mai apropiat de o configurație de hobby: un braț WidowX 250 cu 6 grade de libertate, 60,096 traiectorii în 24 de medii și 13 abilități la 5 Hz. Rețineți compoziția: 50,365 demonstrații teleoperate de experți plus 9,731 dintr-o politică scriptată aleatorie de tip pick-and-place, deci aproximativ 16 procente nu reprezintă demonstrații umane, ceea ce contează pentru învățare prin imitație calitate. Descărcarea obișnuită, IPEC-COMMUNITY/bridge_orig_lerobot, raportează 53,192 episoade și 1,893,026 cadre la 5 fps, robot_type widowx: mai puține decât cele 60,096 din lucrare, așa că citiți numărul din meta/info.json în loc să citați oricare dintre ele.

Open X-Embodiment

Nu este un set de date în același sens: 60 de seturi de date robotice existente de la 34 de laboratoare, reunite într-o singură colecție RLDS, acoperind 22 de implementări și peste un milion de traiectorii. BridgeData V2 se află în interiorul acesteia ca bridge_orig; secțiunea google_robot, fractal20220817_data, se convertește în 87.212 episoade la 3 fps.

Reunirea seturilor de date implică o avertizare pe care lucrarea o menționează explicit. Pentru experimentele RT-X, autorii convertesc fiecare sursă într-o acțiune a efectorului final cu 7 grade de libertate (DoF), dar nu aliniază sistemele de coordonate între seturile de date și permit ca valorile acțiunilor să fie poziții sau viteze absolute sau relative, conform schemei de control originale a fiecărui robot. Concluzia lor: același vector de acțiune poate induce mișcări foarte diferite pentru roboți diferiți.

Nepotrivirea, în patru părți

Discrepanța de întruchipare este de obicei tratată ca o problemă vagă. Sunt patru, eșuează diferit, și două nu pot fi remediate prin scriptare.

1. Grade de libertate

Un SO-100 are cinci articulații ale brațului plus un gripper. Numărat ca motoare, este un braț cu 6-DoF, și lucrarea SmolVLA îl numește astfel; numărat ca mecanism de poziționare este un 5-DoF, și LeRobot îl numește astfel în docstring-ul său de cinematică inversă, care descrie IK cu orientare moale pe SO-101 cu 5-DOF unde încheietura urmărește orientarea doar parțial. O Franka are șapte articulații de poziționare. Acest decalaj decide ce poziții există: un braț cu 5-DoF nu poate atinge în general o poziție și orientare arbitrară simultan, așa că rezolvitorul returnează cea mai apropiată poziție pe care o poate atinge, o mișcare diferită de cea demonstrată. Context: grade de libertate.

# 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

Așadar, un checkpoint DROID gata făcut nu este o scurtătură. Physical Intelligence livrează pi05_droid la gs://openpi-assets/checkpoints/pi05_droid, iar același README care îi laudă amploarea avertizează că aceste checkpoint-uri expert s-ar putea să nu se generalizeze la configurația dumneavoastră. Starea sa este formată din opt numere de articulație Franka, iar cheile sale de imagine sunt exterior_image_1_left și wrist_image_left. Niciun flag nu transformă asta într-o comandă SO-100 cu șase motoare.

2. Ce spune de fapt vectorul de acțiune

Mai profund decât dimensionalitatea. În conversiile LeRobot, toate cele trei spun unde ar trebui să meargă gripper-ul, în spațiul cartezian. Un SO-100 spune unde ar trebui să meargă șase servomotoare. Conversia necesită un model cinematic și un rezolvitor, nu o reconfigurare.

LeRobot livrează piesa lipsă: urmăritorul SO are un procesor de cinematică cu pași InverseKinematicsEEToJoints și ForwardKinematicsJointsToEE. Cheile sale sunt ee.x, ee.y, ee.z plus un vector de rotație ee.wx, ee.wy, ee.wz și ee.gripper_pos, astfel încât chiar și codificarea orientării diferă de roll-pitch-yaw din fișiere. Pasul IK preia un orientation_weight, implicit 0.01, al cărui docstring spune să setați 0.0 pentru IK doar pe poziție pe brațe sub-acționate. Puteți construi puntea, dar jumătatea de orientare a fiecărei acțiuni împrumutate rămâne aproximată.

3. Frecvența de control

DROID este de 15 Hz, BridgeData V2 de 5 Hz, secțiunea google_robot de 3 fps; autorii pi0 descriu partea open-source a amestecului lor ca fiind un control de joasă frecvență între 2 și 10 Hz. DatasetRecordConfig al LeRobot are ca valori implicite fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50. O , antrenată pe date de 5 Hz a învățat că o acțiune acoperă 200 ms. Redați-o la 30 Hz și brațul se mișcă lent; reeșantionați naiv și veți estompa cadrul în care se închide prehensorul. De asemenea, interacționează prost cu : un fragment de 100 de pași este de 20 de secunde la 5 Hz, 3.3 la 30 Hz.

4. Camere

BridgeData V2 a randomizat două poziții de cameră la fiecare 50 de traiectorii, iar pagina sa de proiect menționează că majoritatea datelor conțin oricum doar vizualizarea fixă. DROID a folosit suporturi reglabile ZED 2 plus un ZED Mini la încheietura mâinii. Aveți două camere web USB poziționate la ochi. Poziția camerei nu este o variabilă deranjantă pentru un ; este o mare parte din ceea ce a folosit encoderul vizual, și nimic din formatul fișierului nu indică faptul că pozițiile diferă.

Ce se întâmplă când încerci oricum să combini datele

Planul evident este să se concateneze: câteva mii de episoade DROID plus cele 50 ale tale. LeRobot refuză, iar refuzul menționează cele trei lucruri care diferă.

1. 1
   Descarcă eșantionul de 100 de episoade, nu întregul 1.7 TB

   2 GB sunt suficiente pentru a vedea structura.

   bash

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

2. 2
   Convertește RLDS în format LeRobot

   openx2lerobot încapsulează transformările standard OXE și adnotează tipul robotului și frecvența de control. Fișierul README plasează acest lucru în 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
   Citește meta/info.json înainte de orice altceva

   Acest fișier decide dacă restul zilei tale va funcționa.

   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
   Încearcă îmbinarea și citește eroarea

   Operația de îmbinare încarcă fiecare set de date, apoi validate_all_metadata verifică fps, robot_type și caracteristicile în raport cu primul din listă, generând o eroare la prima nepotrivire.

   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.

Valorile de referință provin de la setul de date pe care l-ați listat primul, motiv pentru care mesajul se plânge de cei 30 fps ai dumneavoastră, mai degrabă decât de cei 15 ai DROID. Corectați fps-ul și veți întâlni verificarea robot_type; corectați-o și veți întâlni verificarea caracteristicilor, 7 față de 6 pentru acțiune. Nicio ordine nu trece, iar aceeași verificare rulează la momentul înregistrării prin sanity_check_dataset_robot_compatibility.

Deci ce se transferă de fapt?

Ponderi, nu episoade. Fiecare politică generalistă modernă a absorbit o parte din acestea în preantrenare, iar când de la un îl moșteniți deja reconciliat de oameni cu puterea de calcul necesară pentru a o face corect. Lucrarea lui pi0 este sinceră în privința proporției: 9.1 la sută din amestecul său de pre-antrenare, numărat în pași de timp, este reprezentat de date open-source, inclusiv OXE, Bridge v2 și DROID. Această cifră este a lui pi0; amestecul fiecărui furnizor diferă.

Acesta este motivul pentru care SmolVLA se comportă diferit pe un braț cu cost redus. Lucrarea sa selectează 481 de seturi de date din comunitate de la Hugging Face, filtrate după tipul de întruchipare, numărul de episoade, calitatea datelor și acoperirea cadrelor: 22.9K episoade, 10.6M cadre, evaluate pe brațe reale SO-100 și SO-101. Micul și potrivitul învinge marele și nepotrivit. Comparați ACT împotriva SmolVLA.

Trei căi demne de urmat

Calea A: ajustare fină dintr-un punct de control care a absorbit deja datele

Majoritatea oamenilor ar trebui să o aleagă pe aceasta. Nu atingeți niciodată DROID sau Open X-Embodiment: alegeți o politică a cărei pre-antrenare a absorbit deja date cross-embodiment, înregistrați-vă propriile episoade, ajustați fin.

ACT este cazul limită onest: fără model de bază, deci niciuna dintre datele publice nu ajunge vreodată la el. Nu este automat un dezavantaj, deoarece la 20 ms per pas de acțiune este singurul dintre cele cinci care poate închide o buclă rapidă, așa cum pagina ACT se arată. Alegeți după sarcină folosind toate cele cinci comparate, GR00T N1.7 versus Pi0.5, și cele 332 de rezultate de benchmark pentru 85 de modele în arena.

Calea B: utilizați DROID ca dispozitiv de testare

Eșantionul de 100 de episoade este cei mai buni 2 GB pe care îi veți descărca luna aceasta, și nu pentru antrenament. Este un set de date despre care știți că este corect. Rulați convertorul, încărcătorul și o scurtă sarcină GPU pe el; orice eșec este o eroare de infrastructură găsită cât timp a fost ieftin. NVIDIA face același lucru la scară: placa GR00T N1.7 listează patru variante post-antrenate, pentru Bridge și Fractal în SimplerEnv, DROID și LIBERO.

Calea C: înregistrați-vă propriile date, în mod deliberat

Treizeci până la cincizeci sună puțin lângă 76.000 până când vă amintiți că ale dumneavoastră sunt singurele cu brațul, camerele și masa dumneavoastră. La setările implicite ale LeRobot, 50 de episoade înseamnă 100 de minute de timp real. Consultați , și .

Două moduri de a ajunge de la date publice la o politică funcțională

Cât costă fiecare cale

Asimetria este esențială: calea care împrumută cele mai multe date este cea mai costisitoare și cel mai puțin probabil să-ți miște brațul. Mai puțin de două ore de teleoperare proprie învinge un terabyte de date Franka ale altcuiva. Nu ai încă un braț? /live transmite în direct un SO-100 fizic fără înregistrare. Apoi antrenează-ți prima politică, și SmolVLA pe SO-100 pentru ghidul specific.