Dati Sintetici per le Politiche dei Robot: Dove la Simulazione Aiuta

Ogni pochi mesi qualcuno si rende conto che registrare cinquanta episodi a mano è lento, e chiede se un simulatore potrebbe produrli invece. È una domanda legittima. La risposta onesta ha tre parti: i dati generati aiutano, non sostituiscono le registrazioni reali, e il rapporto tra questi due fatti dipende interamente dal tipo di dati sintetici a cui ci si riferisce.

Questa pagina esamina ciò che il lavoro pubblicato ha effettivamente misurato, cosa si può eseguire oggi su un braccio a basso costo come il SO-100, e dove il divario sim-to-real annulla i guadagni. La versione breve, prima dei dettagli: i sistemi che riportano i maggiori moltiplicatori moltiplicano un piccolo insieme di dimostrazioni umane reali. Non eliminano la necessità di queste ultime.

Quattro diverse cose vengono chiamate dati sintetici

Prima di confrontare i numeri, vale la pena separare le famiglie, perché un articolo che riporta un moltiplicatore 100x e un articolo che riporta un guadagno di successo di 5 punti spesso descrivono la stessa pipeline da prospettive diverse. Il filo conduttore è che qualcosa nel LeRobot dataset è stato prodotto da una macchina piuttosto che registrato da un braccio fisico. Ciò che differisce è quale parte.

Solo i primi tre sono dati sintetici nel senso inteso da questo articolo. Il quarto merita di essere menzionato perché viene raggruppato nella stessa conversazione ed è di gran lunga la cosa più economica della lista. Se non hai già attivato le aumentazioni fornite con il tuo trainer, fallo prima di installare un simulatore.

Cosa dicono realmente i numeri pubblicati

Ecco la base di prove, con i numeri così come dichiarati dalle fonti piuttosto che come riassunti dai comunicati stampa. Ogni riga seguente proviene da un articolo o una pagina di progetto letta il 23 agosto 2026.

Il modello in ogni ablazione onesta è lo stesso. I dati sintetici ampliano la copertura a basso costo. Non crea informazioni sulla tua pinza, sull'abbassamento del tuo servo, sulla tua illuminazione o sull'altezza del tuo tavolo che non fossero già presenti nelle dimostrazioni reali da qualche parte. Se la tua policy fallisce perché l'effettore finale si chiude con mezzo secondo di ritardo, nessuna quantità di variazione simulata può risolverlo. Questo è un problema di temporizzazione della pinza nelle registrazioni reali.

Un risultato di MimicGen merita di essere considerato nelle tue sessioni di registrazione, perché va contro i consigli abituali. Il progetto ha generato due dataset su Square D2, uno inizializzato con 10 demo da un operatore umano di migliore qualità e uno con 10 demo da un operatore di peggiore qualità, entrambi tratti dal dataset robomimic multi-umano Square. Le policy addestrate su ciascuno hanno ottenuto risultati comparabili, che gli autori interpretano come un segno che nel regime di dati su larga scala la qualità dei dati potrebbe non essere così importante. Leggi attentamente, questa è un'affermazione sulle dieci dimostrazioni iniziali, non sui tuoi cinquanta episodi reali. Significa che un set di seed leggermente disordinato non è ciò che si frappone tra te e un dataset generato utilizzabile. Non significa che gli episodi reali su cui co-addestri possano essere disordinati, perché sono quelli che contengono le informazioni che il simulatore non ha.

Il divario sim-to-real, concretamente

Il divario è solitamente discusso come una singola quantità, il che è inutile. Si tratta di almeno cinque disallineamenti separati, e hanno dimensioni diverse su un braccio hobby da 110 a 150 EUR rispetto a quelle su un Franka.

