Control Systems interview questions

10 questions, easiest first

1. 1A cooling fan can be run two ways: (1) open-loop, where you just set a fixed PWM duty cycle and hope the RPM lands where you want, or (2) closed-loop, where a tachometer measures actual RPM and the controller adjusts duty cycle to hold a target RPM. As the battery voltage droops from 8.4V to 6.0V over a discharge cycle, explain what happens to the fan speed in each case and why the closed-loop version behaves differently.intro

   Answer this one, graded

   Or just show what a strong answer covers

   In open loop, duty cycle is fixed, so as voltage droops the motor gets less power and RPM sags — there's no way for the system to know or correct for this because nothing is being measured. In closed loop, the tachometer reports actual RPM, the controller compares it to the setpoint, and as voltage drops and RPM starts to fall, the growing error causes the controller to increase duty cycle to compensate, holding RPM roughly constant until the duty cycle saturates at 100%, at which point it behaves like the open-loop case. The three ingredients that make this work are a sensor, a setpoint to compare against, and an actuator capable of responding to the resulting error.

   • Open-loop failure mode — States that fixed duty cycle output drops in speed as voltage sags because there is no measurement of actual RPM to correct it.
   • Closed-loop correction mechanism — Explains the controller measures RPM, computes error against setpoint, and raises duty cycle to compensate as voltage drops.
   • Identifies necessary components — Names the sensor, setpoint comparison, and actuator as the pieces required for the loop to reject the disturbance.
   • Notes a limit of closed-loop correction — Mentions the closed loop can only compensate up to some duty-cycle/voltage limit, beyond which it saturates and speed still drops.

   Where answers go wrong: Saying closed loop is simply 'more accurate' without explaining the correction mechanism. · Ignoring that the closed loop can still fail once duty cycle saturates at 100%. · Describing feedback as just 'having a sensor' without mentioning the comparison to a setpoint.

2. 2You're closing a temperature control loop: a heater's drive signal is generated by comparing a thermistor voltage to a setpoint voltage. The moment you power it on, instead of settling near the setpoint, the heater slams to full power and the measured temperature just keeps climbing until you cut the supply. What's the most likely wiring mistake, and why does that specific mistake produce a runaway instead of just a slightly-off setpoint?intro

   Answer this one, graded

   Or just show what a strong answer covers

   This smells like inverted feedback polarity — the comparator is probably wired so that rising temperature increases the drive signal instead of decreasing it, turning negative feedback into positive feedback. In a correctly wired loop, error = setpoint − measured value, and as temperature approaches setpoint the error shrinks and drive shrinks with it. Here, the sign is flipped: as temperature rises, error effectively grows (or its sign no longer opposes the disturbance), so the controller keeps commanding more heat, which raises temperature further, which commands even more heat. That's a monotonic runaway, distinct from an oscillation you'd get from a gain that's just too high. To confirm without risking the board again, I'd power it briefly through a current-limited supply and probe the drive/error signal while manually nudging the sensor voltage or gently warming the thermistor by hand — the drive should decrease as measured temperature increases; if it increases instead, that confirms inverted feedback, and I'd swap the comparator inputs or invert the sensor conditioning.

   • Identifies swapped/inverted feedback polarity — States that the comparator's inputs (setpoint vs. sensor) are likely swapped or the sensor is wired with inverted polarity, turning negative feedback into positive feedback.
   • Explains why this causes runaway, not just offset — Explains that with positive feedback, as temperature rises the error signal increases the drive further instead of decreasing it, so any small deviation amplifies rather than corrects — this is qualitatively different from a miscalibrated but stable loop.
   • Proposes a safe verification method — Suggests a way to confirm the diagnosis without repeating the runaway, e.g. probing the error/drive signal sign with a current limit or low power supply, or briefly touching the thermistor to see if drive decreases as expected.

   Where answers go wrong: Blaming sensor noise or a bad thermistor reading instead of loop polarity. · Assuming the gain is simply too high, when a stable-but-oscillating system behaves very differently from a monotonic runaway. · Not distinguishing between 'wrong setpoint value' and 'wrong sign of feedback' as failure modes.

