Données synthétiques pour les politiques de robotique : Là où la simulation aide

Tous les quelques mois, quelqu'un réalise qu'enregistrer cinquante épisodes à la main est lent, et demande si un simulateur pourrait les produire à la place. C'est une question légitime. La réponse honnête comporte trois parties : les données générées sont utiles, elles ne remplacent pas les enregistrements réels, et le rapport entre ces deux faits dépend entièrement du type de données synthétiques que vous entendez.

Cette page examine ce que les travaux publiés ont réellement mesuré, ce que vous pouvez exécuter aujourd'hui sur un bras à faible coût tel que le SO-100, et où l'écart entre la simulation et la réalité annule les gains. La version courte, avant les détails : les systèmes qui rapportent les plus grands multiplicateurs multiplient un petit ensemble de démonstrations humaines réelles. Ils n'éliminent pas le besoin de ces dernières.

Quatre choses différentes sont appelées données synthétiques

Avant de comparer les chiffres, il est utile de séparer les familles, car un article rapportant un multiplicateur de 100x et un article rapportant un gain de succès de 5 points décrivent souvent le même pipeline sous des angles différents. Le point commun est que quelque chose dans le jeu de données LeRobot a été produit par une machine plutôt qu'enregistré à partir d'un bras physique. Ce qui diffère, c'est la partie.

Seuls les trois premiers sont des données synthétiques au sens où l'entend cet article. Le quatrième mérite d'être mentionné car il est regroupé dans la même conversation et est de loin la chose la moins chère de la liste. Si vous n'avez pas encore activé les augmentations fournies avec votre entraîneur, faites-le avant d'installer un simulateur.

Ce que disent réellement les chiffres publiés

Voici la base de preuves, avec les chiffres tels que les sources les présentent plutôt que tels que les communiqués de presse les résument. Chaque ligne ci-dessous provient d'un article ou d'une page de projet lue le 23 août 2026.

Le schéma observé dans chaque ablation honnête est le même. Les données synthétiques étendent la couverture à moindre coût. Elles ne créent pas d'informations sur votre pince, le fléchissement de votre servomoteur, votre éclairage ou la hauteur de votre table qui n'étaient pas déjà présentes quelque part dans les démonstrations réelles. Si votre politique échoue parce que l'effecteur final se ferme une demi-seconde trop tard, aucune quantité de variation simulée ne peut y remédier. C'est un problème de synchronisation de la pince dans les enregistrements réels.

Une découverte de MimicGen mérite d'être prise en compte dans vos propres sessions d'enregistrement, car elle va à l'encontre des conseils habituels. Le projet a généré deux ensembles de données sur Square D2, l'un amorcé avec 10 démonstrations d'un opérateur humain de meilleure qualité et l'autre avec 10 démonstrations d'un opérateur de moins bonne qualité, tous deux tirés de l'ensemble de données robomimic multi-humain Square. Les politiques entraînées sur chacun ont obtenu des résultats comparables, ce que les auteurs interprètent comme un signe que dans le régime de données à grande échelle, la qualité des données pourrait ne pas être aussi importante. Lisez attentivement, c'est une déclaration concernant les dix démonstrations d'amorçage, et non vos cinquante épisodes réels. Cela signifie qu'un ensemble d'amorçage légèrement imparfait n'est pas ce qui vous sépare d'un ensemble de données généré utilisable. Cela ne signifie pas que les épisodes réels sur lesquels vous co-entraînez peuvent être imparfaits, car ce sont eux qui contiennent les informations que le simulateur n'a pas.

L'écart sim-réel, concrètement

L'écart est généralement discuté comme une quantité unique, ce qui est peu utile. Il s'agit d'au moins cinq déséquilibres distincts, et ils ont des tailles différentes sur un bras de loisir de 110 à 150 EUR que sur un Franka.

