Syntetiske data for robotpolicyer: Hvor simulering hjelper

Med noen måneders mellomrom finner noen ut at det er sakte å spille inn femti episoder for hånd, og spør om en simulator kunne produsere dem i stedet. Det er et rimelig spørsmål. Det ærlige svaret har tre deler: genererte data hjelper, det erstatter ikke de virkelige opptakene, og forholdet mellom disse to faktaene avhenger helt av hvilken type syntetiske data du mener.

Denne siden går gjennom hva det publiserte arbeidet faktisk målte, hva du kan kjøre i dag på en rimelig arm som SO-100, og hvor sim-til-virkelighet-gapet spiser opp gevinstene. Kortversjonen, før detaljene: systemene som rapporterer de største multiplikatorene, multipliserer et lite sett med virkelige menneskelige demonstrasjoner. De fjerner ikke behovet for dem.

Fire forskjellige ting kalles syntetiske data

Før vi sammenligner tall, er det verdt å skille familiene, fordi en artikkel som rapporterer en 100x multiplikator og en artikkel som rapporterer en 5 poengs suksessøkning, ofte beskriver den samme pipelinen fra forskjellige ender. Den røde tråden er at noe i LeRobot datasett ble produsert av en maskin i stedet for å bli registrert fra en fysisk arm. Det som skiller seg er hvilken del.

Bare de tre første er syntetiske data i den betydningen denne artikkelen mener. Den fjerde er verdt å nevne fordi den blir samlet i den samme samtalen og er den desidert billigste tingen på listen. Hvis du ikke allerede har slått på augmenteringene treneren din leveres med, gjør det før du installerer en simulator.

Hva de publiserte tallene faktisk sier

Her er evidensgrunnlaget, med tallene slik kildene oppgir dem, snarere enn slik pressemeldingene oppsummerer dem. Hver rad nedenfor kommer fra en artikkel eller prosjektside lest 23. august 2026.

Mønsteret på tvers av hver ærlige ablasjon er det samme. Syntetiske data utvider dekningen billig. Det skaper ikke informasjon om griperen din, servoslakket ditt, belysningen din eller bordhøyden din som ikke allerede fantes i de virkelige demonstrasjonene et sted. Hvis din policy feiler fordi end-effektoren lukker et halvt sekund for sent, ingen mengde simulert variasjon fikser det. Det er et problem med gripertiming i de virkelige opptakene.

Et funn fra MimicGen er verdt å ta med seg inn i egne opptaksøkter, fordi det går imot de vanlige rådene. Prosjektet genererte to datasett på Square D2, ett sådd med 10 demoer fra en menneskelig operatør av bedre kvalitet og ett med 10 demoer fra en operatør av dårligere kvalitet, begge hentet fra robomimic multi-human Square-datasettet. Policyer trent på hver av dem oppnådde sammenlignbare resultater, noe forfatterne tolket som et tegn på at i et storskala dataregime kanskje datakvalitet ikke betyr like mye. Les nøye, dette er en uttalelse om de ti sådd-demonstrasjonene, ikke om dine femti virkelige episoder. Det betyr at et litt rufsete sådd-sett ikke er det som står mellom deg og et brukbart generert datasett. Det betyr ikke at de virkelige episodene du samtrener på kan være rufsete, for det er de som bærer informasjonen simulatoren ikke har.

Sim-til-virkelighet-gapet, konkret

Gapet diskuteres vanligvis som en enkelt størrelse, noe som er lite nyttig. Det er minst fem separate uoverensstemmelser, og de har forskjellige størrelser på en 110 til 150 EUR hobbyarm enn de har på en Franka.

