Simulation reproduction planning
ASPIRE v1.0: Check the Host and Evaluation Before Running
Review ASPIRE LIBERO-Pro host requirements, gated SAM3 access, saved versus seeded evaluation, and the limits of structural checks and agent-generated code.
ASPIRE v1.0 packages workflows for coding agents, but a usable skill file is only one part of a reproduction. Confirm the host, model access, simulator and evaluation state policy before authorizing a run. Treat author-reported success, structural validation and physical demonstrations as different kinds of evidence.
Documentation inspection at commit fa00f0ef2bc1d91d594b9aa502c22133c9f538f7. RoboSkin.ai did not install or run ASPIRE, download gated weights, call a model API, accept dataset terms, or operate a robot. Proposed review steps are not completed experiments.
A version update, not a first release or new paper
The ASPIRE v1.0 commit has a committer timestamp of October 16, 2026 at 03:57:48 UTC and an author timestamp on October 15. The original paper was submitted to arXiv on June 30, 2026. Use the fixed commit below when comparing setup instructions; do not describe this update as ASPIRE first becoming public.
The versioned README packages iterative-debugging and evosearch skills for Codex and Claude Code, alongside simulation and real-robot recipes and demonstrations. Its 99% claim is author-reported benchmark evidence, not a RoboSkin experiment or a hardware reliability rate. Added demo material does not establish that a new independent physical validation occurred.
Check the provider host before interpreting a bootstrap result
The host guide requires uv on PATH and a working NVIDIA driver. The base cuRobo bootstrap supplies an nvcc wheel, so its base path does not require a system CUDA toolkit. That statement does not extend to the BEHAVIOR runtime below.
SAM3 weights are gated. Access approval and an authorized Hugging Face credential are separate prerequisites: a credential alone does not grant model access. A bootstrap can finish before model loading later fails with 401. We did not request access or download weights.
| Readiness question | Evidence to retain before a trial |
|---|---|
| Which host and GPU? | Operating system, GPU, driver and available resources; keep a dated inventory rather than assuming a laptop is sufficient. |
| Which provider is blocked? | Distinguish package installation from permission to load the model; redact credentials from logs. |
| Which runtime? | Identify LIBERO-Pro or BEHAVIOR explicitly before applying installation advice. |
LIBERO-Pro: preserve the runtime and check rendering
The LIBERO-Pro bootstrap initializes pinned submodules and a frozen .venv-libero environment. The guide discourages unpinned upgrades as an ad hoc repair. Offscreen rendering also requires libEGL.so.1; an NVIDIA driver alone is insufficient.
EGL device selection ignores CUDA_VISIBLE_DEVICES. The guide uses MUJOCO_EGL_DEVICE_ID as well to select the rendering GPU. Resource contention can look like a depth or point-cloud failure, so record GPU placement before attributing every failure to the generated policy.
BEHAVIOR is a separate resource and terms decision
The host guide additionally lists Python 3.11, a CUDA 12.x toolkit, glibc 2.35+, NVIDIA Vulkan support, about 12 GB for the environment and 40 GB for data, and 32 GB RAM. A CUDA 13 toolkit alone is rejected for that path.
The documented launch accepts the Omniverse EULA through OmniGibson; the dataset bootstrap requires explicit BEHAVIOR Data Bundle terms acceptance. Review those prerequisites before execution. The guide also warns that only one Isaac process can run at a time on its single-GPU bench. These are documented assumptions, not a universal performance guarantee.
Separate structural validation from task success
The LIBERO-Pro validation plans check resets, schemas, movement/hold ticks, close and resume behavior. Smoke uses seed 1; nightly uses seeds 1–3. These structural gates do not establish that manipulation tasks succeeded.
Default saved initialization selects (seed - 1) % N from a finite state set, typically 50. Higher seed numbers can therefore repeat earlier states. Seeded initialization samples through the environment RNG without restoring a saved state afterward; constrained tasks can still repeat layouts. The guide warns that older buggy seeded runs restored saved state 0. Record init_mode and the actual state coverage, not just a large seed count.
| Your proposed claim | What the evidence must establish |
|---|---|
| The environment is usable | Which structural checks passed on which runtime; do not label them task-completion results. |
| The program generalizes across layouts | Initialization mode, distinct initial states and held-out coverage; count repeated states explicitly. |
| The method works on a robot | A separately authorized physical protocol, trial outcomes and interventions; simulation or a demo link cannot substitute. |
Coding-agent skills and watchdogs are not a security boundary
The README states that generated Python has full import access. Trial processes and watchdogs are not a security sandbox. An agent skill packages instructions; it does not constrain everything imported code can read or execute.
For a proposed simulation trial, define isolation, network access, allowed data and a stop condition before running generated programs. Keep simulation agents separated from physical hardware. Review the actual execution environment with its operator; this guide does not validate a sandbox or authorize a real-robot procedure.
Write a reproduction manifest before spending compute
Our suggested manifest fixes the repository revision, runtime lock, task IDs, initialization mode, discovery seeds, held-out evaluation seeds and output directory. Also record the coding-agent version, selected model, permitted tools and approved budget. Fill these fields from the intended run; do not copy a headline result into an empty local results table.
Keep failed installation, blocked model access, structural failure and unsuccessful manipulation as separate outcomes. Preserve the first generated program and its later revisions. If a program was selected after trying several candidates, state that selection procedure beside the final evaluation.
A result summary should identify attempted tasks, completed tasks, resets, interventions and missing outputs. Compare like-for-like conditions before discussing improvements. We have no local success rate, runtime, cost or hardware result to report.
Compare the interface being adapted
ASPIRE organizes discoverable robot skills and executable programs. Our InterEvolve brief instead examines test-time reward-program search around a frozen humanoid controller. Both make program-level artifacts important, but their control interfaces and evaluation protocols are not interchangeable.
Use this checklist to decide what must be verified before a simulation reproduction. For a research evidence review, share the exact paper or version and the unresolved claim; do not treat a setup document as a tactile sensor selection or hardware procurement recommendation.
Read the separate InterEvolve reward-program analysis for the frozen-controller boundary.
The Physical AI overview places models, programs, control and measured feedback in the wider system.
Common questions
Does a passed setup check reproduce the reported 99%?
No. Environment checks, benchmark task success and physical reliability need different evidence. The percentage is attributed to the authors; RoboSkin.ai has not reproduced it.
Do different seed numbers guarantee different initial scenes?
No. Saved states can wrap, and procedural placement constraints can also produce repeated layouts. Retain the initialization mode and observed state coverage in the evaluation record.
Next steps
- Physical AI system boundaries →
Separate reasoning, control, sensing and measured outcomes.
- InterEvolve reward-program analysis →
A different program interface around a frozen humanoid controller.
- Robotics programming learning path →
Find the existing programming and data-processing resources.
- Request a research evidence review →
Bring a specific source, version and unresolved research question.