docs: staged real-robot bring-up procedure - #105
Draft
amburger66 wants to merge 3 commits into
Draft
Conversation
A checkable procedure from a captured scene through oracle-in-sim, a dry executor, live cameras, first motion, and the closed loop, to real active learning. Ordered so each stage adds exactly one new source of failure -- a failure three stages later is much harder to attribute. Two stages exist to replace guessed defaults with measurements: real_robot_divergence_atol (0.02 m) and real_robot_settle_s (0.5 s) both ship as guesses, and the doc says where the numbers come from rather than suggesting the tolerance be raised until the warning stops. Calls out what has never run: per-option shipping at the hand (every prior hardware session shipped whole episodes), and live perception through the conversion path. Every flag name, default, path and symbol cited was checked against the code.
Stage 1 said to un-skip domino_real in oracle.yaml and offered a bare
`python predicators/main.py --env pybullet_domino_real --approach oracle`
for one-off overrides. Following that produced
AssertionError: perceived 4 dominoes but only 3 slots
because a bare main.py run inherits none of the env's flags from
envs/all.yaml, and this env does not work on the settings.py defaults --
domino_use_domino_blocks_as_target defaults False, which sizes the domino
component with the target as a separate object. The doc now points at
predicatorv3/oracle_domino_real.yaml and warns against main.py rather than
suggesting it.
Two traps added, both hit while running Stage 1 for real:
* The scene path must be set in the launcher. envs/all.yaml already sets
domino_real_scene and a config value beats the settings.py default, so
editing settings.py has no effect on a launcher run.
* `import predicators` resolves to the editable install, not the cwd, so
running from a worktree silently executes another checkout's code. The
symptom is a fix that appears to do nothing; the doc gives the one-liner
that shows which tree is actually loaded.
Stage 1 also now says to read the init atoms before believing a pass -- a
goal already true in the initial state yields a length-0 plan and a SOLVED
that means nothing -- and describes what the oracle actually plans over:
hand-written processes, including the two exogenous ones that are the
cascade, on a lattice of loc/angle helpers. That lattice is the likeliest
reason a continuous capture fails, which separates "re-capture the scene"
from "debug the code".
The launcher itself lands in the roll-fold PR; this doc depends on it.
Author
|
Updated Stage 1 and the flags section to run through Depends on #106, which adds that launcher (alongside the roll-fold fix). Merging this doc first would leave Stage 1 pointing at a file that does not exist yet. Also added two traps hit while running Stage 1 for real: the scene path must be set in the launcher ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Docs only — no code changes.
A staged bring-up procedure for the real Franka, from a captured scene to closed-loop active learning. Ordered so that each stage adds exactly one new source of failure, because a failure three stages later is much harder to attribute.
Three things the doc is deliberate about:
max_initial_demos: 0 # can't solve the real scenenote inenvs/all.yaml— that's about the demo generator, not the oracle approach, but it's a warning about this scene.RealRobot's session-wide gripper dedup, and the doc says to verify that at the hand rather than in the log.real_robot_divergence_atol(0.02 m) andreal_robot_settle_s(0.5 s). Stages 3 and 7 exist to measure them, and the doc explicitly says not to raise the tolerance until the warning stops.Also documents the safety ordering to confirm at Stage 4 — the arm homes before the human is prompted — so it's already trusted by Stage 8.
Every flag name, default value, file path and symbol cited was checked against the code (23 assertions, 0 mismatches), so the doc can't drift silently from the defaults it quotes.
Caveat, stated in the doc itself: nothing in Stages 3+ has been validated on hardware. The pass criteria are what I'd check, not results anyone has seen.