• Kontakt og friksjon. Isaac Lab slår fast at gitt samme maskinvare og samme Isaac Sim- og PhysX-versjon er simuleringen reproduserbar, men at resultatene varierer på tvers av forskjellige maskinvarekonfigurasjoner på grunn av flyttallspresisjon og avrundingsfeil, og at PhysX ikke garanterer determinisme for scener med ikke-stive legemer som tøy eller myke legemer.
• Aktuering. En Feetech STS3215 busservo som kjører på 7.4 V synker under belastning, har slark, og endrer oppførsel når den varmes opp. MJCF-modellen for SO-101 låner motorparametrene sine fra et urelatert prosjekt i stedet for å identifisere dem på armen din.
• Rendering. Kamerastøy, rullende lukker, autoeksponering og den nøyaktige fargen på bordet ditt er ikke med i rendringen. Dette er halvparten av gapet som Cosmos-Transfer1 ble bygget for å tette: dens arbeidsflyt for robotikkaugmentering kartlegger ett robotisk syntetisk eksempel til flere realistiske eksempler fra segmentering, dybde eller kantkondisjonering.
• Tidsstyring. En simulator utfører trinn med en fast hastighet. En ekte kontrollsløyfe gjør det ikke, og selve modellen koster 20 til 485 ms per handlingstrinn avhengig av hvilken du valgte. Se inference latency.
• Objektstatistikk. Simulerte scener er samplet fra en distribusjon noen har skrevet ned. Kjøkkenbordet ditt er ikke det.

Hva en simulert SO-100 faktisk vet om armen din

Dette er delen som avgjør om noe av det ovennevnte er verdt helgen din, og den første overraskelsen er at SO-100 og SO-101 ikke er like godt ivaretatt. TheRobotStudios SO-ARM100-arkiv holder sine simuleringsressurser under Simulation/. SO100-mappen inneholder en enkelt URDF-fil og ingenting annet. SO101-mappen inneholder både URDF- og MuJoCo-filer: scene.xml, so101_new_calib.xml, so101_old_calib.xml, de matchende URDF-ene og en joints_properties.xml. Hvis du vil ha en fysikkmodell i stedet for en kinematisk kjede, vil du ha SO-101-filene.

De ble generert med onshape-to-robot-plugin-en fra en CAD-modell designet i Onshape, noe som betyr at kinematikken og de visuelle meshene er like gode som CAD-modellen. Dynamikken er en annen historie, og depotets egen README er ærlig om tre ting. Kollisjonsnett for basen ble fjernet på grunn av problematisk kollisjonsatferd under simulering og planlegging. STS3215-motoregenskapene er tilpasset fra Open Duck Mini-prosjektet i stedet for målt på en SO-101. Og LeRobot-griperkonvensjonen, der 0 er helt lukket og 100 er helt åpen, er eksplisitt ennå ikke reflektert i URDF- og MuJoCo-filene. Hver av disse er et sted hvor en policy trent rent i den modellen vil oppføre seg annerledes på skrivebordet ditt.

Domenerandomisering, og hva den ikke fikser

Standardløsningen på gapet er å slutte å prøve å matche virkeligheten og i stedet trene på tvers av en distribusjon som er bred nok til at virkeligheten faller innenfor den. Tobin og kolleger viste den sterke versjonen av dette i 2017: en objektdetektor trent kun på simulerte bilder med urealistiske tilfeldige teksturer, uten noen forhåndstrening på virkelige bilder i det hele tatt, lokaliserte virkelige objekter med en nøyaktighet på 1.5 cm og forble robust mot distraksjoner og delvise okklusjoner.

Isaac Lab eksponerer den samme ideen som hendelsesvilkår du knytter til en miljøkonfigurasjon. Dette er justeringspunktene, med deres faktiske funksjonsnavn i isaaclab.envs.mdp, slik at du kan lese dem i stedet for å gjette.

Her er grensen, og det er den folk snubler over. Randomisering utvider distribusjonen som policyen har sett inne i modellen du bygde. Den kan ikke introdusere en fysisk effekt som simulatoren ikke representerer. Hvis PhysX ikke modellerer tilbakeslag og termisk nedgang i dine STS3215-servoer, lærer randomisering av deres stivhet policyen ingenting om tilbakeslag. Det er derfor en arm som under en sim-trent policy ikke er et randomiseringsbudsjettproblem. Det er et modelleringsproblem.

Den manuelle veien: generering av data i Isaac Lab

