Model Inference and Real-Robot Operation

This section treats inference and real-robot operation as a single development workflow. The current scope covers starting the inference service, connecting the client, executing actions, and completing controlled validation. It does not constitute a complete production-grade system for containerized deployment, process supervision, monitoring, rollback, and long-term operations.

Real-robot execution workflow

  1. Confirm that the checkpoint, training YAML, and normalization files match;

  2. Start the inference service and complete a health check;

  3. Read camera and robot states in the SDK client;

  4. Construct observations consistent with training;

  5. Send the observation and task text;

  6. Receive the action chunk;

  7. Complete denormalization, dimension mapping, motion limits, and validity checks;

  8. Issue actions via the SDK;

  9. Continuously check robot state, emergency stop, network, and model latency;

  10. Stop upon task completion, timeout, or exception.

Operational safety

  • Use only short episodes for the initial run;

  • Use low speeds and small motion ranges;

  • Do not continue inference when observations are expired or missing;

  • Stop immediately in case of inference timeout, disconnection, or invalid actions;

  • Do not issue actions when the robot state does not permit control;

  • Retain both the physical emergency stop and software stop;

  • Record checkpoints, configurations, tasks, environments, and failure causes.

Real-robot deployment checklist

  • A real-robot dataset in LeRobot v3 format has been created;

  • Camera, state, and action field mappings and dimensions are consistent with the training configuration;

  • The corresponding normalization statistics file has been generated and linked;

  • The real-robot fine-tuning checkpoint can be fully loaded;

  • The WebSocket inference service has been started at ws://127.0.0.1:32195 or the actual deployment address;

  • Open-loop plotting results show no obvious action spikes, directional errors, or continuous saturation;

  • The SDK client has motion limits, timeouts, stop-on-disconnect behavior, and emergency-stop handling configured;

  • The initial real-robot validation uses low speed, small range, and short episodes.

For the SDK data reading and action dispatch flow on the robot side, see section: Model Inference and Real-Robot Operation.

On this page

Real-robot execution workflowOperational safetyReal-robot deployment checklist