DROID, BridgeData V2 en Open X gebruiken op een SO-100

Er is een openbare dataset met een miljoen trajecten op een Google Cloud bucket en een SO-100 op het bureau die 110 tot 150 EUR aan onderdelen kostte. Waarom kan de eerste de tweede niet leren? Gedeeltelijk wel, maar bijna geen van de overdracht gebeurt waar mensen het verwachten, en het deel dat het gemakkelijkst lijkt, werkt helemaal niet.

Wat volgt: wat er in DROID, BridgeData V2 en Open X-Embodiment zit, waar elk botst met een goedkope 5-DoF arm, en wat je in plaats daarvan moet doen. Elk getal hieronder komt uit het paper, de datasetkaart of het bronbestand waartoe het behoort.

Wat de drie datasets daadwerkelijk bevatten

DROID

De meest gestandaardiseerde van de drie. Eén opstelling overal: een Franka Panda met een Robotiq 2F-85 grijper, twee verstelbare ZED 2 stereocamera's en een pols-ZED Mini, telebediend met Meta Quest 2 controllers, opgenomen via Polymetis op 15 Hz in zowel gewrichts- als eindeffector ruimte. Taallabels kwamen later via tasq.ai, tot drie per aflevering.

• 76k trajecten, 350 uur, 564 scènes, 84 taken, 50 verzamelaars op drie continenten.
• Het belangrijkste resultaat is co-training, geen op zichzelf staande training: batches die 50/50 gemengd zijn met in-domain demonstraties verslaan de op één na beste methode met 22 procent absolute succes in distributie, 17 procent daarbuiten.
• 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.
• Een 2 GB, 100-episode debugging sample bevindt zich op gs://gresearch/robotics/droid_100. Begin daar.

BridgeData V2

Het dichtst bij een hobby-opstelling: een WidowX 250 6-DoF arm, 60.096 trajecten verdeeld over 24 omgevingen en 13 vaardigheden bij 5 Hz. Let op de samenstelling: 50.365 door experts geteleopereerde demonstraties plus 9.731 van een gerandomiseerde gescripte pick-and-place policy, dus ongeveer 16 procent is geen menselijke demonstratie, wat van belang is voor imitatieleren kwaliteit. De gebruikelijke download, IPEC-COMMUNITY/bridge_orig_lerobot, rapporteert 53.192 episodes en 1.893.026 frames bij 5 fps, robot_type widowx: minder dan de 60.096 van het artikel, dus lees het aantal uit meta/info.json in plaats van een van beide te citeren.

Open X-Embodiment

Geen dataset in de gebruikelijke zin: 60 bestaande robotdatasets van 34 laboratoria samengevoegd tot één RLDS-collectie, die 22 uitvoeringen en meer dan een miljoen trajecten omvat. BridgeData V2 bevindt zich erin als bridge_orig; de google_robot-slice, fractal20220817_data, wordt omgezet naar 87.212 afleveringen met 3 fps.

De samenvoeging brengt een voorbehoud met zich mee dat het artikel expliciet vermeldt. Voor de RT-X experimenten zetten de auteurs elke bron om in een 7-DoF eindeffectoractie, maar lijnen ze de coördinatenstelsels niet uit over de datasets heen, en staan ze toe dat actiewaarden absolute of relatieve posities of snelheden zijn, per het oorspronkelijke besturingsschema van elke robot. Hun conclusie: dezelfde actievector kan zeer verschillende bewegingen veroorzaken voor verschillende robots.

De mismatch, in vier delen

Mismatches in belichaming worden meestal behandeld als één vaag probleem. Het zijn er vier, ze falen op verschillende manieren, en twee zijn niet te verhelpen met scripting.

1. Vrijheidsgraden

