|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| {{Math notes}} | | {{Math notes}} |
|
| |
|
| ==Optimization theory, control theory==
| | TEMPORARILY IN ONE BIG HEAP |
| <!--
| |
| '''Optimization theory''' is basically applied mathematics that finds the best choice in given data.
| |
| Which is still very abstract, yes.
| |
| | |
| | |
| It often sits along '''control theory''', which is concerned with the best course of action.
| |
| | |
| Optimization theory tends to focus a little more on the math of the model,
| |
| control theory more on feedback from the real world.
| |
| | |
| | |
| https://en.wikipedia.org/wiki/Mathematical_optimization#Major_subfields
| |
| | |
| -->
| |
| | |
| ===Glossary===
| |
| <!--
| |
| | |
| '''Controller-related'''
| |
| * Controller - something that monitors and affects the operational conditions of given dynamic system
| |
| | |
| * Control system - [http://en.wikipedia.org/wiki/Control_system]
| |
| | |
| * Control loop - a (feedback) system that attempts to regulate a variable, in terms of something else
| |
| | |
| * Feedback - systems where output/control affects the thing being measured - that past influence will influence current/future state [http://en.wikipedia.org/wiki/Feedback]
| |
| ** Positive feedback - refers to cases feedback reinforces itself. Without stabilizing forces this will lead to oscillation, to divergence, and small changes to result in very large. A technical example: a microphone too much near its amplified output, a sociological one: a stampede, a bank run. [http://en.wikipedia.org/wiki/Positive_feedback]
| |
| ** Negative feedback - systems that try to avoid positive feedback (control opposing input and thereby itself), which means the system will tend to be more stable. [http://en.wikipedia.org/wiki/Negative_feedback]
| |
| | |
| * Proportional feedback
| |
| | |
| | |
| * closed loop control
| |
| ** system where there is feedback to check the output of the control (into the actuating system, or the control system), and correct any immediate problems.
| |
| ** makes sense when short-term accuracy, waste, danger is relevant (e.g. in CNC devices, chemical processes, and such)
| |
| ** If you measure system state fairly directly, you can (re)formulate things into a closed loop strategy by taking measured state as current state.
| |
| | |
| * open loop control (a.k.a. feed-forward?)
| |
| ** systems where the control is ''assumed'' to arrive, and runs in a predetermined way. If it does not (e.g. a motor is blocked), there is no way to know.
| |
| ** If you don't directly measure and can only really estimate, it's typically modelled as open loop.
| |
| | |
| | |
| * horizon: for systems that plan ahead...
| |
| ** '''control horizon''' - refers to the finite future for which there is a control plan. If not the same as the prediction horizon, it will be shorter.
| |
| ** '''predicton horizon''' - the finite future for which you have predicted the results of the planned control. If different than the control horizon, it is typically longer.
| |
| ** 'what would you have to do to have to do no control after this time window?'
| |
| ** finite-dimensional reduction (while QP, LP are infinite-dimensional, at least in the theory stage)
| |
| | |
| * Stability
| |
| ** Is there a sensible/preditable domain on the output given a reasonable bound of the input?
| |
| ** For closed-loop systems there are relatively simple analyses (e.g. Routh–Hurwitz)
| |
| ** degree of stability, relative stability -
| |
| | |
| * Setpoint - the target value that a controller aims to reach (when control is non-instant, which is usually)
| |
| | |
| | |
| | |
| '''Kalman's observability criterion''' and '''Kalman's controllability criterion''' are
| |
| | |
| | |
| Controllability: In order to be able to do whatever we want with the given
| |
| dynamic system under control input, the system must be controllable.
| |
| | |
| Observability: In order to see what is going on inside the system under observation, the system must be observable.
| |
| | |
| | |
| | |
| | |
| '''Model/strategy/system terms and properties'''
| |
| | |
| {{comment|(Often useful properties to describe and express systems in terms familiar in DSP, in terms of feedback, to apply transforms like convolution, describe in terms things like a system's impulse response.)}}
| |
| | |
| * '''Linear system''' - one in which the output is homogenous and additive in terms of the input
| |
| ** Linearity makes control simpler. (Linear estimates are occasionally used for simplicity's sake)
| |
| ** Things like robots and such won't make for particularly linear systems
| |
| | |
| * Homogeneity -
| |
| | |
| * Additivity -
| |
| | |
| * Superposition - homegenous and additive
| |
| | |
| * Shift-invariance
| |
| ** describes whether responses at different points in time are identical. For example, a sound amplifier is a shift-invariant linear system
| |
| ** In modelling it is often useful to know whether a linear system is also shift-invariant
| |
| | |
| * linear filter - often synonymous with 'shift-invariant linear system'.
| |
| | |
| * Linear feedback system -
| |
| | |
| * Nonlinear system -
| |
| | |
| * Nonlinear feedback system -
| |
| | |
| * Linear control systems - (control system with linear feedback) use linear negative feedback to produce a control signal mathematically based on other variables, with a view to maintaining the controlled process within an acceptable operating range.
| |
| ** simple soltutions for linear systems (and systems that you can control under the assumption they are linear enough in the short term)
| |
| | |
| * saturation strategy -
| |
| | |
| * windup - when the response to a setpoint change can mean significant accumulation of error, often meaning an overshoot. In particular in PID systems.
| |
| ** Can have various causes, one of which controller's physical limitations (e.g. slower change), which PID can't really model, and which can cause the I part to go crazy.
| |
| ** http://en.wikipedia.org/wiki/Integral_windup
| |
| | |
| * anti-windup strategy - some way of avoiding windup, such as ramping towards the setpoint, disabing I until we get closeish to the setpoint, modelling the actuator, or whatnot
| |
| | |
| | |
| * SISO, SIMO, MISO, MIMO - single/multiple input, single/multiple output. Has implication on the model's complexity, and computational compexity.
| |
| | |
| -->
| |
| | |
| ===System analysis===
| |
| <!--
| |
| | |
| | |
| Note: timespan and type of dynamics are important - and interact
| |
| * For example, a chemical plant may easily have nonlinear dynamics, that work on the order of minutes or even hours
| |
| * Whereas computer process or network scheduling has to happen in less than milliseconds, and you can assume fairly linear dynamics
| |
| | |
| | |
| | |
| Limits on control:
| |
| * practical actuation constraints
| |
| ** amplitide (e.g. actuator extents), slew rate (e.g. actuator speed limit, a servo may take up to a second to move to the target position)
| |
| | |
| * practical state constraints,
| |
| ** hard maximums such as a full water tank
| |
| | |
| * discrepancy on wished and and delivered control
| |
| | |
| | |
| | |
| All real-world problems are constrained in some way. Sometimes in minor ways you can ignore, while in other cases cannot, particularly where the state and/or set point are near a point where control would be constrained, which makes this a fundamental part of the problem statement.
| |
| | |
| Such constraints implicitly make control suboptimal, partly because it often makes the effective response time larger, and partly because some models cannot (and some just do not) consider such constraints.
| |
| | |
| Depending on goals and costs, it can be useful to actuate a little more than you otherwise would to reach a setpoint faster, but at the cost of possible instability, and in particular overshoot.
| |
| | |
| '''Windup''' refers to this pattern of overshoot. Also known as '''integral windup''' because it is the integral controller that causes this{{verify}}.
| |
| There is some theory on how to avoid and model it to predictably.
| |
| | |
| Linear system, symmetric control:
| |
| *
| |
| | |
| Linear system, asymmetric control:
| |
| | |
| | |
| | |
| Example problems:
| |
| * Boat rudder control
| |
| ** course keeping, but also using small adjustments to stabilize rolling motion (one actuator, two goals)
| |
| ** limited in amplitude, slew rate
| |
| | |
| * Cruise control
| |
| | |
| * HVAC system
| |
| | |
| * Airplane aileron control
| |
| | |
| ===Problem theory===
| |
| | |
| | |
| Example description of linear system:
| |
| x(t+1) = Ax(t) + Bu(t)
| |
| Where
| |
| * t is integer (discrete steps)
| |
| | |
| * x(t) is system state
| |
| * x(0) = z (given start state)
| |
| | |
| * x has to be in a given set
| |
| | |
| * u is the control/action
| |
| * input/controls u are in a given set / constraints (e.g. throttle opening, aileron stops)
| |
| | |
| * Aim to minimize some cost function (may be sum over time)
| |
| | |
| | |
| | |
| | |
| Real-world problems are almost always due to various sorts of constraints, like actuator constraints (speed, delay, slew), and some fundamental details (reservoir size, etc.)
| |
| | |
| | |
| | |
| | |
| | |
| ===Types of problems===
| |
| | |
| LP, QP, and other approaches make it easy to model various entangled properties while keeping the way we manage a lot of interaction fairly easy to express and handle (mathematically speaking)
| |
| | |
| ====Second-order cone program (SOCP)====
| |
| Relation to Quadratically constrained quadratic program (QCQP) [http://en.wikipedia.org/wiki/Quadratically_constrained_quadratic_program] ?
| |
| | |
| | |
| =====Linear Programming (LP)=====
| |
| Special case of SOCP problems,
| |
| | |
| * objective is linear function of the decision variables
| |
| * constraints are linear functions of the decision variables
| |
| | |
| For example:
| |
| * maximize/minimize:
| |
| c<sub>1</sub>x<sub>1</sub> + c<sub>2</sub>x<sub>2</sub> +...+ c<sub>n</sub>x<sub>n</sub>
| |
| * subject to
| |
| a<sub>11</sub>x<sub>1</sub> + a<sub>12</sub>x<sub>2</sub> +...+ a<sub>1n</sub>x<sub>n</sub> ~ b<sub>1</sub>
| |
| a<sub>21</sub>x<sub>1</sub> + a<sub>22</sub>x<sub>2</sub> +...+ a<sub>2n</sub>x<sub>n</sub> ~ b<sub>2</sub>
| |
| ...
| |
| a<sub>m1</sub>x<sub>1</sub> + a<sub>m2</sub>x<sub>2</sub> +...+ a<sub>mn</sub>x<sub>n</sub> ~ b<sub>m</sub>
| |
| * with bounds:
| |
| l<sub>1</sub> ≤ x<sub>1</sub> ≤ u<sub>1</sub>
| |
| ...
| |
| l<sub>n</sub> ≤ x<sub>n</sub> ≤ u<sub>n</sub>
| |
| | |
| Where
| |
| * ~ can be ≤, = ≥
| |
| * lower bound (l) and upper bound (u) can be -inf, inf, real numbers
| |
| | |
| You would enter:
| |
| * objective function coefficients (c1, c2, ..., cn)
| |
| * constraint coefficients (a, right hand sides b)
| |
| * upper and lower bounds
| |
| | |
| The solution will be coefficients for x1.. xn
| |
| | |
| | |
| | |
| * typically solved via the simplex method [http://en.wikipedia.org/wiki/Simplex_method]
| |
| * Since all linear functions are convex, they are intrinsically easier and faster to solve than various types of non-linear programming problems.
| |
| | |
| * can determine:
| |
| (i) has no feasible solution
| |
| (ii) has an unbounded objective
| |
| (iii) has a globally optimal solution (single point or multiple equivalent points).
| |
| | |
| | |
| Mixed Integer Programming (MIP)
| |
| * LP with integer constraints [http://en.wikipedia.org/wiki/Linear_programming#Integer_unknowns]
| |
| * harder to solve?
| |
| | |
| | |
| '''Quadratic Programming (QP)'''
| |
| * special case of SOCP problems
| |
| * objective is quadratic function of the decision variables
| |
| * constraints are linear functions of the decision variables
| |
| | |
| | |
| Constraint Programming (CSP)
| |
| | |
| | |
| | |
| When QPs were new, calculating them was heavy and complex. By now it's cheap (which is one reason MPC is fast ''enough'').
| |
| Note that it can be a lot faster when a specific problem is worked our and optimized for hardware, than the same model may be while part of a generic solver, such as prototyping in matlab.
| |
| | |
| | |
| | |
| | |
| | |
| Quadratic Program(ming) (QP): An optimization problem with a quadratic objective function, and linar constraints. In general:
| |
| f(x) = cx + 1/2 x<sup>T</sup>Q x
| |
| subject to:
| |
| Ax < b
| |
| x ≥ 0
| |
| | |
| | |
| | |
| | |
| * Convex function - one that, within a given interval, lies below all possible line segments from two points on that interval. Visually: a dip.
| |
| ** Useful property because this makes optimization tractible, partly because because local optimality is global optimality
| |
| ** http://en.wikipedia.org/wiki/Convex_function
| |
| | |
| * Convex optimization: minimizing/maximizing convex functions
| |
| ** http://en.wikipedia.org/wiki/Convex_optimization
| |
| ** Complex optimizations include:
| |
| *** Least squares [http://en.wikipedia.org/wiki/Least_squares]
| |
| *** Linear programming (LP) [http://en.wikipedia.org/wiki/Linear_programming]
| |
| *** Quadratic programming (QP) [http://en.wikipedia.org/wiki/Quadratic_programming]
| |
| *** Conic optimization [http://en.wikipedia.org/wiki/Conic_optimization]
| |
| *** Second order cone programming (SOCP) [http://en.wikipedia.org/wiki/Second-order_cone_programming]
| |
| *** Geometric programming [http://en.wikipedia.org/wiki/Geometric_programming]
| |
| *** Semidefinite programming [http://en.wikipedia.org/wiki/Semidefinite_programming]
| |
| *** Quadratically constrained quadratic programming [http://en.wikipedia.org/wiki/Quadratically_constrained_quadratic_programming]
| |
| *** Entropy maximization [http://en.wikipedia.org/wiki/Entropy_maximization]
| |
| | |
| ====Unsorted====
| |
| | |
| Linear-quadratic regulator [http://en.wikipedia.org/wiki/Linear-quadratic_regulator]
| |
| | |
| http://en.wikipedia.org/wiki/Category:Optimal_control
| |
| | |
| | |
| ===Software===
| |
| | |
| '''C''':
| |
| * CSDP: C Library for Semidefinite Programming [https://projects.coin-or.org/Csdp]
| |
| * CVXGEN: Code Generation for Convex Optimization [http://cvxgen.com/]
| |
| ** generates fast, library-free C code (useful for embedded use)
| |
| | |
| * http://www.stanford.edu/~boyd/papers/fast_mpc.html
| |
| | |
| '''Python''':
| |
| * http://jleny.wordpress.com/2009/12/31/python-control-libraries/
| |
| * CVXMOD: Convex optimization software in Python [http://cvxmod.net/]
| |
| * CVXOPT: Python Software for Convex Optimization [http://abel.ee.ucla.edu/cvxopt/]
| |
| | |
| | |
| '''Matlab''':
| |
| * CVX: Disciplined Convex Programming [http://cvxr.com/cvx/]
| |
| * SDPT3: semidefinite-quadratic-linear programming [http://www.math.nus.edu.sg/~mattohkc/sdpt3.html]
| |
| * SeDuMi: [http://sedumi.ie.lehigh.edu/]
| |
| * YALMIP [http://users.isy.liu.se/johanl/yalmip/]
| |
| | |
| | |
| -->
| |
| | |
| ===Some controllers===
| |
| | |
| In terms of the (near) future:
| |
| * greedy control doesn't really look ahead.
| |
| | |
| * PID can be tuned for some basic tendencies
| |
| | |
| * MPC tries to minimize mistakes in predicted future
| |
| | |
| | |
| | |
| * For example, take a HVAC system that actively heats but passively cools. This effectively means you should be very careful of overshooting. You would make the system sluggish -- which also reduces performance because it lengthens the time of effects and settling
| |
| | |
| | |
| | |
| Non-linear:
| |
| * HVAC
| |
| | |
| | |
| | |
| ====Greedy controllers====
| |
| | |
| Doesn't look ahead, just minimizes for the current step.
| |
| | |
| | |
| For example basic proportional adjustment.
| |
| | |
| Tends not to be stable.
| |
| | |
| | |
| Can be stable ''enough'' for certain cases, in particular very slow systems where slow control is fine, and accuracy not so important.
| |
| | |
| For example, water boilers have such large volume that even a [https://en.wikipedia.org/wiki/Bang%E2%80%93bang_control bang-bang controller] (turn a few-hundred-watt heater element fully on or off according to temperature threshold) will keep the water within a few few-degrees of that threshold, simply because the water's heat capacity means is large in relation to the heating element you'ld probably use (see also [https://en.wikipedia.org/wiki/Volumetric_heat_capacity#Thermal_inertia thermal inertia]).
| |
| | |
| | |
| If on the other hand the bioler's volume is small or the heater too powerful, it will spike much too warm, and average well above the setpoint.
| |
| | |
| More generally, you run into issues like that if you need control to be fast,
| |
| you easily run into the issue that actuation may be too fast for the measurement,
| |
| easily causing feedback and oscillations as well.
| |
| | |
| ====Hysteresis (behaviour)====
| |
| | |
| <!--
| |
| Hysteresis refers to a system state depending on some amount of history,
| |
| and intuitively to sluggishness of response.
| |
| | |
| There is often some hysteresis in the measurement or control to avoid rapid switching - though such fast control isn't ''always'' a problem.
| |
| -->
| |
| | |
| ====Hysteresis control (type)====
| |
| | |
| <!--
| |
| '''Hysteresis ''control'' '''
| |
| | |
| -->
| |
| | |
| ====Map-based controller (type)====
| |
| | |
| <!--
| |
| Based on a lookup table, so determinisic.
| |
| | |
| Somewhat like greedy, but can have more interesting responses,
| |
| because it lets you code nontrivial transfer function into a very simple IC (or even discrete solution).
| |
| | |
| It also theoretically lets you update parts
| |
| | |
| | |
| https://en.wikipedia.org/wiki/Map-based_controller
| |
| -->
| |
| | |
| ====PID controller====
| |
| {{stub}}
| |
| | |
| PID is a fairly generic control-loop system, still widely used in industrial control systems.
| |
| | |
| It is useful in systems that have to deal with delays between and/or in actuation and sensing,
| |
| where they can typically be tuned to work better than greedy controllers (and also be tuned to work worse),
| |
| because unlike greedy, you can try to tune out overshoots as well as oscillations.
| |
| | |
| PID is computationally very cheap (a few adds and multiplies per step), compared to some other cleverer methods.
| |
| | |
| | |
| Yet:
| |
| * There are no simple guarantees of optimality or stability,
| |
| : you have to tune them,
| |
| : and ''learn'' how to tune them.
| |
| | |
| * tuning is complex in that it depends on
| |
| : how fast the actuation works
| |
| : how fast you sample
| |
| : how fast the system changes/settles
| |
| | |
| * doesn't deal well with long time delays
| |
| | |
| * derivative component is sensitive to noise, so filtering may be a good idea
| |
| | |
| * has trouble controlling complex systems
| |
| : more complex systems should probably look to MPC or similar.
| |
| | |
| * linear at heart (assumes measurement and actuation are relatively linear)
| |
| : so doesn't perform so well in non-linear systems
| |
| | |
| * symmetric at heart, so not necessarily well-suited to non-symmetric actuation
| |
| : consider e.g. a HVAC system -- which would oscillate around its target by alternately heating and cooling.
| |
| : It is much more power efficient to do one passively, e.g. active heating and passive cooling (if it's cold outside), or active cooling and passive heating (if it's warmer outside)
| |
| :: means it's easier to overshoot, and more likely to stick off-setpoint on the passive side, so on average be on one side
| |
| :: You could make the system sluggish -- in this case it reduces the speed at which it reaches the setpoint, but that is probably acceptable to you.
| |
| :: in other words: sluggish system and/or a bias to one side
| |
| | |
| | |
| =====Some definition=====
| |
| {{stub}}
| |
| | |
| The idea is to adjust the control based on some function of the error, and a Proportional–Integral–Derivative (PID) controller combines the three components it names, each tweaked with their own weight (gain).
| |
| | |
| The very short version is that
| |
| * P adjusts according to the ''proportional'' error
| |
| * I adjusts according to the ''integrated'' error
| |
| * D adjusts according to the ''derivative'' error
| |
| | |
| | |
| It can be summarized as:
| |
| : [[File:PID formula.png|300px]]
| |
| where
| |
| * e(t) is the error
| |
| * P, I, and D are scalar weights controlling how much effect each component has
| |
| | |
| | |
| <!--
| |
| Roughly speaking,
| |
| P looks at how far you currently are,
| |
| I looks at where you've been over time,
| |
| D considers where you're probably going,
| |
| | |
| | |
| In practice, it turns out there are many cases where it makes sense to disable parts.
| |
| | |
| * PI controllers (D turned off, or maybe just very low) may be more common than full PID
| |
| : because adding I does a little better than just P in many systems
| |
| | |
| : you see some full PID
| |
| | |
| : PD has relatively few specific applications
| |
| | |
| : just P can work well enough in situations with low mass/delay
| |
| | |
| : (I and D by themselves make little sense {{verify}})
| |
| | |
| | |
| | |
| | |
| -->
| |
| | |
| =====Some intuition=====
| |
| {{stub}}
| |
| <!--
| |
| Example time.
| |
| | |
| Say you're trying to match speeds with the car in front of you, and you have distance sensor.
| |
| | |
| The easiest way is to have a target distance, and keep that constant.
| |
| | |
| | |
| You would probably make your error function (the thing that should go down to zero)
| |
| measured_distance - intended_distance
| |
| and your actuation be the gas and brake pedals.
| |
| | |
| | |
| A '''P controller''' (and some people) would be using ''only'' at that distance,
| |
| meaning you accelerate when it's too far away, and brake when you are too close.
| |
| | |
| A P controller would also base the magnitude of the response (how hard to hit the gas or brake pedal) on the magnitude of the error.
| |
| | |
| The gain of the P response would be a factor of how strong to press in response to the same amount of error.
| |
| | |
| | |
| | |
| That works, and the P factor will typically be the largest contributor in a PID system.
| |
| | |
| But there's a few practical details.
| |
| | |
| In any real world case there is some delay in the sensor, the decision, a the actuation - and in this case also some sluggish response because cars have mass.
| |
| Whatever you do, it happens late.
| |
| | |
| This means you're likely to overshoot a little, then to slow down to correct, accelerate again, brake, accelerate, etc.
| |
| If sensing and actuation was almost immediate, that oscillation would be smaller, but still there.
| |
| | |
| Not enough to cause accidents, but probably enough to make ''some'' passengers carsick, depending a little on how aggressive the adjustment.
| |
| : A very small P factor would be smoother ride, but react too slowly to changes and spend little of the time with distance or speed matched.
| |
| : A very large P factor makes any amount of oscillation stronger. In fact, if it starts far enough off-target (or gets far enough off-target) it may try to actuate so strongly it would never stabilize again. In the example, if you get far behind, you may race to get back, and never even consider braking before you cross your intended distance -- which with a large speed difference may be far too late. (this system doesn't actually model things like braking distance at all, which is why you wouldn't use it for this example in the real world)
| |
| | |
| | |
| Also, when the actuator
| |
| : has a lot of momentum, it'll oscillate harder
| |
| : is very immediate, it'll oscillate faster
| |
| | |
| | |
| Also, with P alone there is not necessarily much reason for the amount of oscillation (so reaction) to lower and disappear. It's almost like a conservation of energy thing.
| |
| | |
| | |
| | |
| | |
| One reason to consider D is that it reacts to changes in distance over time.
| |
| | |
| In this case it would reacts to changes in speed, and D by itself may even match speed, but at a distance you can't control. In most applications that's not useful and you would combine it with P.
| |
| | |
| As such, D is often added with a low factor, considered as a useful dampening for P and I efforts.
| |
| This also helps dampen oscillation over time.
| |
| | |
| Generally, D should be kept low, more so around noise, e.g. measurement noise
| |
| | |
| You can get better response with some lowpass on D (some suggest median instead), though too strong a lowpass cancels out the derivative control. It's not necessarily useful to have ''another'' thing to tune.
| |
| | |
| There is an argument that well tuned PI is better than moderately tuned PID.
| |
| | |
| | |
| | |
| | |
| | |
| One reason to consider I is that P and D basically still using one step for error calculation,
| |
| and at some small amount of error P would no longer respond (and and D won't react at all when error is constant), so PD may settle ''near'' but not ''on'' the setpoint.
| |
| | |
| That offset is stronger if there are system-inherent delays, or effects that push more in one direction than another - e.g. gravity in robot control, environment temperature when heating things, etc.
| |
| | |
| | |
| I effectively collects error over time, (its influence is proportional to magnitude ''and duration'' of error).
| |
| | |
| But for the same reason, this is most useful when already near the setpoint - the further away, the more it has a tendency of wanting to ''accelerate'' towards the setpoint, and just be another reason for overshoot and oscillations.
| |
| As such, it's generally used with a rather small small factor, to help nudge it (P or PD) over to the real setpoint.
| |
| | |
| -->
| |
| | |
| <!--
| |
| | |
| Further properties
| |
| * differentiation is a shift-invariant linear operation, which makes it an interesting tool in systems with such properties.
| |
| | |
| See also:
| |
| * http://en.wikipedia.org/wiki/PID_controller
| |
| * http://www.google.com/search?q=PID%20without%20phd
| |
| | |
| | |
| https://controls.engin.umich.edu/wiki/index.php/PIDIntro
| |
| | |
| TODO: read:
| |
| * http://www.codeproject.com/Articles/36459/PID-process-control-a-Cruise-Control-example
| |
| * http://www.diydrones.com/profiles/blogs/announcing-arducopter-the?id=705844:BlogPost:163519&page=119#comments
| |
| * http://www.mstarlabs.com/docs/tn031.html
| |
| * http://www.expertune.com/tutor.aspx
| |
| * http://www.mstarlabs.com/docs/tn031.html
| |
| | |
| | |
| | |
| | |
| | |
| Examples / discussion
| |
| | |
| | |
| : '''Heating a large pot of water'''
| |
| | |
| ...for example a boiler providing you with hot water trying to stay at a temperature.
| |
| | |
| The heat capacity of water is so large that given a few liters, even shoving a kilowatt in there will still only mean a bunch-of-degrees-per-minute change.
| |
| | |
| You don't even need P, as on and off (bang-bang control) is fine,
| |
| particular if you don't care about overshooting a degree or two.
| |
| | |
| A bit of hysteresis is fine, but mostly for the electronics involved relay.
| |
| The oscillation's asymmetry isn't a big issue either.
| |
| | |
| | |
| | |
| An example for when D is useful:
| |
| | |
| Say you are heating a wax, and its smoke point is not much higher than its melting point, meaning that while you want to get it to melt soon, you don't want to overshoot and burn it. {{comment|(note that in this example, you only get to actuate one way, adding heat, so we only need to discuss one side)}}
| |
| | |
| Assuming your heater is good enough to increase the temperature quickly, PI alone would probably still overshoot, because it's not considering that heat added should be zero near the setpoint{{verify}}
| |
| | |
| | |
| | |
| -->
| |
| | |
| =====So how do you tune it?=====
| |
| <!--
| |
| | |
| There's always the "set enough P for reasonable actuation speed, add a much smaller amount of I and D, and decide if you're happy" method.
| |
| | |
| | |
| More specific advice depends on specifics.
| |
| | |
| Disturbance rejection and overshoot/oscillation are at odds in various cases. Decide what you want.
| |
| | |
| | |
| But also, there will generally be effects from
| |
| * sampling rate
| |
| : mostly in relation to...
| |
| | |
| * actuation speed
| |
| : and how actuation relates to sampling -- they should probably be on the same order, or sample faster.
| |
| | |
| * time in which you want the system to settle
| |
| : and how actuation relates to sampling -- should probably sample faster than the time in which you want the system to settle
| |
| | |
| * speed at which you want to react
| |
| | |
| * overshoot
| |
| | |
| * noise
| |
| | |
| | |
| | |
| | |
| | |
| To be a little more exact, look at"
| |
| * [https://en.wikipedia.org/wiki/Ziegler%E2%80%93Nichols_method Ziegler-Nichols tuning]
| |
| | |
| | |
| -->
| |
| | |
| ====MPC (Model Predictive Control)====
| |
| <!--
| |
| {{stub}}
| |
| | |
| For a basic intuition: Model predictive control (MPC) makes decisions based on how a basic numeric solution (e.g. quadratic programming) thinks the system would react to the planned control.
| |
| | |
| It makes a complete plan up to a given prediction horizon (some steps ahead), but only actually uses the first step for control.
| |
| | |
| The rest are basically there to avoid making predictable mistakes within the plan's timespan (which means that even if calculations are bad, it's often still better than greedy reaction based on the same).
| |
| | |
| It will then measure and do the same thing again.
| |
| | |
| It typically tries to solve control to be finished at the end of the control horizon {{comment|(if that is infeasibile, that often means the horizon is too short)}}
| |
| | |
| | |
| | |
| As an idea it is fast enough to be realtime, in that what MPC wraps around what you already have is fairly basic math, so widely applicable, though currently mostly seen in industrial, particularly petrochemical control.
| |
| | |
| Many real-world applications are not fast, sometimes far from it, because designers often err on the side of thorough calculation, i.e. complex models, whenever control doesn't need to be that fast.
| |
| | |
| It also doesn't help that people don't think to use MPC for for smaller problems.
| |
| Also, some MPC toolboxes are set up for prototyping and generic problem solving, and are more flexible than they are fast.
| |
| | |
| | |
| | |
| Practical for multivariate systems, and applicable to non-linear systems.
| |
| | |
| The mathematical properties (constraints, model) vary a little with the field's details, because different people came up with the same basic idea in different fields, and implemented it in different ways.
| |
| | |
| MPC is, arguably, the modern name that attempts to pull together a lot of closely-related theory (and names) - see e.g. '''finite lookahead control''', '''moving horizon control''', '''receding horizon control''', '''generalized predictive control''', '''dynamical matrix control''' and others.
| |
| | |
| | |
| Because the math of generic MPC is quadratic cost, it begs some comparison to Linear–Quadratic Regulators (LQR), and introductions tend to mention the differences.
| |
| | |
| | |
| | |
| | |
| Properties:
| |
| * Allows choice of model, including complex ones.
| |
| | |
| * Finite horizon of prediction
| |
| : that amount of future steps is calculated each step (hence some of the names)
| |
| | |
| * tends to work decently even when your basic model is flawed - because its plan tends to be stabilizing in the given timespan
| |
| ** ...assuming fairly complete state information
| |
| ** partly because it avoids violating the given constaints within the timespan as well as it can, avoiding overreactions and some feedback
| |
| * MPC has advantages when things aren't so deterministic (when a model can't be perfect, when disturbances are likely). Depending a little on implementation, MPC still does fairly well when the future doesn't match the plan very much
| |
| | |
| * lets you models state contstraints more easily than some other systems,
| |
| * ...so behaves in an anti-[https://en.wikipedia.org/wiki/Integral_windup windup] sort of way, within certain demands
| |
| | |
| | |
| Variations include:
| |
| * Linear MPC - called that when using a linear model (even if the controlled system's dynamics aren't linear)
| |
| * nonlinear MPC - any computable model
| |
| * hybrid MPC -
| |
| * state-based MPC -
| |
| * stochastic MPC -
| |
| * control using first few steps plan, only recalculate after that (cheaper calculation, also has further implications)
| |
| * explicit MPC (automatically generated), limited but still useful applications
| |
| | |
| | |
| See also:
| |
| * http://en.wikipedia.org/wiki/Model_predictive_control
| |
| | |
| | |
| | |
| http://www.mathworks.nl/products/mpc/index.html
| |
| | |
| -->
| |
| | |
| ====FLC (Fuzzy Logic Control)====
| |
| | |
| <!--
| |
| | |
| See also:
| |
| * http://en.wikipedia.org/wiki/Fuzzy_control_system
| |
| | |
| -->
| |
| | |
| ====LQR====
| |
| <!--
| |
| | |
| -->
| |
| | |
| ===See also===
| |
| | |
| * http://en.wikibooks.org/wiki/Control_Systems
| |
| | |
| | |
| | |
| | |
| | |
| [[Category:Math on data]]
| |
| [[Category:Algorithms]]
| |