Easy Reasons a Person Can Make Motor Speed Control Fail
On a powered exercise platform, the user is not a passive load. The user adds energy to the mechanism. If the closed-loop motor speed control does not expect that energy, it will fight them.
Why a powered exercise platform is not a normal motion control problem
The machine we worked on for this project was a mid-stage prototype of a total-body cardio trainer. It used foot platforms and arm bars that were driven by a motor, so the machine moved the user rather than the user moving the machine. The electronics within measured speed and rep count from reflective optical sensors. The machine could also stop the platforms in a known position, read pressure-sensitive switch mats under both feet, drive an analog DC motor drive, and put speed control on a handlebar rocker with a touch display for the workout.
None of that is unusual as embedded systems design work. The difference was the person standing on the platforms. They were adding power to the system, not just inertia. On a conveyor or a pump you size the drive for the worst case scenario, and the load never argues back. Here the load can decide to help, and it does so unpredictably, in bursts, at exactly the moments the loop is trying to settle.
The stage of the work matters here, because it changes what counts as a correct answer. Everything below is prototype-stage engineering on a machine that only ever ran under the supervision of the people who built it. Some of it is the right answer generally, and some of it is the right answer only for that context.
We had to measure the speed command curve, not calculate it.
The drive accepted an analog speed reference derived from a filtered PWM output. Duty cycle in, shaft speed out. The relationship was not a straight line. Gear reduction, belt and bearing losses, the spring return elements and the geometry of the linkage itself meant the same duty step produced very different speed changes at the bottom and the top of the range.
We tested three fits against the measured points: linear, second-order polynomial, and exponential. The exponential fit was the one that stayed. That curve is not a model of the machine. It is a lookup that put the command in the right neighborhood so the feedback loop had less work to do. During revisions between builds, engineers updated the prototype’s mechanism, making a real plant model obsolete before it finished. Characterizing the thing you actually have is often faster, as long as you remember you have a fit and not physics.
What happens when the user out-runs the set-point
Set the target to 40 RPM. A strong user leans into it and the platforms come around at 46. A textbook loop sees positive error and reduces drive output to bring speed back down.
Two things go wrong. The machine goes slack under the user’s feet, which feels dead and, on a platform that is swinging your legs, unsettling. And if the output falls far enough, the drive stops contributing at all, so the moment the user eases off the platform decelerates hard with nothing underneath it.
The fix was to give the loop limited authority in the downward direction. The control system keeps the commanded output above 80 percent of the curve’s target speed. It also enforces a floor at the start-speed command. Together those mean the loop can trim against an over-driving user, but it cannot back all the way out from under one.
The cost of that is real and worth stating. The machine tolerates running above its set-point instead of forcing it back down, so the number on the display is a target rather than a guarantee. On a machine whose job is to move a person smoothly, that was the right trade. On a machine that had to hold speed to a specification, it would not have been, and the answer would have had to come from somewhere other than the speed loop.
Why closed-loop motor speed control had to be slow here
Speed came from a single reflective marker per revolution, measured as a period between edges. Across a 15 to 55 RPM operating range that is somewhere between roughly one and four updates per second. Debounce and the input scan interval push that lower still.
That bandwidth sets everything else. There was no room for high loop gain, because a correction that assumes fresh error data will oscillate when the data is a third of a second old. We applied a small fixed-size step only when a new revolution had actually been timed, and we scaled the step by measured speed so its effect stayed proportional across the range. Deliberately sluggish, which was correct here.
If this had gone forward, the first change would have been more markers per revolution. More edges per rev is the cheapest control bandwidth available on a rotating machine, and it costs a strip of tape.
Only a person on the machine could judge ramp behavior.
Acceleration and deceleration were requirement line items, but “correct” acceleration is not a number you can derive from the mechanics. The rocker moved the target one step every 200 milliseconds while held. On the bench that looked fine. On the machine, with a person waiting for it to come up to speed, it felt slow, so the ramp was increased and re-evaluated with someone actually on it. That change, install, ride, adjust loop is how you converge on it, and it argues for keeping tuning constants somewhere you can reach without a rebuild.
Platform homing has the same character. The platforms have to come to rest where a user can step on, which was done by creeping the motor at a fraction of a percent duty until the optical sensor picked up. The first version was a blocking loop with a sleep in it. That works until you notice the control application is not reading its inputs while the machine is moving. The design uses a state machine in the background loop; nothing moving the machine blocks the code that watches it.
What a prototype control loop is allowed to skip
The loop ran as an application process on a general-purpose operating system on a small single-board computer. That was a deliberate choice. The same board drove the touch display and the workout interface, it was cheap and available, and it left an obvious path to connectivity later.
What it also means is that a great deal of behavior depended on that one process continuing to run. A GPIO library background thread produced PWM, so last commanded value continues to be transmitted regardless of app above. There was no watchdog. The optical sensor’s pulses were not verified while the motor ran, allowing a blocked sensor to freeze the speed.
For a supervised prototype that is a defensible place to be, and it is close to what a mid-stage prototype is for. For a machine a member of the public stands on, it is not. The production version needs a limit path that does not share a processor with the user interface: sensor presence, over-speed and mat state enforced in hardware or in firmware on a small dedicated controller, with the application computer allowed to request a speed and nothing more.
The broader point is about authority. When the load can put energy into the system, symmetric control is the wrong default. Decide separately what the loop is allowed to do in each direction, and decide separately which of those decisions is allowed to depend on software that might stop running.
If you are building a machine where a person is part of the mechanism, the speed loop needs to account for that long before the enclosure does. Take a look at Getting Started and we can talk through the control strategy and the safety split on your system.
FAQ
In closed-loop motor speed control, how does a load that can add power change its behavior?
A conventional speed loop assumes the motor is the only energy source, so any over-speed means reduce output. When a person or another active element can drive the load faster than commanded, that response is wrong: cutting output makes the machine go slack and can leave nothing supporting the load when the external effort stops. The loop needs asymmetric limits so it can trim in the down direction without fully withdrawing.
How do you keep a motor from stalling when a user over-drives an exercise machine?
Put a floor under the commanded output rather than letting the error term take it to zero. On this platform there were two: the command could not fall below roughly 80 percent of what the target speed required, and there was an absolute floor at the machine’s start-speed command. The result is that a strong user can push the machine above set-point, but cannot cause the drive to give up entirely.
What limits control loop bandwidth when RPM is measured once per revolution?
The update rate is the speed itself. At 15 to 55 RPM, one marker per revolution gives roughly one to four samples per second before debounce and scan interval reduce it further. That rules out high gain, forces small correction steps, and means the loop cannot respond to anything faster than about a revolution. Adding markers per revolution is usually the cheapest fix.
Can a Linux single-board computer run the motor control loop on a powered machine?
For a prototype, yes, and it buys you a display, a UI and a path to connectivity on one board. The problem is that a general-purpose operating system gives no guarantee your control process keeps running, and PWM generated by a library thread will keep outputting the last value if it does not. Prototypes can accept that. Production machines that move people need the limit and stop functions on a separate, dedicated path.
Do you need closed-loop motor speed control, or is an open-loop curve enough?
If the load is predictable, a measured command-to-speed curve alone can be adequate, and it is worth building that curve either way as a feed-forward starting point. Closed loop earns its place when something outside the drive changes the load, as a user does. Here the curve set the operating point and a slow correction handled the disturbance, which is a common and reasonable split.
