Overview#
This workflow checks the RP1 policy, robot configuration, and device connections as a matching set, then proceeds through startup, constrained validation, and result recording. If training is complete, begin with the policy handoff; externally supplied policies require the same interface definitions and validation records.
1. Prepare the environment and delivery information#
First complete the environment preparation, source checkout and build, and device connection checks in Environment setup and connection checks. Installation commands and platform-specific settings are maintained in that guide.
Record the current robot's hardware revision, boards, system image, firmware, SDK source version, robot configuration, and calibration version, and confirm that they match the policy. See Electrical system and hardware design for power and control relationships.
| Check sequence | Conditions for proceeding |
|---|---|
| Policy and model | Body axis count, observations and actions, history layout, normalizer, and joint order correspond |
| Software and resources | The image, firmware, robot configuration, and policy configuration form a matching set; all referenced files are present |
| Devices and calibration | Actual buses, IDs, directions, zero offsets, IMU extrinsics, and closed-chain transformations correspond |
| Constrained validation | Follow the stop, protection, and recovery rules of the delivered configuration, and retain execution and result records |
2. Receive the policy and simulation outputs#
Prepare the training provenance, checkpoint, exported policy and hash, model and motion references, I/O conventions, and Sim2Sim records. See Training deliverables. The full development path is:
- Models and data: confirm the body configuration and motion references.
- Training and export: retain the task, checkpoint, and exported policy.
- Sim2Sim: align interfaces and complete independent simulation validation.
- Integrate the physical robot using this workflow: check calibration and configuration before constrained validation.
The 930-dimensional input of the default 28-axis configuration cannot accept the 126-dimensional motion-tracking policy for 24-axis BeyondMimic. The 24-axis BeyondMimic setup has a separate deployment configuration; its weights, reference motion, and actual export must still be verified as a complete set. See Policy paths and I/O for detailed definitions.
3. Select the deployment configuration#
Deployment loads robot.yaml, policy YAML files, and model and motion resources from the robot directory. Choose <robot> and <policy> first, then check every file referenced by that combination.
File organization#
src/inference/robots/<robot>/
robot.yaml
configs/<policy>.yaml
models/
motions/
latents/Replace <robot> and <policy> with the configuration names. The launch implementation resolves model, motion, and latent paths from these parameters.
Current resource coverage#
| Configuration | Resource status | Usage limits |
|---|---|---|
rp1_24dof/default |
The repository contains the policy.onnx path and related data files |
The specific weights, external data relationships, and I/O still require verification |
rp1_24dof/beyondmimic |
Policy and motion paths exist | Associate them with the corresponding training source, configuration, and acceptance records |
rp1_24dof/ufo |
Missing FBcprAuxModel.onnx and latents/zs_66.npz |
Resources are incomplete |
rp1/default |
A 28-action configuration exists, but models/policy.onnx is missing |
Not a complete policy that can be launched |
| 30/42 | Not currently available | Separate resources and mappings still need to be added |
The motion-tracking branch of rp1_24dof/beyondmimic uses a 126-dimensional single-frame input, 24-dimensional actions, and dance1.npz; the same configuration also lists the 243-dimensional default velocity policy. rp1/default uses 28 actions and a 930-dimensional history input. See Policy paths for the correspondence between specific branches and exported files.
4. Check robot and policy mappings#
Fields to check in robot.yaml#
| Field | What to check |
|---|---|
motor_id, motor_interface, motor_num |
Actual buses, IDs, and grouping |
motor_type, motor_model |
Specific drivers and models |
motor_zero_offset, motor_sign |
Zero positions and directions for the individual delivered robot |
urdf2motor |
Model joint order to motor order |
close_chain_motor_idx |
Closed-chain motor indices and decoupling implementation |
extrinsic_R |
Extrinsic rotation from the IMU mounting orientation to the body orientation |
kp, kd |
Gains matching the actual actuators and control conditions |
Use the calibration results for the current robot for zero offsets and gains. Both 24/28-axis deployment configurations have type set to rp1.3; when pairing them with RP1.3.4 hardware or an rp1.3.2 model, separately confirm the relationship between revisions. See Environment setup and connection checks for on-device interfaces, feedback, and calibration checks.
Fields to check in policy YAML#
Check joint_num, model_names, obs_layouts, frame_stacks, obs_stack_orders, mappings, default angles, action scaling, clipping, dt, and decimation. The 24-axis default and Sim2Sim use different history layouts; see the I/O contract.
5. Start and validate in stages#
Select the robot and policy explicitly#
inference.launch.py selects rpo/default by default. Pass the robot and policy names explicitly when starting RP1. Startup constructs the hardware interfaces; first complete wiring, power, calibration, and emergency-stop confirmation according to the operating documentation for the applicable delivered version.
After verifying the configuration and resources, use this entry point for the 24-action default configuration:
ros2 launch roboparty_inference inference.launch.py robot:=rp1_24dof policy:=defaultrobot:=rp1 selects the 28-action configuration. Provide its missing default policy.onnx and verify the I/O contract before use. See Environment setup and connection checks for the startup script, background sessions, and shutdown methods.
Transfer stages and entry prerequisites#
The stages below organize the transfer checks. Follow the applicable delivery specification for specific physical robot conditions, protection settings, and pass thresholds.
| Stage | What to check | Records to retain |
|---|---|---|
| Interface alignment | Model, joints, observation and action semantics, and outputs from the training and target backends | Configurations, hashes, and comparisons using fixed inputs and outputs |
| Sim2Sim | Closed-loop behavior of the same policy in an independent simulation runtime | References or commands, scene, initial conditions, explanations of differences, and playback |
| Physical robot calibration | Directions, zero positions, IMU extrinsics, state freshness, and closed-chain transformations | Calibration files for the specific robot and controlled validation records |
| Constrained task | Actuator response, support, protection, stopping conditions, and timing budget | Runtime conditions, errors, events, and complete data |
| Target task | Success, interventions, continuous operation, and energy consumption for the specified task and conditions | Methods, valid intervals, raw records, and analysis versions |
Completion of training, model export, Sim2Sim execution, and physical robot acceptance are different states and should be recorded separately. Also record completion of the software task, completion of log uploads, and passing the physical task separately. Results may be pass, fail, aborted, or insufficient evidence; missing data remains unknown.
6. Record acceptance and prepare rollback#
Associate each policy experiment with its sources, configuration, and outputs so that results can be compared and issues reproduced. The experiment identity must include at least the robot configuration, system image and firmware, model and policy, calibration, and task conditions.
Experiment outputs#
| Stage | Outputs |
|---|---|
| Training | Run directory, checkpoint, params/env.yaml, params/agent.yaml |
| Play export | exported/policy.pt, exported/policy.onnx |
| Sim2Sim | simulation.mp4, joint_positions.png, base_velocities.png |
| Inference | Startup configuration, model, and runtime outputs; organize physical robot records according to delivery acceptance requirements |
Recommended record fields#
For every experiment, record:
- Each source commit, model source, and hashes of the checkpoint and exported files.
- Task/agent, random seed, environment and software versions, and runtime configuration.
- I/O contract, history layout, normalizer, and joint/motor mappings.
- Scene, command conditions, result artifacts, complete errors, and actual timing.
- For physical robot tests, also record the delivered hardware, firmware, system image, calibration, and operating documentation versions.
Retain the training run and checkpoint, and assign separate versions to policy changes; do not overwrite originals and then try to infer the experiment identity from filenames.
Physical robot acceptance prerequisites#
Physical robot acceptance requires operating prerequisites for the applicable configuration, formal metrics and thresholds, abnormal-stop conditions, emergency-stop confirmation, recovery rules, and recording and sign-off requirements. Follow the formal operating documentation for the applicable delivered version when powering on, wiring, zeroing, using the emergency stop, validating motion, and recovering from faults. The formal operating SOP and complete acceptance specification for the current version are still to be provided.
Rollback conditions#
Before rollback, confirm the known-good policy, matching configuration, system image and firmware, hashes, calibration, and the validation procedure to use after recovery. The physical robot rollback SOP for the current version is still to be provided.
Use software stop, deinitialization, and error clearing according to their respective interface semantics: terminating a background session exits the software, stop_inference stops policy inference, and deinit_motors performs driver deinitialization; use the stop method specified for the delivered version for a hardware emergency stop. See ROS 2 services for the specific semantics of software interfaces and Driver errors for driver feedback and error sources.
Interfaces and further resources#
- Device interfaces: IMU, motors, Robot, ROS 2, camera, and hand interfaces.
- Integration examples: find the appropriate entry point through minimal integration examples.
- Troubleshooting: locate issues through environment, connection, and driver feedback checks.