Använda DROID, BridgeData V2 och Open X på en SO-100

Det finns en offentlig datamängd med en miljon trajektorier på en Google Cloud-bucket och en SO-100 på skrivbordet som kostade 110 till 150 EUR i delar. Varför kan den första inte lära den andra? Delvis kan den det, men nästan ingen av överföringen sker där folk förväntar sig, och den del som ser enklast ut fungerar inte alls.

Vad som följer: vad som finns inuti DROID, BridgeData V2 och Open X-Embodiment, där var och en kolliderar med en billig 5-DoF-arm, och vad man ska göra istället. Varje siffra nedan kom från den artikel, datamängdskort eller källfil den tillhör.

Vad de tre datamängderna faktiskt innehåller

DROID

Den mest standardiserade av de tre. En rigg överallt: en Franka Panda med en Robotiq 2F-85 gripklo, två justerbara ZED 2 stereokameror och en handleds-ZED Mini, fjärrstyrd med Meta Quest 2-kontroller, inspelad via Polymetis vid 15 Hz i både led- och slut-effektor utrymme. Språketiketter kom senare via tasq.ai, upp till tre per episod.

• 76k trajektorier, 350 timmar, 564 scener, 84 uppgifter, 50 insamlare på tre kontinenter.
• Huvudresultatet är samträning, inte fristående träning: batchar blandade 50/50 med demonstrationer inom domänen slog den näst bästa metoden med 22 procent absolut framgång i distribution, 17 procent utanför den.
• 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.
• Ett 2 GB, 100-episoders felsökningsprov finns på gs://gresearch/robotics/droid_100. Börja där.

BridgeData V2

Det närmaste en hobbymiljö: en WidowX 250 6-DoF-arm, 60 096 trajektorier över 24 miljöer och 13 färdigheter vid 5 Hz. Notera sammansättningen: 50 365 expertteleopererade demonstrationer plus 9 731 från en randomiserad skriptad plock-och-placera-policy, så cirka 16 procent är inte mänsklig demonstration, vilket är viktigt för imitationsinlärning kvalitet. Den vanliga nedladdningen, IPEC-COMMUNITY/bridge_orig_lerobot, rapporterar 53 192 episoder och 1 893 026 bildrutor vid 5 fps, robot_type widowx: färre än uppsatsens 60 096, så läs antalet från meta/info.json istället för att citera något av dem.

Open X-Embodiment

Inte en datamängd i samma bemärkelse: 60 befintliga robotdatamängder från 34 laboratorier samlade i en RLDS-samling som täcker 22 utföranden och över en miljon trajektorier. BridgeData V2 finns inuti den som bridge_orig; google_robot-skivan, fractal20220817_data, konverteras till 87 212 episoder vid 3 fps.

Samlingen medför en reservation som artikeln uttryckligen anger. För RT-X-experimenten konverterar författarna varje källa till en 7-DoF end-effector-aktion, men de anpassar inte koordinatsystemen mellan datamängderna, och tillåter att aktionsvärden är absoluta eller relativa positioner eller hastigheter, enligt varje robots ursprungliga kontrollschema. Deras slutsats: samma aktionsvektor kan inducera mycket olika rörelser för olika robotar.

Mismatchningen, i fyra delar

Kroppslig inkompatibilitet behandlas oftast som ett vagt problem. Det är fyra, de misslyckas på olika sätt, och två kan inte åtgärdas med skriptning.

1. Frihetsgrader

En SO-100 har fem armleder plus en gripklo. Räknat som motorer är det en 6-DoF-arm, och SmolVLA-artikeln kallar den det; räknat som en positioneringsmekanism är den 5-DoF, och LeRobot kallar den det i sin docstring för invers kinematik, som beskriver mjukorienterad IK på den 5-DOF SO-101 där handleden endast delvis spårar orientering. En Franka har sju positioneringsleder. Detta gap avgör vilka poser som existerar: en 5-DoF-arm kan i allmänhet inte nå en godtycklig position och orientering samtidigt, så lösaren returnerar det närmaste den kan, en annan rörelse än den som demonstrerades. Bakgrund: 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å en färdig DROID-checkpoint är ingen genväg. Physical Intelligence levererar pi05_droid på gs://openpi-assets/checkpoints/pi05_droid, och samma README som berömmer dess bredd varnar för att dessa expert-checkpoints kanske inte generaliserar till din installation. Dess tillstånd är åtta Franka-lednummer och dess bildnycklar är exterior_image_1_left och wrist_image_left. Ingen flagga förvandlar det till ett sex-motorigt SO-100-kommando.

2. Vad aktionsvektorn faktiskt säger

Djupare än dimensionalitet. I LeRobot-konverteringarna säger alla tre vart gripdonet ska gå, i kartesiskt rum. En SO-100 säger vart sex servon ska gå. Konvertering kräver en kinematisk modell och en lösare, inte en omformning.

LeRobot levererar den saknade biten: SO follower har en kinematikprocessor med stegen InverseKinematicsEEToJoints och ForwardKinematicsJointsToEE. Dess nycklar är ee.x, ee.y, ee.z plus en rotationsvektor ee.wx, ee.wy, ee.wz och ee.gripper_pos, så även orienteringskodningen skiljer sig från roll-pitch-yaw i filerna. IK-steget tar en orientation_weight, standard 0.01, vars docstring säger att man ska sätta 0.0 för position-only IK på underaktiverade armar. Du kan bygga bron, men orienteringshalvan av varje lånad åtgärd förblir approximerad.

