Gebruik van DROID, BridgeData V2 en Open X op 'n SO-100

Daar is 'n miljoen-trajek publieke datastel op 'n Google Cloud-emmer en 'n SO-100 op die lessenaar wat 110 tot 150 EUR in onderdele gekos het. Waarom kan die eerste nie die tweede leer nie? Dit kan gedeeltelik, maar byna niks van die oordrag gebeur waar mense verwag nie, en die deel wat die maklikste lyk, werk glad nie.

Wat volg: wat is binne DROID, BridgeData V2 en Open X-Embodiment, waar elkeen bots met 'n laekoste 5-DoF arm, en wat om eerder te doen. Elke nommer hieronder kom uit die referaat, datastelkaart of bronlêer waaraan dit behoort.

Wat die drie datastelle werklik bevat

DROID

Die mees gestandaardiseerde van die drie. Een opstelling oral: 'n Franka Panda met 'n Robotiq 2F-85 gryper, twee verstelbare ZED 2 stereokameras en 'n pols ZED Mini, tele-opereer met Meta Quest 2 beheerders, opgeneem deur Polymetis teen 15 Hz in beide gewrig- en eindeffektor ruimte. Taallabels het later via tasq.ai gekom, tot drie per episode.

• 76k trajekte, 350 ure, 564 tonele, 84 take, 50 versamelaars op drie kontinente.
• Die hoofresultaat is mede-opleiding, nie selfstandige opleiding nie: bondels wat 50/50 gemeng is met in-domein demonstrasies, oortref die volgende beste metode met 22 persent absolute sukses in verspreiding, 17 persent daarbuite.
• 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.
• ’n 2 GB, 100-episode ontfoutingsmonster is by gs://gresearch/robotics/droid_100. Begin daar.

BridgeData V2

Die naaste aan 'n stokperdjie-opstelling: 'n WidowX 250 6-DoF arm, 60,096 trajekte oor 24 omgewings en 13 vaardighede teen 5 Hz. Let op die samestelling: 50,365 kundige tele-geopereerde demonstrasies plus 9,731 van 'n gerandomiseerde geskripte optel-en-plaas beleid, so ongeveer 16 persent is nie menslike demonstrasie nie, wat saak maak vir nabootsingsleer kwaliteit. Die gewone aflaai, IPEC-COMMUNITY/bridge_orig_lerobot, rapporteer 53,192 episodes en 1,893,026 rame teen 5 fps, robot_type widowx: minder as die referaat se 60,096, so lees die telling van meta/info.json eerder as om een van die twee aan te haal.

Open X-Embodiment

Nie 'n datastel in dieselfde sin nie: 60 bestaande robotdatastelle van 34 laboratoriums saamgevoeg in een RLDS-versameling wat 22 beliggamings en meer as 'n miljoen trajekte dek. BridgeData V2 is daarin as bridge_orig; die google_robot-segment, fractal20220817_data, skakel om na 87,212 episodes teen 3 fps.

Die saamvoeging hou 'n voorbehoud in wat die referaat uitdruklik stel. Vir die RT-X eksperimente skakel die outeurs elke bron om na 'n 7-DoF eind-effektor aksie, maar belyn nie koördinaatraamwerke oor datastelle heen nie, en laat aksiewaardes toe om absolute of relatiewe posisies of snelhede te wees, volgens elke robot se oorspronklike beheerskema. Hul gevolgtrekking: dieselfde aksievektor kan baie verskillende bewegings vir verskillende robotte veroorsaak.

Die wanpassing, in vier dele

Embodiment mismatch word gewoonlik as een vae probleem behandel. Dit is vier, hulle misluk verskillend, en twee is nie met skripte reg te maak nie.

1. Grade van vryheid

