Syntetisk data för robotpolicyer: Där simulering hjälper

Några gånger om året kommer någon på att det är långsamt att spela in femtio episoder för hand, och frågar om en simulator istället skulle kunna producera dem. Det är en rimlig fråga. Det ärliga svaret har tre delar: genererad data hjälper, den ersätter inte de verkliga inspelningarna, och förhållandet mellan dessa två fakta beror helt på vilken typ av syntetisk data du menar.

Denna sida går igenom vad det publicerade arbetet faktiskt mätte, vad du kan köra idag på en lågkostnadsarm som SO-100, och var sim-till-verklighet-gapet äter upp vinsterna. Den korta versionen, innan detaljerna: systemen som rapporterar de största multiplikatorerna multiplicerar en liten uppsättning verkliga mänskliga demonstrationer. De tar inte bort behovet av dem.

Fyra olika saker kallas syntetisk data

Innan man jämför siffror är det värt att separera familjerna, eftersom en artikel som rapporterar en 100x multiplikator och en artikel som rapporterar en 5-punkts framgångsökning ofta beskriver samma pipeline från olika håll. Den gemensamma nämnaren är att något i LeRobot-datasetet producerades av en maskin snarare än spelades in från en fysisk arm. Vad som skiljer sig är vilken del.

Endast de tre första är syntetisk data i den mening denna artikel avser. Den fjärde är värd att nämna eftersom den klumpas ihop i samma konversation och är överlägset det billigaste på listan. Om du inte redan har aktiverat de augmentationer som din tränare levereras med, gör det innan du installerar en simulator.

Vad de publicerade siffrorna faktiskt säger

Här är evidensbasen, med siffrorna som källorna anger dem snarare än som pressmeddelandena sammanfattar dem. Varje rad nedan kommer från en artikel eller projektsida läst den 23 augusti 2026.

Mönstret över varje ärlig ablation är detsamma. Syntetisk data utökar täckningen billigt. Den skapar inte information om din gripklo, din servos nedböjning, din belysning eller din bordshöjd som inte fanns i de verkliga demonstrationerna någonstans. Om din policy misslyckas för att gripdonet stänger ett halvt sekund för sent, ingen mängd simulerad variation fixar det. Det är ett problem med gripdonets timing i de verkliga inspelningarna.

Ett fynd från MimicGen är värt att ta med sig till dina egna inspelningssessioner, eftersom det går emot de vanliga råden. Projektet genererade två dataset på Square D2, ett med 10 demonstrationer från en mänsklig operatör av bättre kvalitet och ett med 10 demonstrationer från en operatör av sämre kvalitet, båda hämtade från robomimic multi-human Square dataset. Policyer tränade på vardera uppnådde jämförbara resultat, vilket författarna tolkade som ett tecken på att datakvalitet i storskaliga dataregimer kanske inte spelar lika stor roll. Läs noga, det är ett uttalande om de tio startdemonstrationerna, inte om dina femtio verkliga episoder. Det betyder att en något rörig startuppsättning inte är det som står mellan dig och ett användbart genererat dataset. Det betyder inte att de verkliga episoder du samtränar på kan vara röriga, eftersom det är de som bär den information som simulatorn inte har.

Sim-till-verklighet-gapet, konkret

Gapet diskuteras vanligtvis som en enda kvantitet, vilket är till ingen hjälp. Det består av minst fem separata avvikelser, och de har olika storlekar på en hobbyarm för 110 till 150 EUR jämfört med en Franka.

