robomimic pins three Hugging Face libraries to exact versions, which is the number to watch

Datasets moved to HuggingFace in v0.4.0, and that changed the install

The release history is the clearest way to understand what robomimic is now. v0.4.0, dated 03/11/2025, did two significant things: added support for robosuite v1.5 and migrated robomimic datasets to HuggingFace.

That migration is not incidental. Datasets were previously distributed as HDF5 files hosted alongside the project, and moving them to HuggingFace means robomimic is now a client of someone else's file hosting. That is where the exact version pins in setup.py come from, and it is the single most likely thing to break an existing environment.

The dependency block names the versions directly:

huggingface_hub==0.23.4
transformers==4.41.2
diffusers==0.11.1

All three use `==`, not a caret or a tilde. If your project already depends on a newer `transformers` for something else, installing robomimic will either downgrade it or fail to resolve. That is the first conflict to expect.

The rest of the dependency list is ordinary: `numpy>=1.13.3`, `h5py`, `psutil`, `tqdm`, `termcolor`, `tensorboard`, `tensorboardX`, `imageio`, `imageio-ffmpeg`, `matplotlib`, `egl_probe>=1.0.1`, `torch` and `torchvision`. Note that torch and torchvision are unpinned, while the three HuggingFace packages are pinned, which tells you the pinning is not a policy about reproducibility in general but a reaction to a specific incompatibility with the dataset-loading path.

The package version in setup.py is 0.5.0, matching the v0.5.0 release on 2025-06-27, which brought Diffusion Policy, multi-dataset training and language-conditioned policies.

What v0.5.0 added, and what v0.3.0 added

Two releases account for most of the framework's current capability, and both are listed in the README's update log.

v0.5.0 on 06/27/2025 added Diffusion Policy, multi-dataset training and language-conditioned policies. Language-conditioned policies is the one with the widest implications: it means a policy can be conditioned on text, which is the direction the field has moved in, and it is presumably why `transformers` and `diffusers` are dependencies at all. Diffusion Policy explains `diffusers`, and the language side explains `transformers`.

v0.3.0 on 07/03/2023 added BC-Transformer and IQL, support for the DeepMind MuJoCo bindings, pre-trained image representations and wandb logging. BC-Transformer is the sequence model behind robomimic's best-known result, and IQL is the offline RL algorithm that gave the framework its offline reinforcement learning credibility.

Also worth noting from v0.3.1 on 10/11/2023: support for extracting, training on and visualising depth observations for robosuite datasets. Depth is a distinct observation modality from RGB, and supporting it as a first-class modality rather than bolting it on later is the kind of decision that is expensive to retrofit.

The intent behind all of this is stated plainly. robomimic aims to make robot learning accessible and reproducible, allowing researchers and practitioners to benchmark tasks and algorithms fairly and to develop the next generation of robot learning algorithms. That framing explains why the project ships datasets at all.

Docker builds a MuJoCo stack with software rendering

The Dockerfile is unusual and worth reading, because it encodes several decisions you would otherwise discover the hard way.

The base image is `nvidia/cuda:11.8.0-base-ubuntu20.04`, which means the build expects an NVIDIA base even when you only want CPU, because the CUDA runtime layer is the starting point and PyTorch is installed separately.

Rendering is forced to software with `MUJOCO_GL=osmesa` set as an environment variable. The system packages installed to support that include `libosmesa6-dev`, `libgl1-mesa-glx`, `libglfw3-dev` and `libglib2.0-0`, plus `patchelf`, which is needed to fix dynamic library paths for MuJoCo's binaries. If you are running this on a headless machine, that env var is the difference between a working renderer and a black screen.

Python is 3.9, installed through Miniconda into a conda environment named `robomimic_venv`. The README describes the container as giving you Python 3.9, Miniconda, robosuite and PyTorch with CPU or GPU support.

PyTorch is pinned hard, with a fallback:

RUN /opt/conda/bin/conda run -n robomimic_venv conda install -y pytorch==2.0.0 torchvision==0.15.0 cpuonly -c pytorch || \
    /opt/conda/bin/conda run -n robomimic_venv pip install torch==2.0.0+cpu torchvision==0.15.0+cpu

The Docker image uses PyTorch 2.0.0 while setup.py leaves torch unpinned. So the Docker image is behind the library, and building your own environment from setup.py with a current PyTorch is a different experience from the container.

The three commands the README gives:

docker build -t robomimic .

docker run -it robomimic

docker run --gpus all -it robomimic

robosuite is cloned from source and installed from its requirements file rather than from a pinned release, which is another source of drift.

Try the Colab notebook before you build anything

