Chapter 1 — Introduction
Mechatronics
Model-based design, simulation,
realization, and test
David A. Haessig, PhD and Matthew Domier
Introduction
Mechatronics Systems
In their first refereed journal on the subject of Mechatronics, the Institute of Electrical and Electronic Engineers (IEEE) and American Society of Mechanical Engineers (ASME) jointly defined Mechatronics as:
“the synergistic combination of precision mechanical engineering, electronic control, and systems thinking in the design of products and manufacturing processes.”
Wikipedia offers a similar definition as:
“a multidisciplinary field of science that includes a combination of mechanical engineering, electronics, computer engineering, telecommunications engineering, systems engineering and control engineering.”
The mechatronics engineer must be armed with knowledge which exceeds that offered by many legacy mechanical, electrical, or computer engineering curriculums. This new multi-disciplinary field has developed out of the need by industry for engineers capable of developing systems that are increasingly complex and broad in content. Such systems can combine electronics for signal measurement, mechanical elements having moving parts, linkages, hydraulic drives, etc., actuators, and computational hardware for the realization of control processes. Computer engineering is required for the automatic generation of the embedded controller code, both software and VHDL, and for simulation of dynamic performance.
Mechatronics system design seeks to synergistically design a system as a whole, to optimize performance and cost while accounting for the complex interaction between the mechanical, electrical, and computational subsystems being integrated.
A block diagram of a generic mechatronic system is given Figure 1-1. Across the top of the diagram is the physical plant, and across the bottom, the digital controller and user interface.
The plant consists primarily of the electromechanical system providing the operational functionality that is desired of the system. Examples include a motor and load, a robot arm, an automobile, and an unmanned aerial system (UAS). It can also be a purely electronic device such as a laser printer with an electromagnetically actuated droplet jet. (In that case, having no mechanical parts, the designation as a mechatronic system might be considered a misnomer; however the concepts developed here and thru this text still apply.) The model of the plant may include models of the control effectors driving the system, i.e. the actuators driving the system, and the sensor being used to transducer the physical states and/or signals that are being measured and fed back to through the controller. The dynamic effects added by these components and their consideration in system modeling and simulation are topics sometimes omitted or glossed over in controls texts. Ignoring them is ok if these components introduce nonlinear effects, noise sources and/or dynamic effects which are negligible. However when they are not, models of these effects must be included in the dynamic models used for simulation.
Outputs from sensors may be in analog or digital in form. In the case of the analog, there are typically anti-alias filters that preprocess the signals prior to analog-to-digital (A/D) conversion. In the case in which the signal is already digital in nature, it may be possible to sample this digital signal directly (in the case of a discrete bus), or it may require further digital processing depending on the interface; for example in the case of an incremental encoder the binary signals must be counted and converted to a count representing angle (see Chapter 7).
The Digital Controller portion of the mechatronic system receives the conditioned signals at sampling rate TS and sends this to a controller, also typically executing once every TS intervals of time. These are processed within some type of computation engine, which can range from the 8-bit micro-controller, to the Digital Signal Processor (DSP), to a Field-Programmable-Gate-Array (FPGA), etc. Implementation using FPGAs will be the subject of several examples described in Chapter 6 – Controller Realization. The controller output sample values are converted back to analog form or remain digital for direct digital interfacing to the actuator.
Disturbances and external command inputs may affect performance. In general, the disturbance input is an unwanted external input that is unknown. For example, the torque applied to a steerable antenna as the result of vibration is a disturbance input. These disturbances are undesired. An objective of the feedback controller is therefore to reduce sensitivity to disturbances, such that they have an acceptable effect. Command inputs, on the other hand, are known signals that serve as reference signals or setpoints that the system is to respond to, or track.
Systems Engineering and Model-Based Design
Model-based design techniques and methods have been developing rapidly over the last several years and are being applied ever more frequently in the development of control systems, embedded computations, and mechatronic systems in general. A model-based design differs from a design process considered to be more “traditional” in that it involves a common dynamic model that is used across the various phases of the development process1. Thus, this model serves as the basis for performance simulation, analysis and the associated design choices, serving also in defining the code which is created by automatic code-generation engines, and serving as the basis for performance verification testing. Hyperlinks from text-based system requirements to the model also allow that same model to connect directly to the requirements values that the model is to assess. Thus, as requirements change or are added, these changes are piped directly into the model. Also, as information is learned about the system being controlled, it is fed back into the model to improve its accuracy, enabling a better match between the model and physical system. This in turn can result in improved control design thru an update to the controller. With model-based design the embedded controller code is rapidly regenerated by the code generator, followed by another iteration of the implementation and testing steps. This process continues until a physical design meeting the performance requirements is realized; which in some cases may involve changing requirements if too difficult or costly to achieve.
Model-based mechatronics design is consistent with and supporting of the well-known System Engineering development process known as the “V” diagram (see Figure 1-2). Both involve top level system requirements that are decomposed to the elemental subsystem level, and both involving performance verification testing on each subsystem during the process and at each level of assembly. The use of model-based design approach within the system engineering development process should improve development efficiency and increases a project’s likelihood of success.
Figure 1-2 –The Systems Engineering and Design Process
Systems engineering and design involves the development of multiple models, often with a different set of models being created within each of the design phases, and often by a different team of individuals. The design phase produces simulation models for the purpose of performance analysis. This team then produces a document defining that part of the design that must be coded, passing this document to the Implementation Team. This team produces by hand coding the software and/or firmware to implement the design. This software/firmware product is essentially another model. Simulation testing is typically done with test vectors created by the Design Team, but if this model is not a fixed point model, or weakly connected to the code, verification can be difficult. Finally the embedded code is compiled and integrated with the physical system and tested using test vectors from the design phase simulation model or possibly from the integration phase model. The problem is that the connection between the simulation model and the hardware is weakened by multiple modeling stages. This increases the potential for issue or bugs to remain undetected, thereby causing anomalous behavior that is not uncovered until testing with the physical system, making the root cause of the problem difficult to isolate.
Figure 1-3 –The model-based design process (courtesy of MathWorks)
Controller Design and Simulation
Truth and Design Models
Complex control system designs are often performed with heavy reliance on the tools of dynamic modeling and simulation. Detailed models of the control effector (i.e. the plant) and of the disturbance environment (for example, the riling motion of an on-the-move vehicle) are combined to create a “Truth Model”, a nonlinear dynamic model containing whatever is necessary for accurately simulating system behavior. The system level model, because it is intended to reflect the true behavior of the system is heretofore referred to as the “Truth Model”. From the Truth Model a “Design Model” is extracted, a less complicated and often linear model upon which the control law is based. The Design Model, appropriately named, includes a model of the plant and possibly a model of the disturbance input.
The control design process is described with the help of Figure 1-4. It begins initially with the definition of Performance Objectives derived from higher level system requirements (e.g. link budgets, disturbance input levels, etc.). Control effector components must be selected that will provide the performance needed to support the overall performance objectives, features such as sufficient electromechanical bandwidth, torque limits, sensor resolution, noise, etc. Other important features that must be included can be described as internal disturbance effects, such as coulomb friction in gimbals. These define the features typically built into the Truth Model. Note in Figure 1-4 that the Truth Model receives information from a number or sources defining the system characteristics: the disturbance model, the control effector model, and the open-loop performance testing results designed to identify system parameters. From the Truth Model the designer extracts the “Design Model” which is the model on which the control design is to be based. This model will typically be of lower order than the Truth Model and it typically will not include the nonlinearities, for example the sensor quantization error. It is the simplest model possible that will permit the development of a controller that is adequate. Typically one starts with a Design Model that is too simple, resulting in a design that does not meet performance, and complexity is added until an acceptable design is reached.
In some cases hardware is fabricated and can be tested early in the design process, before the detailed control design is complete, and in those cases actual hardware test results can bear upon the contents of the Truth Model. In addition, the Disturbance Environment, i.e. a model of these undesired inputs, can be built into the Truth Model, from which it may also flow into the Design Model.
The next phase in the design process is that of Control Design based on the selected Design Methodology. Design Methodologies span a wide range of methods including simple PID control (proportional, integral, derivative), to model-based modern control design techniques that involve coupled multi-input, multi-output systems.
Simulation of the resulting controller with the Truth Model serves as a basis for initial acceptance of the controller design. If Design Requirements are met, the controller can be implemented, integrated with the actual hardware and tested in a realistic environment. Testing in this realistic environment is typically done in the laboratory when possible, to enable the discovery of integration and performance issues prior to installation in the actual system, where diagnosis becomes difficult. During laboratory or actual installation testing, if the unit-under-test fails to perform as expected, then one is faced with a decision. One choice is to return to the Control Design phase using the same Design Methodology and this time attempt to improve behavior with a better tuned design. Alternatively, one may decide to select a different control design methodology or controller architecture, hopefully to improve performance. If the testing phase has revealed a flaw or an error in the Truth Model that is important to controller performance, that error can be corrected, a new Design Model derived and the design process repeated. Another alternative might be the more involved effort associated with changing the hardware to derive better performance, and then repeating the design. If that fails or is not feasible, a final alternative is that of relaxing the overall system performance requirements.
Figure 1-4 –The Model-based System-Level Control Design Process
Model-based Mechatronic System Engineering
Consider first the System-Level of the Systems Engineering “V” diagram. At this level a dynamic model of the system is developed. This is a model of the complete system, in that it must comprehensively include all elements and effects that can impact those performance parameters constrained by the system requirements. It need not include, however, anything else. In other words, don’t include in this model the low level driver interface models that don’t affect the accuracy of the results at this level. Take, for example, the angular sensor data provided by an incremental encoder, a digital device with finite resolution. It suffices at this level to model the encoder as a quantizer with a step size equal to the quantization level. As another example, consider the drive interface to a pulse-width modulated motor. A driver interface need not be included at the system level model, again because it presumably does not impact overall system performance. It may be part of a model developed when actually creating the driver for that motor, however, and at that sub-system level the motor interface driver could be produced using a model-based approach. In other words, make the model as simple as possible, but sufficiently accurate. Not unlike the guidance provided by Einstein, who said that “Everything should be made as simple as possible, but no simpler.”