RoboHive: one Gym API over many robot manipulation tasks

What RoboHive is: MuJoCo tasks behind a Gym interface

RoboHive is a collection of environments and tasks simulated with the MuJoCo physics engine, exposed using the OpenAI Gym API. The README's next sentence is the practical part: it is compatible with any gym-compatible agents training framework, naming Stable Baselines, RLlib, TorchRL and AgentHive as examples.

That is the whole design in one line. Rather than being a training framework, RoboHive is a benchmark surface. An environment is a state, an action space, a reward function and a reset, and the point of the project is that the same interface works whether the task is a five-finger hand or a musculoskeletal arm model or a kitchen multi-task. Swapping the task means changing the environment identifier rather than rewriting the training loop.

The framing is unified robot learning, and it has the academic apparatus to match: a paper on arXiv, 2310.06828, titled RoboHive, A Unified Framework for Robot Learning, a project page hosted on Google Sites, a wiki for documentation, a PyPI package named robohive, a Slack workspace, and a Colab notebook that runs an example without a local setup. The code is by Vikash Kumar, and the licence is Apache-2.0, with the licence header carried in the source files themselves.

For a benchmark collection, the interesting question is not the interface but what is inside it, and the answer is breadth across robot morphologies: hands, arms, musculoskeletal models and household tasks, each built on the same physics engine and the same API.

Getting started: install, initialise, look at an environment

The README's getting started section is three commands, and the middle one is the part that is specific to this project.

   # Install RoboHive
   pip install robohive
   # Initialize RoboHive
   robohive_init
   # Demo an environment
   python -m robohive.utils.examine_env -e FrankaReachRandom-v0

robohive_init is a separate step rather than something pip does for you, and it exists because the environments are not self-contained: they carry assets, and those assets have to be fetched and laid out locally before an environment can be constructed. Running examine_env with an environment identifier such as FrankaReachRandom-v0 is the quick check that the installation works, and the environment naming convention with a version suffix is the same one the wider Gym ecosystem uses.

For development, the README gives an editable route that clones with the recursive flag:

   # Clone RoboHive
   git clone --recursive https://github.com/vikashplus/robohive.git; cd robohive
   # Install (editable) RoboHive
   pip install -e .
   # Demo an environment
   python -m robohive.utils.examine_env -e FrankaReachRandom-v0

The recursive flag is required rather than decorative: the repository has a .gitmodules file, so a shallow clone leaves the submodules empty and the environments that depend on them will not build their models.

The setup directory has the detailed installation instructions, and the README points at them for the two choices that matter on a research machine: the choice of mujoco-python bindings, and the choice of visual encoders, with R3M, RRL and VC named as options. The encoders matter because they decide whether your policy sees raw pixels or a learned representation, which changes both the compute budget and what your results are comparable to.

The suites: hands, arms, musculoskeletal models and kitchens

RoboHive's environments are organised as suites, and the README defines a suite as a collection of loosely related environments. The ones provided at the moment are listed with plans to improve the diversity of the collection.

The Hand-Manipulation Suite is centred on dexterous manipulation and includes the standard ADROIT benchmarks, which were introduced in the paper on learning complex dexterous manipulation with deep reinforcement learning and demonstrations at RSS 2018. ADROIT is the reference point for five-finger hand manipulation, so having it here means a result can be compared against the published numbers rather than against another group's reimplementation.

The Arm-Manipulation Suite is the arm equivalent, a collection of environments centred on arm manipulation.

The Myo Suite covers musculoskeletal control, and the Myo and MyoDM Suite holds musculoskeletal environments for dexterous manipulation introduced as MyoDM in MyoDeX. Musculoskeletal models are where the simulation earns its keep, because the constraint structure of a muscle-driven arm produces behaviours that a rigid-joint model does not.

The MultiTask Suite is centred on multi-task settings and includes the standard RelayKitchen benchmarks.

