Skip to main content
Use this checkpoint with the DROID robot and camera conventions. Another arm requires more than padding or relabeling its joints; validate embodiment compatibility before using the policy.
  1. Publish wrist and two exterior RGB views. Pair them with the measured state in your capture system and retain timestamps.
  2. Encode the seven joint angles in the reference order and radians. Convert measured gripper state to a closed fraction (0 open, 1 closed).
  3. Pin an available checkpoint, set the instruction, and submit one request. Keep the tracks delivering frames after the request.
  4. Accept only the matching step. Validate shape, finite values, target limits, and observation age.
  5. Execute absolute joint targets through your local controller at the 15 Hz sample cadence, with any required interpolation to its servo rate. Convert column 7 into the gripper driver’s command convention.
  6. Observe the resulting state and request the next chunk. Decide and evaluate how many rows to execute before replanning.
Returned targets are already in the robot action representation; do not apply model-training normalization again or treat joint targets as deltas. Enforce limits and watchdogs locally. Reactor does not provide a hardware driver, trajectory execution, or collision checking. A repeated request can return different actions because new frames are used. Never execute two replies for the same logical request. After a disconnect or uncertain reset, start a new session and discard the previous action queue.

​
Observation timing

Camera tracks and state commands arrive independently. Timestamp observations at capture and set limits for their age and cross-camera skew; a reply counter does not establish capture alignment. Publish actual observations rather than treating repeated images as new measurements. Measure capture-to-execution age and controller queue depth. Validate the complete loop in a simulator or replay harness before adapting it to hardware.