Robust hinfsyn: add suboptimal synth #1184
Conversation
|
Note that this relaxation works typically OK with LMI based design since you introduce slackness but for Riccati based solvers there are no guarantees that this improves the conditioning of the controllers. This is typically due to the bilinear nature of the problem. It works OK for smooth-enough problems though. |
murrayrm
left a comment
There was a problem hiding this comment.
Thanks for this contribution, @wuschel-brompf. I had a few things that I think should be updated to be consistent with our coding conventions and to provide a bit more information to the user.
Also, we need a unit test that covers the new code.
|
|
||
|
|
||
| def hinfsyn(P, nmeas, ncon): | ||
| def hinfsyn(P, nmeas, ncon, gamTry=None): |
There was a problem hiding this comment.
This parameter name doesn't not follow python-control naming conventions. From the developer notes:
Use longer description parameter names that describe the action or role (e.g., trajectory_constraints and print_summary in optimal.solve_optimal_trajectory.
I suggest something like target_gamma for this parameter name.
| ncon : int | ||
| Number of control inputs (output from controller). | ||
| gamTry : int, optional | ||
| Target performance level (default = None). |
There was a problem hiding this comment.
Although this is consistent with the current very terse docstring, I think a bit more information is needed, either here or in a Notes section later in the docstring. Something like:
If
target_gammais specified, then a controller with the target value of$\gamma$ will be generated. This is potentially suboptimal, but save computation time.
to obtain numerically more robust controllers, usually a slightly suboptimal controller is synthesized after running the first optimization.