3. Kontrollfrekvens

DROID är 15 Hz, BridgeData V2 5 Hz, google_robot-skivan 3 fps; pi0:s författare beskriver den öppen källkodsdelen av sin blandning som lågfrekvent kontroll mellan 2 och 10 Hz. LeRobot:s DatasetRecordConfig har standardvärdena fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50. En tränad på 5 Hz data lärde sig att en åtgärd täcker 200 ms. Spela upp den vid 30 Hz och armen kryper; omsampla naivt och du smetar ut ramen där griparen stängs. Det interagerar också dåligt med : en 100-stegs chunk är 20 sekunder vid 5 Hz, 3.3 vid 30 Hz.

4. Kameror

BridgeData V2 randomiserade två kamerapositioner var 50:e bana, och dess projektsida noterar att det mesta av datan ändå bara innehåller den fasta vyn. DROID använde justerbara ZED 2-fästen plus en handledsmonterad ZED Mini. Du har två USB-webbkameror placerade på fri hand. Kameraposition är inte en störande variabel för en ; det är mycket av vad den visuella kodaren fokuserade på, och inget i filformatet berättar att positionerna skiljer sig åt.

Vad händer när du ändå försöker slå samman datan

Den uppenbara planen är att sammanfoga: några tusen DROID-episoder plus dina 50. LeRobot vägrar, och vägran nämner de tre saker som skiljer sig åt.

1. 1
   Hämta 100-episodersprovet, inte hela 1.7 TB

   2 GB räcker för att se strukturen.

   bash

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

2. 2
   Konvertera RLDS till LeRobot-format

   openx2lerobot omsluter OXE:s standardtransformationer och annoterar robottyp och kontrollfrekvens. README-filen placerar detta 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öre något annat

   Denna fil avgör om resten av din dag fungerar.

   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 sammanslagningen och läs felet

   merge laddar varje dataset, sedan kontrollerar validate_all_metadata fps, robot_type och features mot den första i listan, och utlöser ett fel vid första avvikelsen.

   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.

Referensvärdena kommer från det dataset du listade först, vilket är anledningen till att meddelandet klagar på dina 30 fps istället för DROID:s 15. Fixa fps och du stöter på robot_type-kontrollen; fixa det och du stöter på feature-kontrollen, 7 mot 6 för åtgärden. Ingen ordning fungerar, och samma skydd körs vid inspelningstillfället via sanity_check_dataset_robot_compatibility.

Så vad överförs egentligen?

Vikter, inte episoder. Varje modern generalistpolicy har absorberat en del av det under förträning, och när du finjusterar från en släppt kontrollpunkt ärver du det redan avstämt av personer med beräkningskraft att göra det korrekt. pi0:s rapport är uppriktig om proportionen: 9,1 procent av dess förträningsblandning, räknat i tidssteg, är öppen källkodsdata inklusive OXE, Bridge v2 och DROID. Den siffran är pi0:s; varje leverantörs blandning skiljer sig åt.

Det är därför SmolVLA beter sig annorlunda på en lågkostnadsarm. Dess publikation väljer 481 gemenskapsdataset från Hugging Face, filtrerade efter typ av utförande, antal episoder, datakvalitet och bildtäckning: 22.9K episoder, 10.6M bilder, utvärderade på verkliga SO-100 och SO-101 armar. Litet och matchat slår stort och omatchat. Jämför på ACT mot SmolVLA.

Tre vägar värda att ta

Väg A: finjustera från en kontrollpunkt som redan har absorberat datan

De flesta bör välja denna. Du rör aldrig DROID eller Open X-Embodiment: välj en policy vars förträning redan har absorberat data för olika utföranden, spela in dina egna episoder, finjustera.

ACT är det ärliga gränsfallet: ingen basmodell, så ingen av den offentliga datan når den någonsin. Inte automatiskt en nackdel, eftersom den med 20 ms per åtgärdssteg är den enda av de fem som kan sluta en snabb loop, som ACT-sidan beskriver. Välj efter uppgift med hjälp av alla fem jämförda, GR00T N1.7 mot Pi0.5, och de 332 benchmarkresultaten över 85 modeller i arenan.

Väg B: använd DROID som testfixtur

Det 100-episoders urvalet är de bästa 2 GB du kommer att ladda ner denna månad, och inte för träning. Det är ett dataset du vet är korrekt. Kör din konverterare, laddare och ett kort GPU-jobb på det; allt som misslyckas är en infrastruktur-bugg som hittats medan det var billigt. NVIDIA gör detsamma i stor skala: GR00T N1.7-kortet listar fyra eftertränade varianter, för Bridge och Fractal i SimplerEnv, DROID och LIBERO.

Väg C: spela in dina egna, medvetet

Trettio till femtio låter lite bredvid 76 000 tills du kommer ihåg att dina är de enda med din arm, dina kameror och ditt bord. Med LeRobots standardinställningar är 50 episoder 100 minuters verklig tid. Se , och .

Två sätt att gå från offentlig data till en fungerande policy

Vad varje sökväg kostar

Asymmetrin är poängen: sökvägen som lånar mest data är den dyraste och minst sannolika att flytta din arm. Mindre än två timmar av din egen teleoperation slår en terabyte av någon annans Franka. Ingen arm än? /live strömmar en fysisk SO-100 utan registrering. Sedan träna din första policy, och SmolVLA på SO-100 för den specifika guiden.