Article · AI translation
Full blueprints for a humanoid robot are open source! From joints to algorithms, download them and build one yourself.
Tian Yanlin, reporting from Aofeisi
QbitAI | WeChat public account QbitAI
Tian Yanlin, reporting from Aofeisi
QbitAI | WeChat public account QbitAI
That's bold! This humanoid robot company is actually opening up its technology black box all the way down.
Humanoid robots are not so easy to open source. From mechanical structures and electrical systems to joint control and motion algorithms, the hardware and software are tightly interconnected.
In the past, although some robots claimed to be “open source,” developers might receive only an SDK, a few APIs, or some algorithm code.
Want to change joint control? You can't. Want to adjust the mechanical structure? You can't get the drawings. Want to run a model you trained on a physical robot? The low-level interfaces become another obstacle.
But now, humanoid robot open source efforts are beginning to reach deep into the hardware.
The company making the move is RoboParty. Recently, RoboParty officially released RP1, a full-stack open-source humanoid robot.
From mechanical drawings, electrical systems, and joints developed in-house to low-level control, simulation, training, and deployment, RoboParty is trying to put the entire humanoid robot development chain, from hardware to software, in developers' hands.
That is also the biggest difference between full-stack open source and merely opening up an SDK or some algorithm code.
Developers can do more than call the robot's existing functions: they can go deeper to study why and how it moves, and even modify it themselves.
RP1's movement capabilities are also worth a look.
Standing 135 cm tall and available in multiple body configurations with 24–30 degrees of freedom, RP1 can meet the needs of education and research, data collection, guided tours, entertainment, and other settings. It has already demonstrated a range of physical-robot movement capabilities, including continuous walking, tracking human movements, recovering from disturbances, and getting up after a fall.
Supporting these movements are RoboParty's self-developed ROMOMO joint modules and accompanying motion control and training tools.
On one side is visible performance on a physical robot; on the other is the underlying technology the company plans to hand over to developers.
Developers have more ways to use it, but there is still a lot involved between opening up code and putting it to practical use.
Projects may all be called open source, but how far a humanoid robot opens up can vary considerably.
For example, suppose a research team wants a robot to walk with a new gait.
If the manufacturer opens only high-level APIs, researchers can issue walking commands and adjust some parameters.
But once motor response, low-level control, or even joint structure comes into play, they still have to ask the manufacturer for help.
If the experiment's results are unsatisfactory, you cannot quickly pinpoint the problem.
Was the algorithm trained poorly? Could the joints not keep up? Or is there a gap between the simulation model and the physical robot? Layer upon layer of technology black boxes makes it hard for researchers to investigate to the bottom.
Whether a robot's “open source” claim is sincere depends on how deeply developers can modify it.
If only an SDK is opened, developers mainly call existing functions. Open up the control algorithms, and they can study how the robot generates and executes movements in greater depth.
If mechanical drawings, electrical systems, joint documentation, embedded software, and simulation and training tools are all opened up, the scope for research becomes much broader.
That is why RP1 emphasizes “full-stack open source.”
For research institutions in particular, independence in research is crucial.
A robot walks steadily in a paper, but switch to another machine and it falls flat; this is hardly uncommon in laboratories. (doge)
Joint layout, device protocols, control frequency, and even the definition of the zero position (that is, which position a joint uses as its 0° reference) can all affect experimental results.
Without access to low-level documentation, researchers must spend a great deal of time adapting to the platform. Some research topics may even be constrained by the hardware.
Embodied AI model companies have similar frustrations.
VLA, world models, and motion control policies are all being put to work now, but a model that trains well in simulation may not behave as expected on a physical robot.
For example, a model plans for a robot to lift its foot over an obstacle. It goes smoothly in simulation, but fails on the physical robot because of differences in joint response or dynamics.
Is the problem with the model, or did the robot's execution deviate from the plan? If data, control, and hardware feedback can all be inspected and adjusted, there are more ways to pinpoint the problem.
University education also needs this degree of openness.
In the past, students might only have needed to call an API to make a robot perform preset movements.
But to truly understand how a robot works, knowing how to call an interface is clearly not enough.
Being able to modify control algorithms, replace components, and even redesign mechanical structures naturally creates more room for teaching and research.
Research institutions want independence, embodied AI model companies want efficient development, and universities want students to get hands-on experience.
The 3 types of customers may seem to have different starting points, but in fact all want robots to follow their research needs rather than have research constrained by the manufacturer's functional limits.
That is the role RoboParty hopes RP1 will play: an open development platform.
Of course, how deeply it can be open sourced depends on what has actually been released.
In the official demonstration video, the robot can walk, run, and jump. With vision, it can also parkour over obstacles, go up and down steps autonomously, plan its gait autonomously based on the terrain, get up quickly after a fall, track human movements, and immediately adjust its posture when disturbed to maintain balance and its current movement state.
Behind these fluid movements is an entire set of hardware and software working together.
Take recovery from disturbances: the control system must adjust movements based on the body's state, the joint modules respond to commands, and the mechanical structures of the hips, knees, ankles, and other parts determine which postures the robot can use to make those adjustments.
Getting up after a fall is more complex: how the body contacts the ground, how the joints exert force, and how the center of gravity shifts must all work together.
RP1 offers 2 body configurations.
The open-source version has 24 active degrees of freedom, while the open-source Pro version increases that to 30, including 2 degrees of freedom in the head and 7 in each arm, making it better suited to research on complex manipulation.
Also worth mentioning is that RP1's head and hand modules can be selected to suit different settings.
On the hardware side, the joint modules are a key part.
RP1 is equipped with RoboParty's self-developed ROMOMO integrated rotary joints.
According to the officially disclosed joint specifications, the modules have rated peak torque values spanning 25–160 N·m and use 48 V power and CAN-FD communication.
Why such a wide torque range?
The hips and knees must support the body, so they require higher torque; the ends of the arms must balance weight, size, and response speed.
ROMOMO uses an inner-rotor motor paired with an NGW planetary gearbox. Lower rotor inertia helps it respond quickly, while the planetary gearbox balances rigidity, overload resistance, and cost.
The mechanical structure has its own design considerations.
RP1 uses a non-coincident hip design and parallel ankles. In the parallel ankles, 2 motors work together to produce foot pitch and roll; neither motor independently controls a single direction.
The joint modules also use clamp mounting and hollow cable routing, making them easier to remove and reducing cable interference during movement.
For ordinary users, all of this is hidden inside the robot's shell. But these are precisely the details researchers care about.
Why are the joints arranged this way? What would happen with a different actuator? After changing the mechanism, how would the control system need to adapt?
RP1 has currently released resources including URDF, MJCF, and mesh models. Developers can inspect how the robot's joints and links connect for simulation and motion control research.
The mechanical design documentation also covers joint-axis layout, ranges of motion, assembly methods, and electrical architecture.
As for more fundamental materials such as CAD, BOM, and circuit board manufacturing files, some remain internal engineering records. The precise scope of what is available should be determined from the project repositories.
The joints execute movements, but when to exert force and how far to rotate are determined by the control system.
RP1's embedded software uses device abstraction and unified interfaces to connect hardware such as motors, inertial sensors, and the battery management system.
The upper-level algorithm generates joint targets; low-level drivers handle communication and execution, then return feedback on joint states.
Its accompanying software uses a 500 Hz control frequency and a 50 Hz policy update frequency. Developers can use the unified joint-command interface to study the relationship between control and device feedback.
A robot also needs training tools to learn new movements.
RoboParty has also opened up hhtools (human-humanoid-tools), a human-motion retargeting tool.
hhtools first maps human movements onto the robot's structure, then corrects the movements using constraints such as joint limits and ground contact to generate motion trajectories the robot can use.
These data can enter a simulation training process and, after policy learning and parameter adjustment, be deployed to a physical robot for validation.
Developers can study motion mapping, training, and deployment, and try their own control policies.
Developers can also take part in how a robot learns a movement.
RoboParty is reportedly also building PartyOS, an open development foundation.
At present, parts of System0's basic motion control and related infrastructure have been open sourced, including projects such as hhtools, MimicLite, and UFO. UFO focuses on research into recovery from disturbances and getting up after falls, and provides configurations for various robots, including RP1.
System1 and System2, which target intent representation and Agent skill orchestration, are still in the research stage.
Algorithms may run on a physical robot, but day-to-day experiments also need support.
RP1 has established collection and logging processes for robot state, sensor, and movement data to help developers check how the data correspond to control commands.
Hot-swappable batteries, modular assembly and disassembly, standardized maintenance, and options for different heads, end effectors, and computing configurations also make ongoing experiments easier.
After all, a robot running out of power, damaged parts, or equipment needing modification can all bring an experiment to a halt.
An open platform has real research and development value only when developers can modify it, get it running, and validate it repeatedly.
The robotics industry has benefited from open source for years.
Open-source tools such as ROS have spared many developers the trouble of repeatedly building software infrastructure.
Now, open source is extending into mechanical structures, joints, electrical systems, and control systems. More technology previously held by manufacturers may become foundational resources shared across the industry.
Before RP1, RoboParty released the open-source robot RPO. The project received about 2,600 stars on GitHub and built up a following.
With RP1's release, the scope of openness extends further across the entire robot development chain.
RoboParty has built 3 interconnected parts around this system.
Open Body: Provides robot bodies and hardware resources, including RPO, RP1, ROMOMO joints, and RP Hand.
PartyOS: Connects development tools for motion control, perception and interaction, and whole-body manipulation; some projects remain under active development.
Developer Ecosystem: Aimed at individual developers, university research teams, and embodied AI model companies, with the aim of attracting more people to develop and improve the technology.
What can people do with this combination?
For example, a model company that has trained a new motion control policy can try validating it on RP1. Researchers at a research institution who improve a joint or control module can also continue developing it from the existing design.
Although their research directions differ, they all have opportunities to reuse foundational resources, spend less time adapting hardware, and focus their efforts on the problems they actually want to solve.
This is especially important for the embodied AI industry.
At present, robot model evaluation still faces major hardware differences and inconsistent test conditions. For the same task, changing robots can change the success rate.
If more teams conduct experiments using stable hardware versions, training tools, and testing standards, research results will have more comparable points of reference, and later researchers will find it easier to verify and improve the technology.
But open sourcing is only the starting point.
Is the documentation complete? Will the repositories be maintained? What happens if hardware has a problem? Can developers successfully reproduce and modify the work? And does the license permit further development and commercial use?
These are tests that open-source projects cannot avoid.
From RPO to RP1, RoboParty has laid out a framework spanning open robot bodies, software tools, and a developer ecosystem.
Whether it can truly form an ecosystem still depends on how many developers choose to participate and how many concrete results it can accumulate.
For the industry as a whole, this may matter more than the release of another open-source robot.
The barriers to developing humanoid robots have always been high. Mechanics, electrical engineering, control, algorithms—every part requires specialized talent and long-term investment.
Even to test a new idea, a team may first have to spend considerable time building a basic platform.
Open source gives those who come later a chance to build on existing work, and allows different teams to repeatedly test, improve, and carry forward the same technology.
Of course, publishing drawings and code does not make hardware costs or engineering challenges disappear. Building a real ecosystem also requires ongoing maintenance and contributions.
Still, as more foundational technologies become available to study, modify, and reuse, the humanoid robotics industry may be able to spend less time reinventing the wheel and have more opportunities to explore new technologies.
The directions any one company can explore are limited, after all.
Opening up the technology's black box is what gives more people a chance to participate and move humanoid robots forward together.
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
RoboParty is currently accepting applications to co-create and beta test RP1 from developers and teams with actual project needs who are willing to participate continuously in product iterations. Participants can report problems, submit Issues, and receive a special co-creation price during beta testing.
Application link:
https://roboparty.com/beta/RP1