Isaac Gym er utdatert programvare. NVIDIAs egen side har overskriften "Isaac Gym - Nå utdatert" og sier at utviklere kan laste ned og fortsette å bruke den, men at den ikke lenger støttes, og peker i stedet på Isaac Lab. Hvis du vil ha historien, har vi dekket begge: og . For nytt arbeid i 2026, start med Isaac Lab.

1. 1
   Installer Isaac Sim og Isaac Lab

   Pip-installasjonssiden oppgir at instruksjonene er for Isaac Sim 5.X, som krever Python 3.11. Kildeklonen gir deg skriptene de neste trinnene trenger.

   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
   Ta opp omtrent ti menneskelige demonstrasjoner

   Isaac Lab-dokumentasjonen er spesifikk: omtrent 10 vellykkede demonstrasjoner er nødvendig for at de følgende trinnene skal lykkes. Tipsene er like spesifikke. Hold demonstrasjonene korte, ta en direkte vei i stedet for å bevege deg langs vilkårlige akser, og ikke pause, fordi det ikke er åpenbart for en policy hvorfor og når den skal 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 deloppgavegrensene

   Mimic deler inndata-demonstrasjonene inn i deloppgaver slik at den kan re-tidsbestemme og re-målrette segmentene. --auto-flagget gjør dette uten et menneske i loopen for oppgaver som definerer automatisk annotering; uten det pauser du med B, fortsetter med N og markerer en grense med S. Merk at oppgave-ID-en får et -Mimic-suffiks.

   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
   Generer det multipliserte datasettet

   Dette er trinnet som gjør 10 til 1000. Mimic anvender et boolsk suksesskriterium på hver kandidat og beholder kun de som fullførte oppgaven, så uttellingen er lavere enn antall forsøk. Dokumentasjonen angir at kandidatsuksessraten er så høy som 70 prosent i enkle tilfeller og under 1 prosent for vanskelige oppgaver og komplekse roboter: omtrent 50 prosent for Franka-kube-stabelen, og 65 til 80 prosent for GR1T2 pick and place, hvor 1000 demoer tar 18 til 40 minutter (19 minutter på en RTX ADA 6000 med 80 prosent).

   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
   Konverter HDF5 til et LeRobot-datasett

   Alt ovenfor produserer robomimic-smaksatt HDF5, og Isaac Lab-kjernen leverer ingen egen LeRobot-konverterer: dokumentasjonen sier bare at du kan konvertere det genererte datasettet til LeRobot-format. To prosjekter leverer den faktiske konvertereren. IsaacLab-Arena leverer en GR00T-målrettet en som er fullstendig drevet av en YAML-konfigurasjon, og LeIsaac leverer sitt eget par for SO-101-ruten (se nedenfor).

   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

Hvorfor genereringsforsøk mislykkes, og hva du kan endre

En kandidats suksessrate som svinger mellom 70 prosent og under 1 prosent er ikke et mysterium, og Isaac Lab dokumenterer de vanlige fallgruvene i stedet for å la deg gjette. Hver eneste av dem er noe du kontrollerer under opptak, og derfor lønner det seg å lese denne listen før du tar opp de ti frødemonstrasjonene, snarere enn etter den første skuffende genereringskjøringen.

• Demonstrasjoner er for lange. En lengre tidshorisont er vanskeligere for en policy å lære. Start nær det første objektet og minimer bevegelse.
• Demonstrasjoner er ikke jevne. Uregelmessig bevegelse er vanskelig for en policy å tyde, og bedre teleoperasjonsmaskinvare gir bedre data: dokumentasjonen sier tydelig at en SpaceMouse slår et tastatur.
• Pauser. Pauser er vanskelige å lære, fordi det ikke er åpenbart for en policy hvorfor og når den skal pause. Hold bevegelsen flytende.
• For mange deloppgaver. Flere deloppgaver betyr mer sammenføyning mellom trajektoriesegmenter, noe som gir mindre jevn bevegelse og en lavere genereringssuksessrate. Annoter grenser der armen er usannsynlig å kollidere med noe.
• Ingen handlingsstøy. Handlingsstøy gjør de resulterende policyene mer robuste.
• Opptaket er kuttet for stramt. Hvis opptaket stopper på nøyaktig den rammen suksesskriteriet utløses, kan det hende det ikke utløses på nytt under avspilling. La det være en buffer på slutten.
• Ikke-deterministisk avspilling. Fysikk i Isaac Lab er ikke deterministisk reproduserbar på tvers av env.reset, så noen menneskelige demoer mislykkes ved avspilling. Samle inn mer enn du trenger og behold de som overlever annotering. Alt som havner i en Mimic-generert HDF5-fil er en vellykket demo og kan brukes til trening selv om avspilling senere mislykkes.

