The common description for a continous PID-controller is written like this: $$y(t)=K_p⋅e(t)+K_i\int_0^t e(τ)dτ+K_d\dfrac{de(t)}{dt}$$ The best value of the constants $K_p$, $K_i$ and $K_d$ for a given controlled system will depend on its time constant(s), be it a $\text{PT}_1$ system, or $\text{PT}_2$ system, etc. ...

What do you do if the time constant of such a system is variable. Lets say, it varies between $T_a$ and $T_b$ ($T_a < T_b$). How do you design the PID-constants?


One way would be to implement some form of adaptive control. If your range of time constants is small and known, you could use something called "gain scheduling" where you determine before hand all the time constants you'll be dealing with (hopefully it is finite) and use if/then logic to define P I and D. It can be challenging to make sure you have covered enough variability to ensure stability and performance through the range. A good success story for gain scheduling is the Chinook helicopter. It can be done.

If you don't have a feasible prediction for what the time constants will be, you could look into using Model Reference Adaptive Control(MRAC). In this control scheme you have a reference model (your ideal system) with your chosen PID controller. The MRAC minimizes the error between what the plant is actually doing and what your reference model is doing. In this way you force your changing plant to act like your LTI model.

Or you could try using Model Identification Adaptive Controller (MIAC). Here the control scheme does system identification in real time and uses an update law for your controller. This one requires the most advanced skill of the three ideas.

Since your system is changing time constants over time, it is no longer LTI. This means you need to either do gain scheduling (pretty easy if you know the range of time constants) or system identification with update law for your PID.

  • $\begingroup$ why not dynamically equalize the time steps by designing for the larger timestep and making the software quasi-realtime by waiting during each iteration before submitting actuator commands? $\endgroup$ Dec 2 '15 at 20:23
  • $\begingroup$ @GürkanÇetin what is the software waiting for? Can you help me understand what is happening when the software deliberately delays a control update? $\endgroup$ Dec 2 '15 at 20:46
  • $\begingroup$ If I understand correctly, there's an unknown time-delay at each loop of the computation iterations (i.e. because of I/O communications, or other CPU tasks.) This is a general problem on a non-real-time target (OS). So, tuning the controller for a predetermined (long) delta_t (say 100msec), and then at each iteration, trying to adjust the total loop-time to this delta_t (suppose the control algorithms are finished by the 80th msec, wait an extra 20msec) to submit the control commands; could work, if it is known that all other tasks take less than 100ms (minus the control law calculation time). $\endgroup$ Dec 2 '15 at 20:58
  • $\begingroup$ @GürkanÇetin if I understand the original question correctly, the question is about how to control when the physical aspects of a plant changes over time (i.e. rocket losing mass over time), not how to deal with non-real time operating loop execution times. I do think your suggestion could be valid, in terms of dealing with non-real time OS running a controller. $\endgroup$ Dec 7 '15 at 19:48
  • $\begingroup$ oh yes. I've mistaken the question. In this case if the plant is changing within time (abrupt or gradually), I would say reconfiguration is another possibility. Of course, works only if you know the change of the model dynamics. Like losing mass, spending fuel, extracting/retracting landing gears, etc. $\endgroup$ Dec 8 '15 at 5:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.