The Renaissance of Robotics is coming.
Applied research on humanoid robots.
Pulsar Robotics is a European applied-research lab working on humanoid robots: locomotion policies, simulation, motion retargeting, and the hardware and software it takes to put a humanoid on a real floor.
Three ways a humanoid fails after the demo.
Humanoids look impressive on video. In the real world it is a different story. These are the three places the work breaks.
- 01
Sim-to-real gap
A policy that succeeds in simulation often fails on the floor. Until the gap is measured it is not an engineering problem, it is an opinion.
- 02
Fine manipulation
Picking rigid objects is broadly solved. Soft, fragile and very small objects are not, and that is where most humanoid pilots quietly stop.
- 03
Long-term reliability
Succeeding once proves almost nothing. The question is whether it repeats across a full shift, unsupervised.
Baseline, close the loop, validate.
A measurement procedure before it is a robot. The discipline is measuring the gap before and after, and writing down what did not work.
- 01
Baseline
We capture the site and the task as it is actually performed, and build the digital twin from that. The same policy runs in simulation and on the real robot, and the difference between them is the baseline every later claim is measured against.
- 02
Close the loop
System identification against the recorded runs, so the simulator matches the cell instead of the datasheet, then optimisation through reinforcement learning. Edge cases found on site are reproduced and scaled in simulation, where a failure costs a compute-hour instead of a shift.
- 03
Validate and deploy
The policy goes back onto the floor. We quantify the change against the baseline and package the edge cases as a field-validation report, so the result can be checked rather than believed.
Drive it yourself.
Trained locomotion policies driving simulated Unitree humanoids in your browser. MuJoCo compiled to WebAssembly steps the physics at 500 Hz, each robot on its own released checkpoint at 50 Hz. Nothing is scripted.
Recorded from a simulation run, not a live readout.
Where each policy stops working.
A blind policy has an envelope, and the only useful number is the edge of it. We swept the released checkpoints against test geometry.
| Ramps | climbs 8° reliably, loses it past ~10° |
| Steps | ~2 cm reliable, 4 cm every time, 5 cm almost never |
| Real stairs, 15 cm risers | topples on the second step, every time |
The cliff between a 4 cm and a 5 cm riser is sharp: eight landings out of eight against one out of eight. Eight landings is a small sample and we call it what it is: enough to place a level, not enough to publish a curve.
A thousand at once.
A locomotion policy meets more ground in an afternoon than one robot would meet in a year.
Our own footage, on a robot.
A camera is the cheapest sensor in a building and the hardest data to use. This is the pipeline we run on it, on our own footage.
- Source videoOwn footage, any camera
- Pose trackingMediaPipe
- Rigid bodySmoothed, fixed bone lengths
- Unitree G1Retargeted, in simulation
Bodies under evaluation.
The work is in the policy and the measurement, not in the chassis.
Unitree G1
132 cm · 35 kg · up to 2.0 m/s · 23 to 43 DoF
The reference body, and the platform our simulation harness already runs.
AgiBot A2
169 cm · 69 kg · up to 2.0 m/s · 40 DoF
Larger, heavier, more joints. Under consideration where reach and payload matter more than footprint.
Our own humanoid
In build, so the policies above have somewhere to run that we control end to end. It has not walked, so there are no specifications here yet; when it is measured on the bench, the numbers will appear with the run they came from.
Manufacturer figures. We publish our own numbers only from a recorded run.
What we are studying next.
Each chosen because it isolates a different failure mode, not because it is the easiest work to sell.
- targets 02
Assembly and control of automated equipment
Repetitive, precise motions on parts that do not forgive a millimetre. The clearest test of fine manipulation.
- targets 03
Order preparation and packaging
Mixed items, mixed geometries, an unforgiving cycle time.
- targets 01 and 03
End-of-line visual quality control
Repeated inspection at the end of a line. Reliability with a failure a human can read directly.
Record.
Dated, and short on purpose. We spend as much time in the field as we do writing code.
- Apr 2026URDF Studio V1
- Jun 2026Simulator benchmarking
- Jun 2026Hackathon win
- Jul 2026First pilots, on site
Questions we get.
What the lab is, what you can check yourself, and how the method runs.
What is Pulsar Robotics?
A European applied-research lab working on humanoid robots: locomotion policies, simulation, motion retargeting and our own humanoid build. A large part of the work is measuring where humanoid control fails between simulation and a real floor, and closing that gap with system identification, reinforcement learning and field validation.
What can I check for myself?
The policy sandbox on this page runs trained reinforcement-learning locomotion policies for Unitree G1, H1 and H1-2 in your browser: MuJoCo compiled to WebAssembly steps the physics at 500 Hz and each robot is driven by its own released checkpoint at 50 Hz. The measured envelope for those checkpoints is published on this page, including where they fail.
How does the method work?
Three stages. Baseline: capture the site, build the digital twin, run the same policy in simulation and reality, and record the difference. Close the loop: system identification against the recorded runs, then optimisation through reinforcement learning, with edge cases reproduced and scaled in simulation. Validate and deploy: quantify the change against the baseline and package the edge cases as a field-validation report.
Which machines does the lab work on?
Unitree G1 (132 cm, 35 kg, up to 2.0 m/s, 23 to 43 DoF) and AgiBot A2 (169 cm, 69 kg, up to 2.0 m/s, 40 DoF) are under evaluation; those are manufacturer figures. Unitree G1, H1 and H1-2 run in the sandbox because those are the humanoids with a publicly released locomotion policy. A humanoid of our own is in build.
Does the lab build its own humanoid?
One is in build, designed in-house and proven in simulation first. It has not walked, so there are no specifications on this page. When it has been measured on the bench, the numbers will appear here with the run they came from.
How does a video become a robot motion?
A source video is tracked with MediaPipe, the pose is fitted to a rigid body with fixed bone lengths so limbs stop changing length between frames, and the motion is retargeted onto a Unitree G1 in simulation. The footage on this page is our own.
What about robots at events?
Event deployments are run by Vanta Machina, the humanoid deployment agency, powered by Pulsar Robotics.
Write to the lab.
Send us a task that fails in a way you can describe: what it is, where it fails today, and what a fixed version would have to survive. If we cannot move the number, we will say so.
- We spend as much time in the field as we do writing code.
- Every number we publish comes from a spec, a recorded run or a site.
- Simulation before the floor. Always.
The people doing the work
Pasha RizaliStanislas MichelRayan El IdrissiNikhil Chandramohan RaneNader Rizk
Vanta Machina, the humanoid deployment agency, is powered by Pulsar Robotics.