# Robust Control Toolbox Release Notes

## R2016a

New Features, Bug Fixes, Compatibility Considerations

#### Control system tuning tools moved to Control System Toolbox

A Robust Control Toolbox™ license is no longer required to use the `systune` or `looptune` commands or to use Control System Tuner. You can now:

• Tune control systems modeled in MATLAB® (tunable `genss` models) with a Control System Toolbox™ license.

The following still requires a Robust Control Toolbox license:

• `hinfstruct` command

• Robust tuning of control systems with parameter uncertainty using `systune`, `looptune`, or Control System Tuner

#### Functionality being removed or changed

`a`, `b`, `c`, `d`, and `e` properties of `uss` models.Still works`A`, `B`, `C`, `D`, and `E` respectively.If your code uses any of these properties, consider modifying your code to use the new property names.
`cpmargin`Still works`ncfmargin`If your code uses `cpmargin`, modify it to use `ncfmargin` instead.

## R2015b

New Features, Bug Fixes, Compatibility Considerations

#### Robust Tuning with `systune` Command or Control System Tuner App: Automatically tune controllers to maximize performance over a range of parameter values

Control System Tuner and the `systune` command now tune control systems for robustness against real parameter uncertainty in the plant. You represent parameter uncertainty in your control system model using uncertain real parameters `ureal` or `uss`. The software automatically finds the worst combinations of parameter values and tunes the controller to maximize performance over the parameter uncertainty range.

In MATLAB, build a generalized state-space (`genss`) model of your control system using `ureal` or `uss` blocks to represent real parameter uncertainty in the plant. You can tune the model with `systune` or in Control System Tuner exactly as you would for a tunable control system model without uncertainty. For a detailed example, see Robust Tuning of Positioning System.

In Simulink, use linearization with block substitution to replace one more blocks in the model with uncertain values represented by `ureal` or `uss` objects. (Requires Simulink Control Design software.) See Robust Tuning of Mass-Spring-Damper System.

In both cases, when you tune the model, the software automatically adjusts the tunable components to achieve the specified performance as well as possible throughout the uncertainty range. Analysis plots automatically display random samples of the uncertain system to give you a visual sense of the performance variation.

#### Compatibility Considerations

Previously, when you used `systune` to tune a model that had uncertainties, the software would set the uncertain blocks to their nominal values before tuning the system. Now, `systune` tunes the model for robustness against those uncertainties. To recover the old behavior, i.e., to tune a controller for the nominal system only, use `getNominal` to obtain the nominal value. For example:

`[CL,fSoft,GHard,info] = systune(getNominal(CL0),SoftReqs,HardReqs);`

In this example, `CL0` is a `genss` model containing uncertain blocks.

#### Gain Scheduling with `systune` and `slTuner`: Automatically tune the Lookup Table and Interpolation blocks used to model gain-scheduled controllers in Simulink

You can now use the `slTuner` interface to automatically tune control systems modeled in Simulink in which plant dynamics change with operating conditions or time. (Requires Simulink Control Design software.)

In such gain-scheduled control systems, the controller gains vary as a function of one or more scheduling variables. In the Simulink model, use the Lookup Table or Interpolation blocks to implement the variable controller gains. You then use the new `tunableSurface` command to parameterize the dependency of these gains on the scheduling variables. The software automatically tunes the coefficients of that parameterization so that the control system meets the tuning requirements you specify over the entire grid of scheduling-variable values. The software also writes the tuned coefficients back to the Lookup Table or Interpolation blocks.

In previous releases, you could not parameterize Lookup Table or Interpolation blocks in terms of the functional form of its dependence on the scheduling variable. As a result, you could not automatically tune a gain-scheduled control element and write the tuned coefficients back to the Simulink model. Using `systune` to tune and implement gain-scheduled controllers required a complex process of manually extracting coefficient values and inserting them in the blocks.

For examples showing how to use `tunableSurface` to tune gain-scheduled controllers implemented with Lookup Table blocks, see:

#### `tunableSurface` Object: Parameterize and tune gain-scheduled controllers using improved workflow

The new `tunableSurface` object lets you express gain in terms of tunable parameters for tuning gain-scheduled controllers with `systune`. In such gain-scheduled control systems, the controller gains vary as a function of one or more scheduling variables. You parameterize the dependency of controller gains on the scheduling variables. The software automatically tunes the coefficients of that parameterization so that the control system meets the tuning requirements you specify over the entire grid of scheduling-variable values. `tunableSurface` replaces the `gainsurf` command.

In previous releases, you could use the `gainsurf` command to represent tunable surfaces for control system tuning. With that command, you had to explicitly supply the values of the gain surface calculated over the grid of design points. `tunableSurface` simplifies that workflow by allowing you to specify the gain surface in terms of functions of the scheduling variables, such as the basis functions of a polynomial expansion.

For more details about creating tunable gain surfaces, see:

#### Compatibility Considerations

`tunableSurface` replaces `gainsurf`, which was used in previous releases to parameterize controller gains as functions of scheduling variables. `gainsurf` still works, but might be removed in a future release. If you have scripts or functions that use `gainsurf`, consider updating them to use `tunableSurface` instead.

#### `getNominal` command for extracting nominal value of uncertain model

Use `getNominal` to replace the uncertain elements of a generalized model with their nominal values. All other control design blocks in the generalized model are unchanged. For example, suppose that `M` is a generalized state-space (`genss`) model that has both uncertain blocks and tunable blocks. The command `getNominal(M)` returns a `genss` model having the same tunable blocks as `M`.

For more information, see the `getNominal` reference page.

#### `usample` samples uncertain blocks and preserves other control design blocks

The `usample` command now preserves any non-uncertain control design blocks when you use it to sample the uncertain elements of a generalized model. For example, suppose that `M` is a generalized state-space (`genss`) model that has both uncertain blocks and tunable blocks. The command `usample(M,N)` samples the uncertain blocks, and returns an array of `genss` models having the same tunable blocks as `M`.