Een SO-100 heeft vijf armgewrichten plus een grijper. Geteld als motoren is dat een 6-DoF arm, en het SmolVLA-paper noemt het zo; geteld als een positioneringsmechanisme is het 5-DoF, en LeRobot noemt het zo in zijn inverse-kinematica docstring, die soft-orientation IK beschrijft op de 5-DOF SO-101 waar de pols de oriëntatie slechts gedeeltelijk volgt. Een Franka heeft zeven positioneringsgewrichten. Die kloof bepaalt welke poses bestaan: een 5-DoF arm kan over het algemeen niet tegelijkertijd een willekeurige positie en oriëntatie bereiken, dus de oplosser retourneert het dichtstbijzijnde dat het kan, een andere beweging dan de gedemonstreerde. Achtergrond: vrijheidsgraden.

# 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

Een kant-en-klaar DROID checkpoint is dus geen kortere weg. Physical Intelligence levert pi05_droid op gs://openpi-assets/checkpoints/pi05_droid, en dezelfde README die de breedte ervan prijst, waarschuwt dat deze expert checkpoints mogelijk niet generaliseren naar uw setup. De staat ervan bestaat uit acht Franka gewrichtsnummers en de afbeeldingssleutels zijn exterior_image_1_left en wrist_image_left. Geen enkele vlag verandert dat in een zes-motorige SO-100 commando.

2. Wat de actievector daadwerkelijk zegt

Dieper dan dimensionaliteit. In de LeRobot conversies zeggen alle drie waar de grijper naartoe moet, in Cartesische ruimte. Een SO-100 zegt waar zes servo's naartoe moeten. Converteren vereist een kinematisch model en een oplosser, geen herschikking.

LeRobot levert wel het ontbrekende stuk: de SO follower heeft een kinematica-processor met InverseKinematicsEEToJoints en ForwardKinematicsJointsToEE stappen. De sleutels zijn ee.x, ee.y, ee.z plus een rotatievector ee.wx, ee.wy, ee.wz en ee.gripper_pos, dus zelfs de oriëntatie-codering verschilt van de roll-pitch-yaw in de bestanden. De IK-stap gebruikt een orientation_weight, standaard 0.01, waarvan de docstring aangeeft om 0.0 in te stellen voor positie-alleen IK op onder-aangedreven armen. Je kunt de brug bouwen, maar de oriëntatiehelft van elke geleende actie blijft benaderd.

3. Besturingsfrequentie

DROID is 15 Hz, BridgeData V2 5 Hz, de google_robot slice 3 fps; de auteurs van pi0 beschrijven het open-source deel van hun mix als laagfrequente besturing tussen 2 en 10 Hz. LeRobot's DatasetRecordConfig stelt standaard fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50 in. Een getraind op 5 Hz data leerde dat één actie 200 ms beslaat. Speel het af op 30 Hz en de arm kruipt; hersampleer naïef en je smeert het frame uit waar de grijper sluit. Het interageert ook slecht met : een 100-staps chunk is 20 seconden bij 5 Hz, 3.3 bij 30 Hz.

4. Camera's

BridgeData V2 randomiseerde twee cameraposes elke 50 trajecten, en de projectpagina vermeldt dat de meeste gegevens sowieso alleen het vaste zicht bevatten. DROID gebruikte verstelbare ZED 2-bevestigingen plus een ZED Mini aan de pols. Je hebt twee USB-webcams die op het oog zijn gepositioneerd. Camerapositie is geen hinderlijke variabele voor een ; het is veel van waar de visuele encoder op focuste, en niets in het bestandsformaat vertelt je dat de poses verschillen.

Wat gebeurt er als je de gegevens toch probeert samen te voegen

Het voor de hand liggende plan is om te concateneren: een paar duizend DROID-afleveringen plus jouw 50. LeRobot weigert, en de weigering noemt de drie dingen die verschillen.

1. 1
   Haal de 100-afleveringen sample op, niet de volledige 1.7 TB

   2 GB is genoeg om de structuur te zien.

   bash

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

2. 2
   Converteer RLDS naar LeRobot-vorm

   openx2lerobot omvat de standaard OXE-transformaties en annoteert het robottype en de controlefrequentie. De README plaatst 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 voordat je iets anders doet

   Dit bestand bepaalt of de rest van je dag werkt.

   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 de samenvoeging en lees de foutmelding

   merge laadt elke dataset, waarna validate_all_metadata de fps, robot_type en features controleert tegen de eerste in de lijst, en een fout genereert bij de eerste afwijking.

   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.

