TODO add: PID material from Pont slides Some inverted pendulum videos Model-based control and other more sophisticated
controllers? controllers?
More code speed issues – perf with and w/o FP on
different processors
TODO add: PID material from Pont slides Some inverted pendulum - - PowerPoint PPT Presentation
TODO add: PID material from Pont slides Some inverted pendulum videos Model-based control and other more sophisticated controllers? controllers? More code speed issues perf with and w/o FP on different processors Last
TODO add: PID material from Pont slides Some inverted pendulum videos Model-based control and other more sophisticated
controllers? controllers?
More code speed issues – perf with and w/o FP on
different processors
Estimating worst case execution time Holistic scheduling: real-time guarantees over a CAN
bus
Feedback (closed loop) control and PID controllers
Principles Implementation Tuning
Definitions:
Desired state variables: X*(t)
Estimated state variables: X’(t)
E.g. “room temperature is currently 67”
– E.g. thermistor + ADC
Actions: U(t)
using transducers
Goal of a control system is to minimize error:
e(t) = | X*(t) – X’(t) |
Evaluating a control system
Steady-state controller error
Transient response
final value after X*(t) is changed
Stability
Centrifugal governor for a throttle
We’re designing a thermostat
Goal is to heat room to a set temperature We can turn the furnace on and off When furnace is off, room cools down by itself
Fancy control is not needed here! Rather we just need two temperature settings
Tlow – temperature at which we turn on the furnace Thigh – temperature at which we turn off the furnace The difference between these provides hysteresis
An on/off (“bang bang”) controller works well when
the physical system is slow to respond
What happens if control loop runs too fast or slow?
int Thigh, Tlow; bool on = false; timer_interrupt_handler (void) { int T = read_adc(); if (T < Tlow && !on) { turn_furnace_on();
} if (T > Thigh && on) { turn_furnace_off();
} }
We’re controlling a robot arm attached to a stepper
motor
Need to get the arm to a certain position Position sensor tells us where the arm is
Algorithm:
if E > 1mm then decrement position by 1mm if E < -1mm then increment position by 1mm
Pretty tough to go wrong with a strategy like this
But slow to converge
What happens if control loop runs too fast or slow?
Simple controllers like previous two examples work
but in many real situations
Respond slowly Have large errors
Better answer: PID (Proportional Integral Derivative) PID equation: KP, KI, and KD are design parameters
Can be fixed at zero to simplify the controller
t D I P
KP – determines response to current error
Too large Oscillation Too small Slow response Can’t eliminate steady-state error
KI – determines response to cumulative error
Can eliminate steady-state error but often makes transient Can eliminate steady-state error but often makes transient
response worse
KD – determines response to rate of change of error
Damps response when error is moving in the right
direction
Amplifies response when error is moving in the wrong
direction
Can be used to increase stability and improve transient
response
double UpdatePID (SPid *pid, double error, double position) { … } position = ReadPlantADC(); drive = UpdatePID (&plantPID, plantCommand - position, position); DrivePlantDAC (drive);
double UpdatePID (SPid *pid, double error, double position) { double pTerm; double pTerm; pTerm = pid->pGain * error; return pTerm; }
Problem: Proportional control can’t always eliminate
steady-state error
Problem: When there is too much actuator delay,
proportional control cannot stabilize the system
double iTerm; pid->iState += error; if (pid->iState > pid->iMax) { pid->iState = pid->iMax; } else if (pid->iState < pid-> iMin) { } else if (pid->iState < pid-> iMin) { pid->iState = pid->iMin; } iTerm = pid->iGain * iState;
In practice, always used in conjunction with
proportional control
Steady state error is eliminated
Sampling time becomes more important
Sampling time shouldn’t vary more than 1%-5% On average, sampling should be periodic
Integrator range is important
“Integrator windup” occurs when the integrator value gets
stuck too high or too low stuck too high or too low
Limiting the range makes this less of a problem Reasonable heuristic: Set integrator limits to drive limits
Usually, if you can’t stabilize a system with
proportional control, you can’t stabilize it with PI control either
double dTerm; dTerm = pid->dGain * (position - pid->dState); pid->dState = position;
Basically just computes the slope of the system
state
Attempts to predict system future based on recent
past history
Derivative is very sensitive to noise
In practice, might keep a buffer of several samples into the
past in order to smooth out noise
differential control in the first place differential control in the first place
Important for sampling period to be very even
Do sampling in a high-priority interrupt or thread
typedef struct { double dState; // Last position input double iState; // Integrator state double iMax, iMin; double iGain, // integral gain pGain, // proportional gain dGain; // derivative gain } SPid; double UpdatePID (SPid * pid, double error, double position) { double pTerm, dTerm, iTerm; pTerm = pid->pGain * error; pid->iState += error; if (pid->iState > pid->iMax) pid->iState = pid->iMax; else if (pid->iState < pid->iMin) pid->iState = pid->iMin; iTerm = pid->iGain * iState; dTerm = pid->dGain * (position - pid->dState); pid->dState = position; return pTerm + iTerm - dTerm; }
Example code uses floating point
Convert to integer or fixed-point by hand
OR
Keep using FP if the control loop frequency is low or if HW
FP is available
Multiplies can be avoided by selecting constants that Multiplies can be avoided by selecting constants that
are multiples of 2
Sampling rate
Too low Slow response time Too high Differential noise and integral overflow Rule of thumb: Set sampling rate between 1/10 and 1/100 of
desired settling time
Difficult control problems argue for higher sampling rates
Method 1: Plug system model into Matlab, it hands
you the parameters
Method 2: Tune by hand
Happy fact: When the system is not too sensitive, control
parameters only have to be roughly correct to do a good job
Requirements for hand tuning: Requirements for hand tuning:
Need to be able to observe controller variables and output Need to be able to supply square-wave inputs
Note: Parameters can interact in complex ways
Tuning is an art Tuning by hand will be difficult if system is barely
controllable
System may be uncontrollable
Start here unless you can do without dGain, in which
case set it to 0.0 and move to pGain
Start with small proportional gain, e.g. 1.0 Start with dGain == pGain * 100 Increase dGain until unacceptable oscillation, Increase dGain until unacceptable oscillation,
Oscillation from too much dGain is much faster than
Back off by factor of 2-4 System will now be sluggish – time to tune P and I
Start with a pGain around 1-100 By experimentation find the value of pGain where
Then back off by a factor of 2-4 Start with iGain around 0.0001-0.001 Start with iGain around 0.0001-0.001 Again find a value that gives reasonably good
performance without causing oscillation
Feedback control is a broadly useful technology for
getting an embedded system to have some desired effect on the real world
In practice manual tuning replaces analytic solutions However, Matlab has great support for feedback
control
Can generate efficient code too