Brug af DROID, BridgeData V2 og Open X på en SO-100

Der er et offentligt datasæt med en million-trajektorier på en Google Cloud bucket og en SO-100 på skrivebordet, der kostede 110 til 150 EUR i dele. Hvorfor kan den første ikke lære den anden? Det kan den delvist, men næsten ingen af overførslen sker, hvor folk forventer det, og den del, der ser nemmest ud, virker slet ikke.

Hvad følger: hvad der er inde i DROID, BridgeData V2 og Open X-Embodiment, hvor hver især kolliderer med en billig 5-DoF arm, og hvad man skal gøre i stedet. Hvert tal nedenfor kom fra den artikel, datasætkort eller kildefil, det tilhører.

Hvad de tre datasæt faktisk indeholder

DROID

Den mest standardiserede af de tre. Én opsætning overalt: en Franka Panda med en Robotiq 2F-85 griber, to justerbare ZED 2 stereokameraer og et ZED Mini håndledskamera, teleopereret med Meta Quest 2 controllere, optaget via Polymetis ved 15 Hz i både led- og end-effektor rum. Sprog-labels kom senere via tasq.ai, op til tre pr. episode.

• 76k trajektorier, 350 timer, 564 scener, 84 opgaver, 50 indsamlere på tre kontinenter.
• Hovedresultatet er co-træning, ikke selvstændig træning: batches blandet 50/50 med in-domain demonstrationer slår den næstbedste metode med 22 procent absolut succes i distribution, 17 procent udenfor.
• 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.
• En 2 GB, 100-episode debugging-prøve findes på gs://gresearch/robotics/droid_100. Start der.

BridgeData V2

Det tætteste på et hobby-setup: en WidowX 250 6-DoF arm, 60.096 trajektorier fordelt på 24 miljøer og 13 færdigheder ved 5 Hz. Bemærk sammensætningen: 50.365 ekspert-teleopererede demonstrationer plus 9.731 fra en randomiseret scriptet pick-and-place politik, så omkring 16 procent er ikke menneskelig demonstration, hvilket er vigtigt for imitationslæring kvalitet. Den sædvanlige download, IPEC-COMMUNITY/bridge_orig_lerobot, rapporterer 53.192 episoder og 1.893.026 frames ved 5 fps, robot_type widowx: færre end papirets 60.096, så læs antallet fra meta/info.json i stedet for at citere nogen af dem.

Open X-Embodiment

Ikke et datasæt i samme forstand: 60 eksisterende robotdatasæt fra 34 laboratorier samlet i én RLDS-samling, der dækker 22 udførelsesformer og over en million trajektorier. BridgeData V2 ligger i den som bridge_orig; google_robot-udsnittet, fractal20220817_data, konverteres til 87.212 episoder ved 3 fps.

Samlingen indeholder et forbehold, som artiklen direkte angiver. Til RT-X-eksperimenterne konverterer forfatterne hver kilde til en 7-DoF end-effector-handling, men justerer ikke koordinatsystemer på tværs af datasæt og tillader, at handlingsværdier er absolutte eller relative positioner eller hastigheder, i henhold til hver robots originale kontrolskema. Deres konklusion: den samme handlingsvektor kan fremkalde meget forskellige bevægelser for forskellige robotter.

Uoverensstemmelsen, i fire dele

Uoverensstemmelse i legemliggørelse behandles normalt som ét vagt problem. Det er fire, de fejler forskelligt, og to kan ikke løses med scripting.

1. Frihedsgrader

En SO-100 har fem armled plus en griber. Talt som motorer er det en 6-DoF arm, og SmolVLA-papiret kalder den det; talt som en positioneringsmekanisme er det 5-DoF, og LeRobot kalder den det i sin inverse-kinematik docstring, som beskriver soft-orientation IK på den 5-DOF SO-101, hvor håndleddet kun delvist sporer orientering. En Franka har syv positioneringsled. Det gab afgør, hvilke positioner der eksisterer: en 5-DoF arm kan generelt ikke nå en vilkårlig position og orientering på én gang, så løseren returnerer det tætteste, den kan, en anden bevægelse end den demonstrerede. Baggrund: frihedsgrader.

# 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

Så et færdigt DROID-checkpoint er ingen genvej. Physical Intelligence leverer pi05_droid på gs://openpi-assets/checkpoints/pi05_droid, og den samme README, der roser dens bredde, advarer om, at disse ekspert-checkpoints muligvis ikke generaliserer til din opsætning. Dens tilstand er otte Franka-lednumre, og dens billednøgler er exterior_image_1_left og wrist_image_left. Ingen flag omdanner det til en seks-motor SO-100 kommando.

2. Hvad handlingsvektoren faktisk siger

Dybere end dimensionalitet. I LeRobot-konverteringerne angiver alle tre, hvor griberen skal bevæge sig hen, i kartesisk rum. En SO-100 angiver, hvor seks servoer skal bevæge sig hen. Konvertering kræver en kinematisk model og en løser, ikke en omformning.

LeRobot leverer den manglende brik: SO-følgeren har en kinematikprocessor med InverseKinematicsEEToJoints- og ForwardKinematicsJointsToEE-trin. Dens nøgler er ee.x, ee.y, ee.z plus en rotationsvektor ee.wx, ee.wy, ee.wz og ee.gripper_pos, så selv orienteringskodningen adskiller sig fra roll-pitch-yaw i filerne. IK-trinnet tager en orientation_weight, standard 0.01, hvis docstring siger, at man skal sætte 0.0 for position-only IK på underaktiverede arme. Du kan bygge broen, men orienteringshalvdelen af hver lånt handling forbliver approksimeret.

