Based on his experience with traditional machine building, Rockwell Automation Kinetix Motion Control Business product marketing manager, John Pritchard, says: “individual mechanical, control, and electrical design teams work independently to produce separate pieces of the overall machine. Typically, the marriage of the mechanical functions with the control system is not optimal; it is merely sufficient. Mechatronics provides a more effective design approach.”
Over the past two years, much has been said and written about simulation software, project management tools, and collaboration software as aids to mechatronic motion control system design and development. While these tools are an important and potentially critical part of any development project, they can’t compete with good upfront planning and engineering savvy. This project development tutorial shows where software tools and good project management converge, and describes what makes a good mechatronics engineer.
Start with good specifications
Every development project starts with a specification. For a product development project, that specification comes from the marketing or sales department based on customer requirements. When a project involves developing a machine for internal use, the ‘customer’ is the manager of the user department. In either case, the specification always originates with the prospective user, not the developer or system integrator.
When asked how he designs a custom motor for motion applications, Incremotion Associates director, Dan Jones, points out: “I have to know where to start. Basic first questions typically centre on: What can you get out of the motor? What is your strategy? What is the performance direction [in which] you want to go?”
Specifications provided to engineers involved in motion control project design should be somewhat vague, providing enough information to set the correct direction, but not enough detail to inhibit the application of the best solution. For example, a good specification for a material transport system might be:
“Remove parts (description attached) from the output of machine A (description attached) at a rate between Rmin units per minute and Rmax units per minute, and feed them to machine B (description attached). System should have a minimum uptime of Umin, error rate below Emax. Overflow buffer required.”
This specification provides a description of the existing equipment the new machine must interface to, details acceptable performance ranges, and explains the results that the new machine should achieve. What this specification does not do is tell the engineer how to accomplish the result.
A poor specification for the same project might be: “Install a SCARA robot between machines A and B.” This specification fails in three ways. First, it fails to provide quantitative information about the required performance. Second, it fails to provide complete descriptions of the machines to which the SCARA robot is to interface. Third, and perhaps most seriously, it constrains the integrator to providing a SCARA robot, which may or may not be the best solution.
Divide projects into tasks
The first sentence in Julius Caesar’s Commentaries on the Gallic Wars is, “Gallia est omnis divisa in partes tres,” which means “All Gaul is divided into three parts.”
Caesar, being one of the greatest generals in history, knew that you can’t do the whole job at once, and that biting off more than you can chew is a recipe for disaster. Other commentators, including Machiavelli, Sun Tsu, and Lau Tsu have said basically the same thing in various ways, and it has become one of the foundations of modern project management.
So, before doing anything else, developer must divide the project into individual tasks, each of which can be worked on as a unit. Block diagrams provide a means of dividing up an engineering design project.
There are two parts to a block diagram: blocks and the interconnections between them. Blocks represent subsystems or subassemblies that work together to accomplish the whole task. The material handling system described above has three blocks: a means of taking parts from machine A, a means of transporting them to machine B, and a means of feeding to machine B.
Interconnections, usually represented by arrows in the block diagram, transfer something between blocks. That something might be information, physical interactions such as forces or torques, or material objects. Usually, it is some combination of all three.
What makes blocks most useful is the fact that they typically don’t represent single objects, but subsystems. They are black boxes that an engineer can open up to tinker with machinery within, or leave closed to work on the interfaces between them. Of course, a block contains nothing until an engineer opens it up and puts something in.
The process of selecting what to put in begins with listing all available options, then culling out those that clearly don’t fit or are too complicated. If, for example, the output of machine A, and the input to machine B are separated by a quarter of a mile, a SCARA robot is not going to do the job—at least not by itself. A conveyor line probably wouldn’t help either (see “Not your grandfather’s transfer line” in the November 2008 issue of Control Engineering). In fact, an automated guided vehicle (AGV) might be the best bet.
“The behaviour I’d like to see,” Pritchard says, “is where [engineers] start from the basics of what kind of move profile is involved, then, based on the physics, what forces are required. Instead, engineers generally just reach into their design toolbox and grab something they’ve used before.”
That’s a dangerous practice, Pritchard contends.
“If we choose something that is merely sufficient, the outcome will be mediocre. If we select something optimal, the outcome stands a good chance of being remarkable.”
The point at which the engineer determines what to put into the high-level blocks is where traditional engineering disciplines run into problems.
Engineering curricula have, for generations, aimed at turning out highly trained specialists. This was fine as long as designing mechanical systems such as automobile transmissions needed the expertise of mechanical engineers, design of electronic systems such as instrumentation amplifiers required electronics engineers, and design of computer systems required engineers specialising in digital electronics. In today’s mechatronic and motion-control systems, none of those traditional disciplines can do the job.
What is needed at is someone capable of evaluating available options, then making an informed engineering decision: a ‘jack of all trades’ is how Pritchard characterizes the ideal mechatronics engineer.
“He or she needs an understanding of all the different disciplines. They need to have been exposed to mechanical design, as well as automation, and software. In other words, be multi-disciplined,” he says.
Professor Kevin Craig at Marquette University leads a course on mechatronics designed to develop such beasts. Students will spend time on mechanical, electrical, electronic, software, and control theory. Pritchard says, “They’re going to come out understanding the needs and the interaction between all of those different disciplines.”
“Those students,” he continues, “are going to be exactly the type of people we need. and our customers need them, too!”
Use quantitative models
After exhausting all of the qualitative considerations of a motion control project, it’s time to narrow the field with quantitative modelling—even if you’ve already eliminated all but one option.
“A good mechatronics design,” says Pritchard, “should start with a basic physical analysis to guide a designer to choosing the correct mechanism.”
There are two types of quantitative models: dynamical equations and finite element models. Both are applied mathematics techniques, and often both are needed.
Dynamical equations are equations of motion in generalised coordinates which simply extend the idea of coordinate systems beyond simple forward-back, left-right, and up-down. The position of a gear train, for example, is best represented by the angular position of one of the gears or shafts.
The power of analytical models in generalized coordinates is that they involve cross-engineering disciplines. Thinking in terms of generalized coordinates helps one treat the non-mechanical aspects of the model the same as the mechanical aspects. For example, each component of the mechanical system has an angular position associated with it. Each electrical component, however, has a value as well. Each of these variables counts as another generalised coordinate.
Most of the coordinates are coupled by constraint equations, which reduce the number of equations of motion. For example, the torque between the field and armature is proportional to the drive current. The system’s degrees of freedom are the variables remaining when all of the constraints have been taken into account.
Out of some nine generalized coordinates for a rotating-load positioning system, for example, there is only one degree of freedom and one equation of motion governing the entire subsystem’s reaction to a change in the target position:
I ö + 2S = Q å,
where I is the load moment of inertia, S is the shaft stiffness, Q is an auxiliary parameter expressing the system loop gain, is the difference between the load angle and the target angle, and is the angular twist in the shaft.
Note that this equation of motion doesn’t explicitly contain the controlled variable, which is the load orientation. The load orientation in some fixed reference frame means absolutely nothing to the system. All the system cares about is the difference between the actual and target load orientations, and the amount of twist in the shaft.
The equation of motion could be written it in terms of the actual angular positions, but it would look more complicated. The best choice is to solve it using these auxiliary variables, then transform the solution back to absolute coordinates (actual load and target angles).
Another advantage of setting up the equation(s) of motion explicitly is that it allows that greatest of all differential equation solution methods: knowing the answer beforehand. Readers familiar with the equations of vibrating systems will recognize this as a forced harmonic oscillator with no damping. The solution has been well known and studied in detail for centuries.
The form of this equation should immediately send up a red flag for the mechatronic engineer: unless something is done, the system will oscillate around the target position. The seasoned mechatronics engineer will know that there are three possible remedies: add damping, install a notch filter in the feedback loop, or modify the motion profile to cancel the oscillation.
Use numerical models for real world conditions
Knowing the equation of motion and its analytical solution is just the first step. This equation of motion, like those for most real-life machines, is not solvable analytically except under special conditions, such as with no driving input or driving by a sinusoidal input.
To predict the system’s behaviour under real-world conditions, a numerical (computer) model is best. Computer modelling takes the tedious repetitive calculation out of what-if analyses. There are two approaches: numerical solution of the equation(s) of motion and finite element analysis (FEA). Use numerical solutions for general sizing and configuration. Use FEA for detailed analysis of what is going on in the different system components.
Of course, with sufficient time and computer programming expertise, a mechatronics engineer can write a program to solve the equations of motion in a high-level language such as C++. A number of companies, however, provide tools to help users set up and solve equations of motion based on commercial off-the-shelf components. Often, motion-control vendors will provide tools free of charge to help customers select the right components for their project.
“Most of the tools are either global equation approaches, or they’re finite element design programs,“ says Jones. “Tools of both types include excellent examples [to help kick-start an application]. There are probably somewhere between eight and ten software companies supporting different programs.”
Pritchard points out that “this stage is where we try different mechanical approaches, analyse, and then optimise them. Of those different mechanical approaches, there is generally one best candidate.”
“Global equations have a major advantage over finite element at this stage. Although normally not as accurate as finite element, the time saving at the beginning of a design is important. Once I get the design pretty much hammered out, I use finite element to validate it, Jones says.
How do you know whether you’ve got the right answer?
“Well that’s an interesting question. The only way to know is to build it, or compare it to something similar and see if it looks right. That’s one of the things with simulation tools: you can make them fail or succeed by how you set them up. They’re not idiot-proof,” says Jones.
Control Engineering