• Kontakt och friktion. Isaac Lab anger tydligt att med samma hårdvara och samma version av Isaac Sim och PhysX är simuleringen reproducerbar, men att resultaten varierar mellan olika hårdvarukonfigurationer på grund av flyttalsprecision och avrundningsfel, och att PhysX inte garanterar determinism för scener med icke-rigida kroppar som tyg eller mjuka kroppar.
• Aktuering. Ett Feetech STS3215 busservo som körs vid 7.4 V sjunker under belastning, har glapp och ändrar beteende när det blir varmt. MJCF-modellen för SO-101 lånar sina motorparametrar från ett orelaterat projekt istället för att identifiera dem på din arm.
• Rendering. Kamerabrus, rullande slutare, automatisk exponering och den exakta nyansen på ditt bord finns inte med i renderingen. Detta är den halva av gapet som Cosmos-Transfer1 byggdes för att täppa till: dess arbetsflöde för robotikaugmentation mappar ett syntetiskt robotikexempel till flera realistiska exempel från segmentering, djup- eller kantkonditionering.
• Tidsaspekter. En simulator stegar med en fast hastighet. En verklig kontrollslinga gör det inte, och själva modellen kostar 20 till 485 ms per åtgärdssteg beroende på vilken du valde. Se inferenslatens.
• Objektstatistik. Simulerade scener samplas från en distribution som någon har skrivit ner. Ditt köksbord är det inte.

Vad en simulerad SO-100 faktiskt vet om din arm

Detta är den del som avgör om något av ovanstående är värt din helg, och den första överraskningen är att SO-100 och SO-101 inte är lika väl tillgodosedda. TheRobotStudios SO-ARM100-repository förvarar sina simuleringsresurser under Simulation/. SO100-mappen innehåller en enda URDF-fil och inget annat. SO101-mappen innehåller både URDF- och MuJoCo-filer: scene.xml, so101_new_calib.xml, so101_old_calib.xml, de matchande URDF-filerna och en joints_properties.xml. Om du vill ha en fysikmodell snarare än en kinematisk kedja, vill du ha SO-101-filerna.

De genererades med onshape-to-robot-pluginet från en CAD-modell designad i Onshape, vilket innebär att kinematiken och de visuella mesherna är lika bra som CAD-modellen. Dynamiken är en annan historia, och repositoryts egen README är uppriktig om tre saker. Kollisionsmesher för basen togs bort på grund av problematiskt kollisionsbeteende under simulering och planering. STS3215-motorns egenskaper är anpassade från Open Duck Mini-projektet snarare än mätta på en SO-101. Och LeRobot-griparens konvention, där 0 är helt stängd och 100 är helt öppen, återspeglas uttryckligen ännu inte i URDF- och MuJoCo-filerna. Var och en av dessa är en punkt där en policy tränad enbart i den modellen kommer att bete sig annorlunda på ditt skrivbord.

Domänrandomisering, och vad den inte åtgärdar

Standardsvaret på gapet är att sluta försöka matcha verkligheten och istället träna över en distribution som är tillräckligt bred för att verkligheten ska falla inom den. Tobin och kollegor visade den starka versionen av detta 2017: en objektdetektor tränad enbart på simulerade bilder med orealistiska slumpmässiga texturer, utan någon förträning på verkliga bilder alls, lokaliserade verkliga objekt med en noggrannhet på 1,5 cm och förblev robust mot distraktioner och partiella ocklusioner.

Isaac Lab exponerar samma idé som händelsetermer du kopplar till en miljökonfiguration. Dessa är rattarna, med deras faktiska funktionsnamn i isaaclab.envs.mdp, så du kan läsa dem istället för att gissa.

Här är gränsen, och det är den folk snubblar över. Randomisering breddar distributionen som policyn har sett inuti modellen du byggde. Den kan inte introducera en fysisk effekt som simulatorn inte representerar. Om PhysX inte modellerar glappet och den termiska nedgången hos dina STS3215-servon, lär randomisering av deras styvhet policyn ingenting om glapp. Det är därför en arm som under en sim-tränad policy inte är ett randomiseringsbudgetproblem. Det är ett modelleringsproblem.

Den manuella vägen: generera data i Isaac Lab

