Utilisation de DROID, BridgeData V2 et Open X sur un SO-100

Il existe un ensemble de données publiques d'un million de trajectoires sur un bucket Google Cloud et un sur le bureau qui a coûté 110 à 150 EUR en pièces. Pourquoi le premier ne peut-il pas enseigner au second ? Il le peut en partie, mais presque aucun transfert ne se produit là où les gens s'y attendent, et la partie qui semble la plus facile ne fonctionne pas du tout.

Ce qui suit : ce qui se trouve dans , et , où chacun entre en collision avec un bras 5-DoF à faible coût, et ce qu'il faut faire à la place. Chaque chiffre ci-dessous provient du document, de la fiche de données ou du fichier source auquel il appartient.

Ce que contiennent réellement les trois ensembles de données

DROID

Le plus standardisé des trois. Un seul équipement partout : un Franka Panda avec une pince Robotiq 2F-85, deux caméras stéréo ZED 2 réglables et une ZED Mini au poignet, téléopéré avec des contrôleurs Meta Quest 2, enregistré via Polymetis à 15 Hz à la fois dans l'espace articulaire et de l'effecteur final. Les étiquettes linguistiques sont venues plus tard via tasq.ai, jusqu'à trois par épisode.

• 76k trajectoires, 350 heures, 564 scènes, 84 tâches, 50 collecteurs sur trois continents.
• Le résultat principal est le co-apprentissage, et non l'apprentissage autonome : des lots mélangés à 50/50 avec des démonstrations intra-domaine ont surpassé la meilleure méthode suivante de 22 % de succès absolu en distribution, et de 17 % hors distribution.
• IPEC-COMMUNITY/droid_lerobot : 92 233 épisodes, 27 044 326 images, franka, 15 ips, codebase_version v2.0, trois flux AV1 à 180x320, 392 Go.
• Un échantillon de débogage de 2 Go et 100 épisodes se trouve à l'adresse gs://gresearch/robotics/droid_100. Commencez par là.

BridgeData V2

Le plus proche d'une configuration de loisir : un bras WidowX 250 à 6 degrés de liberté, 60 096 trajectoires à travers 24 environnements et 13 compétences à 5 Hz. Notez la composition : 50 365 démonstrations téléopérées par des experts plus 9 731 provenant d'une politique de prise et de placement scriptée et randomisée, donc environ 16 % ne sont pas des démonstrations humaines, ce qui est important pour l'apprentissage par imitation la qualité. Le téléchargement habituel, IPEC-COMMUNITY/bridge_orig_lerobot, rapporte 53 192 épisodes et 1 893 026 images à 5 ips, robot_type widowx : moins que les 60 096 du document, il faut donc lire le compte à partir de meta/info.json plutôt que de citer l'un ou l'autre.

Open X-Embodiment

Pas un jeu de données au sens habituel : 60 jeux de données de robots existants provenant de 34 laboratoires regroupés dans une collection RLDS couvrant 22 implémentations et plus d'un million de trajectoires. BridgeData V2 s'y trouve sous le nom de bridge_orig ; la tranche google_robot, fractal20220817_data, se convertit en 87 212 épisodes à 3 ips.

Le regroupement comporte une mise en garde que l'article énonce clairement. Pour les expériences RT-X, les auteurs convertissent chaque source en une action d'effecteur final à 7 DDL, mais n'alignent pas les systèmes de coordonnées entre les jeux de données, et permettent que les valeurs d'action soient des positions ou des vitesses absolues ou relatives, selon le schéma de contrôle original de chaque robot. Leur conclusion : le même vecteur d'action peut induire des mouvements très différents pour différents robots.

Le décalage, en quatre parties

Le désalignement d'incarnation est généralement traité comme un problème vague. Il y en a quatre, ils échouent différemment, et deux ne peuvent pas être corrigés par script.

1. Degrés de liberté

