Gymnasium-Robotics forces every observation into observation, desired_goal and achieved_goal
A collection of robotics simulation environments for reinforcement learning
At a glance
- What is it?
- Gymnasium-Robotics is a set of MuJoCo-backed reinforcement learning environments following the Gymnasium API, from a 7-DoF Fetch arm to a 24-DoF Shadow hand and multi-agent MaMuJoCo factorizations. The GoalEnv base class requires a three-key observation dictionary and exposes reward, terminated and truncated as recomputable functions.
- Who is it for?
- Adopt Gymnasium-Robotics when you need a simulated manipulation or locomotion task that follows the Gymnasium API and supports goal-conditioned training with Hindsight Experience Replay. Do not adopt it for a MuJoCo model you built yourself, since these are fixed environments.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A catalogue of environments, not a modelling library
The package is a collection of environments that use the Gymnasium API and run on the MuJoCo physics engine with the maintained MuJoCo Python bindings. What it does not do is let you assemble a new robot: the embodiments here are fixed and the tasks come with them.
The Fetch group is the entry point. It is a 7-DoF robot arm doing manipulation tasks, with variants for Reach, Push, Slide and Pick and Place.
The Shadow Dexterous Hand group is a 24-DoF anthropomorphic hand manipulating a cube, an egg-shaped object or a pen. Some variants add data from 92 touch sensors into the observation space, which is the difference between an environment you can learn grasping from pixels and one you learn from proprioception plus contact.
MaMuJoCo is a different shape entirely: multi-agent factorizations of the existing Gymnasium MuJoCo environments, plus a framework for factorizing robotic environments, using the PettingZoo ParallelEnv API rather than the single-agent one.
The D4RL environments are included but carry a warning that matters for reproducibility: they have been refactored and may not have the same action and observation spaces as the originals. The Maze environments navigate to a goal position with either a 2-DoF force-controlled ball or the Ant agent, across a range of maze shapes of increasing difficulty. Adroit Arm combines the Shadow Dexterous Hand with extra arm degrees of freedom for hammering a nail, opening a door, twirling a pen or moving a ball. Franka Kitchen is a multitask environment with a 9-DoF Franka in a kitchen of household items, where each task is a sequence of interactions ending in a goal configuration.
The GoalEnv contract, and why it forces three keys
The robotic environments inherit from a GoalEnv class, which extends the core Gymnasium API in a way that has consequences for your algorithm.
The observation space must be a dictionary with exactly three keys. `observation` is the actual observation. `desired_goal` is the goal the agent has to achieve. `achieved_goal` is what the agent has currently achieved. The objective is to bring achieved_goal close to desired_goal.
That is not a formatting preference. The goal keys let an algorithm substitute the goal that was achieved and recompute the outcome. This functionality is useful for algorithms that use Hindsight Experience Replay (HER).
So the environment exposes reward, terminated and truncated as functions rather than values, and each takes achieved_goal, desired_goal and info. The consistency guarantee you can assert after any step is that the values you received equal what those functions compute from the observation.
import gymnasium as gym
import gymnasium_robotics
gym.register_envs(gymnasium_robotics)
env = gym.make("FetchReach-v4")
env.reset()
obs, reward, terminated, truncated, info = env.step(env.action_space.sample())
assert reward == env.compute_reward(obs["achieved_goal"], obs["desired_goal"], info)
assert truncated == env.compute_truncated(obs["achieved_goal"], obs["desired_goal"], info)
assert terminated == env.compute_terminated(obs["achieved_goal"], obs["desired_goal"], info)Substituting a goal is then three more calls on the same observation, and the info dictionary exists so simulation state that is independent of the goal can travel with the recomputation.
The GoalEnv class is not restricted to the bundled environments; it is documented for writing your own, which is the more interesting half for anyone with a real robot in mind.
Installation carries a second dependency and a legacy extra
The package installs from PyPI, and then you still need the physics engine.
pip install gymnasium-roboticsThe MuJoCo engine itself comes from DeepMind, with installation instructions on the MuJoCo website and its GitHub repository. That is the pattern to expect: this is a set of environments on top of an engine, not a self-contained simulator.
The version story is worth knowing before you pin anything. The current environment versions use the maintained MuJoCo Python bindings from the MuJoCo team, and the dependency list in pyproject.toml asks for mujoco 2.2.0 or newer alongside gymnasium 1.2.0 or newer, numpy 1.21.0 or newer and PettingZoo 1.23.0 or newer. If you need the older environments that depend on mujoco-py, the README gives a separate extra: pip install gymnasium-robotics[mujoco-py]. A second extra, mujoco_py_original, pins the older mujoco-py with cython below 3.
That legacy path is the practical risk in this project. An environment version, a bindings generation and an extra all have to agree, and the matrix is not something the README tabulates for you.
Platform support is stated plainly: Linux and macOS are supported and tested, Windows pull requests are accepted but not officially supported. The package metadata says the same thing more precisely, requiring Python 3.11 or newer and classifying 3.11 through 3.14.
Where simulation environments stop being enough
The first limitation is the one every simulator carries: a policy that works in MuJoCo has not proven it works on hardware. Contact dynamics, actuator lag and camera artefacts all differ, and a Fetch arm that reaches reliably in simulation will need tuning on the real arm.
The second is the environment catalogue itself. If your task is not one of these, the package does not help. It also does not simulate the hardware it abstracts, such as joint limits under real load, so the embodiment parameters are a model rather than a measurement.
The third is the D4RL situation. The environments were refactored to sit on Gymnasium, and the README warns the action and observation spaces may differ from the originals. Any published result or dataset indexed against the original spaces needs re-checking before comparison, and the README points to the per-environment documentation for that.
The alternative approaches differ in what they give you. Building a custom Gymnasium environment may be an alternative when you need a task outside the bundled catalogue. Using an older environment collection preserves the original spaces at the cost of no longer being on the maintained API. Writing a custom MuJoCo scene gives you a simulator without the GoalEnv contract, which means implementing your own reward function and your own HER relabelling.
A note on data: the README lists generating new D4RL environment datasets with Minari as work in progress, so a dataset that does not exist yet should not be planned around.
Maintenance and project shape
The project is maintained by Kallinteris Andreas with help from the wider Farama team, and the package metadata classifies it as Development Status 5, Production/Stable, with the intended audience as Science/Research and the topic as Scientific/Engineering, Artificial Intelligence.
The release pattern is worth noting against that classification. The last tag is v1.4.2 from 2026-01-02, after v1.4.1 in July 2025 and v1.4.0 in June 2025, and the last push to the repository was on 2026-10-14. So there is steady work on main without a tag for it, and the citation block in the README still names version 1.4.0.
The packaging is conventional: setuptools as the build backend, requires-python of 3.11 or newer, and a setup.py that reads the version out of gymnasium_robotics/__init__.py rather than duplicating it. Pre-commit is enabled and the code style is black, both stated in badges and a .pre-commit-config.yaml at the root.
The licence is MIT. Documentation is at robotics.farama.org, and the README mentions a public Discord server that is also used to coordinate development, which is where environment questions and coordination both go.
Editorial conclusion
Adopt Gymnasium-Robotics when you need a simulated manipulation or locomotion task that follows the Gymnasium API and supports goal-conditioned training with Hindsight Experience Replay. Do not adopt it for a MuJoCo model you built yourself, since these are fixed environments. Before installing, confirm you are on Python 3.11 or newer and install the MuJoCo engine separately, and read the D4RL documentation if you plan to reuse its data, because those environments were refactored and may not match the original spaces.
Frequently asked questions
How do I install Gymnasium-Robotics?
Run pip install gymnasium-robotics, then install the MuJoCo engine from DeepMind separately using the instructions on the MuJoCo site. Python 3.11 or newer is required, and Linux and macOS are the supported platforms.
What is the GoalEnv multi-goal API?
The robotic environments inherit from GoalEnv, which requires a dictionary observation space with observation, desired_goal and achieved_goal. It exposes compute_reward, compute_terminated and compute_truncated so those values can be recomputed with a substituted goal, which is what Hindsight Experience Replay needs.
Can I still use the old mujoco-py environments?
Yes, through an extra. The current environments use the maintained MuJoCo bindings; the older mujoco-py versions are available with pip install gymnasium-robotics[mujoco-py], and mujoco_py_original pins the older bindings with cython below 3.
Are the D4RL environments the same as the originals?
No. They have been refactored and may not have the same action and observation spaces as the originals. Read each environment's documentation before comparing them with published results.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/farama-foundation-gymnasium-robotics)Was this useful?