Isaac Gym är äldre programvara. NVIDIAs egen sida har rubriken "Isaac Gym - Nu föråldrad" och säger att utvecklare kan ladda ner och fortsätta använda den men att den inte längre stöds, och pekar istället på Isaac Lab. Om du vill ha historiken har vi täckt båda: och . För nytt arbete 2026, börja med Isaac Lab.

1. 1
   Installera Isaac Sim och Isaac Lab

   Pip-installationssidan anger att instruktionerna är för Isaac Sim 5.X, vilket kräver Python 3.11. Källklonen ger dig de skript som nästa steg behöver.

   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
   Spela in cirka tio mänskliga demonstrationer

   Isaac Labs dokumentation är specifik: cirka 10 framgångsrika demonstrationer krävs för att följande steg ska lyckas. Dess tips är lika specifika. Håll demonstrationerna korta, ta en direkt väg snarare än att röra dig längs godtyckliga axlar, och pausa inte, eftersom det inte är uppenbart för en policy varför och när man ska pausa.

   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
   Annotera deluppgiftsgränserna

   Mimic delar upp indatademonstrationerna i deluppgifter så att den kan om-tidsbestämma och om-målsätta segmenten. Flaggan --auto gör detta utan en människa i loopen för uppgifter som definierar automatisk annotering; utan den pausar du med B, fortsätter med N och markerar en gräns med S. Observera att uppgifts-ID:t får suffixet -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
   Generera den multiplicerade datamängden

   Detta är steget som förvandlar 10 till 1000. Mimic tillämpar ett booleskt framgångskriterium på varje kandidat och behåller endast de som slutförde uppgiften, så utdataantalet är lägre än antalet försök. Dokumentationen anger att kandidatens framgångsfrekvens är så hög som 70 procent i enkla fall och under 1 procent för svåra uppgifter och komplexa robotar: cirka 50 procent för Franka-kubstapeln, och 65 till 80 procent för GR1T2 pick and place, där 1000 demonstrationer tar 18 till 40 minuter (19 minuter på en RTX ADA 6000 vid 80 procent).

   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
   Konvertera HDF5 till en LeRobot-datamängd

   Allt ovan producerar robomimic-smaksatt HDF5, och Isaac Labs kärna levererar ingen egen LeRobot-konverterare: dess dokumentation säger bara att du kan konvertera den genererade datamängden till LeRobot-format. Två projekt tillhandahåller den faktiska konverteraren. IsaacLab-Arena levererar en GR00T-riktad som helt styrs av en YAML-konfiguration, och LeIsaac levererar sitt eget par för SO-101-vägen (se nedan).

   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

Varför genereringsförsök misslyckas, och vad man kan ändra

En kandidats framgångsfrekvens som svänger mellan 70 procent och under 1 procent är inget mysterium, och Isaac Lab dokumenterar de vanliga fallgroparna istället för att låta dig gissa. Var och en av dem är något du kontrollerar vid inspelningstillfället, vilket är anledningen till att det lönar sig att läsa denna lista innan du spelar in de tio startdemonstrationerna snarare än efter den första nedslående genereringskörningen.

• Demonstrationerna är för långa. En längre tidshorisont är svårare för en policy att lära sig. Börja nära det första objektet och minimera rörelsen.
• Demonstrationerna är inte jämna. Oregelbunden rörelse är svår för en policy att tyda, och bättre teleoperationshårdvara ger bättre data: dokumentationen säger tydligt att en SpaceMouse är bättre än ett tangentbord.
• Pauser. Pauser är svåra att lära sig, eftersom det inte är uppenbart för en policy varför och när den ska pausa. Håll rörelsen flytande.
• För många deluppgifter. Fler deluppgifter innebär mer sammansättning mellan trajektoriesegment, vilket ger mindre jämn rörelse och en lägre genereringsframgångsfrekvens. Annotera gränser där armen sannolikt inte kommer att kollidera med något.
• Inget aktionsbrus. Aktionsbrus gör de resulterande policyerna mer robusta.
• Inspelningen är för snävt beskuren. Om inspelningen stannar exakt på den bildruta då framgångsvillkoret utlöses, kanske det inte utlöses igen under uppspelning. Lämna en buffert i slutet.
• Icke-deterministisk uppspelning. Fysiken i Isaac Lab är inte deterministiskt reproducerbar över env.reset, så vissa mänskliga demonstrationer misslyckas vid uppspelning. Samla in fler än du behöver och behåll de som överlever annotering. Allt som hamnar i en Mimic-genererad HDF5-fil är en framgångsrik demo och kan användas för träning även om uppspelningen senare misslyckas.