• Contatto e attrito. Isaac Lab afferma chiaramente che, dato lo stesso hardware e la stessa versione di Isaac Sim e PhysX, la simulazione è riproducibile, ma che i risultati variano tra diverse configurazioni hardware a causa della precisione in virgola mobile e degli errori di arrotondamento, e che PhysX non garantisce il determinismo per alcuna scena con corpi non rigidi come tessuti o corpi morbidi.
• Attuazione. Un servo bus Feetech STS3215 che funziona a 7.4 V cede sotto carico, presenta gioco e cambia comportamento man mano che si riscalda. Il modello MJCF per il SO-101 prende in prestito i suoi parametri motore da un progetto non correlato piuttosto che identificarli sul tuo braccio.
• Rendering. Il rumore della fotocamera, il rolling shutter, l'auto-esposizione e l'esatta tonalità del tuo tavolo non sono presenti nel rendering. Questa è la metà del divario che Cosmos-Transfer1 è stato costruito per colmare: il suo flusso di lavoro di aumento robotico mappa un esempio sintetico robotico a più esempi realistici da segmentazione, profondità o condizionamento dei bordi.
• Tempistica. Un simulatore procede a una velocità fissa. Un ciclo di controllo reale no, e il modello stesso costa da 20 a 485 ms per passo d'azione a seconda di quello che hai scelto. Vedi latenza di inferenza.
• Statistiche degli oggetti. Le scene simulate sono campionate da una distribuzione che qualcuno ha scritto. Il tuo tavolo da cucina no.

Cosa sa effettivamente un SO-100 simulato del tuo braccio

Questa è la parte che decide se quanto sopra vale il tuo fine settimana, e la prima sorpresa è che il SO-100 e il SO-101 non sono serviti allo stesso modo. Il repository SO-ARM100 di TheRobotStudio mantiene i suoi asset di simulazione sotto Simulation/. La cartella SO100 contiene un singolo file URDF e nient'altro. La cartella SO101 contiene sia file URDF che MuJoCo: scene.xml, so101_new_calib.xml, so101_old_calib.xml, i corrispondenti URDF e un joints_properties.xml. Se desideri un modello fisico piuttosto che una catena cinematica, desideri i file SO-101.

Sono stati generati con il plugin onshape-to-robot da un modello CAD progettato in Onshape, il che significa che la cinematica e le mesh visive sono fedeli al CAD. La dinamica è un'altra storia, e il README del repository è esplicito su tre aspetti. Le mesh di collisione di base sono state rimosse a causa di un comportamento problematico di collisione durante la simulazione e la pianificazione. Le proprietà del motore STS3215 sono adattate dal progetto Open Duck Mini piuttosto che misurate su un SO-101. E la convenzione del gripper LeRobot, dove 0 è completamente chiuso e 100 è completamente aperto, non è ancora esplicitamente riflessa nei file URDF e MuJoCo. Ognuno di questi è un punto in cui una policy addestrata puramente in quel modello si comporterà in modo diverso sulla vostra scrivania.

Randomizzazione del dominio, e cosa non risolve

La risposta standard al divario è smettere di cercare di eguagliare la realtà e invece addestrare su una distribuzione sufficientemente ampia da includere la realtà. Tobin e colleghi hanno mostrato la versione forte di questo nel 2017: un rilevatore di oggetti addestrato solo su immagini simulate con texture casuali non realistiche, senza alcun pre-addestramento su immagini reali, ha localizzato oggetti reali con una precisione di 1.5 cm ed è rimasto robusto a distrattori e occlusioni parziali.

Isaac Lab espone la stessa idea dei termini di evento che si associano a una configurazione dell'ambiente. Questi sono i parametri, con i loro nomi di funzione effettivi in isaaclab.envs.mdp, così puoi leggerli invece di indovinare.

Ecco il limite, ed è quello su cui le persone inciampano. La randomizzazione allarga la distribuzione che la policy ha visto all'interno del modello che hai costruito. Non può introdurre un effetto fisico che il simulatore non rappresenta. Se PhysX non sta modellando il gioco e il cedimento termico dei tuoi servomotori STS3215, randomizzare la loro rigidità non insegna nulla alla policy sul gioco. Ecco perché un braccio che si contrae e poi cede sotto una policy addestrata in simulazione non è un problema di budget di randomizzazione. È un problema di modellazione.

Il percorso manuale: generare dati in Isaac Lab