#### Compatibility Considerations

Previously, when applied to models having tunable control design blocks, `usample` used the current (nominal) value of those blocks, and returned an array of numeric models. To recover the previous behavior, use `getValue`. For example, the following command randomly samples the uncertain blocks of `M`, replaces the tunable blocks of `M` with their current values, and returns an array of numeric state-space models.

`Msamp = getValue(usample(M,N));`

#### New property for limiting maximum frequency in random samples of `ultidyn`

Use the `SampleMaxFrequency` property of `ultidyn` to limit the natural frequency of dynamics when you take random samples of `ultidyn` blocks. For example, the following command creates SISO uncertain dynamics.

`dH = ultidyn('dH',[1 1],'SampleMaxFrequency',1);`

When you take random samples of `dH`, such as with `usample`, the dynamics of the samples are no faster than 1 rad/s. The default value of `SampleMaxFrequency` is `Inf` (no limit).

Also, the `SampleStateDim` property of `ultidyn` is changed to `SampleStateDimension`.

#### Compatibility Considerations

The property name `SampleStateDim` still works, but might be removed in a later release. If you have scripts or functions that use `SampleStateDim`, consider updating them to use `SampleStateDimension` instead.

#### Functionality being removed or changed

`systune(CL0,...)` where `CL0` contains uncertain blocksTunes robustly against real parameter uncertainty in `CL0``systune(getNominal(CLO),...)`Previously, `systune` used the nominal value of all uncertain blocks in the tuned model. Now, use `getNominal` explicitly to tune for the nominal system only. See Robust Tuning with `systune` Command or Control System Tuner App: Automatically tune controllers to maximize performance over a range of parameter values.
`gainsurf`Still works`tunableSurface`If you have scripts or functions that use `gainsurf`, consider updating them to use `tunableSurface` instead. See `tunableSurface` Object: Parameterize and tune gain-scheduled controllers using improved workflow
`usample(M,N)`Samples uncertain control design blocks of `M`, and preserves other control design blocks`getValue(usample(M,N))`Previously, `usample` used the current value of non-uncertain control design blocks. See `usample` samples uncertain blocks and preserves other control design blocks
`SampleStateDim` property of `ultidyn`Still works`SampleStateDimension`Consider replacing `SampleStateDim` with `SampleStateDimension`.

## R2015a

New Features, Bug Fixes

#### Robust tuning of controller parameters against a set of plant models specified through parameter variations in Control System Tuner app

When you use Control System Tuner to tune a Simulink model of a control system, you can now generate multiple plant models by varying model parameters. You can then tune the control system to satisfy your specified tuning goals for all the resulting models.

Tuning to multiple models is useful to help ensure that the tuned control system is robust against parameter variations or changes in operating conditions. For example, if a parameter in your Simulink model represents a process temperature, you can generate multiple models spanning the range of expected temperature variations, and tune your control system to meet your design requirements for all those models at once.

For more information about tuning control systems for multiple models in Control System Tuner, see Robust Tuning Using Multiple Plant Models in Control System Tuner. For an example showing how to specify parameter variations for tuning with Control System Tuner, see Tuning Control System with Multiple Valued Plant Parameters using Control System Tuner.

#### Open Control System Tuner app with saved session from command line

Use the new syntax `controlSystemTuner(sessionfile)` to open Control System Tuner and load data from a saved session. When you use Control System Tuner, you can click Save Session to save session data to disk such as tuning goals you have created, response I/Os you have defined, operating points, and stored designs. The string `sessionfile` is the name of a session data file saved in the current working directory or on the MATLAB path. The software also opens the Simulink model associated with the saved session.

## R2014b

New Features, Bug Fixes, Compatibility Considerations

#### Quick Loop Tuning option in Control System Tuner app for tuning control systems to target loop bandwidth and stability margins

Quick Loop Tuning lets you use a loop-shaping approach to tune SISO or MIMO feedback loops in Control System Tuner. You can use Quick Loop Tuning to tune control systems modeled in MATLAB or Simulink. With Quick Loop Tuning you can tune your system to meet target gain crossover and margin requirements without explicitly creating tuning goals that capture these requirements. You specify feedback loops to tune by selecting the control signals and measurement signals in a block diagram of your control system. Control System Tuner adjusts the tunable parameters of your system such that the open-loop gain crossover falls within the desired frequency range with the gain and phase margins you specify.

For more information about using Quick Loop Tuning, see Quick Loop Tuning of Feedback Loops in Control System Tuner.

#### Tuning goals for automated tuning to meet transient response and disturbance rejection requirements

New tuning goals let you explicitly specify a target transient response or a minimum disturbance rejection in a tuned control system. These tuning goals are available both in Control System Tuner and at the command line when tuning with `systune`.

The transient response goal lets you shape how the closed-loop system responds to a specific input signal. You specify the desired transient response as a reference model. The target transient response is the response of the reference model to an impulse, step, ramp, or custom input signal. To use the transient response goal:

• In Control System Tuner, in the Tuning tab, in the New Goal menu, select ```Transient Response Matching```.

• At the command line, specify the design requirement using `TuningGoal.Transient`.

The step rejection goal lets you specify a minimum standard for rejecting disturbances. You specify characteristics such as the maximum amplitude and settling time of the response at some point in your control system to a step disturbance injected at another point in the system. Alternatively, specify a reference system whose response to step input is the target response. To use the step rejection goal:

• In Control System Tuner, in the Tuning tab, in the New Goal menu, select ```Rejection of Step Disturbances```.

• At the command line, specify the design requirement using `TuningGoal.StepRejection`.

#### MATLAB code generation from Control System Tuner app for automatically scripting control system tuning tasks

You can now generate a MATLAB script for control system tuning from Control System Tuner. Generated MATLAB scripts are useful when you want to programmatically reproduce a result you obtained interactively. You can also use generated code to perform multiple tuning operations with systematic variations in tuning configurations such as model operating point or tuning goals.