Interpolationssteget mellan sammansatta deluppgiftssegment har sin egen justeringsratt, och antalet interpolationssteg du behöver skalas med hur snabbt roboten rör sig och hur bred objektets återställningsdistribution är. En komplex uppgift med en stor återställningsdistribution lämnar större luckor mellan segmenten, vilket kräver fler interpolationssteg för att framstå som kontinuerlig rörelse. Om dina genererade videor visar armen rycka mellan faserna, är det den parametern du ska titta på innan du skyller på startdemonstrationerna.

Samma pipeline på en SO-101, med den riktiga ledararmen

Detta är det intressanta för alla som läser den här sidan, eftersom det är den enda öppna pipelinen som placerar en inuti Isaac Lab och låter dig styra den med den fysiska ledararmen du redan äger. LeIsaac, version 0.4.0 vid tidpunkten för skrivandet, är den officiella simuleringsmiljön för imitationsinlärning integrerad i LeRobots EnvHub. Dess kompatibilitetstabell listar tre fungerande kombinationer; den nyaste kombinerar Isaac Sim 5.1 med Isaac Lab v2.3.0, CUDA 12.8, PyTorch 2.7.0 och Python 3.11, och dokumentationen rekommenderar Isaac Sim 5.0 eller nyare för 50-seriekort.

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 detta på plats driver ledararmen på /dev/ttyACM0 den simulerade följaren och spelar in direkt till HDF5. Loopen är densamma som du redan känner till från verklig inspelning, bara följaren är en styv kropp 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 flesta av dessa ID:n finns också som en -Direct-v0 variant, och python scripts/environments/list_envs.py skriver ut den aktuella listan. Du kan också helt hoppa över HDF5-omvägen och skriva LeRobot-format under teleoperation genom att lägga till tre flaggor. Två förbehåll kommer från dokumentationen själv: inspelaren hoppar automatiskt över de första 5 bildrutorna i varje episod för att undvika instabilitet från initiala tillstånd, och det kan orsaka små fördröjningar i teleoperationen, vilket är precis den typ av sak som tyst förändrar karaktären på dina demonstrationer. Den spolar också bara ut episoder som uppgiften markerat som framgångsrika.

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

Multiplikationssteget körs sedan på dessa inspelningar. LeIsaac omsluter Isaac Lab Mimic i fyra kommandon, eftersom Mimic generaliserar trajektorier från ändeffektor- och objektpositioner: konvertera ledrumsaktionerna till IK-baserade aktioner, annotera, generera, konvertera sedan tillbaka till ledrum.

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

Konvertera sedan till LeRobot. Detta är steget där plattformens formatregel slår till, och LeIsaac råkar leverera exakt de två konverterare du behöver: isaaclab2lerobot.py skriver LeRobot v2, vilket är vad GR00T-laddarna använder, och isaaclab2lerobotv3.py skriver v3 för Pi0.5, SmolVLA och ACT.

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

Två vägar till en tränad policy

Videovärldsmodeller: det nyaste lagret, och det minst mätta

Idén bakom DreamGen är att en videogenerativ modell, anpassad till den avsedda robotkroppen, kan föreställa sig plausibla episoder i scener du aldrig besökt. Pipeline har fyra steg: finjustera videovärldsmodellen, generera fotorealistiska syntetiska robotvideor, återställa pseudo-aktionssekvenser med en latent aktionsmodell eller en invers dynamikmodell, och sedan träna robotpolicyn på resultatet. NVIDIAs GR00T-dreams-repository implementerar exakt detta.

