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.
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 — a humanoid's limbs follow where
the recorded bones point, any other robot is mapped joint by joint. 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 the retarget
works, and where it stops being the right tool.
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.