RoboParty Open-Sources Full-Stack Humanoid Robot RP1 from Hardware to Algorithms

Full Blueprints for Humanoid Robots Open-Sourced! From Joints to Algorithms, Download and Build Your Own.

By Tian Yanlin, reporting from Aofeisi QbitAI | WeChat Official Account: QbitAI

This is bold! A humanoid robot company has actually decided to crack open the technical black box completely.

It’s worth noting that open-sourcing a humanoid robot is no simple feat. The software and hardware are tightly interlocked, spanning mechanical structures, electrical systems, joint control, and motion algorithms.

In the past, some robots claimed to be "open source," but developers often received only an SDK, a few APIs, or partial algorithm code.

Want to modify joint control? You can’t. Want to adjust the mechanical structure? No blueprints available. Want to run your own trained models on the actual hardware? Low-level interfaces become major roadblocks.

But now, the open-source movement in humanoid robotics is pushing into the deepest layers of hardware.

The one making this move is RoboParty. Recently, RoboParty officially released the RP1, a fully stack-open-source humanoid robot.

From mechanical blueprints, electrical systems, and proprietary joints to low-level control, simulation, training, and deployment, RoboParty aims to lay out the entire R&D pipeline—from hardware to software—for developers.

This is the biggest difference between full-stack open source and merely releasing an SDK or partial algorithm code.

Developers aren’t just calling existing functions; they can dive deep into the underlying layers to understand why and how the robot moves, and even modify it themselves.

RP1’s own locomotion capabilities are also impressive.

Standing 135 cm tall with 24–30 degrees of freedom (DoF) across various body configurations, RP1 can adapt to diverse scenarios such as education and research, data collection, guided tours, and entertainment. It has already demonstrated real-world locomotion capabilities including continuous walking, human motion tracking, disturbance recovery, and getting up after falling.

Supporting these movements are RoboParty’s proprietary ROMOMO joint modules, along with accompanying motion control and training tools.

On one side, there are visible real-world performance metrics; on the other, there is foundational technology intended for developers.

While this expands what developers can do, there are still many nuances between releasing code and making it truly usable.

Why Open Up the Underlying Layers for Humanoid Robots?

Even when labeled "open source," the extent to which a humanoid robot can be opened up varies significantly.

For example, suppose a research team wants a robot to learn a new gait pattern.

If the manufacturer only exposes high-level APIs, researchers can issue walking commands and tweak certain parameters.

However, once motor response, low-level control, or joint structure modifications are involved, they must rely on the manufacturer for help.

If experimental results are unsatisfactory, you can’t quickly pinpoint where the problem lies.

Is the algorithm poorly trained? Are the joints lagging? Or is there a discrepancy between the simulation model and the real robot? With layers of technical black boxes blocking the way, it is difficult for researchers to investigate thoroughly.

The sincerity of a robot’s "open source" status depends on how deep developers can go.

Releasing only an SDK means developers primarily call functions. Releasing control algorithms allows further study of motion generation and execution logic.

But if mechanical blueprints, electrical systems, joint specifications, embedded software, and simulation/training tools are all open, the scope for research expands dramatically.

This is why RP1 emphasizes "full-stack open source."

Especially for research institutions, autonomy in research is critical.

It’s not uncommon in labs for a robot described in a paper to walk steadily, only to tip over immediately when swapped onto different hardware. (doge)

Joint layout, device protocols, control frequency, and even zero-position definitions (i.e., which position serves as the 0° reference for a joint) can all impact experimental results.

Without access to underlying documentation, researchers spend significant time adapting to platforms. Some projects are even constrained by hardware limitations.

Embodied AI companies face similar frustrations.

With VLA (Vision-Language-Action) models, world models, and motion control strategies emerging rapidly, models may perform well in simulation but fail to behave predictably on real hardware.

For instance, a model might plan for the robot to step over an obstacle, succeeding smoothly in simulation but failing on the real robot due to differences in joint response or dynamics.

Is it a model issue, or a deviation in robot execution? If data, control, and hardware feedback are all accessible and adjustable, there are more levers for diagnosing problems.

Higher education also requires this level of openness.

In the past, students might have only needed to call APIs to make a robot perform preset actions.

But to truly understand how a robot works, simply calling interfaces isn’t enough.

Being able to modify control algorithms, replace components, or even redesign mechanical structures naturally expands the possibilities for teaching and research.

