Jumper: Cómo Entrenar un Robot Cangrejo en Simulación en 2026

Hola HaWkers, un robot con forma de cangrejo apareció entre los proyectos de robótica más comentados: Jumper, de KingKong Robotics. Su documentación describe un cuerpo con 22 grados de libertad y un conjunto abierto de herramientas para crear su apariencia, entrenar movimientos y construir escenas. Hay, sin embargo, un detalle más importante que su aspecto: el propio equipo distingue lo que funciona en el simulador de lo que todavía necesita demostrarse en el dispositivo físico.

¿Te gustaría experimentar con robótica sin comprar un robot y sin confundir una animación convincente con una prueba de hardware? En esta guía recorreremos el flujo reproducible del proyecto, veremos cómo se entrena una política de movimiento y estableceremos comprobaciones antes de confiar en una demostración. Así podrás separar lo que observaste realmente de lo que todavía es una hipótesis sobre el mundo físico.

Qué ofrece realmente Jumper

El repositorio principal reúne el modelo del robot, tareas de entrenamiento, scripts de ejecución y un controlador que se puede empaquetar para distintos entornos. Según la guía oficial del proyecto, el entrenamiento utiliza MuJoCo, MuJoCo Warp, mjlab y rsl_rl. Su objetivo es producir una política: un programa que recibe observaciones sobre el estado del robot y elige acciones para sus motores. Dentro de la simulación, esto permite ensayar locomoción y otros movimientos antes de pensar en el bus real de servomotores.

Existe además un proyecto separado, jumper-design, dedicado a las apariencias y los escenarios. Sus archivos .skin y .map cumplen funciones diferentes de las de una política de control. Una apariencia visual no cambia por sí sola el comportamiento del robot, y un escenario importado para reproducir una escena no se convierte automáticamente en un entorno de entrenamiento. La diferencia evita una interpretación frecuente de los vídeos de demostración: ver al robot en un escenario atractivo no demuestra que esa secuencia se entrenó allí ni que se ejecutó en el equipo físico.

La ficha de hardware publicada por el equipo especifica dimensiones de 400 × 400 × 200 mm, un procesador Rockchip RK3576, sensores y 22 servomotores táctiles. Son datos que los autores declaran para su hardware; no son requisitos para estudiar el software. Si solo quieres explorar el proyecto, no necesitas tener esos componentes en tu mesa. Puedes comenzar con el modelo digital y un ordenador capaz de ejecutar Python y el simulador.

Por qué la simulación precede al robot físico

Entrenar mediante ensayo y error directamente en una máquina con articulaciones, batería y piezas móviles consume tiempo y puede dañar componentes. En un simulador, una tarea define observaciones, acciones, condiciones de finalización y una función de recompensa. La política aprende a maximizar esa recompensa durante muchas tentativas. Aun así, un movimiento estable en el modelo no tiene por qué ser igual de estable sobre un suelo real: cambian la fricción, las holguras mecánicas, los retrasos y las lecturas de los sensores.

Jumper resulta interesante porque expone la transición entre ambos mundos como parte del proceso. El tutorial oficial cubre entrenamiento, reproducción, exportación y empaquetado. También advierte que un orden incorrecto de articulaciones o una escala distinta en el control pueden generar un programa que se ejecuta sin un error aparente, pero que mueve mal el robot. Por eso, la validación debe examinar los resultados y los contratos de control, además del código de salida del proceso.

Si sigues el debate más amplio sobre modelos que representan entornos físicos, este experimento se relaciona con el artículo sobre world models y simulación del mundo real. Aquí el alcance es más concreto: una tarea de locomoción, un simulador específico y límites documentados para transferir el movimiento al hardware.

Prepara un entorno que puedas reproducir

La guía de instalación del proyecto pide Python de la versión 3.10 a la 3.13. Distingue entre los equipos con NVIDIA, que pueden seguir la ruta de GPU, y los demás, que usan MuJoCo nativo sobre CPU. Los comandos siguientes crean un entorno aislado e instalan las dependencias del propio repositorio para una primera prueba con CPU. Hazlo en una copia de trabajo dedicada: descargar bibliotecas de aprendizaje automático puede ocupar bastante espacio.

# Crea y activa un entorno Python aislado dentro del proyecto.
git clone https://github.com/KingKongRobotics/jumper.git
cd jumper
python3 -m venv .venv
source .venv/bin/activate

# Instala PyTorch para CPU y el paquete local en modo editable.
python -m pip install torch torchvision
python -m pip install -e .

