Environment Setup and Connection Checks

roboparty_deploy provides motor, IMU, inference, and camera modules. Before selecting software, confirm the delivered boards, system image, hardware revision, firmware, robot configuration, and policy files. Verify that these identifiers form a matching set for the delivered version.

The inference module's build configuration uses ONNX Runtime 1.21.0 and selects the archive for x86_64 or aarch64; it also depends on yaml-cpp and ZLIB. The camera module additionally uses OpenCV. Extension .so files and dependency archives must match the target CPU architecture.

• Deployment board: ROS 2 and the driver workspace.
• Training workstation: the Isaac Sim, Isaac Lab, and Python environments specified in Training environment.
• Dexterous hand: the separate RP Hand SDK and its Python ABI; these are not automatically merged with the deployment board environment.

Configure the real-time kernel, real-time permissions, udev, and buses according to the deployment instructions for the target image. Orange Pi/RDK settings apply only to their respective platforms; confirm the image requirements first for other controllers.

The current version provides the 24-action rp1_24dof configuration and the 28-action rp1 configuration. The default policy file for 28 actions is still missing, and the 30/42 configurations are not yet available. Read Physical robot configuration checks before selecting a deployment entry point.

In the target environment with ROS 2 Humble, colcon, and the project dependencies installed, obtain the source, build, and load the workspace in the following order.

Run these commands in a separate development directory to avoid overwriting an existing robot workspace:

Run from the workspace root:

install/setup.bash is a build artifact and is not included in the source code. If the first build fails, resolve missing dependencies or compilation errors before loading this file.

Reload the environment whenever you open a new terminal:

source affects only the current terminal. An environment loaded inside a startup script is not propagated back to the terminal that called it.

imu_py, motors_py, and robot_py are built with the workspace. After building and loading the environment, check whether the modules can be located:

Once the modules can be located, continue to Connection checks. For import errors, see Build and resource troubleshooting.

First verify the target devices, interfaces, and configuration, then use communication status to check whether feedback is being updated continuously.

The 24-action configuration uses the IMU interface can_hipnuc and motor buses can1, can2, can0, and can3, with motor counts of [7,7,5,5] per bus. Check each actual interface, ID, and group, and use calibration values for that specific robot.

Inspect the system and interfaces on the target device:

Replace can0 in the last command with the actual interface name. Check that the interface exists and inspect its type, state, and statistics, then verify the node ID, bit rate, wiring harness, and feedback protocol.

For serial connections, verify the actual device path and the current user's permissions. Different USB ports and udev rules can change device names. The serial baud rate must be within the range supported by the HIPNUC driver.

IMU getters return asynchronously updated cached data. The motor method refresh_motor_status() sends a status request, while subsequent getters still read the cache. RobotInterface.read_joints() updates the joint cache; refresh_joints() requests motor feedback, waits, and then reads it. See IMU, Motors, and Robot for details.

Before running enable, zeroing, or motion examples, complete the wiring, power, calibration, and emergency-stop checks specified in the operating documentation for the applicable delivered version.

The inference node starts with both a robot configuration and a policy configuration. Startup constructs hardware interfaces. Before running the physical robot, complete Policy deployment checks and the operating requirements for the delivered version.

inference.launch.py defaults to rpo/default. When starting RP1, pass the robot and policy names explicitly.

After completing configuration checks, use this entry point for the default 24-action configuration:

robot:=rp1 selects the 28-action configuration. Supply its missing default policy.onnx and verify the I/O conventions before use.

tools/start_robot.sh accepts --robot and --policy, builds the workspace internally, and creates two screen sessions: inference_session and joy_session. The script starts the device interfaces and joystick node; complete Connection checks first. The comment in the unchanged source example below means: "Only for a target workspace that has passed the prerequisites for operation on the physical robot."

Inspect existing background sessions:

The repository provides these commands to terminate the background components:

These commands terminate software sessions. For a hardware emergency stop, use the stopping method specified for the delivered version. The stop_inference service stops policy inference, while deinit_motors performs driver deinitialization; these have different semantics. See ROS 2 interfaces for service details. Follow the applicable hardware documentation for formal emergency-stop, power-off, and recovery procedures.