Jumper (Robot)

Jumper is a crab-inspired robot from KingKong Robotics with 22 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 and 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]

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]

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]

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]

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 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]

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 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. ^1 ^2KingKong Robotics. Jumper repository and README. Accessed October 13, 2026.
2. ^KingKong. Jumper product page. Manufacturer specifications. Accessed October 13, 2026.
3. ^KingKong Robotics. `assets/jumper/jumper.xml`. Published MuJoCo robot model. Accessed October 13, 2026.
4. ^1 ^2 ^3KingKong Robotics. Jumper project guide. Setup, backends, and implementation status. Accessed October 13, 2026.
5. ^KingKong Robotics. `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. arXiv:1707.06347, 2017.
7. ^Todorov, Emanuel, Tom Erez, and Yuval Tassa. MuJoCo: A physics engine for model-based control. IEEE/RSJ International Conference on Intelligent Robots and Systems, 2012, pp. 5026-5033. DOI: 10.1109/IROS.2012.6386109.
8. ^1 ^2KingKong Robotics. Jumper training tutorial. Training, replay, policy export, and bundle workflow. Accessed October 13, 2026.
9. ^1 ^2KingKong Robotics. Jumper manual. Entry points, checkpoints, and export checks. Accessed October 13, 2026.
10. ^1 ^2KingKong Robotics. Motion bundle format. Bundle contents, host contracts, and schema checks. Accessed October 13, 2026.
11. ^1 ^2KingKong Robotics. Shared controller documentation. Observations, joint-name matching, and controller states. Accessed October 13, 2026.
12. ^1 ^2KingKong Robotics. Deployment overview. Board checks and open hardware-validation work. Accessed October 13, 2026.
13. ^1 ^2KingKong Robotics. Train and Design workflows. Independent environments and integration boundaries. Accessed October 13, 2026.
14. ^KingKong Robotics. `tasks/jumper/jump/env_cfg.py`. Reference-guided jump configuration. Accessed October 13, 2026.