Observation and action loop
- Create one session per robot/episode stream. Subscribe before connecting; publish named cameras
after
READY. The SDK maintains transport keepalive. - Send measured joint and gripper state, start all camera streams, then set the task prompt.
- Receive
action_chunk, validate its shape and finite values, and check it belongs to the active episode. Trackchunk_indexandobs_seqto reject already-consumed messages. - Apply your robot’s position, velocity, acceleration, and workspace limits before replacing the pending plan. Execute accepted targets at the controller’s cadence.
- Continue sending current measured state and new camera samples. There is no execution acknowledgement command gating the next chunk.
Freshness and temporal context
Use actual captured frames. Repeating a still image at video rate can fill the model’s four-frame history with copies and change its temporal conditioning. Video and state use separate transport paths;obs_seq does not make them an atomic observation or identify your last capture exactly. For
paced simulator requests, use an adapter that explicitly manages camera delivery and episode state.
For live control, log capture time, model counters, receipt time, and the rows actually executed.
Set a cross-camera skew limit and measure capture-to-execution age and controller queue depth.
Camera FPS, action cadence, and inference latency are separate quantities.
Set an application-specific maximum action age and observation age. On a stalled view, inference
timeout, disconnect, malformed output, or out-of-bounds target, stop replacing the plan and invoke
your controller’s defined hold/stop behavior. Do not continue indefinitely on the final chunk.
Episode transitions
Stop or hold the controller before changing an episode. A changed prompt re-anchors model context but does not reset episode counters. For a new episode, sendreset, wait for episode_reset,
discard buffered actions, and republish measured state and frames before the next prompt. The reset
acknowledgement is not a physical-stop acknowledgement. After an ambiguous interruption, a fresh
session gives the clearest boundary between old and new messages.
See the reference for exact command names and
troubleshooting for symptoms.