Contributing
The Oopsie Dataset is a community effort. We are collecting failure data from diverse robots, tasks, and environments.
Currently, we focus on single-arm and bi-arm manipulator robots. To ensure the collected data is broadly useful across different labs, we are especially interested in data from standardized setups, such as the DROID Franka setup, the SERL Franka setup, the Trossen Aloha setup, the Trossen WidowX Bridgev2 setup, YAM or ARX bimanual setups, etc. However, if you have other systems that you believe will be useful for the community, please also submit your data! Failure data on non-standard systems is still very useful for many research directions.
Why should YOU contribute?
Open data and cross-lab collaboration are how academics take on ambitious robotics projects. Beyond that, contributing labs get:
- A say in the dataset. Take part in shaping the dataset and adapting the tooling, the data format, and the utilities we build around it for your use-case.
- Early access. Contributors get pre-release versions of the dataset for their research. Having your own robot in the dataset also means future work built on it comes with lab-specific fine-tuning data for free.
- Co-authorship. Everyone who collects a substantial amount of data and gives us feedback can qualify as a co-author on the public dataset release.
Contribution Requirements
We are currently calling for the first round of contributions, which will run until Oct 5th 2026. We welcome data contributions from all robotic manipulators, especially common setups such as Franka, WidowX, YAM, and UR. Major contributors who meet the requirements below can qualify as authors of the dataset, and minor contributors will also get acknowledged for their contribution as well!
What to contribute
Logged policy rollout data (image observations, actions, proprio states, etc.) on real robot manipulators, including both successes and failures. Episodes must be submitted in our required data format, and every episode must carry a success/failure label.
Requirements for authorship
A contribution can qualify for authorship if it meets all of the following:
- Volume: 750+ qualifying episodes of logged rollout data, with at least 350 of them being failures. These data should add up to no less than 5 hours of real robot time (which averages 24s per rollout for 750 rollouts, so submitting e.g. all 1-second rollouts will not qualify).
- Task diversity: at least 4 distinct tasks, where “distinct” means a different language instruction or a completely different scene layout. In an effort to make the data more diverse, we encourage having 3 or more different initial object layouts within the same task.
- Per-task cap: at most 200 episodes from any single task count toward the 750. Additional episodes of that task are still welcome and will be included in the dataset — they just don’t count toward the threshold.
Requirements for acknowledgement
A contribution will be acknowledged if it has 200+ qualifying episodes of logged rollout data.
Data Requirements
We are looking to create a large-scale dataset of robot failures in real based on failing policy executions that will be useful for various downstream applications. In general, most types of failures are good contributions to the dataset. However, several ways of generating failures make downstream training harder, or create redundant data.
We therefore provide some guidelines on how to generate good failure data:
- Keep the data from your embodiment as is (aside from necessary reformatting): Some prior work artificially create failure examples by corrupting the data post-collection, e.g. by adding noise to the action space. However, this destroys important information for use cases such as world model training. If you corrupt actions, please re-execute the policy to generate a proper trajectory.
- Do not change the context of the data: It is easy to relabel success data as failure by changing the task label post-collection. However, these types of failure augmentations are easy to create at training time for any downstream application, and there is therefore little additional value in explicitly adding them to a failure dataset.
- Vary your task setup: Many interesting failures can be generated by exploring how robust your policies are to minor changes in your task setup. For example, you can randomize the placement of objects, change the lighting setup, or create different backgrounds from object clutter. Be creative and challenge your policies!
Who can contribute?
Anyone who rolls out a policy on a real robot. If the robot is moving under a policy, you are already generating the data we need:
- Policy evaluation. Every eval run produces exactly the mix of successes and failures we are after.
- RL experiments. Online training rollouts are full of the suboptimal behavior that is missing from every other dataset.
- Play data collection. Unscripted interaction, including the parts that go wrong.
You do not necessarily have to run anything extra; you just have to keep what you would otherwise throw away.