Complete an engineering design
Turn requirements, experiments, and reproducible evidence into a defensible project. This module has 3 lessons and takes about 2h 25m. Each lesson has a practice exercise that runs real Python in your browser and a short quiz.
Start module 20 in the Learning LabWrite requirements and acceptance tests
Define measurable pass conditions before tuning a controller.
A useful requirement names a stimulus, operating condition, metric, threshold, and measurement method. For example: for a unit step at nominal load, overshoot below 10%, settling within 5 s to a 2% reference band, and command magnitude no greater than 2.
Use separate cases for tracking, load rejection, noise, parameter uncertainty, saturation recovery, and sensor faults. Define what happens if settling is not observed. A missing result must not pass by default.
A requirement can be infeasible. Check steady actuator balance first, then stability and transient performance. Document tradeoffs when speed, noise, robustness, and command limits cannot all be improved together.
See it in action
metrics={'overshoot_pct':8.,'settling_s':4.2,'peak_u':1.8}
passed=(metrics['overshoot_pct']<=10 and metrics['settling_s']<=5 and metrics['peak_u']<=2)
print('Nominal case passed:',passed)
Make success measurable before you search for a controller.
Reproducible experiments and supervised bench work
Prepare a project another learner can rerun and inspect.
Record model equations, parameter units, initial states, controller form, gains, time step, solver, random seeds, and package versions. Save raw results as well as figures. Report unsuccessful experiments when they explain a design choice.
Use simulation first. Optional physical work should use an institution-approved low-voltage trainer under qualified supervision, with known ratings, current limits, guards, emergency stop, and independent protection. The course does not require access to hardware or mains-powered equipment.
Before a supervised bench test, verify sensor scaling and actuator direction at a limited command, check interlocks and the fallback state, then increase scope gradually. Stop on unexpected motion, heat, noise, or invalid measurements. A successful simulation does not validate physical wiring or equipment.
See it in action
import json
record={
'model':'dy/dt=-y+u+d',
'controller':{'form':'parallel PI','kp':2.,'ki':1.},
'dt_s':0.01,'duration_s':40.,'seed':42,
'limits':{'u_min':0.,'u_max':2.},
'status':'simulation only'
}
print(json.dumps(record,indent=2))
Leave a record that another person can rerun and challenge.
Practical: defend a complete controller design
Build a final simulation report with requirements and adverse cases.
Use the normalised plant dy/dt=-y+u+d, a PI controller, and command limits [0,2]. Start at y=0, request y=1, and apply d=-0.3 after 10 s. Use conditional anti-windup and compare two gain choices.
Define metrics before running: final tracking error, integrated absolute error, peak command, and saturation fraction. Record the initial state and update order. Repeat with slower plant dynamics, sensor noise, and an unreachable target followed by recovery.
The automated check verifies a baseline simulation, not an entire engineering qualification. Your final deliverable explains the model, requirements, controller, evidence, limitations, and next experiment. Use a project brief to extend the work to a richer plant.
Your experiment plan
Use the browser editor or the downloadable notebook. All plant data are simulated. Keep a notebook with parameters, predictions, results, and units.
- Write a requirements table before tuning.
- Compare two PI gains on tracking and load rejection with command limits.
- Repeat on at least three plant time constants and two noise levels using fixed seeds.
- Add an unreachable-reference recovery case and a stale-sensor fault case.
- Prepare a short report and choose one of the six projects for a deeper extension.
What to hand in
- A rerunnable notebook with configuration and seeds.
- A requirements table with pass, fail, or unproven for every test.
- Output and command plots, uncertainty cases, and a clear limitations section.
Reflect on your results
Which assumption matters most? Describe one result that surprised you and one experiment that would test your explanation.
The automatic exercise checks the core code behaviour. Review observations and written deliverables yourself or with a mentor.
See it in action
def run_design(kp=2.,ki=1.):
y, integral, dt = 0.,0.,0.01
iae, peak = 0.,0.
for k in range(4000):
e=1-y
raw=kp*e+integral
u=max(0.,min(2.,raw))
if not ((raw>2 and e>0) or (raw<0 and e<0)):
integral+=dt*ki*e
load=-0.3 if k*dt>=10 else 0.
y+=dt*(-y+u+load)
iae+=dt*abs(e); peak=max(peak,u)
return {'final_error':abs(1-y),'iae':iae,'peak_u':peak}
print(run_design())
A complete design is an argument supported by reproducible experiments.
Free, open and run by a nonprofit.
This page is part of Control Engineering, a free course of 20 modules and 60 lessons in the engineering.fit( ) Learning Lab. The Learning Lab is built and run by engineering.fit( ), a nonprofit founded by Abdullateef Opeyemi Bakare that helps African engineering students gain research experience. You do not need an account or pay a fee to learn.