Place command provided gain matrix which commands inputs to be too large
Show older comments
When using the place command on a MIMO system I recieve a gain matrix.
When testing this gain matrix output at an operating point where the output should be near zero, the output is far greater (30s).
[A,B,C,D] = linmod('LIN_F16Block_Modded', xeval, ueval);
[K,prec,message] = place(A,B,pp)
I checked that the poles of the closed look system were indeed where I had placed them with:
eig(A-B*K)
The inputs that I expect from:
u = -K*xeval
are an order of magnitude or more lower than the ones I recieve.
I considered this might be due to passing a large A matrix to the place command (18x18), so I reduced it to a 4x4 but the commands provided were still similarly an order of magnitude or more greater than expected.
Am I using the place command wrong? Is the place algorithm ill suited for MIMO systems?
10 Comments
Paul
on 5 Apr 2021
What do you mean by:
"The inputs that I expect from:
u = -K*xeval
are an order of magnitude or more lower than the ones I recieve."
What inputs are you receiving from where?
John Viljoen
on 5 Apr 2021
Paul
on 6 Apr 2021
To be clear on what the problem is ....
The model of the plant in LIN_F16Block_Modded is linearized around the operating point xeval, ueval. Is the operating point an equilibrium point, i.e., when evluated at xeval, ueval are all state derivatives xdot = 0?
The state feedback gain matrix is computed for the linearized model.
The state feedback control is then implemented in the model LIN_F16Block_Modded as u = -K*x?
Then the model is simulated. What are the initial states sent to in this simulation?
Finally, compare the control input u as computed in this simulation to -K * xeval?
Is this the workflow?
John Viljoen
on 6 Apr 2021
Paul
on 7 Apr 2021
Based on this detailed description, the control input at t = 0 should be -K*xeval. If that's not the case then it sounds like there is an error in setting the initial conditions on all of the states in the model, or in the formulation of u = -K*x (like incorrect ordering of the state variables), or both. Of course, as the simulation runs the control input u(t) will evolve in accordance with the closed loop dynamics.
Mathieu NOE
on 7 Apr 2021
hello guys
are we sure that we are not comparing apples and oranges, I mean, when you say that u = -K*xeval , this applies in closed loop , so the closed loop equilibrium point is different from the open loop (another value for xeval , probably much larger, but don't take the open loop value of xeval for predicting what the control would be in closed loop when you do u = -K*xeval ; that's two different scenarios
Paul
on 7 Apr 2021
I'm not sure which comment your responding to, but if you're responding to my comment that precedes yours, I don't see how your comment is any different than mine. I stated that u = -K*xeval is only true at t = 0 based on the OPs statement that the simulation is initialized at x = xeval. As I also stated, u(t) will then evolve in accordance with the closed loop dynamics (which may or may not lead to closed loop equilibrium point depending on the closed loop stability of the system). Are we not saying exactly the same thing?
Mathieu NOE
on 8 Apr 2021
John Viljoen
on 13 Apr 2021
Paul
on 13 Apr 2021
Two comments:
Regarding this statement: " ... at T=0 the closed loop system should be attempting to keep the system at the position it is intialised at ..." I'm not sure about this based on how this problem is described. The pair (xeval, ueval) defines a trim condition. But at T=0 in your closed loop simulation the initial state/input are (xeval/ -K*xeval), which is (likely) not a trim condition. Note that, in general, -K*xeval ~= ueval, so I don't think it is true that at T=0 there should be "zero change to the inputs." From initialization the closed loop dynamics wlll evolve and, if the closed loop is stable, come to steady state at a new trim condition (xfinal, -K*xfinal). Is that not what happens?
Regarding this statement: "When all poles are 'placed' at exactly the same positions that they are already at, ..." I assume this means that the requested closed loop poles are the same as the open loop poles. If so, then it's true that this could be achieved with K = 0. But I suspect that the system in question has more than one control input, so the selection of K is not, in general, unique for a desired set of closed loop poles. Some other restriction has to be applied and the doc page says the algorithm tries to pick K to meet some robustness goals. I don't know whether or not that algorithm typically resutls in "high gain" feedback. The high gain might also just be a consequece of the selection of the closed loop poles relative to the open loop poles.
Answers (0)
Categories
Find more on Tuning Goals in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!