`rock-climbing-robot`: The Browser Simulator That Treats Climbing Like a Robotics Problem

A Three.js climbing lab that turns text files into routes, solves reach with Jacobian inverse kinematics, and points toward MuJoCo-level physics when the visualization is not enough.

9 min read • View on GitHub • More from lgadiego001

A climbing robot hangs on a vertical wall made of discrete holds that resemble typed symbols brought into physical space. One hold is emphasized as the current target, while the rest of the route recedes as a legible grid of options, explaining that the wall is authored before it is simulated. — The wall is not just rendered. It is composed from route data, then turned into a problem the robot can solve.

Key Takeaways

This repo turns climbing into a control problem by making route authoring, reachability, and inverse kinematics part of one workflow.
Its most distinctive choice is formal Jacobian IK, which makes the simulator feel like robotics tooling instead of a casual animation demo.
The text-file wall system makes the environment editable and inspectable, so the route itself becomes a first-class input to the simulation.
The MuJoCo assets suggest the browser front end is only half the story, with higher-fidelity physics waiting behind it.

The most interesting thing about lgadiego001/rock-climbing-robot is not that it animates a climber. It is that it treats climbing like a robotics bench problem: author the wall, solve the reach, inspect the result, then push the model toward heavier physics when the browser view runs out of fidelity.

Why a Climbing Wall Starts as Text

That route-first choice changes the whole project. The wall is not hand-built hold by hold. It begins as a map, where characters encode grip types and placement, then gets turned into cloned meshes, markers, and reachable targets.

That matters because it makes the environment editable. You can change the climbing problem without redrawing the scene. For a simulator, that is a quiet superpower: the route becomes data, not scenery.

A close, blueprint-like view of a route being transformed into a wall. On one side, a compact text map and a few symbols imply authored holds; on the other, those symbols become clustered climbing grips arranged on a vertical surface, explaining how a plain route file becomes a 3D training environment. — The route begins as text, then becomes a wall the solver can reason about.

This is the project’s core loop: pick a hold, solve the joints, test feasibility, repeat.

The Robot Is Solved, Not Just Animated

This repo does not lean on the easiest-looking inverse kinematics trick. The codebase points to a formal Jacobian-based solver, which means joint movement is computed from the relationship between the end effector and the target, not guessed by a simple visual heuristic.

That is a meaningful choice. Jacobian IK is harder to implement than common web-friendly options like CCD or FABRIK, but it gives the simulator a more robotics-native feel. The robot is not merely drifting toward a hold. It is solving a constrained motion problem.

// Conceptual shape of the solver
const J = calcJacobian(jointAngles);
const error = target.subtract(endEffector);
const delta = inverseKinematics(J, error, jointLimits);
applyJointUpdate(delta);

In practice, that changes what the simulator can teach. Instead of only showing where an arm can go, it shows why a hold is reachable, why a joint saturates, and why a target can fail even when it looks close in screen space.

Why Jacobian IK Changes the Feel of the Simulator

The control loop is the point. A climber that uses Jacobian IK invites you to think in terms of gradients, constraints, and feasibility. A climber built on a simpler interpolator mostly invites you to watch motion happen.

Approach	What it optimizes	Strength	Trade-off
Jacobian IK	Joint updates that reduce end-effector error	Precise, robotics-aligned control	More math and more tuning
CCD or FABRIK	Fast positional convergence	Simple and cheap to run	Less natural for formal control analysis
Keyframed animation	Preauthored pose changes	Easy to make look good	Not a solver at all

That is why this repo feels closer to a lab than to a demo. The interesting output is not only a pose. It is an answer to a question: can this chain of joints actually reach that hold under the rules we gave it?

A Browser Front End With a Robotics Back End

The front end is deliberately light and legible. Three.js gives the scene, Tweakpane gives the controls, and the browser becomes a place to inspect the system in motion instead of a black box that spits out frames.

But the presence of MuJoCo assets changes the reading. That signals an ambition beyond visualization. It suggests the same climbing problem can move from browser ergonomics into a physics engine that is better suited to contact, dynamics, and downstream robotics work.

What This Repo Has in Common With Real Climbing Robots

The comparison set matters here. LEMUR, LORIS, SCALER, and ReachBot are serious research systems. They optimize for hardware, autonomy, and field use. This repo does something different: it optimizes for understanding.

System	Primary goal	Control style	Best known for
rock-climbing-robot	Inspectable climbing simulation	Jacobian IK in a browser workflow	Making route design and reachability easy to study
LEMUR	Planetary and field exploration	Autonomous planning with advanced grippers	Redundant limbs and microspine adhesion
LORIS	Lightweight rough-terrain climbing	Passive mechanisms with minimal complexity	Low-mass free-climbing on irregular rock
SCALER	Versatile bouldering and ground motion	High-DoF locomotion and body repositioning	Dynamic climbing with a specialized gripper
ReachBot	Extreme enclosed-space reach	Extendable boom-based locomotion	Large workspace in caves and lava tubes

That positioning is the reason the repo is interesting even without hardware. It sits in the explanatory layer of robotics, where the job is to make control legible before it is made physical.

Why This Matters

Good simulators do two things at once. They reduce friction for builders, and they preserve the structure of the real problem. This project does both. It makes a niche climbing system editable in a browser, but it keeps the math and the constraints intact enough to remain useful.

That is the rare part. The wall is authored as data. The motion is solved as control. The result is a climbing model that is easy to inspect without being cheapened into a toy.