• Contact et frottement. Isaac Lab déclare clairement que, étant donné le même matériel et la même version d'Isaac Sim et de PhysX, la simulation est reproductible, mais que les résultats varient selon les différentes configurations matérielles en raison de la précision des nombres flottants et des erreurs d'arrondi, et que PhysX ne garantit pas le déterminisme pour toute scène avec des corps non rigides tels que des tissus ou des corps mous.
• Actionnement. Un servomoteur de bus Feetech STS3215 fonctionnant à 7,4 V s'affaisse sous charge, présente du jeu et modifie son comportement à mesure qu'il chauffe. Le modèle MJCF pour le SO-101 emprunte ses paramètres moteur à un projet sans rapport plutôt que de les identifier sur votre bras.
• Rendu. Le bruit de la caméra, l'obturateur roulant, l'auto-exposition et la teinte exacte de votre table ne sont pas inclus dans le rendu. C'est la moitié de l'écart que Cosmos-Transfer1 a été conçu pour combler : son flux de travail d'augmentation robotique mappe un exemple synthétique robotique à plusieurs exemples réalistes à partir de la segmentation, de la profondeur ou du conditionnement des bords.
• Synchronisation. Un simulateur avance à un rythme fixe. Une boucle de contrôle réelle ne le fait pas, et le modèle lui-même coûte de 20 à 485 ms par étape d'action selon celui que vous avez choisi. Voir latence d'inférence.
• Statistiques d'objets. Les scènes simulées sont échantillonnées à partir d'une distribution que quelqu'un a écrite. Votre table de cuisine ne l'est pas.

Ce qu'un SO-100 simulé sait réellement de votre bras

C'est la partie qui décide si tout ce qui précède vaut votre week-end, et la première surprise est que les SO-100 et SO-101 ne sont pas servis de manière égale. Le dépôt SO-ARM100 de TheRobotStudio conserve ses ressources de simulation sous Simulation/. Le dossier SO100 contient un seul fichier URDF et rien d'autre. Le dossier SO101 contient à la fois des fichiers URDF et MuJoCo : scene.xml, so101_new_calib.xml, so101_old_calib.xml, les URDF correspondants et un joints_properties.xml. Si vous voulez un modèle physique plutôt qu'une chaîne cinématique, vous voulez les fichiers SO-101.

Ils ont été générés avec le plugin onshape-to-robot à partir d'un modèle CAO conçu dans Onshape, ce qui signifie que la cinématique et les maillages visuels sont aussi bons que le modèle CAO. La dynamique est une autre histoire, et le README du dépôt est franc sur trois points. Les maillages de collision de base ont été supprimés en raison d'un comportement de collision problématique lors de la simulation et de la planification. Les propriétés du moteur STS3215 sont adaptées du projet Open Duck Mini plutôt que mesurées sur un SO-101. Et la convention de la pince LeRobot, où 0 est entièrement fermé et 100 est entièrement ouvert, n'est pas encore explicitement reflétée dans les fichiers URDF et MuJoCo. Chacun de ces points est un endroit où une politique entraînée purement dans ce modèle se comportera différemment sur votre bureau.

Randomisation de domaine, et ce qu'elle ne corrige pas

La réponse standard à cet écart est d'arrêter d'essayer de correspondre à la réalité et d'entraîner plutôt sur une distribution suffisamment large pour que la réalité y soit incluse. Tobin et ses collègues ont montré la version forte de ceci en 2017 : un détecteur d'objets entraîné uniquement sur des images simulées avec des textures aléatoires non réalistes, sans aucun pré-entraînement sur des images réelles, a localisé des objets réels avec une précision de 1.5 cm et est resté robuste aux distracteurs et aux occlusions partielles.

Isaac Lab expose la même idée que les termes d'événement que vous attachez à une configuration d'environnement. Ce sont les paramètres, par leurs noms de fonction réels dans isaaclab.envs.mdp, afin que vous puissiez les consulter plutôt que de deviner.

Voici la limite, et c'est celle sur laquelle les gens trébuchent. La randomisation élargit la distribution que la politique a vue à l'intérieur du modèle que vous avez construit. Elle ne peut pas introduire un effet physique que le simulateur ne représente pas. Si PhysX ne modélise pas le jeu et la dérive thermique de vos servomoteurs STS3215, randomiser leur rigidité n'apprend rien à la politique sur le jeu. C'est pourquoi un bras qui sous une politique entraînée en simulation n'est pas un problème de budget de randomisation. C'est un problème de modélisation.

Le chemin manuel : générer des données dans Isaac Lab

Isaac Gym est un logiciel hérité. La propre page de NVIDIA est intitulée "Isaac Gym - Maintenant obsolète" et indique que les développeurs peuvent le télécharger et continuer à l'utiliser, mais qu'il n'est plus pris en charge, renvoyant plutôt vers Isaac Lab. Si vous voulez l'historique, nous avons couvert les deux : et . Pour tout nouveau travail en 2026, commencez par Isaac Lab.

