Control Systems Made Easy

Getting Started

1. Unsure How to Get Started? Try our Book Workshop!
2. How to Write on Leanpub
3. Previewing and publishing
4. Basic formatting
5. Markdown and Markua
6. Generate a preview version of your book
7. Either read a tutorial, or just go for it!
8. Thanks for being a Leanpub author!

Writing in Markua

1. Section One
2. Including a Chapter in the Sample Book
3. Links
4. Images
5. Lists
6. Page Breaks
7. Code Samples
8. Tables
9. Math
10. Headings
11. Block quotes, Asides and Blurbs
12. Good luck, have fun!

Copyright and Disclaimer

Preface

How to Use This Book

Contents

Chapter 1 —- Why Control Systems Exist Everywhere

1. 1.1 The fundamental idea: error correction
2. 1.2 Open-loop versus closed-loop
3. 1.3 Anatomy of a control loop
4. 1.4 Real-world examples in each domain
5. 1.5 Negative feedback and why it stabilises
6. 1.6 Why systems become unstable: a preview
7. 1.7 Your first simulation: the proportional feedback loop
8. Always simulate before connecting hardware. A ten-minute simulation that shows an instability saves hours of debugging on physical hardware —- and protects expensive actuators, sensors, and mechanical components from the damage that an unstable loop can cause. Even a crude first-order Euler simulation reveals the dominant behaviour of most control loops. Get the simulation right first, tune conservatively in simulation, then transfer to hardware expecting to retune. The simulation and the hardware will never agree perfectly; the question is how far apart they are and why.
9. Assuming that a stable simulation guarantees a stable hardware implementation. It never does. Simulations omit sensor noise, quantisation, actuator nonlinearities, computational delays, unmodelled mechanical resonances, and the hundred small approximations that separate a model from reality. A system with 45 degrees of phase margin in simulation may have only 15 degrees on hardware after accounting for a 2 ms ADC conversion delay and a 50 Hz resonance in the motor mount. Always measure the actual loop behaviour on hardware before trusting the design is robust.
10. Chapter Recap
11. Exercises
12. Chapter Checklist
13. Reflections

Chapter 2 —- Mathematical Foundations You Actually Need

1. 2.1 Differential equations and system memory
2. 2.2 Second-order systems: the two parameters that govern everything
3. 2.3 Time constants and the rule of five
4. 2.4 Complex numbers and why they appear in control
5. 2.5 Euler’s formula and sinusoidal response
6. 2.6 Step-test system identification
7. When performing a step test for system identification on real hardware, use a step amplitude of 5—15% of the operating range. Large steps may drive the system into nonlinear regimes where the first-order model does not apply. Too small a step drowns in sensor noise. Before fitting, subtract any pre-test offset (the output may not be exactly zero before the step). Verify that the output has fully settled before the test ends —- truncating before 5 tau will underestimate both the gain and the time constant. Repeat the step test three to five times in both directions and average the identified parameters to reduce noise influence.
8. Confusing omega_n (natural frequency in rad/s) with f_n (natural frequency in Hz). They are related by omega_n = 2 * pi * f_n. A system with f_n = 10 Hz has omega_n = 62.8 rad/s. A phase margin calculation using the wrong units can be off by a factor of 2*pi —- which will completely invalidate your stability analysis. Establish which unit system you are using at the start of every design and check every number that crosses a unit boundary. The control library in Python uses rad/s throughout. Most oscilloscopes and spectrum analysers display Hz. Be explicit every time.
9. Chapter Recap
10. Exercises
11. Chapter Checklist
12. Reflections

Chapter 3 —- Laplace Transforms Without the Pain

1. 3.1 What the transform does and why it works
2. 3.2 Transfer functions: the engineer’s system description
3. 3.3 Poles, zeros, and physical meaning
4. 3.4 Block diagram algebra
5. 3.5 The RC circuit: building intuition from first principles
6. 3.6 DC motor transfer function derivation
7. When building a transfer function model from datasheet parameters, verify it against a measured step response before designing the controller. Datasheet values —- particularly inductance and viscous friction —- have wide tolerances, and the measured behaviour of a real motor often differs from nominal by 20-30%. A 30-minute step-test identification session using ch02_step_identification.py gives you a far more reliable basis for controller design than a textbook derivation from nominal datasheet values. Do both: derive the model to understand the physics, identify the model to get reliable numbers.
8. Forgetting that transfer functions assume zero initial conditions. The expression G(s) = Y(s)/U(s) is valid only when all initial conditions (initial position, velocity, voltage, temperature, etc.) are zero. If the system starts from a non-zero state —- the motor is already spinning, the temperature is 30°C above ambient —- the response to a new input has an additional transient superimposed on the step response. Transfer functions model the input-output behaviour from zero state. If initial conditions matter, use the state-space representation (Chapter 9) or explicitly include the initial condition terms in the Laplace transform.
9. Chapter Recap
10. Exercises
11. Chapter Checklist
12. Reflections

Chapter 4 —- Transfer Functions and System Modeling

1. 4.1 The modeling philosophy
2. 4.2 Electrical systems
3. 4.3 Mechanical systems: mass, spring, damper
4. 4.4 Thermal systems and long time constants
5. 4.5 Linearization: making nonlinear systems workable
6. After building a transfer function model from first principles, validate it with at least three different test inputs before using it for controller design: a small step (5% of range), a large step (50% of range), and a slow ramp. If the responses are consistent with the model, you can proceed with reasonable confidence. If the large step response looks qualitatively different from the small step response —- faster, slower, oscillatory where the small step was not —- the system has significant nonlinearity in that range and the linear model needs to be restricted to a smaller operating region, or a nonlinear model is required.
7. Building a model that includes too many uncertain parameters. A model with 12 poles, 6 zeros, and 15 adjustable parameters requires at least 15 independent measurements to identify —- and in practice several times more for statistical reliability. If you have a 10-second step test and three repeats, you have enough information to identify a first- or second-order model reliably. Adding more complexity than your data can support produces a model that fits the identification data perfectly and predicts nothing correctly. The classic symptom: the identified model looks excellent on the training data but fails completely on a new test case. Always validate on data that was not used for identification.
8. Chapter Recap
9. Exercises
10. Chapter Checklist
11. Reflections

Chapter 5 —- Stability: Why Systems Oscillate and Explode

1. 5.1 What stability means
2. 5.2 Routh-Hurwitz stability criterion
3. 5.3 Root locus: tracking poles as gain changes
4. 5.4 Gain and phase margin: practical stability measurement
5. 5.5 Saturation and conditional stability
6. When a system first shows instability on hardware, measure the oscillation frequency immediately and log the measurement. The instability frequency is approximately the phase crossover frequency omega_pc —- the frequency at which the loop phase has accumulated −180 degrees. Knowing omega_pc tells you the frequency at which you need to add phase or reduce gain to restore stability. If the oscillation frequency matches a structural resonance you know about but did not include in the model, you have identified the source immediately. If it does not match anything in your model, you have discovered an unmodelled dynamics that needs to be characterised and either attenuated by a notch filter or avoided by reducing the control bandwidth below that frequency.
7. Designing stability margins at the nominal operating point only. A motor servo with a 10 kg load may have generous stability margins, but with a 1 kg load attached instead, the mechanical time constant changes and the gain-bandwidth product of the plant shifts. Always analyse stability across the full range of expected plant parameter variation: minimum and maximum load inertia, minimum and maximum damping (hot vs cold bearings), minimum and maximum supply voltage affecting motor gain. The worst case —- the combination of parameters that gives the smallest stability margins —- is what the controller must survive.
8. Chapter Recap
9. Exercises
10. Chapter Checklist
11. Reflections

Chapter 6 —- PID Control: The Workhorse of Industry

1. 6.1 Proportional control: the foundation
2. 6.2 Integral control: eliminating steady-state error
3. 6.3 Derivative control: predicting the future
4. 6.4 The complete PID controller
5. 6.5 Tuning methods: from first principles to practice
6. 6.6 Cascade PID and feedforward
7. 6.7 Embedded C++ implementation
8. 6.8 Setpoint weighting and ISA standard form
9. When commissioning a PID on real hardware for the first time, always start with Ki = 0, Kd = 0, and Kp set to 10% of your calculated starting value. Verify that the loop direction is correct (positive error produces positive control action) by watching the output change in response to a small manual setpoint step. Verify that the sensor signal direction is correct (output increasing produces measured value increasing, not decreasing). Only after confirming these two things should you begin increasing gain. A reversed loop direction or sensor polarity will make any finite gain value cause instability.
10. Running the control task at an inconsistent rate. If the PID runs sometimes at 1 ms and sometimes at 3 ms due to RTOS scheduling jitter, the integral accumulates at a non-constant rate (the Ki*e*dt term accumulates correctly only if dt is the actual elapsed time), and the derivative uses the wrong denominator. Both errors produce noise and reduced performance. Always either run PID from a timer interrupt with guaranteed periodicity, or measure the actual elapsed time since the last call and use that measured dt in the algorithm. For latency-sensitive servo applications, use a dedicated timer interrupt, not an RTOS task —- RTOS scheduling overhead is non-deterministic.
11. Chapter Recap
12. Exercises
13. Chapter Checklist
14. Reflections

Chapter 7 —- Frequency-Domain Thinking

1. 7.1 Frequency response: what it measures
2. 7.2 Bode plot construction and the slope rules
3. 7.3 Bandwidth, disturbance rejection, and noise
4. 7.4 Notch filters for resonance rejection
5. 7.5 The effect of sampling delay on phase margin
6. Before closing any high-bandwidth loop on new hardware, measure the open-loop Bode plot experimentally. Apply a swept-frequency sinusoidal input (chirp) to the plant and measure the output. The frequency response function (output FFT / input FFT at each frequency) gives the measured plant Bode plot directly. Compare it to the model. Resonances that are in the measured plot but not in the model are the ones that will cause problems —- address them before closing the loop. Even a simple swept-sine test from 1 Hz to 1000 Hz over 30 seconds provides enough information to identify resonances, verify the model gain and phase, and spot any gross modelling errors.
7. Setting controller bandwidth close to the sample rate. The Nyquist theorem requires the sample rate to be at least twice the signal bandwidth, but for control systems the practical limit is much lower. At f_crossover = f_sample / 4, the phase lag from the zero-order hold alone is T/2 * (f_sample/4 * 2*pi) = pi/4 = 45 degrees —- consuming an entire typical phase margin budget from ZOH alone, before adding computation delay or plant phase. In practice, design for f_crossover < f_sample / 10, and f_crossover < f_sample / 20 when computation time is significant. Trying to run a 100 Hz bandwidth control loop at 200 Hz sample rate will fail on hardware regardless of what the continuous-time simulation shows.
8. Chapter Recap
9. Exercises
10. Chapter Checklist
11. Reflections

Chapter 8 —- Nyquist, Root Locus, and Robustness

1. 8.1 The Nyquist plot
2. 8.2 Root locus design
3. 8.3 Lead and lag compensators
4. 8.4 Robustness and the sensitivity peak
5. 8.5 Monte Carlo robustness analysis
6. Always run Monte Carlo robustness analysis before signing off on a production controller. Identify the five to ten most uncertain parameters, assign realistic uncertainty ranges, and run 500-1000 simulations. Report the minimum margin from the distribution, not the nominal margin. If any simulation produces a gain margin below 6 dB or phase margin below 30 degrees, redesign with more conservative gains until the minimum margins hold across the entire parameter space.
7. Designing for nominal performance and ignoring the extremes of the operating envelope. A motor servo designed for a 5 kg payload may oscillate violently with a 1 kg payload (lower inertia, higher effective gain, reduced damping) or fail to meet specifications with a 10 kg payload. The worst case for stability is typically maximum plant gain combined with minimum damping. Always verify margins at both extremes.
8. Chapter Recap
9. Exercises
10. Chapter Checklist
11. Reflections

Chapter 9 —- State Space Control Made Practical

1. 9.1 The state-space model
2. 9.2 Controllability and observability
3. 9.3 State feedback and pole placement
4. 9.4 LQR: optimal state feedback
5. When tuning LQR weights, use a dimensionless formulation: set Q = C^T*diag(1/y_max_i^2)*C where y_max_i is the maximum acceptable deviation in each output, and R = diag(1/u_max_j^2) where u_max_j is the maximum actuator effort acceptable in normal operation. This makes all weights dimensionless and equal to 1 at the limit value —- an intuitive starting point that scales correctly regardless of physical units.
6. Designing an LQR without verifying controllability first. If the system is not controllable, the Riccati solver may return a gain matrix that does not stabilise all modes. Always compute np.linalg.matrix_rank(Wc) before calling solve_continuous_are, and always verify np.linalg.eigvals(A - B@K) after computing K —- confirm all real parts are negative before proceeding.
7. Chapter Recap
8. Exercises
9. Chapter Checklist
10. Reflections

Chapter 10 —- Observers and State Estimation

