www.gusucode.com > control_featured 案例源码程序 matlab代码 > control_featured/TuningValidationExample.m

    %% Validating Results
% This example shows how to interpret and validate tuning results from |systune|.

% Copyright 1986-2012 The MathWorks, Inc.

%% Background
% You can tune the parameters of your control system with |systune| or |looptune|.
% The design specifications are captured using |TuningGoal| requirement objects.
% This example shows how to interpret the results from |systune|, 
%  graphically verify the design requirements, and perform additional
% open- and closed-loop analysis.

%% Controller Tuning with SYSTUNE
% We use an autopilot tuning application as illustration, see the
% _"Tuning of a Two-Loop Autopilot"_ example for details. The tuned 
% compensator is the "MIMO Controller" block highlighted in orange 
% in the model below.

open_system('rct_airframe2')

%% 
% The setup and tuning steps are repeated below for completeness.

ST0 = slTuner('rct_airframe2','MIMO Controller');

% Compensator parameterization
C0 = tunableSS('C',2,1,2);
C0.D.Value(1) = 0;
C0.D.Free(1) = false;
setBlockParam(ST0,'MIMO Controller',C0)

% Requirements
Req1 = TuningGoal.Tracking('az ref','az',1);                  % tracking
Req2 = TuningGoal.Gain('delta fin','delta fin',tf(25,[1 0])); % roll-off
Req3 = TuningGoal.Margins('delta fin',7,45);                  % margins
MaxGain = frd([2 200 200],[0.02 2 200]);
Req4 = TuningGoal.Gain('delta fin','az',MaxGain);  % disturbance rejection

% Tuning
Opt = systuneOptions('RandomStart',3);
rng('default')
[ST1,fSoft] = systune(ST0,[Req1,Req2,Req3,Req4],Opt);

%% Interpreting Results
% |systune| run three optimizations from three different starting points and
% returned the best overall result. The first output |ST| is an |slTuner| interface
% representing the tuned control system. The second output |fSoft| contains
% the final values of the four requirements for the best design.

fSoft

%%
% Requirements are normalized so a requirement is satisfied if and only if
% its value is less than 1. Inspection of |fSoft| reveals that Requirements 1,2,4
% are active and slightly violated while Requirement 3 (stability margins) is
% satisfied. 

%% Verifying Requirements
% Use |viewSpec| to graphically inspect each requirement. This is useful to
% understand whether small violations are acceptable or what causes large 
% violations. First verify the tracking requirement.

viewSpec(Req1,ST1)

%%
% We observe a slight violation across frequency, suggesting that setpoint
% tracking will perform close to expectations. Similarly, verify the 
% disturbance rejection requirement.

viewSpec(Req4,ST1)
legend('location','NorthWest')

%%
% Most of the violation is at low frequency with a small bump near 35 rad/s, 
% suggesting possible damped oscillations at this frequency. Finally, verify 
% the stability margin requirement.

viewSpec(Req3,ST1)

%%
% This requirement is satisfied at all frequencies, with the smallest margins
% achieved near the crossover frequency as expected.

%% Evaluating Requirements
% You can also use |evalSpec| to evaluate each requirement, that is, compute
% its contribution to the soft and hard constraints. For example

[H1,f1] = evalSpec(Req1,ST1);

%%
% returns the value |f1| of the requirement and the underlying 
% frequency-weighted transfer function |H1| used to computed it. 
% You can verify that |f1| matches the first entry of |fSoft| and
% coincides with the peak gain of |H1|.

[f1 fSoft(1) getPeakGain(H1,1e-6)]

%% Analyzing System Responses
% In addition to verifying requirements, you can perform
% basic open- and closed-loop analysis using |getIOTransfer| and |getLoopTransfer|.
% For example, verify tracking performance in the time domain by plotting the
% response |az| to a step command |azref| for the tuned system |ST1|.

T = ST1.getIOTransfer('az ref','az');
step(T)

%%
% Also plot the open-loop response measured at the plant input |delta fin|.
% You can use this plot to assess the classical gain and phase margins at
% the plant input.

L = ST1.getLoopTransfer('delta fin',-1);  % negative-feedback loop transfer
margin(L)
grid


%% Soft vs Hard Requirements
% So far we have treated all four requirements equally in the objective 
% function. Alternatively, you can use a mix of soft and hard constraints
% to differentiate between must-have and nice-to-have requirements. For example,
% you could treat Requirements 3,4 as hard constraints and optimize the first
% two requirements subject to these constraints. For best results,
% do this only after obtaining a reasonable design with
% all requirements treated equally.

[ST2,fSoft,gHard] = systune(ST1,[Req1 Req2],[Req3 Req4]);

%%
fSoft

%%
gHard

%%
% Here |fSoft| contains the final values of the first two requirements
% (soft constraints) and |gHard| contains the final values of the last two
% requirements (hard constraints). The hard constraints are satisfied since
% all entries of |gHard| are less than 1. As expected, the best value of
% the first two requirements went up as the optimizer strived to strictly
% enforce the fourth requirement.

bdclose('all')