1. 1
   Installer Isaac Sim et Isaac Lab

   La page d'installation pip indique que les instructions sont pour Isaac Sim 5.X, qui nécessite Python 3.11. Le clonage de la source vous fournit les scripts nécessaires aux étapes suivantes.

   bash

   pip install "isaacsim[all,extscache]==5.1.0" \
       --extra-index-url https://pypi.nvidia.com
   
   git clone https://github.com/isaac-sim/IsaacLab.git --branch main
   cd IsaacLab
   sudo apt install cmake build-essential
   ./isaaclab.sh --install
   
   # smoke test
   ./isaaclab.sh -p scripts/tutorials/00_sim/create_empty.py

2. 2
   Enregistrer une dizaine de démonstrations humaines

   La documentation d'Isaac Lab est spécifique : environ 10 démonstrations réussies sont nécessaires pour que les étapes suivantes aboutissent. Ses conseils sont tout aussi spécifiques. Gardez les démonstrations courtes, prenez un chemin direct plutôt que de vous déplacer le long d'axes arbitraires, et ne faites pas de pause, car il n'est pas évident pour une politique de savoir pourquoi et quand faire une pause.

   bash

   ./isaaclab.sh -p scripts/tools/record_demos.py \
       --task Isaac-Stack-Cube-Franka-IK-Rel-v0 \
       --device cpu \
       --teleop_device spacemouse \
       --dataset_file ./datasets/dataset.hdf5 \
       --num_demos 10

3. 3
   Annoter les limites des sous-tâches

   Mimic divise les démonstrations d'entrée en sous-tâches afin de pouvoir redéfinir le timing et la cible des segments. L'option --auto effectue cette opération sans intervention humaine pour les tâches qui définissent l'annotation automatique ; sans elle, vous mettez en pause avec B, continuez avec N et marquez une limite avec S. Notez que l'ID de la tâche gagne un suffixe -Mimic.

   bash

   ./isaaclab.sh -p scripts/imitation_learning/isaaclab_mimic/annotate_demos.py \
       --device cpu \
       --task Isaac-Stack-Cube-Franka-IK-Rel-Mimic-v0 \
       --auto \
       --input_file ./datasets/dataset.hdf5 \
       --output_file ./datasets/annotated_dataset.hdf5

4. 4
   Générer l'ensemble de données multiplié

   C'est l'étape qui transforme 10 en 1000. Mimic applique un critère de succès booléen à chaque candidat et ne conserve que ceux qui ont terminé la tâche, de sorte que le nombre de sorties est inférieur au nombre d'essais. La documentation indique que le taux de succès des candidats peut atteindre 70 % dans les cas simples et être inférieur à 1 % pour les tâches difficiles et les robots complexes : environ 50 % pour l'empilement de cubes Franka, et 65 à 80 % pour le pick and place GR1T2, où 1000 démos prennent 18 à 40 minutes (19 minutes sur une RTX ADA 6000 à 80 %).

   bash

   ./isaaclab.sh -p scripts/imitation_learning/isaaclab_mimic/generate_dataset.py \
       --device cpu \
       --num_envs 10 \
       --generation_num_trials 1000 \
       --headless \
       --input_file ./datasets/annotated_dataset.hdf5 \
       --output_file ./datasets/generated_dataset.hdf5

5. 5
   Convertir HDF5 en un ensemble de données LeRobot

   Tout ce qui précède produit du HDF5 de type robomimic, et le cœur d'Isaac Lab ne fournit pas son propre convertisseur LeRobot : sa documentation indique seulement que vous pouvez convertir l'ensemble de données généré au format LeRobot. Deux projets fournissent le convertisseur réel. IsaacLab-Arena fournit un convertisseur ciblé GR00T entièrement piloté par une configuration YAML, et LeIsaac fournit sa propre paire pour la route SO-101 (voir ci-dessous).

   bash

   # IsaacLab-Arena, GR00T LeRobot format
   python isaaclab_arena_gr00t/lerobot/convert_hdf5_to_lerobot.py \
       --yaml_file isaaclab_arena_gr00t/lerobot/config/gr1_manip_config.yaml

Pourquoi les tentatives de génération échouent, et quoi changer

