Jumper: How to Train a Crab Robot in Simulation in 2026

Hello HaWkers, a crab-shaped robot has surfaced among trending robotics projects: Jumper by KingKong Robotics. Its documentation describes a body with 22 degrees of freedom and an open set of tools for designing appearances, training movements, and assembling scenes. The decisive detail is elsewhere: the team itself distinguishes what already works in the simulator from what still needs to be verified on the physical machine.

Would you like to experiment with robotics without buying a robot, and without mistaking a convincing animation for a hardware test? In this guide, we will follow the project's reproducible workflow, understand how a movement policy is trained, and define checks to make before trusting a demonstration.

What Jumper Actually Provides

The main repository contains the robot model, training tasks, execution scripts, and a controller that can be packaged for different environments. According to the official project guide, training uses MuJoCo, MuJoCo Warp, mjlab, and rsl_rl. The aim is to produce a policy: a program that receives observations about the robot's state and chooses actions for its motors. In simulation, this makes it possible to rehearse locomotion and other movements before considering the real servo bus.

There is also a separate project, jumper-design, for appearances and scenes. Its .skin and .map files play different roles from a control policy. A visual skin does not magically change the robot's behavior, and a scene imported for playback does not automatically become a training environment. That distinction prevents a common misreading of demo videos: seeing a robot in a polished scene does not prove that the same sequence was trained in that scene or executed on the physical device.

The team's published hardware sheet specifies dimensions of 400 × 400 × 200 mm, a Rockchip RK3576 processor, sensors, and 22 tactile servos. Those are the authors' stated specifications for the hardware. If you only want to study the software, you do not need any of those components on your desk. Your starting point is the digital model and a computer that can run Python and the simulator.

Why Simulation Comes Before the Physical Robot

Training by trial and error directly on a machine with joints, a battery, and moving parts takes time and can damage components. In a simulator, a task defines observations, actions, termination conditions, and a reward function. A policy learns to maximize that reward over many attempts. There is no guarantee that a movement stable in the model will be equally stable on a real floor: friction, mechanical play, delays, and sensor readings all change.

Jumper is interesting because it exposes the transition between these worlds as part of the workflow instead of hiding the problem. The official tutorial covers training, playback, export, and packaging. It warns that an incorrect joint order or a differently scaled control signal can produce a program that runs without an apparent error but moves the robot incorrectly. Validation therefore needs to examine outcomes and control contracts, not just the process exit code.

If you follow the broader discussion of models that represent physical environments, connect this experiment to my article on world models and real-world simulation. Here, the focus is more concrete: one locomotion task, a particular simulator, and documented limits on transfer to hardware.

Set Up an Environment You Can Reproduce

The project's installation guide calls for Python 3.10 through 3.13. It distinguishes NVIDIA machines, which can use the GPU path, from other machines, which use native MuJoCo on the CPU. The commands below create an isolated environment and install the repository's own dependencies for an initial CPU experiment. Do this in a dedicated working copy; machine learning library downloads can be large.

# Create and activate an isolated Python environment in the project.
git clone https://github.com/KingKongRobotics/jumper.git
cd jumper
python3 -m venv .venv
source .venv/bin/activate

# Install CPU PyTorch and the local package in editable mode.
python -m pip install torch torchvision
python -m pip install -e .

Do not replace the last command with a standalone installation of mjlab or rsl_rl. The project maintains its own copies of these libraries under rl/, and editable mode configures the paths expected by its scripts. If your machine has an NVIDIA GPU, follow the dedicated branch of the official document to choose the right PyTorch version. Copying an installation command for another card can create an environment that imports its libraries but fails only when CUDA initializes.

Before training, check that the task list loads and that the simulator is accessible. According to the documentation, the first command was designed to list tasks without importing the entire set of heavy dependencies. The second checks the local MuJoCo installation. Failures at this point are easier to diagnose than training interrupted after downloading packages and creating logs.

# Check the task registry before spending time on training.
python scripts/train.py --list

# Confirm that the installed MuJoCo package can be imported.
python -c 'import mujoco; from mujoco import rollout; print(mujoco.__version__)'

Train a Small Task and Read the Result

The repository provides tasks with names such as jumper.flat, jumper.tripod, jumper.jump, and jumper.dance. To begin on a machine without CUDA, the authors' recommended smoke test uses the native backend, CPU, 64 parallel environments, and three iterations. This test confirms that the basic pipeline runs; three iterations do not teach a reliable gait or demonstrate policy quality.

# Run a short CPU pipeline test without opening a viewer.
python scripts/train.py --task jumper.flat \
  --backend native --device cpu --num_envs 64 \
  --max-iterations 3 --headless

Watch for the backend reported at startup, completed iterations, and the absence of an error. The mean reward may start negative; that alone does not mean the installation failed. If the process runs out of memory, reduce --num_envs: with the native backend, each environment keeps its own simulation structures. The environment count reflects your machine's capacity, not a quality score.

