Model Run / Inference
The Model Run page is used to control the robotic arm with a trained model.
Pre-Run Checks
Section titled “Pre-Run Checks”Before running, confirm:
- The robotic arm is connected correctly.
- The follower arm is in a safe posture.
- The workspace is free of people, obstacles, and fragile objects.
- The camera view is stable, and task objects are placed consistently with the training data.
- Do not disconnect or disassemble the robotic arm during execution.
Model Selection
Section titled “Model Selection”The page displays the local model list. If there is no local model, complete training first and wait for the model to be downloaded locally.
Model information includes training source, policy type, and device profile. Use a model that matches the current hardware model and number of cameras.
The model in the list should match the current task, hardware, and camera layout. A model usually only applies to the task and environment used during training. For example, a model trained with a “top view + gripper view” dataset should not be run directly with a “top view + side view” layout. Data collected on B601 should not be used directly with a different robotic arm configuration.
If no model is available on the page, training may not be complete, the model may not have been downloaded locally, or local model registration may have failed. In this case, return to the Training page and check training task status instead of repeatedly refreshing the Model Run page.
Inference Mode
Section titled “Inference Mode”| Mode | Description |
|---|---|
| Local inference | Use a downloaded model and run inference on the local machine |
| Cloud inference | Use a downloaded model and start an async policy server workflow for cloud-related policy inference or integration |
Run Parameters
Section titled “Run Parameters”Cloud / async policy server parameters:
| Parameter | Default Value | Description |
|---|---|---|
| Actions per chunk | 30 | Number of continuous actions sent to the robotic arm in each inference request. Larger values make motion more continuous but may slow correction. Use the default value during debugging |
| Chunk size threshold | 0.5 | Determines when to request the next action chunk. Lower values request more frequently. Do not lower it blindly when network or compute is unstable |
Local ACT parameters:
| Parameter | Default Value | Description |
|---|---|---|
| Run count | 1 | Number of automatic executions. For first validation of a new model, start with 1 |
| Time limit per run | 60 seconds | Maximum duration for one run. For simple tasks, do not set it too long, so the arm does not continue ineffective actions after failure |
| Control FPS | Auto | If left blank, it follows the dataset FPS in Device Setup and is also limited by camera FPS |
| Policy device | Backend default | Use the system default first. If performance is insufficient, select cpu, mps, or cuda according to device capability |
Run Controls
Section titled “Run Controls”| Button | Function |
|---|---|
| Start Run | Start inference and robotic arm control |
| Stop Run | Stop the current run |
| Reconnect | Reconnect when execution is abnormal or connection is lost |
| Refresh Preview | Refresh the run camera preview |
| Diagnostics | View run stage, deployment status, log path, and RobotClient logs |
Run Results
Section titled “Run Results”After starting a run, do not only check whether the robotic arm moves. Observe whether the motion steadily progresses toward the task objective. In a grasping task, watch whether the gripper aligns with the target, whether the approach path is smooth, whether grasp timing is reasonable, and whether the placement position is close to the training target.
If the model motion starts to deviate from the goal, repeatedly jitters, opens and closes the gripper incorrectly, or moves close to a dangerous position, stop the run immediately. After stopping, do not simply click Start again. Return to the dataset and training configuration to inspect the cause. Possible causes include insufficient demonstrations, failed samples not deleted, camera position changes, model-hardware mismatch, or an overly difficult task.
After one run completes, the user should obtain a real-machine validation result: success, partial success, or failure. Success means the current data, training, and environment configuration can support the task. Partial success usually means more boundary cases should be collected. Failure means the dataset quality, training strategy, and task definition should be checked again. The Model Run page is the end of the verification loop and also the starting point for the next round of data improvement.