No sustituyas el último comando por una instalación independiente de mjlab o rsl_rl. El proyecto mantiene copias propias de esas bibliotecas dentro de rl/, y el modo editable configura las rutas que esperan los scripts. Si tu equipo tiene una GPU NVIDIA, sigue la sección específica del documento oficial para elegir la versión adecuada de PyTorch. Copiar una instrucción de instalación preparada para otra tarjeta podría dejarte un entorno que importa las bibliotecas correctamente y solo falla cuando inicializa CUDA.

Antes de iniciar el entrenamiento, comprueba que se puede cargar la lista de tareas y que el simulador está disponible. De acuerdo con la documentación, el primer comando se diseñó para enumerar las tareas sin importar todo el conjunto de dependencias pesadas. El segundo verifica que la instalación local de MuJoCo funciona. Investigar un fallo en este punto es más sencillo que hacerlo después de descargar paquetes y generar registros de una ejecución interrumpida.

# Comprueba el registro de tareas antes de dedicar tiempo al entrenamiento.
python scripts/train.py --list

# Confirma que puedes importar la instalación local de MuJoCo.
python -c 'import mujoco; from mujoco import rollout; print(mujoco.__version__)'

Entrena una tarea pequeña e interpreta el resultado

El repositorio incluye tareas con nombres como jumper.flat, jumper.tripod, jumper.jump y jumper.dance. Para empezar en un ordenador sin CUDA, la prueba rápida recomendada por los autores emplea el backend nativo, CPU, 64 entornos paralelos y tres iteraciones. La finalidad de esa prueba es confirmar que el flujo básico se ejecuta. Tres iteraciones no enseñan una marcha fiable ni demuestran la calidad de la política resultante.

# Ejecuta una prueba breve del flujo en CPU, sin abrir el visor.
python scripts/train.py --task jumper.flat \
  --backend native --device cpu --num_envs 64 \
  --max-iterations 3 --headless

Comprueba el backend que aparece al comienzo, las iteraciones completadas y la ausencia de errores. La recompensa media podría empezar con un valor negativo; por sí solo, eso no significa que la instalación haya fallado. Si el proceso termina por falta de memoria, reduce --num_envs: en el backend nativo, cada entorno mantiene sus propias estructuras de simulación. El número de entornos expresa la capacidad que le pides a la máquina, no una puntuación de calidad de la política.

Después de la prueba breve, puedes entrenar una tarea de locomoción durante más tiempo y reproducir un checkpoint. La guía del proyecto usa jumper.tripod como ejemplo de entrenamiento y scripts/play.py para la reproducción. La política aprendida depende de la configuración, la semilla, el hardware y la duración. Evita copiar una cifra de recompensa obtenida en otra máquina como si fuera un objetivo universal para tu experimento.

# Entrena una marcha en CPU; ajusta los entornos a la memoria disponible.
python scripts/train.py --task jumper.tripod \
  --backend native --device cpu --num_envs 64

# Reproduce la tarea con el checkpoint generado por el proyecto.
python scripts/play.py --task jumper.tripod

Qué medir además de una animación atractiva

Una demostración visual ayuda a observar el movimiento, pero no resume el comportamiento de una política. Empieza por verificar si el robot se mantiene estable en distintas superficies y condiciones iniciales, si se recupera de pequeñas perturbaciones y si sus acciones respetan los límites previstos. Anota la configuración de la tarea, el checkpoint y el escenario de reproducción. Sin esos datos será difícil comparar dos ejecuciones o descubrir si un cambio mejoró el sistema o solo produjo un vídeo favorable.

El tutorial de Jumper recomienda leer el resultado de cada etapa, incluidos los mensajes de empaquetado. El flujo incluye cuadros de referencia para comparar la salida de una política entre entornos. Si las observaciones o los objetivos no coinciden, el problema podría estar en el orden de las articulaciones, la escala de control o la ruta de inferencia. Un paquete que se abre en el navegador y responde al teclado todavía necesita superar esas verificaciones antes de conectarse a un controlador físico.

Puedes crear una breve ficha del experimento con la información que ya tienes: tarea, backend, número de entornos, máquina utilizada, checkpoint y criterios observados. No inventes una tasa de éxito si no realizaste una batería de pruebas. Escribe «no medido» cuando falte evidencia; resulta más útil que convertir una impresión visual en un porcentaje. Dentro de un equipo, esta disciplina impide que un vídeo de demostración se transforme en una promesa de producto sin fundamento.

Apariencias, escenas y paquetes de movimiento son elementos distintos