#### Enhanced constraints on controller dynamics for control system tuning

New functionality gives you more flexibility when specifying constraints on controller dynamics for control system tuning. The following new features are available in both Control System Tuner using Controller Poles Goal and when tuning at the command line using `TuningGoal.ControllerPoles` (formerly `TuningGoal.StableController`).

• You can now specify a minimum damping constant for the poles of a tunable block. Previously, the damping constant of controller poles could take any value between zero and 1.

• You can now specify a negative value for the minimum decay rate of controller poles, allowing for unstable controllers. Previously, the minimum decay rate had to be positive, and therefore always enforced the stability of the constrained block.

• Fixed integrators in the constrained tunable block are no longer considered when evaluating the constraint. In other words, the tuning goal now constrains locations of all poles in the block except fixed integrators, such as the I term in a PID controller.

#### Compatibility Considerations

`TuningGoal.StableController` has been renamed to `TuningGoal.ControllerPoles`. Scripts and functions that use `TuningGoal.StableController` do not generate errors. However, `TuningGoal.StableController` will not be maintained in future releases. You should replace instances of `TuningGoal.StableController` in your code with `TuningGoal.ControllerPoles`.

#### New syntax in TuningGoal.Poles for directly specifying constraints on dynamics

When you use `TuningGoal.Poles` to constrain the dynamics of a tuned control system, you can now directly specify the minimum decay rate, minimum damping, and maximum natural frequency when you create the tuning goal. To do so, use the following syntaxes:

```R = TuningGoal.Poles(MinDecay,MinDamping,MaxFreq); R = TuningGoal.Poles(Location,MinDecay,MinDamping,MaxFreq);```

Previously, to specify such constraints on controller dynamics, you had to first create the tuning goal, and then modify its `MinDecay`, `MinDamping`, and `MaxFrequency` properties.

For more information, enter see the `TuningGoal.Poles` reference page.

#### TuningGoal.StepResp renamed to TuningGoal.StepTracking

The tuning requirement `TuningGoal.StepResp` is now called `TuningGoal.StepTracking`.

#### Compatibility Considerations

Scripts and functions that use `TuningGoal.StepResp` do not generate errors. However, `TuningGoal.StepResp` will not be maintained in future releases. You should replace instances of `TuningGoal.StepResp` in your code with `TuningGoal.StepTracking`.

#### DisturbanceInput property of TuningGoal.Rejection renamed to Location

The `DisturbanceInput` property of the tuning requirement `TuningGoal.Rejection` is now called `Location`, to unify the names of similar properties of several tuning requirements. If `Req` is a `TuningGoal.Rejection` requirement, you can access this property using `Req.Location`.

#### Compatibility Considerations

Scripts and functions that use the `DisturbanceInput` property do not generate errors. However, the `DisturbanceInput` property will not be maintained in future releases. You should replace instances of `DisturbanceInput` in your code with `Location`.

#### Functionality being removed or changed

FunctionalityWhat Happens When You Use This Functionality?Use This InsteadCompatibility Considerations
`TuningGoal.StableController`Still works`TuningGoal.ControllerPoles`Consider replacing `TuningGoal.StableController` with `TuningGoal.ControllerPoles`.
`TuningGoal.StepResp`Still works`TuningGoal.StepTracking`Consider replacing `TuningGoal.StepResp` with `TuningGoal.StepTracking`.
`DisturbanceInput` property of `TuningGoal.Rejection`Still works`Location` propertyConsider replacing `DisturbanceInput` with `Location`.

## R2014a

New Features, Bug Fixes, Compatibility Considerations

#### Control System Tuner app for automated tuning of control systems

The new Control System Tuner lets you interactively tune SISO or MIMO control systems modeled in MATLAB or Simulink. Control System Tuner tunes the control system parameters to meet design requirements you specify, such as reference tracking, disturbance rejection, stability margins, loops shapes, and sensitivity. You can examine multiple system responses in both the time and frequency domains to evaluate performance of the tuned control system.

If you have Simulink Control Design software, you can tune a control system represented by a Simulink model. Control System Tuner can tune most blocks used to create a control system in Simulink. These blocks include `Gain`, `PID Controller`, ```Transfer Fcn```, `State-Space`, `Zero-Pole`, ```Discrete Filter```, and the `LTI System` block. Any controller architecture created using these blocks can be tuned. To access Control System Tuner for tuning a Simulink model, select Analysis > Control Design > Control System Tuner.

Control System Tuner can also tune a control system represented by a tunable `genss` model. Any control architecture constructed with Control Design Blocks such as `ltiblock.pid`, `ltiblock.tf`, or `realp` blocks can be tuned. To open Control System Tuner for tuning a control system modeled in MATLAB, use the `controlSystemTuner` command.

#### Step response and LQG requirements for control system tuning with `systune` and `looptune` commands

New `TuningGoal` requirement objects allow you to specify tuning objectives for automated tuning of control systems with `systune` and `looptune`.

• `TuningGoal.StepResp` — Requires that the step response between specified locations in the control system match the step response of a specified reference system. For details about this requirement, see the `TuningGoal.StepResp` reference page.

• `TuningGoal.LQG` — Specifies a linear-quadratic-gaussian (LQG) goal for control system tuning. This requirement lets you quantify control performance as an LQG cost. For details about this requirement, see the `TuningGoal.LQG` reference page.

#### Improvements to `TuningGoal` requirements for control system tuning

This release introduces a variety of improvements to `TuningGoal` requirement objects for automated tuning of fixed-structure control systems with `systune` and `looptune`.

### Tuning Goals for constraining dynamics impose implicit stability constraints

`TuningGoal.StableController` and `TuningGoal.Poles` now impose implicit stability constraints on controller or system dynamics. This allows you to require poles of the controller or the closed-loop control system to be stable, without necessarily limiting the minimum decay or maximum frequency of those poles. Previously, you had to specify finite values for minimum decay and maximum frequency when using these tuning goals.

