GMR: real-time motion retargeting where the default motor speed limit is 3*pi

Velocity limiting is on by default, at three times pi radians per second

One entry in the updates section from 2025-08-24 carries more engineering weight than the rest of the list. It records that velocity limits for the robot motors are supported, that `use_velocity_limit=True` is the default in the `GeneralMotionRetargeting` class, and that three times pi is the velocity limit used by default. A project whose stated purpose is real-time whole-body teleoperation, on CPU, driving physical joints, therefore ships with a hard clamp on motor speed already enabled rather than off. The same entry notes that printing of robot DoF, body and motor names and their identifiers was turned on by default as well, reachable through the `robot_dof_names`, `robot_body_names` and `robot_motor_names` attributes. Both defaults point the same way: the library is set up to be safe and verbose rather than quiet and fast, which is the right starting position for hardware and the wrong one for a benchmark. Nothing later in the updates section changes either default, so a caller who wants raw motion has to find and turn them off.

Every robot is added by hand and the contributor must supply open-source model files

The note near the top of the page is the real onboarding document. To support a new robot or a new human motion format you send the robot files, with `.xml`, `.urdf` and meshes named explicitly, or the motion data, either to the author or through an issue, and the project says it will support it as soon as possible. The same note attaches a condition: the robot files you send must be open-sourced in the repository. That condition decides which robots can ever appear here, because a manufacturer that will not release its URDF and meshes cannot be supported by this route no matter how cooperative the integration would be otherwise. It also means the seventeen robots present are not a neutral survey of the field but the set the project could actually redistribute. For a user, the practical consequence is that the supported list is a list of what could be published, and a robot missing from it is a licensing outcome rather than an engineering one. The motion data side has no such stated restriction.

The robot count is numbered but skips a number, and two entries carry no number

Reading the updates in order shows how the support list was built. HighTorque Hi arrives on 2025-08-06 as the sixth humanoid robot, followed the next day by Galexea R1 Pro and KUAVO as the seventh and eighth, described on the page as a wheeled humanoid robot. Booster K1 is the ninth on 2025-08-10, Unitree H1 the tenth on 2025-08-24, Berkeley Humanoid Lite the eleventh on 2025-08-27, and Unitree H1 2 with PND Adam Lite the twelfth and thirteenth on 2025-08-30. Tienkung is the fourteenth on 2025-09-12 and PAL Robotics' Talos the fifteenth on 2025-10-15. The next ordinal to appear is seventeenth, Fourier GR3 on 2026-01-12, so the sixteenth robot was added without a numbered entry. Two more additions sit in the same stretch without any ordinal at all, Unitree G1 with Dex31 hands on 2025-08-09 and Booster T1 in both 23dof and 29dof variants on 2025-08-28. The count is therefore maintained by hand and the sequence is not a reliable index of what is supported.

Motion arrives as BVH, FBX, a pickle file or a monocular video

The input side widened faster than the robot side. Three vendor formats are named on the page: Xsens BVH offline data on 2026-01-21, Nokov BVH on 2025-10-14, and exported offline FBX motion data from OptiTrack on 2025-08-28. The first demo retargets LAFAN1 dancing motion onto five robots at once, which is the case the retargeting has to survive, since the same source has to satisfy bodies with different proportions and joint counts. Two entries extend the pipeline past a file on disk. From 2025-09-16 the pose can be extracted from monocular video with GVHMR and then retargeted, so the input becomes a camera rather than a capture file. From 2025-10-01 the project also converts GMR pickle files to CSV for beyondmimic, through `scripts/batch_gmr_pkl_to_csv.py`, and since 2025-11-08 MimicKit accepts the GMR format through a conversion tool in that project. TWIST2 support from 2025-12-02 goes the other way, using the XRoboToolkit SDK, which ties the library to that SDK for the teleoperation path.

The install pulls a body model from Git at whatever commit HEAD happens to be

The manifest is a plain `setup.py` and its contents are more revealing than the prose. The distribution is named `general_motion_retargeting` while the repository is called GMR, so the package you import and the project you read about are not spelled the same way. It declares version `0.2.0`, requires Python 3.10 or later, and lists its dependencies without version constraints, except for the extras markers. One entry is a direct git reference with no commit pinned:

    "smplx @ git+https://github.com/vchoutas/smplx",
    "redis[hiredis]",
    "imageio[ffmpeg]",

That first line means an install resolves the SMPL-X body model library from a moving branch rather than from a tagged release, so two installs of the same `0.2.0` can end up with different code underneath. The file also has the hand-written look of a script rather than a generated one, with spaces around the assignment keywords and a `long_description` that opens `README.md` without naming an encoding. There is no `pyproject.toml` at the root, so installation goes through the older setuptools path, and the repository publishes no GitHub releases, which leaves the manifest version as the only version number a reader can find.

Redis and protobuf sit in the dependency list of a retargeting library

The dependency list explains what the library actually does and raises one question it does not answer. The numeric path is visible: `mink` for inverse kinematics, `qpsolvers[proxqp]` for the quadratic program that solves it, `mujoco` for simulation, `numpy` and `scipy`, and `smplx` for the human body model the motion is expressed in. The real-time claim has its own dependency, `loop_rate_limiters`, which is what keeps a retargeting loop at a fixed rate on CPU rather than as fast as the machine allows. Video and console handling account for `opencv-python`, `imageio[ffmpeg]`, `rich` and `tqdm`, with `natsort` for ordering numbered files and `psutil` for process and system information. Then there are `redis[hiredis]` and `protobuf`, which have no obvious place in a motion pipeline that reads files and writes joint angles, and the page never mentions a server, a queue or a message format. Either a component outside the documented path needs them, or they are left over from a tool the library grew out of.

CLAUDE.md is in the root, and the listing shows no test suite and no CI

The repository root is short enough to read in one line: `.gitignore`, `CLAUDE.md`, `DOC.md`, `LICENSE`, `README.md`, `TEST_MOTIONS.md`, then the `assets`, `general_motion_retargeting`, `scripts` and `third_party` directories with `setup.py`. Three of those files describe how to work with the project rather than what it does. `CLAUDE.md` is an instruction file for an AI coding assistant, kept in the repository so the guidance travels with the code. `DOC.md` was added on 2025-10-14 as documentation on the inverse kinematics configuration, which is the part of the system with the most knobs. `TEST_MOTIONS.md` covers motion data rather than a test suite, and no test directory and no `.github` directory appear in the listing, so nothing in the root records an automated check for seventeen robot models. The last push on the default branch is dated 2026-04-02 and the newest updates entry is 2026-01-21, and the community is reached through a WeChat contact rather than an issue tracker first.

Editorial conclusion

GMR is worth a look if you have a humanoid or a motion capture file and want to see the same movement on different bodies, and the documentation is unusually honest about how much of that support is manual. Seventeen robots arrived in about five months, one at a time, through a channel that asks you to email XML, URDF and mesh files and to confirm they can be open sourced, which means robots whose vendor withholds models will never appear. Before pointing it at hardware, read the defaults rather than assuming them: velocity limiting is on by default at three times pi radians per second, and robot name and identifier printing is on as well. The repository was last pushed on 2026-04-02 and the newest entry in its updates section is dated 2026-01-21, and it publishes no GitHub releases while the manifest carries version 0.2.0, so pin your own version and re-check that the motor limit matches your hardware before real-time teleoperation.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. YanjieZe/GMR on GitHub