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.

How we validated Joint Tracker's tracking improvement and what the data tells us about teleoperation performance.

We validated Joint Tracker on two 6-axis robot platforms. The goal was to measure how much model-based feedforward control actually reduces tracking error, and to understand what that reduction means for teleoperation — where tracking fidelity directly determines what tasks the system can perform.

This post walks through the validation methodology, the measured results, what drives the improvement, and why it matters for teams building teleoperation systems.

How we measured it

The validation methodology is straightforward.

We define a trajectory in task space and use inverse kinematics to convert it to joint space. The robot executes the trajectory while we capture encoder readings at each joint. We then apply forward kinematics to the encoder data to compute the actual TCP position throughout the motion.

We run this twice: once with Joint Tracker off (the robot's stock controller executing the trajectory directly) and once with Joint Tracker on. Both runs are compared against the desired trajectory.

The metric is RMS tracking error — computed per-joint in degrees and per-axis at the TCP in millimeters. Joint-level error tells you how well each actuator follows the reference. TCP error tells you what the end-effector actually does — which is what the operator experiences.

On the first platform, we swept speed from 1.0x to 2.5x nominal to see how tracking degrades with speed. On the second, we validated at 5.0x speed scale — well beyond the trajectory's original timing.

Results

Platform A (6-axis arm used in teleoperation applications):

• TCP tracking error: 7.6mm → 1.9mm (4.1x improvement)

• Joint tracking error: 1.12° → 0.24° (4.6x improvement, averaged across joints)

• Per-joint improvements ranged from 1.9x to 9.2x

• Per-axis TCP improvements: 6.0x (X), 6.1x (Y), 2.0x (Z)

• Measured at top speed scale of 2.5x

The Z-axis improvement is notably lower than X and Y. This tells us the dynamics along Z are harder to compensate — likely because the Z-axis loads gravity more directly, and the structural compliance in that direction is different. The joint-level data is consistent with this: the joints most loaded by gravity showed smaller improvement ratios.

Platform B (6-axis arm):

• TCP tracking error: 10.9mm → 1.9mm (5.7x improvement)

• Joint tracking error: 1.51° → 0.18° (8.6x improvement, averaged across joints)

• Per-joint improvements ranged from 4.7x to 15.7x

• Per-axis TCP improvements: 8.6x (X), 4.9x (Y), 4.0x (Z)

• Measured at 5.0x speed scale

The larger improvement on Platform B is partly because the baseline error was worse — 10.9mm versus 7.6mm at the TCP. The converged accuracy with Joint Tracker on is nearly identical on both platforms (1.9mm), which tells us the controller is bringing both robots to roughly the same performance floor regardless of how poor the stock tracking was.

This result is important. It suggests the residual 1.9mm error is dominated by effects the current model doesn't capture — backlash, higher-frequency structural modes, or sensor resolution — rather than by the controller itself.

User input vs. robot output with and without Joint Tracker.

The speed behavior

The most informative result isn't the headline multiplier. It's what happens as you increase speed.

With Joint Tracker off, tracking error grows approximately linearly with trajectory speed. This is expected. The stock controller uses feedback only. At higher speeds, the joints lag further behind the reference because the controller is always reacting to error rather than anticipating it. Faster motion means more dynamic error, and the feedback loop cannot keep up.

With Joint Tracker on, tracking error stays approximately constant across the speed sweep.

This is the defining characteristic of feedforward compensation. The calibrated model predicts what each joint will do at a given command, and the controller pre-compensates. The compensation scales with the trajectory, so the tracking fidelity holds as speed increases.

For teleoperation, this has a direct consequence. An operator using a system with stock control learns to slow down — they move, wait for the robot to settle, check the position visually, correct, and continue. The system's tracking error creates a feedback loop that caps the operator's throughput.

When tracking error is constant across speed, that loop disappears. The operator can move at their natural pace and trust the end-effector to follow.

What drives the tracking error

Tracking error in teleoperation comes from two sources that compound in a way that is difficult for operators to compensate for.

Kinematic error is the static component. The robot's internal kinematic model — the DH parameters, the joint offsets, the frame alignments — doesn't exactly match the real machine. Manufacturing tolerances, installation differences, and wear all contribute. The result is a systematic TCP offset that varies with joint configuration. This is not a fixed bias. It changes across the workspace, so the operator cannot learn a single correction.

Dynamic error is the speed-dependent component. At speed, each joint lags behind, overshoots, or oscillates relative to the commanded trajectory. The end-effector follows a path that diverges from what was commanded, not just at the final position but throughout the entire motion.

Our products address both. Kinematic calibration (KineCal) corrects the geometric model using measured data from the specific robot. Model-based feedforward (Joint Tracker) uses per-joint dynamic models — calibrated to the actual physical response of each joint — to pre-compensate the trajectory before it reaches the actuator driver.

The key learning from our validation work is that controller performance is tied directly to model quality. When we tested early models that didn't accurately capture the joint dynamics, the controller compensated for behavior that didn't exist on the real robot. The tracking error metric appeared to improve, but the actual contour error — the spatial deviation from the intended path — got worse. The controller was generating oscillations to counteract dynamics that weren't there.

This reinforced something we now treat as a principle: model quality is the bottleneck, not algorithm quality. A good controller with a bad model will underperform a simple controller with an accurate model.

The calibration pipeline

Joint Tracker sits in the robot's motion command pipeline between trajectory generation and the actuator driver. The pipeline from the user's perspective has three steps.

Data collection. An automated calibration routine runs on the physical robot through the Reforge SDK. Controlled excitations exercise each joint through its dynamic range while sensors record the response.

Model identification. The calibration data is uploaded to a cloud API that runs system identification. The output is a set of per-joint dynamic models that capture how each joint actually responds to commands — its lag, its resonant behavior, its damping characteristics.

Deployment. The calibrated models deploy locally with the Joint Tracker controller. For teleoperation, Joint Tracker operates in a streaming mode — it processes trajectory commands in real time as they arrive from the operator interface.

The entire calibration process is designed to run without metrology equipment or specialized engineers. The data collection is automated. The model fitting runs in the cloud. The deployment is a software update.

What 5x means for the application

Reducing TCP tracking error from 8-10mm to roughly 2mm changes what a teleoperation system can physically do.

At 5mm or more of TCP error, the system is limited to tasks with coarse tolerances — moving boxes, gross positioning, pick-and-place where the gripper has generous clearance. The robot can't place things precisely enough for tasks like connector insertion, precision assembly, or any operation where the tolerance is smaller than the tracking error.

At 2mm, tasks that were previously out of reach become feasible. This isn't about making existing tasks marginally better. It's about expanding the set of tasks the system can attempt at all.

The per-unit variation question matters here too. Two robots of the same model, from the same manufacturer, will have different dynamic characteristics — different friction profiles, different structural stiffness, different backlash. A controller tuned on one unit doesn't produce the same tracking performance on another. Per-robot calibration handles this. For manufacturers with tight tolerances, models may hold across units of the same SKU. Where they don't, calibration can be integrated into the manufacturing workflow as a standard step.

What the data tells us

The validation results across two platforms demonstrate a few things clearly.

First, model-based feedforward control delivers a measurable and consistent improvement in tracking accuracy — 4x to 8x at the joint level, 4x to 6x at the TCP. The improvement is not marginal.

Second, the speed-invariant behavior is the more important result. Flat tracking error across speed means the system's accuracy doesn't degrade as operators move faster. For teleoperation, this directly translates to higher operator throughput without sacrificing fidelity.

Third, the converged accuracy of approximately 1.9mm TCP RMS on both platforms suggests a performance floor determined by effects outside the current model's scope. Understanding and reducing that floor is the next engineering problem.

The 5x number is real and validated. But the behavior underneath it — constant accuracy across speed, per-robot calibration, model quality as the bottleneck — is what actually matters for building teleoperation systems that work at production scale.

Reforge Robotics builds open-source motion control software that helps robots move faster and track more accurately. Book a demo for access to all our data or to learn more.

—And why it's costing you more than you think.

In 2024, we set out to solve a problem that most robotics teams had learned to live with: residual vibration.

Not because it was unsolvable — the physics and control theory have existed for decades. But because solving it required bridging a gap that the robotics industry had quietly accepted. On one side, affordable robot hardware that's proliferating across every sector. On the other, motion performance that still depends on manual tuning, conservative speed limits, and a lot of patience.

Residual vibration sits right in that gap. And it's more expensive than most teams realize.

The problem hiding in plain sight

Every robotics engineer has seen it. The arm reaches the target position, and instead of stopping cleanly, it shakes. Sometimes for a few milliseconds. Sometimes long enough to watch.

What's actually happening is straightforward physics. A robot arm is not a perfectly rigid machine. It has structural compliance, actuator dynamics, cable routing, and real-world properties that the commanded trajectory doesn't account for. When the joints reach the target, the rest of the system hasn't fully settled. Energy is still stored in the structure. The end-effector oscillates around the intended position until that energy dissipates.

That oscillation is residual vibration. And it doesn't just show up at the end of moves — the robot is lagging, overshooting, and ringing at structural frequencies throughout the entire trajectory. The controller just doesn't know it.

The real cost

We've worked with teams across truck loading, precision manufacturing, and visual inspection. The pattern is always the same: vibration quietly constrains three things that directly affect the business.

The cost of vibration and Reforge Robotics' solution to it

Throughput. Every move that ends with vibration needs settling time before the next operation can begin. In a single pick-and-place cycle, that might be 50 to 200 milliseconds. Across thousands of cycles per shift, that settling time becomes hours of lost output. For high-volume applications, we're talking about a measurable hit to unit economics.

Accuracy. If the application can't wait for the vibration to settle — because the next operation starts immediately, or the arm is in continuous motion — the robot is executing at a position offset from where the controller thinks it is. In welding, dispensing, inspection, or any path-sensitive task, this degrades quality.

Deployment time. This is the one that surprises teams the most. Vibration behavior changes with speed, payload, mounting, and even the specific robot unit. A trajectory that works cleanly on one machine may vibrate badly on another. One software manager at a robotics company told us their engineers would "perpetually spend 5% of engineering time fine-tuning control speeds for different applications." Multiply that across every deployment, and you have a serious engineering bottleneck.

Why robots vibrate

Residual vibration is not a defect. It's physics.

Every robot arm is a mechanical system with mass, stiffness, and damping at every link and joint. When the robot accelerates or decelerates, those physical properties determine how the structure responds. If the commanded motion includes acceleration changes that excite the system's natural frequencies, the structure will vibrate.

Think of it like a spring-mass-damper system — the fundamental model we use in mechanical engineering. The robot's links have mass and resist acceleration (inertia). The structure resists deformation like a spring (stiffness). And energy dissipates through joint friction and material behavior (damping). The equation of motion that governs this — mx'' + cx' + kx = F(t) — is well understood. The challenge is that every robot, in every installation, has different values for those parameters.

Three factors make this especially pronounced on modern cost-effective robots:

Lighter, more flexible structures. Affordable arms use lighter materials and less rigid construction. That lowers the natural frequencies of the system, which means even moderate speeds can excite vibration. Heavier industrial robots aren't immune — they just push the problem to higher speeds.

Lower-resolution actuators. Less expensive motors and gearboxes have more compliance, and less precise torque control. What the joint actually delivers is a noisier version of what was commanded.

Generic controller tuning. Most robot controllers ship with a single set of gains optimized for a general case. They don't account for the specific payload, mounting structure, or installation. Every deployment starts with a controller that is only approximately correct for the system it's controlling.

Why common fixes fall short

The instinctive response is to slow the robot down. Lower speeds mean lower accelerations, less energy into structural modes, less vibration. It works — but it trades throughput for smoothness. At some point, the business case for automation breaks down.

The next step is manual gain tuning. An engineer adjusts controller parameters — PID gains, acceleration limits, jerk limits — until the vibration is acceptable for a specific trajectory and payload. This works for a fixed scenario. Change the speed, change the payload, move the robot to a different mounting, and you're back to tuning.

The common thread: these approaches are either too conservative, too narrow, or too labor-intensive to scale.

Closing the gap with data from the real machine

The fundamental problem is that the controller doesn't know enough about the physical system it's controlling. It commands a trajectory based on an idealized model — or no model at all — and the real dynamics create the gap that shows up as vibration.

We solve this by calibrating the robot as installed — on its real structure, with its real payloads, using its real actuators — and changing the model with the system's configuration and payload. During calibration, sensors capture the machine's physical responses while controlled excitations expose its resonant frequencies and structural behavior. From that data, we build a precise and comprehensive dynamic model — a mathematical replica of how that specific robot actually moves, bends, and vibrates.

That model deploys directly into the control architecture. The software anticipates and neutralizes physical deviations before they happen. No manual gain tuning. No conservative speed limits. No months of trial and error.

Here's what that looks like in practice on a KUKA KR500:

The results speak for themselves: we've demonstrated larger than 85% reduction in vibration even with a 2x increase in productivity. The machine gets faster and smoother at the same time — through software alone, with zero hardware modifications.

The best part is we've built production infrastructure around it. You start with a base model that you fine-tune to your setup. Our databases store and maintain models for each robot in your fleet. And we provide enterprise-grade support as you scale.

Why this matters now

Cost-effective robots are proliferating across the general-purpose robotics market. They're cheaper, easier to deploy, and increasingly paired with AI systems that can plan, perceive, and adapt.

But intelligence doesn't eliminate motion error. A robot still has to follow the path. It still has to move quickly without shaking. It still has to repeat the same motion reliably. It still has to behave in production the way it behaved in testing.

The industry has largely solved the design and mass manufacturing of affordable robots. What it hasn't solved is making those robots perform like high-end machines. That's a software problem — and it's the one we're working on.

The robot vibrates because the controller doesn't know how the real machine moves. Fix that, and the robot stops shaking.

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

Contact us to learn more about how we address residual vibration.