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.

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.