Skip to main content
Your application captures model inputs and applies returned actions. Read the checkpoint’s own feature names and shapes before writing the NumPy mapping; inspection does not require a registered robot:
robot computer
This checkpoint-owned contract lists feature keys, modalities, shapes, and action chunk geometry. It does not assign physical cameras, define state or action semantics, or prove serving support. Fine-tuned Pi0.5 checkpoints can declare different numbers of visual inputs. Missing or contradictory facts remain unknown; the CLI exits nonzero instead of guessing. observation.state follows the checkpoint’s published state representation; it need not represent joint positions.
robot computer
Hosted recordings retain the supplied capture timestamps, frame IDs, drops, and clock IDs.
Use the exact feature names from the contract as mapping keys. The customer chooses how to read each physical sensor and state source:
robot computer
Servo validates each mapping. Customers own sensor access and applying returned actions.

You now have

  • Checkpoint-named NumPy inputs, independent of robot taxonomy.
  • Optional camera capture metadata and runtime input validation.
  • Customer-owned capture and action application.

Next

Continue with Keep your own loop to schedule action chunks.