main content

multi-凯发k8网页登录

this example shows how to use looptune to tune a multi-loop controller for a 6-dof robotic arm manipulator.

robotic arm model and controller

this example uses the six degree-of-freedom robotic arm shown below. this arm consists of six joints labeled from base to tip: "turntable", "bicep", "forearm", "wrist", "hand", and "gripper". each joint is actuated by a dc motor except for the bicep joint which uses two dc motors in tandem.

figure 1: robotic arm manipulator.

the file "cst_robotarm.slx" contains a simulink model of the electrical and mechanical components of this system.

open_system("cst_robotarm");

figure 2: simulink model of robotic arm.

the "controller" subsystem consists of six digital pi controllers (one per joint). each pi controller is implemented using the "2-dof pid controller" block from the simulink library (see pid tuning for setpoint tracking vs. disturbance rejection example for motivation). the control sample time is ts=0.1 (10 hz).

figure 3: controller structure.

typically, such multi-loop controllers are tuned sequentially by tuning one pid loop at a time and cycling through the loops until the overall behavior is satisfactory. this process can be time consuming and is not guaranteed to converge to the best overall tuning. alternatively, you can use systune or looptune to jointly tune all six pi loops subject to system-level requirements such as response time and minimum cross-coupling.

in this example, the arm must move to a particular configuration in about 1 second with smooth angular motion at each joint. the arm starts in a fully extended vertical position with all joint angles at zero except for the bicep angle at ninety degrees. the end configuration is specified by the angular positions: turntable = 60 deg, bicep = 80 deg, forearm = 60 deg, wrist = 90 deg, hand = 90 deg, and gripper = 60 deg.

press the "play" button in the simulink model to simulate the angular trajectories for the pi gain values specified in the model. you can first double-click on the blue button to also show a 3d animation of the robotic arm. the angular responses and the 3d animation appear below. clearly the response is too sluggish and imprecise.

figure 4: untuned response.

linearizing the plant

the robot arm dynamics are nonlinear. to understand whether the arm can be controlled with one set of pi gains, linearize the plant at various points (snapshot times) along the trajectory of interest. here "plant" refers to the dynamics between the control signals (outputs of pid blocks) and the measurement signals (output of "6 dof robot arm" block).

snapshottimes = 0:1:5;
% plant is from pid outputs to robot arm outputs
linios = [...
   linio('cst_robotarm/controller/turntablepid',1,'openinput'),...
   linio('cst_robotarm/controller/biceppid',1,'openinput'),...
   linio('cst_robotarm/controller/forearmpid',1,'openinput'),...
   linio('cst_robotarm/controller/wristpid',1,'openinput'),...
   linio('cst_robotarm/controller/handpid',1,'openinput'),...
   linio('cst_robotarm/controller/gripperpid',1,'openinput'),...
   linio('cst_robotarm/6 dof robot arm',1,'output')];
linopt = linearizeoptions('sampletime',0);  % seek continuous-time model
g = linearize('cst_robotarm',linios,snapshottimes,linopt);
size(g)
6x1 array of state-space models.
each model has 6 outputs, 6 inputs, and 19 states.

plot the gap between the linearized models at t=0,1,2,3,4 seconds and the final model at t=5 seconds.

g5 = g(:,:,end);  % t=5
g5.samplinggrid = [];
sigma(g5,g(:,:,2:5)-g5,{1e-3,1e3}), grid
title('variation of linearized dynamics along trajectory')
legend('linearization at t=5 s','absolute variation',...
       'location','southwest')

while the dynamics vary significantly at low and high frequency, the variation drops to less than 10% near 10 rad/s, which is roughly the desired control bandwidth. small plant variations near the target gain crossover frequency suggest that we can control the arm with a single set of pi gains and need not resort to gain scheduling.

tuning the pi controllers with looptune

with looptune, you can directly tune all six pi loops to achieve the desired response time with minimal loop interaction and adequate mimo stability margins. the controller is tuned in continuous time and automatically discretized when writing the pi gains back to simulink. use the sltuner interface to specify which blocks must be tuned and to locate the plant/controller boundary.

% linearize the plant at t=3s
tlinearize = 3;
% create sltuner interface
tunedblocks = {'turntablepid','biceppid','forearmpid',...
               'wristpid','handpid','gripperpid'};
st0 = sltuner('cst_robotarm',tunedblocks,tlinearize);
% mark outputs of pid blocks as plant inputs
addpoint(st0,tunedblocks)
% mark joint angles as plant outputs
addpoint(st0,'6 dof robot arm')
% mark reference signals
refsignals = {...
   'ref select/tref',...
   'ref select/bref',...
   'ref select/fref',...
   'ref select/wref',...
   'ref select/href',...
   'ref select/gref'};
