e9038949 y la revisión de microduck_rl cb70b792. Este sitio verificó los comandos documentados y la fuente del iniciador; no reprodujo la simulación completa del demonio localmente.Elija el simulador que coincida con la pregunta.
Esto es diferente de la experiencia del navegador. El simulador de navegador es la forma más rápida de probar movimientos existentes. El simulador de demonio sirve para desarrollar el software del robot en sí: el mismo robotd, bucle de control de 50 Hz, políticas, controles de seguridad, IPC y robotctl impulsa un cuerpo MuJoCo. Guía oficial de simulación de demonios ↗
| Ruta | Úselo para | No establece |
|---|---|---|
| Simulador de navegador | Probar controles y movimientos existentes sin instalar una cadena de herramientas. | Comportamiento del demonio local, actualizador o IPC. |
duck-sim modo simple | Desarrollo de políticas, lazo de control, IPC, consola y cliente. | Comportamiento del motor-bus, Bluetooth, cámara ISP, NPU o codificador-controlador. |
duck-sim boot | unidades systemd, aprovisionamiento, puertas de estado del actualizador y trabajo con múltiples patos. | Validación de hardware eléctrico o mecánico. |
Prepara dos copias locales de las revisiones fijadas.
Coloque ambos repositorios en el mismo directorio principal o configure DUCK_SIM_RL en la copia local del repositorio de RL. El lanzador espera un entorno virtual RL que contenga duck-body y ONNX Runtime. La creación de demonios de Rust también requiere la cadena de herramientas declarada por el repositorio del robot.
git clone https://github.com/pollen-robotics/microduck.git
git -C microduck checkout --detach e90389492bd4da42f60da343983e50cecd43b54b
git clone https://github.com/pollen-robotics/microduck_rl.git
git -C microduck_rl checkout --detach cb70b792312d559a4da09064d92009079671815f
cd microduck_rl
uv syncEl iniciador oficial tiene por defecto ~/Pollen/microduck_rl. Si sus carpetas están en otro lugar, apúntelas a la ruta RL absoluta en lugar de mover una copia local del repositorio existente. Lanzador oficial de simulación de pato ↗
cd /absolute/path/to/microduck
DUCK_SIM_RL=/absolute/path/to/microduck_rl scripts/duck-sim
scripts/duck-sim status
scripts/duck-sim drive
scripts/duck-sim ctl health
scripts/duck-sim realtime
scripts/duck-sim downLea la salud antes de juzgar el movimiento.
drive pide una corta caminata hacia adelante. Es una prueba de humo, no un punto de referencia de la marcha. Guarde status, ctl health, realtime, log y simlog juntos. Un mundo que funciona por debajo del tiempo real cambia el momento visto por la política; la guía oficial recomienda menos patos, menos cámaras y luego un espectador sin cabeza cuando el circuito no puede mantenerse saludable.
scripts/duck-sim status
scripts/duck-sim realtime
scripts/duck-sim ctl health --json
scripts/duck-sim log
scripts/duck-sim simlogUtilice el modo contenedor solo cuando responda una pregunta de contenedor.
scripts/duck-sim boot 2 inicia dos patos con sus demonios en contenedores systemd reales y necesita sudo, systemd-nspawn y mmdebstrap. Es valioso para el trabajo de actualización, propiedad de unidades y orden de reinicio. Para un cambio de política o IPC, el modo simple se inicia más rápido y elimina la configuración no relacionada.
Mantenga el límite del hardware en el informe.
El cuerpo simulado puede exponer fallas de demonios y clientes. No puede validar el bus Dynamixel, la radio Bluetooth, el ISP de la cámara, la NPU, el codificador de hardware, la entrega de energía, las piezas impresas o el contacto real con el piso. Etiquete un resultado aprobado como "simulación de demonio en estas revisiones" y luego haga un plan de hardware por separado si la pregunta cruza ese límite.
¿Qué te gustaría entender a continuación?
Mantenga juntos la fuente, su entorno y sus observaciones.
Fuentes y fecha de revisión
Fuentes comprobadas el 23 de septiembre de 2026 · Fuente revisada