#### Compatibility Considerations

The default values of the `MinDecay` and `MaxFrequency` properties of these requirements have changed. If you have scripts that use `TuningGoal.StableController` or `TuningGoal.Poles` requirements with default values, update those scripts to explicitly set the finite values you want.

PropertyPrevious Default ValueNew Default Value

`TuningGoal.Poles.MinDecay`

`TuningGoal.StableController.MinDecay`

`1e-6``0`

`TuningGoal.Poles.MaxFrequency`

`TuningGoal.StableController.MaxFrequency`

`1e6``Inf`

`TuningGoal.Poles.MinDamping`

`1e-6``0`

### Option to limit dynamics constraint to poles in a particular feedback loop

A new syntax for creating the `TuningGoal.Poles` requirement allows you to constrain only the poles of the sensitivity function measured at a specified location. Use this syntax to narrow the scope of the requirement to a particular feedback loop.

For example, suppose you have a cascaded-loop control system in which the inner and outer loops contain loop-opening locations `'InnerLoop'` and `'OuterLoop'`, respectively. The following command uses the new syntax to constrain the poles of the inner loop sensitivity function:

```Req = TuningGoal.Poles('InnerLoop'); Req.MinDamping = 0.5; Req.Openings = 'OuterLoop';```

`Req` imposes a minimum damping on the poles of the inner loop sensitivity function measured with the outer loop open. The dynamics of blocks that do not participate to the inner loop are ignored.

For more information about using this constraint, see the `TuningGoal.Poles` reference page.

### `TuningGoal.Tracking` allows specification of peak error

A new syntax for creating the `TuningGoal.Tracking` requirement allows you to specify a maximum tracking error for a particular input-output pair in terms of a response time, a relative DC error, and a peak relative error across all frequencies. These parameters are converted to the following expression for the maximum tracking error:

`$\text{MaxError}=\frac{\left(\text{PeakError}\right)s+{\omega }_{c}\left(\text{DCError}\right)}{s+{\omega }_{c}}.$`

For more information about how to specify tracking error requirements, see the `TuningGoal.Tracking` reference page.

### Specification of signal scaling in MIMO closed-loop Tuning Goals

New properties in several closed-loop Tuning Goals allow you to specify the relative amplitudes of multiple input and output signals in the loops constrained by the requirements. Use these properties to reduce cross-coupling in tuned systems when the choice of units results in a mix of small and large signals.

• `TuningGoal.Tracking` and `TuningGoal.Overshoot` now have an `InputScaling` property. This information is used to scale the off-diagonal terms in the transfer function from reference to tracking error. This scaling ensures that cross-couplings are measured relative to the amplitude of each reference signal.

• `TuningGoal.Gain` and `TuningGoal.Variance` now have `InputScaling` and `OutputScaling` properties. The values you set for these properties are used to scale the closed-loop transfer function T(s) on which you impose the tuning requirement. The requirement is evaluated for the scaled transfer function Do–1T(s)Di. Do and Di are diagonal matrices formed from the `OutputScaling` and `InputScaling` property, respectively.

For more information on how to interpret and use these properties, see the reference pages for the Tuning Goals.

### Option to remove stability constraint from loop-shape and gain-limiting Tuning Goals

The new `Stabilize` property of loop-shaping and gain-limiting Tuning Goals allows you turn off the implicit closed-loop stability constraint. If stability for the specified loop is not required or cannot be achieved, set `Stabilize` to `false` to relax the stability constraint.

This property is available for the following Tuning Goals:

For more information on how to use the `Stabilize` property, see the reference pages for the Tuning Goals.

### `ScalingOrder` property added to `TuningGoal.Margins`

The `TuningGoal.Margins` tuning goal has a new property, `ScalingOrder`. This property controls the number of states in the diagonal scalings involved in computing MIMO stability margins. Increasing the order may improve results at the expense of increased computations.

Previously, this scaling order was set as a tuning option in `systuneOptions`.

#### Compatibility Considerations

If you have scripts that use the `ScalingOrder` option of `systuneOptions`, set the `ScalingOrder` property of `TuningGoal.Margins` instead.

#### Improved control system tuning of Simulink models with `systune` or `looptune` functions using `slTuner` interface (with Simulink Control Design)

Use the new `slTuner` interface for tuning control systems in Simulink models. This interface replaces `slTunable`. The `slTuner` interface allows you to:

• Tune model blocks and subsystems to meet tuning goals using the `systune` and `looptune` functions.

• Perform robust tuning of a controller against a set of plant models using `systune`. You can configure an `slTuner` interface to vary model parameter values and operating points. When you call `systune` for the interface, the software returns a control system that satisfies the tuning goals for all the specified model variations.

• Validate the controller design by examining the transfer function for relevant I/O sets using the `getIOTransfer`, `getLoopTransfer`, `getSensitivity`, and `getCompSensitivity` functions.

`slTuner`, similar in design to `slLinearizer`, simplifies I/O management in the controller tuning and validation workflow. You specify signals of interest as analysis points. You can use these analysis points to configure design requirements and specify linearization inputs/outputs when you extract transfer functions.

For more information on command-line tuning of Simulink models with `slTuner`, see:

#### Compatibility Considerations

The `slTunable` interface will continue to work for backward compatibility. However, only the `slTuner` interface will be supported and enhanced in future releases. Therefore, adoption of the `slTuner` interface is strongly recommended.

For documentation of the `slTunable` interface, see `slTunable` in the R2013b documentation.

## R2013b

New Features, Bug Fixes, Compatibility Considerations

#### Automatic tuning of gain-scheduled control systems with `systune` and `looptune` commands

You can now use `systune` and `looptune` to automatically tune control systems in which plant dynamics change with operating conditions or time. In such gain-scheduled control systems, the controller gains vary as a function of one or more scheduling variables. You parameterize the dependency of controller gains on the scheduling variables. The software automatically tunes the coefficients of that parameterization so that the control system meets the tuning requirements you specify over the entire range of plant operating conditions. The new `gainsurf` command helps you parameterize your controller gains as functions of scheduling variables.

