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

Det finnes et offentlig datasett med en million trajektorier på en Google Cloud bucket og en SO-100 på skrivebordet som kostet 110 to 150 EUR i deler. Hvorfor kan ikke den første lære den andre? Det kan den delvis, men nesten ingen av overføringen skjer der folk forventer, og den delen som ser enklest ut, fungerer ikke i det hele tatt.

Hva som følger: hva som er inne i DROID, BridgeData V2 og Open X-Embodiment, hvor hver kolliderer med en rimelig 5-DoF arm, og hva man skal gjøre i stedet. Hvert tall nedenfor kom fra artikkelen, datasettkortet eller kildefilen det tilhører.

Hva de tre datasettene faktisk inneholder

DROID

Den mest standardiserte av de tre. Ett rigg overalt: en Franka Panda med en Robotiq 2F-85 griper, to justerbare ZED 2 stereokameraer og et håndledds-ZED Mini, teleoperert med Meta Quest 2-kontrollere, registrert via Polymetis ved 15 Hz i både ledd- og endeffektor rom. Språketiketter kom senere via tasq.ai, opptil tre per episode.

• 76k trajektorier, 350 timer, 564 scener, 84 oppgaver, 50 samlere på tre kontinenter.
• Hovedresultatet er samtrening, ikke frittstående trening: batcher blandet 50/50 med in-domain demonstrasjoner slo den nest beste metoden med 22 prosent absolutt suksess i distribusjon, 17 prosent utenfor den.
• IPEC-COMMUNITY/droid_lerobot: 92,233 episoder, 27,044,326 bilder, franka, 15 fps, codebase_version v2.0, tre AV1-strømmer på 180x320, 392 GB.
• En 2 GB, 100-episode feilsøkingsprøve ligger på gs://gresearch/robotics/droid_100. Start der.

BridgeData V2

Det nærmeste et hobbysetup: en WidowX 250 6-DoF arm, 60,096 trajektorier fordelt på 24 miljøer og 13 ferdigheter ved 5 Hz. Merk sammensetningen: 50,365 ekspertdemonstrasjoner teleoperert pluss 9,731 fra en randomisert skriptet pick-and-place policy, så omtrent 16 prosent er ikke menneskelig demonstrasjon, noe som betyr noe for imitasjonslæring kvalitet. Den vanlige nedlastingen, IPEC-COMMUNITY/bridge_orig_lerobot, rapporterer 53,192 episoder og 1,893,026 bilder ved 5 fps, robot_type widowx: færre enn papirets 60,096, så les antallet fra meta/info.json i stedet for å sitere noen av dem.

Open X-Embodiment

Ikke et datasett i samme forstand: 60 eksisterende robotdatasett fra 34 laboratorier samlet i én RLDS-samling som dekker 22 utførelser og over en million trajektorier. BridgeData V2 ligger inne i den som bridge_orig; google_robot-delen, fractal20220817_data, konverteres til 87 212 episoder ved 3 fps.

Samlingen innebærer et forbehold som artikkelen tydelig angir. For RT-X-eksperimentene konverterer forfatterne hver kilde til en 7-DoF end-effektor-handling, men justerer ikke koordinatsystemer på tvers av datasett, og tillater at handlingsverdier er absolutte eller relative posisjoner eller hastigheter, i henhold til hver robots originale kontrollskjema. Deres konklusjon: den samme handlingsvektoren kan indusere svært forskjellige bevegelser for forskjellige roboter.

Uoverensstemmelsen, i fire deler

Uoverensstemmelse i utførelse blir vanligvis behandlet som ett vagt problem. Det er fire, de feiler forskjellig, og to kan ikke fikses med skripting.

1. Frihetsgrader

En SO-100 har fem armledd pluss en griper. Talt som motorer er det en 6-DoF arm, og SmolVLA-artikkelen kaller den det; talt som en posisjoneringsmekanisme er den 5-DoF, og LeRobot kaller den det i sin inverse-kinematikk docstring, som beskriver myk-orientering IK på 5-DOF SO-101 hvor håndleddet kun delvis sporer orientering. En Franka har syv posisjoneringsledd. Dette gapet avgjør hvilke positurer som eksisterer: en 5-DoF arm kan vanligvis ikke nå en vilkårlig posisjon og orientering samtidig, så løseren returnerer det nærmeste den kan, en annen bevegelse enn den demonstrerte. Bakgrunn: frihetsgrader.

# 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 ferdig DROID-sjekkpunkt er ingen snarvei. Physical Intelligence leverer pi05_droid på gs://openpi-assets/checkpoints/pi05_droid, og den samme README-filen som roser dens bredde advarer om at disse ekspert-sjekkpunktene kanskje ikke generaliserer til ditt oppsett. Dens tilstand er åtte Franka-leddnumre og dens bilde-nøkler er exterior_image_1_left og wrist_image_left. Ingen flagg gjør det om til en seks-motorers SO-100-kommando.

2. Hva handlingsvektoren faktisk sier

Dypere enn dimensionalitet. I LeRobot-konverteringene sier alle tre hvor griperen skal gå, i kartesisk rom. En SO-100 sier hvor seks servoer skal gå. Konvertering krever en kinematisk modell og en løser, ikke en omforming.

LeRobot leverer den manglende brikken: SO-følgeren har en kinematikkprosessor med InverseKinematicsEEToJoints- og ForwardKinematicsJointsToEE-trinn. Nøklene er ee.x, ee.y, ee.z pluss en rotasjonsvektor ee.wx, ee.wy, ee.wz og ee.gripper_pos, så selv orienteringskodingen avviker fra roll-pitch-yaw i filene. IK-trinnet tar en orientation_weight, standard 0.01, hvis docstring sier å sette 0.0 for posisjons-kun IK på underaktiverte armer. Du kan bygge broen, men orienteringshalvdelen av hver lånte handling forblir tilnærmet.

