Nine source adapters turn surfaces into a shared interface
UMR documents 9 motion-source paths: BONES-SEED, HiPHI, GRAIL, OmniContact, LAFAN1, OMOMO, MimicKit characters, AdaPT, and an NR FBX/BVH route. The common idea is to sample a moving exterior surface, learn ordered correspondence between that source template and a robot in aligned poses, then optimize robot motion using matched positions, orientations, contacts, and kinematic constraints. A learned correspondence can be reused across motions that share the source template and robot.
That approach avoids hand-picking human-to-robot joint pairs for every clip. It does not make input formats interchangeable by itself. Each adapter expects a particular local layout and representation, and several point to outside conversion tools or datasets. The practical boundary is surface-level motion: once your source reaches the expected mesh or SMPL-X form, UMR can apply one formulation. Getting a new capture format to that boundary remains your job.
Nine robot configurations shorten onboarding without removing it
The repository carries 9 files under robot_configs, covering examples such as Unitree G1 and H2, Booster K1, EngineAI T800, and MimicKit. For another robot, the README says to copy an example, provide the MJCF path, set model-specific limits, and create a T-pose in the browser-based UMR Studio. The studio copies tpose_qpos back into the configuration; it does not discover a correct pose from arbitrary geometry.
Source and task weights live outside those robot files. Separate defaults and retargeting modules cover SMPL-X, SOMA, character motion, human-object interaction, NR, and AdaPT. The README says these values work well for G1 and often transfer, while warning they may not suit every embodiment. That is the right research posture. A successful optimization still needs inspection for foot sliding, ground penetration, contact loss, joint-limit pressure, and object-scale mistakes.
What happened when we ran it
Our fresh Debian sandbox installed commit c56b630 in 20 seconds on 3 CPUs with 8 GB of RAM and no secrets. Installation succeeded with 35 packages and used 37 MB on disk. The build step completed successfully in 6 seconds. Pip-audit reported 0 known vulnerabilities in the installed dependency set.
The checkout contained 410 files, about 35,243 lines of source, and occupied 32.4 MB. No test script or test target existed, so we skipped tests. Our scan found 0 CI workflow files, no Dockerfile, and no tests directory. Those results cover repository setup and build mechanics only. We did not download SMPL-X models, learn correspondence, launch MuJoCo, or score the physical quality of a retargeted sequence.
SMPL-X files and several converters stay outside the repository
UMR does not distribute SMPL-X body-model files. The README directs users to accept the provider's terms, download neutral and any needed gendered models, then place .pkl or .npz files under smpl/. Current documentation says both formats are supported. The manual installation also pins PyTorch 2.4.1 from the CUDA 12.1 wheel index before installing the 20 entries listed in requirements-umr.txt.
Conversion coverage varies by source. LAFAN1 directs users to lafan_to_smplx, while HiPHI now has a separate hiphi2smplx repository. OmniContact expects pre-converted SMPL-X input. Open issue 2 asks whether the team's internal BVH-to-SMPL-X converter will be released, confirming that this step remains unavailable here. NR takes FBX or BVH through bundled parsing code but adds Node 18 as another runtime. Read the adapter guide before downloading a large dataset.
Batch tools favor bounded memory over automatic speed
UMR includes batch runners for SMPL-X, BONES-SEED, and HiPHI. The HiPHI path defaults object preprocessing and retargeting to 1 worker to limit peak memory, then lets the user raise --object-workers or --workers. Batch summaries record clip status, and bidirectional warm starts with dynamic programming aim to reduce sensitivity to occasional singularities. GPU assignment is exposed for retarget jobs, while a closed discussion also describes the existing solve path as CPU and Clarabel based.
Visualization has two routes. The default GLFW viewer suits a local machine with a display. The Viser backend serves results on port 8080 and can refresh a result directory while a remote batch is running. This split is useful in a lab, though it is still an inspection tool. A browser animation can reveal a tilted body or sliding foot; it cannot establish that a trajectory is safe for hardware or suitable as policy-training data.
One open issue and seven closed reports show active triage
GitHub showed 443 stars and 1 open issue on October 1, 2026. The repository was pushed on September 27, and the API returned 7 closed issues covering licensing, model format, foot sliding, visualization, comparisons, and workflow questions. There are no releases, so users must pin a commit rather than a version tag. The recent push and resolved reports indicate current maintenance despite that missing release process.
UMR fits after motion conversion and before simulation, policy learning, or robot deployment. GMR is the closer alternative when CPU real-time conversion is the main constraint. Human2Humanoid moves toward live teleoperation, while ProtoMotions covers the larger training stack. Choose UMR for its reusable learned surface mapping, then keep the downstream checks strict: a 6-second build says the code packages, while contact quality and robot safety require evidence from the actual body, task, and controller.