De referentiewaarden komen van de dataset die je als eerste hebt vermeld, daarom klaagt het bericht over jouw 30 fps in plaats van DROID's 15. Corrigeer de fps en je stuit op de robot_type-controle; corrigeer die en je stuit op de feature-controle, 7 tegen 6 voor de actie. Geen enkele volgorde komt erdoorheen, en dezelfde controle wordt uitgevoerd tijdens het opnemen via sanity_check_dataset_robot_compatibility.

Dus wat wordt er eigenlijk overgedragen?

Gewichten, geen episodes. Elk modern generalistisch beleid heeft er een deel van geabsorbeerd tijdens de voorbereiding, en wanneer u fine-tunen van een uitgebracht checkpoint erft u het al verzoend door mensen met de rekenkracht om het correct te doen. Het artikel van pi0 is openhartig over het aandeel: 9,1 procent van de voorbereidingsmix, geteld in tijdstappen, bestaat uit open-source gegevens, waaronder OXE, Bridge v2 en DROID. Dat cijfer is van pi0; de mix van elke leverancier verschilt.

Dit is waarom SmolVLA zich anders gedraagt op een goedkope arm. De paper selecteert 481 community datasets van Hugging Face, gefilterd op type belichaming, aantal afleveringen, datakwaliteit en frame-dekking: 22.9K afleveringen, 10.6M frames, geëvalueerd op echte SO-100 en SO-101 armen. Klein en passend verslaat groot en niet-passend. Vergelijk op ACT tegen SmolVLA.

Drie paden die de moeite waard zijn

Pad A: fine-tunen vanaf een checkpoint dat de data al heeft verwerkt

De meeste mensen zouden deze moeten kiezen. Je raakt DROID of Open X-Embodiment nooit aan: kies een beleid waarvan de voor-training al cross-embodiment data heeft geabsorbeerd, neem je eigen afleveringen op, fine-tune.

ACT is het eerlijke randgeval: geen basismodel, dus geen van de openbare gegevens bereikt het ooit. Niet automatisch een nadeel, aangezien het met 20 ms per actiestap de enige van de vijf is die een snelle lus kan sluiten, zoals de ACT-pagina uiteenzet. Kies per taak met behulp van alle vijf vergeleken, GR00T N1.7 tegen Pi0.5, en de 332 benchmarkresultaten van 85 modellen in de arena.

Pad B: gebruik DROID als testopstelling

De 100-afleveringen-sample is de beste 2 GB die je deze maand zult downloaden, en niet voor training. Het is een dataset waarvan je weet dat deze correct is. Voer je converter, loader en een korte GPU-taak erop uit; alles wat faalt, is een infrastructuurfout die is gevonden toen het nog goedkoop was. NVIDIA doet hetzelfde op schaal: de GR00T N1.7-kaart vermeldt vier nader getrainde varianten, voor Bridge en Fractal in SimplerEnv, DROID en LIBERO.

Pad C: neem je eigen data op, weloverwogen

Dertig tot vijftig klinkt weinig naast 76.000 totdat je bedenkt dat die van jou de enige zijn met jouw arm, jouw camera's en jouw tafel. Met de standaardinstellingen van LeRobot zijn 50 afleveringen 100 minuten kloktijd. Zie , en .

Twee manieren om van openbare data tot een werkend beleid te komen

Wat elk pad kost

De asymmetrie is het punt: het pad dat de meeste data leent, is het duurst en het minst waarschijnlijk om je arm te bewegen. Minder dan twee uur van je eigen teleoperatie verslaat een terabyte van iemand anders' Franka. Nog geen arm? /live streamt een fysieke SO-100 zonder aanmelding. Train dan je eerste beleid, en SmolVLA op SO-100 voor de specifieke handleiding.