When a model trained on one machine can cover the fleet — and when it can't.

One of the first questions we hear from teams evaluating Reforge is about scaling: if I calibrate one robot, do I need to calibrate every other robot of the same model?

The short answer is no — with a caveat that matters. A model trained on one unit of a given SKU will transfer to other units of the same SKU and deliver roughly 90% of the calibrated performance. The remaining 10% is the gap between nominally identical and physically identical. Whether that gap matters depends on your application.

This post explains what transfers across robots, what doesn't, and how to decide the right calibration strategy for your fleet.

What the model actually captures

When we calibrate a robot, we're building a mathematical model of how that specific machine behaves. For kinematic calibration, the model captures the real geometry — actual link lengths, joint axis orientations, offsets, and frame alignments as measured on the physical hardware. For dynamic calibration (vibration compensation and feedforward control), the model captures frequency response characteristics — how the robot amplifies or dampens motion at different frequencies, with what lag, and with what coupling between joints.

These properties come from two sources: the design of the robot and the specific physical instance.

Design-level properties are shared across all units of a SKU. The nominal link lengths, the gear ratios, the actuator types, the structural topology — these are determined by the engineering drawings and are consistent across the production run. A model captures these faithfully, and they transfer perfectly.

Instance-level properties vary from unit to unit. Manufacturing tolerances in link dimensions, joint axis alignment, gearbox backlash, bearing preload, cable routing, and assembly torques. These are small variations — typically tenths of a millimeter in geometry and single-digit percentage differences in dynamic parameters — but they compound through the kinematic chain and produce measurably different behavior at the TCP.

The 90% transfer

When you apply a model trained on Robot A to Robot B of the same SKU, you get the design-level correction for free. The systematic errors that all units of that model share — the difference between the nominal kinematic parameters and the actual average for that production run — are captured and corrected.

That correction alone is significant. On the platforms we've validated, the design-level error accounts for the majority of the total kinematic error. Correcting it brings most units from roughly 0.6-1.0mm of positional error down to the 0.2-0.3mm range.

The remaining instance-level error — the per-unit variation from manufacturing tolerances — is what the transferred model doesn't capture. It's real, but it's small relative to the uncalibrated baseline. This is what we mean by 90% of the performance: the transferred model eliminates most of the error, but the last increment of accuracy requires per-unit calibration.

When 90% is enough

For many applications, a transferred model is the right answer.

If your tolerance budget is 1mm and the uncalibrated robot has 2-3mm of error, a transferred model that brings every unit down to 0.2-0.3mm gives you substantial margin. You don't need per-unit calibration. You need one calibration per SKU, and every robot benefits.

This is the scaling story that matters for fleet operators. Calibrate one unit. Deploy the model across all units of that SKU. The marginal cost of adding the next robot is zero calibration time.

Applications where this works well:

• Pick-and-place with tolerances above 0.5mm. The transferred model puts every unit well inside the budget.

• Palletizing and machine tending. These applications are tolerance-friendly and benefit primarily from the speed improvement that vibration compensation provides. The dynamic model transfers well across units because the structural design is shared.

• Visual inspection at fixed stations. If the robot moves to inspection positions and stops, the accuracy requirement is at the waypoints only. A transferred kinematic model is usually sufficient.

When you need per-unit calibration

The 10% gap matters when your application consumes the full accuracy budget.

If your tolerance is 0.3mm and the transferred model delivers 0.2-0.3mm, you're operating at the margin. Some units will pass. Others won't. The variation between units becomes the limiting factor.

Per-unit calibration closes the gap. Calibrating the specific robot identifies its actual geometry — not the average geometry of its SKU — and produces a model that reaches the platform's accuracy floor. On our validated platforms, that floor is approximately 0.18-0.21mm.

Applications where per-unit calibration matters:

• Precision assembly and insertion tasks. Connector insertion, pin alignment, and similar operations where the tolerance is smaller than the per-unit variation.

• Offline programming without touch-up. If the goal is to generate paths in simulation and run them on the real robot without manual correction, per-unit accuracy is the requirement. The transferred model gets close. Per-unit calibration eliminates the remaining teaching step.

• Multi-robot coordination. When two or more robots need to agree on the location of a shared workspace, their individual kinematic errors need to be independently corrected. A shared model doesn't resolve the relative error between units.

• Quality-critical applications where out-of-tolerance means scrap — welding, dispensing, laser processing — and the cost of a single bad part exceeds the cost of calibrating the robot.

The practical approach

