RoboParty Releases Fully Open-Source Humanoid Robot RP1

That's pretty bold! This time, a humanoid robot company is actually going to tear the technical black box wide open.

You see, open-sourcing something like a humanoid robot is no simple matter. From the mechanical structure and electrical system to joint control and motion algorithms, software and hardware are linked one after another.

In the past, although some robots claimed to be "open source," what developers received might have been just an SDK, a few APIs, or part of the algorithm code.

Want to change the joint control? You can't touch it. Want to adjust the mechanical structure? You can't get the drawings. Want to run your own trained model on the real robot? The low-level interfaces become a roadblock.

But now, open source for humanoid robots is starting to push into the deepest parts of the hardware.

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

From mechanical drawings, electrical systems, and self-developed joints to low-level control, simulation, training, and deployment, RoboParty aims to lay the entire R&D chain of a humanoid robot, from hardware to software, before developers.

This is also the biggest difference between full-stack open source and merely opening up an SDK or part of the algorithm code.

Developers can not only call the robot's ready-made functions, but also go deep into the underlying layers to study why it can move and how it moves, and even modify it by hand.

RP1's own motion capabilities are also worth a look.

At 135 cm tall, it offers multiple body configurations with 24 to 30 degrees of freedom and can adapt to different scenarios such as education and research, data collection, guided tours, and entertainment. RP1 has already demonstrated a series of real-robot motion capabilities, including continuous walking, human motion tracking, disturbance recovery, and getting up after a fall.

Supporting these movements are RoboParty's self-developed ROMOMO joint modules, along with the accompanying motion control and training tools.

On one side is the visible real-robot performance; on the other is the underlying technology intended to be handed to developers.

Developers have more ways to play, but from opening up code to actually putting it to use, there are still quite a few hurdles in between.

Though all called open source, how far a humanoid robot can open up may differ considerably.

For example, a research team wants the robot to walk with a new gait.

If the manufacturer only opens high-level APIs, researchers can issue walking commands and adjust some parameters.

However, once it comes to motor response, low-level control, or even joint structure, they still have to ask the manufacturer for help.

If the experimental results are not ideal, you still cannot quickly pinpoint where the problem lies.

Is the algorithm not trained well? Are the joints not keeping up? Or is there a deviation between the simulation model and the real robot? Layer after layer of technical black boxes stand in the way, making it hard for researchers to get to the bottom of things.

Whether a robot's "open source" is sincere depends on which layer developers can modify.

With only an SDK open, developers are mainly responsible for calling functions. With control algorithms open, they can further study the robot's motion generation and execution logic.

If mechanical drawings, electrical systems, joint data, embedded software, and simulation training tools can all be opened, the room for research is much greater.

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

Especially for research institutions, research autonomy is too important.

The robot in the paper walks steadily, but on another machine it directly fails—these things are not uncommon in the lab. (doge)

Joint layout, device protocols, control frequency, and even the zero-position definition (i.e., which position the joint uses as the 0° reference) can all affect experimental results.

Without access to the underlying data, researchers have to spend a lot of time adapting the platform. Some projects may even be constrained by the hardware.

Embodied model companies have similar troubles.

Now VLA, world models, and motion control policies are taking turns, and a model may train well in simulation but not necessarily obey on the real robot.

For example, the model plans for the robot to lift its foot over an obstacle, and in simulation it goes smoothly, but on the real robot it fails due to joint response or dynamic differences.

Is it a problem with the model, or is the robot's execution off? If data, control, and hardware feedback can all be viewed and adjusted, there are more ways to pinpoint the problem.

University education also needs this degree of openness.

In the past, students might only need to call APIs to make the robot complete preset actions.

But to truly understand how the robot works, just being able to call interfaces is obviously not enough.

Being able to modify control algorithms, replace components, and even redesign the mechanical structure naturally leaves more room for teaching and research.

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

The starting points of these three types of customers seem different, but in reality, all of them hope the robot will follow research needs and not let research be trapped by the manufacturer's functional boundaries.

The role RoboParty hopes RP1 will play is exactly that of an open R&D platform.

Of course, how deep open source can go still depends on what it actually delivers.

In the official demonstration video, the robot can not only walk, run, and jump, but with vision it can also parkour over obstacles, autonomously go up and down stairs, autonomously plan its gait according to the actual terrain, quickly get up after a fall, track human motion, and instantly adjust its posture after being disturbed to maintain balance and keep its current motion state.

Behind these smooth movements is a whole set of software and hardware working together.

Take disturbance recovery as an example: the control system needs to adjust movements according to body state, the joint modules are responsible for responding to commands, and the mechanical structures such as the hips, knees, and ankles determine the postures in which the robot can complete the adjustment.

Getting up after a fall is even more complex: how the body contacts the ground, how the joints exert force, and how the center of gravity shifts all need to work together.

RP1 offers two body configurations.

The open-source version has 24 active degrees of freedom, while the open-source Pro version increases this to 30, including 2 degrees of freedom in the head and 7 in each arm, making it better suited for complex manipulation research.

Even more noteworthy is that the RP1's head and hand modules can be selected to match different scenarios.

At the hardware level, the joint module is a key component.

RP1 is equipped with RoboParty's self-developed ROMOMO integrated rotary joint.

According to the officially disclosed joint parameter table, the module's nominal peak torque covers 25–160 N·m, and it uses 48V power supply and CAN-FD communication.

Why is the torque coverage range so wide?

