Фон

Можно настроить параметры системы управления с systune или looptune. Технические требования проекта получены с помощью TuningGoal объекты требования. В этом примере показано, как интерпретировать результаты systune, графически проверьте конструктивные требования и выполните дополнительный открытый - и анализ с обратной связью.

Контроллер, настраивающийся с SYSTUNE

Мы используем настраивающее приложение автопилота в качестве рисунка, видим "Настройку примера" Автопилота 2D Цикла для деталей. Настроенный компенсатор является блоком "MIMO Controller", подсвеченным в оранжевом в модели ниже.

open_system('rct_airframe2')

Настройка и настраивающиеся шаги повторяются ниже для полноты.

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);

Final: Soft = 1.51, Hard = -Inf, Iterations = 52
Final: Soft = 1.15, Hard = -Inf, Iterations = 87
Final: Soft = 1.15, Hard = -Inf, Iterations = 70
Final: Soft = 1.16, Hard = -Inf, Iterations = 120

Интерпретация результатов

systune запустите три оптимизации от трех различных начальных точек, и возвратил лучший полный результат. Первый выход ST slTuner интерфейс, представляющий настроенную систему управления. Второй выход fSoft содержит окончательные значения этих четырех требований для лучшего проекта.

fSoft

fSoft =

    1.1476    1.1476    0.5461    1.1476

Требования нормированы так, требованию удовлетворяют, если и только если его значение меньше 1. Контроль fSoft показывает, что Требования 1,2,4 активны и немного нарушенные, в то время как Требованию 3 (запасы устойчивости) удовлетворяют.

Проверка требований

Используйте viewGoal графически смотреть каждое требование. Это полезно, чтобы понять, приемлемы ли маленькие нарушения или что вызывает большие нарушения. Сначала проверьте требование отслеживания.

viewGoal(Req1,ST1)

Мы наблюдаем небольшое нарушение через частоту, предполагая, что отслеживание заданного значения выполнит близко к ожиданиям. Точно так же проверьте требование подавления помех.

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

Большая часть нарушения в низкой частоте с маленьким ударом около 35 рад/с, предлагая возможные ослабленные колебания на этой частоте. Наконец, проверьте требование по запасу устойчивости.

viewGoal(Req3,ST1)

Этому требованию удовлетворяют на всех частотах с самыми маленькими полями, достигнутыми около частоты среза как ожидалось.

Оценка требований

Можно также использовать evalGoal чтобы оценить каждое требование, то есть, вычисляют его вклад в мягкие и трудные ограничения. Например,

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

возвращает значение f1 из требования и базовой взвешенной частотой передаточной функции H1 используемый к вычисленному это. Можно проверить тот f1 совпадает с первой записью fSoft и совпадает с пиковым усилением H1.

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

ans =

    1.1476    1.1476    1.1476

Анализ откликов системы

В дополнение к проверке требований можно выполнить основной открытый - и анализ с обратной связью с помощью getIOTransfer и getLoopTransfer. Например, проверьте производительность отслеживания во временном интервале путем графического вывода ответа az к команде шага azref для настроенной системы ST1.

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

Также постройте ответ разомкнутого цикла, измеренный во входе delta fin объекта. Можно использовать этот график оценить классические запасы по амплитуде и фазе во вход объекта.

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

Мягкий по сравнению с трудными требованиями

До сих пор мы обработали все четыре требования одинаково в целевой функции. В качестве альтернативы можно использовать соединение мягких и трудных ограничений, чтобы дифференцироваться между обязательными и хорошими, чтобы требованиями. Например, вы могли обработать Требования 3,4 как трудные ограничения и оптимизировать первые два требования, удовлетворяющие этим ограничениям. Для лучших результатов сделайте это только после получения разумного проекта со всеми требованиями, обработанными одинаково.

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

Final: Soft = 1.29, Hard = 0.99959, Iterations = 140

fSoft

fSoft =

    1.2898    1.2898

gHard

gHard =

    0.4674    0.9996

Здесь fSoft содержит окончательные значения первых двух требований (мягкие ограничения) и gHard содержит окончательные значения последних двух требований (трудные ограничения). Трудным ограничениям удовлетворяют начиная со всех записей gHard меньше 1. Как ожидалось оптимальное значение первых двух требований повысилось, когда оптимизатор стремился строго осуществить четвертое требование.

bdclose('all')