Several new examples illustrating the workflow for gain-scheduled tuning, including:

#### Automatic tuning of discrete-time control systems with `systune` and `looptune` commands

You can now use `systune` and `looptune` for automatic tuning of discrete-time control systems. This capability includes both:

• Control systems represented by discrete-time generalized LTI models (`genss` models with `Ts` property not equal to zero).

• Control systems represented by an `slTunable` interface to a Simulink mode. Set the `Ts` property of the `slTunable` interface to the sampling time at which you want to linearize the model.

To tune a discrete-time control system, use the same procedure and command syntax and you use to tune a continuous-time control system. For examples of discrete-time tuning, see:

#### Sensitivity, overshoot, minimum and maximum loop gain requirements for control system tuning with `looptune` and `systune`

New `TuningGoal` requirement objects allow you to specify a variety of tuning objectives for automated tuning of fixed-structure control systems with `systune` and `looptune`. New tuning requirements include:

Additionally, `TuningGoal.LoopShape` has two new syntaxes. These syntaxes allow you to specify a target crossover frequency or range of crossover frequencies for an open-loop response in your control system.

For more information about these `TuningGoal` requirement objects see the reference pages for each requirement object, and:

#### `looptuneSetup` command for switching from `looptune` to `systune` to use additional `systune` functionality

The new `looptuneSetup` command provides a bridge between the tuning commands `looptune` and `systune`. `looptuneSetup` takes the argument list for `looptune` and constructs an equivalent argument list for `systune`. The `looptuneSetup` command is valid for systems represented in either MATLAB or Simulink.

You can use this command to switch from `looptune` to `systune` to take advantage of the additional flexibility and functionality of `systune`. For example, `looptune` requires that you tune all channels of a MIMO feedback loop to the same target bandwidth. Converting to `systune` allows you to specify different crossover frequencies and loop shapes for each loop in your control system. Also, `looptune` treats all tuning requirements as soft requirements, optimizing them but not requiring that any constraint be exactly met. Converting to `systune` allows you to enforce some tuning requirements as hard constraints, while treating others as soft requirements.

You can also use `looptuneSetup` to probe into the tuning requirements that `looptune` implicitly imposes. When you use `looptune`, you specify a target loop bandwidth and stability margins. `looptune` expresses these as hard and soft tuning constraints, specified as `TuningGoal` objects. You can use `looptuneSetup` to examine these constraints. After examining the constraints, you can then alter them and pass them to `systune` for further tuning.

#### `hinfnorm` command for computing H∞ norm

The new `hinfnorm` command computes the H norm of SISO or MIMO systems. For SISO systems, the H norm is defined as the largest value of the frequency response magnitude. For MIMO systems, H norm is the largest singular value across frequencies.

For more information, see the `hinfnorm` reference page.

#### Some properties of `TuningGoal` requirements renamed

The following properties of `TuningGoal` requirement objects are renamed to better reflect their purpose and uses:

ObjectPrevious Property NameNew Property Name
`TuningGoal.LoopShape``LoopTransfer``Location`
`TuningGoal.Margins``LoopTransfer``Location`
`TuningGoal.Tracking``ReferenceInput``Input`
`TuningGoal.Tracking``TrackingOutput``Output`

#### Compatibility Considerations

If you have scripts or functions that use any of these properties, consider updating your code to use the new property names instead. Using the previous property names does not generate an error in this release, but the names might be removed in a future release.

#### Power iteration method option for structured singular value computation with `mussv`

A new `'p'` option to the `mussv` command allows you to specify a power iteration method for computing the lower bound on structured singular values (μ values). This method is recommended for cases of complex uncertainty. When at least one of the uncertain blocks specified in the block diagonal matrix structure is complex, `mussv` now uses the power iteration method by default.

For pure real uncertainty, `mussv` uses a gain-based lower bound algorithm by default.

For more information, see the `mussv` reference page.

#### Compatibility Considerations

Previously, `mussv` used a gain-based lower bound algorithm for both pure real and mixed uncertainty. Therefore, you might now obtain different results for the lower bounds with mixed uncertainty.

#### Option to specify feedback sign for stability margin calculation with `ncfmargin`

The `ncfmargin` command includes a new input argument that lets you specify the sign of the feedback interconnection assumed for the margin calculation. Use the syntax ```[marg,freq] = ncfmargin(P,C,sign)``` or `[marg,freq] = ncfmargin(P,C,sign,tol)` to specify a negative or positive feedback interconnection. For more information, see the `ncfmargin` reference page.

#### Compatibility Considerations

Previously, the relative accuracy `tol` was the third input argument to `ncfmargin`. If you have scripts or functions that use the syntax ```[marg,freq] = ncfmargin(P,C,tol)```, update them to use ```[marg,freq] = ncfmargin(P,C,-1,tol)``` instead.

## R2013a

New Features, Bug Fixes, Compatibility Considerations

#### Minimum damping requirement for closed-loop poles in `TuningGoal.Poles` object

You can now specify the minimum damping ratio of closed-loop poles for automated tuning of fixed-structure control systems with `systune` or `looptune`. To do so, create a `TuningGoal.Poles` object and set its `MinDamping` property to the minimum damping ratio you want to specify. Additionally, you can now use the `Focus` property to limit enforcement of the `TuningGoal.Poles` requirements to poles within a specified frequency range.

For more information about the `TuningGoal.Poles` requirement, see the `TuningGoal.Poles` reference page. For more information about using requirement objects to tune control systems, see Using Design Requirement Objects.

#### `TuningGoal.Rejection` object for specifying disturbance rejection requirement

You can now specify a disturbance rejection requirement for automated tuning of fixed-structure control systems with `systune` or `looptune`. The new `TuningGoal.Rejection` object allows you to specify a frequency-dependent attenuation factor for a disturbance injected at a specified location in the control system.