’n SO-100 het vyf armgewrigte plus ’n gryper. Getel as motors is dit ’n 6-DoF arm, en die SmolVLA-artikel noem dit so; getel as ’n posisioneringsmeganisme is dit 5-DoF, en LeRobot noem dit so in sy inverse-kinematika-docstring, wat sagte-oriëntasie IK op die 5-DOF SO-101 beskryf waar die pols oriëntasie slegs gedeeltelik volg. ’n Franka het sewe posisioneringsgewrigte. Daardie gaping besluit watter posisies bestaan: ’n 5-DoF arm kan oor die algemeen nie ’n arbitrêre posisie en oriëntasie gelyktydig bereik nie, so die oplosser gee die naaste terug wat dit kan, ’n ander beweging as die een wat gedemonstreer is. Agtergrond: grade van vryheid.

# 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

Dus is 'n klaargemaakte DROID-kontrolepunt geen kortpad nie. Physical Intelligence verskaf pi05_droid by gs://openpi-assets/checkpoints/pi05_droid, en dieselfde README wat die breedte daarvan prys, waarsku dat hierdie kundige kontrolepunte dalk nie na jou opstelling sal veralgemeen nie. Die toestand daarvan is agt Franka-gewrignommers en die beeldleutels is exterior_image_1_left en wrist_image_left. Geen vlag verander dit in 'n ses-motor SO-100-opdrag nie.

2. Wat die aksievektor werklik sê

Dieper as dimensionaliteit. In die LeRobot-omskakelings sê al drie waar die gryper moet gaan, in Kartesiese ruimte. 'n SO-100 sê waar ses servo's moet gaan. Omskakeling benodig 'n kinematiese model en 'n oplosser, nie 'n hervorming nie.

LeRobot lewer wel die ontbrekende stuk: die SO follower het 'n kinematika-verwerker met InverseKinematicsEEToJoints en ForwardKinematicsJointsToEE stappe. Sy sleutels is ee.x, ee.y, ee.z plus 'n rotasievektor ee.wx, ee.wy, ee.wz en ee.gripper_pos, so selfs die oriëntasie-enkodering verskil van die roll-pitch-yaw in die lêers. Die IK stap neem 'n orientation_weight, verstek 0.01, waarvan die docstring sê om 0.0 te stel vir posisie-alleen IK op onder-aangedrewe arms. Jy kan die brug bou, maar die oriëntasie-helfte van elke geleende aksie bly benaderd.

3. Beheer tempo

DROID is 15 Hz, BridgeData V2 5 Hz, die google_robot sny 3 fps; pi0 se outeurs beskryf die open-source deel van hul mengsel as lae-frekwensie beheer tussen 2 en 10 Hz. LeRobot se DatasetRecordConfig verstek na fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50. 'n wat op 5 Hz data opgelei is, het geleer dat een aksie 200 ms dek. Speel dit teen 30 Hz af en die arm kruip; hersampleer naïef en jy smeer die raam waar die gryper sluit. Dit interaksie ook sleg met : 'n 100-stap segment is 20 sekondes teen 5 Hz, 3.3 teen 30 Hz.

4. Kameras

BridgeData V2 het twee kameraposisies elke 50 trajekte gerandomiseer, en sy projekbladsy meld dat die meeste van die data in elk geval slegs die vaste aansig bevat. DROID het verstelbare ZED 2-monterings plus 'n pols ZED Mini gebruik. Jy het twee USB-webkameras wat met die oog geposisioneer is. Kameraposisie is nie 'n hinderlike veranderlike vir 'n ; dit is baie van waarop die visuele enkodeerder gefokus het, en niks in die lêerformaat vertel jou dat die posisies verskil nie.

Wat gebeur as jy in elk geval probeer om die data saam te voeg

Die voor die hand liggende plan is om te konkateneer: 'n paar duisend DROID-episodes plus jou 50. LeRobot weier, en die weiering noem die drie dinge wat verskil.

1. 1
   Trek die 100-episode-voorbeeld, nie die volle 1.7 TB nie

   2 GB is genoeg om die struktuur te sien.

   bash

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