Interpolasjonstrinnet mellom sammenføyde deloppgavesegmenter har sin egen justeringsknapp, og antallet interpolasjonstrinn du trenger, skalerer med hvor raskt roboten beveger seg og hvor bred objektets tilbakestillingsdistribusjon er. En kompleks oppgave med en stor tilbakestillingsdistribusjon etterlater større hull mellom segmentene, noe som krever flere interpolasjonstrinn for å fremstå som kontinuerlig bevegelse. Hvis dine genererte videoer viser armen som rykker mellom fasene, er det den parameteren du bør se på før du skylder på frødemoene.

Den samme pipelinen på en SO-101, med den virkelige lederarmen

Dette er den interessante for alle som leser denne siden, fordi det er den eneste åpne pipelinen som plasserer en inne i Isaac Lab og lar deg styre den med den fysiske lederarmen du allerede eier. LeIsaac, versjon 0.4.0 på skrivende tidspunkt, er den offisielle simuleringsplattformen for imitasjonslæring integrert i LeRobots EnvHub. Kompatibilitetstabellen lister opp tre fungerende kombinasjoner; den nyeste kombinerer Isaac Sim 5.1 med Isaac Lab v2.3.0, CUDA 12.8, PyTorch 2.7.0 og Python 3.11, og dokumentasjonen anbefaler Isaac Sim 5.0 eller nyere for 50-serie kort.

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

Med dette på plass driver lederarmen på /dev/ttyACM0 den simulerte følgeren og tar opp direkte til HDF5. Den -sløyfen er den samme som du allerede kjenner fra ekte opptak, bare følgeren er et stivt legeme i 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

De fleste av disse ID-ene finnes også som en -Direct-v0 variant, og python scripts/environments/list_envs.py skriver ut den nåværende listen. Du kan også hoppe over HDF5-omveien helt og skrive LeRobot-format under teleoperasjon ved å legge til tre flagg. To forbehold kommer fra dokumentasjonen selv: opptakeren hopper automatisk over de første 5 rammene av hver episode for å unngå ustabilitet fra starttilstander, og det kan forårsake små forsinkelser i teleoperasjonen, noe som er akkurat den typen ting som stille endrer karakteren av demonstrasjonene dine. Den tømmer også kun episoder som oppgaven markerte som vellykkede.

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

Multiplikasjonstrinnet kjører deretter på disse opptakene. LeIsaac pakker Isaac Lab Mimic inn i fire kommandoer, fordi Mimic generaliserer trajektorier fra end-effektor- og objektposisjoner: konverter leddrom-handlingene til IK-baserte handlinger, annoter, generer, og konverter deretter tilbake til leddrom.

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

Konverter deretter til LeRobot. Dette er trinnet der plattformens formatregel slår inn, og LeIsaac leverer tilfeldigvis nøyaktig de to konvertererne du trenger: isaaclab2lerobot.py skriver LeRobot v2, som er det GR00T-lasterne bruker, og isaaclab2lerobotv3.py skriver v3 for Pi0.5, SmolVLA og ACT. De to skriptene tar identiske argumenter, men bruker forskjellige lerobot-versjoner, og kun vellykkede episoder konverteres.

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

To veier til en trent policy

Video-verdensmodeller: det nyeste laget, og det minst målte

Ideen bak DreamGen er at en video-generativ modell, tilpasset målet for robotens utførelse, kan forestille seg plausible episoder i scener du aldri har besøkt. Pipeline-en har fire stadier: finjuster video-verdensmodellen, generer fotorealistiske syntetiske robotvideoer, gjenopprett pseudo-handlingssekvenser med en latent handlingsmodell eller en invers dynamikkmodell, og tren deretter robotpolicyen på resultatet. NVIDIAs GR00T-dreams-repository implementerer nøyaktig dette.