Two suites are announced but not complete. The TCDM Suite is marked work in progress and is a collection of environments centred on dexterous manipulation that includes the standard TCDM benchmarks. The ROBEL Suite is marked coming soon and covers real-world locomotion and manipulation, with the standard ROBEL benchmarks as a part of it. The distinction matters when you plan a paper: a suite listed as coming soon is a promise, and the benchmarks you would cite from it are not in the package yet.

The install-time checks: FFmpeg and Python 3.8

The setup script in the repository does two checks before it does anything else, and both are visible in the packaging metadata rather than hidden in a wiki page.

The first is FFmpeg. The script looks for it on the path and, if it is not there, refuses to continue with a message that names the options, giving apt-get install ffmpeg for Linux and brew install ffmpeg for macOS. So a missing FFmpeg is a hard failure at install time rather than a surprise later when you try to record a rollout video.

The second is the Python version. The script checks whether the interpreter is older than 3.8 and, if so, prints a warning that the library requires Python 3.8 or higher, that you are running a lower version, and that the installation will likely fail.

The asymmetry between the two is worth noticing. FFmpeg raises a ModuleNotFoundError and stops; the Python version only prints a warning and continues. In practice that means an unsupported interpreter gives you a partially working installation rather than a clean refusal, which is the kind of detail worth knowing before you spend a day debugging an environment that will not construct.

The repository layout explains the rest. There is a robohive/ package holding the environments, a robohive_init.py at the top level for the initialisation step, setup/ for the detailed setup instructions and assets, and a .gitmodules file for the submodules the environments depend on.

Releases, dependencies and where RoboHive is the wrong choice

The release history tells you where the project has been. Version 0.7, published on 2024-03-26, brought a Gymnasium upgrade, multiple teleOP controllers and a MuJoCo upgrade. Version 0.6 from 2023-10-10 added the Kitchen, Myo, HMS, Arms, MultiTask and MyoDM environments. Version 0.5 from 2023-04-14 was a pre-release with the Kitchen, Myo, HMS and Arms environments.

So the suite structure grew quickly across 2023 and then consolidated in the v0.7 release, and the last one is from March 2024. The last push to the repository was on 2026-09-22 and the repository is not archived, which means the branch keeps moving while the published releases do not. For a project whose environments depend on simulator versions, that gap is the central maintenance question: the Gymnasium and MuJoCo upgrades in v0.7 were necessary because the underlying stack moved, and the same pressure will return.

The first wrong case is a group that needs a benchmark suite which is not in the package yet. TCDM is marked work in progress and ROBEL is marked coming soon, so a plan that depends on those benchmarks is a plan that depends on unreleased work.

The second is a pipeline that needs a pinned, released, reproducible version. Here you have a moving branch and a two-year-old release, and choosing between them means choosing between reproducibility and current features.

The third is a hardware-free workflow where MuJoCo's rendering or asset pipeline conflicts with your own tooling, and where the FFmpeg requirement at install time is one more system dependency to justify.

The realistic alternative is to depend directly on MuJoCo and on the individual benchmark repositories, the original ADROIT, MyoSuite, Relay Policy Learning and ROBEL codebases. The difference in approach is that those give you the reference implementations of their benchmarks with no unification layer, while RoboHive gives you one interface, one install path and one set of baselines across all of them, at the cost of being a layer above the originals rather than the original itself.

Editorial conclusion

RoboHive earns its place for a group that trains manipulation policies across several benchmark suites and wants one interface, one dependency set and a shared evaluation protocol instead of a repository per benchmark family. It is not a fit for a pipeline that needs the newest simulator or a released, pinned version of the framework, since the last release is v0.7 from 2024-03-26 while the branch has continued to move. Verify first that the tasks you need are in a suite that has actually shipped rather than one marked work in progress or coming soon, that ffmpeg is present before you install, and that the Gymnasium-era API changes described in the v0.7 release notes do not break the training framework you plan to use.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. vikashplus/robohive on GitHub