2. 2
   Skakel RLDS om na LeRobot-formaat

   openx2lerobot omvou die OXE standaard transformasies en annoteer robot tipe en beheerfrekwensie. Die README plaas dit 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
   Lees meta/info.json voor enigiets anders

   Hierdie lêer besluit of die res van jou dag werk.

   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
   Probeer die samesmelting en lees die fout

   merge laai elke datastel, dan kontroleer validate_all_metadata fps, robot_type en kenmerke teen die eerste in die lys, en gee 'n fout by die eerste wanpas.

   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.

Die verwysingswaardes kom van watter datastel jy ook al eerste gelys het, en daarom kla die boodskap oor jou 30 fps eerder as DROID se 15. Maak die fps reg en jy tref die robot_type-kontrole; maak dit reg en jy tref die kenmerkkontrole, 7 teen 6 vir die aksie. Geen volgorde kom deur nie, en dieselfde kontrole loop tydens opname via sanity_check_dataset_robot_compatibility.

So wat dra eintlik oor?

Gewigte, nie episodes nie. Elke moderne algemene beleid het 'n deel daarvan in vooropleiding geabsorbeer, en wanneer jy van 'n vrygestelde erf jy dit reeds versoen deur mense met die rekenkrag om dit behoorlik te doen. pi0 se referaat is openhartig oor die proporsie: 9.1 persent van sy vooropleidingsmengsel, getel in tydstappe, is oopbron data insluitend OXE, Bridge v2 en DROID. Daardie syfer is pi0 s'n; elke verskaffer se mengsel verskil.

Dit is hoekom SmolVLA anders optree op 'n laekoste-arm. Die referaat daarvan kies 481 gemeenskapsdataskemas van Hugging Face, gefiltreer volgens beliggamingstipe, episode-telling, datakwaliteit en raamdekking: 22.9K episodes, 10.6M rame, geëvalueer op regte SO-100 en SO-101 arms. Klein en gepas klop groot en onvanpas. Vergelyk op ACT teen SmolVLA.

Drie paaie wat die moeite werd is om te volg

Pad A: fyninstel vanaf 'n kontrolepunt wat reeds die data verwerk het

Die meeste mense moet hierdie een volg. Jy raak nooit aan DROID of Open X-Embodiment nie: kies 'n beleid waarvan die vooropleiding reeds kruis-beliggaming data geabsorbeer het, neem jou eie episodes op, fyninstel.

ACT is die eerlike randgeval: geen basismodel nie, so geen van die publieke data bereik dit ooit nie. Nie outomaties 'n nadeel nie, aangesien dit teen 20 ms per aksiestap die enigste van die vyf is wat 'n vinnige lus kan sluit, soos die ACT-bladsy uiteensit. Kies volgens taak deur gebruik te maak van al vyf vergelyk, GR00T N1.7 teen Pi0.5, en die 332 maatstafresultate oor 85 modelle in die arena.

Pad B: gebruik DROID as 'n toetsarmatuur

Die 100-episode-monster is die beste 2 GB wat jy hierdie maand sal aflaai, en nie vir opleiding nie. Dit is 'n datastel wat jy weet korrek is. Voer jou omskakelaar, laaier en 'n kort GPU-taak daarop uit; enigiets wat misluk, is 'n infrastruktuurfout wat gevind is terwyl dit goedkoop was. NVIDIA doen dieselfde op skaal: die GR00T N1.7-kaart lys vier na-opgeleide variante, vir Bridge en Fractal in SimplerEnv, DROID en LIBERO.

Pad C: neem jou eie op, doelbewus

Dertig tot vyftig klink klein langs 76,000 totdat jy onthou joune is die enigstes met jou arm, jou kameras en jou tafel. Teen LeRobot se verstekke is 50 episodes 100 minute se werklike tyd. Sien , en .

Twee maniere om van publieke data na 'n werkende beleid te kom

Wat elke pad kos

Die asimmetrie is die punt: die pad wat die meeste data leen, is die duurste en die minste geneig om jou arm te beweeg. Minder as twee uur van jou eie teleoperasie oortref 'n teragreep van iemand anders se Franka. Nog geen arm nie? /live stroom 'n fisiese SO-100 sonder registrasie. Dan lei jou eerste beleid op, en SmolVLA op SO-100 vir die spesifieke gids.