DROID, BridgeData V2 és Open X használata SO-100-on

Van egy millió trajektóriás nyilvános adatkészlet egy Google Cloud bucketen és egy SO-100 az asztalon, ami 110-150 EUR-ba került alkatrészekben. Miért nem taníthatja az első a másodikat? Részben igen, de az átvitel szinte egyáltalán nem ott történik, ahol az emberek várják, és a legkönnyebbnek tűnő rész egyáltalán nem működik.

Ami következik: mi van benne DROID, BridgeData V2 és Open X-Embodiment, ahol mindegyik ütközik egy alacsony költségű 5-DoF karral, és mit tegyünk helyette. Minden alábbi szám az adott tanulmányból, adatkészlet-kártyáról vagy forrásfájlból származik.

Amit a három adatkészlet valójában tartalmaz

DROID

A három közül a legszabványosabb. Egyetlen berendezés mindenhol: egy Franka Panda Robotiq 2F-85 gripperrel, két állítható ZED 2 sztereó kamerával és egy csuklóra szerelt ZED Mini-vel, Meta Quest 2 kontrollerekkel távvezérelve, Polymetisen keresztül rögzítve 15 Hz-en, mind az ízületi, mind a végberendezés térben. Nyelvi címkék később kerültek hozzá tasq.ai-n keresztül, legfeljebb három epizód.

• 76k trajektória, 350 óra, 564 jelenet, 84 feladat, 50 gyűjtő három kontinensen.
• A fő eredmény a ko-tréning, nem az önálló tréning: az 50/50 arányban tartományon belüli demonstrációkkal kevert kötegek 22 százalékos abszolút sikerrel felülmúlják a következő legjobb módszert a disztribúción belül, és 17 százalékkal azon kívül.
• 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.
• Egy 2 GB-os, 100 epizódos hibakeresési minta található a gs://gresearch/robotics/droid_100 címen. Kezdje ott.

BridgeData V2

A legközelebb egy hobbi beállításhoz: egy WidowX 250 6-DoF kar, 60 096 trajektória 24 környezetben és 13 képességben 5 Hz-en. Figyelje meg az összetételt: 50 365 szakértői távirányítású demonstráció, plusz 9 731 egy randomizált szkriptelt pick-and-place irányelvből, így körülbelül 16 százalék nem emberi demonstráció, ami számít a utánzó tanulás minőségéhez. A szokásos letöltés, az IPEC-COMMUNITY/bridge_orig_lerobot, 53 192 epizódot és 1 893 026 képkockát jelent 5 fps-en, robot_type widowx: kevesebbet, mint a cikkben szereplő 60 096, ezért az adatot a meta/info.json fájlból olvassa ki, ahelyett, hogy bármelyiket idézné.

Open X-Embodiment

Nem adatgyűjtemény a szó szoros értelmében: 60 létező robot adatgyűjtemény 34 laborból egyetlen RLDS gyűjteménybe összevonva, amely 22 megvalósítást és több mint egymillió trajektóriát fed le. A BridgeData V2 benne található bridge_orig néven; a google_robot szelet, a fractal20220817_data, 87 212 epizóddá alakul 3 fps sebességgel.

Az összevonás egy kikötéssel jár, amelyet a tanulmány egyértelműen megfogalmaz. Az RT-X kísérletekhez a szerzők minden forrást 7-DoF végrehajtó műveletté alakítanak, de nem igazítják a koordináta-rendszereket az adatgyűjtemények között, és lehetővé teszik, hogy a műveleti értékek abszolút vagy relatív pozíciók vagy sebességek legyenek, az egyes robotok eredeti vezérlési sémája szerint. Következtetésük: ugyanaz a műveleti vektor nagyon eltérő mozgásokat indukálhat különböző robotoknál.

Az eltérés, négy részben

A megtestesülésbeli eltérést általában egy homályos problémaként kezelik. Pedig négyféle van, különböző módon hibásodnak meg, és kettő nem javítható szkripteléssel.

1. Szabadságfokok

Egy SO-100-asnak öt karízülete és egy megfogója van. Motorokként számolva ez egy 6-DoF kar, és a SmolVLA tanulmány is így nevezi; pozicionáló mechanizmusként számolva 5-DoF, és a LeRobot is így nevezi az inverz-kinematikai docstringjében, amely az 5-DOF SO-101-en végzett lágy-orientációs IK-t írja le, ahol a csukló csak részlegesen követi az orientációt. Egy Franka hét pozicionáló ízülettel rendelkezik. Ez a különbség dönti el, hogy mely pózok léteznek: egy 5-DoF kar általában nem képes egyszerre tetszőleges pozíciót és orientációt elérni, így a megoldó a legközelebbi elérhetőt adja vissza, ami eltér a bemutatott mozgástól. Háttér: szabadságfokok.