Hovedresultatet er reelt og verdt å ta på alvor: teleoperasjonsdata fra kun én plukk-og-plasser-oppgave i ett miljø produserte 22 nye atferder på en humanoid, i både sett og usett miljø. Forbeholdet er like reelt og ligger i den tredje fasen.

Samtrening er oppskriften som faktisk viser gevinster

Hvis du tar én operasjonell lærdom fra litteraturen, ta denne. Sim-og-virkelighets-samtreningstudien (Maddukuri og kolleger, 2025) hadde som mål å finne en enkel oppskrift for å bruke simuleringsdata til å løse synsbaserte robotmanipulasjonsoppgaver, på tvers av to domener, en robotarm og en humanoid, og konklusjonen er at du trener på en blanding. Simuleringsdata forbedret ytelsen til virkelige oppgaver med et gjennomsnitt på 38 prosent, og artikkelen er eksplisitt på at dette gjaldt selv med merkbare forskjeller mellom simulerings- og virkelighetsdataene.

Den siste setningen betyr mer enn de 38 prosentene. Det betyr at simuleringen ikke trenger å være en perfekt digital tvilling for å være nyttig, forutsatt at de virkelige dataene er med i blandingen for å forankre den. Overføring kun fra simulering er den kostbare veien: den samme artikkelen slår fast at trening av en policy utelukkende i simulering og overføring til den virkelige verden ofte krever betydelig menneskelig innsats for å tette virkelighetsgapet. Samtrening hopper over det meste av denne innsatsen ved aldri å be policyen om å tette gapet på egen hånd.

Praktisk talt, på denne plattformen, betyr samtrening én ting: legg begge settene med episoder i det samme LeRobot-datasettet med konsistente kameranøkler, konsistent leddrekkefølge og konsistente enheter, og kjør deretter en normal finjustering. Det er ingen blandingsvekt-knapp i treningsskjemaet. Hvis du ønsker et 3:1 sim-til-virkelighets-forhold, uttrykker du det ved hvor mange episoder av hver du legger i datasettet.

Den billigste gevinsten fra simulering er ikke treningsdata

Det er evaluering. Å kjøre dusinvis av virkelige forsøk per oppgave for å sammenligne to er en dag med armtid, og armen driver mellom forsøkene. SIMPLER (Li og kolleger, 2024) bygde simulerte miljøer hvis formål er å score virkelige policyer i stedet for å trene dem, og målte deretter hvor godt simuleringsrangeringen forutsier den virkelige. Et enkelt SIMPLER-miljø gjengis med 3 500 simuleringstrinn per sekund på et forbruker-RTX 4090 med 640 x 512 oppløsning, noe som under en 500 Hz simuleringsfrekvens er en 7x hastighetsøkning sammenlignet med reell evaluering.

Dette er gjennomsnitt over tre Google Robot-oppgavegrupper for seks vanlige åpen kildekode-sjekkpunkter: tre RT-1-sjekkpunkter på forskjellige treningsstadier, RT-1-X, RT-2-X og Octo-Base. Den virkelige siden har ikke et ensartet antall forsøk, noe som er verdt å vite før du siterer det: 75 forsøk for å plukke colaboks, 60 for å flytte nær, 54 for oppgavene med å åpne og lukke skuffen og 27 for den lengre skuff-og-eple-oppgaven. Sammenligningen mot validerings-MSE er den nyttige delen. Modellvalg basert på valideringstap rangerer disse sjekkpunktene dårlig, og en Pearson r på 0.924 under visuell matching betyr at hvis et sjekkpunkt scorer bedre i SIMPLER, scorer det svært sannsynlig bedre på benken. Det er en repeterbar resultattavle over natten, og det krever ikke at du tror noe om sim-til-virkelig-treningsoverføring.

Hvis du ønsker den bredere konteksten om hva disse benchmark-tallene forteller og ikke forteller deg om en , skrev vi det opp separat i .

Hvor denne plattformen ikke hjelper deg