3. Kontrolfrekvens

DROID er 15 Hz, BridgeData V2 5 Hz, google_robot-udsnittet 3 fps; pi0's forfattere beskriver den open source-del af deres blanding som lavfrekvent kontrol mellem 2 og 10 Hz. LeRobots DatasetRecordConfig har standardindstillingerne fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50. En trænet på 5 Hz data lærte, at én handling dækker 200 ms. Afspil det ved 30 Hz, og armen kravler; gensample naivt, og du udvisker rammen, hvor griberen lukker. Det interagerer også dårligt med : et 100-trins segment er 20 sekunder ved 5 Hz, 3.3 ved 30 Hz.

4. Kameraer

BridgeData V2 randomiserede to kamerapositioner hver 50. trajektorie, og dets projektside bemærker, at det meste af dataene alligevel kun indeholder den faste visning. DROID brugte justerbare ZED 2-beslag plus en håndleds-ZED Mini. Du har to USB-webkameraer placeret efter øjemål. Kameraposition er ikke en generende variabel for en ; det er meget af det, den visuelle encoder fokuserede på, og intet i filformatet fortæller dig, at positionerne er forskellige.

Hvad sker der, når du alligevel forsøger at flette dataene

Den oplagte plan er at sammenkæde: et par tusind DROID-episoder plus dine 50. LeRobot nægter, og nægtelsen nævner de tre ting, der adskiller sig.

1. 1
   Hent 100-episode-eksemplet, ikke de fulde 1,7 TB

   2 GB er nok til at se strukturen.

   bash

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

2. 2
   Konverter RLDS til LeRobot-format

   openx2lerobot omslutter OXE's standardtransformationer og annoterer robottype og kontrolfrekvens. README'en placerer dette i 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
   Læs meta/info.json før noget andet

   Denne fil afgør, om resten af din dag fungerer.

   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
   Prøv sammenfletningen og læs fejlen

   merge indlæser hvert datasæt, hvorefter validate_all_metadata kontrollerer fps, robot_type og features mod det første på listen og udløser en fejl ved første uoverensstemmelse.

   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.

Referenceværdierne kommer fra det datasæt, du listede først, hvilket er grunden til, at meddelelsen klager over dine 30 fps i stedet for DROID's 15. Ret fps, og du rammer robot_type-kontrollen; ret den, og du rammer feature-kontrollen, 7 mod 6 for handlingen. Ingen rækkefølge slipper igennem, og den samme kontrol kører ved optagelsestidspunktet via sanity_check_dataset_robot_compatibility.

Så hvad overføres egentlig?

Vægte, ikke episoder. Enhver moderne generalistpolitik har absorberet noget af det i fortræning, og når du fra et udgivet arver du det allerede afstemt af folk med den nødvendige regnekraft til at gøre det ordentligt. pi0's artikel er ærlig omkring proportionen: 9,1 procent af dens fortræningsblanding, talt i timesteps, er open source-data inklusive OXE, Bridge v2 og DROID. Dette tal er pi0's; hver leverandørs blanding er forskellig.

Dette er grunden til, at SmolVLA opfører sig anderledes på en billig arm. Dets artikel udvælger 481 fællesskabsdatasæt fra Hugging Face, filtreret efter embodiment-type, antal episoder, datakvalitet og billeddækning: 22.9K episoder, 10.6M frames, evalueret på rigtige SO-100 og SO-101 arme. Lille og matchet slår stor og uoverensstemmende. Sammenlign på ACT mod SmolVLA.

Tre veje værd at tage

Vej A: finjuster fra et checkpoint, der allerede har absorberet dataene

De fleste bør vælge denne. Du rører aldrig DROID eller Open X-Embodiment: vælg en politik, hvis fortræning allerede har absorberet tværgående embodiment-data, optag dine egne episoder, finjuster.

ACT er det ærlige grænsetilfælde: ingen basismodel, så ingen af de offentlige data når nogensinde den. Ikke automatisk en ulempe, da den med 20 ms pr. handlingstrin er den eneste af de fem, der kan lukke en hurtig løkke, som ACT-siden beskriver. Vælg efter opgave ved hjælp af alle fem sammenlignet, GR00T N1.7 mod Pi0.5, og de 332 benchmarkresultater på tværs af 85 modeller i arenaen.

Sti B: brug DROID som testarmatur

Den 100-episoders prøve er de bedste 2 GB, du vil downloade denne måned, og ikke til træning. Det er et datasæt, du ved er korrekt. Kør din konverter, loader og et kort GPU-job på det; alt, der fejler, er en infrastrukturfejl fundet, mens det var billigt. NVIDIA gør det samme i stor skala: GR00T N1.7-kortet viser fire eftertrænede varianter, til Bridge og Fractal i SimplerEnv, DROID og LIBERO.

Vej C: optag dine egne, bevidst

Tredive til halvtreds lyder måske af lidt ved siden af 76.000, indtil du husker, at dine er de eneste med din arm, dine kameraer og dit bord. Med LeRobots standardindstillinger er 50 episoder 100 minutters reel tid. Se , og .

To måder at komme fra offentlige data til en fungerende politik

Hvad hver sti koster

Asymmetrien er pointen: den sti, der låner mest data, er den dyreste og mindst sandsynlige til at bevæge din arm. Under to timer af din egen fjernstyring slår en terabyte af en andens Franka. Ingen arm endnu? /live streamer en fysisk SO-100 uden tilmelding. Derefter træn din første politik, og SmolVLA på SO-100 for den specifikke guide.