The README puts a Colab quickstart above everything else, and for this project that is the correct advice rather than a shortcut.

The Colab notebook runs a demo without installing anything locally, which lets you check whether your environment can host robomimic. Given the pinned HuggingFace versions and the PyTorch 2.0.0 expectation in the container, that question comes up before the interesting one.

The same reasoning applies to the Dockerfile's Python 3.9. Ubuntu 20.04 and Python 3.9 are both end-of-life tracks, so building the container today means building on a base that receives no OS security updates. That is a real consideration for anything you intend to run longer than an afternoon.

The setup.py declares `python_requires='>=3'` with no upper bound, so the library itself does not force 3.9. The 3.9 in the Dockerfile is a choice about which combination was verified, not a constraint enforced by the package. If you are installing from source into a newer Python, you are outside what the container tested, and you should expect to resolve the conflicts yourself.

The README also points to a troubleshooting section in the documentation and to the GitHub issue tracker for anything not covered there, which is the right escalation path given the framework's size.

Reproducibility is the feature, and the paper is the reference

robomimic's stated purpose includes making reproduction easy, and the README backs that with a datasets page for downloading datasets and reproducing experiments, plus a study website and a study paper on arXiv.

The citation request is specific. If you use the framework in your work, the README asks you to cite the paper, which is What Matters in Learning from Offline Human Demonstrations for Robot Manipulation, published at CoRL in 2021, authored by Mandlekar, Xu, Wong, Nasiriany, Wang, Kulkarni, Fei-Fei, Savarese, Zhu and Martín-Martín.

That title is also the most informative sentence about the project. The paper's subject is what matters in learning from offline human demonstrations, which is a study of which parts of the observation actually carry signal. A framework built around that question will have opinions about modalities, observation keys and architecture defaults, and those opinions are the contribution rather than incidental.

The examples directory shows how the modularity is meant to be used. `add_new_modality.py` is the clearest statement of intent: adding an observation modality is a supported first-class operation, not a hack. Alongside it are `simple_config.py`, `simple_train_loop.py`, `train_bc_rnn.py`, `simple_obs_nets.py` and a `notebooks/` directory. Reading those files is a faster way to understand the configuration model than the documentation.

The repository layout is minimal: `robomimic/`, `examples/`, `tests/`, `docs/`, `Dockerfile`, `setup.py`, `MANIFEST.in` and `requirements-docs.txt`. The package list in setup.py is filtered to packages starting with `robomimic`, so `examples` and `tests` are not installed.

Where it is the wrong tool

If you want to run an actual robot, this is not a deployment framework. It is a research framework for learning from demonstration datasets, and the datasets it ships are collected on manipulation domains in simulation and on real hardware as research data. There is no runtime, no control loop and no hardware interface in what the README describes.

If you need current PyTorch or current HuggingFace, you have a conflict to resolve. `transformers==4.41.2` and `diffusers==0.11.1` are fixed alongside `huggingface_hub==0.23.4`. Any application that needs a newer `transformers` for a different model will fight this.

If you are on a machine without substantial compute, the environment itself is the obstacle. CUDA 11.8 as the base, Miniconda, a conda env, MuJoCo with OSMesa rendering, and PyTorch installation all add up to a build that assumes a Linux workstation with an NVIDIA GPU. The CPU path exists in the container via the `cpuonly` fallback and the plain `docker run -it robomimic`, but it is the slower path through the same heavy setup.

And the maintenance cadence has slowed. The last push was on 2026-08-09 and the last release is v0.5.0 from 2025-06-27, so there has been no tagged version in over a year. The README says the project is actively maintained and used for robotics research projects across multiple labs, which is a claim about the community rather than about release frequency. If you need a maintained release cadence with changelogs, weigh the gap between the latest release and the repository's more recent development.

Editorial conclusion

Adopt robomimic if you want to reproduce published manipulation results or benchmark offline RL algorithms on a common set of demonstration datasets, since reproducing results is an explicit goal and the datasets page documents how. Do not expect it to work against current PyTorch or HuggingFace releases without checking, because `huggingface_hub==0.23.4`, `transformers==4.41.2` and `diffusers==0.11.1` are exact pins and the Dockerfile builds against `pytorch==2.0.0`. Before committing, read those pins, and use the Colab notebook linked in the README to confirm the framework runs in your environment before setting up the Docker route, which builds a full MuJoCo stack on `nvidia/cuda:11.8.0-base-ubuntu20.04` with `MUJOCO_GL=osmesa`.

Frequently asked questions

Official sources

1. ARISE-Initiative/robomimic on GitHub
2. Issues
3. License: MIT
4. README
5. Releases