Un taux de réussite candidat qui oscille entre 70 % et moins de 1 % n'est pas un mystère, et Isaac Lab documente les pièges courants plutôt que de vous laisser deviner. Chacun d'eux est quelque chose que vous contrôlez au moment de l'enregistrement, c'est pourquoi il est judicieux de lire cette liste avant d'enregistrer les dix démonstrations initiales plutôt qu'après la première exécution de génération décevante.

• Les démonstrations sont trop longues. Un horizon temporel plus long est plus difficile à apprendre pour une politique. Commencez près du premier objet et minimisez les mouvements.
• Les démonstrations ne sont pas fluides. Un mouvement irrégulier est difficile à déchiffrer pour une politique, et un meilleur matériel de téléopération fournit de meilleures données : la documentation indique clairement qu'une SpaceMouse est supérieure à un clavier.
• Pauses. Les pauses sont difficiles à apprendre, car il n'est pas évident pour une politique de savoir pourquoi et quand faire une pause. Gardez le mouvement fluide.
• Trop de sous-tâches. Plus de sous-tâches signifient plus de raccordements entre les segments de trajectoire, ce qui entraîne un mouvement moins fluide et un taux de réussite de génération plus faible. Annotez les limites où le bras est peu susceptible d'entrer en collision avec quoi que ce soit.
• Pas de bruit d'action. Le bruit d'action rend les politiques résultantes plus robustes.
• Enregistrement trop court. Si l'enregistrement s'arrête sur la trame exacte où le terme de succès se déclenche, il pourrait ne pas se redéclencher lors de la relecture. Laissez une marge à la fin.
• Relecture non déterministe. La physique dans Isaac Lab n'est pas reproductible de manière déterministe après un `env.reset`, de sorte que certaines démonstrations humaines échouent lors de la relecture. Collectez plus que nécessaire et conservez celles qui survivent à l'annotation. Tout ce qui se trouve dans un fichier HDF5 généré par Mimic est une démonstration réussie et peut être utilisé pour l'entraînement même si la relecture échoue ultérieurement.

L'étape d'interpolation entre les segments de sous-tâches raccordés possède son propre réglage, et le nombre d'étapes d'interpolation dont vous avez besoin dépend de la vitesse de déplacement du robot et de l'étendue de la distribution de réinitialisation de l'objet. Une tâche complexe avec une large distribution de réinitialisation laisse des écarts plus importants entre les segments, ce qui nécessite plus d'étapes d'interpolation pour produire un mouvement continu. Si vos vidéos générées montrent le bras se déplaçant par à-coups entre les phases, c'est le paramètre à examiner avant de blâmer les démonstrations initiales.

Le même pipeline sur un SO-101, avec le bras leader réel

C'est le plus intéressant pour quiconque lit cette page, car c'est le seul pipeline ouvert qui intègre un dans Isaac Lab et vous permet de le piloter avec le bras leader physique que vous possédez déjà. LeIsaac, version 0.4.0 au moment de la rédaction, est le terrain de jeu de simulation officiel pour l'apprentissage par imitation intégré à l'EnvHub de LeRobot. Sa table de compatibilité liste trois combinaisons fonctionnelles ; la plus récente associe Isaac Sim 5.1 à Isaac Lab v2.3.0, CUDA 12.8, PyTorch 2.7.0 et Python 3.11, et la documentation recommande Isaac Sim 5.0 ou plus récent pour les cartes de la série 50.

git clone https://github.com/LightwheelAI/leisaac.git --recursive
conda create -n leisaac python=3.11 && conda activate leisaac
conda install -c "nvidia/label/cuda-12.8.1" cuda-toolkit
pip install -U torch==2.7.0 torchvision==0.22.0 \
  --index-url https://download.pytorch.org/whl/cu128
pip install "isaacsim[all,extscache]==5.1.0" --extra-index-url https://pypi.nvidia.com
sudo apt install cmake build-essential
cd leisaac/dependencies/IsaacLab && ./isaaclab.sh --install && cd ../..
pip install -e source/leisaac
pip install -e "source/leisaac[lerobot]"
pip install numpy==1.26.0

Une fois cela en place, le bras leader sur /dev/ttyACM0 pilote le suiveur simulé et enregistre directement au format HDF5. La boucle est la même que celle que vous connaissez déjà de l'enregistrement réel, seule la partie suiveuse est un corps rigide dans PhysX.

python scripts/environments/teleoperation/teleop_se3_agent.py \
    --task=LeIsaac-SO101-PickOrange-v0 \
    --teleop_device=so101leader \
    --port=/dev/ttyACM0 \
    --num_envs=1 \
    --device=cuda \
    --enable_cameras \
    --record \
    --dataset_file=./datasets/dataset.hdf5