1. 10.1 The Luenberger observer
2. 10.2 Kalman filter: the optimal observer
3. 10.3 LQG: the complete optimal controller
4. When tuning the Kalman filter, start by measuring actual sensor noise: log data from a stationary system for 60 seconds at full sample rate and compute the variance of each sensor. Use this measured variance as the R_kf diagonal entry. For Q_kf, start with values 10x smaller than R_kf. Increase individual Q_kf entries if the filter lags rapid state changes; decrease them if the estimate is too noisy.
5. Using continuous-time Kalman gain L in a discrete-time implementation without recomputing for the discrete system. For control rates above a few hundred Hz the difference is small, but for slower rates or plants with fast eigenvalues relative to sample period, the difference can cause divergence. Always use control.c2d() to discretise the plant first, then design the discrete Kalman filter with the discrete A_d and C matrices.
6. Chapter Recap
7. Exercises
8. Chapter Checklist
9. Reflections

Chapter 11 —- Digital Control Systems

1. 11.1 Sampling, Nyquist, and anti-aliasing
2. 11.2 Digital phase lag: the key formula
3. 11.3 Discretisation: Tustin is best
4. 11.4 Velocity-form discrete PID
5. Always measure and log the actual sample period in your embedded controller, not just the intended period. RTOS schedulers produce 1-5% jitter even at high priority. For a 1 ms loop, that is 10-50 us of jitter. Use the measured elapsed time as dt in the integral: integral += Ki * error * actual_dt. This single change can significantly improve performance on RTOS-based systems at the cost of one additional hardware timer read per cycle.
6. Computing the discrete derivative as (e[k]-e[k-1])/T using the nominal T rather than measured elapsed time. On systems with 5% jitter, the error is modest. But a 20% timing anomaly (task running late due to interrupt or cache miss) creates a 20% derivative error that produces visible spikes in the output. Use actual_dt from a hardware timer in all rate calculations.
7. Chapter Recap
8. Exercises
9. Chapter Checklist
10. Reflections

Chapter 12 —- Nonlinear Control and Real Systems

1. 12.1 Saturation and anti-windup (revisited with simulation)
2. 12.2 Friction and limit cycling
3. 12.3 Gain scheduling
4. 12.4 Quadrotor control architecture
5. When implementing gain scheduling, test at the interpolation boundaries —- the operating points between lookup table entries —- not just at the breakpoints. Instabilities sometimes appear between breakpoints where interpolated gains produce less stable combinations than either endpoint alone. Sweep the scheduling variable from minimum to maximum in closed-loop simulation and verify the response remains stable and within specification throughout.
6. Implementing gain scheduling as abrupt switching rather than smooth interpolation. If gains jump discontinuously at a threshold, the proportional term jumps immediately. For a 1-unit error when Kp changes from 5 to 3, the control output drops from 5 to 3 —- a 2-unit step that excites transients. Always interpolate gains smoothly. Linear interpolation between adjacent breakpoints executes in nanoseconds on any modern processor and completely eliminates this problem.
7. Chapter Recap
8. Exercises
9. Chapter Checklist
10. Reflections

Chapter 13 —- Control Systems in Robotics, Drones, and Autonomous Systems

1. 13.1 Robot arm: three-level cascade
2. 13.2 Self-balancing robot: LQR for unstable systems
3. 13.3 ROS 2 Control stack
4. 13.4 Pure pursuit lateral control
5. Before writing any code for a new robot platform, sketch the full loop diagram. List every controlled variable, every sensor, every actuator, and the sampling rate of each loop. Draw data flow arrows. Identify where state estimation is needed. Verify that each inner loop is at least five times faster than the loop above it. This 30-minute exercise catches architectural problems that take weeks to debug in code.
6. Tuning robot control gains in rigid-body simulation and expecting them to work directly on hardware. Real robots have joint flexibility, transmission backlash, encoder quantisation, and motor driver latency —- none of which appear in rigid-body simulation. Budget explicit time for hardware tuning, starting at 30-50% of simulation gains and increasing conservatively. Verify each joint in isolation before enabling multiple joints simultaneously.
7. Chapter Recap
8. Exercises
9. Chapter Checklist
10. Reflections

Chapter 14 —- Building Production-Ready Control Systems

1. 14.1 Sensor noise characterisation
2. 14.2 Safety system architecture
3. 14.3 Hardware-in-the-loop testing
4. 14.4 Eight-phase deployment workflow
5. 14.5 Logging and diagnostics
6. 14.6 Deployment checklist
7. Chapter Recap
8. Exercises
9. Chapter Checklist
10. Reflections

Appendix A —- Control Systems Formula Reference

Appendix B —- Laplace Transform Table

Appendix C —- Python Control Toolbox Setup

Appendix D —- ROS 2 Control Stack Overview

Appendix E —- Glossary of Key Terms