# 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

Tehát egy kész DROID ellenőrzőpont nem jelent gyorsítást. A Physical Intelligence a pi05_droid-ot a gs://openpi-assets/checkpoints/pi05_droid címen szállítja, és ugyanaz a README, amely dicséri a széleskörűségét, figyelmeztet, hogy ezek a szakértői ellenőrzőpontok nem biztos, hogy általánosíthatók az Ön beállításaihoz. Állapota nyolc Franka ízületi szám, és képkulcsai az exterior_image_1_left és wrist_image_left. Egyetlen flag sem alakítja ezt hatmotoros SO-100 parancssá.

2. Amit az akcióvektor valójában mond

Mélyebben, mint a dimenzionalitás. A LeRobot konverziókban mindhárom azt mondja meg, hová kell mennie a megfogónak, Descartes-i térben. Egy SO-100 azt mondja meg, hová kell mennie hat szervónak. Az átalakításhoz kinematikai modell és megoldó szükséges, nem pedig átalakítás.

A LeRobot szállítja a hiányzó darabot: az SO follower rendelkezik egy kinematikai processzorral, amely InverseKinematicsEEToJoints és ForwardKinematicsJointsToEE lépéseket tartalmaz. Kulcsai az ee.x, ee.y, ee.z, plusz egy rotációs vektor ee.wx, ee.wy, ee.wz és ee.gripper_pos, így még az orientáció kódolása is eltér a fájlokban található roll-pitch-yaw-tól. Az IK lépés egy orientation_weight-et vesz fel, alapértelmezett értéke 0.01, melynek docstringje szerint 0.0-ra kell állítani a csak pozíció alapú IK-hoz alulvezérelt karokon. Megépítheti a hidat, de minden kölcsönzött akció orientációs fele közelített marad.

3. Vezérlési sebesség

A DROID 15 Hz, a BridgeData V2 5 Hz, a google_robot szelet 3 fps; a pi0 szerzői a keverékük nyílt forráskódú részét alacsony frekvenciájú vezérlésként írják le 2 és 10 Hz között. A LeRobot DatasetRecordConfig alapértelmezése fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50. Egy amely 5 Hz-es adatokon képződött, megtanulta, hogy egy akció 200 ms-ot fed le. Játssza le 30 Hz-en, és a kar lassan mozog; naivan újramintavételezve elkeni azt a képkockát, ahol a markoló bezáródik. Rosszul működik együtt a is: egy 100 lépéses darab 20 másodperc 5 Hz-en, 3.3 másodperc 30 Hz-en.

4. Kamerák

A BridgeData V2 50 trajektóriánként két kameraállást randomizált, és a projektoldala megjegyzi, hogy az adatok nagy része amúgy is csak a rögzített nézetet tartalmazza. A DROID állítható ZED 2 rögzítéseket, valamint egy csuklóra szerelt ZED Minit használt. Önnek két USB webkamerája van, szemre pozícionálva. A kameraállás nem zavaró változó egy ; ez nagyrészt az, amire a vizuális kódoló épített, és semmi a fájlformátumban nem jelzi, hogy az állások eltérnek.

Mi történik, ha mégis megpróbálja egyesíteni az adatokat

A nyilvánvaló terv az összefűzés: néhány ezer DROID epizód plusz a saját 50-ed. A LeRobot elutasítja, és az elutasítás megnevezi a három eltérő dolgot.

1. 1
   Húzza le a 100 epizódos mintát, ne a teljes 1,7 TB-ot

   2 GB elegendő a struktúra megtekintéséhez.

   bash

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

2. 2
   RLDS konvertálása LeRobot formátumba

   Az openx2lerobot magába foglalja az OXE szabványos transzformációkat, és annotálja a robot típusát és a vezérlési frekvenciát. A README a convert.sh fájlba helyezi ezt.

   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
   Olvassa el a meta/info.json fájlt minden más előtt

   Ez a fájl dönti el, hogy a nap hátralévő része működik-e.

   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óbálja meg az összefűzést és olvassa el a hibát

   A merge betölt minden adatkészletet, majd a validate_all_metadata ellenőrzi az fps-t, a robot_type-ot és a features-t a lista első elemével szemben, hibát dobva az első eltérésnél.

   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.

