mahgoobi/mcts-value-data
MCTS value data Dense value supervision for a robot manipulation critic, generated by running Monte-Carlo tree search offline as a supervision generator rather than online as a planner. A policy that is only ever scored at the end of an episode gives one number per episode. Running MCTS from a recorded scene and backing terminal outcomes up the tree turns that one number into a value for every state the search visited — 85,747 of them here, from 250 searches over 13 tasks.… See the full description on the dataset page: https://huggingface.co/datasets/mahgoobi/mcts-value-data.
MCTS value data
Dense value supervision for a robot manipulation critic, generated by running Monte-Carlo tree search offline as a supervision generator rather than online as a planner.
A policy that is only ever scored at the end of an episode gives one number per episode. Running MCTS from a recorded scene and backing terminal outcomes up the tree turns that one number into a value for every state the search visited — 85,747 of them here, from 250 searches over 13 tasks.
What a value is
V(node) is the mean terminal utility of its subtree, over the tiers the benchmark scores an episode with:
That identity is exact, not an approximation of the MCTS backup — it reproduces it, and it can be recomputed from the tables by anyone who wants a different utility.
How it was collected
rewind's branch-and-rollback search over the RoboTwin simulator: snapshot a state, run a chunk of actions, restore, try a different chunk. Each run is 48 continuations from one scene, with progressive widening ceil(2.0 * N**0.5) capped at 8 children.
Selection is uniform, deliberately. UCT concentrates samples on the branch it already believes in, which is right for finding a plan and wrong for regression targets — the resulting values are biased towards the arm that was explored. Uniform selection costs plan quality and buys unbiased targets, which is what this corpus is for.
Total: 4,274,850 simulator steps over 221 GPU-hours.
Per task
Seeds come from the 50000+ collection block, never the 40000+ evaluation bank — a critic trained here is not scored on scenes it has already seen.
Read "solved" carefully
It does not mean the policy solves the task. It means at least one of the 48 sampled continuations reached the goal. Per-continuation success is 56.1% (6,738 of 12,000 endings), ranging from 30.9% on move_cup_put_pen_in_cup to 76.2% on place_bowl_in_dishrack_ks. At that rate, the chance none of 48 succeeds is about 7e-18 — so 99.2% measures the sampling budget, not the policy. The gap between 56% and 99% is the headroom a perfect critic could recover, which is the reason this corpus exists.
Two runs found no success in any continuation: put_milktea_on_shelf seed 50007 and put_phone_on_holder seed 50003.
Layout
data/nodes/task=<task>/run_id=<timestamp>/<search_id>.parquet states, values, tiers, frames
meta/searches/<run_id>__<search_id>.parquet one row per run
figures/convergence/<task>_seed<n>.svg root value vs continuations
figures/trees/<task>_seed<n>.svg the search tree, valuedsearch_id is task__task_config__seed<N> and names the scene, so it is deliberately not unique — two runs of one scene share it. run_id is what separates them, which is why it is a partition of its own.
Every node carries its own observation — one image per camera and the robot pose — so a scorer reads identical inputs for every candidate out of a state and can only earn a score by ranking actions.
Figures
Two seeds per task — 26 of each, as SVG under figures/ and PNG under figures/png/.
The root's value, as the evidence arrives
V(root) after each of the 48 continuations, with a ±1 s.e. band. The band assumes independent draws; a tree's are not, since simulations share prefixes — so it is honest about when an estimate has settled and optimistic as a confidence interval.
Two things to read off it. The tasks span 0.917 to 0.146 — a sixfold spread in what a scene is worth to this policy — and every panel has flattened by roughly continuation 20, which is the budget of 48 justifying itself.
The search trees, valued
Every node filled by its subtree value on a red→yellow→green ramp, sized by the endings behind that value, and ringed if it ended. The fill is the value; the ring is the tier.
The shape is the point: progressive widening spends the budget near the root, so the tree is wide and shallow — 8 children at depth 1, 40 at depth 2 — and each of those runs out to the horizon as a spine of nodes sharing one value until the ending that set it.
Reading it
from rewind.scoring.dataset import runs, read
from rewind.record import values
index = runs("mahgoobi/mcts-value-data") # one row per run
nodes = values.read_nodes(record, search_id) # one run's tree
V = values.subtree_values(nodes) # node_id -> (value, endings)rewind is at <https://github.com/EAI-RSM/rewind>.
Caveats
- A tier is latched at the first physics substep its predicate holds, not at a settled state — so a success frame can show the object still in motion. The benchmark's own evaluation latches identically, so search and eval agree; but a "settled" outcome is a different question this corpus does not answer.
- Five tasks score position without orientation.
put_stapler_next_to_mousepasses 77 of 500 successes with the object more than 45° off upright;put_mouse_on_padhas one at 170°. That is the benchmark's criterion read faithfully, not a collection defect, but a consumer who cares about pose should filter on it. - Values are exact for the tree that was searched. They are estimates of the true value only to the extent 48 continuations sample it, and the ±1 s.e. band in the convergence figures is the optimistic version of that.