# Jumper (Robot)

> Source: https://aiwiki.ai/wiki/jumper_robot
> Updated: 2026-10-13
> Categories: Reinforcement Learning, Robot Hardware, Robotics
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "Jumper (Robot)." aiwiki.ai, 13 Oct 2026. https://aiwiki.ai/wiki/jumper_robot
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

**Jumper** is a crab-inspired [robot](https://aiwiki.ai/wiki/robot) from KingKong Robotics with 22 [degrees of freedom](https://aiwiki.ai/wiki/degrees_of_freedom). Its public software project provides tools for training motion, replaying policies, exporting controllers, and creating appearances and scenes with an AI coding assistant. The software is published in the `KingKongRobotics/jumper` repository, with a separate `jumper-design` project for appearance and scene creation.[1]

The project uses [reinforcement learning](https://aiwiki.ai/wiki/reinforcement_learning) and [MuJoCo](https://aiwiki.ai/wiki/mujoco) simulation. Its documentation separates implemented training and export tools from unfinished hardware validation: as checked on October 13, 2026, the repository's RKNN inference path had not been verified on the robot board, and its controller loop had not driven the live motor bus.[4]

## Robot structure and advertised specifications

The published MuJoCo model has six limbs. The left and right front limbs each have five articulated joints, including a finger joint; the four middle and rear limbs each have three. These make 22 articulated joints in total. The model also includes meshes for a display module, time-of-flight sensor, and camera. These are descriptions of the published simulation asset, not an independent inspection of delivered hardware.[3]

KingKong's product page gives the following specifications. The page qualifies them as subject to official product documentation, test conditions, and delivered configuration; they should be read as manufacturer specifications rather than independent benchmark results.[2]

| Property | Manufacturer specification |
| --- | --- |
| Motion structure | Crab-style multi-leg |
| High-torque tactile servos | 22 |
| Weight | 1.8 kg |
| Top speed | >= 0.5 m/s |
| Battery life | Approx. 2 hours |
| Maximum jump height | >= 400 mm |
| Maximum grasping load | 1 kg |

## Learning and simulation

Jumper's training framework builds on mjlab and rsl_rl. It uses MuJoCo Warp as its primary GPU physics backend, with native MuJoCo available for CPU training. The project guide states that task configurations, reward definitions, and PPO code are shared across these backends.[4]

PPO, or proximal policy optimization, is a family of policy-gradient methods that alternates collecting interactions with the environment and optimizing a surrogate objective. The original 2017 research evaluated PPO on simulated robotic locomotion as well as other tasks.[6] Jumper's own PPO configuration constructs actor and critic networks, a clipped PPO objective, and optional symmetry augmentation. Hyperparameters belong to individual tasks rather than one mandatory configuration for every motion.[5]

MuJoCo's original research describes an engine for model-based control with articulated dynamics, contact handling, and XML-based models.[7] This explains the simulation technology underneath Jumper; it does not establish that a Jumper policy transfers successfully to physical hardware.

The documented tutorial trains separate policies for distinct motions:[8]

| Task | Training objective |
| --- | --- |
| `jumper.tripod` | Track commanded velocity with a tripod gait |
| `jumper.jump` | Learn residual corrections to a recorded jump motion |
| `jumper.dance` | Follow a recorded choreography |

The jump configuration runs at 200 Hz and adds the policy's output to reference joint angles. Its source explicitly records a simulation-to-hardware difference: the jump uses a proportional gain of 20 for reference tracking, while the real robot is described as using 10. The configuration therefore should not be treated as proof of matching hardware behavior.[14]

## Training, replay, and export workflow

The project guide requires Python 3.10-3.13 and an editable installation of the repository. GPU training uses an appropriate GPU build of PyTorch; CPU training can select the native backend. A documented CPU example is:[4]

```bash
python scripts/train.py --task jumper.tripod --backend native --device cpu --num_envs 64
```

The main entry points separate learning from replay, policy export, and packaging.[9]

| Entry point | Purpose |
| --- | --- |
| `scripts/train.py` | Train a task and save checkpoints |
| `scripts/play.py` | Replay a trained policy in simulation |
| `scripts/export.py` | Produce `actor.onnx`, `layout.json`, a README, and a checkpoint copy |
| `scripts/deploy.py` | Build and package policies with the shared controller |

The tutorial stores checkpoints under `logs/<model>/<task>/<timestamp>/`, with files named `model_<N>.pt`. Training supports resuming, while replay can select the latest checkpoint. Reference-guided tasks also export the recorded trajectory required by their policy.[8]

The manual describes export checks for observation compatibility, joint layout, checkpoint configuration, and numerical agreement between the PyTorch policy and its [ONNX](https://aiwiki.ai/wiki/onnx) export. It also distinguishes a task checkpoint from the packaged controller needed by a deployment host.[9]

## Controller and motion packages

A motion package contains a finite-state controller and one policy per mode. The `.app` format is a ZIP archive with `bundle.json` at its root. The bundle specifies which runtime and model format each host uses:[10]

| Host | Runtime and model format |
| --- | --- |
| Browser | WebAssembly controller and ONNX policies |
| Local `play --app` simulation | Platform-specific controller extension and ONNX policies |
| Robot board | Board controller executable and RKNN policies |

The controller builds observations, runs a policy, and converts actions into joint targets. It matches joints by name rather than assuming a policy's joint order is the same as the robot's wire order. Locomotion and jump policies use 20 joints, excluding the finger joints, while the dance policy uses all 22.[11]

The package includes reference frames for comparing host inputs and outputs and a generated control manual. Packaging checks require the expected files and validate the bundle schema before creating the archive.[10] Controller holding states keep the current or home pose without running a policy; documented failure cases include missing feedback or excessive tilt. A missing model can be reported as a stub, and reference-residual modes are prevented from running on that stub.[11]

## Hardware validation boundary

The deployment documentation targets conversion from ONNX to RKNN for a Rockchip RK3576 NPU. It reports read-only checks of the board's runtime libraries and joint names, but lists two open validation gaps: actual `rknn_run` inference on the NPU and operation of the controller against the motor bus.[12]

The intended controller publishes at 1 kHz while individual policies have their own inference rates. The documentation says that this timing behavior has not been measured on the live bus and that the controller does not implement real-time scheduling, memory locking, or jitter accounting. Passing a host-side bundle check consequently does not certify [sim-to-real transfer](https://aiwiki.ai/wiki/sim_to_real_transfer) or reliable physical motion.[12]

## Appearance and scene creation

The separate design workflow produces `.skin` appearance packages and `.map` scene packages. It requires its own checkout and environment. Appearance rendering and package validation are distinct from printing a shell or testing its physical fit.[13]

Imported maps can be used to replay a trained policy while retaining the training task's robot and controller. They cannot be used for training because their terrain and props are not replicated across parallel environments. The training project also has no direct `.skin` importer. Built-in training scenes remain available.[13]

## Licensing

Maintainer-owned project materials are published under the Apache License 2.0. Third-party materials keep their own terms, and generated outputs do not automatically inherit the repository's license. This distinction applies to the software and materials in the repository; it is not a claim that every design or output has identical reuse rights.[1]

## References

1. KingKong Robotics. [Jumper repository and README](https://github.com/KingKongRobotics/jumper). Accessed October 13, 2026.
2. KingKong. [Jumper product page](https://kingkong.tech/en/jumper). Manufacturer specifications. Accessed October 13, 2026.
3. KingKong Robotics. [`assets/jumper/jumper.xml`](https://github.com/KingKongRobotics/jumper/blob/main/assets/jumper/jumper.xml). Published MuJoCo robot model. Accessed October 13, 2026.
4. KingKong Robotics. [Jumper project guide](https://github.com/KingKongRobotics/jumper/blob/main/docs/PROJECT_GUIDE.md). Setup, backends, and implementation status. Accessed October 13, 2026.
5. KingKong Robotics. [`tasks/jumper/common/ppo.py`](https://github.com/KingKongRobotics/jumper/blob/main/tasks/jumper/common/ppo.py). Task-specific PPO configuration. Accessed October 13, 2026.
6. Schulman, John, Filip Wolski, Prafulla Dhariwal, Alec Radford, and Oleg Klimov. [Proximal Policy Optimization Algorithms](https://arxiv.org/abs/1707.06347). arXiv:1707.06347, 2017.
7. Todorov, Emanuel, Tom Erez, and Yuval Tassa. [MuJoCo: A physics engine for model-based control](https://ieeexplore.ieee.org/document/6386109). IEEE/RSJ International Conference on Intelligent Robots and Systems, 2012, pp. 5026-5033. DOI: 10.1109/IROS.2012.6386109.
8. KingKong Robotics. [Jumper training tutorial](https://github.com/KingKongRobotics/jumper/blob/main/docs/TUTORIAL.md). Training, replay, policy export, and bundle workflow. Accessed October 13, 2026.
9. KingKong Robotics. [Jumper manual](https://github.com/KingKongRobotics/jumper/blob/main/docs/USAGE.md). Entry points, checkpoints, and export checks. Accessed October 13, 2026.
10. KingKong Robotics. [Motion bundle format](https://github.com/KingKongRobotics/jumper/blob/main/deploy/BUNDLE.md). Bundle contents, host contracts, and schema checks. Accessed October 13, 2026.
11. KingKong Robotics. [Shared controller documentation](https://github.com/KingKongRobotics/jumper/blob/main/deploy/fsm/README.md). Observations, joint-name matching, and controller states. Accessed October 13, 2026.
12. KingKong Robotics. [Deployment overview](https://github.com/KingKongRobotics/jumper/blob/main/deploy/README.md). Board checks and open hardware-validation work. Accessed October 13, 2026.
13. KingKong Robotics. [Train and Design workflows](https://github.com/KingKongRobotics/jumper/blob/main/docs/WORKFLOWS.md). Independent environments and integration boundaries. Accessed October 13, 2026.
14. KingKong Robotics. [`tasks/jumper/jump/env_cfg.py`](https://github.com/KingKongRobotics/jumper/blob/main/tasks/jumper/jump/env_cfg.py). Reference-guided jump configuration. Accessed October 13, 2026.