3. 3You're tuning a proportional-only (P-only) controller for a heater trying to hold 60C. No matter how much you raise the gain short of causing oscillation, the system settles a few degrees below 60C and stays there indefinitely. Why does this happen, and what single change to the controller structure would eliminate it?easy

   Answer this one, graded

   Or just show what a strong answer covers

   With P-only control, output is just Kp times error, so at steady state the heater still needs to supply some nonzero power to offset heat loss to ambient — that power can only come from a nonzero error, since zero error means zero proportional output. Raising Kp shrinks that residual error for a given output level but never eliminates it, and pushing gain too high risks oscillation. The fix is adding an integral term: it accumulates the error over time and keeps ramping output up as long as any error remains, so it converges to zero steady-state error without needing gain to go to infinity.

   • Explains the offset mechanism — States that output = Kp * error, so to sustain any heat output against ambient losses, some nonzero error must persist at steady state.
   • Identifies raising gain as an incomplete fix — Notes that raising Kp shrinks but never eliminates the offset, and pushes the system closer to oscillation/instability.
   • Names the correct fix — Explicitly proposes adding an integral term (moving to PI or PID) to drive steady-state error to zero.

   Where answers go wrong: Suggesting to just keep raising gain indefinitely without acknowledging the stability tradeoff. · Confusing this offset with sensor noise or calibration error rather than a structural property of P-only control. · Naming the fix as 'derivative' instead of 'integral'.

4. 4A motor position loop runs its control update at 100 Hz. The encoder-to-controller communication and the motor driver's response together add roughly 15ms of pure delay before a commanded change actually affects position. If you want the closed loop's crossover frequency (roughly where gain margin starts to erode) to stay comfortably below the frequency where this delay eats your phase margin, about how fast, in Hz, would you want the loop's bandwidth to stay under, using the rule that 15ms of delay costs about 90 degrees of phase at f = 1/(4*delay)?easy

   Use the rule of thumb that a pure time delay T contributes roughly 90 degrees of phase lag at f = 1/(4T), and you want to keep crossover safely below that frequency to preserve phase margin.

   Answer this one, graded

   Or just show what a strong answer covers

   Using f = 1/(4T) with T = 0.015s gives about 16.7 Hz as the frequency where the delay alone eats roughly 90 degrees of phase. Since you want comfortable margin, not exactly zero, you'd want closed-loop bandwidth well under that, maybe 3-5 Hz depending on how much margin you need, not right up against 16.7 Hz. The 100 Hz sample rate isn't the binding constraint here since Nyquist is 50 Hz, way above the delay-imposed limit — the communication and driver delay is what's actually limiting how fast you can push this loop.

   • Correct numeric computation — Computes f = 1/(4*0.015s) ≈ 16.7 Hz as the frequency where delay costs ~90 degrees.
   • Interprets result as an upper bound — States that desired crossover/bandwidth should stay meaningfully below ~16.7 Hz, not treat it as an achievable target.
   • Connects to sample rate check — Notes 100 Hz sampling (Nyquist ~50 Hz) is not the limiting factor here — the 15ms delay is the binding constraint, not sample rate.

   Where answers go wrong: Computing based on the 100Hz sample rate/Nyquist limit instead of the delay. · Forgetting to convert 15ms to seconds correctly, giving an answer off by 1000x. · Treating the computed frequency as the target bandwidth rather than an upper bound to stay well under.

