By Tian Yanlin, from 凹非寺
QbitAI | Official account QbitAI
Pretty ruthless! This time, a humanoid robot company is actually tearing the technology black box all the way open.
You should know that open sourcing a humanoid robot is no simple feat. From mechanical structure and electrical systems to joint control and motion algorithms, software and hardware are interlocked at every step.
In the past, some robots claimed to be "open source", but what developers got might only be an SDK, a few APIs, or part of the algorithm code.
Want to modify joint control? Can't do it. Want to adjust the mechanical structure? No blueprints available. Want to run your own trained model on the real robot? The low-level interface becomes the roadblock.
But now, humanoid robot open source is marching into the deepest levels of the hardware.
The one making the move isRoboParty萝博派对. Recently, RoboParty officially released thefull-stack open source humanoid robot RP1。
. From mechanical drawings, electrical systems, and self-developed joints to low-level control, simulation, training, and deployment, RoboParty is trying to lay the entire R&D chain of humanoid robots, from hardware to software, in front of developers.
This is also the biggest difference between full-stack open source and merely opening up an SDK or partial algorithm code.
Developers can not only call the robot's ready-made functions, but also go down to the underlying layer to study why it moves and how it moves, and even modify it themselves.
RP1's own motion capabilities are also worth a look.
Standing 135cm tall with multiple body configurations offering 24～30 degrees of freedom, it can adapt to the different scenario needs of education and research, data collection, guided tours, entertainment and more. RP1 has already demonstrated a series of real-robot motion capabilities including continuous walking, human motion tracking, disturbance recovery, and getting up after falling.
Supporting these movements areRoboParty'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 over to developers.
Developers now have more ways to play, but there are still quite a few intricacies between open code and actually using it.
Why open up the humanoid robot all the way to the underlying layer?
Even when both are called open source, how far a humanoid robot can be opened up can vary enormously.
For example, suppose a research team wants the robot to walk with a new gait.
If the vendor only opens high-level APIs, researchers can issue walking commands and adjust some parameters.
However, once it involves motor response, low-level control, or even joint structure, they still have to ask the vendor for help.
If the experimental results are not ideal, you can't quickly pinpoint where the problem lies either.
Is the algorithm poorly trained? Are the joints failing to keep up? Or is there a deviation between the simulation model and the real robot? Layer upon layer of technical black boxes stand in the way, making it hard for researchers to trace the problem to its root.
Whether a robot's "open source" effort is genuinely sincere depends on which layer developers can actually modify.
If only the SDK is open, developers are mainly responsible for calling its functions. Opening up the control algorithms allows further research into how the robot's motions are generated and executed.
If mechanical drawings, electrical systems, joint documentation, embedded software, and simulation training tools are all opened up, the research space becomes much larger.
This is exactly why the RP1 emphasizes "full-stack open source".
Especially for research institutions, research autonomy is extremely important.
A robot that walks steadily in a paper tips right over when you switch to another machine—these things are not rare in the lab. (doge)
The joint layout, device protocols, control frequencies, and even the zero-position definition (i.e., which position each joint uses as its 0° reference) can all affect experimental results.
When low-level documentation is inaccessible, researchers have to spend a great deal of time adapting to the platform. Some research topics are even held back by hardware limitations.
Embodied model companies face similar frustrations.
Now that VLAs, world models, and motion control policies take turns on stage, a model may train well in simulation, yet not necessarily behave on a real robot.
For example, the model may plan for the robot to lift its leg over an obstacle; this goes smoothly in simulation, but on the real machine it fails due to differences in joint response or dynamics.
Is it a problem with the model, or did the robot's execution deviate?If data, control, and hardware feedback can all be inspected and adjusted, there are more handles for pinpointing problems.
Higher education likewise needs this degree of openness.
In the past, students might only need to call an API to make a robot perform preset motions.
But if you truly want to understand how robots work, merely knowing how to call interfaces is clearly not enough.
Being able to modify control algorithms yourself, swap out components, or even redesign the mechanical structure naturally expands the space for teaching and research.
Research institutions want autonomy, embodied model companies want development efficiency, and universities want students to get hands-on for real.
The three types of customers seem to start from different places, but in reality,they all want the robot to follow their research needs, rather than letting research be trapped by the vendor's functional boundaries.
The role RoboParty hopes RP1 will play is exactly such an open R&D platform.
Of course, how deep the open source can go depends on what it actually delivers.
From joints to algorithms, just how open is RP1?
In the official demonstration video, the robot can not only walk, run and jump, but with vision it can also do parkour over obstacles, go up and down stairs autonomously, autonomously plan its gait according to the actual terrain, get up quickly after falling, track human motions, and instantly adjust its posture after disturbances to maintain balance and keep its current motion state.
Behind these fluid movements is a whole set of software and hardware working together.
Take disturbance recovery, for example: the control system needs to adjust movements according to the body's state, the joint modules are responsible for responding to commands, and the mechanical structures such as the hip, knee, and ankle determine what posture the robot can use to complete the adjustment.
Falling and getting up 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 in coordination.
RP1 offers two body configurations.
The open-source version has 24 active degrees of freedom, and the open-source version Pro increases this to 30, including 2 degrees of freedom in the head and 7 degrees of freedom in each arm, making it better suited for complex manipulation research.
Even more noteworthy is that RP1's head and hand modules can be chosen optionally to match different scenarios.
At the hardware level, the joint module is one of the key links.
RP1 is equipped withRoboParty's self-developed ROMOMO integrated rotary joints.
According to the official joint parameter table, the modules' ratedpeak torque covers 25～160N·m, powered by 48V supply and using CAN-FD communication.
Huang Yi, founder of RoboParty, and the RP1 parts wall behind him
Why is the torque coverage range so wide?
The hips and knees need to support the body, so they demand higher torque; the ends of the arms must balance weight, size, and response speed.
ROMOMO usesan inner-rotor motor paired with an NGW planetary reducer solution. The lower rotor inertia enables fast response, while the planetary reducer balances stiffness, overload resistance, and cost.
The mechanical structure also involves careful design.
The 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 movements, with neither motor independently controlling a single direction.
The joint modules also feature clamp mounting and hollow routing for cables, making disassembly easy and reducing cable interference during movement.
For ordinary users, all of this is hidden inside the robot's shell. But for researchers, it is precisely these details that matter.
Why is the joint laid out this way? What happens with a different actuator? After adjusting the mechanism, how must the control system be adapted?
Currently,RP1 has publicly released resources such as the URDF, MJCF and mesh models. Developers can view 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 the electrical architecture.
As for lower-level materials such as CAD, BOM, and circuit board manufacturing files, some still remain internal engineering records; the exact scope of openness is subject to the project repository.
The joints carry out the actions, but when to apply force and how far to rotate is up to the control system.
RP1's embedded software connects hardware such as motors, inertial sensors, and the battery management system through device abstraction and unified interfaces.
Upper-level algorithms generate joint targets, low-level drivers handle communication and execution, and then joint states are fed 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 the unified joint command interface.
For a robot to learn new actions, it also needs training tools.
RoboParty has alsoreleased hhtools (human-humanoid-tools), a human motion retargeting tool.
hhtools first maps human motion onto the robot's structure, then refines the motion with constraints such as joint limits and ground contact, generating motion trajectories that the robot can use.
hhtools retargeting examples: carrying, dancing, steps, and obstacles
These data can enter the simulation training pipeline, go through policy learning and parameter tuning, and then be deployed to real hardware for validation.
Developers can study the motion mapping, training, and deployment stages, and try out their own control policies.
Developers can also take part in how a robot learns an action.
It is reported thatRoboParty is also building the PartyOS open development foundation.
Currently, part of System0 basic motion control and related infrastructure has been open-sourced, including projects such as hhtools, MimicLite, and UFO. Among them, UFO focuses on research into disturbance recovery and fall recovery, and provides configurations for multiple robots, including RP1.
System1 and System2, aimed at intent representation and Agent skill orchestration, remain at the research stage.
Algorithms must run on real hardware, and daily experiments must keep up as well.
RP1has established collection and recording processes around robot state, sensor, and action datahelping developers check the correspondence between data and control commands.
Hot-swappable battery replacement, modular disassembly and assembly, standardized maintenance, as well as different heads, end effectors, and compute configurations, also facilitate continuous experimentation.
RP1 wrist interface and three interchangeable end tools
After all, a robot running out of power, a broken part, or equipment needing modification can all bring experiments to a halt.
Only when developers can modify it, run it, and repeatedly validate it does an open platform have real R&D value.
With the technical black box opened, the ecosystem is just getting started
The robotics industry has benefited from open source for many years.
Open source tools like ROS have spared many developers the trouble of repeatedly building software infrastructure.
Now, open source is beginning to reach deep into mechanical structures, joints, electrical and control systems, and more technologies that were once held in the hands of manufacturers have the opportunity to become shared foundational resources for the industry.
Before RP1,RoboParty launched the open source robot RPO. The project received on GitHubabout 2600 Stars, accumulating a group of followers.
With this release of RP1, the scope of openness extends further to the entire machine development chain.
Around this system, RoboParty has built three mutually complementary parts.
- Open Body: Provides the robot body and hardware resources, including RPO, RP1, ROMOMO joints, and RP Hand.
- PartyOS: Connects R&D tools such as motion control, perception and interaction, and whole-body operation, some of which are still under continuous development.
- Developer Ecosystem: Aimed at individual developers, university research teams, and embodied model companies, hoping to attract more people to participate in technical development and improvement.
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 improve a joint or control module also have the opportunity to continue development on top of the existing design.
Although everyone's research directions differ, all have the chance to reuse underlying resources, spend less time adapting hardware, and devote their energy to the problems they truly want to solve.
This is especially important for the embodied intelligence industry.
Currently, robot model evaluation still faces problems such as large hardware differences and inconsistent testing conditions. The same task may show a different success rate when run on a different robot.
If more teams conduct experiments around stable hardware versions, training tools, and testing standards, research results will have a more comparable reference, and technical achievements will be easier for later comers to verify and improve.
But open source is only the starting point.
Are the materials complete? Can the repositories be maintained continuously? What if the hardware has problems? Can developers smoothly reproduce and modify it? Does the license allow secondary development and commercial use?
These are all unavoidable tests for open source projects.
From RPO to RP1, RoboParty has laid out the framework of an open body, software tools, and a developer ecosystem.
Whether a true ecosystem can actually form depends on how many developers are willing to participate going forward and how many practical results can be accumulated.
For the entire industry, the significance of this may be greater than simply releasing one more open source robot.
The R&D barrier for humanoid robots has always been high. Mechanics, electronics, control, algorithms—every link requires professional talent and long-term investment.
Even if you only want to validate a new idea, you may first have to spend considerable time building a basic platform.
Open source gives later comers the chance to continue research on top of existing achievements, and allows the same technology to be repeatedly verified, improved, and carried forward by different teams.
Of course, publishing blueprints and code does not mean hardware costs and engineering challenges disappear. Forming a real ecosystem still requires continuous maintenance and contributions.
It's just that when more and more underlying technologies can be studied, modified, and reused, the humanoid robot industry may be able to reduce reinventing the wheel and have more opportunities to explore new technologies.
The directions a single company can explore are ultimately limited.
Only by opening the technology black box can more people be brought in to push humanoid robots forward together.
Appendix: RP1 open source resources and beta test 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 the RP1 beta co-creation program, aimed at developers and teams with actual project needs who are willing to participate continuously in product iteration. Participants can report problems, submit Issues, and enjoy the beta co-creation price.
Application entry point:
https://roboparty.com/beta/RP1