The calibration strategy that makes sense for most fleets is a two-tier approach.

Tier 1: One model per SKU. Calibrate one robot of each model in your fleet. Deploy that model across all units of the same SKU. This covers the design-level error and handles the majority of the accuracy improvement with minimal effort.

Tier 2: Per-unit calibration where needed. For robots in precision applications, or for units that show higher-than-expected error with the transferred model, run per-unit calibration. The process takes roughly 10 minutes for kinematic calibration. It can be integrated into commissioning workflows or run during scheduled maintenance.The process for other products is similar because our system fine-tunes the base model, combining the initial data with a smaller dataset.

The key advantage of this approach is that per-unit calibration is not expensive. With Reforge's KineCal, the calibration fixture costs under $35 in commodity hardware. The measurement routine is automated through the SDK. The model fitting runs in the cloud. An operator can calibrate a robot without metrology expertise or specialized equipment.

When calibration takes 10 minutes and costs effectively nothing in equipment, the question shifts from "can we afford to calibrate every robot?" to "is there a reason not to?"

Recalibration and drift

The transferability question also has a time dimension. A model trained today captures the robot's current state. Over months, mechanical wear changes the properties — gearbox backlash increases, bearings develop play, structural characteristics shift.

We recommend recalibrating at a minimum every six months. Robots in heavy-use or high-precision applications benefit from more frequent calibration — even as often as monthly. The calibration process is designed to run during scheduled downtime or overnight without taking the robot offline during production.

A continuous monitoring feature is on our roadmap that would use ongoing data collection to detect drift and trigger recalibration automatically. Until then, scheduled recalibration at a cadence matched to your application's tolerance budget is the practical approach.

The bottom line

You don't need to calibrate every robot from day one. A model trained on one unit covers the fleet at roughly 90% of the calibrated performance. For most applications, that's more than sufficient.

Where the last 10% matters — precision assembly, offline programming, multi-robot coordination — per-unit calibration/fine-tuning closes the gap in about 10 minutes with no specialized equipment.

The practical strategy: calibrate one per SKU as the baseline, then per-unit where the application demands it. Scale the fleet first. Calibrate precisely where it counts.

—

Reforge Robotics builds advanced motion control software that makes robot calibration fast, affordable, and repeatable.

It depends on the robot. Here's how to think about it.

The most common question we hear in customer conversations is some version of: "What kind of results should we expect?"

It's a fair question, and it doesn't have a single answer. After deploying our control software across multiple robot platforms from different manufacturers, we've learned that the honest answer is: it depends on the robot. But not in the way most people assume.

The bell curve

There's a bell curve to how much software-based calibration and control can improve a given robot.

On one end are robots with genuinely poor mechanical engineering — excessive backlash, inconsistent manufacturing, structural problems that no amount of software will compensate for. If the hardware can't repeat a motion consistently, there's no model that can predict what it will do next. These robots see limited improvement because the problem isn't the controller or the calibration. It's the machine.

On the other end are over-engineered robots — machines built with such tight tolerances and rigid structures that they already perform close to their theoretical limits. A precision industrial arm from a top-tier manufacturer running well within its speed and load envelope doesn't leave much room for software to improve. The delta between the commanded trajectory and actual behavior is already small.

The large middle is where the results happen. This is most of the robots we see in the field. Machines with decent mechanical engineering that are underperforming because their controllers don't account for the actual dynamics of the physical system. Robots that vibrate, overshoot, or drift because the software was tuned for a generic case, not the specific machine as installed.

For that middle range — which includes most cobots, most affordable industrial arms, and most robots operating near their speed or load limits — the improvements are substantial.

Three tiers of improvement

We've built three products that each address a different layer of robot performance. The improvement you see depends on which layer is your bottleneck.

Vibration compensation

This is where we started, and it remains the most dramatic result. Vibration compensation uses a calibrated dynamic model of the robot to predict and pre-compensate for structural vibration before it happens. Instead of commanding a trajectory and waiting for the robot to stop shaking, the controller shapes the input so the robot arrives at the target position cleanly.

Across our deployments, we've consistently demonstrated over 90% reduction in residual vibration. In applications where the robot must stop and wait for vibration to settle before executing the next operation — visual inspection, precision pick-and-place, dispensing — this translates directly to throughput. We've measured 2x productivity improvement in these scenarios, because you're eliminating the settling time that was consuming half of every cycle.

