14 Sep 2026Sankalp Chopkar7 min read
Your policy is only as good as your URDF
When a policy that walked beautifully in simulation stumbles on the real robot, the first suspects are usually the simulator, the reward or the domain randomization. In my experience the problem often started much earlier, on the bench, in the robot description file everyone trained on.
The robot the policy actually learned
A reinforcement-learning policy never sees your robot. It sees the URDF: a tree of links and joints, each with a mass, a centre of mass, an inertia tensor, joint limits and collision shapes. Every one of those numbers is a claim about the physical machine. If the claims are wrong, the policy is trained on a different robot, and no amount of randomization fully closes a gap that was baked in on day one.
At Tuesday Labs we rebuild a commercial humanoid into Voxel: a new torso and head, a new pelvis, new leg structures, new electronics. Each change moves mass and moves the centre of mass. The ML team trains locomotion and expressive motion on the model of that robot, so the model has to change every time the hardware does.
What "accurate" means
- Mass per link, measured. CAD gives you a starting point. The scale gives you the truth.
- Centre of mass and inertia per link, consistent with that mass, not copied from the vendor model after the part changed.
- Joint limits, effort and velocity that match the actuators and the hard stops on the real build.
- Sensor frames and fields of view placed where the cameras actually sit, so perception in sim sees what the robot sees.
- Meshes in the right units and frames. A part exported from SolidWorks in millimetres and dropped into a URDF in metres is a thousand times too big, and someone will lose an afternoon to it.
Where the errors come from
Almost every error I've found had a mundane cause.
3D-printed parts are not solid. A printed shell's effective density depends on material, infill and walls. Modelling it as solid plastic overstates its mass; ignoring it understates. We assign an effective density per print material and compute shell mass from the CAD volume.
CAD forgets the things that weigh the most surprising amounts: wiring, connectors, fasteners, adhesives, cable slack. The CAD-derived model of a real robot almost always comes in light. In one refit the baseline model was more than 3 kg under the measured robot. We distribute that correction to the links that actually carry it rather than pretending it isn't there.
Changed parts keep their old properties. When you redesign a torso, the old inertia tensor quietly survives in the URDF unless someone owns updating it.
Mirrors and frames. Left and right parts that are mirrored in CAD, joint origins that drift between assemblies, a camera mount moved two centimetres in the last revision. Each one is small; together they are a different robot.
Making it fast enough to keep up
Accuracy that arrives a week late is accuracy nobody uses. Industrial design and hardware iterate quickly, and if the asset lags, ML trains on last month's robot. So I built tooling to make an accurate asset the default, not a project:
- URDF Designer swaps new CAD shells into the robot, rescales them, aligns them to link frames and exports a clean URDF and meshes in one package.
- Inertia Forge refits mass properties: per-material densities, shell mass from CAD volume, and a baseline correction to the measured robot mass.
- Static Pose Analyzer checks whether the robot can actually hold a pose: balance margin, centre of pressure and per-joint torque against the limits, before a motion is ever run.
Together they took asset turnaround from about a week to about two hours. The real win is cultural: when updating the model is cheap, people do it every time.
A checklist I'd hand to any hardware team
- Weigh the robot, and weigh the big subassemblies. Write the numbers down next to the URDF version.
- Own the asset like you own the CAD. Every hardware change ships with a URDF change.
- Use real densities for printed and composite parts, and account for wiring explicitly.
- Check units, mirrors and frames visually, overlaid on the CAD, every time.
- Validate statically before dynamically: if the model can't stand where the robot stands, don't train on it.
- Make the pipeline fast. Two hours gets used. A week gets skipped.
Sim-to-real is a shared problem, but the hardware team can remove a whole class of it before training even starts. The most useful thing I can give an ML engineer is a model of the robot that is true.
19 Oct 2026Sankalp Chopkar6 min read
Hardware is the part of robotics that says no
You can do a lot of robotics without hardware: planning, perception, learning, simulation. It is real and valuable work. But until it runs on a machine, it is a very good simulation. Hardware is where the ideas meet torque limits, heat, batteries and a floor that is not quite flat.
Hardware sets the envelope
Every controller and every policy works inside an envelope the hardware defines. Peak and continuous torque, joint speed, mass and where it sits, stiffness and backlash, the range of each joint. On Voxel the knee is rated to 139 N·m. No amount of clever software makes it 160.
Sometimes the envelope shows up in places you don't expect. Voxel's eyes are two 8×8 LED panels. At full white those 128 LEDs would pull around 4 A, more than the panel wiring should carry, so the firmware caps brightness at 25%. The robot's expressions, a character decision, are shaped by a current limit, a hardware decision.
Hardware sets the speed of learning
How fast a team learns depends on how fast it can try things on a real robot, and how much a failure costs. Before our full-size robots, I built three 33%-scale bipeds from scratch so the software team could test locomotion policies on hardware that was cheap to crash. When we needed full-size platforms, the bar was speed: two 40 kg bipedal, bimanual robots, designed, fabricated, assembled and wired in two months.
Speed also means knowing what not to build. Voxel Series-1 starts from a commercial humanoid. We kept the stock structure where it already worked, like the load-bearing core of the feet, and rebuilt everything that defined our robot around it: the head and torso, the pelvis, the legs, the foot shells and the electronics. That choice bought months.
Hardware decides what you can measure
Data is only as good as the instrument. On the GelSight skin probe, a load cell lets each capture happen at the same contact force, because a tactile image taken at a different force is a different measurement. In Magnify's sample-prep device, a heated chamber held to ±0.2 °C is the difference between a usable sample and a ruined one. On Spot and on drones, where a camera is mounted and how rigidly decides whether calibration survives the first field day.
Hardware decides what survives
A robot that works once is a demo. A fleet that works every day is a product. Supporting five robots through launches and demos taught me that serviceability is a design requirement: connectors you can reach, parts you can swap, a board you can debug without a teardown, and a shared record of what broke and why. Some of that is mechanical design. Some of it is a booking and repair board on a wall.
So, who wins?
Nobody, and that's the point. The best robots I've worked on came from teams where hardware engineers thought about the policy, and ML engineers knew the gear ratio. Hardware says no a lot. A good hardware engineer's job is to say it early, with numbers, and then find the yes.