La plupart de ces identifiants existent également en tant que variante -Direct-v0, et python scripts/environments/list_envs.py affiche la liste actuelle. Vous pouvez également ignorer entièrement le détour par HDF5 et écrire au format LeRobot pendant la téléopération en ajoutant trois drapeaux. Deux mises en garde proviennent de la documentation elle-même : l'enregistreur ignore automatiquement les 5 premières images de chaque épisode pour éviter l'instabilité due aux états initiaux, et cela peut entraîner de légers retards en téléopération, ce qui est exactement le genre de chose qui modifie subtilement le caractère de vos démonstrations. Il ne vide également que les épisodes que la tâche a marqués comme réussis.

python scripts/environments/teleoperation/teleop_se3_agent.py \
    --task=LeIsaac-SO101-PickOrange-v0 \
    --teleop_device=so101leader \
    --port=/dev/ttyACM0 \
    --num_envs=1 --device=cuda --enable_cameras --record \
    --use_lerobot_recorder \
    --lerobot_dataset_repo_id=<your-user>/<dataset-name> \
    --lerobot_dataset_fps=30

L'étape de multiplication s'exécute ensuite sur ces enregistrements. LeIsaac encapsule Isaac Lab Mimic en quatre commandes, car Mimic généralise les trajectoires à partir des poses de l'effecteur et de l'objet : convertir les actions de l'espace articulaire en actions basées sur l'IK, annoter, générer, puis reconvertir en espace articulaire.

python scripts/mimic/eef_action_process.py \
  --input_file ./datasets/mimic-lift-cube-example.hdf5 \
  --output_file ./datasets/processed_mimic-lift-cube-example.hdf5 \
  --to_ik --headless

python scripts/mimic/annotate_demos.py --device cuda \
  --task LeIsaac-SO101-LiftCube-Mimic-v0 \
  --input_file ./datasets/processed_mimic-lift-cube-example.hdf5 \
  --output_file ./datasets/annotated_mimic-lift-cube-example.hdf5 \
  --enable_cameras

python scripts/mimic/generate_dataset.py --device cuda \
  --num_envs 1 --generation_num_trials 10 \
  --input_file ./datasets/annotated_mimic-lift-cube-example.hdf5 \
  --output_file ./datasets/generated_mimic-lift-cube-example.hdf5 \
  --enable_cameras

python scripts/mimic/eef_action_process.py \
  --input_file ./datasets/generated_mimic-lift-cube-example.hdf5 \
  --output_file ./datasets/final_generated_mimic-lift-cube-example.hdf5 \
  --to_joint --headless

Ensuite, convertissez vers LeRobot. C'est l'étape où la règle de format de la plateforme entre en jeu, et LeIsaac fournit exactement les deux convertisseurs dont vous avez besoin : isaaclab2lerobot.py écrit LeRobot v2, ce que les chargeurs GR00T utilisent, et isaaclab2lerobotv3.py écrit la v3 pour Pi0.5, SmolVLA et ACT. Les deux scripts prennent des arguments identiques mais épinglent des versions différentes de lerobot, et seuls les épisodes réussis sont convertis.

pip install lerobot==0.3.3
pip install numpy==1.26.0

python scripts/convert/isaaclab2lerobot.py \
    --task_name=LeIsaac-SO101-PickOrange-v0 \
    --repo_id=<your-user>/so101_pick_orange_sim \
    --hdf5_root=./datasets \
    --hdf5_files=dataset.hdf5

Deux approches pour une politique entraînée

Modèles du monde vidéo : la couche la plus récente et la moins mesurée

L'idée derrière DreamGen est qu'un modèle génératif vidéo, adapté à l'incarnation du robot cible, peut imaginer des épisodes plausibles dans des scènes que vous n'avez jamais visitées. Le pipeline comporte quatre étapes : affiner le modèle du monde vidéo, générer des vidéos de robots synthétiques photoréalistes, récupérer des séquences de pseudo-actions avec un modèle d'action latente ou un modèle de dynamique inverse, puis entraîner la politique du robot sur le résultat. Le dépôt GR00T-dreams de NVIDIA implémente exactement cela.