Huvudresultatet är verkligt och värt att ta på allvar: teleoperationsdata från endast en enda plock-och-placera-uppgift i en miljö producerade 22 nya beteenden på en humanoid, i både sedda och osedda miljöer. Förbehållet är lika verkligt och finns i det tredje steget.

Samträning är metoden som faktiskt visar vinster

Om du tar en operativ lärdom från litteraturen, ta den här. Sim-och-verklig samträningsstudien (Maddukuri och kollegor, 2025) syftade till att hitta ett enkelt recept för att använda simuleringsdata för att lösa synbaserade robotmanipulationsuppgifter, över två domäner, en robotarm och en humanoid, och dess slutsats är att du tränar på en blandning. Simuleringsdata förbättrade verklig uppgiftsprestanda med i genomsnitt 38 procent, och artikeln är tydlig med att detta gällde även med märkbara skillnader mellan simuleringen och verklighetsdata.

Den sista satsen är viktigare än de 38 procenten. Det betyder att simuleringen inte behöver vara en perfekt digital tvilling för att vara användbar, förutsatt att verklig data finns med i blandningen för att förankra den. Överföring enbart från simulering är den dyra vägen: samma artikel anger att träning av en policy enbart i simulering och överföring till den verkliga världen ofta kräver betydande mänsklig ansträngning för att överbrygga verklighetsgapet. Samträning hoppar över det mesta av den ansträngningen genom att aldrig be policyn att stänga gapet på egen hand.

Praktiskt sett, på denna plattform, betyder samträning en sak: lägg båda uppsättningarna av episoder i samma LeRobot dataset med konsekventa kameranycklar, konsekvent ledordning och konsekventa enheter, kör sedan en normal finjustering. Det finns ingen ratt för blandningsvikt i träningsformuläret. Om du vill ha ett 3:1 sim-till-verklighet-förhållande, uttrycker du det genom hur många episoder av varje du lägger i datamängden.

Den billigaste vinsten från simulering är inte träningsdata

Det är utvärdering. Att köra dussintals verkliga försök per uppgift för att jämföra två är en dags armtid, och armen driver mellan försök. SIMPLER (Li och kollegor, 2024) byggde simulerade miljöer vars syfte är att poängsätta verkliga policyer snarare än att träna dem, och mätte sedan hur väl simuleringsrankningen förutsäger den verkliga. En enda SIMPLER-miljö renderar med 3 500 simuleringssteg per sekund på ett konsument-RTX 4090 med 640 gånger 512 upplösning, vilket under en simuleringsfrekvens på 500 Hz är en 7x snabbare än verklig utvärdering.

Dessa är medelvärden över tre Google Robot-uppgiftsgrupper för sex vanliga öppen källkods-kontrollpunkter: tre RT-1-kontrollpunkter i olika träningsstadier, RT-1-X, RT-2-X och Octo-Base. Den verkliga sidan har inte ett enhetligt antal försök, vilket är värt att veta innan du citerar det: 75 försök för att plocka colaburk, 60 för att flytta nära, 54 för uppgifterna att öppna och stänga lådor och 27 för den längre låd- och äppeluppgiften. Jämförelsen mot validerings-MSE är den användbara delen. Modellval genom valideringsförlust rankar dessa kontrollpunkter dåligt, och ett Pearson r på 0.924 under visuell matchning betyder att om en kontrollpunkt får bättre poäng i SIMPLER så får den mycket troligt bättre poäng i verkligheten. Det är en repeterbar resultattavla över natten, och det kräver inte att du tror på något om sim-till-verklighet träningsöverföring.

Om du vill ha ett bredare sammanhang om vad dessa benchmarknummer berättar och inte berättar om en , har vi skrivit om det separat i .

Vad denna plattform inte hjälper dig med

