How many times faster than real-time does a model has to be to be feasible for using model predictive control?
Assumptions:
Of course this depends a lot on the system dynamics, but could anybody make an educated guess?
This is almost impossible to answer, it depends on at least the following things, likely more
Thanks for your detailed reply!
I am trying to answer your question:
Lets start with a simple example. Steering a kite, keeping the nose pointing against the wind, and then applying different steering signals.
So we have a model with about 66 states, one input and one output.
Linearizing the system is problematic because the limited rate of the steering motors has a major impact on the behavior.
I plot the input and the output of the system. In the first example you can see that the turn rate is pretty much proportional to the steering signal, but in the second example this is not the case. Only difference is amplitude and shape of the steering signal.
Any idea how fast the model must be to make NMPC work?
I have a linearized controller that - somewhat - works, but the performance is not so good and it needs a lot of tuning for different wind speeds etc., and my hope would be that I could achieve better performance with less tuning with an NMPC controller.
I did not understand the question: “Do you use an interior-point solver or something like SQP with real-time iterations?” Currently I use no solver.
Performance of a PID controller for the given problem as reference:
The controller tries to keep the azimuth angle zero such that the nose of the kite is always pointing against the wind. At 20s there is a disturbance (1s 10% set_steering). The controller is active before and after the disturbance and compensates it, but:
So I thought trying an NMPC controller might be worth it.
It seems that your linear controller is sensitive to operating points and your nonlinear model is a bit too complex for realtime nonlinear MPC.
For that, you might want to try successive linearization MPC. In short, a new linearization is computed at each control period (using ForwardDiff.jl), and the plant model of a linear MPC is updated with this new linearization. See an example here.
Well, currently my model does not work with ForwardDiff.jl, because it is not everywhere differentiable. OK, that could be fixed.
But does this approach work well with actuator limitations (max force, max speed, max power)?
It the actuators are at the plant manipulated inputs u (from the MPC controller perspective), yes it will work very well since linear MPC can easily handle constraints on u (and possibly time-varying).
If the actuators are elsewhere, it depends. The local linearization can be quite bad near a saturation point. Reducing the control period and increasing the move suppression weight can sometimes mitigate these kind of modelling errors.
Does a rate limit at the input of the plant counts as constraint on u ?
Yes, rate limits on the plant inputs are also easily handled by linear MPCs. The are called \Delta \mathbf{u_{min}} and \Delta \mathbf{u_{max}} in ModelPredictiveControl.jl
Out of curiosity, how have you approached the tuning?
So I guess the only limit that might be difficult to handle are power limits? And perhaps speed limits, if the plant has a set-torque input, but the actuator (winch) also has a speed limit?
So far:
Of course I could try some tuning based on the transfer function in the frequency domain, but that is changing so much depending on the wind speed, height and the actuator saturation that I did not yet consider it worth the effort.
Yes, but you need to try it to confirms. If it turns out that these nonlinear constraints are problematic, there might be potential workaround: a NMPC with successive linearized plant model + a custom nonlinear constraint function. Custom nonlinear constraints are not available right now in NonLinMPC objects, but it’s the next feature on my TODO list. For that, you need to be able to estimate your constrained signals using the plant input and output. Would you be able to estimate power or winch speed using the steering and and turnrate signals only?
No matter what, you will probably needs to make your model differentiable, since many NMPC toolkit relies on AD for the optimization.
The way to approach this with PID controllers would probably be gain scheduling, but I agree with Francis, a continuously linearizing MPC controller would be a sensible thing to try. On another note, a state dimension of 60+ is rather large, are you sure that you need such an accurate model for the real-time controller? Does a discretization of a tether contribute a large number of variables? If so, could you reduce this number and maintain an acceptable accuracy?
When solving MPC problems, your final performance will be dictated both by how accurately you can simulate the dynamics, but also by how fast you can respond to disturbances. If your control performance is primarily dictated by disturbances, it can be better to trade off some model accuracy for faster response times (higher sample rate). Especially if your accurate prediction isn’t so accurate anyway, due to unpredictable disturbances.
Well, I currently use only 6 tether segments, using less is not really an option. But it would be possible to use a quasi static tether model like this one by Paul Williams: https://arc.aiaa.org/doi/abs/10.2514/1.G002354 .
Gain scheduling is the standard for the control of conventional wind turbines, but I doubt that it works well for airborne wind energy systems (I did that a lot in the past, but the results where debatable, also finding the right scheduling tables is time consuming and hard to automate).
Why is using less segments not an option? I suspect that using a MPC with a bad model already is a lot better than using a PID controller. Anyways, will have to test to find out what works. Another question: how are you going to estimate the state of the points of all the tether segments?
Well, the point is that with six segments you already get a force error of 10% at low wind speeds. This is less relevant for steering, but a problem for tether force control. At high tether tensions the error is lower.
10% error sounds like nothing, it’s not uncommon to design controllers to be robust enough to handle gains between 50%-200% of nominal model (gain margin of 2).
In this application this is not the case. We have a minimal force and a maximal force. The minimal force might be 10% of the max force. It shall never become zero, because when the tether becomes loose you loose the controllability of the kite. And the max force must never be exceeded, otherwise your tether might break.
The fact that the min value of the (control?) variable is 10 % of the max value does not imply anything about the error, does it?
