COMP 3212 - Cruise control: a continuous car, a digital controller
The car is a cyber-physical system that evolves continuously in time. The controller is software: it wakes up periodically, reads the speed, computes a force and writes it to the actuator. The control law is already tuned, but you can see the impact of changing its parameters (as well as those of the car, the road, and the reference speed set by the driver). In a separate box, you can change the implementation and performance characteristics of the digital controller independently of the control law.
The plant and the control law
dv/dt = (f − b·v)/m, with f = Kp·e + Ki·∫e dt and e = reference − speed.
The computer running the control law
Sample-to-actuation delay, as a share of the period.
Random variation added to the delay, run to run.
Share of jobs that never complete. The actuator holds its last value.
Start from
Speed of the car
The driver asks for the reference speed at t = 2 s.
Force at the actuator
Held constant between actuations. Ticks below mark each controller job; orange ticks are jobs that missed their deadline.
What to try
Leave the car, the road and the two gains alone: that is somebody else's design, and on an infinitely fast computer it produces the grey dashed curve every time. Your job is to find out what your implementation does to it.
- Start from a 10 ms period with no delay and no jitter. Increase the sampling period slowly. At what period does the red curve visibly separate from the grey one? At what period does the car start to overshoot, even though the control law was designed not to? At what period does it stop settling at all?
- Put the period back to a value that worked, then raise the response time. A late actuation is not the same as a slow one — compare a 200 ms period with 80% response time against an 800 ms period with none. Which of the two is worse, and why?
- Add jitter without changing anything else, then change the seed a few times. What does that tell you about testing a control system on a platform whose timing you have not bounded?
- Now add deadline misses. Is losing 20% of the jobs as bad as running the loop five times slower? What is the actuator doing while the job is missing?
- Finally, take a case that has gone unstable and recover it without touching Kp or Ki. Whatever you changed is the engineering budget you have to negotiate for.
Simplifications worth knowing about: the engine can produce any force the control law asks for, there is no gravity, no gear, no measurement noise and no quantisation, and the plant is integrated exactly between events, so every difference you see between the two curves comes from the timing of the software and from nothing else.