RoboParty RP1: Inside Its Open-Source Humanoid Stack

What this inspection covers

RoboParty's RP1 overview, updated 14 October 2026, presents one open humanoid platform. The repositories behind that page do not yet form one robot configuration. The overview names RP1. The training and deployment code that can actually be read today still names RPO and ROBOTO_ORIGIN, the earlier open prototype. [1] [2]

This article is a code and file inspection. It is not a hardware build, a training run or a physical test. Commands are quoted only when they appear in the current documentation or source. The one command executed for this article is the description-repository limit check, and its output is reported below. No policy was trained, no ONNX file was loaded, and no robot was powered. [3]

A press note from 3 October 2026 calls RP1 a new platform unveiled at IROS 2026 and says it builds on RPO. Treat that as a company announcement. The sections below use repository files, not the announcement, for joint counts, training tasks and deployment interfaces. [4]

What is included in the RP1 platform?

The RP1 repository itself is an index. At commit ee25506 its root holds two READMEs, an assets folder and a docs folder. It tells contributors to open issues in the sub-repositories, not in the overview. Release contents and setup steps are delegated to those other repositories. [1]

Two configurations you can open, and two you cannot

RP1_description, commit 84529a5 from 20 August 2026, contains the model files. urdf/rp1.urdf has 28 revolute joints: 6 per leg, 2 at the waist, and 7 per arm. Each arm is shoulder pitch, roll and yaw, one elbow, and a 3-axis wrist. urdf/rp1_24dof.urdf has 24 revolute joints. The difference is the wrist: each arm keeps a single wrist joint instead of three. There is no finger joint in either URDF. [5] [6]

mjcf/robot.xml is a MuJoCo model named rp1.3.2. It has one free joint on the base, 28 hinge joints and 28 motors. The option timestep is 0.005 seconds and the solver is Newton. mjcf/rp1_flat.xml and mjcf/rp1_rough.xml are scene files that include robot.xml. robot_24dof.xml is the shorter variant. The description repository has no README. [7]

The RP1 overview says supported configurations include 24, 28, 30 and 42 degrees of freedom. Only the 24-DoF and 28-DoF URDFs were in RP1_description at the commit above. A search of that tree did not find a 30-DoF or 42-DoF URDF or MJCF. Do not treat 30 and 42 as models you can load until those files exist. [1] [5]

Hardware files use another version number

rp1_hardware, commit 5966da2 from 10 October 2026, is the manufacturing tree: mechanics, PCB data, cable-assembly drawings and bills of materials. The checked-in BOMs are RP1_BOM_5DOF_MotionHead.xlsx and RP1_BOM_7DOF_MotionHead.xlsx, both described as RP1.3.4 whole-machine lists with a MotionHead. The main assembly named in the mechanical README is RP1.3.4整机.SLDASM. SolidWorks source, STEP/X_T models and drawings are attached to GitHub release v0.1.0, not stored as the full CAD set in the git checkout. The documented CAD host is SolidWorks 2021 SP5.1. [8] [9]

That leaves a version gap a builder has to resolve: the MJCF model string is rp1.3.2, while the hardware README and BOM directory describe RP1.3.4. This inspection did not prove that the August description files match the October CAD release. [7] [8]

The sum of the mass values on the 29 links in urdf/rp1.urdf is 40.73 kg. That is a model total from the inertial tags, not a weighed robot. The RPO URDF, discussed later, sums to a different number. [5]

Repository guide: where developers should start

Start from the repository that matches the job. Opening roboto_origin does not check out the RP1 CAD, and opening RP1 does not give you an Isaac Lab task named RP1. The training repository's README and the files under its robolab submodule still implement RPO. [10] [2]

[1] [8] [5] [11] [12] [13] [2] [10] [14] [15] [16] [17]