Un SO-100 possède cinq articulations de bras plus une pince. Compté comme des moteurs, c'est un bras à 6 DDL, et le document SmolVLA l'appelle ainsi ; compté comme un mécanisme de positionnement, c'est un bras à 5 DDL, et LeRobot l'appelle ainsi dans sa docstring de cinématique inverse, qui décrit la CI à orientation douce sur le SO-101 à 5 DDL où le poignet ne suit l'orientation que partiellement. Un Franka possède sept articulations de positionnement. Cet écart détermine les poses possibles : un bras à 5 DDL ne peut généralement pas atteindre une position et une orientation arbitraires simultanément, de sorte que le solveur renvoie la position la plus proche qu'il peut, un mouvement différent de celui démontré. Contexte : degrés de liberté.

# 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

Ainsi, un point de contrôle DROID prêt à l'emploi n'est pas un raccourci. Physical Intelligence livre pi05_droid à gs://openpi-assets/checkpoints/pi05_droid, et le même README qui vante son étendue avertit que ces points de contrôle experts pourraient ne pas se généraliser à votre configuration. Son état est composé de huit nombres d'articulations Franka et ses clés d'image sont exterior_image_1_left et wrist_image_left. Aucun drapeau ne transforme cela en une commande SO-100 à six moteurs.

2. Ce que le vecteur d'action dit réellement

Plus profond que la dimensionnalité. Dans les conversions LeRobot, les trois indiquent où le préhenseur doit aller, dans l'espace cartésien. Un SO-100 indique où six servomoteurs doivent aller. La conversion nécessite un modèle cinématique et un solveur, pas un remodelage.

LeRobot fournit bien la pièce manquante : le suiveur SO dispose d'un processeur cinématique avec les étapes InverseKinematicsEEToJoints et ForwardKinematicsJointsToEE. Ses clés sont ee.x, ee.y, ee.z plus un vecteur de rotation ee.wx, ee.wy, ee.wz et ee.gripper_pos, de sorte que même l'encodage de l'orientation diffère du roulis-tangage-lacet (roll-pitch-yaw) dans les fichiers. L'étape IK prend un orientation_weight, par défaut 0.01, dont la docstring indique de le régler à 0.0 pour une IK basée uniquement sur la position pour les bras sous-actionnés. Vous pouvez construire le pont, mais la moitié de l'orientation de chaque action empruntée reste approximée.

3. Fréquence de contrôle

DROID est à 15 Hz, BridgeData V2 à 5 Hz, la tranche google_robot à 3 ips ; les auteurs de pi0 décrivent la partie open-source de leur mélange comme un contrôle à basse fréquence entre 2 et 10 Hz. Le DatasetRecordConfig de LeRobot utilise par défaut fps 30, episode_time_s 60, reset_time_s 60, num_episodes 50. Une entraînée sur des données à 5 Hz a appris qu'une action couvre 200 ms. Rejouez-la à 30 Hz et le bras rampe ; rééchantillonnez naïvement et vous étalez l'image où le préhenseur se ferme. Cela interagit également mal avec le : un bloc de 100 étapes représente 20 secondes à 5 Hz, 3,3 secondes à 30 Hz.

4. Caméras

BridgeData V2 a randomisé deux poses de caméra toutes les 50 trajectoires, et sa page de projet note que la plupart des données ne contiennent de toute façon que la vue fixe. DROID a utilisé des supports ZED 2 réglables ainsi qu'une ZED Mini au poignet. Vous avez deux webcams USB positionnées à l'œil. La pose de la caméra n'est pas une variable parasite pour un ; c'est en grande partie ce sur quoi l'encodeur visuel s'est basé, et rien dans le format de fichier ne vous indique que les poses diffèrent.

Ce qui se passe lorsque vous essayez de fusionner les données malgré tout

Le plan évident est de concaténer : quelques milliers d'épisodes DROID plus vos 50. LeRobot refuse, et le refus nomme les trois choses qui diffèrent.

1. 1
   Télécharger l'échantillon de 100 épisodes, pas les 1,7 To complets

   2 Go suffisent pour voir la structure.

   bash

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