3. Kontrollfrekvens

DROID er 15 Hz, BridgeData V2 5 Hz, google_robot-skiven 3 fps; pi0s forfattere beskriver den åpen kildekode-delen av blandingen sin som lavfrekvent kontroll mellom 2 og 10 Hz. LeRobots DatasetRecordConfig har standardinnstillinger for fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50. En trent på 5 Hz data lærte at én handling dekker 200 ms. Spill den av på 30 Hz og armen kryper; resample naivt og du smører ut rammen der griperen lukkes. Det samhandler også dårlig med : et 100-trinns segment er 20 sekunder ved 5 Hz, 3.3 ved 30 Hz.

4. Kameraer

BridgeData V2 randomiserte to kameraposisjoner hver 50. trajektorie, og prosjektsiden deres bemerker at mesteparten av dataene uansett kun inneholder den faste visningen. DROID brukte justerbare ZED 2-fester pluss en ZED Mini på håndleddet. Du har to USB-webkameraer plassert på øyemål. Kameraposisjon er ikke en plagsom variabel for en ; det er mye av det den visuelle koderen fokuserte på, og ingenting i filformatet forteller deg at posisjonene er forskjellige.

Hva skjer når du prøver å slå sammen dataene uansett

Den åpenbare planen er å slå sammen: noen tusen DROID-episoder pluss dine 50. LeRobot nekter, og avslaget nevner de tre tingene som er forskjellige.

1. 1
   Hent 100-episode-eksempelet, ikke hele 1.7 TB

   2 GB er nok til å 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 pakker inn OXE-standardtransformasjonene og annoterer robottype og kontrollfrekvens. README-filen plasserer 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
   Les meta/info.json før noe annet

   Denne filen avgjør om resten av dagen din 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 sammenslåingen og les feilen

   merge laster inn hvert datasett, deretter sjekker validate_all_metadata fps, robot_type og features mot den første i listen, og utløser en feil 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.

Referanseverdiene kommer fra det datasettet du listet opp først, og det er derfor meldingen klager over dine 30 fps i stedet for DROID sine 15. Fiks fps, og du treffer robot_type-sjekken; fiks det, og du treffer feature-sjekken, 7 mot 6 for handlingen. Ingen rekkefølge kommer gjennom, og den samme sjekken kjører ved opptakstid via sanity_check_dataset_robot_compatibility.

Så hva overføres egentlig?

Vekter, ikke episoder. Hver moderne generalistpolicy har absorbert noe av det i førtreningen, og når du finjusterer fra et utgitt sjekkpunkt arver du det allerede avstemt av folk med regnekraften til å gjøre det skikkelig. pi0s artikkel er åpen om andelen: 9,1 prosent av førtreningsblandingen, talt i tidsskritt, er åpen kildedata inkludert OXE, Bridge v2 og DROID. Dette tallet er pi0s; hver leverandørs blanding varierer.

Dette er grunnen til at SmolVLA oppfører seg annerledes på en rimelig arm. Dets artikkel velger 481 fellesskapsdatasett fra Hugging Face, filtrert etter utførelsestype, episodeantall, datakvalitet og rammedekning: 22.9K episoder, 10.6M rammer, evaluert på ekte SO-100 og SO-101 armer. Lite og matchet slår stort og uoverensstemmende. Sammenlign på ACT against SmolVLA.

Tre veier verdt å ta

Vei A: finjuster fra et sjekkpunkt som allerede har absorbert dataene

De fleste bør velge denne. Du rører aldri DROID eller Open X-Embodiment: velg en policy hvis forhåndstrening allerede har absorbert tverr-utførelsesdata, ta opp dine egne episoder, finjuster.

ACT er det ærlige grensetilfellet: ingen grunnmodell, så ingen av de offentlige dataene når den noen gang. Ikke automatisk en ulempe, siden den med 20 ms per handlingstrinn er den eneste av de fem som kan lukke en rask sløyfe, slik ACT-siden beskriver. Velg etter oppgave ved å bruke alle fem sammenlignet, GR00T N1.7 mot Pi0.5, og de 332 benchmark-resultatene på tvers av 85 modeller i arenaen.

Sti B: bruk DROID som en testarmatur

Den 100-episoders prøven er de beste 2 GB du vil laste ned denne måneden, og ikke for trening. Det er et datasett du vet er korrekt. Kjør konverteren, lasteren og en kort GPU-jobb på den; alt som feiler er en infrastrukturfeil funnet mens det var billig. NVIDIA gjør det samme i stor skala: GR00T N1.7-kortet lister opp fire post-trente varianter, for Bridge og Fractal i SimplerEnv, DROID og LIBERO.

Sti C: ta opp dine egne, bevisst

Tretti til femti høres lite ut sammenlignet med 76 000, helt til du husker at dine er de eneste med din arm, dine kameraer og ditt bord. Med LeRobots standardinnstillinger er 50 episoder 100 minutter reell tid. Se , og .

To måter å komme fra offentlige data til en fungerende policy

Hva hver bane koster

Asymmetrien er poenget: stien som låner mest data er den dyreste og minst sannsynlig til å bevege armen din. Under to timer av din egen teleoperasjon slår en terabyte av andres Franka. Ingen arm ennå? /live strømmer en fysisk SO-100 uten registrering. Deretter tren din første policy, og SmolVLA på SO-100 for den spesifikke veiledningen.