Heuristic:ARISE Initiative Robosuite Hard Reset Vs Soft Reset
| Knowledge Sources | |
|---|---|
| Domains | Robotics_Simulation, Debugging |
| Last Updated | 2026-02-15 07:00 GMT |
Overview
Choosing between `hard_reset=True` (full model reload) and `hard_reset=False` (sim state reset only) involves tradeoffs between determinism, speed, memory, and platform-specific crash risks.
Description
Robosuite environments support two reset modes via the `hard_reset` parameter. A hard reset destroys and reloads the MuJoCo model, simulation, and renderer from scratch on each `reset()` call. A soft reset (default when `hard_reset=False`) only calls `sim.reset()` and reinitializes robosuite-internal variables. Hard resets are slower but guarantee a completely clean state. Soft resets are faster but can accumulate subtle state drift and have known platform-specific issues including segfaults on macOS and GLFW errors on Linux when used with domain randomization.
Usage
Use this heuristic when choosing the `hard_reset` parameter for your environment, especially when:
- Running domain randomization (where `hard_reset=False` can cause segfaults)
- Collecting demonstrations (where deterministic replay requires consistent initial states)
- Training RL agents (where speed matters and `hard_reset=False` is preferred)
- Preserving backward compatibility with datasets from robosuite <= 1.4.1
The Insight (Rule of Thumb)
- Action: Set `hard_reset=False` for RL training and interactive teleoperation where speed matters.
- Action: Set `hard_reset=True` for data collection and demonstration recording where determinism is critical.
- Warning: When using `DomainRandomizationWrapper`, `hard_reset=False` is actually required to avoid segfaults on macOS and GLFW errors on Linux. This is a known bug.
- Trade-off: `hard_reset=True` is slower (full model reload per episode) but guarantees a clean simulation state. `hard_reset=False` is fast but risks subtle physics drift.
- Backward Compatibility: Set `lite_physics=False` to preserve compatibility with datasets collected in robosuite <= 1.4.1.
Reasoning
Hard reset destroys the `sim`, `model`, and render objects, then reloads the MJCF XML and reinitializes everything. This is expensive but provides a guaranteed clean state. Soft reset only calls `mj_resetData()` which resets simulation data (qpos, qvel, time) but does not re-parse the XML or reinitialize the renderer.
The domain randomization segfault occurs because the DR wrapper modifies model properties in-place, and a full model reload (hard reset) can invalidate pointers or cause OpenGL context issues. The specific comment in the demo code states: "Not setting this flag to False brings up a segfault on macOS or glfw error on Linux."
For demonstration collection, the `DataCollectionWrapper` uses a trick to ensure deterministic replay: it records the full XML string and simulation state at episode start, then replays by reconstructing from that XML. This works more reliably with hard resets since the entire model is freshly loaded.
Code evidence from `robosuite/demos/demo_domain_randomization.py:57`:
hard_reset=False, # TODO: Not setting this flag to False brings up a segfault on macos or glfw error on linux
Code evidence from `robosuite/environments/base.py:290`:
if (self.sim is None) or (self.hard_reset and not self.deterministic_reset):
if self.renderer == "mujoco":
self._destroy_viewer()
self._destroy_sim()
self._load_model()
self._initialize_sim()
else:
self.sim.reset()
Code evidence from `robosuite/environments/robot_env.py:71-72`:
lite_physics (bool): Whether to optimize for mujoco forward and step calls to reduce total simulation overhead.
Set to False to preserve backward compatibility with datasets collected in robosuite <= 1.4.1.