robocasa · diff
git:20260903.012b6e8 to git:20261012.50c05b0
175 added, 14 removed. Audit A to A.
---
name: robocasa
- description: Use to run RoboCasa kitchen-task simulation as a first-class NPA workbench tool — Gymnasium task registration, kitchen asset availability, headless EGL environment reset, and random rollouts with video artifacts, through the npa-robocasa service.
+ description: Use to run RoboCasa kitchen-task simulation and held-out policy evaluation as a first-class NPA workbench tool through the npa-robocasa service.
---
# RoboCasa (kitchen-task simulation)
- RoboCasa is an Apache-2.0 kitchen-task simulation framework built on robosuite
- and MuJoCo. This tool promotes the accepted RoboCasa BYOF candidate into a
- first-class workbench tool: a dedicated `npa-robocasa` container with a FastAPI
+ RoboCasa is an MIT kitchen-task simulation framework built on Apache-2.0
+ robosuite and MuJoCo. Its upstream license retains a separate Apache-2.0 notice
+ for included partial DeepMind MuJoCo code. This tool promotes the accepted
+ RoboCasa BYOF candidate into a first-class workbench tool: a dedicated `npa-robocasa` container with a FastAPI
service, CLI, SDK, and workflow toolRefs that exercise the real upstream
capabilities.
The upstream repo is `robocasa/robocasa` at the pinned `v1.0` tag, with
robosuite at a pinned commit and the exact MuJoCo 3.3.1 / Gymnasium 0.29.1 /
CUDA 12.4 closure from the live-accepted BYOF evidence. Kitchen assets
(textures, fixtures, objects) are NOT baked and download at run time under the
operator's own network access.
## Capabilities
| Capability | What it proves |
| --- | --- |
| `kitchen_task_registration` | Gymnasium `robocasa/PickPlaceCounterToCabinet` is registered |
| `kitchen_asset_availability` | The kitchen assets root exists and is populated |
| `kitchen_egl_env_reset` | A headless `MUJOCO_GL=egl` env creates and resets |
| `kitchen_random_rollout` | A real random rollout runs and writes a video artifact |
+ | `kitchen_trajectory_export` | Causal observation/action rows and terminal review frames are exported |
+ | `kitchen_policy_eval` | Matched-seed ACT and random-baseline episodes retain native outcomes and videos |
## Two execution modes
Direct (the default) runs the work from your CLI invocation. Service mode calls a
deployed Kubernetes endpoint:
```bash
npa workbench robocasa run --capability kitchen_random_rollout \
--output-path s3://<bucket>/robocasa/<id>/ \
--iterations 1 --num-envs 1
npa workbench robocasa run --capability kitchen_random_rollout \
- --output-path s3://<bucket>/robocasa/<id>/ --service --endpoint <url>
+ --output-path s3://<bucket>/robocasa/<id>/ --service --endpoint <url> \
+ --expected-image-source-sha <40-hex-source-sha> \
+ --expected-image-manifest-digest sha256:<manifest-digest>
```
Deploy the service when you want a persistent endpoint several runs share:
```bash
npa workbench robocasa deploy \
--project <alias> --cluster-name <name> \
+ --image '<registry>/npa-robocasa@sha256:<manifest-digest>' \
+ --expected-image-source-sha <40-hex-source-sha> \
--output-path s3://<bucket>/robocasa/ \
- --gpu-type rtxpro6000 --namespace default \
- --dry-run # prints the manifest without applying
+ --gpu-type l40s \
+ --dry-run
npa workbench robocasa deploy --project <alias> --destroy
```
`--gpu-type` is `h100`, `l40s`, `rtx6000`, or `rtxpro6000`. Auth defaults to
`token` (the token comes from the variable named by `--token-env`, default
`ROBOCASA_TOKEN`); `--insecure-no-auth` exists but should not be used. Always
- `--dry-run` first and read the manifest.
+ `--dry-run` first and read the manifest. While the image is quarantined, deploy
+ requires an explicit immutable `@sha256` image plus its exact baked source SHA.
+ The default remains Kubernetes' existing `default` namespace, preserving
+ upgrade/destroy continuity with earlier releases without requiring permission
+ to create cluster-scoped resources. A custom namespace must already exist
+ unless the operator explicitly passes `--create-namespace`; destroy
+ deliberately leaves it in place. When selecting a custom namespace, also
+ override `robocasa_endpoint` in the workflow. For a private image, create the
+ named pull secret in the selected namespace and pass `--image-pull-secret`.
+ The pod and container both enforce `runAsNonRoot`.
+ The service pod requests `32Gi` of local ephemeral storage by default. Override
+ that scheduler request with `--ephemeral-storage-request` after measuring the
+ workload's writable usage. The option sets a request, not a storage limit, and
+ image layers consume node imagefs separately, so confirm enough imagefs
+ headroom for both the immutable image and the pod's writable data before
+ launching a run.
+
+ The `0.1.1` candidate recipe uses a CUDA 12.9 runtime base without inherited
+ cuDNN or development toolkits, with the pinned PyTorch 2.13.0+cu129
+ runtime; this is the first available CUDA 12 wheel set that clears the declared
+ Torch dependency vulnerabilities. The image rebuilds exact upstream RoboCasa
+ and LeRobot sources as locally versioned `1.0.0+npa5` and `0.6.1+npa2`
+ derivatives. Their packaging patches bind RoboCasa's ACT path to the
+ reviewed LeRobot derivative and declare the fixed Torch pair and Gymnasium/OpenCV
+ closure. The RoboCasa patch also resolves the native recorded-action reader's
+ `write_info` import from LeRobot's `datasets.io_utils`. Its native counter
+ reset-region enumeration removes duplicate XML elements in first-occurrence
+ order, preventing element allocation order from permuting physical regions.
+ Candidate membership, constructor/reset seeds, settling, replay, action ordering
+ and task-success predicates are unchanged. Native ordering controls do not prove
+ matched GPU rollouts. This import/reader check
+ does not prove GPU replay or qualify upstream dataset writing.
+ Datasets is locked to 5.0.1 for the upstream folder-metadata
+ path-containment security fix; the derivative's dataset-extra metadata declares
+ that compatible major version. The RoboCasa derivative omits tianshou because its sole exact-source
+ import is the unqualified vectorized speed-benchmark script; the NPA service and
+ matched ACT rollout path do not import it. Normal resolver checks, real ACT
+ construction, inference, shape rejection, dataset round trips, and exact
+ checkpoint save/load through the production adapter must pass before deployment.
+ This qualifies only the ACT
+ path used here and does not claim upstream support for Torch 2.13 or qualify
+ other LeRobot policies. Use L40S for pixel-bearing EGL runs.
+ RTX PRO 6000, B200, and B300 are
+ unverified for this exact image until its wheel architecture set and real EGL
+ path are measured; do not infer support or a blocker from the base-image tag or
+ generic rendering capability alone.
+
## Run
```bash
npa workbench robocasa run \
--capability kitchen_random_rollout \
--env-id robocasa/PickPlaceCounterToCabinet \
--output-path s3://<bucket>/robocasa/runs/<id>/ \
+ --service --endpoint <url> \
+ --expected-image-source-sha <40-hex-source-sha> \
+ --expected-image-manifest-digest sha256:<manifest-digest> \
--iterations 1 --num-envs 1 \
--wait --poll-seconds 30 --timeout-seconds 3600 \
--output json
```
`--capability` and `--output-path` are required. The legacy `--output-uri`
spelling remains as an alias. `--wait` polls `/status` until
the run completes **and fails if it does not** — without it, the command returns
- as soon as the run is accepted.
+ as soon as the run is accepted. Service mode additionally requires both expected
+ runtime-identity flags. The service compares them with the deployment-provided
+ manifest digest and with the source SHA baked into the running image before it
+ creates a run record or schedules GPU work.
## Status, system-info, list
```bash
npa workbench robocasa status --run-id <id> --service --endpoint <url>
npa workbench robocasa system-info --service --endpoint <url>
npa workbench robocasa list --service --endpoint <url>
```
`system-info` reports the RoboCasa, robosuite, MuJoCo, and Gymnasium versions,
- CUDA availability, and the registered env count.
+ the exact LeRobot/Torch/TorchVision policy stack, CUDA availability, registered
+ env count, exact NPA image source revision, and deployment manifest digest.
+ The official image sets `NPA_IMAGE_SOURCE_SHA` and
+ `ROBOCASA_REQUIRE_IMAGE_SOURCE_SHA=1`; do not override them. A direct local run
+ without an image-bound revision reports `source_identity: local_unbound`.
## In workflows
There are six per-capability toolRefs:
`workbench.robocasa.task_registration`, `.asset_availability`,
`.egl_env_reset`, `.random_rollout`, `.trajectory_export`, and `.policy_eval`.
The first four appear together in `robocasa-smoke.yaml`; the latter two drive
the data-policy workflow's real rollout export and held-out evaluation.
+ Every RoboCasa toolRef passes the expected source SHA and manifest digest. The
+ checked-in workflows use all-zero non-runnable placeholders; override both with
+ the exact values used by `deploy`.
+ Trajectory rows use the observation-before-action convention required by
+ behavior cloning. The checked-in workflow deliberately labels its source as a
+ seeded random-action baseline rather than expert demonstrations.
+ These toolRefs are HTTP clients and run on CPU resources; assigning them a GPU
+ would compete with the separately deployed service for its exclusive device.
+ The smoke path needs one L40S for the service plus a CPU worker. The data-policy
+ path needs two L40S devices/nodes plus a CPU worker: one L40S remains held by the
+ service while the second runs ACT training before held-out evaluation returns to
+ the service.
+
+ Policy evaluation runs one unambiguous exact ACT checkpoint and a random-action
+ arm on the same held-out task IDs and reset seeds. It fails when paired initial
+ workspace frames or robot-state hashes do not match, when native success
+ signals disagree, when actions or states are non-finite, or when either arm does
+ not produce its MP4. Finite policy outputs outside the simulator bounds are
+ clipped at the environment boundary; each episode records the raw and applied
+ action hashes, clipped-step count, and maximum bound violation. The split
+ record verifies the checkpoint's content-bound
+ `training_dataset_provenance.json` against the exact ordered training task IDs,
+ then proves the held-out set is disjoint. Use
+ `success_rate_delta` and the paired win/loss/tie counts for comparison; do not
+ turn a zero or negative delta into a policy-improvement claim.
+
+ A refused initial-state match stays `failed`. Before cleanup, the producer
+ captures each arm's initial workspace PNG before action 0. Once the containment
+ supervisor proves all descendants stopped, the service retains the failed
+ pair's two initial PNGs, two completed arm videos, and typed `failure.json` under
+ the run's `failure-diagnostics/` output prefix. The record identifies the pair,
+ seed, robot-state/workspace hashes, optional full simulator-state hash, action
+ digests, checkpoint/tree hashes, request hash and runtime image/source identity.
+ An unavailable or unsupported simulator-state accessor yields `null`, not an
+ empty or fabricated state. An observed non-finite simulator state still fails
+ the run. The parent independently checks the retained episode index, seed and
+ held-out environment against the requested episode plan.
+ The v2 failure record also preserves the contiguous completed prefix, with strict
+ per-arm native outcomes and exactly four media per completed pair named
+ `completed-XXXX-{policy,random_baseline}.{png,mp4}`. Every completed pair binds the
+ same checkpoint/tree, request and runtime image/source. The parent checks indices,
+ seeds, held-out tasks, horizon and the full requested population; report read bounds
+ come from that admitted request, never the worker's self-declared population.
+ `requested_pairs` and `unattempted_pairs` keep missing cases explicit. These are
+ partial outcomes under an overall failed status, not a final success rate or a
+ completed evaluation. A validated failed-only v1 record is sealed before prefix
+ staging. If prefix copying, schema validation or report writing fails, this
+ original record and exactly its four failed-pair media remain available with
+ `completed_prefix: "unavailable; failed-pair evidence only"`; it makes no completed
+ prefix claim. The parent still refuses invalid promoted records and hostile
+ request bindings rather than downgrading them. Historical v1 records remain
+ readable. Report reads use bounded chunks even for large admitted populations.
+ No scratch tree, environment dump or checkpoint is retained with these artifacts.
+ Diagnostic publication uses the same immutable byte/readback commit as successful
+ outputs, but its commit only establishes delivery of failure evidence; it does
+ not establish a matched pair or completed run. Failed publication remains failed
+ and reports diagnostics unavailable. Timeout or uncontained-worker failures do
+ not publish these files.
+
Every run uploads `result.json` and `provenance.json`. Rollout provenance names
- the RoboCasa → MuJoCo execution path and hashes each generated MP4, with
- machine-readable `rrd: false` and `mcap: false` fields; this tool does not emit
- RRD or MCAP recordings.
+ the RoboCasa → MuJoCo execution path, exact image source revision, and hashes
+ each generated MP4. Successful policy evaluation also retains each arm's
+ after-reset/before-action-0 workspace PNG at `episode_XXXX/rollout.png` and
+ `episode_XXXX/random_baseline.png`; `png_artifacts` in provenance binds their
+ paths and byte hashes, and the immutable output commit covers those bytes.
+ Machine-readable `rrd: false` and `mcap: false` fields remain explicit;
+ this tool does not emit RRD or MCAP recordings.
+ The service owns one GPU, so accepted runs execute through one process-wide GPU
+ gate. Each run has a bounded registry slot and executes in a killable process
+ group under its requested `timeout_seconds`; timeout cleanup removes parent-owned
+ checkpoint, output, and asset-staging scratch. If the process group or scratch
+ cannot be cleaned up, the gate stays poisoned and new runs receive HTTP 503
+ instead of overlapping a possibly live GPU worker. A duplicate request for the
+ same active deterministic run ID returns the existing queued/running record and
+ does not enqueue a second copy. SDK service calls must pass
+ `expected_image_source_sha` and `expected_image_manifest_digest`, just like CLI
+ service calls.
+
+ Queued runs wait asynchronously for the existing single GPU execution slot;
+ they do not occupy the shared HTTP worker pool while waiting. Accepted executions
+ remain attached through HTTP-waiter cancellation until worker cleanup completes;
+ disconnecting a request does not cancel an accepted run. Output publication
+ keeps a private, seekable local snapshot, verifies its size and SHA-256 before
+ writing, then uses conditional S3 PUT and full byte readback. It never relies on
+ CopyObject destination preconditions or writes payloads outside the requested
+ run prefix. No remote staging or delete grant is needed. Conflicting output
+ objects fail closed, while an identical immutable commit can be resumed.
+
## Gotchas
- **Without `--wait`, "started" is not "succeeded".** Check `status` before
reporting a result.
- **Kitchen assets download at run time.** The first run on a fresh image needs
- network access to fetch textures, fixtures, and objects.
+ network access. Fetches are pinned to
+ `robocasa/robocasa-assets@1b92c3d02ca4354984fec961357db0bff7b32166`
+ and
+ `nvidia/PhysicalAI-Robotics-Manipulation-Objects-Kitchen-MJCF@420a04af939c34873e6839a586b70844baf28aab`.
+ Population is locked, bounded before ZIP metadata allocation, extracted
+ without following links into validated staging trees, and published with
+ per-archive content-hash/file-count receipts. Downloaded fixture trees retain
+ the exact pinned upstream control XML files in the same atomic publication.
+ Installed bytes are rehashed before a receipt can suppress a fetch. A failed
+ or mutated archive remains
+ retryable and fails the capability instead of being logged and ignored.
- **`--service` needs both a reachable `--endpoint` and the token variable set.**
A missing token presents as an auth failure from the endpoint, not as a CLI
validation error.
- **Gymnasium must stay pinned at 0.29.1.** Newer wrappers drop `__getattr__`
and break `env.sim` video capture.
+ - **The data-policy reference trains on random actions.** It proves the
+ data/training/evaluation path and exposes a matched baseline; it does not
+ establish useful imitation learning without successful demonstrations and a
+ measured held-out benefit.
## Verify
```bash
npa/.venv/bin/python -m pytest npa/tests/guardrails/test_skills_index.py -q
```