The catch: vibration compensation requires the most calibration data. Currently up to 48 hours of data collection, which can be spread across overnight runs over the course of a week. We're actively working to reduce this. But it's important to be transparent — this isn't a 10-minute setup.

Kinematic calibration

Every robot ships with a kinematic model — a mathematical description of the arm's geometry. And on virtually every robot we've measured, that model doesn't match the actual machine. Manufacturing tolerances, installation effects, wear, and thermal drift all contribute to a gap between where the controller thinks the robot is and where it actually is.

Kinematic calibration identifies the robot's real geometric parameters by measuring its actual positions across its workspace. The result is a corrected model that accounts for the specific machine as installed.

The improvement: 3 to 5x increase in positional accuracy. On robots where we've measured 0.6 to 1.0mm of positional error, calibration brings that down to 0.18 to 0.21mm. And the calibration itself takes approximately 10 minutes. No laser tracker. No metrology specialist. A commodity calibration fixture that costs under $35 and assembles in under five minutes.

This is the product where we hear the most immediate "I need that" from customers, because the problem is so widespread and the current alternative — a $50,000 to $150,000 laser tracker — is prohibitively expensive for most teams.

Feed-forward controller

The feed-forward controller sits between the trajectory planner and the robot's actuators. It uses a calibrated dynamic model of each joint to predict how the robot will actually respond to a given command, then pre-compensates the trajectory so the end-effector follows the intended path more closely.

The improvement: up to 10x reduction in tracking error. On one platform, we measured TCP tracking error drop from over 10mm to under 2mm. On another, from 7.6mm to 1.9mm. The more important result is that tracking accuracy stays approximately constant as speed increases — the controller compensates for the dynamics that cause error to grow with speed on stock controllers.

For teleoperation, this changes what the system can physically do. At 5mm of tracking error, you're limited to coarse tasks. At 2mm, precision assembly, connector insertion, and close-tolerance operations become feasible.

What determines where you fall on the curve

The question isn't just "how much improvement" but "which improvement matters for your application."

If your robots are running visual inspection and losing throughput to settling time, vibration compensation is your highest-leverage product. If you're running offline-programmed paths and spending days on touch-up programming because the robot doesn't go where the model says, kinematic calibration solves that. If you're building a teleoperation system and the tracking fidelity limits what tasks the operator can perform, the feed-forward controller is what you need.

Some customers need all three. Some need one. The bell curve applies to each product independently — a robot that sees 90% vibration reduction might only see 3x accuracy improvement from kinematic calibration, or vice versa, depending on where the performance gap lives.

The one thing we can say with confidence: for robots in the middle of that bell curve — which is most of them — the improvements are not incremental. They're step-changes. And they come through software, with no hardware modifications.

How to find out where your robot sits

We've designed the calibration and evaluation process so you can find out quickly. Kinematic calibration takes about 10 minutes. The feed-forward controller calibration takes 5 to 10 minutes. Vibration compensation takes longer but can run in the background during normal operations.

If you're curious whether your robot is in the middle of the bell curve — where the improvements are real and measurable — the fastest way to find out is to run the calibration and look at the data.

Reforge Robotics builds open-source motion control software that helps robots move faster, track more accurately, and behave more predictably.

The simulation-to-real gap in robot control — and what to do about it.

We spent years assuming that if we built good enough simulations, we could transfer controllers directly to real machines. The physics and control theory exist. The simulators are getting better every year. The promise of sim2real is compelling: build once in simulation, deploy everywhere in reality.

We've now deployed control software across five robot platforms from different manufacturers. Different kinematics, different actuators, different controllers, different dynamics. And every deployment has taught us the same lesson: simulation gets you to about 70% of production performance. The last 30% lives in the real machine.

What simulation gets right

We use simulation constantly. Architecture validation, trajectory planning, workspace analysis, collision checking. If you're building a robot system and you're not simulating first, you're wasting time.

Simulation is excellent at geometry. Joint limits, collision volumes, workspace boundaries — these are properties of the mechanical design, and simulators capture them faithfully. Motion planning works. Offline programming works. Idealized dynamics for trajectory planning — gravity loading, inertial forces, basic torque budgets — are reasonable because the errors are small relative to planning margins.

Simulation catches gross errors cheaply. Sign flips in coordinate frames, trajectory violations, kinematic singularities. These are expensive to find on real hardware, and simulation eliminates them before you touch a real machine. That's genuinely valuable.

Where it breaks down

The gap between simulation and reality is not in geometry. It's in dynamics.

Simulation tells you where the robot should be. Production performance depends on where the robot actually is. Those are different things, and the difference is everything.