roboto_origin also snapshots roboparty_navigation and roboparty_xr_teleop. Navigation is a ROS 2 Nav2 workspace. The teleop README describes a PICO VR arm teleoperation app derived from Unitree's xr_teleoperate, under GPL-3.0-only for the combined work, with Apache-2.0 retained on the Unitree-derived code. Neither was exercised here. [18]

Training humanoid locomotion with Isaac Lab

The trainable robot in roboparty_train is RPO, not the RP1 URDF. Gym registrations in robolab, submodule commit 6b1c3d99, are RPO-Flat, RPO-Rough, RPO-AMP, RPO-AMP-Play, RPO-BeyondMimic, RPO-Getup-Mimic, RPO-Parkour, RPO-Parkour-Play, RPO-AttnEnc and RPO-Interrupt. A search of that tree found no task id containing RP1. [19] [20] [21] [22]

The training README asks for Python 3.11, Isaac Sim 5.1.0, Isaac Lab on its main branch, and RSL-RL 3.3.0, on Ubuntu 22.04 or Windows x64. Install Isaac Lab first, clone roboparty_train with submodules, then install the two local packages. The parent repository's own README badges still advertise Isaac Sim 4.5.0, Isaac Lab 2.1.1 and Python 3.10. Follow the training README, not the older badge line. [10] [2]

git clone --recursive https://github.com/Roboparty/roboparty_train.git
cd roboparty_train
pip install -e ./robolab
pip install -e ./rsl_rl
python robolab/scripts/tools/list_envs.py

The flat-ground velocity task

RPO-Flat is a direct Isaac Lab environment, RPOFlatEnvCfg. It sets action_space to 23 and observation_space to 78. The single observation is angular velocity, projected gravity, a 3-axis velocity command, 23 joint positions, 23 joint velocities and 23 previous actions. actor_obs_history_length is 10, so the policy input used later in MuJoCo is 780 values. action_scale is 0.25. Physics dt is 0.005 seconds and decimation is 4, so the policy step is 0.02 seconds, or 50 Hz. The episode length is 20 seconds. Terrain for the flat task is the gravel generator with height scan disabled. RPO-Rough turns the height scan on, switches to ROUGH_TERRAINS_CFG, and raises state_space from 139 to 326. [23] [24]

RPOFlatAgentCfg runs RSL-RL's PPO class for experiment rpo_flat. The checked settings are seed 42, 24 steps per environment, 9001 iterations, clip 0.2, entropy coefficient 0.005, 5 epochs, 4 mini-batches, learning rate 1e-3 and gamma 0.99. The network defaults in BaseAgentCfg are an actor and a critic of widths 512, 256 and 128 with ELU. The device field is cuda:0. Rough terrain adds a mirror-symmetry loss with coefficient 0.2. None of this was launched for this article, so there is no learning curve to report. [25] [24]

python robolab/scripts/rsl_rl/train.py --task=RPO-Flat --headless --logger=tensorboard --num_envs=8192

AMP, BeyondMimic and parkour are in this commit

Those three names are not only README bullets. RPO-AMP uses AmpEnv and the motion directory robolab/data/motions/rpo_lab, with weights for clips such as 127_06, A1-_Stand_stageii and move_l. Matching .pkl files are in the snapshot, alongside a rpo_gmr directory of source pickles. RPO-BeyondMimic uses ManagerBasedRLEnv and loads data/motions/rpo_bm/yundong1.npz, which is present, with anchor body torso_link. RPO-Parkour points its runner config at RPOParkourAmpRunnerCfg. Play entry points exist for all three, and play_parkour.py accepts --exportonnx when num_envs is 1. [20] [21] [22] [10]

Motion preparation is a separate step. dataset_retarget.py reads GMR .pkl files, defaults to robot rpo, and launches Isaac Lab to rewrite joint order into the lab convention. The mapping file is robolab/scripts/tools/retarget/config/rpo.yaml. The README points at the separate GMR repository for making those pickles. Filenames such as A1-_Stand_stageii resemble public motion-capture clips. This inspection did not open the pickles or check their licence. Do not redistribute them until that is settled. [26] [10]