addpoint(st0,refsignals)

in its simplest use, looptune only needs to know the target control bandwidth, which should be at least twice the reciprocal of the desired response time. here the desired response time is 1 second so try a target bandwidth of 3 rad/s (bearing in mind that the plant dynamics vary least near 10 rad/s).

wc = 3;  % target gain crossover frequency
controls = tunedblocks;      % actuator commands
measurements = '6 dof robot arm';  % joint angle measurements
st1 = looptune(st0,controls,measurements,wc);
final: peak gain = 0.957, iterations = 10
achieved target gain value targetgain=1.

a final value near or below 1 indicates that looptune achieved the requested bandwidth. compare the responses to a step command in angular position for the initial and tuned controllers.

t0 = getiotransfer(st0,refsignals,measurements);
t1 = getiotransfer(st1,refsignals,measurements);
opt = timeoptions; opt.iogrouping = 'all'; opt.grid = 'on';
stepplot(t0,'b--',t1,'r',4,opt)
legend('initial','tuned','location','southeast')

the six curves settling near y=1 represent the step responses of each joint, and the curves settling near y=0 represent the cross-coupling terms. the tuned controller is a clear improvement, but there is some overshoot and the bicep response takes a long time to settle.

exploiting the second degree of freedom

the 2-dof pi controllers have a feedforward and a feedback component.

figure 5: two degree-of-freedom pid controllers.

by default, looptune only tunes the feedback loop and does not "see" the feedforward component. this can be confirmed by verifying that the $b$ parameters of the pi controllers remain set to their initial value $b=1$ (type showtunable(st1) to see the tuned values). to take advantage of the feedforward action and reduce overshoot, replace the bandwidth target by an explicit step tracking requirement from reference angles to joint angles.

tr = tuninggoal.steptracking(refsignals,measurements,0.5);
st2 = looptune(st0,controls,measurements,tr);
final: peak gain = 0.766, iterations = 13
achieved target gain value targetgain=1.

the 2-dof tuning eliminates overshoot and improves the bicep response.

t2 = getiotransfer(st2,refsignals,measurements);
stepplot(t1,'r--',t2,'g',4,opt)
legend('1-dof tuning','2-dof tuning','location','southeast')

validating the tuned controller

the tuned linear responses look satisfactory so write the tuned values of the pi gains back to the simulink blocks and simulate the overall maneuver. the simulation results appear in figure 6.

writeblockvalue(st2)

figure 6: tuned angular responses.

the nonlinear response of the bicep joint noticeably undershoots. further investigation suggests two possible culprits. first, the pi controllers are too aggressive and saturate the motors (the input voltage is limited to ± 5 v).

figure 7: input voltage to dc motors (control signal).

second, cross-coupling effects between the wrist and bicep, when brought to scale, have a significant and lasting impact on the bicep response. to see this, plot the step response of these three joints for the actual step changes occurring during the maneuver (-10 deg for the bicep joint and 90 degrees for the wrist joint).

h2 = t2([2 4],[2 4]) * diag([-10 90]);  % scale by step amplitude
h2.u = {'bicep','wrist'};
h2.y = {'bicep','wrist'};
step(h2,5), grid

refining the design

to improve the bicep response for this specific arm maneuver, we must keep the cross-couplings effects small relative to the final angular displacements in each joint. to do this, scale the cross-coupling terms in the step tracking requirement by the reference angle amplitudes.

jointdisp = [60 10 60 90 90 60];  % commanded angular displacements, in degrees
tr.inputscaling = jointdisp;

to reduce saturation of the actuators, limit the gain from reference signals to control signals.

ur = tuninggoal.gain(refsignals,controls,6);

retune the controller with these refined tuning goals.

st3 = looptune(st0,controls,measurements,tr,ur);
final: peak gain = 1.13, iterations = 202

compare the scaled responses with the previous design. notice the significant reduction of the coupling between wrist and bicep motion, both in peak value and total energy.

t2s = diag(1./jointdisp) * t2 * diag(jointdisp);
t3s = diag(1./jointdisp) * getiotransfer(st3,refsignals,measurements) * diag(jointdisp);
stepplot(t2s,'g--',t3s,'m',4,opt)
legend('initial 2-dof','refined 2-dof','location','southeast')

push the retuned values to simulink for further validation.

writeblockvalue(st3)

the simulation results appear in figure 8. the bicep response is now on par with the other joints in terms of settling time and smooth transient, and there is less actuator saturation than in the previous design.

figure 8: angular positions and control signals with refined controller.

the 3d animation confirms that the arm now moves quickly and precisely to the desired configuration.

figure 9: fine-tuned response.

see also

| | |

related topics

    网站地图