For more information about the `TuningGoal.Rejection` requirement, see the `TuningGoal.Rejection` reference page. For an example, see PID Tuning for Setpoint Tracking vs. Disturbance Rejection.

For more information about using requirement objects to tune control systems generally, see Using Design Requirement Objects.

#### `looptune` returns detailed results from multiple random starts

The `info` output of `looptune` now includes detailed results from each optimization run. When you use the `RandomStart` option of `looptuneOptions` to perform multiple optimization runs, the field `info.Runs` of the `info` output now contains a `struct` array. Each entry in the `struct` array includes results from the corresponding optimization run such as minimum constraint values and tuned block values. You can optionally use this information to analyze independent optimization results.

See the `looptune` reference page for more information.

#### Compatibility Considerations

The `Extra` field of `info` is now renamed to `Runs`. If you use `info.Extra` in a script, update your code to use `info.Runs` instead.

New examples in this release include:

## R2012b

New Features, Bug Fixes, Compatibility Considerations

#### `systune` command for multiobjective tuning with soft and hard constraints

The new `systune` command allows automated tuning of fixed-structure control systems to high-level tuning objectives.

To use `systune`, you specify tuning objectives such as reference tracking, disturbance rejection, or stability margins. You can specify both soft requirements (objectives) and hard requirements (constraints). `systune` automatically tunes the parameters of your control system to meet the requirements.

You can use `systune` to tune control systems modeled in either MATLAB or Simulink.

#### H2 performance, stability margin, pole location, and disturbance rejection requirements

New `TuningGoal` requirement objects allow you to specify a variety of tuning objectives for automated tuning of fixed-structure control systems with `systune` and `looptune`. New tuning requirements include:

For more information about these `TuningGoal` requirement objects see the reference pages for each requirement object, and:

#### Robust tuning of one controller against a set of plant models

The new `systune` command can simultaneously tune the parameters of multiple models or control configurations. This feature allows you, for example, to tune a single controller against a range of plant models, to help ensure that the tuned control system is robust against parameter variations. As another example, you can tune for reliable control by simultaneously to multiple plant configurations that represent different failure modes of a system. In either case, `systune` finds values for tunable parameters that best satisfy the specified tuning objectives for all models.

#### Option to constrain tuned parameter values and to restrict some tuning requirements to a frequency band

You can now optionally impose lower and upper bounds on tunable parameters when tuning fixed-structure control systems using `systune`, `looptune`, or `hinfstruct`. For example, you can constrain a gain to always be positive, or impose a maximum value on a filter time constant.

To impose bounds on tunable parameters, set the `Maximum` and `Minimum` properties of the parameter in the corresponding Control Design Block. For example, create a scalar gain block and constrain the gain to be positive:

```gainblock = ltiblock.gain('gainblock',1,1); gainblock.Gain.Minimum = 0;```

Then, use `gainblock` as a component in a tunable `genss` model of the control system. When you tune the control system, the tuning command enforces the constraint.

Additionally, you can limit the range of frequencies in which almost any `TuningGoal` requirement is enforced for fixed-structure control system tuning with `systune` or `looptune`. The only exceptions are `TuningGoal.Variance` and `TuningGoal.WeightedVariance`.

For example, you can enforce a stability margin requirement in a frequency band extending for one decade on each side of the target gain crossover frequency.

To limit the range of frequencies in which a requirement is enforced, use the `Focus` property of the `TuningGoal` requirement object. For example, create a requirement that limits the gain from an input `du` to an output `u` to 10. Limit enforcement of the requirement to the frequency range 10–1000 rad/s.

```Req = TuningGoal.Gain('du','u',10); Req.Focus = [10 1000];```

#### `ltiblock.pid2` and `loopswitch` objects for tuning two-degree-of-freedom PID controllers and marking loop opening sites for open-loop requirements

New Control Design Blocks in Control System Toolbox allow you to specify more control structures and more types of constraints for fixed-structure control system tuning in MATLAB:

• `ltiblock.pid2` — Tunable two-degree-of-freedom PID controller

• `loopswitch` — Control Design Block for specifying feedback loop opening locations in a tunable `genss` model of a control system

For more information, see the `ltiblock.pid2` and `loopswitch` reference pages.

#### `TuningGoal.MaxGain` and `GainLimit` property renamed

The tuning requirement `TuningGoal.MaxGain` is now called `TuningGoal.Gain`. Additionally, the `GainLimit` property of that tuning requirement is now called `MaxGain`.

For more information, see the `TuningGoal.Gain` reference page.

#### Compatibility Considerations

Replace instances of `TuningGoal.MaxGain` in your code with `TuningGoal.Gain`. Replace references to the `GainLimit` property with `MaxGain`.

#### Options in `hinfstructOptions` and `looptuneOptions` renamed or removed

The following options in `hinfstructOptions` and `looptuneOptions` are changed:

• `SpecRadius` is now called `MaxFrequency`. Additionally, `NaN` is no longer a supported value for this option. For an unconstrained `MaxFrequency` value, use `Inf`.

• `StableOffset` is now called `MinDecay`.

• `StableRadius` option has no effect.

• `StableExclude` option of `hinfstructOptions` has no effect. `hinfstruct` now automatically excludes from stability tests Control Design Blocks such as weighting functions or multipliers. These blocks do not affect the closed-loop stability of the actual control system to tune.

For more information about these options, see the `hinfstructOptions` and `looptuneOptions` reference pages.

#### Compatibility Considerations

If you use any of the affected options in your code, update your code to reflect the current names and supported values.

## R2012a

New Features, Bug Fixes

#### Parallel Computing Support for looptune and hinfstruct

If you have Parallel Computing Toolbox™ software installed, you can use parallel computing to speed up tuning of fixed-structure control systems with the `looptune` or `hinfstruct` commands. When you run multiple randomized `looptune` or `hinfstruct` optimization starts, parallel computing speeds up tuning by distributing the optimization runs among MATLAB workers.

