PID-Controlled DC Motor Speed Project

This project develops a closed-loop speed controller for a brushed DC motor using encoder feedback and a discrete PID controller. It is designed as a practical control engineering exercise: the goal is not merely to make the motor spin, but to define requirements, build a model, implement a feedback loop, tune it, test it, and document whether the system satisfies measurable performance criteria.

The project can be implemented with many hardware platforms. The engineering structure is the same whether the controller runs on a microcontroller, a real-time development board, or a laboratory data-acquisition system. The essential components are:

• a brushed DC motor;
• a motor driver or H-bridge;
• a speed sensor, usually an encoder;
• a controller that samples speed and updates motor voltage or PWM duty cycle;
• a power supply sized for the motor;
• a safe mechanical load or inertial disk;
• logging tools for setpoint, measured speed, duty cycle, and error.

The project should be treated as an engineering design task, not a wiring demonstration. Every control decision should be traceable to a requirement, measurement, model, or test result.

Project objective

Design and validate a motor speed loop that makes the motor shaft follow commanded speed changes while rejecting moderate load disturbances.

Example requirements:

• commanded speed range: 200 rpm to 2000 rpm;
• steady-state speed error: less than 2 percent after settling;
• overshoot for a step command: less than 10 percent;
• settling time for a moderate step: less than 1.5 seconds;
• no sustained oscillation over the operating range;
• safe current, voltage, and temperature limits;
• graceful behaviour when the actuator saturates.

These numbers are examples. The exact values should be adapted to the selected motor, driver, power supply, and load. What matters is that the project begins with measurable requirements.

System architecture

The control loop has the following structure:

1. The user or test script sets a reference speed \omega_r[k].
2. The encoder measures shaft motion.
3. The software estimates measured speed \omega[k].
4. The controller computes speed error:

5. The discrete PID controller computes a command.
6. The command is limited to the allowable duty-cycle range.
7. The motor driver applies voltage through PWM.
8. The motor and load respond.
9. The loop repeats at the next sample.

The controlled variable is motor speed. The manipulated variable is usually PWM duty cycle, which approximates average motor voltage if the motor driver and supply remain within their operating limits.

Plant model

A simple brushed DC motor model connects electrical and mechanical dynamics. One common form is:

where:

• V(t) is applied armature voltage;
• i(t) is armature current;
• L is armature inductance;
• R is armature resistance;
• K_e is back-emf constant;
• \omega(t) is angular speed;
• J is rotor and load inertia;
• b is viscous friction coefficient;
• K_t is torque constant;
• \tau_L(t) is load torque.

If armature inductance is small compared with mechanical dynamics, a reduced first-order speed model is often sufficient:

This approximation is useful for initial tuning, but it should not be mistaken for the real motor. Coulomb friction, dead zone, driver voltage drop, current limiting, quantisation, gearbox compliance, and saturation can all matter.

Identifying a first-order model

A practical way to estimate the model is to apply a small safe voltage step or PWM step and record speed. Use a test that stays within safe current and speed limits.

For a first-order approximation:

where \omega_{\infty} is final speed and \tau is the time constant. The time constant is approximately the time required to reach 63.2 percent of final speed after a step.

The static gain is:

or, if the input is duty cycle d rather than voltage:

Here K_u is the static gain from command input to speed. It is intentionally separate from the PID derivative gain K_d used later.

This model should be identified at more than one operating point. A motor may not have the same gain near low speed, high speed, no load, and loaded operation.

Encoder speed measurement

An encoder produces pulses related to shaft rotation. A quadrature encoder can also provide direction. The speed estimate can be computed in two common ways:

1. count pulses over a fixed sampling interval;
2. measure time between pulses.

Pulse counting is simple but has poor resolution at low speed if the sample interval is short. Period measurement can be better at low speed but becomes sensitive to jitter and noise. Many implementations combine both methods or filter the speed estimate.

If the encoder has N counts per revolution and the controller samples every T_s seconds, then a pulse-count speed estimate is:

where \Delta n[k] is the count change during the sample.

A speed estimate should be filtered carefully. Too little filtering makes the controller react to quantisation and pulse jitter. Too much filtering adds delay and phase lag, which can reduce stability margin.

Choosing the sample time

The sample time T_s must be fast enough to capture the motor dynamics but not so fast that measurement quantisation dominates. As a starting point, choose a sampling frequency at least 10 to 20 times faster than the desired closed-loop bandwidth.

For a small DC motor project, sample times such as 1 ms, 2 ms, 5 ms, or 10 ms may be plausible, depending on hardware and encoder resolution. The correct value depends on:

• motor time constant;
• encoder counts per revolution;
• expected speed range;
• processor timing;
• PWM frequency;
• data logging capacity;
• noise and filtering.

The sample time should be measured, not assumed. Scheduler jitter can become a control problem if timing varies significantly.

Controller structure

A discrete PID controller can be implemented as:

with integral update:

and a derivative term based on measured speed rather than error:

Using derivative on measurement avoids a derivative kick when the speed reference changes suddenly. In practice, the derivative term is often filtered or omitted for speed control if encoder noise is significant.

The final command is limited:

