The day a robot is commissioned is the day its environment starts drifting. Bearings wear in. Payloads change as the product changes. Floors settle, temperatures swing between shifts, and operators find new ways to use the cell. A controller tuned for day one slowly becomes a controller tuned for nobody.
The usual answer is a service visit: an engineer comes out, retunes the machine and leaves. By the time the next visit comes around, the drift has started again. We think the machine should be able to keep up with itself, within limits we define before it ever leaves the lab.
Why the cloud is not enough
Sending sensor data to a remote server and waiting for an answer introduces latency a motion controller cannot tolerate. A servo loop runs thousands of times a second. It cannot pause while a request crosses the internet, and it certainly cannot stop because a factory network went down.
So we keep inference on the machine. Compact models run on the controller itself, beside the servo loop, adjusting feed-forward terms, friction compensation and acceleration limits as conditions change. The cloud still has a role: collecting logs, comparing machines across a fleet and training the next version of the model. But the decisions that affect motion are made where the motion happens.
Small models, known inputs
The models we deploy are deliberately small. They see a limited set of signals, such as motor current, following error, temperature and payload estimates, and they adjust a limited set of parameters. A small model with known inputs is easier to test, easier to explain and fast enough to run on hardware that also has to close a control loop on time.
Guardrails first
Adaptation without limits is just instability with extra steps. Before we let a machine learn anything in the field, we define the envelope it is allowed to learn in. Every adjustable parameter has a minimum, a maximum and a maximum rate of change, all set and tested during validation.
If the model wants to step outside that envelope, the controller refuses, falls back to the certified baseline and flags the event for an engineer to review. The machine never discovers a new behaviour on its own. It only optimises inside a space that people have already proven safe.
Every change is logged
Each adjustment the model makes is recorded with the conditions that caused it. When a customer asks why a cell behaves differently in winter, we can show them: which parameter moved, when, by how much and why. Adaptive does not have to mean opaque.
Testing a machine that changes
Validating a system that adapts is harder than validating one that does not. We test the baseline controller the usual way, then test the adaptive layer against deliberately bad conditions: worn bearings, overloaded grippers, cold starts and sensor noise. The question is not only whether the machine performs better, but whether it ever performs worse than the baseline. If it does, the envelope gets tighter.
The payoff
Across our pilot fleet of assembly cells and humanoid research platforms, on-device tuning reduced cycle-time variance by 22% and cut energy per cycle by 9% over six months, without a single manual retune. The bigger win is harder to measure: machines that behave the same in their second year as they did on the day they were commissioned.
Adaptive control is not about making robots clever. It is about making them consistent in a world that keeps changing around them.
