Do You Need to Calibrate Every Robot?

8/27/26

What Kind of Improvement Can You Actually Expect from Robot Software?

By Iago Alves Pereira

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.

8/27/26

What Kind of Improvement Can You Actually Expect from Robot Software?

By Iago Alves Pereira

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.

8/17/26

Why Sim2Real Falls Short for Robot Control

By Nosa Edoimioya

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.

8/17/26

Why Sim2Real Falls Short for Robot Control

By Nosa Edoimioya

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.

Industrial robot arm measuring positional error against a calibration target

8/14/26

The Hidden Cost of Uncalibrated Robots

By Iago Alves Pereira

What poor accuracy actually costs — and why most teams don't see it.

Every industrial robot ships with a spec sheet that lists repeatability — typically ±0.05mm or better. That number is real. It means the robot can return to the same joint configuration with extraordinary consistency.

But repeatability is not accuracy. Repeatability tells you the robot can do the same thing twice. Accuracy tells you it's doing the right thing in the first place. The gap between those two concepts is where factories and warehouses quietly lose money — in ways that rarely show up on a single line item.

What "accuracy" actually means for a robot

A robot's controller plans motions using a kinematic model — a mathematical description of the arm's geometry. Link lengths, joint axis orientations, offsets, and frame alignments. If that model exactly matches the physical machine, the robot goes where it's told. If it doesn't, every commanded position has a built-in error.

The problem is that the model almost never matches the machine.

Manufacturing tolerances. No two robot arms are geometrically identical. The actual link lengths, joint axes, and offsets differ from the nominal model by tenths of a millimeter. The controller doesn't know this. It plans motions using an idealized machine that doesn't exist.

Installation effects. The base plate isn't perfectly level. The mounting structure has compliance. The tool center point and fixturing differ from what offline programming assumed. Before the robot runs its first cycle, it's already working from a map that doesn't match the territory.

Thermal drift. A robot that's accurate at 7 AM may be measurably different by 2 PM after hours of continuous operation. A robot OEM we spoke with confirmed that damping characteristics change over time and with temperature, justifying repeated recalibration. It's not a one-time problem.

Wear and damage. Gearbox backlash increases. Bearings develop play. Cable routing forces change. After a collision — which happens — kinematic error increases significantly and the robot needs recalibration. The geometry drifts from installation day forward.

The result is that the commanded position and the actual position are never quite the same. And most teams have no instrumentation to quantify the gap.

What this looks like in practice

We visited a bio-manufacturing company running dozens of robots across their facility. They observed 2–3mm of positional error when commanding the same Cartesian position from different joint configurations. Their existing calibration — adjusting joint reference offsets only — closed just 0.2–0.4mm of that gap. Their assessment: global kinematic accuracy is currently unsolved.

That same company sells robotic lab cells to third parties, meaning their customers also need to calibrate robots in the field. The cost compounds across their fleet and their customers' fleets.

The part that stuck with us: they told us their customers will likely not have a method to quantify the kinematic error accurately. They can't see the cost because they can't measure it.

This is the pattern we see in almost every conversation with startup robotics teams. The error is real, the cost is distributed, and the teams bearing it don't have the tools to put a number on it.

Where the money goes

The costs of uncalibrated robots don't appear on a single line item. They're distributed across the operation in ways that feel normal until you add them up.

Scrap and rework. Welding runs off-seam. Dispensing lands in the wrong location. Inspection measures the wrong point. The root cause is positional error, but it gets attributed to programming mistakes or process variation.

Touch-up programming. After offline programming generates a path, an engineer jogs the robot through each waypoint to correct for real-world positional error. Hundreds of waypoints means days per program. Every new part, every program change, every robot replacement triggers another round. One software manager at a robotics company told us their engineers "perpetually spend 5% of engineering time fine-tuning control speeds for different applications." That's not engineering. That's compensating for a geometric problem with labor.

Speed constraints. An uncalibrated robot may hold tolerance at 50% speed but drift out of spec at 80%. The easy fix is to run slower. The compounding cost is lost throughput across every shift, every day — and most teams never quantify what they're leaving on the table.

Settling time. Robots need 50–200ms per move for vibration to settle before the process can execute. Across thousands of cycles per shift, that settling time becomes hours of lost output.

Cell-to-cell variation. Programs aren't interchangeable between nominally identical cells because each robot has its own error signature. Scaling from 1 line to 10 doesn't mean copying a program 10 times. It means commissioning 10 times.

Deployment time. This is where the cost really hides. An integrator we work with estimates that 30–40% of deployment time goes to accuracy-related commissioning — not programming the task, but teaching the robot where things actually are versus where the model says they should be. For a deployment that takes weeks, that's days of engineering time burned on a problem that could be solved upstream.

If you're managing a robotics operation, some of these will look familiar. The question is whether you've added them up.

Why teams live with it

Traditional calibration requires a laser tracker — $50,000 to $150,000 in equipment — plus trained metrology engineers and hours or days of production downtime.

