chocopan/chocopan-t3-reverse-oracle-hdf5-v1p-file

chocopan-t3-reverse-oracle-hdf5-v1p-file

Raw HDF5 output of a scripted oracle for reverse manipulation tasks in simulation -- take an object out of a container or off a plate and put it back on the table. This batch adds visual appearance variation: every job runs a perturbed scene file rather than the canonical one.

Two families of perturbation, both baked into the BDDL / scene definition rather than applied at run time:

Everything else -- the task, the objects, the goal predicate, the oracle -- is the same as in the canonical batches, so this is a clean appearance-only axis.

This is the raw, unfiltered output of the generator, in LIBERO's create_dataset.py HDF5 layout. It is published because it is bulky to regenerate, not because it is the recommended training format -- for training, use the RLDS build linked below.

Contents

The job directory name is the perturbed task stem, e.g. KITCHEN_SCENE1_take_the_black_bowl_off_the_cabinet_and_put_it_on_the_table_light_424. The sidecar JSON keeps the perturbed bddl_path, and its problem_name / env_name carry the upstream variant id (..._kitchen_light_sync_modified_101 and similar), so a job can always be traced back to the exact scene it was rendered from.

How it was generated

A scripted oracle drives LIBERO's ControlEnv with the OSC_POSE controller at a 20 Hz control frequency: it plans a grasp on the target object, lifts it out of its container or off its support, and places it in a goal region on the table. The task definitions are BDDL files derived from LIBERO / LIBERO-plus forward tasks by swapping the initial and goal predicates; for this batch the BDDL files are additionally the perturbed-scene variants described above.

An episode is accepted only if the goal predicate is satisfied and no non-target object moved by more than 1 mm. Both outcomes are kept here: the sidecar JSON carries an accepted flag, and rejected attempts stay in the repository so their failure modes remain inspectable.

Seeds are deterministic and recorded in every sidecar JSON, so the batch is regenerable.

Layout

<JOB_NAME>/
  episode_0000.hdf5        # trajectory
  episode_0000.json        # sidecar metadata
  episode_0000_sheet.png   # contact sheet of the episode
  ...
results_<JOB_NAME>.json    # per-job outcome summary         (top level)
log_<JOB_NAME>.txt         # per-job generator log           (top level)
batch_summary.json         # counts and timings for the whole batch

Images inside the HDF5 are in the simulator's OpenGL (bottom-up) orientation. The RLDS conversion rotates them 180 degrees to reach the OpenVLA convention -- do the same if you read the HDF5 directly.

Loading

# one job directory, rather than the whole repository
hf download chocopan/chocopan-t3-reverse-oracle-hdf5-v1p-file --repo-type dataset \
  --include "<JOB_NAME>/*" --local-dir ./chocopan-t3-reverse-oracle-hdf5-v1p-file

# or only the lighting half
hf download chocopan/chocopan-t3-reverse-oracle-hdf5-v1p-file --repo-type dataset \
  --include "*_light_*/*" --local-dir ./chocopan-t3-reverse-oracle-hdf5-v1p-file

import json
from pathlib import Path

import h5py

for episode in sorted(Path("./chocopan-t3-reverse-oracle-hdf5-v1p-file").glob("*/episode_*.hdf5")):
    meta = json.loads(episode.with_suffix(".json").read_text())
    if not meta["accepted"]:
        continue                       # failures are kept in this repository
    with h5py.File(episode, "r") as f:
        demo = f["data"]["demo_0"]
        actions = demo["actions"][:]                       # (T, 7) float64
        states = demo["states"][:]                         # (T, D) flattened MuJoCo state
        agentview = demo["obs"]["agentview_rgb"][:]        # (T, 256, 256, 3) uint8
        wrist = demo["obs"]["eye_in_hand_rgb"][:]          # (T, 256, 256, 3) uint8

Open one file and inspect it before writing a loader against the field names above; the sidecar JSON is the authoritative description of what a given episode contains.

Limitations

• —Failed attempts are included (accepted: false in the sidecar), on purpose, so that failure modes stay inspectable. Filter on accepted unless you want the failures.
• —Only 10 attempts per scene variant, so per-variant accepted counts are small and uneven.
• —The perturbations are appearance-only. Object placement and the robot's initial pose are unchanged here; those axes live in the sibling batch below.
• —Synthetic: scripted-oracle trajectories, not human teleoperation.
• —Bulky and awkward for training. The RLDS build is the format a training pipeline should read.
• —No normalisation statistics are shipped here; they belong to the RLDS build.

Known caveats

The data/demo_*.attrs['model_file'] MuJoCo XML embedded in every episode contains absolute asset paths from the recording machine (e.g. /mnt/e/.../LIBERO-plus/..., /home/<user>/.../LIBERO-plus/...). They are informational only; the simulator never re-reads them, and the BDDL name in bddl_file_name is what identifies the scene. Sidecar JSON files were rewritten to repo-relative paths before upload.

Related

Sources and license

Released under the MIT license. Upstream terms still apply to anything derived from LIBERO / LIBERO-plus; the LIBERO-plus source repository carries no license file, while its Hugging Face distribution is published as MIT.