For a unidirectional speed loop, u_{min} may be zero. For bidirectional control, negative duty or direction commands may be allowed, depending on the driver.

Anti-windup

Integral action can remove steady-state speed error, but it can also create windup. Windup occurs when the actuator saturates but the integral term continues to accumulate error. When the system finally leaves saturation, the stored integral can cause overshoot and slow recovery.

Simple anti-windup options include:

• stop integrating when the actuator is saturated and the error would drive it further into saturation;
• clamp the integral term to a safe range;
• use back-calculation to drive the integral state toward the saturated command.

A conditional integration rule is easy to implement:

1. compute the unsaturated command;
2. saturate the command;
3. integrate only if the command is not saturated or if the error tends to reduce saturation.

Anti-windup should be tested explicitly by commanding a speed that temporarily exceeds actuator capability.

Initial tuning method

A conservative tuning workflow:

1. Set K_i = 0 and K_d = 0.
2. Increase K_p until the motor responds quickly but does not oscillate.
3. Add a small K_i to remove steady-state error.
4. Increase K_i carefully until offset is corrected within the desired time.
5. Add derivative or lead-like filtering only if damping is inadequate and the measurement is clean enough.
6. Retest at low speed, mid speed, high speed, no load, and loaded conditions.

Do not tune only at one operating point. A controller that works well at 1500 rpm may chatter near 200 rpm because encoder quantisation is worse, or may saturate near 2000 rpm because the available voltage is insufficient.

Disturbance testing

A useful speed controller must reject load changes. Disturbance tests may include:

• adding a small friction load;
• coupling a fan or inertial disk;
• applying a controlled brake torque;
• changing supply voltage within safe limits;
• stepping the reference while the motor carries load.

For each test, log:

• reference speed;
• measured speed;
• error;
• command or duty cycle;
• saturation status;
• current, if measured;
• time stamps.

The response should be evaluated with the same metrics used in the requirements: steady-state error, overshoot, settling time, actuator saturation, and oscillation.

Safety and hardware limits

Motor control projects can damage hardware if treated casually. The controller can command high current before the motor reaches speed. A stalled motor can draw much more current than expected. An H-bridge can overheat. A mechanical load can loosen or become unsafe at high speed.

Minimum safety practices:

• use a current-limited power supply when possible;
• verify motor driver current and thermal ratings;
• start with low voltage and low duty-cycle limits;
• secure the motor and load mechanically;
• include an emergency stop or power cutoff;
• limit maximum speed in software;
• test direction logic before attaching a load;
• log saturation and current warnings;
• never rely only on the PID loop for safety.

The control loop should fail safe. If encoder measurements stop, become impossible, or indicate unrealistic speed jumps, the controller should reduce command or shut down rather than continue integrating error.

Commissioning Log and Repeatable Test Script

The project should keep a commissioning log as the loop is brought online. Useful entries include wiring checks, encoder direction, PWM frequency, sample-time measurement, current limit, duty-cycle limit, emergency stop check, open-loop response, first closed-loop gains, saturation events, temperature observations, and any code or hardware changes.

Repeatable tests make tuning evidence credible. A simple test script should apply the same speed steps, load disturbances, startup condition, and logging interval each time so gain changes can be compared. Without repeatability, an apparent improvement may come from a different load, warmer motor, supply sag, or noisier speed estimate.

The log should preserve the controller gains, filter constants, anti-windup method, sample time, firmware version, and hardware setup used for each plotted result.

Validation checklist

The project is complete only after validation, not after the motor spins. A good final report should include:

• hardware diagram;
• signal list;
• motor and driver specifications;
• encoder resolution;
• sample time measurement;
• plant identification data;
• selected model and its limitations;
• PID gains and units;
• anti-windup method;
• filtering method;
• step response plots;
• disturbance response plots;
• saturation tests;
• safety limits;
• final assessment against requirements.

The most important engineering question is:

Does the controller meet the stated requirements over the intended operating range without relying on unsafe or fragile behaviour?

If the answer is no, the project should explain why. Perhaps the actuator is undersized, the encoder resolution is too low, the sample time is inappropriate, the plant is too nonlinear for one set of gains, or the requirements are unrealistic. A well-diagnosed limitation is a valid engineering outcome.

Extensions

After the basic PID loop works, useful extensions include:

• feedforward voltage compensation based on desired speed;
• current measurement and current limiting;
• cascade control with inner current loop and outer speed loop;
• gain scheduling for different speed ranges;
• state-space modelling;
• observer-based speed estimation;
• disturbance observer design;
• comparison between continuous-time design and discrete implementation;
• automated test scripts for repeatable validation.

These extensions should be added only after the baseline loop is stable, measurable, and documented. Complexity is useful when it solves a known limitation, not when it hides a poorly understood system.

Deliverable

The final deliverable should include a short design report, source code or controller pseudocode, data plots, and a clear pass/fail table against the original requirements. The report should identify what was measured directly, what was estimated, what was assumed, and what remains uncertain.

This project teaches a core lesson of control engineering: feedback is not a magic correction layer. It is an engineered loop that depends on modelling, measurement, timing, actuation, safety limits, and validation.

Sources and further reading

• MathWorks: PID Tuner
• Arduino Documentation: Secrets of Arduino PWM