The hips and knees must support the body, so they have higher torque requirements; the arm ends need to balance weight, volume, and response speed.

ROMOMO adopts an inner-rotor motor paired with an NGW planetary reducer. Lower rotor inertia facilitates fast response, while the planetary reducer balances stiffness, overload resistance, and cost.

The mechanical structure is also carefully designed.

RP1 adopts a non-coincident hip and parallel ankle design. In the parallel ankle, two motors jointly participate in the foot's pitch and roll motions, and neither motor independently controls a single direction.

The joint modules also use clamp mounting and hollow cable routing, making them easy to disassemble and reducing cable interference during movement.

For ordinary users, these things are hidden inside the robot's shell. But what researchers care about is precisely these details.

Why are the joints laid out this way? What would happen with a different actuator? After adjusting the mechanism, how does the control system need to adapt?

Currently, RP1 has publicly released resources such as URDF, MJCF, and mesh models. Developers can inspect the connection relationships between the robot's joints and links for simulation and motion control research.

The mechanical design materials also cover joint axis layout, range of motion, assembly methods, and electrical architecture.

As for lower-level materials such as CAD, BOM, and circuit board manufacturing files, some still remain internal engineering records, and the specific scope of release is subject to the project repository.

Joints are responsible for executing actions, but when to exert force and how many degrees to rotate still depends on the control system.

RP1's embedded software connects hardware such as motors, inertial sensors, and battery management systems through device abstraction and unified interfaces.

The upper-level algorithms generate joint targets, the low-level drivers handle communication and execution, and then feed joint states back.

Its accompanying software uses 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.

For a robot to learn new movements, it also needs training tools.

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

hhtools first maps human motions onto the robot's structure, then corrects the motions with constraints such as joint limits and ground contact to generate motion trajectories usable by the robot.

These data can enter the simulation training pipeline, undergo policy learning and parameter tuning, and then be deployed to the real robot for validation.

Developers can study motion mapping, training, and deployment, and try out their own control strategies.

Developers can also participate in how the robot learns a movement.

It is reported that RoboParty is also building PartyOS, an open development foundation.

Currently, System0 basic motion control and related infrastructure have been partially open-sourced, including projects such as hhtools, MimicLite, and UFO. Among them, UFO conducts research on disturbance recovery and getting up after a fall, and provides configurations for multiple robots including RP1.

System1 and System2, aimed at intent representation and Agent skill orchestration, are still in the research stage.

Algorithms can run on the real robot, and daily experiments must keep up as well.

RP1 establishes collection and logging processes around robot states, sensors, and motion data to help developers check the correspondence between data and control commands.

Hot-swappable batteries, modular disassembly and assembly, standardized maintenance, and different head, end-effector, and compute configurations also facilitate continuous experimentation.

After all, a robot running out of power, parts being damaged, or equipment needing modification can all bring experiments to a halt.

Only when developers can modify it, get it running, and repeatedly validate it does an open platform have real R&D value.

The robotics industry has benefited from open source for many years.

Open-source tools such as ROS have saved many developers the trouble of repeatedly building software infrastructure.

Now, open source is beginning to reach deeper into mechanical structures, joints, electrical systems, and control systems, and more technologies originally held by manufacturers have the opportunity to become shared foundational resources for the industry.

Before RP1, RoboParty launched the open-source robot RPO. That project gained about 2,600 stars on GitHub and accumulated a group of followers.

With the release of RP1 this time, the scope of openness has further extended to the entire robot development chain.

Around this system, RoboParty has built three mutually coordinated parts.

How can this combination be used?

For example, a model company that has trained a new motion control policy can try to validate it on RP1; researchers at research institutions who have improved a joint or control module also have the opportunity to continue development based on existing designs.

Although everyone's research directions differ, they all have the opportunity to reuse foundational resources, spend less time adapting hardware, and save their energy for the problems they truly want to solve.

This is especially important for the embodied intelligence industry.

Currently, robot model evaluation still faces the problems of large hardware differences and inconsistent testing conditions. For the same task, changing to a different robot can change the success rate.

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

But open source is only the starting point.

Is the material complete? Can the repository be continuously maintained? What if there is a hardware problem? Can developers successfully reproduce and modify it? And does the license allow secondary development and commercial use?

These are all tests that open-source projects cannot avoid.

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

Whether a real ecosystem can be formed still depends on how many developers are willing to participate in the future and how many practical results can be accumulated.

For the entire industry, the significance of this matter may be greater than simply releasing one more open-source robot.

The R&D threshold for humanoid robots has always been high. Mechanical, electrical, control, and algorithms—any one of these links requires specialized talent and long-term investment.

Even to validate just one new idea, one may first have to spend considerable time building a basic platform.

Open source gives latercomers the opportunity to stand on existing achievements and continue research, and also allows the same technology to be repeatedly validated, improved, and carried forward by different teams.

Of course, publishing drawings and code does not mean hardware costs and engineering challenges will disappear. Forming a real ecosystem still requires continuous maintenance and contributions.

But as more and more foundational technologies can be studied, modified, and reused, the humanoid robot industry may be able to reduce reinventing the wheel and gain more opportunities to explore new technologies.

After all, the directions a single company can explore are limited.

Only by opening up the technical black box can more people have the opportunity to participate and push humanoid robots forward together.

Appendix: RP1 open-source resources and beta testing information

Currently, RoboParty has opened applications for the RP1 beta co-creation program, 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 the beta co-creation price.