Å være tydelig om grensene sparer alle tid. AY-Robots er en plattform for opptak, trening og serving. Den inneholder ingen simulator.

• Ingen Isaac Lab, ingen MimicGen, ingen verdensmodell, ingen scene-redigering. Hvis du vil ha genererte data, genererer du dem et annet sted og tar med resultatet.
• Trenerne bruker LeRobot datasett og ingenting annet. En simulator-eksport må konverteres før den kan brukes som input, og den må være riktig versjon: v2.0 eller v2.1 for GR00T N1.5 og N1.7, v3.0 for Pi0.5, SmolVLA og ACT.
• GR00Ts finjusterings-inngangspunkt er en tyro CLI som ikke eksponerer noe seed, så GR00T-kjøringer er ikke bit-for-bit reproduserbare. Hvis du kjører en nøye sim-versus-real ablasjon, er dette en reell begrensning. lerobots eget standard seed er 1000, og ACT-, SmolVLA- og Pi0.5-formene eksponerer et seed-felt.
• Gradientakkumulering brukes faktisk bare for de to GR00T-trenerne. For Pi0.5 og SmolVLA eksisterer feltet i skjemaet, men lerobot 0.5.1 har ingen slik flagg, så det gjør ingenting.
• Inferens må sitte ved siden av servoene for raske oppgaver. Kontrollsløyfen er 20 til 485 ms per handlingstrinn avhengig av modellen, og å legge til offentlige internett-rundturer gjør en fungerende policy om til en nølende en. Fjerninferens er levedyktig for langsom pick-and-place, ikke for rask reaktiv bevegelse.

Et budsjett du kan forsvare

Sett de to veiene side om side med tallene hver enkelt faktisk publiserer, og beslutningen tar vanligvis seg selv for et enkelt-oppgaveprosjekt på en rimelig arm.

For en første policy på en SO-100, ta opp. Den og får deg til et servert sjekkpunkt for prisen av en kaffe, og du vil ha den virkelige halvdelen av enhver fremtidig samtreningsblanding. Gå for simulatoren når du har en fungerende grunnlinje og en spesifikk generaliseringsfeil du kan navngi, for eksempel en policy som .

En oppskrift som respekterer bevisene

1. 1
   Registrer den virkelige grunnlinjen først

   30 episoder for SmolVLA, 50 for ACT, GR00T N1.7 og Pi0.5. Tren én gang. Det politikken feiler på er din spesifikasjon for de syntetiske dataene.

2. 2
   Navngi generaliseringsfeilen

   Objektposisjon? Belysning? Bordhøyde? Forstyrrende elementer? En annen formulering av instruksjonen? Syntetiske data er gode på nøyaktig én av disse om gangen, og ubrukelige hvis du ikke kan si hvilken.

3. 3
   Velg den billigste familien som dekker det

   Posisjons- og layoutvariasjon: trajektoriemultiplikasjon. Belysning og tekstur: bildeaugmentering først, verdensmodell deretter. Helt nye scener: fysikk-rollouts, og aksepter modelleringskostnaden.

4. 4
   Generer, og kast deretter aggressivt

   Genereringsforsøk mislykkes, og Isaac Labs egen kandidatsuksessrate varierer fra 70 prosent ned til under 1 prosent avhengig av oppgaven. Behold kun vellykkede, oppgavefullførende trajektorier, og se på et utvalg som video før du stoler på batchen.

   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
   Samtren, ikke erstatt

   Slå sammen de genererte episodene med de virkelige til et enkelt LeRobot-datasett med identiske kameranøkler og leddrekkefølge. Tallet 38 prosent er et samtreningstall.

6. 6
   Evaluer på den virkelige armen, og bare der

   Simulert evaluering er et godt rangeringssignal (Pearson r 0.924 i SIMPLERs visuelle matchoppsett), men det er ikke akseptansetesten. Kjør sjekkpunktet på testbenken før du tror på det.

Hvis du heller vil starte med en sjekkliste for selve de virkelige opptakene, dekker kameraplassering, implikasjoner og feilmoduser som gjør et datasett ubrukelig. Detaljer om selve formatet finnes i , og hyperparameter-siden i .