RP1 Quick Start

This page takes you through getting started with RP1 from scratch. Choose one of three paths based on what you have available:

The three paths are independent, so you can start with any of them. They ultimately connect to the same development workflow: model → training → export → Sim2Sim → real robot.

---

This path requires neither a robot nor a GPU. You will open the RP1 model in MuJoCo, then run a script to swing its arms while it is held by a simulated "suspension rig."

• Python 3 (3.10 or later recommended)
• Internet access to install pip packages
• macOS, Linux, or Windows

RP1_description is a public repository containing URDF, MJCF, and mesh files:

The repository contains these MuJoCo models:

RP1 will appear standing on flat ground, then fall over. This is normal: all joint actuators in the model are torque motors. Without a controller sending commands, the robot goes limp as though its power were off.

In the viewer, you can:

• Press Space to pause or resume the simulation;
• Double-click a part to select it, then hold Ctrl + right mouse button and drag to apply a force;
• Inspect joint angles in the Joint panel on the right and actuators in the Control panel.

To view the 24-axis model, change the file to mjcf/robot_24dof.xml. This file contains only the robot, without a ground plane, so it will keep falling. It is suitable for inspecting the structure while paused.

The following script simulates a suspension rig: it fixes the robot's base at its initial height, then uses PD control to swing both shoulder joints back and forth. Save it as rp1_hold_demo.py in the root of the RP1_description repository:

Run it:

Tip On macOS, run this script with mjpython instead of python. This is a requirement of MuJoCo's passive viewer on macOS.

You will see RP1's base held at its initial position, its legs straight, and both arms swinging back and forth at 0.5 Hz with an amplitude of about ±0.6 rad. To use the 24-axis model, change the argument to mjcf/robot_24dof.xml.

Without a graphical interface, add --headless to run for just 2 seconds and print the result:

The actual value in the last line lags behind the target because of PD tracking lag with the demo gains. This is normal. Modify the target() function to make any joint follow a trajectory of your choice.

---

This path trains a flat-ground walking policy for RP1 in Isaac Lab, then exports it to MuJoCo to check whether it also works in another physics engine.

First install Isaac Sim and Isaac Lab using the official Isaac Lab installation guide. Run all commands below in the Python environment used by Isaac Lab.

Clone the repository outside the Isaac Lab source directory:

The repository contains two directories: robolab (RoboParty's Isaac Lab extension, tasks, and robot assets) and rsl_rl (the reinforcement learning library).

Confirm that the RP1 tasks are registered (on Linux):

You should see RP1.3-Flat, RP1.3-Rough, RP1.3-AMP, RP1.3-AMP-Play, and RP1.3-BeyondMimic.

Note The repository's list_envs.py only lists tasks with "RPO" in their names. RP1 tasks will not appear there; this does not mean the installation failed.

Use 1 environment and 1 iteration to confirm that Isaac Sim starts, the task loads, and training runs:

Expected result: the program exits normally and creates a timestamped run directory under logs/rsl_rl/rp1.3_flat/. This run only checks the environment and is not intended for deployment.

Remove the two parameters used for the workflow check to use the task's default configuration:

The defaults are 4096 parallel environments and 9001 iterations, with a checkpoint saved every 1000 iterations. If GPU memory is insufficient, reduce the number of parallel environments with --num_envs; adjust the training length with --max_iterations.

During training, use TensorBoard to monitor reward curves:

Each run directory contains checkpoints, along with params/env.yaml and params/agent.yaml, which record the configuration for that training run.

Tip To train on rough terrain, switch the task to RP1.3-Rough. Logs will be written to logs/rsl_rl/rp1.3_rough/.

After training, choose a checkpoint to play back:

The Isaac Sim window will show RP1 walking according to velocity commands. play.py also automatically exports two files to exported/ under the checkpoint's directory:

Observation normalization parameters are bundled into both files and do not need to be saved separately.

Run this from the repository root:

Replace --load_model with the actual path to exported/policy.pt from the previous step. The script opens a MuJoCo window and lets your trained policy control the 24-axis RP1.

A few notes:

• The default command is to turn in place. In robolab/scripts/mujoco/sim2sim_rpo.py, velocity commands are defined in the cmd class, with defaults of vx = 0.0, vy = 0.0, and dyaw = 0.8. The robot will rotate in place at 0.8 rad/s. Change these values to make it walk forward.
• Output files. The script runs according to its configuration, with a default simulation duration of 1000 seconds. When it finishes, it saves joint_positions.png and base_velocities.png in the current working directory. Adding --headless disables the window and records the rendered video to simulation.mp4 in that directory.
• Rough terrain. Add --terrain to use the rough-terrain scene.
• Missing dependencies. If mujoco_viewer or cv2 cannot be found, install mujoco-python-viewer or opencv-python, respectively.

Note The rp1_flat.xml used by Sim2Sim comes from roboparty_train and references the 24-axis model. The file with the same name in RP1_description references the 28-axis model. Do not interchange them.

Stable walking in Sim2Sim shows that the policy can tolerate some differences between physics engines. This is a necessary step before running it on the real robot. Moving from simulation to hardware also requires checking joint directions, zero positions, IMU mounting orientation, feedback latency, and other factors. Passing Sim2Sim does not guarantee that the real robot will walk.

---

This path uses the 24-axis policy included in the roboparty_deploy repository to make RP1 stand and walk under gamepad control.

Caution: read this section before powering on

• Zero calibration, reset, and the first inference run can all cause motors to apply torque suddenly. Perform these operations on a load-bearing safety suspension rig, with the robot suspended, the area clear, and someone supervising.
• If you notice abnormal shaking, an unexpected gait, or mechanical interference during operation, press X on the gamepad immediately to disable the motors. If the software does not respond, press the physical emergency stop immediately to cut power.
• The gamepad's X button and the stop_inference service are software stops and cannot replace a physical emergency stop. Before starting, confirm that the emergency stop is within reach and works properly.
• RoboParty's published Safety Operation Guide covers the previous-generation Roboto Origin, which shares RP1's deployment software and gamepad controls. Read it as well.

Install the build and runtime dependencies on the main controller:

The second installation line installs the gamepad driver; the third installs dependencies for Python scripts such as zero calibration.

Allow real-time priority for the current user. Edit /etc/security/limits.conf and append these two lines, replacing <用户名> with the username you use to log in to the main controller:

Reboot the main controller, then check:

An output of 98 confirms the configuration is successful.

install/setup.bash is generated by the build and will only exist after the first successful compilation. Whenever you open a new terminal, run both source commands again:

RP1's motors connect to 4 CAN-FD buses, while the IMU uses a separate CAN interface. The 24-axis configuration (src/inference/robots/rp1_24dof/robot.yaml) uses the following interfaces:

After powering on, list the network interfaces and confirm that all 5 interfaces above are present:

Then inspect the detailed status and transmit/receive statistics of an interface, replacing can0 with the interface you want to check:

These two commands only read status and do not send any commands to the motors.

Motor zero positions define which physical pose corresponds to "0 degrees" in software. Incorrect zero positions will offset every movement commanded by the policy. Skip this step if the robot's zero positions have already been calibrated. Recalibrate after the initial assembly, motor replacement or servicing, or loss of the stored zero positions.

To calibrate each motor individually, suspend the robot on the rig, then run:

The script processes the motors in the order specified in scripts/config/set_zero.yaml, which already matches the RP1 24-axis bus and motor IDs. It switches the motors to damping mode so you can position them by hand. Follow the prompts to move the current motor to its zero position, press Enter to save it, or press Space to skip it.

Note In robot.yaml, motor_zero_offset records each motor's offset relative to its zero-calibration pose. These offsets correspond directly to how the joints are positioned during calibration. Before recalibrating, confirm that your calibration poses match these offsets; otherwise, the robot will assume an incorrect pose after reset.

Confirm that the robot is suspended on the rig and its motors are disabled, then run this from the repository root:

Note Always specify --robot rp1_24dof. Both the script and the launch file default to rpo, the previous-generation robot. Omitting this option loads the wrong configuration.

The script first builds the workspace, then starts two screen sessions in the background:

Finally, it prints a message that all components have started successfully in the background, followed by the gamepad controls. View the inference node's output:

After confirming that there are no errors, press Ctrl + A, then D to detach. The node continues running in the background.

Follow these steps in order:

1. Enable. With the robot still suspended on the rig, press X to enable the motors. After confirming everything is normal, you can press X again to test disabling them, then re-enable them.
2. Reset. First position the robot approximately in a standing pose by hand, then press A. The joints will move smoothly to their default standing angles. The farther the starting pose is from the default, the more pronounced the reset movement will be.
3. Lower to the floor. After reset completes, lower the robot steadily from the rig. Confirm that both feet are firmly on the ground and its center of gravity is centered. Keep the rig's support line within reach.
4. Clear the gamepad inputs. Before pressing B, move each stick fully in all four directions and release it, then press LT and RT several times. This clears stick drift to prevent residual commands when inference starts.
5. Start inference. Press B. RP1 will balance while standing in place.
6. Walk. Gently move the right stick to walk forward, backward, or sideways, and use LT / RT to turn. The default policy's command limits are: forward 0.6 m/s, backward 0.4 m/s, sideways 0.4 m/s, and turning 0.8 rad/s.
7. Stop. Press B to pause inference, then support or suspend the robot before pressing X to disable the motors.

This only ends the software sessions. Before shutting them down, confirm that the motors are disabled and the robot is supported.

If the robot suddenly disables its motors and goes limp during inference, leave the setup as it is and inspect the errors with screen -r inference_session. Common causes include software limits, such as joint position or velocity limits, and hardware protection, such as overload, overheating, or undervoltage. Save the error logs before cutting power to help diagnose the issue.

The deployment software also provides ROS 2 services for scripting or remote debugging. Load the environment in a new terminal, then call them:

After pressing Y to switch to /cmd_vel control, you can send velocity commands through the /cmd_vel topic using geometry_msgs/msg/Twist. To inspect the current joint states:

The deployment repository also includes a 24-axis motion-tracking policy and a dance motion. Start it in the same way:

This configuration loads both the default walking policy and the dance policy. Once inference has started, press LB to switch between walking and motion tracking, and RB to switch motion sequences. Use the suspension rig for the first dance run as well, and check the range of motion before lowering the robot to the floor.