For the simulator install itself, use Isaac Sim and Isaac Lab setup notes. The walking-training article on this site uses a different codebase and should not be mixed with these task ids. [10]

See the walking-training guide.

From simulation to MuJoCo: understanding Sim2Sim

Sim2Sim here means loading a policy that was trained in Isaac Lab and stepping a second simulator, MuJoCo, with the same observation layout. It does not mean the physical robot has run. scripts/mujoco/sim2sim_rpo.py loads a TorchScript module with torch.jit.load. It does not load the ONNX files shipped in the deployment repository. [27]

python robolab/scripts/mujoco/sim2sim_rpo.py --load_model "/path/to/policy.pt"

Without --terrain the script loads the RPO MJCF at the Isaac data path robots/roboparty/rpo/mjcf/rpo.xml. With --terrain it loads rpo_terrain.xml. The inner timestep is 0.001 seconds and decimation is 20, so the policy still runs at 50 Hz, but the physics step is five times finer than the Isaac Lab dt of 0.005 seconds. The script runs for 10 seconds, holds a zero velocity command unless you edit the cmd class, and writes joint_positions.png and base_velocities.png. A --headless run also writes simulation.mp4. PD gains, default pose, action scale 0.25 and the usd2urdf joint permutation match the ROS 2 file configs/default.yaml. [27] [28]

The same folder has sibling scripts for AMP, attention-encoder, BeyondMimic, interrupt and parkour policies. Each expects its own checkpoint. A successful run can show that the network accepts the MuJoCo observation and that the PD controller produces joint motion in that MJCF. It cannot show actuator delay, CAN timing, ankle linkage error, foot compliance or balance on a real floor. [27]

For a smaller MuJoCo example that was executed on this site, see MuJoCo humanoid simulation notes.

The limits of that transfer are discussed in simulation-to-robot transfer.

How the ROS 2 deployment stack works

roboparty_deploy is a ROS 2 Humble workspace for the RPO robot. Its README says the stack was verified on an Orange Pi 5 Plus running Ubuntu 22.04 with kernel 5.10, and on an RDK X5 running Ubuntu 22.04 with kernel 6.1.83. The Orange Pi path installs a real-time kernel from local .deb packages and raises rtprio. The RDK path expects a preinstalled real-time image. Host packages named in the README are ccache, fmt, spdlog, eigen3 and screen, plus ros-humble-joy if a gamepad is used. [14]

The build sequence in the README is source /opt/ros/humble/setup.bash, then colcon build --symlink-install, then source install/setup.bash. tools/start_robot.sh builds if needed and starts screen sessions. Motor zeroing is either the service /set_zeros while inference is stopped, or python3 scripts/set_zero.py. This article did not compile the workspace. [14]

Twenty-three motors on four classic CAN buses

robots/rpo/robot.yaml lists motor ids 1 through 23. interface types are can, can, can, can on can0, can1, can2 and can3. Motor counts are 6, 7, 5 and 5. The README maps can0 to the left leg, can1 to the right leg and waist, can2 to the left hand and can3 to the right hand. In this file those last two groups are the five arm joints each, not fingers. Every motor_type entry is DM, the Damiao driver. motor_model is 1 on the four hip and knee joints of each leg and on the torso, and 0 on both ankles and both arms. That is 9 high-model and 14 low-model entries, matching the URDF effort split below, but the yaml does not print a torque number. [29] [14]

The IMU block is type HIPNUC on /dev/ttyUSB0 at 921600 baud. The README also asks for a 500 Hz IMU rate and says other baud rates are allowed if the rate stays above 200 Hz, provided robot.yaml is edited to match. The IMU package contains a HiPNUC serial driver and an MCT7123 driver, plus a CAN-FD socket implementation. The RPO robot yaml does not select CAN-FD for the IMU or the motors. [29] [14]

