Our model is deterministic, not probabilistic. That's a deliberate choice.
One of the first questions we get in technical conversations is: "Is this a machine learning model?"
It's a reasonable assumption. In 2026, if someone tells you their software improves robot performance using a calibrated model, the default mental model is a neural network trained on data. The entire industry has been conditioned to assume that "model" means "learned from data in a way that's hard to explain."
Our model is not that. It's a physics-based, deterministic simulation of the robot. And the distinction matters more than you might think.
What the model actually is
When we calibrate a robot, we're building a mathematical replica of how that specific machine responds to commanded inputs. Not a statistical approximation. Not a learned mapping from inputs to outputs. A physics model.
A frequency response plot from a real calibration. The peaks show where the robot's structure amplifies motion — exactly what the physics model captures and compensates for.
The model captures the robot's frequency response characteristics — how the physical system amplifies, attenuates, and delays motion commands across the frequency spectrum. Every robot arm is a mechanical system with mass, stiffness, damping, friction, and compliance at every joint and link. Those physical properties determine how the structure responds when you command a motion. Our calibration process measures those responses and builds a model that reproduces them.
Given a tool path, the model predicts exactly how the robot will behave — where it will overshoot, where it will vibrate, where it will lag. Then we use optimization to modify the input command so that the robot's actual behavior matches the intended path. The controller doesn't learn a general mapping from experience. It predicts the specific physical response and compensates for it.
The output is deterministic. Same input, same model, same output. Every time.
Why not machine learning
We considered it. In the early days, we explored learned models. The appeal is obvious — let the data speak, don't impose assumptions about the physics, let a neural network figure out the relationship between commanded trajectories and actual behavior.
Here's what we found.
ML models learn correlations from training data. Physics models encode the system that generates the data.
Learned models are robust to what they've seen. A neural network trained on a set of trajectories performs well on similar trajectories. Move outside the training distribution — a new speed profile, a new payload, a different region of the workspace — and the predictions degrade in ways that are difficult to predict in advance. You don't know the boundary of what the model knows until you cross it.
Physics models generalize by construction. If the model correctly captures the mass, stiffness, and damping of the system, it predicts behavior for any trajectory, any speed, any payload within the system's physical limits. The model doesn't need to have seen a specific motion before. It understands the system that produces the motion.
Determinism is not optional for control. When you're modifying the commands that a robot's actuators receive, you need to know exactly what the controller will do. Not approximately. Not with a confidence interval. Exactly.
A probabilistic model has an inherent uncertainty band. For planning, for analysis, for decision support, that uncertainty band is manageable. For real-time control — where the output of the model directly determines the forces applied to a mechanical system — uncertainty means risk. A controller that occasionally produces unexpected outputs is a controller that occasionally moves the robot in ways you didn't intend.
We can't ship that. Our customers operate in environments where unexpected robot behavior has real consequences.
Explainability matters for adoption. When an engineer evaluates our software, they want to understand what it does. Not conceptually — specifically. What does the model capture? Why did it produce this output? If the result is wrong, where is the error?
A physics model answers those questions directly. The model has parameters — masses, stiffnesses, damping ratios, friction coefficients — that correspond to physical properties of the real machine. If the model's prediction doesn't match reality, you can identify which parameter is wrong and why. The debugging process follows the same engineering reasoning that roboticists already use.
A learned model doesn't offer that. The weights of a neural network don't correspond to physical quantities. When a learned model fails, the diagnostic is "retrain with more data" or "the input was outside the training distribution." That's not a diagnosis. It's a restart.
What we gain from physics
The physics-based approach has constraints. It requires a structured calibration process. It requires that we know enough about the physical system to write down the relevant equations. It doesn't handle phenomena we haven't modeled.
But it gives us three things that matter enormously in production:
Predictable behavior at boundaries. Our customers push robots to the edges of their performance envelopes — higher speeds, heavier payloads, longer duty cycles. Physics models degrade gracefully at boundaries because the equations remain valid even as the system approaches its limits. The predictions become less accurate as unmolded effects grow, but they don't suddenly produce nonsensical outputs. They fail in ways that make physical sense.
Per-robot specificity without per-robot training data sets. Every robot we calibrate gets a model tuned to its specific physical parameters. But the calibration process is structured and efficient — typically 5 to 10 minutes for kinematic calibration, 5 to 10 minutes for the feed-forward controller. We don't need hours of trajectory data covering the robot's full workspace. We need a targeted measurement of the system's physical properties.
Transferability across robots of the same SKU. This is a question we get frequently: if you calibrate one robot, does it work on identical robots? With a physics model, the answer is nuanced but useful. Robots of the same SKU share the same basic structure, so a model calibrated on one unit captures roughly 90% of the performance on siblings. The last 10% is per-unit variation — manufacturing tolerances, installation differences, wear. Per-robot calibration closes that gap, but even without it, the physics model provides a strong starting point because it's modeling the right system.
A learned model doesn't transfer as cleanly, because the learned weights encode not just the physics but also the specific noise and artifacts of the training data. A model trained on unit A doesn't generalize to unit B the way a physics model parameterized from unit A does.
The AI distinction that matters
We use the word "model" deliberately. In our context, it means a mathematical representation of a physical system — the same way an aerospace engineer builds a flight dynamics model or a structural engineer builds a finite element model. It predicts behavior from first principles and physical measurements.
We don't have anything against machine learning. We use data-driven techniques in parts of our pipeline where they're appropriate — certain aspects of system identification benefit from optimization methods that could loosely be called "learning." But the core model that drives the controller is physics. It's deterministic. It's explainable. And it produces the same output every time you give it the same input.
When a customer asks "is this AI?", the honest answer is no. And we think that's a better answer for what we're trying to do.
The robots we're improving operate in production environments where predictability, repeatability, and explainability aren't nice-to-have features. They're requirements. A physics model meets those requirements by construction. That's why we chose this path, and it's why we're staying on it.
Same input, same model, same output. Every time.
Reforge Robotics builds open-source motion control software that helps robots move faster, track more accurately, and behave more predictably.


Nosa Edoimioya
Founder & CEO
Share post
Written by
Nosa Edoimioya, Founder & CEO
Published on
Continue Reading
See what Reforge can improve on your robot
Bring one representative trajectory or error dataset. We’ll identify the relevant product, required inputs, and a bounded evaluation plan.



See what Reforge can improve on your robot
Bring one representative trajectory or error dataset. We’ll identify the relevant product, required inputs, and a bounded evaluation plan.






