[Octave-bug-tracker] [bug #40960] control package: mixsyn delivers lower bandwidth controller than matlab/scilab

[Lukas Reichlin]

Follow-up Comment #2, bug #40960 (project octave):

I discussed the reported issue with Thomas Vasileiou, below is our
conversation. In one sentence, Octave's hinfsyn/mixsyn calculates a suboptimal
controller and Matlab an optimal one, neither of them is "wrong".

Hi Thomas,

I've just received this bug report:

http://savannah.gnu.org/bugs/?40960

What do you think? Is Octave's controller "wrong" at all? Do you have any
ideas what causes this? Could it be related to the fact that my mixsyn
calculates a suboptimal instead of an optimal controller? Frankly I have no
idea …

Best regards,
Lukas


Hi Lukas,

Hope things go well for you.
I know about this problem, it has to do with the implementation of hinfsyn.
The controller octave gives is not "wrong", is just suboptimal, because octave
is asked to do so.
If you want to recover Matlab solution, you have to add the expected minimal
infinity norm in the calculations. Just change the lines for the controller
calculation to:

[K1,mu]=mixsyn(Gss,Wp1,Wu,Wt,2.8);
[K2,mu,info2]=mixsyn(Gss,Wp2,Wu,Wt,3.2);

Then the results for me are equivalent (maybe octave is a little better, but I
did the optimization by hand). Before passing to octave the values 2.8 and
3.2, the resulting automatically assigned norms were 4.5 and 5.3. Try to go a
little lower with the values, and the problem is either unsolvable (you will
get a ricatti equation error, or the controller is unstable).

If you want to have the Matlab behavior, you have try to minimize the norm in
the hinfsyn implementation (I think that is what matlab also is doing).

best Regards,
Thomas


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?40960>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/