OopsieVerse adds object health to a robot simulation so completing a task and damaging the scene can be recorded separately. Its DamageSim component converts simulator signals into mechanical, thermal or fluid damage, then accumulates that damage in object state. That state can inform evaluation, demonstration selection or a learning objective.
Consider a simulated robot placing a bowl in a cupboard while knocking a nearby glass onto the floor. A goal defined only by the bowl’s final pose can mark the episode successful. Tracking the other object’s health preserves the consequence that the task-completion label omits.
Damage is a state derived from physical signals
The OopsieVerse project separates DamageSim from OopsieBench, its household task suite. The paper’s damage model tracks health at the link level and defines an object’s health using the minimum health among its links. The stated scale runs from 100 for undamaged to zero for fully damaged.
The health value is an output of the selected model. A collision count says that a contact event occurred; a damage state also depends on how that event is interpreted for the affected object. A metal pot and a fragile glass can experience similar contact signals while their configured damage responses differ.
This suggests retaining the signal and its mapping together. For a suspicious health drop, inspect the affected link, source signal, threshold and damage scaling. A single aggregate number is much less useful when the question is whether the policy struck too hard or the object’s configured response was inappropriate.
The available simulator signals determine which damage can be modeled
The paper’s mechanical model uses a threshold and scaling factor that can be specified per link. Its thermal model needs temperature information; the described implementation uses OmniGibson for that capability. Fluid damage likewise requires represented liquid interactions. Running the framework in two simulation backends does not mean every damage modality has identical support in each one.
Before selecting a task, map the intended failure to the available signal:
| Intended event | Information the model needs | A mismatch to investigate |
|---|---|---|
| Crushing a delicate object | Contact-related loading and object response parameters | Treating every object as equally fragile |
| Heating an unsuitable item | Temperature and exposure model | Assigning thermal damage without modeled heat |
| Spilling onto electronics | Liquid contact and resistance parameters | Treating a visible water texture as liquid exposure |
| Breaking one component | Link identity and object-health aggregation | Hiding a damaged component in an object average |
The examples are review questions rather than executed tests. They make clear which simulator property supports the reported health change.
Decide where health enters the learning problem
An evaluation can log health without supplying it to the policy. A training setup can instead expose it as an observation, penalize damage in the reward, or terminate episodes according to a damage condition. Each choice changes a different part of the experiment.
For example, a policy trained with privileged health observations may use information unavailable to a physical robot. A reward-only design can shape training without adding that field to deployment inputs. A termination rule can also shorten damaged episodes, changing the amount of motion represented in averages. State these choices alongside any comparison.
When filtering demonstrations, retain the original episode identity and the damage condition that removed it. Inspect whether filtering eliminated a failure strategy or simply removed the hardest initial conditions. A smaller selected dataset and a different task distribution are both possible outcomes.
Report damage and completion together
Keep task outcome, per-object health and the timing of damage events in the episode record. A mean over many healthy objects can hide one badly damaged item; inspect the object-level distribution as well. Separate the target object from surrounding scene objects when the task can harm either.
For general motion and interaction measurements, the existing bimanual coordination guide explains why object motion and contact forces convey different information. Here the additional step is an explicit model from simulator signals to accumulated damage state.
The project and paper were checked October 16, 2026. No simulation or physical damage test was performed here. Applying the method to another object starts with checking that object’s signal inputs and response parameters before interpreting a health score.