2. 2
   Convertir RLDS au format LeRobot

   openx2lerobot encapsule les transformations standard OXE et annote le type de robot ainsi que la fréquence de contrôle. Le README place ceci dans 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
   Lire meta/info.json avant toute autre chose

   Ce fichier détermine si le reste de votre journée se déroulera sans accroc.

   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
   Tenter la fusion et lire l'erreur

   merge charge chaque jeu de données, puis validate_all_metadata vérifie les fps, le robot_type et les features par rapport au premier de la liste, levant une erreur à la première incompatibilité.

   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.

Les valeurs de référence proviennent du jeu de données que vous avez listé en premier, c'est pourquoi le message se plaint de vos 30 fps plutôt que des 15 de DROID. Corrigez les fps et vous rencontrerez la vérification du robot_type ; corrigez cela et vous rencontrerez la vérification des features, 7 contre 6 pour l'action. Aucun ordre ne permet de passer, et la même protection s'exécute au moment de l'enregistrement via sanity_check_dataset_robot_compatibility.

Alors, qu'est-ce qui est réellement transféré ?

Les poids, pas les épisodes. Chaque politique généraliste moderne en a absorbé une partie lors du pré-entraînement, et lorsque vous à partir d'un publié, vous l'héritez déjà réconcilié par des personnes disposant de la puissance de calcul nécessaire pour le faire correctement. L'article de pi0 est franc sur la proportion : 9,1 % de son mélange de pré-entraînement, compté en pas de temps, est constitué de données open-source incluant OXE, Bridge v2 et DROID. Ce chiffre est celui de pi0 ; le mélange de chaque fournisseur diffère.

C'est pourquoi SmolVLA se comporte différemment sur un bras à faible coût. Son article sélectionne 481 ensembles de données communautaires de Hugging Face, filtrés par type d'incarnation, nombre d'épisodes, qualité des données et couverture d'images : 22.9K épisodes, 10.6M images, évalués sur de vrais bras SO-100 et SO-101. Petit et adapté l'emporte sur grand et inadapté. Comparez sur ACT against SmolVLA.

Trois voies à suivre

Voie A : affiner à partir d'un point de contrôle qui a déjà absorbé les données

La plupart des gens devraient choisir celle-ci. Vous ne touchez jamais à DROID ou Open X-Embodiment : choisissez une politique dont le pré-entraînement a déjà absorbé les données inter-incarnations, enregistrez vos propres épisodes, affinez.

ACT est le cas limite honnête : pas de modèle de base, donc aucune des données publiques ne l'atteint. Ce n'est pas automatiquement un désavantage, car à 20 ms par étape d'action, c'est le seul des cinq qui peut boucler une boucle rapide, comme la page ACT l'explique. Choisissez par tâche en utilisant les cinq comparés, GR00T N1.7 contre Pi0.5, et les 332 résultats de benchmark sur 85 modèles dans l'arène.

Chemin B : utiliser DROID comme banc d'essai

L'échantillon de 100 épisodes est le meilleur 2 Go que vous téléchargerez ce mois-ci, et non pour l'entraînement. C'est un jeu de données dont vous savez qu'il est correct. Exécutez votre convertisseur, votre chargeur et une courte tâche GPU dessus ; tout ce qui échoue est un bug d'infrastructure trouvé alors que c'était bon marché. NVIDIA fait de même à grande échelle : la carte GR00T N1.7 répertorie quatre variantes post-entraînées, pour Bridge et Fractal dans SimplerEnv, DROID et LIBERO.

Chemin C : enregistrez les vôtres, délibérément

Trente à cinquante semble peu à côté de 76 000 jusqu'à ce que vous vous souveniez que les vôtres sont les seuls avec votre bras, vos caméras et votre table. Avec les paramètres par défaut de LeRobot, 50 épisodes représentent 100 minutes de temps réel. Voir , et .

Deux façons de passer des données publiques à une politique fonctionnelle

Ce que coûte chaque chemin

L'asymétrie est le point clé : le chemin qui emprunte le plus de données est le plus coûteux et le moins susceptible de faire bouger votre bras. Moins de deux heures de votre propre téléopération valent mieux qu'un téraoctet de données Franka de quelqu'un d'autre. Pas de bras encore ? /live diffuse un SO-100 physique sans inscription. Ensuite, entraînez votre première politique, et SmolVLA sur SO-100 pour le guide spécifique.