jumper-design acepta descripciones de apariencia y escenario, pero un archivo visual debe verificarse como paquete. La guía rápida oficial proporciona instrucciones para instalar el proyecto, descargar recursos con Git LFS y validar un mapa de ejemplo. El procedimiento siguiente es independiente del entrenamiento de políticas: comprueba la estructura de un archivo .map que ya está dentro del repositorio de diseño.

# Prepara las herramientas de apariencia y escenarios en otro directorio.
git lfs install
git clone https://github.com/KingKongRobotics/jumper-design.git
cd jumper-design
git lfs pull
python3 -m pip install -e '.[sim,dev]'

# Valida la estructura y compatibilidad de un mapa incluido en el proyecto.
python scripts/shellflow.py verify-package \
  library/maps/park-pump-track.map \
  --profile robots/jumper/profile.json

El verificador examina la declaración del paquete, su integridad y su compatibilidad con el perfil indicado. Según la guía, puedes añadir --mujoco para probar si se carga en el simulador. Aun así, ese resultado no sustituye una inspección visual ni una prueba de encaje físico. Trata cada fase como una evidencia distinta: que el paquete sea válido, que el modelo cargue, que la escena se vea correctamente y que el robot sea seguro son cuatro afirmaciones diferentes.

El repositorio principal también describe paquetes .app para políticas entrenadas, controles y archivos de referencia. No confundas la extensión con una aplicación convencional para móviles. En este flujo representa un archivo transportable que debe construirse y verificarse de acuerdo con el contrato del proyecto. El tutorial muestra etapas específicas para el navegador y la placa, con dependencias adicionales de Rust y herramientas de compilación. Conviene seguirlo completo cuando pases del laboratorio local a la distribución.

Dónde termina la evidencia sobre el hardware

Esta es la distinción principal para evaluar Jumper con rigor. El estado del proyecto documentado por el equipo indica que el entrenamiento, la simulación, la exportación y las verificaciones de paquetes en el ordenador están implementados. Ese mismo texto señala que la inferencia RKNN aún no se había verificado en la placa y que el bucle del controlador no había activado el bus de motores en vivo. Por tanto, el repositorio no demuestra que cualquier política entrenada ya funcione en el robot físico.

La documentación de despliegue propone comprobaciones antes de tocar el bus, entre ellas una ejecución en seco y la comparación con cuadros de referencia. Son barreras útiles, pero no equivalen a una certificación universal de seguridad. Incluso con una comparación numérica consistente, la máquina física puede caerse, chocar, calentarse o superar sus límites de energía: una reproducción en pantalla no elimina esos riesgos. Si tienes acceso al prototipo, sigue las instrucciones de hardware de sus responsables y realiza las pruebas en un entorno controlado.

Para quienes no tienen el robot, esta limitación no reduce el valor educativo del proyecto. Al contrario: la separación explícita entre simulación y mundo físico permite formular mejores preguntas. ¿Qué parte es un modelo? ¿Qué parte se ha medido? ¿Qué se ejecutó en el navegador, en el ordenador y en la placa? En robótica, saber reconocer esas fronteras es tan importante como generar un movimiento interesante.

Una ruta responsable para continuar

Empieza con una tarea sencilla y registra el entorno en el que la ejecutaste. Después cambia solo una variable cada vez: el número de entornos, el tiempo de entrenamiento o la configuración de la escena. Compara el comportamiento de forma repetible y conserva el checkpoint utilizado. Cuando la locomoción parezca estable, lee el tutorial de empaquetado y comprueba sus pruebas de referencia antes de plantearte un despliegue. Así tendrás una secuencia de evidencias, además de comandos que finalizaron sin errores.

El mismo método sirve para otros proyectos de robótica abierta. Una licencia accesible y un vídeo atractivo despiertan interés, pero la pregunta técnica sigue siendo: ¿qué capacidades se reprodujeron, en qué entorno y con qué límites conocidos? Jumper documenta un camino para responder sin comprar hardware desde el primer día. Aprovéchalo para experimentar, aprender y comunicar los resultados con precisión.

¡Vamos con todo! 🦅

📚 ¿Quieres Seguir lo Que Viene Por Delante?

Este artículo trató Jumper y el entrenamiento de movimientos en simulación, pero el ecosistema cambia cada semana y no todo llega a convertirse en un artículo aquí.

En X comparto lo que estoy probando, los detalles de mis proyectos y las novedades que aparecen antes de convertirse en una publicación del blog.

Sígueme Allá

👉 Seguir a @jeffbruchado en X

💡 Contenido diario sobre desarrollo, carrera y las herramientas que uso de verdad