RoboMME Memory-Dependent Manipulation Policy

Design a manipulation policy for the RoboMME benchmark's long-horizon, memory-dependent tasks, starting from a random weak baseline. Maximize episode success rate; your submitted policy is re-run on sealed, re-seeded episodes for scoring.

Hard Constraints

• Modify only /app/methods/main/policy.py as the final submission.
• Keep the public class Policy with methods infer(inputs: dict) -> {"actions": np.ndarray} and reset().
• Declare a module-level ACTION_SPACE, one of three equally supported control interfaces: joint_angle, ee_pose, waypoint. All three are low-level formats driving the same robot on the same episodes, and in every one of them your policy is responsible for the whole trajectory — none of them hands off any part of the control problem to the simulator. Which one suits your method is a research decision and yours alone to make: the sealed episodes, the metric and the reward band are identical for all three, so switching interfaces changes how you solve the problem, never how you are scored. The starter happens to declare one of the three; there is no default and no preferred choice. The verifier rejects any value outside the three and scores the submission 0; /app/selfcheck.py refuses the same values, so you find out before you submit.
• Action shape follows whichever interface you declare — the benchmark's builder documents each one; joint_angle is (chunk_size, 8).
• Use only observations passed to infer; do not read episode metadata (seeds/difficulty) at run time.
• One full evaluation pass on the sealed episodes must finish within 60 minutes; keep per-step inference lightweight.
• Any files your policy needs (weights, caches) must live under /app/methods/main/.

What You Have

• The installed robomme package (at /opt/robomme, on PYTHONPATH) with the ManiSkill simulator: build environments for any task and any train/val episode via BenchmarkEnvBuilder and iterate freely; scripts/run_example.py and scripts/evaluation.py show the rollout loop.
• The package's oracle-planner demonstration wrappers (robomme.env_record_wrapper): you can generate your own successful demonstrations on train/val episodes for cloning or retrieval.
• /app/methods/main/policy.py: a weak random baseline implementing the interface.
• /app/selfcheck.py: runs your policy on a fixed subset of val episodes and reports success rate.
• 16 tasks in four memory suites (Counting, Permanence, Reference, Imitation); episode horizon up to 1500 steps.

What You Submit

Submit /app/methods/main/policy.py. The core research problem is what the paper calls memory design: your policy must remember and use information from earlier in the episode (counts, masked object locations, highlighted references, demonstrated procedures) that is no longer visible in the current observation. Rule-based state machines, retrieval over demos, learned models, or hybrids are all legal.

How It Is Judged

The verifier imports your policy in a restricted process and rolls it out on sealed episodes whose seeds differ from every train/val/test episode you can see, spread across all 16 tasks and difficulty levels. The metric is mean success rate over the sealed episodes; higher is better, and the score rises monotonically above the disclosed weak-policy floor. Strong long-horizon memory use is what separates a competent policy from the reactive starter.