5. 5A motor position controller uses a PI loop. You command a large step move across most of the travel range. The motor's PWM output saturates at maximum for a good chunk of the move (it's just going as fast as it can). When it finally reaches the target, it overshoots noticeably and oscillates for a couple seconds before settling, even though the same controller handles small step moves cleanly with no overshoot. What's going on, and what would you change?easy

   Answer this one, graded

   Or just show what a strong answer covers

   This is classic integral windup. During the large step, the error stays large and positive for a while because the motor is saturated at max PWM and simply can't move any faster — but the integral term doesn't know that, so it keeps accumulating error the entire time the actuator is pinned. By the time position crosses the target, the integrator has built up a huge value, so the controller keeps commanding strong drive in the original direction even though error has flipped sign, causing overshoot; it takes a while for the integrator to unwind through the now-negative error, which shows up as the oscillation before settling. Small moves never saturate the actuator, so the integrator never builds up excess and there's no overshoot. The fix is anti-windup: either clamp the integral term to a reasonable range, freeze integration whenever the actuator is at its output limit (conditional integration), or use back-calculation that subtracts the difference between commanded and actual (saturated) output from the integrator. I'd confirm by logging the integral term's value during the move — if it's still climbing well past the point where output is saturated, that confirms windup.

   • Identifies integral windup as the mechanism — Explains that during saturation the integral term keeps growing because error is still present and nonzero, even though the actuator can't produce any more output to act on it.
   • Connects windup to the overshoot specifically — States that once the position crosses the target, the huge accumulated integral value keeps commanding drive in the same direction for a while longer, causing overshoot and oscillation until the integrator unwinds.
   • Proposes a concrete anti-windup fix — Names at least one specific mitigation: clamping/limiting the integral term while saturated, conditional integration (freeze integrator when actuator is at its limit), or back-calculation feeding the saturation error back to reduce the integrator.

   Where answers go wrong: Concluding the P or I gains are simply too high in general, when small moves work fine with the same gains. · Suggesting to just remove the integral term entirely, losing steady-state accuracy instead of fixing windup specifically. · Not mentioning that the actuator saturation is the trigger condition, only describing the overshoot symptom.

6. 6You're staring at a Bode plot for a closed-loop system and someone tells you the gain margin is 3 dB and the phase margin is 8 degrees. Both numbers are technically 'positive,' meaning the loop is nominally stable, but a colleague says this system is basically unsafe to ship. Explain why small, positive margins are still a serious problem, using a concrete physical example of what could push this system into instability.medium

   Answer this one, graded

   Or just show what a strong answer covers

   Gain and phase margin measure exactly how much extra gain or extra phase lag the loop can tolerate before it crosses into instability. A 3dB gain margin means only about a 40% increase in loop gain would cause oscillation, and 8 degrees of phase margin means barely any added delay would do the same — that's an extremely thin safety buffer. In the real world, things like component tolerance on a sensor's gain, a temperature-dependent op-amp gain shift, extra phase lag from an anti-aliasing filter you add later, or added communication latency in the final system can easily consume a few dB or a few degrees. With margins this small, any one of those real, expected sources of variation could push the system into sustained oscillation, so 'technically stable on the bench today' doesn't mean 'stable in the field over temperature and units.'

   • Explains what margin represents — States that gain/phase margin is the amount of extra gain or phase lag the system can absorb before oscillating/going unstable at the 0dB or -180 degree crossing.
   • Explains why thin margin is risky — Argues that a 3dB/8-degree margin leaves almost no room for real-world variation, so something small can push the system unstable.
   • Gives a concrete real-world source of drift — Names a specific physical cause such as component tolerance, temperature-dependent gain change, sensor noise filter adding phase lag, added communication latency, or mechanical wear.

   Where answers go wrong: Saying the system is 'unstable' when technically it is still marginally stable with positive margins. · Not connecting the abstract dB/degree numbers to a physical cause that would consume them. · Confusing gain margin and phase margin roles (one relates to gain variation, the other to added delay/phase lag).

7. 7A motor position control loop was tuned and verified stable on the bench running at a 1kHz control rate. The team later moves the same control code onto a lower-cost microcontroller and, to save CPU budget elsewhere, drops the loop rate to 200 Hz without changing any PID gains. In testing, the motor now oscillates around the setpoint where before it settled cleanly. Explain the mechanism connecting the rate change to the new oscillation, and what you would change to fix it.medium

   Answer this one, graded

   Or just show what a strong answer covers

   Dropping the control rate from 1kHz to 200Hz increases the time between sensing an error and acting on it — roughly, you go from about 1ms of sample-and-hold delay to about 5ms. That extra delay behaves like added phase lag in the loop, and at the same crossover frequency the phase margin that used to be comfortable at 1kHz is now smaller, possibly negative, which is exactly why the system that used to settle cleanly now rings or sustains oscillation. The fix is to re-tune for the new rate: lower the proportional and especially derivative gain, since derivative action is most sensitive to added delay and noise at slower sample rates, and re-check the margin either analytically or by testing until you get clean settling again. If CPU budget allows, reverting to the faster rate for just this loop is the cleaner fix since it avoids giving up performance.

   • Connects rate drop to added delay — Explicitly states that a lower sample rate means longer time between measurement and actuation, which acts as additional loop delay.
   • Connects delay to reduced phase margin — Explains that the same gains which had sufficient phase margin at 1kHz now have less margin at 200Hz because of the added delay, and reduced margin causes oscillation.
   • Proposes a concrete fix — Suggests re-tuning gains (typically lowering Kp/Kd or adjusting derivative filtering) for the new rate, or reverting to a faster loop rate if CPU budget allows.

   Where answers go wrong: Blaming quantization/ADC resolution instead of the sample-rate-to-delay relationship. · Assuming gains should simply be scaled by the ratio of sample rates without justifying why. · Failing to mention that the fix requires re-verifying margins, not just guessing new gains.

