working MPC controller gets instable in Simulink

98 views
Skip to first unread message

Laura vH

unread,
Apr 15, 2015, 12:12:59 PM4/15/15
to yal...@googlegroups.com

Dear Johan,

I am currently working on building an MPC controller (based on LMIs). I started with a very simple model without uncertainties. In the m-file 'simulation' this simulation can be found and seems to work fine.

Although, I also want to build the MPC controller in Simulink. I have done this by adapting the model from the Standard MPC tutorial in Simulink (the fastest). However, when I run the simulation, the system is instable and 'explodes'. It already goes wrong with the first calculation of u. The input should increase at first, but as can be seen in the scope, this is not the case.

I have no idea what the cause of this can be. The parameters in both files are all the same. The reference is set to 0 and the initial condition of the states is [0.05; 0];

I hope you can tell me what is wrong, and why the controller seems to work perfectly when simulating in an m-file, but does almost the opposite when using Simulink.

I have attached all nescessary files.

Thanks you in advance!

kind regards, Laura


simulation.m
runit.m
controller.m
model.slx

Johan Löfberg

unread,
Apr 15, 2015, 3:15:45 PM4/15/15
to yal...@googlegroups.com
You are not using the discrete model in the definition of the controller object

Johan Löfberg

unread,
Apr 15, 2015, 3:29:00 PM4/15/15
to yal...@googlegroups.com
however, the model which you discretize in controller.m (but never use the discrete model), is used directly as the discrete model in simulation, but you use it as the continuous time model in the state-space block. I.e, completely messed up

Additionally, you have different constraints in the models

Laura vH

unread,
Apr 16, 2015, 4:49:01 AM4/16/15
to yal...@googlegroups.com
Hi Johan,

Thank you for your fast reply. I have changed the constraints so they are indeed the same. I've tried several things using the discrete model, however this gives the same result..

I've changed the state space block in Simulink to a discrete one. I've changed the controller object to a description with the discrete matrices, and a combination of both. But nothing changes whatever I do. 

I believe my model and controller file are now build up the same as in the tutorial on: http://users.isy.liu.se/johanl/yalmip/pmwiki.php?n=Blog.YALMIP-and-Simulink 
but is does not work (see below, in combination with a normal state space block as in the tutorial).

    for k = 1:N
        objective = objective + (C*x{k}-r{k})'*Q*(C*x{k}-r{k}) + u{k}'*R*u{k};  
        constraints = [constraints, x{k+1} == Ad*x{k}+Bd*u{k}+d];                 
        constraints = [constraints, -1 <= u{k}<= 1];     
    end
    constraints = [constraints, -1<=x{N+1}<=1];                                 
    objective = objective + (C*x{N+1}-r{N+1})'*(C*x{N+1}-r{N+1});

Is there anything else I can try?
Thank you

Johan Löfberg

unread,
Apr 16, 2015, 6:22:13 AM4/16/15
to yal...@googlegroups.com
Your file simulation.m says A,B are the discrete-time system data, and since your controller.m implements exactly the same controller, it only makes sense if the simulink scheme contains a discrete-time ss block which uses that A,B data. Runs perfectly fine herewith that. You seem to fail to understand the difference between a continuous-time model and its discretized version, and where they are used. Either you have continuous-time model which you use in a continuous-time ss block, and the MPC controllers then use the data from the discretized version of that, or you have data which defines the discrete-time model, and you use that in a discrete ss block, and in the MPC definition. You currently mix these things incorrectly

Johan Löfberg

unread,
Apr 16, 2015, 7:04:51 AM4/16/15
to yal...@googlegroups.com
Note thpough that your model is ridiculously hard to control with your settings. Removing all constraints, and it requires a prediction horizon of N=100 to stabilize! That is a sign that something is really weird (sample-time vs open-loop dynamics or something like that). This is also apparent if you add a terminal-state penalty based on LQ stability arguments, which enables you to use short horizons. This weight is in the order of 10^6!

[L,P] = dlqr(Ad,Bd,Cd'*Q*Cd,R)
objective = objective + x{end}'
*P*x{end};

P

   
1.0e+06 *

   
2.3404    0.1233
   
0.1233    0.0123


Johan Löfberg

unread,
Apr 16, 2015, 8:47:16 AM4/16/15
to yal...@googlegroups.com
talking about the continuous-time model here of course

Laura vH

unread,
Apr 16, 2015, 9:20:13 AM4/16/15
to yal...@googlegroups.com
It seems to work now!

The system I have now, is not the system I will eventually work with. It is an example that I got from a paper about an angular positioning system, and I wanted to see if I could reproduce the results. But thank you for noticing and I will take a look at it. 

Thanks for all your help!

Johan Löfberg

unread,
Apr 16, 2015, 9:25:11 AM4/16/15
to yal...@googlegroups.com
and was A,B the discrete or continuous-time data?

Johan Löfberg

unread,
Apr 16, 2015, 9:27:22 AM4/16/15
to yal...@googlegroups.com
answering my self, must be discrete time as two unstable poles on positioning system makes no sense, while the conversion to continuous from given reveals a system with damped integrator, which makes sense

>> tf(d2c(ss(A,B,C,0,.1)))

ans
=
 
 
-0.04219 s + 0.8292
 
-------------------
     s
^2 + 1.054 s


Laura vH

unread,
Apr 16, 2015, 9:28:49 AM4/16/15
to yal...@googlegroups.com
A,B was already the discrete data, so I messed that up indeed. With the discrete SS block it works fine :)
Reply all
Reply to author
Forward
0 new messages