robocasa git:20261012.50c05b0A

Immutable. This exact content never changes and is served at /api/v1/blob/bb23efcfdc17c69e.

---
name: robocasa
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 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> \
  --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 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. 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. 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,
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, 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. 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
```