Le résultat principal est réel et mérite d'être pris au sérieux : les données de téléopération provenant d'une seule tâche de prise et de dépose dans un seul environnement ont produit 22 nouveaux comportements sur un humanoïde, dans des environnements vus et non vus. La mise en garde est tout aussi réelle et se situe à la troisième étape.

Le co-entraînement est la recette qui montre réellement des gains

S'il y a une leçon opérationnelle à retenir de la littérature, c'est celle-ci. L'étude de co-entraînement sim-et-réel (Maddukuri et collègues, 2025) visait à trouver une recette simple pour utiliser les données de simulation afin de résoudre des tâches de manipulation robotique basées sur la vision, dans deux domaines, un bras robotique et un humanoïde, et sa conclusion est que l'on s'entraîne sur un mélange. Les données de simulation ont amélioré la performance des tâches du monde réel de 38 pour cent en moyenne, et l'article est explicite sur le fait que cela s'est maintenu même avec des différences notables entre les données de simulation et celles du monde réel.

Cette dernière clause est plus importante que les 38 pour cent. Cela signifie que la simulation n'a pas besoin d'être un jumeau numérique parfait pour être utile, à condition que les données réelles soient présentes dans le mélange pour l'ancrer. Le transfert uniquement par simulation est la voie coûteuse : le même article indique que l'entraînement d'une politique uniquement en simulation et son transfert vers le monde réel exigent souvent un effort humain substantiel pour combler l'écart de réalité. Le co-entraînement évite la majeure partie de cet effort en ne demandant jamais à la politique de combler l'écart par elle-même.

En pratique, sur cette plateforme, le co-entraînement signifie une chose : placez les deux ensembles d'épisodes dans le même LeRobot dataset avec des clés de caméra cohérentes, un ordre d'articulations cohérent et des unités cohérentes, puis exécutez un réglage fin. Il n'y a pas de bouton de poids de mélange dans le formulaire d'entraînement. Si vous voulez un rapport sim-à-réel de 3:1, vous l'exprimez par le nombre d'épisodes de chaque que vous mettez dans l'ensemble de données.

Le gain le moins cher de la simulation n'est pas les données d'entraînement

C'est l'évaluation. Exécuter des dizaines d'essais réels par tâche pour comparer deux représente une journée de temps de bras, et le bras dérive entre les essais. SIMPLER (Li et collègues, 2024) a construit des environnements simulés dont le but est d'évaluer des politiques réelles plutôt que de les entraîner, puis a mesuré la précision avec laquelle le classement de la simulation prédit le classement réel. Un seul environnement SIMPLER rend à 3 500 étapes de simulation par seconde sur une RTX 4090 grand public à une résolution de 640 par 512, ce qui, sous une fréquence de simulation de 500 Hz, représente une accélération de 7x par rapport à l'évaluation réelle.

Ce sont des moyennes sur trois groupes de tâches Google Robot pour six points de contrôle open-source courants : trois points de contrôle RT-1 à différentes étapes d'entraînement, RT-1-X, RT-2-X et Octo-Base. Le côté réel n'est pas un nombre d'essais uniforme, ce qu'il est bon de savoir avant de le citer : 75 essais pour ramasser une canette de Coca, 60 pour déplacer à proximité, 54 pour les tâches d'ouverture et de fermeture de tiroir et 27 pour la tâche plus longue de tiroir et de pomme. La comparaison avec le MSE de validation est la partie utile. La sélection de modèle par perte de validation classe mal ces points de contrôle, et un Pearson r de 0,924 sous correspondance visuelle signifie que si un point de contrôle obtient un meilleur score dans SIMPLER, il obtient très probablement un meilleur score sur le banc. C'est un tableau de bord reproductible du jour au lendemain, et cela ne vous oblige pas à croire quoi que ce soit sur le transfert d'entraînement de la simulation vers le réel.

Si vous souhaitez un contexte plus large sur ce que ces chiffres de benchmark vous disent et ne vous disent pas à propos d'un , nous l'avons détaillé séparément dans .

Où cette plateforme ne vous aide pas

Être clair sur les limites fait gagner du temps à tout le monde. AY-Robots est une plateforme d'enregistrement, d'entraînement et de service. Elle ne contient aucun simulateur.