For high-value applications — aerospace machining, medical device assembly, precision metrology — the math works. Sub-millimeter accuracy is a hard requirement, and the parts are valuable enough to justify the investment. These industries calibrate routinely.

For everyone else — welding lines, palletizing, machine tending, general assembly — the error is manageable. Teams compensate with touch-up programming, slower speeds, and wider tolerances. It's not that they don't know uncalibrated robots cost them money. It's that the cure has historically been more expensive than the disease.

The result is an industry-wide pattern: most industrial robots run uncalibrated, with kinematic models that don't match the machines they describe.

The economics are changing

Two things are shifting the equation.

Accuracy requirements are tightening. As robots move into applications that were previously manual — precision assembly, lab automation, adaptive welding, high-mix manufacturing — the tolerance budgets that worked for single-SKU palletizing don't survive contact with flexible workcells running dozens of part variants.

The cost of calibration is dropping. New approaches use the robot's own sensors and structured measurement routines instead of external metrology equipment. A calibration fixture can be built from commodity hardware for under $35 and assembled in under five minutes. The calibration process takes minutes, not hours. No laser tracker. No metrology specialist. No production shutdown.

We've validated internally that this approach brings positional accuracy from roughly 0.6–1.0mm down to 0.18–0.21mm — a 3x to 5x improvement. That's the difference between a robot that needs touch-up programming and one that runs from offline-generated paths. Between a cell that takes a week to commission and one that takes a day.

When calibration becomes cheap enough to repeat after every tool change, every collision, every maintenance window, the economics invert.

How to evaluate whether calibration makes sense for your operation

Not every robot cell needs sub-millimeter accuracy. If you're running a single-SKU palletizing line with wide tolerances, the existing model may be good enough.

Calibration makes sense when:

Your team is spending days on touch-up programming after every new part or program change. That labor cost is the calibration problem in disguise.

You're running robots below rated speed to hold tolerance. The throughput you're leaving on the table compounds across every shift.

Programs aren't portable between cells. If scaling from 1 line to 10 means commissioning each one from scratch, per-robot kinematic error is almost certainly the cause.

Deployment timelines are dominated by commissioning, not programming. If 30–40% of deployment time is accuracy-related, calibration solves the bottleneck.

You're moving into higher-precision applications — adaptive welding, lab automation, inspection, assembly — where the tolerance budget no longer absorbs the kinematic error.

Your fleet is growing. The cost of uncalibrated robots scales linearly with fleet size. Calibration cost, done right, doesn't have to.

The question is no longer "can we afford to calibrate?" It's whether you can afford not to.

Reforge Robotics builds open-source motion control software that makes robot calibration fast, affordable, and repeatable. Get in touch to learn more.

8/14/26

The Hidden Cost of Uncalibrated Robots

By Iago Alves Pereira

What poor accuracy actually costs — and why most teams don't see it.

Every industrial robot ships with a spec sheet that lists repeatability — typically ±0.05mm or better. That number is real. It means the robot can return to the same joint configuration with extraordinary consistency.

But repeatability is not accuracy. Repeatability tells you the robot can do the same thing twice. Accuracy tells you it's doing the right thing in the first place. The gap between those two concepts is where factories and warehouses quietly lose money — in ways that rarely show up on a single line item.

What "accuracy" actually means for a robot

A robot's controller plans motions using a kinematic model — a mathematical description of the arm's geometry. Link lengths, joint axis orientations, offsets, and frame alignments. If that model exactly matches the physical machine, the robot goes where it's told. If it doesn't, every commanded position has a built-in error.

The problem is that the model almost never matches the machine.

Manufacturing tolerances. No two robot arms are geometrically identical. The actual link lengths, joint axes, and offsets differ from the nominal model by tenths of a millimeter. The controller doesn't know this. It plans motions using an idealized machine that doesn't exist.

Installation effects. The base plate isn't perfectly level. The mounting structure has compliance. The tool center point and fixturing differ from what offline programming assumed. Before the robot runs its first cycle, it's already working from a map that doesn't match the territory.

Thermal drift. A robot that's accurate at 7 AM may be measurably different by 2 PM after hours of continuous operation. A robot OEM we spoke with confirmed that damping characteristics change over time and with temperature, justifying repeated recalibration. It's not a one-time problem.

Wear and damage. Gearbox backlash increases. Bearings develop play. Cable routing forces change. After a collision — which happens — kinematic error increases significantly and the robot needs recalibration. The geometry drifts from installation day forward.

The result is that the commanded position and the actual position are never quite the same. And most teams have no instrumentation to quantify the gap.

What this looks like in practice

We visited a bio-manufacturing company running dozens of robots across their facility. They observed 2–3mm of positional error when commanding the same Cartesian position from different joint configurations. Their existing calibration — adjusting joint reference offsets only — closed just 0.2–0.4mm of that gap. Their assessment: global kinematic accuracy is currently unsolved.

