> For the complete documentation index, see [llms.txt](https://doc.ancorasir.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.ancorasir.com/2026spring/simulation-and-interaction/class-05-motion-retargeting-in-robotics.md).

# Class 05: Motion Retargeting in Robotics

Motion retargeting is the problem of taking a motion demonstrated on one system (a human, another robot, or a simulation character) and producing a motion for a different robot that preserves the original motion's intent while respecting the target robot's physical and kinematic constraints.

In robotics, retargeting is usually not a simple "joint-to-joint" copy, because the source and target often differ in:

* link lengths and proportions (morphology)
* joint types and degrees of freedom (DoF)
* joint limits and velocity limits
* contact capabilities (feet, hands, suction, grippers)
* balance constraints (especially for humanoids)

### Materials

The bundled General Motion Retargeting implementation keeps its original package layout so its scripts and assets continue to work.

<table><thead><tr><th width="200.30078125">Resource</th><th>Purpose</th></tr></thead><tbody><tr><td>GMR overview</td><td>Installation, supported robots, and end-to-end usage.</td></tr><tr><td>Configuration notes</td><td>Match tables, weights, offsets, and IK configuration.</td></tr><tr><td>Test motions</td><td>Available examples and expected inputs.</td></tr><tr><td><code>scripts/</code></td><td>Executable retargeting and visualization entry points.</td></tr></tbody></table>

### Why Retargeting Matters

* **Reuse motion data**: convert existing motion capture, animation, or prior robot trajectories into motions your robot can execute.
* **Teleoperation**: map human motion (or controller motion) to robot motion in real time.
* **Imitation learning/tracking**: create reference trajectories that a controller or RL policy can track.
* **Benchmarking**: compare controllers on a shared set of tasks/motions.

### What "Preserving the Motion" Usually Means

Different applications preserve different features. Common targets include:

* End-effector trajectories: hands/feet positions, orientations, and velocities
* Relative poses: e.g., hand-to-torso, foot-to-pelvis, gaze direction
* Contact schedule: which foot is in contact and when (humanoids)
* Style cues: smoothness, timing, symmetry

### Typical Retargeting Pipeline

1. **Normalize the source motion:** Convert into a representation that is easy to consume: per-frame poses, root trajectory, contact labels, and consistent coordinate frames.
2. **Define a mapping:** Choose how source features map to the target robot. Examples: match human hand pose to robot wrist pose; match pelvis orientation; match foot contact points.
3. **Solve for a feasible robot motion:** Compute robot joint trajectories that best satisfy the mapping while honoring constraints.
4. **Post-process**: time scaling, smoothing, joint-limit handling, collision filtering, and optional contact refinement.

### Common Approaches

#### A. Rule-Based / Heuristic Retargeting

Fast and simple: scale translations by limb length ratios, clamp joint angles, and manually tune offsets. Useful for quick demos but tends to break for contacts and high-precision tasks.

#### B. Optimization-Based Kinematic Retargeting (IK)

Formulate per-frame or trajectory optimization:

* Decision variables: joint angles `q(t)` (and sometimes base pose)
* Objectives: minimize task-space errors (hands/feet/pelvis), regularize posture and smoothness
* Constraints: joint limits, velocity limits, self-collision (optional), contact constraints (optional)

A common trajectory-style objective (conceptually) is:

* minimize: tracking errors + posture regularization + smoothness
* subject to: kinematic constraints and joint bounds

#### C. Learning-Based Retargeting

Train a model to map source pose/features to target robot pose. Often combined with kinematic checks or a final IK projection step to ensure feasibility.

### Special Considerations for Humanoids

Retargeting walking, squatting, and other contact-rich motions requires more than matching joint angles:

* **Contacts**: feet (and sometimes hands) should remain stationary during stance.
* **Balance**: the CoM / ZMP should remain consistent with the support polygon (even if planning is kinematic).
* **Root motion**: pelvis/base translation and yaw must be chosen carefully; small errors cause foot slipping.

A common teaching decomposition is:

* footstep/contact planning
* CoM (or ZMP) planning for stability
* whole-body kinematic realization (IK) with stance/swing constraints

### Implementation guide

Start with the GMR overview, then consult the configuration notes before changing robot-specific mappings. Package assets, robot models, third-party components, and scripts intentionally remain inside `01-KG-03-MovRetarget-GMR/` because their relative paths are part of the implementation.

### Suggested Exercises

1. Pick one motion clip and define what you want to preserve (hands, feet, pelvis, contacts).
2. Change the objective weights (e.g., prioritize feet vs hands) and observe the artifacts.
3. Add a simple smoothness term across time and compare to frame-by-frame IK.
4. If the motion involves stepping, check whether stance feet slip; then add stance constraints.

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://doc.ancorasir.com/2026spring/simulation-and-interaction/class-05-motion-retargeting-in-robotics.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
