Robot motion editor
Author a movement for a robot you already have a description for — keyframes on a timeline, curves per joint — and find out whether the machine can actually perform it. Not whether the file is valid: whether the motors have enough.
Posing by where the foot goes
Drag a leg to put its foot where you want it — the hip, thigh and knee are worked out from the bone lengths in your own file. Nobody poses a robot by picking angles; they decide where the foot goes.
Playback is a drawing
Playback writes joint angles straight into the scene, so every movement looks equally possible. It is a drawing.
That is also why the robot cycles its legs on the spot. Nothing here decides where the body goes — that comes from feet pushing against a floor, which is physics. Press Check and the verdict says how far it actually travelled, in centimetres.
What Check measures
Check plays the same clip through the motors in MuJoCo and measures what the drawing hides: the torque each joint is asked for against the effort your file declares for it, joints resting on their limit stops, feet sliding, links running into each other, and whether the robot is still upright at the end.
That comparison needs the description and the simulation in one place. A simulator alone no longer has the rating — we still do, because the physics model was written from your file.
Shaping the path between two keys
Keys say where a joint is and when. How it gets there is the ease — smooth, linear, or a hold that steps rather than blends — and, when that is not enough, a pair of bezier handles you drag on the curve itself. The handles are stored per joint, because a knee that snaps and a hip that drifts share a frame and want opposite shapes.
The curve you see is the interpolation the clip will actually play, sampled the way the player samples it. Where the last run found a joint working hardest, that stretch of its own line turns amber, then red at the rated limit.
What you can export
The sequence as JSON, joint angles as CSV at a fixed rate, the whole project as one file, the check report as Markdown, a ROS JointTrajectory you can paste into a launch file, or a Unitree SDK Python script. The first line of every export is the verdict — either it is safe to drive as a position reference, or it says why it is not.
The same check runs without a browser: check-clips.mjs takes a model and a folder of clips, prints a verdict for each and exits non-zero when one is beyond the robot — so a commit that makes it fall over fails the build.
Common questions
What files does it open?
URDF, Xacro, MJCF and SDF, with their meshes — drop the folder or a ZIP. A movement authored on one robot can be opened on another: clips store joint angles by name, so whatever the second robot also has, it gets.
Do I need ROS or MuJoCo installed?
No. The physics is MuJoCo compiled to WebAssembly and runs in the tab. Nothing is uploaded, and there is nothing to install.
What does "97% of rating" mean?
It is the peak torque the run demanded of a joint, against the effort value
that joint declares in your own description. Above the rating the motor cannot deliver
what the clip asks for, and the movement is a drawing of something the robot will not do.
Can I bring in motion capture?
BVH and SMPL retarget onto the robot in the Capture tab. What arrives is a clip like any other — and it goes through the same check, which is usually where a human motion turns out to be beyond a machine's joints.
How is this different from an animation tool?
An animation tool answers "does this look right". This one answers "can this robot do it", using the masses, limits and effort ratings already written in the file you opened.
Inspect a model in the viewer Run it in the physics lab Convert between formats