For more information about using parallel computing to speed up `looptune` or `hinfstruct` tuning, see:

For more information about tuning fixed-structure control systems with `looptune` or `hinfstruct`, see Tuning Fixed Control Architectures in the Robust Control Toolbox documentation.

#### Faster and More Accurate H-infinity Norm Computation Using SLICOT Algorithms

H norm calculations now use the SLICOT library of numerical algorithms. These algorithms improve the speed and accuracy of functions such as `hinfstruct` and `looptune`.

## R2011b

New Features, Bug Fixes, Compatibility Considerations

#### looptune Tunes Fixed-Structure Control Systems

Use `looptune` to tune fixed-structure control systems to meet your requirements. To use `looptune`, specify design requirements such as loop bandwidth, stability margin, setpoint tracking, or target loop shape. `looptune` automatically tunes the parameters of your controller to meet the specified requirements.

The requirements objects `TuningGoal.MaxGain`, `TuningGoal.Tracking`, and `TuningGoal.LoopShape` let you express your design requirements directly. You do not have to first convert them to weighting functions or mathematical constraints on an optimization problem.

You can use `loopview` to validate the performance the performance of the tuned control structure against your specified design requirements.

For more information, see Tuning Fixed Control Architectures and the `looptune` and `loopview` reference pages.

#### Control System Tuning for Simulink Models with looptune or hinfstruct Using slTunable Interface

If you have Simulink Control Design software, you can use tuning commands, such as `slTunable.looptune` and `hinfstruct`, to tune control systems modeled in Simulink. The `slTunable` object provides an interface between your Simulink model and these commands.

Use `slTunable` to specify information about your control structure and parametrization. `slTunable` also automates tasks such as linearizing the Simulink model, parametrizing the tunable blocks of your system, and applying tuned parameter values to the model. After you create and configure an `slTunable` object for your control architecture, you can tune the control system using `slTunable.looptune` or `hinfstruct`.

For more information, see Tuning Fixed Control Architectures and the following demos:

#### wcgainplot for Visualizing Worst-Case Gains

`wcgainplot` plots the nominal, sampled, and worst-case gains of uncertain systems as a function of frequency. Use `wcgainplot` for visual analysis of uncertain systems.

For more information, see the `wcgainplot` reference page.

#### Functionality Being Removed or Changed

FunctionalityWhat Happens When You Use This Functionality?Use This InsteadCompatibility Considerations
`umat` object can no longer contain `ultidyn` or `udyn` uncertainty.
• Presence of `ultidyn` or `udyn` uncertain elements forces model type to `uss` or `ufrd` rather than `umat`.

• Mixing `ureal` or `ucomplex` models with `udyn` or `ultidyn` objects produces `uss` instead of `umat`.

Expect a model type of `uss` or `ufrd` instead of `umat` when working with `udyn` or `ultidyn` uncertain elements.Update code to work with `uss` or `ufrd` instead of `umat` when `udyn` or `ultidyn` elements are present.
`uss(sys_frd)`, where `sys_frd` is a `frd` model object no longer converts `sys_frd` to `ufrd`.Errors.`ufrd(sys_frd)`.Replace `uss(sys_frd)` with `ufrd(sys_frd)`.
`ufrd(udat,freq,...)` no longer constructs an uncertain `frd` model from the `umat` object `udat`. Converts `udat` to a `ufrd` object with frequencies `freq`.Use `frd(udat,freq,...)` to construct an uncertain `frd` model from the `umat` object `udat`.Replace `ufrd(udat,freq,...)` with `frd(udat,freq,...)`.
`frd(sys_uss,w)` where `sys_uss` is a `uss` model. Warns; returns `frd` model containing data based on nominal response of `sys_uss`.`ufrd(sys_uss,w)` to obtain a `ufrd` model.Replace `frd(sys_uss,w)` with `ufrd(sys_uss,w)`.
Nominal value of `ultidyn` object.Nominal value is `ss` model object.None.Update code to work with `ss` model objects when working nominal value of `ultidyn`.
`usubs`.Applied to array of uncertain models, default substitution is `'-once'`.Use `'-batch'` to perform batch substitution on uncertain model arrays.Replace `usubs(...)` with `usubs(...,'-batch')`.
`usubs(M,{a1;a2;...},{v1;v2;...})` returns error.`usubs(M,a1,v1,a2,v2,...)`.Replace `usubs(M,{a1;a2;...},{v1;v2;...})` with `usubs(M,a1,v1,a2,v2,...)`.
`usample(sys,'a',na,'b',nb)` where uncertain element `b` does not exist in `sys`.Returns `na`-by-`nb` array with constant values across `nb` dimension, instead of `na`-by-1 array.None.Update code to reflect correct dimensionality.
`wcgopt`.Still runs.`wcgainOptions` or `wcmarginOptions`.Replace `wcgopt` with `wcgainOptions` or `wcmarginOptions`.
`robuststab` and `robustperf`.For `ufrd` models, `BadUncertainValues` field of `Info` output returns `Nf`-by-1 struct array, where `Nf` is the number of frequency points.None.Update code to work with `Nf`-by-1 struct array for `BadUncertainValues` instead of `Nf`-by-1 cell array.
For nominally unstable models, performance margin is zero (instead of a negative value).None.Update code to reflect correct performance margin .
`robopt`.Still runs.`robuststabOptions` or `robustperfOptions`.Replace `robopt` with `robuststabOptions` or `robustperfOptions`.
`actual2normalized`.First output argument is normalized uncertain block value. The second output argument is normalized distance between block value and nominal value.`[NV,ndist] = actual2normalized(BLK,AV)`.Use second output argument `ndist` for normalized distance.
`reshape(unc_sys,S)`.`S` does not include the I/O size of the models in the array `unc_sys`. For example, if `unc_sys` is a 6-by-1 array of 2-output, 4-input models, ```reshape(unc_sys,[2 3])``` converts `unc_sys` to a 2-by-3 array.None.Remove I/O size dimensions from `reshape` on uncertain model arrays.
`diag(uss_sys)` where `uss_sys` is a `uss` model.Errors.None.Remove `diag(uss_sys)`.