Research institutions need autonomy, embodied AI companies need R&D efficiency, and universities want students to get hands-on experience.

While these three customer segments start from different perspectives, they all share a common goal: they want the robot to follow research needs, rather than having their research confined by the vendor’s functional boundaries.

RoboParty hopes RP1 will serve exactly as such an open R&D platform.

Of course, how deep the open source goes depends on what is actually provided.

From Joints to Algorithms: How Much Does RP1 Actually Open Up?

In official demonstration videos, the robot doesn’t just walk, run, and jump. Combined with vision, it can perform parkour-style obstacle crossing, autonomously navigate stairs, plan gaits based on actual terrain, quickly recover from falls, track human motions, and instantly adjust its posture upon encountering disturbances to maintain balance and current motion states.

Behind these fluid movements lies a complete suite of coordinated hardware and software.

Take disturbance recovery, for example. The control system must adjust actions based on body state, the joint modules respond to commands, and mechanical structures like the hips, knees, and ankles determine what postures the robot can adopt during adjustment.

Getting up after a fall is even more complex. How the body contacts the ground, how the joints generate force, and how the center of gravity shifts all require precise coordination.

RP1 offers two body configurations.

The open-source edition features 24 active degrees of freedom (DoF), while the Pro version increases this to 30. This includes 2 DoF in the head and 7 DoF per arm, making it better suited for complex manipulation research.

Notably, the RP1’s head-hand module is customizable to match different scenarios.

At the hardware level, joint modules are a critical component.

The RP1 is equipped with RoboParty’s proprietary ROMOMO integrated rotary joints.

According to the official joint parameter table, the modules offer a nominal peak torque range of 25–160 N·m, utilizing 48V power supply and CAN-FD communication.

Huang Yi, founder of RoboParty, standing before the RP1 parts wall.

Why such a wide torque coverage?

The hips and knees must support the body weight, requiring higher torque; meanwhile, the arm endpoints need to balance weight, volume, and response speed.

ROMOMO employs an inner-rotor motor paired with an NGW planetary gear reducer. The lower rotor inertia facilitates rapid response, while the planetary reducer balances stiffness, overload resistance, and cost.

Mechanical design also involves careful consideration.

The RP1 adopts a non-coaxial hip design and a parallel ankle mechanism. In the parallel ankle setup, two motors jointly contribute to foot pitch and roll movements, with neither motor controlling a single direction independently.

The joint modules also feature clamp-style mounting and hollow-shaft wiring designs, facilitating easy disassembly and reducing cable interference during motion.

For general users, these details are hidden inside the robot’s shell. However, researchers care precisely about these specifics.

Why is the joint layout designed this way? What happens if actuators are swapped? How does the control system adapt after mechanical adjustments?

Currently, RP1 has publicly released resources including URDF, MJCF, and mesh models. Developers can examine the connection relationships between robot joints and links for simulation and motion control research.

Mechanical design documentation also covers joint axis layouts, ranges of motion, assembly methods, and electrical architecture.

Regarding deeper-level materials such as CAD files, BOMs, and PCB manufacturing files, some remain internal engineering records. The specific scope of openness depends on the project repository.

Joints execute actions, but when to apply force and how much to rotate is determined by the control system.

RP1’s embedded software connects hardware—including motors, inertial sensors, and battery management systems—through device abstraction and unified interfaces.

Upper-layer algorithms generate joint targets, while low-level drivers handle communication and execution, feeding back joint states.

Its accompanying software utilizes a 500Hz control frequency and a 50Hz policy update frequency. Developers can study the relationship between control and device feedback around a unified joint command interface.

To learn new actions, robots require training tools.

RoboParty has also open-sourced hhtools (human-humanoid-tools), a human motion retargeting tool.

hhtools first maps human motions to the robot structure, then refines the movements using constraints such as joint limits and ground contact, generating motion trajectories usable by the robot.

hhtools retargeting examples: carrying objects, dancing, climbing stairs, and navigating obstacles.

This data can enter the simulation training pipeline, undergo policy learning and parameter tuning, and finally be deployed for real-world validation.

Developers can explore action mapping, training, and deployment stages, experimenting with their own control strategies.

Developers can actively participate in how robots learn actions.

Reportedly, RoboParty is also building PartyOS, an open development foundation.

