The future of mechatronics

Citation

Billingsley, J. (2004), "The future of mechatronics", Assembly Automation, Vol. 24 No. 4. https://doi.org/10.1108/aa.2004.03324daa.002

The future of mechatronics

The future of mechatronics

John Billingsley University of Southern Queensland, Queensland, Australia.

Keywords: Mechatronics

That mechatronics has a future is as certain as that breathing has a future! What is in question is the way in which it will be regarded as it merges with the mainstream of engineering.

Many engineers (particularly the civils!) still see it as an amalgam of diverse disciplines, but for over a decade it has been clear that the art of blending electronics, control theory and software with enough mechanical hardware to give body to the product is a discipline in itself.

What is perhaps overlooked is the special nature of the “component subjects” required by the mechatronic specialist. Some years ago I presented “A mechatronic cynic's view of control theory”. Electrical engineers cut their teeth on the brew of complex variables, Laplace transforms and exponentials that they need to analyse filters and electrical feedback. Not surprisingly, they see control as an extension of this theory. All too many mechatronics courses allow the electronic engineers to “own” the subject.

But mechatronic control is a thoroughly non- linear art. Motors have drive saturation and mechanical struts break if overstressed. Aircraft that bank at too great an angle has a tendency to upset the passengers. Any attempt to linearise such variables and limitations will lead to an erroneous and often dangerous design.

Mechanical engineers are weaned on a diet of finite element analysis. Discrete-time simulation is but a small step from this and simple code allows the system to be represented in all its non-linear glory. Control strategies can be examined that give systems that are not even stable!

Stability is the Holy Grail of the conventional control theorist. But a bang-bang controller that vibrates the tool-piece in a limit cycle within a fraction of a millimetre of the target is surely preferable to a “robust” linear controller that allows the tool-piece to be deflected several centimetres before the controller applies full restoring force.

Fuzzy control embraces non-linear algorithms – but tends to come with a bag and baggage of its methodology that obscures the real nature of the decisions being made. As I have often said, the whole of control can be summed up in a nutshell, “To decide what values should be applied to the inputs right now, in the light of all available measurements and their history”. Anything further is embroidery.

My point is that the teaching of mechatronics demands an alternative approach to control theory, rooted in simulation and only drawing on frequency domain techniques for the verification of the controller design.

Another leg of mechatronics, the analysis of the end-effector motion, is well served by techniques drawn from the kinematics taught to mechanical engineers. Denavit-Hartenberg matrices give a “crank the handle” technique for forward kinematics, though some ingenuity is called for to deal with inverse kinematics. When we come to control manipulators, Jacobeans can offer some successive approximation alternatives that can give useful strategies.

It would be possible to get a bit more philosophical about DH. It enables the 3 × 3 rotation matrix to be combined with a 3 × 1 translation vector to give a 4 × 4 matrix which fits into the “accepted methodology” of matrix multiplication. This involves adding a useless bottom row for the sole purpose of “making the algebra work”.

In computing terms, the DH matrix can perhaps revert to a “structure”, combining its rotational and translational components with a “method” to chain them together. This is not a dramatic advance, since for calculating positional coordinates the DH matrix multiplications are very convenient as they stand. However, it has been suggested that the methodology could be extended to embrace structural compliance, forces and couples. For this, an alternative algebraic shorthand would be useful.

The bedrock of mechatronics must surely be the embedding of software, not merely to analyse the product during its design but to give it its character and usefulness. Many designers have learned the hard way that software is very fragile – touch it and it has a habit of falling to pieces.

Late in 1992, I was invited to give a lecture in Hong Kong sponsored by HK Telecom. I felt an obligation to base it on a telecommunications theme, not my specialty, so I borrowed an idea from the “seven layer ISO model” that was still a topic of discussion at the time. It was not easy to find my ancient notes, buried in a corner of the hard drive of a machine I no longer use.

A robot system can also be considered in layers:

• •

  project layer;

• •

  task layer;

• •

  purpose layer;

• •

  intention layer;

• •

  action layer;

• •

  reflex layer; and

• •

  physical layer.

The physical level includes “muscles” (motors and actuators) and kinaesthetic (position, tacho, force, pressure) sensors.

At the reflex level, the information from the kinaesthetic sensors is used to control the actuators. The function of the reflex level is to reduce uncertainty, resisting disturbing forces and achieving a state which corresponds to the action command signal.

The action signal represents the target position, force or velocity (or any combination) of a single actuator. This might be one axis of a robot manipulator, or one joint of a walking mechanism.

Intention represents the target position, force vector or velocity of a member governed by a group of actuators. An example of intention is the attitude of one leg of a walking robot.

As used in the development of the wall-climbing Robug II, commands include instructions such as:

• •

  lift foot;

• •

  position foot; and

• •

  press foot against wall.

A purpose is a sequence of linked actions such as “take a step”. Actions within a purpose may be modified to correct previous disturbances.

A task is a chain of purposes, such as:

• •

  walk to this destination; and

• •

  move object from A to B.

Correct execution of a task will usually involve the integration of signals from sensors of attitude, location and environment.

At the top of the pyramid is the Project, which may invoke tasks in a variety of ways dependent on the outcome of previous tasks measured against a general objective, such as:

• •

  find any leak;

• •

  collect a variety of rocks; and

• •

  mow the lawn.

or for a Micromouse or Bilby,

• •

  find the fastest path to the centre of the maze.

With a need to relate closely between code and the movement of “real things”, the designer of software for mechatronics might often be at odds with the more general slaves of the byte-mill. IT students seem to be taught that it is smart to use cumbersome identifiers such as DebugSetProcessKillOnExit (and that is one of the shorter and clearer ones). Engineers probably find it more efficient to think in monosyllables.

Rather than lines of code that represent instructions to “do something” such as a “print” command, the IT vogue is to equate a property to the string to be output and trust that some concurrent process will attend to it – such as

• •

  Form:CommObject:Output = value

The mechatronic programmer must surely prefer a near-English command with a “verb” in it, such as

• •

  Bend frontleft, knee, angle

when trying to choreograph the legs of a robot!

To be even-handed, I should take a swipe at electrical engineering. However, the fundamentals of voltage, current and power stand unchallenged. The intricacies of network analysis can also escape blame, because their relevance to the attentions of the mechatronics engineer is limited, to put it mildly.

When a complete computer can be purchased as a chip for a few dollars and as a fully populated board for a few tens, delving into the intricacies of the logic circuit for a look-ahead carry will leave the mechatronic engineer unmoved. What is relevant and important is the art of voltage-level shifting, the avoidance of earth loops and the addition of the odd transistor to an H-bridge to prevent an inadvertent software command causing a smoking disaster.

So, perhaps I should after all be critical, since I am sure that Thevenin, Norton, Schottky, Eccles, Jordan and even Fermi will all be dragged into the electricians' party when they are invited to address mechatronics students.

Mechatronics certainly has a future, but it may not be a smooth one. The present habit of borrowing tutorial material from other disciplines seems to be basically flawed. Mechatronics needs to embrace the “traditional” specialisations as facets of its own broad nature, developing its own way to teach them with insight into the fundamentals that draw them together.

In a very short time, the rival branches of engineering and IT might start to do the borrowing.