Att vara tydlig med gränsen sparar allas tid. AY-Robots är en plattform för inspelning, träning och driftsättning. Den innehåller ingen simulator.

• Inget Isaac Lab, inget MimicGen, ingen världsmodell, ingen scenredigering. Om du vill ha genererad data genererar du den någon annanstans och tar med resultatet.
• Tränarna konsumerar LeRobot-dataset och inget annat. En simulator-export måste konverteras innan den kan användas som indata, och den måste ha rätt version: v2.0 eller v2.1 för GR00T N1.5 och N1.7, v3.0 för Pi0.5, SmolVLA och ACT.
• GR00T:s finjusteringsingång är en tyro CLI som inte exponerar något seed, så GR00T-körningar är inte bit-för-bit reproducerbara. Om du kör en noggrann sim-mot-verklighet-ablationsstudie är detta en verklig begränsning. lerobot:s eget standard-seed är 1000, och ACT-, SmolVLA- och Pi0.5-formerna exponerar ett seed-fält.
• Gradientackumulering tillämpas endast för de två GR00T-tränarna. För Pi0.5 och SmolVLA finns fältet i formuläret men lerobot 0.5.1 har ingen sådan flagga, så det gör ingenting.
• Inferens måste sitta nära servona för snabba uppgifter. Kontrollloopen är 20 till 485 ms per åtgärdssteg beroende på modell, och att lägga till rundresor över det publika internet förvandlar en fungerande policy till en tveksam. Fjärrinferens är genomförbart för långsam plock-och-placering, inte för snabb reaktiv rörelse.

En budget du kan försvara

Ställ de två vägarna sida vid sida med de siffror som var och en faktiskt publicerar, så fattar beslutet sig oftast självt för ett enskilt uppgiftsprojekt på en lågkostnadsarm.

För en första policy på en SO-100, spela in. Den och tar dig till en serverad checkpoint för priset av en kopp kaffe, och du kommer att ha den verkliga halvan av varje framtida samträningsblandning. Använd simulatorn när du har en fungerande baslinje och ett specifikt generaliseringsfel du kan namnge, till exempel en policy som .

Ett recept som respekterar bevisen

1. 1
   Spela in den verkliga baslinjen först

   30 episoder för SmolVLA, 50 för ACT, GR00T N1.7 och Pi0.5. Träna en gång. Vad policyn än misslyckas med är din specifikation för syntetisk data.

2. 2
   Namnge generaliseringsfelet

   Objektposition? Belysning? Bordshöjd? Distraktorer? En annorlunda formulering av instruktionen? Syntetisk data är bra på exakt en av dessa i taget, och värdelös om du inte kan säga vilken.

3. 3
   Välj den billigaste familjen som täcker det

   Variation i position och layout: trajektorimultiplikation. Belysning och textur: bildaugmentation först, världsmodell sedan. Helt nya scener: fysiksimuleringar, och acceptera modelleringskostnaden.

4. 4
   Generera, kasta sedan bort aggressivt

   Genereringsförsök misslyckas, och Isaac Labs egen kandidatsuccesfrekvens varierar från 70 procent ner till under 1 procent beroende på uppgiften. Behåll endast framgångsrika, uppgiftskompletterande trajektorier, och granska ett urval som video innan du litar 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
   Samträna, ersätt inte

   Slå samman de genererade episoderna med de verkliga till ett enda LeRobot-dataset med identiska kameranycklar och ledordning. Siffran 38 procent är en siffra för samträning.

6. 6
   Utvärdera på den verkliga armen, och endast där

   Simulerad utvärdering är en bra rankningssignal (Pearson r 0.924 i SIMPLERs visuella matchningsuppsättning) men det är inte acceptanstestet. Kör kontrollpunkten på testbänken innan du tror på den.

Om du hellre vill börja med en checklista för de verkliga inspelningarna själva, täcker kameraplacering, implikationer och de fellägen som gör ett dataset oanvändbart. Detaljer om formatet finns i , och hyperparametersidan i .