domino_real: bring-up Stages 2 and 3 -- a perception check and a launcher

[amburger66]

Why

Bring-up Stages 2 (live cameras, no motion) and 3 (human resets) had no vehicle.

replay_plan structurally cannot do either — it forces perception and human resets off so a fixed-plan replay stays reproducible. The only alternative was the active-learning launcher, which spends a full predicate-invention episode with LLM calls to take three camera readings, and buries the numbers in its log. Stage 2's checks are a tight edit-run loop (read, nudge a domino, read again, topple one, read again), so the tool needs to take seconds.

What's here

scripts/domino_debug/check_perception.py — measures the live ZED scene against the simulated twin. Nothing moves: RealRobot is built with no arm, so it runs with the robot powered down and needs no polymetis controller.

It goes through make_real_robot and the env's own state_from_observation — the exact conversion RealRobotExecutor uses at an option boundary — so a disagreement here is a real disagreement rather than an artifact of a parallel code path.

Two reporting choices that matter:

• Per-domino, not just the worst number. _max_position_divergence returns only the maximum, but Stage 2's moved-domino check has to identify which domino moved. A different one moving means the capture-id → slot mapping is wrong, which is the failure this stage exists to catch.
• Mean dz and its spread, separate from position error. A constant z offset across every domino is a table-height disagreement (domino_real_table_z), not a perception error — different fix entirely.

--repeat samples the noise floor across captures, which is what real_robot_divergence_atol should be set from; it currently ships as a guessed 0.02.

observe_scene in real_robot_bridge.py — the bare look, without reset_env's arm homing and human prompt or execute_chunks' motion.

scripts/configs/predicatorv3/stage3_domino_real.yaml — Stage 2's flags plus real_robot_human_reset, driven by oracle rather than the agent. This stage tests reset plumbing; running the learner alongside it would make a failure ambiguous between the two, which is the attribution the staged ladder exists to preserve. Oracle needs no LLM.

It runs one episode per invocation, not the two the doc asks for: oracle is not learning-based, so main.py takes the non-learning branch — a single _run_testing over this env's single generated task, and num_test_tasks is ignored. The header says so and points at tests/envs/test_domino_real_online.py::test_each_episode_prompts_exactly_once, which already covers the across-episode cadence in simulation.

Testing

Both stages verified on hardware.

Locally on the changed files: pylint (with .predicators_pylintrc), yapf, isort, docformatter and mypy all clean. The Stage 3 config resolves to pybullet_domino_real + oracle_process_planning with all four real-robot flags intact.

Note

Rebased onto master after #112. The scene-path edits this branch originally carried were dropped — #112 landed them identically.

Touches real_robot_bridge.py, as does probe-lazy-grounding, but in a different function (observe_scene vs _split_actions); whichever merges second will want a rebase.