At the end of Part II in our H∞ design trilogy, we addressed the disturbance attenuation problem when the torque disturbance input affected the plant output significantly. A straightforward way to deal with this problem is to push the sensitivity weight further down in low-frequency region. This is not easy to do for a non-minimumphase plant, especialy when a closed-loop bandwidth constraint is also imposed. In the discussion below we propose an already known scheme to tackle the tracking and disturbance attenuation problems separately.
From the problem setup discussion in Part I, we proceed with an example on tracking problem using S/T mixed-sensitivityH∞ synthesis. The plant used in this example is a mechanical revolute joint driven by brushless servomotor in Figure 1, consisiting of joint, drive, and motor dynamics, together with a joint resonance model. This is quite a complicated, non-minimum phase plant that results in a challenging control problem.
After the introduction by George Zames in the late 1970’s, H∞ control has become an active research, with tons of articles published each year. Despite that academic growth, Its usage in practical industry remains minimal. While most control design software has toolbox functions for H∞ synthesis and beyond, the user-unfriendliness of these functions are well-known. It’s fair to say, if you don’t know much about robust control theory, leave them alone. Anyway, in this article we discuss introductory H∞ synthesis in a nutshell, and provide examples using functions and features available in Scilab/Xcos, an open-source alternative to MATLAB/Simulink.
To narrow down the scope, we focus on a particular H∞ scheme called “mixed-sensitivity approach” in . Controller synthesis is formulated as closed-loop transfer function shaping problems, mostly the sensitivity S, complementary sensitivity T, or some combination like KS, where K is the resulting stabilizing controller, hence the name “mixed-sensitivity.” The discussion is restricted to SISO (single-input/single-output) systems. Moreover, we only show the how-to’s and omit the underlying math/theory to save space. Please consult robust control texts xuch as , my all-time favorite on the subject.
Warning : This is an outdated material. It is provided here for reference only. Some links may no longer work.
Coming soon to a computer near you
As an instructor who has been teaching industrial robotic courses for more than 10 years, I know too well the difficulty in explaining, without computer aids, topics such as kinematics in 3-D to students. A simple example about rotating coordinate frames could be hard to visualize and comprehend on a flat whiteboard or paper. As computer technology matures, I continue to look for good software tools to supplement my course. Robotic Toolbox by P.I.Corke stays as my favorite choice for some time in terms of well-written documents, up to date, adaptability, and ease of use. The main obstacle for a developing country like Thailand is that it requires MATLAB/Simulink from The MathWorks, Inc , which is available only on computer networks of major universities. Most Thai students, unfortunately, could not afford even the student version of this proprietary software.
Due to such inconvenience, I have switched to the open-source alternatives, Scilab/Xcos or Scicos, to solve engineering problems and strongly endorse them in my courses. The current version of Scilab (5.3.3 at the time of this writing) is quite stable and professional enough for both academic and industrial uses. I searched for robotic tools for Scilab on the internet and,to my dismay, found only some outdated work that could not be used with newer versions of Scilab. So my first attempt was to port Prof.Corke’s Robotic Toolbox for MATLAB (which from now on I will mention it as “rvctools” for short) to Scilab. I thought it should be painless, a thought that is now proved so wrong! While some basic functions might require only minimal efforts like changing the beginning of comment lines from % to //, that convenience could not apply to the rest. The most challenging ones are perhaps those graphic functions (plotting and animation) that I have to write them virtually from scratch. Another difficulty arises naturally when I realize the current Scilab doesn’t support OOP, while the robot models in rvctools are constructed as MATLAB objects. So doing such cool things like robot.plot( ) is not possible in Scilab.