The research framework turns conversational requests into timed, body-specific edits while protecting the rest of an existing movement.
Researchers present TRACE as a motion-generation and editing framework for the Unitree G1 humanoid robot. The arXiv paper reports generated-motion evaluations, controlled editing tests, and qualitative demonstrations on a real robot—not a product people can buy or an established factory deployment.
Its practical question is simple: If a robot already has a usable movement, can someone change one part without accidentally rewriting everything else?
TRACE answers by translating ordinary language into measurable motion events. It then uses those events to guide a diffusion model, which gradually turns noise into a complete motion sequence.
From “move your hand” to a timed change
A conversational request rarely contains enough detail for direct robot control. “Raise your left hand” does not say exactly how high, when to begin, which arm joints should move, or what the feet should do.
TRACE inserts an intermediate step. Its language model predicts typed events for three areas:
- Support: whether the feet support the body.
- Root: the robot’s main body position, height, and movement.
- Hands: hand height and related motion over time.
These events are tied to time patches in the motion. In plain terms, TRACE tries to identify not only what should happen, but when it should happen.
The original caption remains part of the input. That matters because a small event vocabulary cannot capture every detail in a sentence. The event plan supplies timing and structure, while the text keeps the broader meaning.
TRACE also uses a gravity-referenced motion state. Height and body tilt are represented against gravity rather than treated only as local joint changes. The paper combines this representation with trajectory and foot-contact objectives, which encourage the generated motion to keep a coherent path and maintain consistent support.
That does not guarantee balance. A model can generate a plausible sequence without proving that the physical robot will track it safely.
Editing starts from the current motion
Generation and editing are separate jobs in TRACE.
For editing, the system reads both the new request and the current motion. It parses the request into a typed change, such as a hand-height adjustment, then compiles that change into two pieces:
- A body–time scope, identifying which body parts and time interval may change.
- A source-relative goal, describing the change compared with the existing motion.
Suppose the request asks for a hand to rise during part of a movement. TRACE can select the arm’s kinematic chain—the connected joints that control that hand—and limit the edit to the requested interval.
The rest becomes protected reference motion.
This is the key engineering idea behind the system. During each step of diffusion sampling, a process called reference projection restores protected motion coordinates from the existing sequence. The selected body region can change, while the rest of the encoded motion is repeatedly pulled back toward its prior state.
Each edited result becomes the reference for the next request. That creates a conversational loop: make a motion, adjust it, adjust the adjustment, and preserve the accepted parts along the way.
There is an important boundary. The paper notes that preserving encoded coordinates does not by itself guarantee preservation in world space for edits that change the robot’s root, such as its overall position or orientation.
What the reported tests actually show
The paper evaluates generation on a BONES-SEED test split containing 13,302 text–motion pairs. For editing, it uses 199 held-out G1 source motions and controlled hand-height requests. Each initial request specifies one hand, a signed five-centimeter height change, and a time interval.
The multi-turn test uses 597 four-request chains. At four turns, TRACE reports 30.82% all-turn success, compared with 6.48% for an adapted TMED system and 2.74% for an adapted SimMotionEdit system.
“All-turn success” is demanding: every request in the chain must satisfy the change and preservation criteria relative to the method’s previous output. The requests concern controlled hand-height changes, not broad instructions involving tools, objects, rooms, or complicated contact.
The comparison also needs careful reading. The other systems were local G1 adaptations, and the paper notes differences in architecture, prior training, and total computing effort. That makes the result useful evidence from the paper’s comparison, but not a directly matched product shootout or independent replication.
The paper also shows qualitative real-robot demonstrations on the G1, including looking left and right, a hip-hop routine, and shifting weight between legs. These examples show generated motion reaching physical hardware in selected cases. They do not establish reliable performance across varied environments or safety-critical tasks.
Why the distinction matters
TRACE is best understood as a motion-authoring system, not an autonomous humanoid worker.
Its output is a reference motion that can be passed to a downstream controller. That controller still has to handle joint limits, motor tracking, timing, contact forces, unexpected obstacles, and the robot’s surroundings. The paper describes TRACE as operating on flat-ground kinematics without scene perception.
For engineers, the useful interface is clear: language becomes typed events, typed events become scoped numerical goals, and projection limits unwanted changes. For operators, the next meaningful test is physical transfer beyond demonstrations: repeated edits on hardware, recovery from imperfect tracking, and behavior around objects and people.
TRACE makes humanoid motion editing more structured and interactive. It does not yet make conversational robot control a solved deployment problem.