The motor library is broader than the RPO config. motor_driver.hpp defines CAN, CANFD and ETHERCAT, and control modes MIT, position and speed. Driver folders exist for DM, EVO, XYN and LRO motors. EtherCAT headers are present. Using them on RP1 would be a new configuration, not the file robots/rpo/robot.yaml. [30]

Inference is 50 Hz, and the control thread is faster

configs/default.yaml loads policy.onnx. The observation layout string is ang_vel:3, gravity_b:3, cmd_vel:3, dof_pos:23, dof_vel:23, last_action:23, with frame_stacks 10. joint_num is 23, action_scale is 0.25 and dt is 0.004 seconds with decimation 5. inference_node.cpp sleeps the inference thread for dt times decimation, which is 0.02 seconds, and sleeps the control thread for dt, which is 0.004 seconds. The control thread asks for SCHED_FIFO priority 45 and shuts down if that fails. The inference thread asks for priority 35. Other yaml files in the same folder select the AMP, parkour, interrupt, attention-encoder, getup and beyondmimic ONNX files. Those files are in models/. Their presence is not a test report. [28] [31]

Ankles are not left as two independent motors at runtime. robot.yaml sets close_chain_motor_idx to 4, 5, 10 and 11, the ankle pitch and roll indices. decouple_rpo.hpp implements a linkage conversion between motor coordinates and joint coordinates. The RPO URDF still models those ankles as independent revolute joints. A Sim2Sim run that ignores the linkage is not a test of this deploy path. [29] [32]

The RP1 overview describes this same roboparty_deploy repository as the runtime SDK for IMU, motor, dexhand, inference and camera. The checkout inspected here has camera, IMU, motor and inference packages. It has no dexhand source file. The hand driver lives in roboparty_dexhand, described in the next section. RP1_firmware's README also links a repository named RP1_deploy. That repository was not retrieved for this article. [1] [13]

Hardware design, firmware and the dexterous hand

RPO, the robot the training code matches

rpo_description models a 23-DoF humanoid. urdf/rpo.urdf, robot name rpourdf, has 23 revolute joints and no wrist-pitch joint: torso yaw, 6 per leg and 5 per arm, ending at elbow yaw. mjcf/rpo.xml adds a floating base and 23 motors. The compiler timestep is 0.001 seconds and the solver is PGS. Nine joints are tagged with effort 120 and velocity 25 rad/s: both hips, both knees and the torso. The other 14, ankles and arms, are tagged with effort 27 and velocity 8 rad/s. These are URDF limit tags, not a dynamometer result. [33] [34]

The 24 link masses in that URDF sum to 33.76 kg. As with the RP1 figure, this is the sum of the file's mass tags, not a scale measurement. V2 hardware is a different artefact from this URDF: rpo_hardware says V2.0 is mechanically incompatible with V1.0. [33] [15]

python3 scripts/check_limits.py

rpo_hardware V2.0/roboto_origin_mechanic holds SolidWorks files, STEP, STL, CNC and 3D-print folders, plus assembly PDFs. The PCB README describes RBE_Board V2.0 as a 48 V input hub, 80 mm by 60 mm, with a 5 V Type-C output rated 8 A and four 48 V XT30 outputs, plus USB 2.0 for USB-to-CAN. The files actually in 01_Gerber and 02_Assembly are named RBE_PWR_HUB V2.1 and dated 2026-04-09, while the README still mentions Gerber_RBE_Board_v2.0.zip. Use the filenames on disk. roboparty_firmware points at USB-to-CAN firmware, an Orange Pi image build and an RDK X5 image build for this older controller path. [35] [17] [36]

assets/BOM_EN.md in roboto_origin is titled Internal Roboto D-BOM, version ATOM 01 v1.0.1, date field 20260105, and prints TOTAL:49713CNY. Several lines have no unit price. The hardware README says V2.0 does not fit V1.0. Do not use 49,713 CNY as a current RP1 or V2 build quote. It is a repository document for the named ATOM 01 sheet. [37] [15]