After the short test, you can run a locomotion task for longer and replay a checkpoint. The project guide uses jumper.tripod as a training example and scripts/play.py for playback. A learned policy depends on its configuration, seed, hardware, and training duration. Do not copy a reward value from another machine as though it were a universal target.

# Train a gait on CPU; adjust the environment count to available memory.
python scripts/train.py --task jumper.tripod \
  --backend native --device cpu --num_envs 64

# Replay the task using a checkpoint produced by the project workflow.
python scripts/play.py --task jumper.tripod

What to Measure Beyond a Good-Looking Animation

A visual demonstration is useful, but it does not summarize a policy's behavior. First check whether the robot remains stable across different surfaces and initial conditions, recovers from small disturbances, and keeps its actions within expected limits. Record the task configuration, the checkpoint used, and the playback scene. Without this information, comparing two runs and finding out whether a change helped is difficult. A favorable video frame is not a substitute for a repeatable result.

The Jumper tutorial recommends reading the result of every stage, including packaging messages. Its workflow includes reference frames that let you compare a policy's output across environments. When observations or targets diverge, the cause may be joint ordering, control scaling, or the inference path. A package that opens in a browser and responds to keyboard input still needs these checks before anyone connects it to a physical controller.

You can keep a small experiment record using information already available to you: task, backend, number of environments, machine, checkpoint, and observed criteria. Do not invent a success rate if you have not run a set of tests. Write “not measured” when evidence is missing; that is more useful than turning a visual impression into a percentage. For a team, this discipline helps keep a demo video from becoming a product promise.

Appearances, Scenes, and Movement Packages Are Distinct

jumper-design accepts appearance and scene descriptions, but a visual file still needs to be checked as a package. The official quickstart gives commands to install the project, download assets through Git LFS, and validate an example map. The example below follows a separate path from policy training: it checks the structure of an existing .map file in the design repository.

# In another directory, set up the appearance and scene tools.
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]'

# Check the structure and compatibility of a map included in the project.
python scripts/shellflow.py verify-package \
  library/maps/park-pump-track.map \
  --profile robots/jumper/profile.json

This verifier examines the package declaration, integrity, and compatibility with the specified profile. You can add --mujoco to test loading it in the simulator, as the guide describes. Even then, the result does not replace visual inspection or a physical fit test. Treating these stages as different kinds of evidence matters: a valid package, a loadable model, a readable scene, and a safe robot are four distinct claims.

The main repository also describes .app packages for trained policies, controls, and reference files. Do not confuse the extension with a conventional mobile app. In this workflow, it represents a portable archive that has to be built and checked against the project's contract. The tutorial shows dedicated steps for the browser and the board, with additional Rust and build tool dependencies. Follow those steps in full when moving from a local lab experiment to distribution.

Where the Hardware Evidence Ends

This is the distinction that matters most when assessing Jumper honestly. The team's documented project status says that training, simulation, export, and host-side package checks are implemented. The same document records that RKNN inference had not yet been verified on the board and that the controller loop had not driven the live motor bus. It would therefore be inaccurate to describe the repository as proof that every trained policy already runs on the physical robot.

The deployment documentation proposes checks before touching the bus, including dry runs and comparisons against reference frames. These are useful safeguards, but they are not universal safety certification. Even a consistent numerical comparison cannot remove the physical risks of falls, collisions, overheating, and energy limits. Anyone with access to the prototype should follow the maintainers' hardware instructions and test in a controlled setting.

If you do not have the robot, this does not reduce the project's educational value. Quite the opposite: the explicit separation of simulation from the physical world helps you ask better questions. Which part is a model? Which part is a measurement? What was executed in the browser, on the computer, and on the board? In robotics, locating these boundaries matters as much as generating an interesting movement.

A Responsible Path Forward

Start with a simple task and record the environment in which it ran. Then change only one variable at a time: environment count, training duration, or scene configuration. Compare behavior in a repeatable way and save the checkpoint you used. Once locomotion looks stable, read the packaging tutorial and check its reference tests before considering deployment. You will have a sequence of evidence rather than a collection of commands that happened to exit without an error.

The same approach applies to other open robotics projects. An accessible license and an engaging video spark interest, but the technical question remains: which capabilities have been reproduced, in which environment, and with which known limits? Jumper's documentation offers a path to answer that question without buying hardware at the outset. Use that path to experiment, learn, and report your results accurately.

Let's go! 🦅

📚 Want to Keep Up With What Is Coming?

This article covered Jumper and movement training in simulation, but the ecosystem changes every week, and not every development becomes an article here.

On X, I share what I am testing, the work behind my projects, and new developments before they become blog posts.

Follow Me There

👉 Follow @jeffbruchado on X

💡 Daily content about development, careers, and the tools I actually use