Currently, System0 basic motion control and related infrastructure have been partially open-sourced, including projects like hhtools, MimicLite, and UFO. Among them, UFO focuses on disturbance recovery and fall-recovery research, providing configurations for various robots, including the RP1.

System1 and System2, which target intent representation and Agent skill orchestration, are still in the research phase.

For algorithms to run on real robots, daily experiments must keep pace.

RP1 establishes data collection and logging workflows centered on robot state, sensor data, and action data, helping developers verify the correspondence between data and control commands.

Hot-swappable batteries, modular disassembly, standardized maintenance, and interchangeable heads, end-effectors, and compute configurations facilitate continuous experimentation.

RP1 wrist interface and three types of swappable end-effectors.

After all, experiments can halt due to battery depletion, part damage, or the need for equipment modifications.

Only when developers can modify, run, and repeatedly validate the system does an open platform hold true R&D value.

Opening the Technical Black Box: The Ecosystem Is Just Beginning

The robotics industry has benefited from open source for years.

Open-source tools like ROS have saved many developers from the hassle of redundantly building software infrastructure.

Now, open source is delving into mechanical structures, joints, electronics, and control systems. More technology previously held by manufacturers has the opportunity to become shared foundational resources for the industry.

Prior to RP1, RoboParty launched the open-source robot RPO. The project garnered approximately 2,600 Stars on GitHub, accumulating a base of followers.

With the release of RP1, the scope of openness extends further into the full-body R&D chain.

RoboParty has built three interconnected components around this system:

• Open Body: Provides robot bodies and hardware resources, including RPO, RP1, ROMOMO joints, and RP Hand.
• PartyOS: Connects R&D tools for motion control, perception interaction, and whole-body manipulation, with some projects still under continuous development.
• Developer Ecosystem: Targets individual developers, academic research teams, and embodied AI model companies, aiming to attract more participants in technical development and refinement.

How can this combination be utilized?

For example, a model company that has trained a new motion control strategy can validate it on the RP1. Researchers at scientific institutions who have improved a specific joint or control module also have the opportunity to continue development based on existing designs.

Although everyone’s research directions differ, all teams can reuse underlying resources, spend less time adapting to hardware, and focus their energy on solving the problems they truly care about.

This is particularly important for the embodied AI industry.

Currently, robot model evaluation still faces challenges such as significant hardware variations and inconsistent testing conditions. For the same task, switching to a different robot may result in changes to the success rate.

If more teams conduct experiments around stable hardware versions, training tools, and testing standards, research results will have more comparable references, making technical achievements easier for subsequent researchers to verify and improve.

But open-sourcing is just the starting point.

Is the documentation complete? Can the repository be maintained continuously? What happens if there are hardware issues? Can developers smoothly reproduce and modify the code? Does the license permit secondary development and commercial use?

These are unavoidable tests for any open-source project.

From RPO to RP1, RoboParty has already laid out the framework for an open-body platform, software tools, and developer ecosystem.

Whether a true ecosystem can form depends on how many developers are willing to participate and how much tangible progress can be accumulated.

For the entire industry, the significance of this initiative may be greater than simply releasing another open-source robot.

The barrier to entry for humanoid robot R&D has always been high. Mechanics, electronics, control systems, and algorithms—every link requires specialized talent and long-term investment.

Even if you only want to test a new idea, you might first need to spend considerable time building a foundational platform.

Open-sourcing allows newcomers to build upon existing achievements, enabling the same technology to be repeatedly verified, improved, and sustained by different teams.

Of course, publishing blueprints and code does not mean that hardware costs and engineering challenges disappear. Forming a true ecosystem requires continuous maintenance and contributions.

However, when more underlying technologies become available for research, modification, and reuse, the humanoid robot industry may reduce redundant efforts ("reinventing the wheel") and create more opportunities for exploring new technologies.

A single company can only explore limited directions.

Only by opening up the "black box" of technology can we invite more people to participate and collectively push humanoid robotics forward.

Appendix: RP1 Open-Source Resources and Beta Testing Information

[1] RP1 Development Resources: https://github.com/Roboparty/RP1

[2] Technical White Paper: https://roboparty.com/documents/roboto-01

Currently, RoboParty has opened applications for RP1 beta co-creation, targeting developers and teams with actual project needs who are willing to continuously participate in product iteration. Participants can provide feedback, submit Issues, and enjoy special pricing for beta co-creation.