KingKong Robotics open-sourced Jumper, a 22-DoF crab robot, and with it a raffle: the BE UNLIMITED Crab Robot Challenge runs 2026-09-30 through 2026-11-30, and they pick 100 outstanding open-source projects to receive an actual Jumper. Round 1 entries close October 30, there are three to four selection rounds, and the page says enter earlier for more chances to win.
The hardware spec is what makes the thing interesting to simulate rather than to print: 400 by 400 by 200 mm, 1.8 kg, 22 tactile servos, top speed at least half a metre per second, jump height at least 400 mm, grasp load 1 kg, about two hours of battery. The robot in the simulator is 13 cm tall, and that number turned out to be the whole scaling problem later on.
What an entry actually is
There is no entry form. An entry is a video longer than 15 seconds posted on X or YouTube, with the topics #Jumper, #CrabRobot and #OpenSourceRobot and a mention of the official account. Entries get collected across platforms, and the judging is 60% audience response and 40% expert review. The dimensions are appearance, playfulness and usefulness, and they say excellence in any one is enough.
That 60% number is the load-bearing fact. The contest is not graded on whether the simulation is technically excellent, it’s graded on whether people looked at the clip. So the work that pays off is concept and framing, not solver accuracy, and I built the pipeline around that instead of around the physics.
The rules also carry two traps. Originality is enforced, verified plagiarism disqualifies. And music licensing is on the entrant, no pack is provided, so the soundtrack has to be something I can defend. I generate the music myself, a HeartMuLa 3B run under an Apache-2.0 model, which makes the track original by construction rather than licensed by hope.
The pipeline
I cloned the toolkit and got the training environment running, gates pass, smoke train and replay and bundle all clean. The repo ships trained policies, and I kept them as the motion source rather than inventing keyframes: nine dance and gesture behaviors at first, then jump and posture, eleven total, checkpoints at model_2300 for dance, model_1999 for the dance variants, model_999 for gestures, model_3100 for jump, model_74800 for posture.
Rendering on macOS needed the glfw backend, EGL gets rejected, and MuJoCo 3.15 on this arm64 build paints geom_rgba inverted, an exact 1 minus x. I burned a calibration pass on that, because the Miami Neon skin, white shell, pink legs, orange claws, shipped as the inverse of the palette I picked.
The scene pool is where the real learning happened. I first tried authoring custom environments, and they failed visual review repeatedly, skybox never applied, emissive materials washed out, props cropped. The pivot was to use the repo’s own authored registry scenes, beach, football, ice, swing, the ones that made their demo video watchable. Then the scale insight: the robot is 13 cm, a 1.7 m prop is thirteen times its height and gets cropped out of a 0.72 m camera, so props go at diorama scale, rings 0.34 to 0.42 m out, props 0.05 to 0.3 m tall.
Physical props came after, on the repo’s own pattern, a solid body with contact and a visual-only shell. A tree five robots tall with bark grooves and 520 drawn leaf silhouettes, a ramp with a marked gap, a seesaw on a hinge, a pushable crate at density 1500 so the crab’s shove is a trade it loses. The friction numbers matter, bark at 1.6 against the feet’s 1.2 so the grip belongs to the tree.
Rotation drives the daily posts: behavior x scene x palette x camera. The first version of that had a bug worth writing up, environment was the slowest-changing dimension, ei = i // (len(PALS) * len(WINDOWS)), so the first eighteen combinations were all the same scene and the same skin, and the account posted the same clip every day. Reproduced in code, then fixed to cycle behavior slowest and scene fastest with the palette shifted by n // 6, which gives 36 unique combos across 60 days and 19 unique picks in the first 19 with no adjacent repeats in behavior, scene or palette.
The traction research
I read the organizer’s feed and their reposts tab, then the hashtag by likes. The entry with the most engagement by a wide margin is a crab-versus-crab battle game played on a dim-sum table, 15,000 views, 270 likes, 106 reposts on a 24-second clip. My dance demos sit in single digits to low double digits. Same robot, same simulator, four orders of magnitude apart in attention.
So I built the two scenes that answer the difference, a dim-sum table and a living room, and changed what the clips are about. A performance in a void asks nothing, a crab on a sofa with a question in the caption answers a joke someone else would make in the comments. The physics keeps score, the crate gets shoved, the seesaw slams, the tree holds its own weight. One rule came out of the failure modes: props have to sit at the height the trained policy’s feet actually are, the policies walk on the floor and never learned to climb, so a table top is a set, not a surface.
Where it stands
Eleven behaviors, ten scenes, six palettes, four cameras, verified rotation, posts going daily through the 30th. Two things I’m not going to paper over. The entry count is unknown, so 100 robots over an unknown field is an odds statement I can’t finish, and the volume of distinct entries is the lever I control, which is why the rotation exists at all. And the prize rule has a hard edge, if the winner can’t be reached within five days of the official message the prize is forfeited, so the delivery half of this bet is a reply I have to answer when it comes.