That same company sells robotic lab cells to third parties, meaning their customers also need to calibrate robots in the field. The cost compounds across their fleet and their customers' fleets.

The part that stuck with us: they told us their customers will likely not have a method to quantify the kinematic error accurately. They can't see the cost because they can't measure it.

This is the pattern we see in almost every conversation with startup robotics teams. The error is real, the cost is distributed, and the teams bearing it don't have the tools to put a number on it.

Where the money goes

The costs of uncalibrated robots don't appear on a single line item. They're distributed across the operation in ways that feel normal until you add them up.

Scrap and rework. Welding runs off-seam. Dispensing lands in the wrong location. Inspection measures the wrong point. The root cause is positional error, but it gets attributed to programming mistakes or process variation.

Touch-up programming. After offline programming generates a path, an engineer jogs the robot through each waypoint to correct for real-world positional error. Hundreds of waypoints means days per program. Every new part, every program change, every robot replacement triggers another round. One software manager at a robotics company told us their engineers "perpetually spend 5% of engineering time fine-tuning control speeds for different applications." That's not engineering. That's compensating for a geometric problem with labor.

Speed constraints. An uncalibrated robot may hold tolerance at 50% speed but drift out of spec at 80%. The easy fix is to run slower. The compounding cost is lost throughput across every shift, every day — and most teams never quantify what they're leaving on the table.

Settling time. Robots need 50–200ms per move for vibration to settle before the process can execute. Across thousands of cycles per shift, that settling time becomes hours of lost output.

Cell-to-cell variation. Programs aren't interchangeable between nominally identical cells because each robot has its own error signature. Scaling from 1 line to 10 doesn't mean copying a program 10 times. It means commissioning 10 times.

Deployment time. This is where the cost really hides. An integrator we work with estimates that 30–40% of deployment time goes to accuracy-related commissioning — not programming the task, but teaching the robot where things actually are versus where the model says they should be. For a deployment that takes weeks, that's days of engineering time burned on a problem that could be solved upstream.

If you're managing a robotics operation, some of these will look familiar. The question is whether you've added them up.

Why teams live with it

Traditional calibration requires a laser tracker — $50,000 to $150,000 in equipment — plus trained metrology engineers and hours or days of production downtime.

For high-value applications — aerospace machining, medical device assembly, precision metrology — the math works. Sub-millimeter accuracy is a hard requirement, and the parts are valuable enough to justify the investment. These industries calibrate routinely.

For everyone else — welding lines, palletizing, machine tending, general assembly — the error is manageable. Teams compensate with touch-up programming, slower speeds, and wider tolerances. It's not that they don't know uncalibrated robots cost them money. It's that the cure has historically been more expensive than the disease.

The result is an industry-wide pattern: most industrial robots run uncalibrated, with kinematic models that don't match the machines they describe.

The economics are changing

Two things are shifting the equation.

Accuracy requirements are tightening. As robots move into applications that were previously manual — precision assembly, lab automation, adaptive welding, high-mix manufacturing — the tolerance budgets that worked for single-SKU palletizing don't survive contact with flexible workcells running dozens of part variants.

The cost of calibration is dropping. New approaches use the robot's own sensors and structured measurement routines instead of external metrology equipment. A calibration fixture can be built from commodity hardware for under $35 and assembled in under five minutes. The calibration process takes minutes, not hours. No laser tracker. No metrology specialist. No production shutdown.

We've validated internally that this approach brings positional accuracy from roughly 0.6–1.0mm down to 0.18–0.21mm — a 3x to 5x improvement. That's the difference between a robot that needs touch-up programming and one that runs from offline-generated paths. Between a cell that takes a week to commission and one that takes a day.

When calibration becomes cheap enough to repeat after every tool change, every collision, every maintenance window, the economics invert.

How to evaluate whether calibration makes sense for your operation

Not every robot cell needs sub-millimeter accuracy. If you're running a single-SKU palletizing line with wide tolerances, the existing model may be good enough.

Calibration makes sense when:

Your team is spending days on touch-up programming after every new part or program change. That labor cost is the calibration problem in disguise.

You're running robots below rated speed to hold tolerance. The throughput you're leaving on the table compounds across every shift.

Programs aren't portable between cells. If scaling from 1 line to 10 means commissioning each one from scratch, per-robot kinematic error is almost certainly the cause.

Deployment timelines are dominated by commissioning, not programming. If 30–40% of deployment time is accuracy-related, calibration solves the bottleneck.

You're moving into higher-precision applications — adaptive welding, lab automation, inspection, assembly — where the tolerance budget no longer absorbs the kinematic error.

Your fleet is growing. The cost of uncalibrated robots scales linearly with fleet size. Calibration cost, done right, doesn't have to.

The question is no longer "can we afford to calibrate?" It's whether you can afford not to.

Reforge Robotics builds open-source motion control software that makes robot calibration fast, affordable, and repeatable. Get in touch to learn more.

←

Blogs