RP Hand is documented separately from the 23-DoF arms

rp_dexhand describes RP Hand as 147.54 by 73.53 by 26.35 mm, 379 g plus or minus 10 g, worm-gear transmission, 11 mechanical degrees of freedom and 6 actively controlled axes. Tactile sensing is marked optional and not exposed by the current driver API. The maintained driver is roboparty_dexhand: a Linux SocketCAN CAN-FD C++ library, dexhand_py, and the CLI roboparty-dexhand-config, for amd64 and arm64. Its README targets Ubuntu 24.04 with system Python 3.12 and says a RoboParty image already contains the package under /opt/roboparty. The hand repository itself warns that the ROS README it ships still talks about Ubuntu 22.04, Python 3.10 and Humble, and that a combined Jazzy deployment is not presented there as verified. [11] [38]

The quick-start page says the environment check does not start the hand. It also says a configured can0 should be UP, CAN-FD, bitrate 1000000 and dbitrate 5000000. Those figures are from the documentation. They were not run against hardware here. Twelve software and CAD attachments are listed as a private prerelease, resources-2026.10.05, so a public clone does not contain every file the download page names. [39]

ROMOMO's README table lists three modules from its PDFs. RMM10062-2E is 48 V, ratio 22, rated 44 N·m and peak 160 N·m. RMM6562-2E is rated 10 N·m and peak 35 N·m. RMM8463-2E has dashes where the README says the published specification does not list speed or torque. The 160 N·m figure in company announcements matches this module table. It is not a measured whole-robot joint torque from this inspection, and the repository contains no firmware. [12]

What developers should verify before building

Joint limits do not agree everywhere, even inside the RPO path. In configs/default.yaml the first six hip limits are wider or shifted relative to urdf/rpo.urdf. Left thigh yaw is URDF [-1.0, 0.2] and yaml [-1.0, 0.6]. Left thigh roll is URDF [-0.2, 1.0] and yaml [-0.6, 1.0]. Left thigh pitch is URDF [-2.094, 0.7854] and yaml [-1.57, 1.57]. The right hip mirrors that pattern. Ankle, torso and arm pairs in that yaml matched the URDF to 0.01 rad in the comparison run for this article. Decide which file is the safety limit before sending a command. [28] [33]

Policy rate is the consistent number: 50 Hz in Isaac Lab, in sim2sim_rpo.py and in the ROS 2 inference thread. The inner physics steps are not the same: 5 ms, 1 ms and 4 ms. Copying a gain from one of those files into another timestep is a new experiment. [24] [27] [28]

• Which body you are building: RP1.3.4 CAD, the rp1.3.2 MJCF, or the 23-DoF RPO URDF.
• Whether 30-DoF and 42-DoF exist anywhere except the RP1 overview sentence.
• Which computer image you will flash. RPO deploy documents Orange Pi 5 Plus and RDK X5. RP1 firmware points at roboparty_build and a USB-CAN-FD adapter, and that tree was not populated in a non-recursive clone.
• Classic CAN at the bitrate in the RPO README, versus CAN-FD at 1 Mbit/s and 5 Mbit/s data phase in the hand quick start. They are different bus settings.
• Ankle linkage. The deploy code decouples a closed chain. The URDFs used for training do not.
• Licence of the motion pickles before you retrain AMP or BeyondMimic and publish a checkpoint.
• Calibration. The RPO mechanical folder includes a pin-calibration PDF and a wiring PDF. The RP1 BOM tells you to match part numbers to drawings. Neither replaces a zeroing procedure on the motors you received.

[14] [13] [39] [32]

Licences are not one grant

