Datos Sintéticos para Políticas de Robots: Donde la Simulación Ayuda

Cada pocos meses alguien se da cuenta de que grabar cincuenta episodios a mano es lento, y pregunta si un simulador podría producirlos en su lugar. Es una pregunta justa. La respuesta honesta tiene tres partes: los datos generados sí ayudan, no reemplazan las grabaciones reales, y la proporción entre esos dos hechos depende enteramente del tipo de datos sintéticos a los que te refieras.

Esta página detalla lo que el trabajo publicado realmente midió, lo que puedes ejecutar hoy en un brazo de bajo costo como el SO-100, y dónde la brecha de simulación a realidad (sim-to-real) consume las ganancias. La versión corta, antes del detalle: los sistemas que reportan los mayores multiplicadores multiplican un pequeño conjunto de demostraciones humanas reales. No eliminan la necesidad de ellas.

Cuatro cosas diferentes se denominan datos sintéticos

Antes de comparar números, vale la pena separar las familias, porque un artículo que informa un multiplicador de 100x y otro que informa una ganancia de éxito de 5 puntos a menudo describen el mismo proceso desde diferentes perspectivas. El hilo conductor es que algo en el LeRobot dataset fue producido por una máquina en lugar de ser grabado de un brazo físico. Lo que difiere es qué parte.

Solo los tres primeros son datos sintéticos en el sentido que este artículo quiere decir. El cuarto vale la pena mencionarlo porque se agrupa en la misma conversación y es, con mucho, lo más barato de la lista. Si aún no has activado las aumentaciones con las que viene tu entrenador, hazlo antes de instalar un simulador.

Lo que realmente dicen los números publicados

Aquí está la base de evidencia, con los números tal como los declaran las fuentes en lugar de como los resumen los comunicados de prensa. Cada fila a continuación proviene de un artículo o página de proyecto leída el 23 de agosto de 2026.

El patrón en cada ablación honesta es el mismo. Los datos sintéticos amplían la cobertura de forma económica. No crean información sobre su pinza, la holgura de su servo, su iluminación o la altura de su mesa que no estuviera ya en las demostraciones reales en algún lugar. Si su política falla porque el efector final se cierra medio segundo demasiado tarde, ninguna cantidad de variación simulada lo arreglará. Eso es un problema de temporización de la pinza en las grabaciones reales.

Un hallazgo de MimicGen merece ser tenido en cuenta en sus propias sesiones de grabación, porque va en contra del consejo habitual. El proyecto generó dos conjuntos de datos en Square D2, uno con 10 demostraciones de un operador humano de mejor calidad y otro con 10 demostraciones de un operador de peor calidad, ambos tomados del conjunto de datos robomimic multi-humano Square. Las políticas entrenadas en cada uno lograron resultados comparables, lo que los autores interpretaron como una señal de que en el régimen de datos a gran escala la calidad de los datos podría no importar tanto. Léase con atención, esa es una afirmación sobre las diez demostraciones iniciales, no sobre sus cincuenta episodios reales. Significa que un conjunto inicial ligeramente desordenado no es lo que se interpone entre usted y un conjunto de datos generado utilizable. No significa que los episodios reales en los que co-entrena puedan ser desordenados, porque esos son los que llevan la información que el simulador no tiene.

La brecha de simulación a realidad, concretamente

La brecha se suele discutir como una única cantidad, lo cual no es útil. Son al menos cinco desajustes distintos, y tienen tamaños diferentes en un brazo de hobby de 110 a 150 EUR que en un Franka.

• Contacto y fricción. Isaac Lab afirma claramente que, dado el mismo hardware y la misma versión de Isaac Sim y PhysX, la simulación es reproducible, pero que los resultados varían entre diferentes configuraciones de hardware debido a la precisión de punto flotante y los errores de redondeo, y que PhysX no garantiza el determinismo para ninguna escena con cuerpos no rígidos como tela o cuerpos blandos.
• Actuación. Un servo de bus Feetech STS3215 funcionando a 7.4 V cede bajo carga, tiene holgura y cambia su comportamiento a medida que se calienta. El modelo MJCF para el SO-101 toma prestados sus parámetros de motor de un proyecto no relacionado en lugar de identificarlos en su brazo.
• Renderizado. El ruido de la cámara, el obturador rodante, la autoexposición y el tono exacto de su mesa no están en el renderizado. Esta es la mitad de la brecha que Cosmos-Transfer1 fue construido para cerrar: su flujo de trabajo de aumento robótico mapea un ejemplo sintético robótico a múltiples ejemplos realistas a partir de segmentación, profundidad o condicionamiento de bordes.
• Sincronización. Un simulador avanza a una velocidad fija. Un bucle de control real no lo hace, y el modelo en sí cuesta de 20 a 485 ms por paso de acción, dependiendo de cuál haya elegido. Consulte latencia de inferencia.
• Estadísticas de objetos. Las escenas simuladas se muestrean de una distribución que alguien escribió. Su mesa de cocina no lo es.

Lo que un SO-100 simulado realmente sabe sobre su brazo

Esta es la parte que decide si algo de lo anterior vale la pena su fin de semana, y la primera sorpresa es que el SO-100 y el SO-101 no están igualmente atendidos. El repositorio SO-ARM100 de TheRobotStudio mantiene sus activos de simulación bajo Simulation/. La carpeta SO100 contiene un único archivo URDF y nada más. La carpeta SO101 contiene archivos URDF y MuJoCo: scene.xml, so101_new_calib.xml, so101_old_calib.xml, los URDF correspondientes y un joints_properties.xml. Si desea un modelo físico en lugar de una cadena cinemática, necesita los archivos SO-101.

Se generaron con el plugin onshape-to-robot a partir de un modelo CAD diseñado en Onshape, lo que significa que la cinemática y las mallas visuales son tan buenas como el CAD. La dinámica es otra historia, y el README del propio repositorio es sincero sobre tres cosas. Las mallas de colisión base se eliminaron debido a un comportamiento problemático de colisión durante la simulación y la planificación. Las propiedades del motor STS3215 se adaptan del proyecto Open Duck Mini en lugar de medirse en un SO-101. Y la convención del gripper LeRobot, donde 0 es completamente cerrado y 100 es completamente abierto, aún no se refleja explícitamente en los archivos URDF y MuJoCo. Cada uno de esos es un lugar donde una política entrenada puramente en ese modelo se comportará de manera diferente en su escritorio.

Aleatorización de dominio, y lo que no soluciona

La respuesta estándar a la brecha es dejar de intentar igualar la realidad y, en su lugar, entrenar a través de una distribución lo suficientemente amplia como para que la realidad caiga dentro de ella. Tobin y sus colegas mostraron la versión fuerte de esto en 2017: un detector de objetos entrenado solo con imágenes simuladas con texturas aleatorias no realistas, sin ningún pre-entrenamiento en imágenes reales, localizó objetos reales con una precisión de 1.5 cm y se mantuvo robusto ante distractores y oclusiones parciales.

Isaac Lab expone la misma idea que los términos de evento que se adjuntan a una configuración de entorno. Estos son los controles, por sus nombres de función reales en isaaclab.envs.mdp, para que pueda consultarlos en lugar de adivinar.

Aquí está el límite, y es el que la gente suele pasar por alto. La aleatorización amplía la distribución que la política ha visto dentro del modelo que usted construyó. No puede introducir un efecto físico que el simulador no represente. Si PhysX no está modelando la holgura y la caída térmica de sus servomotores STS3215, aleatorizar su rigidez no le enseña nada a la política sobre la holgura. Por eso, un brazo que se sacude y luego se desploma bajo una política entrenada en simulación no es un problema de presupuesto de aleatorización. Es un problema de modelado.

La ruta manual: generación de datos en Isaac Lab

Isaac Gym es un software heredado. La propia página de NVIDIA se titula "Isaac Gym - Ahora obsoleto" y dice que los desarrolladores pueden descargarlo y seguir usándolo, pero que ya no es compatible, señalando a Isaac Lab en su lugar. Si quieres conocer la historia, cubrimos ambos: y . Para nuevos trabajos en 2026, comienza con Isaac Lab.

1. 1
   Instalar Isaac Sim e Isaac Lab

   La página de instalación de pip indica que las instrucciones son para Isaac Sim 5.X, que requiere Python 3.11. La clonación del código fuente proporciona los scripts necesarios para los siguientes pasos.

   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
   Grabar unas diez demostraciones humanas

   La documentación de Isaac Lab es específica: se requieren aproximadamente 10 demostraciones exitosas para que los siguientes pasos tengan éxito. Sus consejos son igualmente específicos. Mantén las demostraciones cortas, toma un camino directo en lugar de moverte a lo largo de ejes arbitrarios, y no hagas pausas, porque no es obvio para una política por qué y cuándo pausar.

   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
   Anotar los límites de las subtareas

   Mimic divide las demostraciones de entrada en subtareas para poder reajustar el tiempo y el objetivo de los segmentos. El flag --auto hace esto sin intervención humana para las tareas que definen la anotación automática; sin él, pausas con B, continúas con N y marcas un límite con S. Ten en cuenta que el ID de la tarea obtiene un sufijo -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
   Generar el conjunto de datos multiplicado

   Este es el paso que convierte 10 en 1000. Mimic aplica un criterio de éxito booleano a cada candidato y solo conserva aquellos que completaron la tarea, por lo que el recuento de salida es menor que el recuento de intentos. La documentación sitúa la tasa de éxito de los candidatos en hasta el 70 por ciento en casos simples y por debajo del 1 por ciento para tareas difíciles y robots complejos: aproximadamente el 50 por ciento para el apilamiento de cubos de Franka, y del 65 al 80 por ciento para la tarea de recogida y colocación de GR1T2, donde 1000 demostraciones tardan de 18 a 40 minutos (19 minutos en una RTX ADA 6000 al 80 por ciento).

   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 a un conjunto de datos LeRobot

   Todo lo anterior produce HDF5 con sabor a robomimic, y el núcleo de Isaac Lab no incluye su propio convertidor de LeRobot: su documentación solo dice que puedes convertir el conjunto de datos generado al formato LeRobot. Dos proyectos proporcionan el convertidor real. IsaacLab-Arena incluye uno dirigido a GR00T impulsado completamente por una configuración YAML, y LeIsaac incluye su propio par para la ruta SO-101 (ver más abajo).

   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

Por qué fallan los intentos de generación y qué cambiar

Una tasa de éxito candidata que oscila entre el 70 por ciento y menos del 1 por ciento no es un misterio, e Isaac Lab documenta los errores comunes en lugar de dejarte adivinar. Cada uno de ellos es algo que controlas en el momento de la grabación, por lo que vale la pena leer esta lista antes de grabar las diez demostraciones semilla en lugar de después de la primera ejecución de generación decepcionante.

• Las demostraciones son demasiado largas. Un horizonte temporal más largo es más difícil de aprender para una política. Comienza cerca del primer objeto y minimiza el movimiento.
• Las demostraciones no son fluidas. El movimiento irregular es difícil de descifrar para una política, y un mejor hardware de teleoperación proporciona mejores datos: la documentación dice claramente que un SpaceMouse supera a un teclado.
• Pausas. Las pausas son difíciles de aprender, porque no es obvio para una política por qué y cuándo pausar. Mantén el movimiento fluido.
• Demasiadas subtareas. Más subtareas significan más unión entre segmentos de trayectoria, lo que resulta en un movimiento menos fluido y una menor tasa de éxito de generación. Anota los límites donde es poco probable que el brazo colisione con algo.
• Sin ruido de acción. El ruido de acción hace que las políticas resultantes sean más robustas.
• Grabación demasiado ajustada. Si la grabación se detiene en el fotograma exacto en que se activa el término de éxito, es posible que no se vuelva a activar durante la reproducción. Deja un búfer al final.
• Reproducción no determinista. La física en Isaac Lab no es reproducible de forma determinista en env.reset, por lo que algunas demostraciones humanas fallan en la reproducción. Recopila más de las que necesitas y conserva las que sobrevivan a la anotación. Todo lo que llega a un archivo HDF5 generado por Mimic es una demostración exitosa y puede usarse para el entrenamiento incluso si la reproducción falla más tarde.

El paso de interpolación entre segmentos de subtareas unidos tiene su propio control de ajuste, y el número de pasos de interpolación que necesitas escala con la velocidad a la que se mueve el robot y la amplitud de la distribución de reinicio del objeto. Una tarea compleja con una gran distribución de reinicio deja mayores huecos entre segmentos, lo que requiere más pasos de interpolación para resultar en un movimiento continuo. Si tus videos generados muestran el brazo tambaleándose entre fases, ese es el parámetro a considerar antes de culpar a las demostraciones semilla.

El mismo pipeline en un SO-101, con el brazo líder real

Este es el interesante para cualquiera que lea esta página, porque es el único pipeline abierto que coloca un dentro de Isaac Lab y te permite controlarlo con el brazo líder físico que ya posees. LeIsaac, versión 0.4.0 en el momento de escribir esto, es el entorno de simulación oficial para el aprendizaje por imitación integrado en el EnvHub de LeRobot. Su tabla de compatibilidad enumera tres combinaciones funcionales; la más reciente combina Isaac Sim 5.1 con Isaac Lab v2.3.0, CUDA 12.8, PyTorch 2.7.0 y Python 3.11, y la documentación recomienda Isaac Sim 5.0 o posterior para tarjetas de la 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 eso en su lugar, el brazo líder en /dev/ttyACM0 controla el seguidor simulado y graba directamente en HDF5. El bucle es el mismo que ya conoces de la grabación real, solo que el seguidor es un cuerpo rígido en 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 mayoría de esos IDs también existen como una variante -Direct-v0, y python scripts/environments/list_envs.py imprime la lista actual. También puedes omitir por completo el desvío de HDF5 y escribir el formato LeRobot durante la teleoperación añadiendo tres banderas. Dos advertencias provienen de la propia documentación: el grabador omite automáticamente los primeros 5 fotogramas de cada episodio para evitar la inestabilidad de los estados iniciales, y puede causar ligeros retrasos en la teleoperación, lo cual es exactamente el tipo de cosa que cambia sutilmente el carácter de tus demostraciones. También solo guarda los episodios que la tarea marcó como exitosos.

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

El paso de multiplicación se ejecuta luego sobre esas grabaciones. LeIsaac envuelve Isaac Lab Mimic en cuatro comandos, porque Mimic generaliza trayectorias a partir de las poses del efector final y del objeto: convierte las acciones en el espacio de las articulaciones a acciones basadas en IK, anota, genera y luego convierte de nuevo al espacio de las articulaciones.

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

Luego, convierta a LeRobot. Este es el paso donde la regla de formato de la plataforma se aplica, y LeIsaac proporciona exactamente los dos convertidores que necesita: isaaclab2lerobot.py, escribe LeRobot v2, que es lo que utilizan los cargadores de GR00T, y isaaclab2lerobotv3.py escribe v3 para Pi0.5, SmolVLA y ACT. Los dos scripts aceptan argumentos idénticos pero fijan diferentes versiones de lerobot, y solo se convierten los episodios exitosos.

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

Dos rutas para una política entrenada

Modelos de mundo de video: la capa más nueva y la menos medida

La idea detrás de DreamGen es que un modelo generativo de video, adaptado a la encarnación del robot objetivo, puede imaginar episodios plausibles en escenas que nunca visitaste. El pipeline tiene cuatro etapas: ajustar el modelo de mundo de video, generar videos de robots sintéticos fotorrealistas, recuperar secuencias de pseudo-acciones con un modelo de acción latente o un modelo de dinámica inversa, y luego entrenar la política del robot con el resultado. El repositorio GR00T-dreams de NVIDIA implementa exactamente eso.

El resultado principal es real y digno de ser tomado en serio: los datos de teleoperación de una única tarea de "pick-and-place" en un solo entorno produjeron 22 nuevos comportamientos en un humanoide, tanto en entornos vistos como no vistos. La advertencia es igualmente real y se encuentra en la tercera etapa.

El co-entrenamiento es la receta que realmente muestra ganancias

Si hay una lección operativa que extraer de la literatura, es esta. El estudio de co-entrenamiento sim-y-real (Maddukuri y colegas, 2025) se propuso encontrar una receta simple para usar datos de simulación para resolver tareas de manipulación robótica basadas en visión, en dos dominios, un brazo robótico y un humanoide, y su conclusión es que se entrena con una mezcla. Los datos de simulación mejoraron el rendimiento de las tareas en el mundo real en un promedio del 38 por ciento, y el artículo es explícito en que esto se mantuvo incluso con diferencias notables entre los datos de simulación y los del mundo real.

Esa última cláusula importa más que el 38 por ciento. Significa que la simulación no tiene que ser un gemelo digital perfecto para ser útil, siempre que los datos reales estén en la mezcla para anclarla. La transferencia solo con simulación es el camino costoso: el mismo artículo afirma que entrenar una política únicamente en simulación y transferirla al mundo real a menudo exige un esfuerzo humano sustancial para cerrar la brecha de la realidad. El co-entrenamiento omite la mayor parte de ese esfuerzo al no pedirle nunca a la política que cierre la brecha por sí misma.

Prácticamente, en esta plataforma, el co-entrenamiento significa una cosa: colocar ambos conjuntos de episodios en el mismo conjunto de datos LeRobot con claves de cámara consistentes, orden de articulaciones consistente y unidades consistentes, luego ejecutar un ajuste fino. No hay un control de peso de mezcla en el formulario de entrenamiento. Si desea una relación sim-a-real de 3:1, lo expresa por la cantidad de episodios de cada uno que coloque en el conjunto de datos.

La victoria más económica de la simulación no son los datos de entrenamiento

Es la evaluación. Ejecutar docenas de pruebas reales por tarea para comparar dos es un día de tiempo de brazo, y el brazo se desvía entre pruebas. SIMPLER (Li y colaboradores, 2024) construyó entornos simulados cuyo propósito es calificar políticas reales en lugar de entrenarlas, y luego midió qué tan bien la clasificación de la simulación predice la real. Un solo entorno SIMPLER se renderiza a 3,500 pasos de simulación por segundo en una RTX 4090 de consumo a una resolución de 640 por 512, lo que bajo una frecuencia de simulación de 500 Hz representa una aceleración de 7x sobre la evaluación real.

Esos son promedios de tres grupos de tareas de Google Robot para seis puntos de control de código abierto comunes: tres puntos de control RT-1 en diferentes etapas de entrenamiento, RT-1-X, RT-2-X y Octo-Base. El lado real no tiene un número uniforme de pruebas, lo cual es importante saber antes de citarlo: 75 pruebas para recoger una lata de Coca-Cola, 60 para mover cerca, 54 para las tareas de abrir y cerrar cajones y 27 para la tarea más larga de cajón y manzana. La comparación con el MSE de validación es la parte útil. La selección de modelos por pérdida de validación clasifica mal estos puntos de control, y un r de Pearson de 0.924 bajo coincidencia visual significa que si un punto de control obtiene una mejor puntuación en SIMPLER, es muy probable que obtenga una mejor puntuación en el banco de pruebas. Eso es un marcador repetible de la noche a la mañana, y no requiere que creas nada sobre la transferencia de entrenamiento de simulación a la realidad.

Si desea el contexto más amplio sobre lo que estos números de benchmark le dicen y no le dicen sobre un , lo redactamos por separado en .

Dónde esta plataforma no le ayuda

Ser claro sobre los límites ahorra tiempo a todos. AY-Robots es una plataforma de grabación, entrenamiento y servicio. No contiene ningún simulador.

• Sin Isaac Lab, sin MimicGen, sin modelo de mundo, sin autoría de escenas. Si quieres datos generados, los generas en otro lugar y traes el resultado.
• Los entrenadores consumen conjuntos de datos de LeRobot y nada más. Una exportación de simulador debe convertirse antes de ser una entrada, y debe ser la versión correcta: v2.0 o v2.1 para GR00T N1.5 y N1.7, v3.0 para Pi0.5, SmolVLA y ACT.
• El punto de entrada de ajuste fino de GR00T es una CLI de tyro que no expone ninguna semilla, por lo que las ejecuciones de GR00T no son reproducibles bit a bit. Si estás realizando una cuidadosa ablación sim-versus-real, esa es una limitación real. La semilla predeterminada de lerobot es 1000, y los formularios de ACT, SmolVLA y Pi0.5 sí exponen un campo de semilla.
• La acumulación de gradientes solo se aplica realmente para los dos entrenadores GR00T. Para Pi0.5 y SmolVLA, el campo existe en el formulario, pero lerobot 0.5.1 no tiene dicha bandera, por lo que no hace nada.
• La inferencia debe estar junto a los servos para tareas rápidas. El bucle de control es de 20 a 485 ms por paso de acción dependiendo del modelo, y añadir viajes de ida y vuelta por internet público convierte una política funcional en una dubitativa. La inferencia remota es viable para tareas lentas de 'pick-and-place', no para movimientos reactivos rápidos.

Un presupuesto que puedes defender

Pon los dos caminos uno al lado del otro con los números que cada uno publica realmente, y la decisión generalmente se toma sola para un proyecto de una sola tarea en un brazo de bajo costo.

Para una primera política en un SO-100, graba. El y te llevan a un punto de control servido por el precio de un café, y tendrás la mitad real de cualquier futura mezcla de co-entrenamiento. Recurre al simulador cuando tengas una línea base funcional y un fallo de generalización específico que puedas nombrar, como una política que .

Una receta que respeta la evidencia

1. 1
   Registre primero la línea base real

   30 episodios para SmolVLA, 50 para ACT, GR00T N1.7 y Pi0.5. Entrene una vez. Aquello en lo que la política falle es su especificación para los datos sintéticos.

2. 2
   Nombre el fallo de generalización

   ¿Pose del objeto? ¿Iluminación? ¿Altura de la mesa? ¿Distractores? ¿Una formulación diferente de la instrucción? Los datos sintéticos son buenos en exactamente uno de estos a la vez, e inútiles si no puede decir cuál.

3. 3
   Elija la familia más económica que lo cubra

   Variación de pose y disposición: multiplicación de trayectorias. Iluminación y textura: aumento de imagen primero, modelo del mundo segundo. Escenas completamente nuevas: simulaciones físicas (physics rollouts), y acepte el coste de modelado.

4. 4
   Genere, luego descarte agresivamente

   Los intentos de generación fallan, y la tasa de éxito de los candidatos de Isaac Lab oscila entre el 70 por ciento y menos del 1 por ciento, dependiendo de la tarea. Conserve solo las trayectorias exitosas que completen la tarea, y revise una muestra en video antes de confiar en el lote.

   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-entrene, no reemplace

   Combine los episodios generados con los reales en un único conjunto de datos LeRobot con claves de cámara y orden de articulaciones idénticos. La cifra del 38 por ciento es una cifra de co-entrenamiento.

6. 6
   Evalúe en el brazo real, y solo allí

   La evaluación simulada es una buena señal de clasificación (Pearson r 0.924 en la configuración de coincidencia visual de SIMPLER), pero no es la prueba de aceptación. Ejecute el punto de control en el banco de pruebas antes de creer en él.

Si prefiere empezar con una lista de verificación para las grabaciones reales, cubre la colocación de la cámara, las implicaciones del y los modos de fallo que hacen que un conjunto de datos de sea inutilizable. Los detalles sobre el formato en sí se encuentran en , y la parte de los hiperparámetros en .