Repository navigation
RoboDojo-Sim: a program as the policy (first implementation) - #102
Draft
ruiling-smartbear wants to merge 14 commits into
Draft
ruiling-smartbear wants to merge 14 commits into
ruiling-smartbear wants to merge 14 commits into
Conversation
examples/aspire_libero/ adds LIBERO's Object, Spatial, Goal, Long (libero_10) and LIBERO-90 suites as tasks of ASPIRE's harness (cap-harness --benchmark libero-pro): 130 task rows, run.yaml (the four ten-task suites), run_90.yaml, smoke.yaml and a launcher that starts the Robosuite example's on this folder. The Robosuite example's engine now takes the benchmark from the task row: the venv that holds cap-harness, the init mode (LIBERO: seeded, so a seed is a scene of its own), the simulator's environment and the benchmark's docs page (LIBERO's without the section that names ASPIRE's worked programs per task). A row without the field is Robosuite's, as before. prepare.py's seeds are presets (--preset aspire|smoke) and its row and split writing is shared.
…out's pages The LIBERO configs granted $ASPIRE_ROOT/docs/libero-pro.md to the task sandbox, whose "Task examples" section names ASPIRE's worked programs per task; only the workspace copy was cut. launch.sh now stages the docs outside the checkout (stage_docs.py) and the Codex configs of both examples grant those (agent.params.aspire_docs). A benchmark page without its cut is refused rather than copied whole. LIBERO's demonstration datasets are hidden from the simulator's sandbox.
smoke_luna.yaml is smoke.yaml with GPT-5.6-Luna acting and coordinating on the Codex ChatGPT login. The launcher asks for FIREWORKS_API_KEY only when the config's models are Fireworks'.
examples/robodojo_sim/ adds RoboDojo-Sim's forty-two bimanual tasks. A Codex session writes policy.py (act(obs) -> actions), develops it on the task's development layout set through a simulator service on the host, and the judge scores it on the held-out layout sets with RoboDojo's own success check. RoboDojo evaluates the harness's XPolicyLab policy (utils/policy/hermit_program): its server never imports the program but runs it as a worker in a bubblewrap sandbox with no network that reads nothing of RoboDojo's checkout, which holds the layouts, the success conditions and the results; the episode loop that runs in the simulator's process is the harness's, and the engine refuses an installed policy that differs from it. The ASPIRE example's simulator service separates its seed rules from what it runs (_validate, _launch), which this example's service replaces.
…nor read the run's output An independent review found that a program could make RoboDojo abandon a layout unscored (a partial action raises in its simulator; a number that overflows float32 passed the finite check) and that the judge divided by the layouts that had a result. - Every action that reaches the simulator is whole and bounded: both arms of one mode and both grippers, what the program left out filled from the observation, numbers checked after the cast. - The judge scores the first eval_layouts of each held-out set against that fixed count: a layout with no result is a failure, and its replacement is not counted. - The program's worker reads a directory holding the program alone, not the run's output (where a held-out evaluation writes its results as it runs); the sandbox's own check finds the checkout and the run's directories missing inside. - RoboDojo's log and the sandbox record stay with the service, not in the workspace; a stopped run's resume manifest is removed from the checkout; the service stops its simulators; one simulator per GPU across the service and the judge (a file lock). - Host-side reads of a session's files and the program check take anything.
…t on an Object task
…ep's init mode is tested
…r on the host; run against RoboDojo
This branch has not been deployed
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
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.
Change
Adds RoboDojo-Sim (arXiv:2607.04434; 42 bimanual ARX X5 tasks in Isaac Sim, five capability dimensions) as a task. A first implementation, written from RoboDojo's and XPolicyLab's source and tested against a stand-in; on the real simulator the engine has run a program's evaluation, and no smoke or training run has been made. Stacked on #100 (it uses that PR's simulator service); the change of this PR is
examples/robodojo_sim/and the service's_run.RoboDojo evaluates a policy served through XPolicyLab. Here the policy is a program: a Codex session writes
policy.py(act(obs) -> actions), develops it on the task's development layouts throughbin/sim, and the judge scores it on held-out layouts with RoboDojo's own success check.examples/robodojo_sim/utils/policy/: the harness's XPolicyLab policyhermit_program(model.py,deploy.py,deploy.yml, launch scripts), the program'sworker.py,install.py.utils/agent/dojo.py: the engine (onescripts/robodojo.sh eval, its result per layout; withROBODOJO_IMAGE, the simulator in RoboDojo's container and the policy server on the host,split_eval.sh, for a host on which Isaac Sim does not install);dojo_service.py,sim_cli.py: the simulator service andbin/sim;task.py, the prompt and the interface page.utils/prepare.py: the 42 tasks; development on layout set 2 (first 10 layouts), held-out on sets 0 and 1 (first 25 each). This is not RoboDojo's leaderboard protocol (three sets, 50 layouts each); the README says so.prompt_only/:run.yaml,smoke.yaml,launch.sh(prompt-only template, built-in Codex Evolver).examples/aspire_robosuite/utils/agent/sim_service.py:_runkeeps the shared rules (assigned seeds, the output moved without following a link) and calls_validate/_launchfor what is run; no behavior change for ASPIRE.What a program can reach (README, "What a program can reach"): RoboDojo's success check reads privileged state, and its checkout holds every set's layouts, the success conditions and the results beside the policy server. The server never imports the program: it runs it as a worker in a bubblewrap sandbox with no network that reads only the worker and a directory holding the program alone (not the run's output); every action that reaches the simulator is whole and bounded, and the judge's denominator is the fixed number of held-out layouts, so a program cannot drop a failing layout from its score; the episode loop in the simulator's process is the harness's, and the engine refuses an installed policy that differs from it; a session runs only its development set.
Validation
python -m pytest examples/robodojo_sim tests/methods/aspire -qon Linux with bubblewrap and numpy: 44 passed (8 RoboDojo, 36 ASPIRE). On macOS: 34 passed, 10 skipped (need bubblewrap).utils/tests/test_robodojo.py:FAKE_EVAL) runs the installed policy's realModel, worker anddeploy.pyunder the real sandbox. Under it: a program is scored by what it does; a program that tries to read a layout file of the checkout, write intoeval_result/, open a socket or find the run's output gets none of them and fails its layouts; a partial action reaches the stand-in whole (it raises on a missing key, as RoboDojo does); a number that overflows float32 never reaches it; a program that raises holds the joints and fails; an installeddeploy.pythat grants success is refused.f57e163with its pinned XPolicyLab5d0be14, the image of RoboDojo's Dockerfile and its Assets, throughdojo.EnginewithROBODOJO_IMAGEonstack_bowls, layout set 2: a program that holds still is scored on one layout (task_successfalse, RoboDojo's_result.jsonand videos delivered, nothing left in the checkout'seval_result/); a program that commands a joint target sees the joint follow (0.000 to 0.400 rad), the(480, 640, 3)image and the instruction, and its exception fails both of two layouts while the robot holds. The worker ran in its sandbox (sandbox/robodojo-program-1.json). About four minutes to start the simulator and three minutes for a layout of 800 steps.scripts/robodojo.sh evalon a native install. The configs' timeouts and budgets are not measured. Whether a program can solve a task from RGB alone is not known (the default observation has no depth or calibration).Review
examples/robodojo_sim/utils/tests/test_robodojo.py; docs:examples/robodojo_sim/README.md,examples/README.md,CHANGELOG.md.hermit.sandbox.Sandbox(dojo.Engine._worker). RoboDojo's own processes (the policy server, Isaac Sim) run on the host unconfined, as the judge does: they are RoboDojo's and the harness's code, and need the GPU and the checkout. The worker's sandbox record of a real run is as described in Validation.play_tic_tac_toe, whose three sets are the same layouts (README). The fixes and the container path have not been reviewed.