roboto_origin is an aggregation. Its root licence does not relicense the modules. Training code, including robolab and the bundled rsl_rl, is BSD-3-Clause and cannot be advertised with the RoboLab or Isaac Lab names without permission. RPO and RP1 hardware designs and the description files are CERN-OHL-W-2.0. Deployment code and the RPO firmware entry point are GPL-3.0-only, with upstream exceptions such as GPL-2.0 on orangepi-build. ROMOMO documentation is CC BY 4.0. XR teleop keeps Apache-2.0 on Unitree-derived portions. Trademarks are excluded. A binary whose origin you cannot identify should not be redistributed. [18] [10] [15] [12]

Before treating any of the shipped policies as a locomotion result, read how published balance claims should be read.

Who should explore RoboParty RP1?

Researchers who want a humanoid URDF to edit should open RP1_description and decide between the 24-DoF and 28-DoF wrist before they write a controller. They should not point an RPO-Flat config at rp1.urdf and expect the observation size of 78 to remain valid. That size is 9 base terms plus three times 23 joints. [5] [23]

Simulation developers who already have Isaac Sim 5.1 can study robolab without owning hardware. list_envs.py is the documented way to confirm the task ids after install. The useful first read is rpo_env_cfg.py and sim2sim_rpo.py, because they show the observation, the 50 Hz step and the joint permutation the deploy stack repeats. [10] [27]

Embedded engineers should pick a bus before they pick a board. The RPO path is ROS 2 Humble, four classic CAN interfaces, a HiPNUC serial IMU and a Damiao motor driver, with real-time priorities that abort the process if they cannot be set. The RP Hand path documented for new work is SocketCAN CAN-FD and a Python 3.12 driver on Ubuntu 24.04. Mixing those two setups is not described as a tested configuration. [14] [38]

Hardware builders should start from rp1_hardware if the goal is the RP1.3.4 BOM, and from rpo_hardware V2.0 only if the goal is the older Roboto Origin. The shell repository rpo_appearance says its STL files are for static display and that printing them for a moving robot is not recommended. [8] [15] [40]

What I could verify

Verified from local checkouts on 14 October 2026: the RP1 overview and the hardware, description, hand, ROMOMO and firmware READMEs; both RP1 URDF joint lists; the rp1.3.2 MJCF header; the RPO URDF and MJCF joint and effort tags; the gym registrations and the flat-task, agent, Sim2Sim and retarget sources at robolab 6b1c3d99; robot.yaml, default.yaml, the inference timing loop, the motor-driver enum and the ankle decoupler; and the RPO hardware and firmware directory layout. Two files in robolab were hashed against the raw file at that commit and matched. [23] [27] [29]

Executed: python3 scripts/check_limits.py in rpo_description at 8e0f8f7, with the three-line success output above. Also executed locally: a joint-limit comparison between default.yaml and rpo.urdf, and sums of the URDF mass tags. Those are file checks. [3]

Not executed and not claimed: Isaac Lab training, list_envs.py, MuJoCo playback, ONNX inference, ROS 2 builds, CAN or CAN-FD traffic, motor zeroing, the hand SDK's import check, and any physical walk or disturbance recovery. Shipped checkpoints were not opened. The 160 N·m peak was read from the ROMOMO README's transcription of its PDF, not from a new test. The documentation site linked from the older RPO README returned HTTP 404 on the URL printed in that README. [12] [2]

What an independent developer can reproduce

From the public files, a developer can reproduce a reading of the stack: which repository holds CAD, which URDF has 24 or 28 joints, which training task is a 23-joint RPO policy, how that policy is supposed to be checked in MuJoCo, and how the RPO ROS 2 process maps 23 motors onto four CAN buses. The limit check in rpo_description can be repeated with a standard Python 3 and no GPU. [3] [10] [14]

What cannot be reproduced from this inspection is a walking RP1. The overview is ahead of the training code. The description commit is behind the hardware revision string. The hand, the actuator PDFs and the RPO controller are three different interface stories. The next useful experiment is a narrow one: load urdf/rp1.urdf and urdf/rpo.urdf in the same viewer, confirm the joint counts, and only then decide which policy repository you are actually about to train. [5] [33]