Unmodeled dynamics. Real robots have joint flexibility, cable routing forces, friction that varies with speed and direction, backlash in gearing, and structural compliance that changes with configuration. Simulation models the arm as a chain of rigid bodies connected by ideal joints. The real system is none of those things.

Parameter uncertainty. The datasheet says the link mass is 15 kg. The actual link, with cables and connectors, is 15.3 kg. The center of mass is shifted. The gear ratio has manufacturing tolerance. The friction coefficient changes with wear, temperature, and lubrication. Every parameter is slightly wrong, and together they produce trajectories that diverge measurably from simulation.

Environmental coupling. In simulation, the robot is bolted to an infinitely rigid floor. In reality, it's mounted to a structure with its own resonant frequencies, deflections, and compliance. The base moves. The floor vibrates. The mounting plate flexes. The robot and its environment are a coupled system, and simulation models only half of it.

The pattern across five platforms

These aren't theoretical concerns. They're what we've encountered on every deployment.

On one platform, our modeling assumed symmetric rotations about the base joint — a standard simplification that works for most robot arms. On the real machine, the kinematics broke that assumption entirely. We had to rearchitect the calibration and control pipeline. No simulation would have revealed this. The discrepancy only became visible when we measured the real system's responses.

On another platform, our controller was compensating for dynamics that didn't actually exist in the real robot. The tracking error metrics appeared to improve, but the actual path deviation got worse. The controller was fighting physics that wasn't there. The problem wasn't the algorithm. It was the model.

The pattern is always the same. Simulation captures the geometry. It misses the dynamics. And the dynamics are what determine production performance — whether the robot vibrates, whether it tracks accurately, whether it can run at speed without ringing.

What surprised us most is the per-unit variation. Two robots of the same model, from the same manufacturer, installed side by side, have different friction profiles, different structural stiffness, different backlash. They are nominally identical and dynamically distinct. A controller transferred from simulation works differently on each one.

Why domain randomization isn't the answer

The standard sim2real response is domain randomization. Train across a distribution of simulated parameters so the controller is robust to whatever the real robot turns out to be. Vary the masses, vary the friction, vary the damping, and hope the real system falls inside the distribution.

This produces controllers that are robust to uncertainty. It does not produce controllers that are optimal for the actual machine.

There's a fundamental difference between "works despite not knowing the dynamics" and "works because it knows the dynamics." A controller trained to handle a wide range of possible friction values will behave conservatively on every robot. A controller calibrated to the actual friction of a specific machine will use that knowledge to move faster and more precisely.

Robustness and performance are in tension. Domain randomization chooses robustness. For production systems where cycle time, accuracy, and vibration matter, that leaves performance on the table.

Calibrate, don't transfer

Our approach inverts the sim2real framing. Instead of starting with a simulation and trying to make the controller survive the transfer, we start with the real machine and measure its actual dynamics.

We calibrate a model to the specific robot as installed — its real mass properties, its real friction, its real structural behavior. During calibration, sensor data captures the machine's physical responses while controlled excitations expose its resonant frequencies and structural compliance. From that data, we build a dynamic model of how that specific robot actually moves, bends, and vibrates.

The controller is then optimized for the actual machine, not a hypothetical distribution of possible machines.

The results validate the approach. Across multiple platforms, we've demonstrated greater than 5x accuracy improvement and greater than 85% vibration reduction with a 2x increase in productivity. All through software, with no hardware modifications.

Better calibration builds better simulation

There's an irony here. The path to better simulation runs through the real world, not away from it.

When you calibrate a model against real machine data, you force that model to become a faithful representation of the actual robot. The identified parameters — the real masses, the real friction, the real structural modes — are exactly what a high-fidelity simulator would need.

Accurate control forces the model to match reality. That model can then be reused for simulation that actually predicts real behavior. The sim2real gap doesn't close by making simulation better in isolation. It closes by making simulation match reality — and that requires measuring reality first.

Distribution is not just a go-to-market problem. Every robot we calibrate is another real-world model that makes simulation more faithful. Scale calibration, and you scale the quality of simulation itself.

The bottom line

Simulation is indispensable. We would not build without it. But if you're building production robot control — where cycle time, accuracy, and vibration performance matter — simulation alone won't get you there.

The robot you simulated is not the robot you deployed. Measure the one you have.

Reforge Robotics builds open-source motion control software that helps robots move faster, track more accurately, and behave more predictably. Learn more at by booking a demo.