• Pas d'Isaac Lab, pas de MimicGen, pas de modèle de monde, pas d'authoring de scène. Si vous voulez des données générées, vous les générez ailleurs et apportez le résultat.
• Les entraîneurs consomment des jeux de données LeRobot et rien d'autre. Un export de simulateur doit être converti avant de pouvoir être utilisé comme entrée, et il doit être de la bonne version : v2.0 ou v2.1 pour GR00T N1.5 et N1.7, v3.0 pour Pi0.5, SmolVLA et ACT.
• Le point d'entrée de fine-tuning de GR00T est une CLI tyro qui n'expose pas de seed, donc les exécutions de GR00T ne sont pas reproductibles bit-par-bit. Si vous effectuez une ablation minutieuse sim-versus-réel, c'est une réelle limitation. La seed par défaut de lerobot est 1000, et les formulaires ACT, SmolVLA et Pi0.5 exposent un champ de seed.
• L'accumulation de gradient n'est réellement appliquée que pour les deux entraîneurs GR00T. Pour Pi0.5 et SmolVLA, le champ existe dans le formulaire mais lerobot 0.5.1 n'a pas un tel flag, donc cela ne fait rien.
• L'inférence doit être située à proximité des servomoteurs pour les tâches rapides. La boucle de contrôle est de 20 à 485 ms par étape d'action selon le modèle, et l'ajout d'allers-retours sur l'internet public transforme une politique fonctionnelle en une politique hésitante. L'inférence à distance est viable pour le pick-and-place lent, pas pour le mouvement réactif rapide.

Un budget que vous pouvez défendre

Mettez les deux chemins côte à côte avec les chiffres que chacun publie réellement, et la décision se prend généralement d'elle-même pour un projet à tâche unique sur un bras à faible coût.

Pour une première politique sur un SO-100, enregistrez. Le et la vous mènent à un point de contrôle servi pour le prix d'un café, et vous aurez la moitié réelle de tout futur mélange de co-entraînement. Utilisez le simulateur lorsque vous avez une base de référence fonctionnelle et un échec de généralisation spécifique que vous pouvez nommer, comme une politique qui .

Une recette qui respecte les preuves

1. 1
   Enregistrez d'abord la base de référence réelle

   30 épisodes pour SmolVLA, 50 pour ACT, GR00T N1.7 et Pi0.5. Entraînez une seule fois. Tout ce que cette politique ne parvient pas à faire constitue votre spécification pour les données synthétiques.

2. 2
   Nommez l'échec de généralisation

   Pose de l'objet ? Éclairage ? Hauteur de la table ? Distracteurs ? Un libellé différent de l'instruction ? Les données synthétiques sont efficaces pour exactement un de ces éléments à la fois, et inutiles si vous ne pouvez pas dire lequel.

3. 3
   Choisissez la famille la moins chère qui le couvre

   Variation de pose et de disposition : multiplication de trajectoires. Éclairage et texture : augmentation d'image d'abord, modèle du monde ensuite. Scènes entièrement nouvelles : simulations physiques, et acceptez le coût de modélisation.

4. 4
   Générez, puis éliminez agressivement

   Les tentatives de génération échouent, et le taux de succès des candidats d'Isaac Lab varie de 70 % à moins de 1 % selon la tâche. Ne conservez que les trajectoires réussies et complétant la tâche, et examinez visuellement un échantillon sous forme de vidéo avant de faire confiance au lot.

   bash

   python scripts/mimic/generate_dataset.py --device cuda \
       --num_envs 8 --generation_num_trials 500 \
       --input_file ./datasets/annotated.hdf5 \
       --output_file ./datasets/generated.hdf5 --enable_cameras

5. 5
   Co-entraînez, ne remplacez pas

   Fusionnez les épisodes générés avec les épisodes réels dans un seul jeu de données LeRobot avec des clés de caméra et un ordre d'articulations identiques. Le chiffre de 38 % est un chiffre de co-entraînement.

6. 6
   Évaluez sur le bras réel, et seulement là

   L'évaluation simulée est un bon signal de classement (Pearson r 0.924 dans la configuration de correspondance visuelle de SIMPLER) mais ce n'est pas le test d'acceptation. Exécutez le point de contrôle sur le banc avant d'y croire.

Si vous préférez commencer par une liste de contrôle pour les enregistrements réels eux-mêmes, le guide de collecte de données couvre le placement de la caméra, le découpage d'actions les implications et les modes de défaillance qui rendent un jeu de données d'apprentissage par imitation inutilisable. Les détails sur le format lui-même se trouvent dans la documentation des jeux de données, et la partie hyperparamètres dans la documentation d'entraînement.