A referenciaértékek abból az adatkészletből származnak, amelyet először sorolt fel, ezért panaszkodik az üzenet az Ön 30 fps-ére a DROID 15-je helyett. Javítsa ki az fps-t, és beleütközik a robot_type ellenőrzésbe; javítsa ki azt, és beleütközik a feature ellenőrzésbe, 7 a 6 ellen az akció esetében. Egyetlen sorrend sem megy át, és ugyanez az őr fut felvételkor a sanity_check_dataset_robot_compatibility segítségével.

Mi is az, ami valójában átkerül?

Súlyok, nem epizódok. Minden modern általános célú irányelv magába szívott valamennyit az előképzés során, és amikor finomhangolsz egy kiadott ellenőrzőpontból már öröklöd azt, amit a megfelelő számítási kapacitással rendelkező emberek már összehangoltak. A pi0 tanulmánya őszintén beszél az arányról: az előképzési keverékének 9,1 százaléka, időlépésekben számolva, nyílt forráskódú adat, beleértve az OXE-t, a Bridge v2-t és a DROID-ot. Ez az adat a pi0-é; minden gyártó keveréke eltér.

Ezért SmolVLA viselkedik másképp egy alacsony költségű karon. Tanulmánya 481 közösségi adatkészletet választ ki a Hugging Face-ről, szűrve az inkarnáció típusa, az epizódok száma, az adatminőség és a képkocka-lefedettség alapján: 22,9K epizód, 10,6M képkocka, valós SO-100 és SO-101 karokon értékelve. A kicsi és illesztett felülmúlja a nagyot és nem illesztettet. Hasonlítsa össze itt: ACT against SmolVLA.

Három járható út

A út: finomhangolás egy olyan ellenőrzőpontról, amely már feldolgozta az adatokat

A legtöbb embernek ezt kellene választania. Soha ne nyúljon a DROID-hoz vagy az Open X-Embodiment-hez: válasszon egy olyan irányelvet, amelynek előképzése már magába szívta a kereszt-inkarnációs adatokat, rögzítse saját epizódjait, majd finomhangolja.

Az ACT az őszinte szélső eset: nincs alapmodell, így semmilyen nyilvános adat nem éri el. Ez nem feltétlenül hátrány, mivel 20 ms-os akció lépésenként az öt közül ez az egyetlen, amely gyors hurkot tud zárni, ahogy az ACT oldal részletezi. Válasszon feladat szerint a következőket használva: mind az öt összehasonlítva, GR00T N1.7 Pi0.5 ellen, és a 332 benchmark eredmény 85 modellre vonatkozóan a következőben: az aréna.

B útvonal: DROID használata tesztberendezésként

A 100 epizódos minta a legjobb 2 GB, amit ebben a hónapban letölt, és nem betanításra. Ez egy olyan adathalmaz, amiről tudja, hogy helyes. Futtassa rajta a konverterét, betöltőjét és egy rövid GPU feladatot; bármi, ami elromlik, egy infrastruktúra hiba, amit olcsón találtak meg. Az NVIDIA ugyanezt teszi nagy léptékben: a GR00T N1.7 kártya négy utólag betanított változatot sorol fel, a Bridge és Fractal számára a SimplerEnv-ben, a DROID és LIBERO számára.

C út: rögzítse sajátját, szándékosan

Harminc-ötven kevésnek tűnik 76 000 mellett, amíg eszébe nem jut, hogy az Ön adatai az egyetlenek, amelyek az Ön karjával, kameráival és asztalával készültek. A LeRobot alapértelmezett beállításai szerint 50 epizód 100 perc valós időt jelent. Lásd: , és .

Két módja annak, hogy nyilvános adatokból működőképes irányelvet hozzunk létre

Az egyes útvonalak költségei

Az aszimmetria a lényeg: az az út, amely a legtöbb adatot kölcsönzi, a legdrágább és a legkevésbé valószínű, hogy megmozdítja a karját. Két óránál kevesebb saját teleoperáció többet ér, mint valaki más Franka robotjának egy terabájtnyi adata. Még nincs robotkarja? /live élőben közvetít egy fizikai SO-100-at regisztráció nélkül. Ezután képezze be az első irányelvét, majd SmolVLA az SO-100-on a konkrét útmutatóért.