8. 8You're tuning the P gain on a position control loop for a mechanical arm. As you raise the gain, steady-state tracking error shrinks nicely, but once gain crosses a certain threshold the arm starts buzzing — a small, persistent oscillation at roughly 40 Hz that wasn't there at lower gain, while gains just below that threshold were rock solid. Why does instability show up at one particular frequency rather than the system just getting generally jittery, and how would you use a frequency response measurement to find the actual cause before you decide how to fix it?medium

   Answer this one, graded

   Or just show what a strong answer covers

   Instability at one specific frequency rather than everywhere tells me the loop's phase lag isn't uniform — every real system has poles (mechanical resonance, sensor filtering, driver electronics) that each add phase lag that grows with frequency, and the loop goes unstable right where total phase reaches -180° while loop gain is still at or above 1. Raising the P gain shifts the crossover frequency higher, and if it lands near wherever the phase has already collapsed — say a lightly damped mechanical resonance in the arm's structure or linkage around 40 Hz — you get exactly this kind of narrow-band buzzing rather than general noise. To confirm rather than guess, I'd measure the actual frequency response: inject a swept sine (or a series of single-frequency sine disturbances) into the loop, ideally open-loop or via a disturbance input, and plot magnitude and phase versus frequency. I'd look for a resonant peak in gain and a rapid phase drop right around 40 Hz — that pinpoints the mechanical resonance (or a filter pole) as the culprit rather than the controller itself, and tells me whether to fix it by adding a notch filter, backing off the crossover frequency, or stiffening the mechanical path instead of just blindly adding derivative gain.

   • Explains why oscillation is frequency-specific — States that the loop's phase lag varies with frequency, and instability occurs at whatever frequency the total loop phase reaches -180° with gain ≥1 (0 dB) — not a general property, but tied to wherever phase margin runs out first.
   • Identifies plausible physical source of the extra phase lag — Names a likely culprit consistent with 40 Hz, such as a lightly damped mechanical resonance (arm/linkage flexing), a sensor or driver low-pass filter, or backlash, that adds phase lag concentrated near that frequency.
   • Describes a frequency response measurement to confirm it — Describes injecting a sine sweep or series of sine disturbances into the loop (e.g., at the setpoint or via a shaker/torque disturbance) and measuring the closed- or open-loop gain and phase at each frequency to see where phase margin gets thin, rather than just guessing from the time-domain oscillation.

   Where answers go wrong: Saying the gain is 'just too high' without addressing why oscillation appears at 40 Hz specifically rather than at all frequencies. · Jumping straight to 'add a derivative term' without first identifying what is actually eating the phase margin near 40 Hz. · Confusing steady-state error (a P-only limitation) with the separate stability question raised here.

