Stanford software translates human motion for robots in seconds

Stanford’s Autonomous Systems Laboratory has added a fast motion-conversion tool to its open-source frax robotics software, giving developers a way to adapt recorded human movements to a humanoid’s body. The new module, frax.ik, could shorten a recurring job in robot development: preparing the movements that machines will later learn to follow.

The developers report converting the LAFAN1 motion-capture dataset for a Unitree G1 humanoid in about four seconds on an Intel i9-14900KF processor. Ubisoft’s dataset contains nearly half a million frames, representing roughly 4.6 hours of recorded movement. Adding checks intended to keep the robot’s limbs from colliding increases the reported processing time to about seven seconds.

The practical attraction is the chance to try more versions of a movement before committing to expensive robot training. A researcher adjusting an arm’s reach or the placement of a foot could regenerate the reference motions and inspect the result. The software produces those reference poses; subsequent training and physical testing determine how well a robot can perform them. Version 0.2.0 entered the repository on November 4 and was highlighted publicly on November 5.

Making human movement fit a different body

A human and a humanoid rarely have matching proportions. A person’s hand may reach farther from the shoulder, or the legs may be longer relative to the torso. Copying the recorded joint angles directly can therefore put a robot’s feet below the floor or its hands somewhere quite different from the intended position.

Roboticists call the conversion retargeting. Inverse kinematics supplies the mathematical machinery: given desired positions and orientations for body parts, it works out how the robot’s joints should move to approach them. The calculation must also accommodate the limits built into the robot’s design.

The published G1 example makes these adjustments visible. It scales the human’s legs and upper body separately, shifts targets to account for the robot’s foot geometry and restricts certain arm movements to avoid an unwanted shoulder configuration. It also smooths the incoming rotations. Together, those adjustments align the recorded movement with the robot’s proportions and joint limits.

The configuration credits ideas and parameters from General Motion Retargeting, or GMR, an existing open-source project. GMR’s research found that defects in converted motions, including sliding feet and body parts passing through each other, could weaken learned tracking behavior, especially in long or dynamic sequences. The quality of the training reference matters alongside the speed of producing it.

What the four seconds measure

The frax documentation advertises the LAFAN1 example with the words, “Retarget the entire dataset in 4 seconds on CPU.” The accompanying code gives that claim a more precise scope. It loads and smooths the recordings before starting the retargeting timer, then saves the converted files afterward. Downloading the data and those surrounding steps add to the time a user will spend running the complete job.

Frax uses JAX, a numerical computing system that compiles Python calculations into optimized operations and can calculate derivatives automatically. In robot control, those derivatives describe how a small joint movement changes the position or orientation of a body part. The offline retargeter distributes motion clips across processing devices, allowing multiple clips to be handled in parallel on the CPU.

Its reported rate above 100,000 frames per second describes this batch-processing workload. Live control has a different timing problem: each incoming movement must be processed promptly enough for the robot to respond. The project also provides an online retargeter, with instructions to compile its critical functions before strict real-time use.

Frax’s guide compares its throughput with a published GMR figure obtained under different conditions. A controlled comparison would use the same processor, robot, recordings and constraints to measure processing time and movement quality.

When movement constraints conflict

The calculations rely on ElastiQP, a solver described in a September preprint by researchers at Stanford and MIT. Such solvers balance movement goals against constraints, including joint limits and clearance from obstacles. As the requirements accumulate, they can become mutually incompatible. A conventional solver may report that the problem is infeasible, which, in the paper’s words, “leaves the robot with no control to execute.”

ElastiQP permits selected amounts of violation of inequality constraints, with penalties governing how costly each violation is. It reduces the computational burden by eliminating the extra mathematical variables normally used to represent that flexibility. When a feasible solution exists and the penalties are sufficiently high, the formulation recovers the solution that satisfies the constraints.

Developers must therefore set priorities through the violation penalties. Equality constraints remain hard and must be mutually consistent. An “always-feasible” optimization problem can still produce a command that breaches a safety margin when requirements conflict. Testing those decisions on the intended robot and environment remains essential.

Frax’s humanoid examples currently target the G1. Adapting another machine requires a description of its structure and a model of its collision geometry. The software is available under the MIT license, while LAFAN1 carries a separate noncommercial, no-derivatives license. For researchers, the immediate opportunity is to rebuild and examine motion libraries quickly, then test whether the revised references produce steadier feet, smoother joints and more reliable movement on a physical robot.

Primary sources

1. StanfordASL frax repository. Version 0.2.0 functionality, JAX architecture and software availability.

2. Version 0.2.0 commit. November 4 code history. November 5 announcement.

3. Inverse kinematics and retargeting guide. Developer-reported four- and seven-second timings, hardware, applications and quoted wording.

4. LAFAN1 retargeting script. Timing boundaries, CPU parallelism and default self-collision setting.

5. LAFAN1 to G1 configuration. Scaling, floor adjustments, arm limits and GMR attribution.

6. Online and offline retargeter implementation. Parallel clip processing, compilation and online preparation.

7. Ubisoft La Forge Animation Dataset. Dataset size, duration and license.

8. Retargeting Matters. GMR study on how retargeting defects affect learned motion tracking. October 2025 research, used as context.

9. ElastiQP paper. September 2026 preprint, solver formulation, constraint qualifications and quoted wording.

10. Frax MIT license. Software terms.

Editorial note: Timings are the developers’ reported results. Independent verification of throughput, motion quality and physical safety remains pending.