← Explore worlds

robosuite 1.4.0 environments

The 17 manipulation environments that robosuite registers at its 1.4.0 release, each exported as the model the environment itself composes and resets.

They are 9 distinct scenes: eight of the 17 are registered single-object variants of Nut Assembly and Pick-and-Place and reuse their base scene.

Source and rights

robosuite is pinned at commit fbee5844ff5632f5b5698e204ec5357ca50be0df, which is the tag v1.4.0; setup.py and robosuite.__version__ both say 1.4.0. The repository carries one licence file, the root MIT licence.

It publishes no separate attribution for the robot, gripper and object meshes or the textures, so none is claimed here.

No mesh or texture is rehosted. The scenes reference 86 files (50,490,078 bytes) that load from the pinned commit; the asset closure lists each one with its byte size, SHA256, git blob id and the scenes that use it.

Every file was checked against the blob the pinned tree records.

The environment list is read from the source, not assumed: EnvMeta in environments/base.py registers every environment class except five abstract bases, and robosuite/__init__.py imports nine manipulation modules.

ToolHang and TwoArmTransport belong to later releases and are not in this one.

Configuration

Each scene is robosuite.make(name, robots="Panda", controller_configs=load_controller_config(default_controller="OSC_POSE")) with rendering and camera observations switched off. The two-arm environments get two Pandas.

Every other argument is left at the class default: 20 Hz control, horizon 1000, default grippers and mounts.

Panda with the operational space controller is what the pinned benchmarking page recommends for the nine environments, and what the shipped demonstration files record.

The native environment reports a PandaGripper on a RethinkMount, the WipingGripper for Wipe, no gripper for TwoArmPegInHole, and the opposed arrangement for two arms.

Runtime: CPython 3.12.3, MuJoCo 3.1.6, NumPy 1.26.4, in an isolated environment with an unmodified checkout.

setup.py asks for mujoco>=2.3.0; this is the runtime already used for the same robosuite commit under LIBERO, without LIBERO. The exact packages are in scripts/worlds/robosuite-native-requirements.txt.

What one scene is

The published XML is env.model.get_xml(), the string the simulator was compiled from, after the environment's own reset() under random.seed(0) and numpy.random.seed(0), in an interpreter started with PYTHONHASHSEED=0.

The hash seed matters for NutAssemblySingle and PickPlaceSingle: they choose the kept object with random.choice over a Python set, whose order follows that seed, so the two seeds alone do not reproduce them.

Three things are changed, and only these. Asset paths become references to the pinned repository.

Values that reset() writes into the compiled model instead of the XML are written back: the door position, the Pick-and-Place target outlines, the 100 wipe markers.

Geoms given as fromto carry the position, orientation and size MuJoCo compiled them to (one visual and one collision cylinder on the door handle). The reset joint positions are stored as a keyframe.

Each export is checked three ways before it is written. A second, independent construction of the same environment and seed must give the same composed XML, joint positions and body poses.

The written file is compiled again and must reproduce every native body pose and every geom frame, size and colour; the largest error over all 17 scenes is zero. Every referenced file must be the pinned blob.

The .native.json next to each scene holds the body poses, joint map, mesh bounds and these checks.

A different seed, camera or reset is the same scene. A registered variant is a separate task entry with its own reset and success rule, on its base scene.

Under the same seed it composes byte-identical XML and differs only in the keyframe, where the unused objects are parked at (10, 10, 10).

Success

Each task's success rule is the environment's own _check_success, read from the pinned source.

Examples: cube height above the table by more than 0.04 m for Lift, door hinge beyond 0.3 rad for Door, pot bottom more than 0.10 m above the table for TwoArmLift.

robosuite environments do not end on success; they run to the horizon. Every reset scene reports _check_success() == False. A reset scene is not a run and no score is claimed.

Recording

No recording is published with these scenes yet. The pinned repository ships three demonstration files under robosuite/models/assets/demonstrations/.

The Lift file restores at this pin the way the repository's own playback script does without --use-actions.

The stored model is loaded with reset_from_xml_string and each recorded simulator state is set and forwarded, with Lift._check_success evaluated on every state.

scripts/worlds/import_robosuite_demo.py does this twice in fresh interpreters and compares the two; its replay is not published yet.

In the viewer

The home page lists the 17 environments. For each it shows the official arena file as a fragment; it does not open the composed scene yet.

The viewer's adapter, assets/worlds-adapter.js, expands a complete world with the remotes it declares per suite. It declares none for robosuite, so it rejects these scenes.

The registry therefore records all 17 assemblies as blocked. The composed scenes, their native reset states and the asset closure are published as files.

What is not here

The shipped Wipe demonstration was recorded with repository version 1.0.0.

MuJoCo 3.1.6 rejects its stored model (XML Error: problem reading attribute 'pos'), and Wipe's success needs the wiped-marker set that only stepping builds.

The shipped TwoArmHandover demonstrations from 2021 have no env_info attribute for the playback script and use older element names, so reset_from_xml_string fails at 1.4.0 (No "geom" with name robot0_g0_vis exists).

Neither is published.

The other environments have no demonstration in the repository.

The robomimic dataset repository states an MIT licence on its dataset card and needs no account, but the task datasets it distributes are version 1.5 files recorded with robosuite 1.5.1.

Its own test/test_v15.hdf5 does not restore at this pin.

The recorded arguments include lite_physics, which 1.4.0 rejects, and the stored model references bases/meshes/rethink_mount/pedestal.stl, a path that does not exist at this commit.

The robomimic documentation pages state no licence for the older 1.4.1-format files on the Stanford download server, so those are not used. No scripted controller or random-action rollout stands in for a recording.

The benchmark atlas has no robosuite identity column yet; this page is the suite's reference. The explorer does not run physics; the published scenes are the native reset state.

• Task inventory and scene registry
• Asset closure: every referenced file with size, hashes and origin