9. 9You're designing the control loop for a single-axis gimbal that must track a moving target smoothly. You have two options for the derivative term: compute it from the raw position error each sample, or run the error through a low-pass filter first and differentiate the filtered signal. The raw version reacts fastest to real changes but the gimbal's position sensor has visible quantization noise. Walk through what goes wrong if you use the raw derivative, why filtering fixes it, and what you give up by adding that filter.hard

   Answer this one, graded

   Or just show what a strong answer covers

   Differentiation is fundamentally a high-pass operation — it amplifies whatever changes fastest, and quantization noise from the position sensor changes fast and randomly between samples, so a raw derivative turns that noise into large, jittery spikes in the D term output, which the actuator then tries to follow, causing jerky or oscillatory motion. Low-pass filtering the error, or the derivative estimate itself, before or after differentiation attenuates that high-frequency noise so the D term reflects the real, slower trend in position error rather than sensor artifacts. The cost is that any low-pass filter adds phase lag near its cutoff, and that extra lag shows up in the loop's overall phase response, eating into phase margin and effectively making the D term less responsive than it would be ideally — so you can't just filter aggressively. Choosing the cutoff is a real tradeoff: too high and the noise still gets through and excites the actuator; too low and you lose phase margin or delay the loop's response enough to hurt performance or destabilize it, so you set it as low as needed to control the noise but no lower, usually well above the loop's crossover frequency to limit the phase penalty.

   • Diagnoses the raw-derivative failure — Explains that differentiating raw quantized position produces large noise-driven spikes because derivative amplifies high-frequency content, leading to jerky or excessive actuator commands.
   • Explains the filtering fix mechanism — States that a low-pass filter on the error/derivative signal attenuates the high-frequency quantization noise before differentiation, smoothing the D term output.
   • Identifies the cost of filtering — Explains that the filter adds phase lag to the loop, reducing phase margin and effectively slowing the response the D term is supposed to provide.
   • Frames cutoff selection as a tradeoff — Notes the filter cutoff must be tuned between suppressing noise and preserving margin/response, not treated as a fixed universal value.

   Where answers go wrong: Saying filtering 'just removes noise' without acknowledging the added phase lag cost. · Suggesting to simply drop the derivative term entirely instead of addressing the noise issue. · Not connecting quantization noise specifically to why derivative (not P or I) is the term most affected.

10. 10A digital PID temperature controller runs comfortably within its computed stability margins and its step response looks textbook on paper. In practice, once it reaches steady state, the temperature never quite settles — it ticks up and down by a fraction of a degree in a tight, perfectly repeating pattern that never damps out, forever. Bode analysis says this loop should be stable. What's likely causing a persistent oscillation in a loop that's mathematically stable, and what would you check or change to fix it?hard

    The controller reads an ADC, runs fixed-point PID math, and outputs to a PWM-driven heater.

    Answer this one, graded

    Or just show what a strong answer covers

    Since the linear stability analysis checks out, this looks like a quantization-induced limit cycle rather than true linear instability — Bode margins assume continuous-valued signals, but the real system has an ADC with finite bit resolution, a PWM output with finite duty steps, and fixed-point PID math with rounding. Near setpoint, the actual error can become smaller than one ADC count or one PWM step, so the controller can't apply a fine enough correction; instead it ends up toggling between adjacent quantization levels forever, producing that tight repeating oscillation. I'd confirm this by logging the raw ADC counts and the internal integrator value right at steady state — if the integrator or output is stepping by exactly one least-significant-bit back and forth in a repeating pattern, that's the signature. To fix it, I'd look at whichever resolution is tightest: bump ADC or PWM resolution if that's the bottleneck, do the integrator math in higher precision (wider fixed-point or floating point) so rounding doesn't dominate near-zero error, and/or add a small deadband or dither around setpoint so the controller stops hunting over a difference it can't actually resolve.

    • Identifies quantization/limit-cycle as distinct from linear instability — Explains that Bode/margin analysis is a linear-model result, but quantization (ADC steps, PWM resolution, integer rounding) is a nonlinearity that can produce a small bounded persistent oscillation the linear analysis doesn't predict.
    • Names specific candidate resolution bottlenecks — Points to at least one concrete source: too-coarse ADC bits making the sensor unable to resolve small errors near setpoint, coarse PWM duty steps, or fixed-point rounding in the integrator causing it to hunt back and forth around the same few least-significant-bit values.
    • Proposes a way to confirm and a way to fix it — Suggests a verification step (e.g., logging raw ADC counts and the integrator's internal accumulated value near steady state to see if it's toggling by exactly one LSB) and a mitigation such as higher-resolution ADC/PWM, using higher-precision (wider fixed-point or floating point) math for the integrator, dithering, or adding a small deadband around setpoint.

    Where answers go wrong: Re-deriving phase/gain margin and insisting the loop 'must' be unstable somewhere, ignoring that quantization is a nonlinear effect outside the linear model. · Blaming sensor noise generically without connecting it to a specific resolution or rounding mechanism. · Proposing to just lower the gains, which may mask the symptom without addressing the actual resolution bottleneck.