The arm that was stable until we made it heavier

A mechanical change that invalidated a control system nobody had touched.

A mechanical change can invalidate a working control system without anyone touching the software at all, because a control loop's tuning is not really tuned to the code running it, it is tuned to the physical machine attached to that code, and changing the machine's mass, friction or geometry changes what the correct tuning actually is even while every line of software stays exactly the same as it was on the day the system worked perfectly.

What is actually happening

Every gain in a control loop, however it was arrived at, is really an answer to a specific question about the physical system it is correcting, how strongly should the controller push given how heavy, how stiff, how quick to respond this particular mechanism is. That question's answer depends entirely on the mechanism's real physical properties, and a gain tuned correctly for one set of properties is simply answering the wrong question once those properties change, regardless of how carefully the original tuning was performed or how well it once worked. A heavier arm carries more momentum for the same applied force, meaning the same correction that used to bring it smoothly to a stop now leaves it carrying more energy past the point where it was meant to settle, tipping a system that used to sit comfortably below the gain limit covered earlier in this collection into oscillation on the far side of it, without a single number in the controller's own settings ever being altered. Friction and stiffness carry the same risk as mass does, since a worn joint carrying extra drag, or a bracket that flexes more than the stiff one it replaced, both change the physical answer the tuning was originally set to answer, though neither shows up in the software's own record of itself.

The loaded-car-suspension comparison

A car's suspension tuned to feel controlled and settled with an empty boot can start feeling bouncy and prone to wallowing over bumps the moment that boot is loaded with heavy luggage for a long trip, even though nothing about the shock absorbers or springs themselves has changed in the slightest. The suspension was never tuned to the car in the abstract, it was tuned to the car carrying roughly the weight it usually carries, and adding a genuinely heavy load shifts how much momentum the car's body has to absorb after every bump, revealing a mismatch between the suspension's damping and the vehicle's new, heavier reality that was always latent and simply never had cause to show itself before. Nobody adjusted a single valve or spring rate, and yet the car's behaviour changed meaningfully, for exactly the same reason a control loop's behaviour changes when the mechanism it is correcting gets heavier without its tuning being revisited to match. A driver who notices the new wallow can usually trace it straight to the obvious extra luggage in the boot, but an engineer facing an arm that has started to oscillate has no equivalent warning light, only the same instinct to suspect whatever changed most recently and is easiest to inspect.

Why this is easy to misdiagnose

A system that starts misbehaving after a period of working correctly points, by instinct, toward whatever changed most recently and most visibly, and software is often the easiest thing to suspect, since it is the part most recently edited, most easily inspected, and most comfortable to blame because a software fix feels within reach. A mechanical change made around the same time, especially one made for an unrelated reason, a heavier arm added for more reach, a stronger bracket added for more rigidity, is easy to overlook as a possible cause precisely because it was not made with the control system in mind at all, and nobody thinks to re-examine a tuning that has not itself been touched. The investigation naturally drifts toward the wrong place, searching software for a bug that was never there while the actual cause sits quietly in a part of the machine nobody thought to reconsider. Widening the search to the full mechanical change list, mass, friction, stiffness, geometry, not only the code, is usually the fastest way back out of that dead end.

The one number worth remembering

Doubling a moving component's mass, without any other change to a control loop's tuning, can be enough on its own to push a previously well-behaved system past the gain limit covered earlier in this collection, since the same correction that once settled the lighter mechanism promptly now has meaningfully more momentum to absorb before it can actually stop, and a tuning with no real margin to spare has nothing left in reserve to cover that difference.

Where this connects to the rest of this set

This is really the same lesson as the slow sensor covered earlier in this set, arrived at from a different direction. There, a mechanical change, a heavier arm again, exposed a weakness that had always existed in the sensor's update rate but had never mattered until the mechanism moved fast enough, or carried enough momentum, to make the gap between readings consequential. Here, the same kind of mechanical change exposes a weakness in the tuning itself rather than in the sensor feeding it. Both cases share the same underlying shape, a control system whose apparent stability was never really a property of the software alone, but a property of the software paired with one particular physical machine, quietly stopping being true the moment that machine changed under it.

What follows from this

Recognising that a control loop's tuning is an answer tied to a specific mechanical reality, not a permanent property of the software, changes how any physical modification to a working machine gets treated, since even a change made for entirely unrelated reasons, more strength, more reach, more capacity, deserves a fresh look at whether the existing tuning still fits the machine it is now attached to. A control system that has not been touched can still be the part quietly broken by a change made somewhere else entirely.

My key error with this

We changed the gear material on the launcher to something stronger, which was a sound decision on its own terms and solved the problem it was aimed at, and I did not think of it as a change to anything else because the geometry was identical and the software had not been touched. The new gears were heavier, so the rotating inertia went up, and the control tuning that had been settled for weeks stopped behaving, overshooting on every launch in a way that took an embarrassing amount of time to connect back to a material substitution. The second consequence was worse and slower to find, because the higher inertia also raised the current the motor drew during acceleration past what that driver had been chosen for, so an electronics decision made months earlier quietly became wrong as well. What replaced the belief is that a material change is a change to the machine the controller is tuned against and to the load the electronics were sized for, and that a substitution which alters mass is never confined to the part it was made in.