## R2011a

New Features, Bug Fixes

#### Enhanced Workflow for H-Infinity Synthesis of Fixed-Structure Control Systems

New Generalized LTI models in Control System Toolbox allow you to model control systems with tunable parameters. Using these models simplifies controller tuning with `hinfstruct`. You can model a closed-loop transfer function, including tunable parameters, as a generalized state-space (`genss`) model and directly tune the parameters to minimize the closed-loop gain. The `hinfstruct` command can tune any fixed-structure SISO or MIMO control system using H synthesis techniques.

Additionally, new `realp` and `genmat` objects let you create parametric expressions. You can use such expressions to create custom tunable components. For example, you can define a low-pass filter parametrized by its cutoff frequency, or an observer-based controller parametrized by the state-feedback and observer gains.

For more information about creating tunable Generalized LTI models, see Models with Tunable Coefficients in the Control System Toolbox User's Guide.

For more information about H tuning with `hinfstruct`, see Tuning Fixed Control Architectures in the Robust Control Toolbox Getting Started Guide.

For examples of designing controllers for several different architectures using `hinfstruct`, see the following updated and new demos:

## R2010b

New Features, Bug Fixes

#### New Commands for H-Infinity Synthesis of Fixed-Structure Control Systems

New commands in this release allow you to tune fixed-structure SISO and MIMO control systems using the techniques of H synthesis.

The new `hinfstruct` command lets you use the frequency-domain methods of H synthesis to tune control systems with a broad range of architectures and controller structures. For example, you can tune:

• Fixed-order, fixed-structure controllers, such as pure gains, PID controllers, or fixed-order transfer function or state-space models

• Single feedback-loop architectures with multiple tunable elements, such as a PID controller plus a filter

• Multiple feedback-loop architectures with multiple tunable elements

Specify the tunable elements of your system using the new parametrized Control Design blocks `ltiblock.gain`, `ltiblock.pid`, `ltiblock.tf`, and `ltiblock.ss`.

For examples of designing controllers for several different architectures using `hinfstruct`, see the following new demos:

For more information, see Tuning Fixed Control Architectures in the Robust Control Toolbox Getting Started Guide.

Bug Fixes

## R2009b

New Features, Bug Fixes, Compatibility Considerations

#### New Option to Improve Robust Performance by Accounting for Real Uncertain Parameters

You can now improve robust performance by accounting for real uncertain parameters when designing controllers using µ-synthesis. The user-defined options you use in the `dksyn` command now includes a new option `MixedMU`. Set this option to `'on'` to account for real uncertain parameters in your system. For more information, see the `dkitopt`, and `dksyn` reference pages.

#### New Command to Linearize Simulink Models with Uncertainty

If you have Simulink Control Design software installed, you can take model uncertainty into account when linearizing a Simulink model. You can then use the resulting uncertain linearized model (`uss` object) to perform linear analysis and robust control design.

If your model already contains Uncertain State Space blocks, use the new `ulinearize` command to obtain an `uss` model. If you want to account for uncertainty in your linear analysis without using Uncertain State Space blocks, you can specify individual Simulink blocks to linearize to an uncertain variable. For more information, see "Computing Uncertain State-Space Models from Simulink Models" in the Robust Control Toolbox User's Guide.

#### New Interface for Simulating Effects of Uncertainty in Simulink Models

This version of the product provides a new interface to simulate the effects of uncertainty in Simulink models. The interface includes the following:

• Uncertain State Space block to specify uncertain system in Simulink. You should replace USS System blocks in your existing models with the Uncertain State Space block. To do so, run the `slupdate` command on your models.

• `ufind` command to extract all uncertain variables from a Simulink model.

• `usample` command to generate random values of these uncertain variables.

For more information on simulating the effects of uncertainty using the new interface, see "Simulating Effects of Uncertainty" in the Robust Control Toolbox User's Guide.

#### New Command to Model Multiple LTI Responses as One Uncertain System

This version of the product includes a new `ucover` command that lets you model a family of LTI responses as one uncertain system. For more information, see the `ucover` reference page.

#### New and Updated Demos

The following new and updated demos illustrate use of the new features:

To access the demos, type

`demo('toolbox','robust control')`

#### Functions, Properties and Blocks Being Removed

Function, Property or Block Name

What Happens When You

Use Function or Property?

Compatibility Considerations

`usiminfo`

Still runs

`ufind`

`usimfill`

Still runs

`ufind`

`usimsamp`

Still runs

`usample`

USS System block

Still runs

Uncertain State Space` `block

`ltiarray2uss`

Still runs

ucover

Bug Fixes

Bug Fixes

## R2008a

New Features

#### Ability to Use LOOPMARGIN with Simulink

This version of Robust Control Toolbox software lets you analyze the robustness of nonlinear Simulink models using the LOOPMARGIN command.

If you have the Simulink Control Design product installed, you can perform stability margin analysis of a Simulink model by passing the model name and a point within that model to the LOOPMARGIN command.

## R2007b

No New Features or Changes

## R2007a

New Features

• USS System — This Robust Control Toolbox version introduces a new Simulink block, USS System. You can use this block to import uncertain systems into Simulink models.

• Multiplot Graph — Plot multiple signals in one figure.

## R2006b

New Features

#### New Function ltiarray2uss

This Robust Control Toolbox version introduces a new function, `ltiarray2uss`. This function constructs an uncertain state-space model from an LTI array.

## R2006a

No New Features or Changes

## R14SP3

No New Features or Changes

## R14SP2

New Features

#### mussvunwrap Is Renamed

`mussvunwrap` has been renamed. It is now called `mussvextract`.

#### New Functions actual2normalized and normalized2actual

This Robust Control Toolbox version introduced two new functions: