E1 · Camino del fabricante listo
10 minCorre la preparación de DDS, del SDK y de unitree_mujoco.
Listo cuando: el bloque termina en cyclonedds 0.10.2 · unitree_sdk2py ok.
Clase 6 · 18 min
Antes de cualquier robot, la policy tiene que pasar por un segundo simulador y por el mismo camino de mensajes que usa el robot. Es el flujo oficial de unitree_rl_lab: entrenar en Isaac Lab, validar en unitree_mujoco y solo después el G1. En esta clase armas esa compuerta (gate) en tres etapas, con DDS de verdad, y ves el error que más derriba policies en esa travesía.
Empezar la clase
Objetivo: pasar la policy por una compuerta (gate) de tres etapas: otro modelo del robot y el camino DDS de mensajes del fabricante.
Haz clic en cada bloque. Si reprueba en una etapa, no sube.
Un estudio de 2026 con el G1 en acciones de obra de construcción evaluó cada acción en dos motores de física antes del robot, y solo las que pasaron fueron al G1 físico (arXiv 2608.01600, según robotica-real2sim, verificado el 14/10/2026).
Hallazgos reales del armado de esta compuerta (gate) (19/10/2026). Haz clic en cada uno.
Isaac Lab ordena las articulaciones de una manera; el SDK del robot, de otra. El deploy.yaml trae el mapa (joint_ids_map), y cada lista viene en un orden: kp y kd en el orden del robot, pose por defecto y acciones en el orden de Isaac Lab.
Equivocarse en esto derriba al robot en 1 s, en los dos simuladores (error común abajo).
El unitree_mujoco viene con paso de 5 ms e integrador de Euler. Con el kd = 10 de la muñeca (límite de 5 N·m en el pitch y en el yaw), el PD oscila y el brazo queda en el límite de torque todo el tiempo. La marcha no sufre; la compuerta (gate) da aviso, no reprueba.
Con 1–2 ms, el aviso desaparece. Viene del simulador, no de la policy: revísalo antes de tocar el entrenamiento.
La interfaz lo no hace multicast, y sin multicast dos procesos DDS no se encuentran. El kit agrega a la configuración de Unitree un par fijo en 127.0.0.1 (s2r.iniciar_dds) solo cuando la interfaz es lo.
En el robot, la interfaz es la tarjeta de red conectada a él; el dominio y los tópicos son los mismos.
El SDK pide el paquete de Python cyclonedds==0.10.2. En aarch64 no hay wheel: pip falla sin la biblioteca C. El bloque compila la rama releases/0.10.x (5041f35) con cmake, en 1–2 min.
El tag 0.10.2 de C abortó aquí con "buffer overflow detected". En x86_64 pip suele encontrar la wheel (reportado, no probado aquí).
CycloneDDS 0.10.2, unitree_sdk2_python y unitree_mujoco, fijados en los commits probados. Necesitas cmake y un compilador C si pip no encuentra wheel.
F=${FTH:-$HOME/fth}; cd $F && . .venv/bin/activate
pip install -q cyclonedds==0.10.2 2>/dev/null || {
[ -d cyclonedds ] || git clone -q --filter=blob:none -b releases/0.10.x https://github.com/eclipse-cyclonedds/cyclonedds
git -C cyclonedds checkout -q 5041f35
cmake -S cyclonedds -B cyclonedds/build -DCMAKE_INSTALL_PREFIX=$F/cyclonedds/install -DBUILD_EXAMPLES=OFF > /dev/null
cmake --build cyclonedds/build --target install -j 4 > /dev/null 2>&1
export CYCLONEDDS_HOME=$F/cyclonedds/install && pip install -q cyclonedds==0.10.2; }
git -C cyclonedds log -1 --format="cyclonedds (C) %H (%ad)" --date=short 2>/dev/null | sed -E 's/([0-9a-f]{7})[0-9a-f]{33}/\1/'
[ -d unitree_sdk2_python ] || git clone -q https://github.com/unitreerobotics/unitree_sdk2_python
git -C unitree_sdk2_python checkout -q 814556d && pip install -q -e unitree_sdk2_python pygame
[ -d unitree_mujoco ] || git clone -q https://github.com/unitreerobotics/unitree_mujoco
git -C unitree_mujoco checkout -q 1eb6642 && git -C unitree_mujoco log -1 --format='unitree_mujoco %h (%ad)' --date=short
python3 -c "import importlib.metadata as m, unitree_sdk2py; print('cyclonedds', m.version('cyclonedds'), '· unitree_sdk2py ok')"cyclonedds (C) 5041f35 (2026-03-22) unitree_mujoco 1eb6642 (2026-09-07) cyclonedds 0.10.2 · unitree_sdk2py ok
Tres líneas. La primera vez en esta máquina (aarch64), la compilación de CycloneDDS tardó de 1 a 2 minutos.
Sin --dds, las etapas 1 y 2 (determinísticas, ~1 min). Con --dds, la etapa 3 en tiempo real. --passo cambia el paso de unitree_mujoco.
F=${FTH:-$HOME/fth}; cd $F/sim2real && . $F/.venv/bin/activate
python3 kit/portao_sim2sim.py; echo "saída: $?"F=${FTH:-$HOME/fth}; cd $F/sim2real && . $F/.venv/bin/activate
python3 kit/portao_sim2sim.py --passo 0.001 --dds 2>/dev/null; echo "saída: $?"F=${FTH:-$HOME/fth}; cd $F/sim2real && . $F/.venv/bin/activate
python3 kit/portao_sim2sim.py --ordem sdk; echo "saída: $?"política: unitree_rl_lab velocity v0 · ordem das juntas: isaac · 0.5 m/s por 10 s
1 Menagerie (MuJoCo, PD no MJCF) passou · andou 4.7 m
2 unitree_mujoco (passo 5 ms) passou · andou 4.8 m
aviso: braços no limite de torque em 99% do tempo
PORTÃO: passou (2 de 2 etapas)
saída: 0Pasó, con el aviso de los brazos en el paso de 5 ms.
política: unitree_rl_lab velocity v0 · ordem das juntas: isaac · 0.5 m/s por 10 s 1 Menagerie (MuJoCo, PD no MJCF) passou · andou 4.7 m 2 unitree_mujoco (passo 1 ms) passou · andou 4.7 m 3 unitree_mujoco + DDS (tempo real) passou · andou 5.3 m · política a 50 Hz PORTÃO: passou (3 de 3 etapas) saída: 0
La etapa 3 corre en tiempo real: la distancia y el aviso de los brazos cambian un poco de una ronda a otra. Lo que vale es la última línea.
política: unitree_rl_lab velocity v0 · ordem das juntas: sdk · 0.5 m/s por 10 s
1 Menagerie (MuJoCo, PD no MJCF) reprovou · andou -0.1 m e caiu · caiu em t = 1.0 s; pernas/cintura no limite de torque em 3% do tempo (máx. 1 %)
aviso: braços no limite de torque em 6% do tempo
2 unitree_mujoco (passo 5 ms) reprovou · andou -0.3 m e caiu · caiu em t = 1.0 s; pernas/cintura no limite de torque em 6% do tempo (máx. 1 %)
aviso: braços no limite de torque em 98% do tempo
PORTÃO: reprovou — caiu em t = 1.0 s
saída: 1Con --ordem sdk, el kit usa la pose predeterminada y las acciones como si ya estuvieran en el orden del robot. El G1 cae en 1 s en los dos modelos. Si tu policy cae apenas empieza, revisa el mapa antes que cualquier otra cosa.
Nada va al robot sin pasar por aquí.
Corre la preparación de DDS, del SDK y de unitree_mujoco.
Listo cuando: el bloque termina en cyclonedds 0.10.2 · unitree_sdk2py ok.
Corre las tres etapas con paso de 1 ms.
Listo cuando: python3 kit/portao_sim2sim.py --passo 0.001 --dds 2>/dev/null; echo "saída: $?" → PORTÃO: passou (3 de 3 etapas) y saída: 0.
Corre con el orden de las articulaciones equivocado y anota en qué etapa y en cuánto tiempo reprueba.
Listo cuando: python3 kit/portao_sim2sim.py --ordem sdk; echo "saída: $?" → PORTÃO: reprovou — caiu em t = 1.0 s y saída: 1.
La explicación aparece después de tu respuesta.
Pregunta 1 de 4
¿Por qué la etapa 3 corre el robot en un proceso separado y se comunica por DDS?competencia
Pregunta 2 de 4
La policy cae en 1 s en los dos modelos, justo al comienzo. ¿Cuál es la primera sospecha?
Pregunta 3 de 4
En la etapa 2 con paso de 5 ms, los brazos quedan en el límite de torque, pero la marcha pasa. ¿Qué haces?
Pregunta 4 de 4
¿Por qué la interfaz lo necesitó un par fijo en 127.0.0.1?
Elige una alternativa. La explicación aparece después de tu intento.