Isaac Gym è un software legacy. La pagina di NVIDIA è intitolata "Isaac Gym - Ora Deprecato" e afferma che gli sviluppatori possono scaricarlo e continuare a usarlo, ma che non è più supportato, indicando invece Isaac Lab. Se vuoi la storia, abbiamo trattato entrambi: e . Per i nuovi lavori nel 2026, inizia con Isaac Lab.

1. 1
   Installa Isaac Sim e Isaac Lab

   La pagina di installazione pip afferma che le istruzioni sono per Isaac Sim 5.X, che richiede Python 3.11. La clonazione del sorgente fornisce gli script necessari per i passaggi successivi.

   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
   Registra circa dieci dimostrazioni umane

   La documentazione di Isaac Lab è specifica: sono necessarie circa 10 dimostrazioni riuscite affinché i passaggi successivi abbiano successo. I suoi suggerimenti sono altrettanto specifici. Mantieni le dimostrazioni brevi, segui un percorso diretto piuttosto che muoverti lungo assi arbitrari e non mettere in pausa, perché non è ovvio per una policy perché e quando mettere in 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
   Annota i confini dei sottocompiti

   Mimic divide le dimostrazioni di input in sottocompiti in modo da poter ritemporizzare e ri-targettare i segmenti. Il flag --auto lo fa senza un intervento umano per i compiti che definiscono l'annotazione automatica; senza di esso si mette in pausa con B, si continua con N e si segna un confine con S. Si noti che l'ID del compito acquisisce un suffisso -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
   Genera il dataset moltiplicato

   Questo è il passaggio che trasforma 10 in 1000. Mimic applica un criterio di successo booleano a ogni candidato e mantiene solo quelli che hanno completato il compito, quindi il conteggio dell'output è inferiore al conteggio dei tentativi. La documentazione indica che il tasso di successo dei candidati è elevato, fino al 70 percento nei casi semplici e inferiore all'1 percento per compiti difficili e robot complessi: circa il 50 percento per l'impilamento di cubi Franka e dal 65 all'80 percento per il pick and place GR1T2, dove 1000 demo richiedono da 18 a 40 minuti (19 minuti su una RTX ADA 6000 all'80 percento).

   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
   Converti HDF5 in un dataset LeRobot

   Tutto quanto sopra produce HDF5 in stile robomimic, e il core di Isaac Lab non include un proprio convertitore LeRobot: la sua documentazione si limita a dire che è possibile convertire il dataset generato nel formato LeRobot. Due progetti forniscono il convertitore effettivo. IsaacLab-Arena fornisce un convertitore mirato a GR00T, interamente guidato da una configurazione YAML, e LeIsaac fornisce la propria coppia per il percorso SO-101 (vedi sotto).

   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

Perché i tentativi di generazione falliscono e cosa cambiare

Un tasso di successo candidato che oscilla tra il 70 percento e meno dell'1 percento non è un mistero, e Isaac Lab documenta le insidie comuni invece di lasciarti indovinare. Ognuna di esse è qualcosa che controlli al momento della registrazione, motivo per cui vale la pena leggere questo elenco prima di registrare le dieci dimostrazioni iniziali piuttosto che dopo la prima deludente esecuzione di generazione.

• Le dimostrazioni sono troppo lunghe. Un orizzonte temporale più lungo è più difficile da apprendere per una policy. Inizia vicino al primo oggetto e minimizza il movimento.
• Le dimostrazioni non sono fluide. Il movimento irregolare è difficile da decifrare per una policy, e un hardware di teleoperazione migliore fornisce dati migliori: la documentazione afferma chiaramente che un SpaceMouse è superiore a una tastiera.
• Pause. Le pause sono difficili da apprendere, perché non è ovvio per una policy perché e quando mettere in pausa. Mantieni il movimento fluido.
• Troppi sottocompiti. Più sottocompiti significano più unione tra segmenti di traiettoria, il che porta a un movimento meno fluido e a un tasso di successo di generazione inferiore. Annota i confini dove è improbabile che il braccio si scontri con qualcosa.
• Nessun rumore d'azione. Il rumore d'azione rende le policy risultanti più robuste.
• Registrazione tagliata troppo stretta. Se la registrazione si ferma esattamente sul frame in cui si attiva il termine di successo, potrebbe non riattivarsi durante la riproduzione. Lascia un buffer alla fine.
• Riproduzione non deterministica. La fisica in Isaac Lab non è riproducibile deterministicamente attraverso env.reset, quindi alcune demo umane falliscono durante la riproduzione. Raccogli più di quanto ti serve e conserva quelle che sopravvivono all'annotazione. Tutto ciò che finisce in un file HDF5 generato da Mimic è una demo di successo e può essere utilizzato per l'addestramento anche se la riproduzione fallisce in seguito.

Il passo di interpolazione tra i segmenti di sottocompiti uniti ha la sua manopola di regolazione, e il numero di passi di interpolazione necessari dipende dalla velocità con cui si muove il robot e dall'ampiezza della distribuzione di reset dell'oggetto. Un compito complesso con un'ampia distribuzione di reset lascia lacune maggiori tra i segmenti, il che richiede più passi di interpolazione per risultare in un movimento continuo. Se i tuoi video generati mostrano il braccio che si muove a scatti tra le fasi, quello è il parametro da esaminare prima di incolpare le demo iniziali.

La stessa pipeline su un SO-101, con il braccio leader reale

Questo è quello interessante per chiunque legga questa pagina, perché è l'unica pipeline aperta che inserisce un SO-101 all'interno di Isaac Lab e ti permette di guidarlo con il braccio leader fisico che già possiedi. LeIsaac, versione 0.4.0 al momento della stesura, è il parco giochi di simulazione ufficiale per l'apprendimento per imitazione integrato nell'EnvHub di LeRobot. La sua tabella di compatibilità elenca tre combinazioni funzionanti; la più recente abbina Isaac Sim 5.1 con Isaac Lab v2.3.0, CUDA 12.8, PyTorch 2.7.0 e Python 3.11, e la documentazione raccomanda Isaac Sim 5.0 o più recente per le schede della serie 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

Con questo configurato, il braccio leader su /dev/ttyACM0 guida il follower simulato e registra direttamente su HDF5. Il ciclo leader-seguace è lo stesso che già conosci dalla registrazione reale, solo che il follower è un corpo rigido in 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 maggior parte di questi ID esiste anche come variante -Direct-v0, e python scripts/environments/list_envs.py stampa l'elenco attuale. Puoi anche saltare completamente la deviazione HDF5 e scrivere nel formato LeRobot durante la teleoperazione aggiungendo tre flag. Due avvertenze provengono dalla documentazione stessa: il registratore salta automaticamente i primi 5 frame di ogni episodio per evitare instabilità dagli stati iniziali, e potrebbe causare lievi ritardi nella teleoperazione, che è esattamente il tipo di cosa che altera silenziosamente il carattere delle tue dimostrazioni. Inoltre, scarica gli episodi solo se il compito è stato contrassegnato come riuscito.

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

Il passo di moltiplicazione viene quindi eseguito su quelle registrazioni. LeIsaac incapsula Isaac Lab Mimic in quattro comandi, perché Mimic generalizza le traiettorie dalle pose dell'end-effector e degli oggetti: convertire le azioni nello spazio articolare in azioni basate su IK, annotare, generare, quindi riconvertire nello spazio articolare.

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

Quindi converti in LeRobot. Questo è il passaggio in cui la regola del formato della piattaforma si fa sentire, e LeIsaac fornisce esattamente i due convertitori di cui hai bisogno: isaaclab2lerobot.py scrive LeRobot v2, che è ciò che i loader GR00T utilizzano, e isaaclab2lerobotv3.py scrive v3 per Pi0.5, SmolVLA e ACT. I due script accettano argomenti identici ma fissano versioni diverse di lerobot, e vengono convertiti solo gli episodi riusciti.

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

Due percorsi per una policy addestrata

Modelli del mondo video: lo strato più recente e meno misurato

L'idea alla base di DreamGen è che un modello generativo video, adattato all'embodiment del robot target, possa immaginare episodi plausibili in scene che non hai mai visitato. La pipeline ha quattro fasi: fine-tuning del modello del mondo video, generazione di video robotici sintetici fotorealistici, recupero di sequenze di pseudo-azioni con un modello di azione latente o un modello di dinamica inversa, quindi addestramento della policy del robot sul risultato. Il repository GR00T-dreams di NVIDIA implementa esattamente questo.

Il risultato principale è reale e merita di essere preso sul serio: i dati di teleoperazione provenienti da un'unica attività di pick-and-place in un solo ambiente hanno prodotto 22 nuovi comportamenti su un umanoide, sia in ambienti visti che non visti. L'avvertenza è altrettanto reale e si trova nella terza fase.

Il co-training è la ricetta che mostra effettivamente dei guadagni

Se c'è una lezione operativa da trarre dalla letteratura, è questa. Lo studio di co-addestramento sim-e-reale (Maddukuri e colleghi, 2025) si è proposto di trovare una ricetta semplice per utilizzare i dati di simulazione per risolvere compiti di manipolazione robotica basati sulla visione, in due domini, un braccio robotico e un umanoide, e la sua conclusione è che si addestra su una miscela. I dati di simulazione hanno migliorato le prestazioni dei compiti nel mondo reale in media del 38 percento, e il documento è esplicito nel dire che ciò è valso anche con notevoli differenze tra la simulazione e i dati del mondo reale.

Quell'ultima clausola è più importante del 38 percento. Significa che la simulazione non deve essere un gemello digitale perfetto per essere utile, a condizione che i dati reali siano presenti nella miscela per ancorarla. Il trasferimento solo-simulazione è il percorso costoso: lo stesso documento afferma che addestrare una policy esclusivamente in simulazione e trasferirla al mondo reale spesso richiede uno sforzo umano sostanziale per colmare il divario di realtà. Il co-addestramento evita la maggior parte di tale sforzo non chiedendo mai alla policy di colmare il divario da sola.

In pratica, su questa piattaforma, il co-addestramento significa una cosa: inserire entrambi i set di episodi nello stesso dataset LeRobot con chiavi della telecamera coerenti, ordine delle giunzioni coerente e unità coerenti, quindi eseguire un normale fine-tuning. Non c'è una manopola per il peso della miscela nel modulo di addestramento. Se si desidera un rapporto sim-reale di 3:1, lo si esprime tramite il numero di episodi di ciascuno che si inseriscono nel dataset.

Il guadagno più economico dalla simulazione non sono i dati di addestramento

È la valutazione. Eseguire decine di prove reali per compito per confrontare due richiede un giorno di tempo braccio, e il braccio si sposta tra le prove. SIMPLER (Li e colleghi, 2024) ha costruito ambienti simulati il cui scopo è valutare politiche reali piuttosto che addestrarle, e ha poi misurato quanto bene la classifica della simulazione predice quella reale. Un singolo ambiente SIMPLER renderizza a 3.500 passi di simulazione al secondo su una RTX 4090 consumer a risoluzione 640 per 512, il che, con una frequenza di simulazione di 500 Hz, rappresenta un'accelerazione di 7x rispetto alla valutazione reale.

Queste sono medie su tre gruppi di compiti di Google Robot per sei checkpoint open-source comuni: tre checkpoint RT-1 a diverse fasi di addestramento, RT-1-X, RT-2-X e Octo-Base. Il lato reale non ha un numero uniforme di prove, il che è utile sapere prima di citarlo: 75 prove per prendere la lattina di Coca-Cola, 60 per spostarsi vicino, 54 per i compiti di apertura e chiusura del cassetto e 27 per il compito più lungo del cassetto e della mela. Il confronto con l'MSE di validazione è la parte utile. La selezione del modello tramite la perdita di validazione classifica male questi checkpoint, e un Pearson r di 0.924 con corrispondenza visiva significa che se un checkpoint ottiene un punteggio migliore in SIMPLER, molto probabilmente ottiene un punteggio migliore sul banco di prova. Questo è un tabellone di valutazione ripetibile da una notte all'altra, e non richiede di credere a nulla riguardo al trasferimento dell'addestramento da simulazione a realtà.

Se vuoi un contesto più ampio su cosa questi numeri di benchmark ti dicono e non ti dicono riguardo a un , lo abbiamo scritto separatamente in .

Dove questa piattaforma non ti aiuta

Essere chiari sul confine fa risparmiare tempo a tutti. AY-Robots è una piattaforma di registrazione, addestramento e servizio. Non contiene alcun simulatore.

• Nessun Isaac Lab, nessun MimicGen, nessun modello del mondo, nessuna creazione di scene. Se si desiderano dati generati, li si genera altrove e si porta il risultato.
• Gli addestratori consumano dataset LeRobot e nient'altro. Un'esportazione del simulatore deve essere convertita prima di essere un input, e deve essere la versione corretta: v2.0 o v2.1 per GR00T N1.5 e N1.7, v3.0 per Pi0.5, SmolVLA e ACT.
• Il punto di ingresso per il fine-tuning di GR00T è una CLI tyro che non espone alcun seed, quindi le esecuzioni di GR00T non sono riproducibili bit per bit. Se si sta eseguendo un'attenta ablazione sim-versus-real, questa è una vera limitazione. Il seed predefinito di lerobot è 1000, e i moduli ACT, SmolVLA e Pi0.5 espongono un campo seed.
• L'accumulo del gradiente è effettivamente applicato solo per i due addestratori GR00T. Per Pi0.5 e SmolVLA il campo esiste nel modulo ma lerobot 0.5.1 non ha tale flag, quindi non fa nulla.
• L'inferenza deve essere posizionata vicino ai servi per compiti veloci. Il ciclo di controllo è di 20 a 485 ms per passo d'azione a seconda del modello, e l'aggiunta di round trip su internet pubblico trasforma una policy funzionante in una esitante. L'inferenza remota è praticabile per il pick-and-place lento, non per il movimento reattivo veloce.

Un budget che puoi difendere

Metti i due percorsi fianco a fianco con i numeri che ciascuno pubblica effettivamente, e la decisione di solito si prende da sola per un progetto a compito singolo su un braccio a basso costo.

Per una prima policy su un SO-100, registra. La e la ti portano a un checkpoint servito al prezzo di un caffè, e avrai la metà reale di qualsiasi futura miscela di co-addestramento. Ricorri al simulatore quando hai una baseline funzionante e un fallimento di generalizzazione specifico che puoi nominare, come una policy che .

Una ricetta che rispetta le prove

1. 1
   Registra prima la baseline reale

   30 episodi per SmolVLA, 50 per ACT, GR00T N1.7 e Pi0.5. Addestra una volta. Qualsiasi cosa in cui quella policy fallisce è la tua specifica per i dati sintetici.

2. 2
   Nomina il fallimento di generalizzazione

   Posa dell'oggetto? Illuminazione? Altezza del tavolo? Distrattori? Una diversa formulazione dell'istruzione? I dati sintetici sono efficaci esattamente in uno di questi aspetti alla volta, e inutili se non riesci a dire quale.

3. 3
   Scegli la famiglia più economica che lo copre

   Variazione di posa e layout: moltiplicazione della traiettoria. Illuminazione e texture: prima l'aumento delle immagini, poi il modello del mondo. Scene completamente nuove: rollouts fisici, e accetta il costo di modellazione.

4. 4
   Genera, poi scarta aggressivamente

   I tentativi di generazione falliscono, e il tasso di successo dei candidati di Isaac Lab varia dal 70 percento a meno dell'1 percento a seconda del compito. Conserva solo le traiettorie riuscite e che completano il compito, e controlla un campione come video prima di fidarti del batch.

   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-addestra, non sostituire

   Unisci gli episodi generati con quelli reali in un singolo dataset LeRobot con chiavi della telecamera e ordinamento delle giunture identici. La cifra del 38 percento è una cifra di co-training.

6. 6
   Valuta sul braccio reale, e solo lì

   La valutazione simulata è un buon segnale di ranking (Pearson r 0.924 nella configurazione di corrispondenza visiva di SIMPLER) ma non è il test di accettazione. Esegui il checkpoint sul banco prima di crederci.

Se preferisci iniziare da una checklist per le registrazioni reali stesse, , copre il posizionamento della telecamera, implicazioni e le modalità di fallimento che rendono un dataset di inutilizzabile. I dettagli sul formato stesso si trovano in , e il lato degli iperparametri in .