Experience with RealSim for Robot Applications

Transcription

1 EC IST Project No Real-time Simulation for Design of Multi-Physics Systems (RealSim) Experience with RealSim for Robot Applications Deliverable D42, Report for Task 4.5 Public Report Arif Kazi, Günther Merk KUKA Roboter GmbH, Augsburg Hui Fan, Matthijs Langelaar, Martin Otter Deutsches Zentrum für Luft- und Raumfahrt e.v., Oberpfaffenhofen Sept. 30, 2002

2 TABLE OF CONTENTS EXECUTIVE SUMMARY INTRODUCTION FUNCTIONALITY SPECIFICATION REALSIM DEVELOPMENT PROCESS REQUIRED CALCULATION FUNCTIONALITY REQUIRED OPTIMISATION FUNCTIONALITY DATA MANAGEMENT AND INITIAL DESIGN DATA MANAGEMENT CONCEPT SOFTWARE ARCHITECTURE Matlab program Data base Modelica under Dymola ROBOT COMPONENT LIBRARY Public robot component library Proprietary KUKA robot component library DEVELOPING AN INITIAL DESIGN Specification of the robot Defining the model

3 3.4.3 Performing static calculations Performing dynamic calculations OPTIMISATION OPTIMISATION CRITERIA Cycle time Energy SELECTION OF THE ROBOT PATH Path data in joint coordinates Path data in Cartesian coordinates Path layout OPTIMISATION PARAMETERS Motors Gears Counterbalancing system Link lengths of structural parts PARAMETER CALCULATION FOR STRUCTURAL PARTS Parameter calculation from CAD data Simplified structure parameter calculation OPTIMISATION SYSTEM Overview over MOPS Robot optimisation tool using MOPS REAL-TIME SIMULATION

4 6 OPTIMISATION CASE STUDY TASK DEFINITION PARAMETERS FOR OPTIMISATION Gear ratios Motor types Counterbalancing system PATH DATA OPTIMISATION PROCEDURE OPTIMISATION RESULTS VALIDATION OF OPTIMISATION RESULTS DISCUSSION Quality of the simulation results Usability of the optimisation tool Time-efficiency of use Required experience level of the user SUMMARY AND CONCLUSIONS...66 REFERENCES...68 LIST OF FIGURES

5 Executive Summary Superior performance of industrial robots can only be achieved if the interaction of mechanics, electronics and software is taken into account already in the design phase. Conventional approaches to modelling, however, cannot cope with such multi-physics systems. The new Modelica modelling language has been specifically developed for this purpose. It also significantly increases re-usability of model components, since components adapt to the connection structure in which they are used. In the European research project Real-time Simulation for Design of Multi-physics Systems (RealSim), efficient tools for modelling, simulating and optimising industrial robots were developed. A general Modelica multi-body library formed the basis for the development of a specific robot component library. A development environment for creating robot models out of the available components was provided, in which initial calculations to verify the first rough design can also be performed. Tools for automated optimisation were developed that take the initial design as the starting point. The performance of a design can than be verified in a real-time simulation before investing in building a real prototype. In a robot design case study, the RealSim tools significantly reduced the development time as compared to previous designs. Thus, the RealSim development tools provide the basis for even more efficient development processes and superior robot performance in the future. 5

6 1 Introduction Industrial robots are truly mechatronic devices: their performance is governed by a close interaction of mechanics, electronics and software. When developing a new type of robot, it is therefore not sufficient to consider the different physical domains individually. Superior performance can only be achieved by taking a holistic view that covers all aspects. A large amount of simulation software is commercially available, and it is already being used extensively in the design of industrial robots. Current methods are, however, usually strong in one physical domain only. For example, the 3D mechanical construction can be simulated efficiently with a multi-body program, yet not the electric drives. Block diagram-based simulation software requires that the user performs the most difficult part of the modelling process manually: he has to transform the natural non-causal description of physical systems into a block diagram form. Modelica, on the other hand, is a new, free modelling language that can cope with large scale, multi-physics systems [1]. It features noncausal, object oriented modelling: mathematical equations are used instead of assignment statements. This significantly increases reusability of model components, since components adapt to the connection structure in which they are used. The Modelica simulation environment Dymola from Dynasim [2] provides the means for realtime simulation of large scale Modelica models with short deadlines. In the European research project Real-time Simulation for Design of multi-physics Systems (RealSim, IST-Project [3]), the Modelica language is applied for optimising the design of industrial 6

7 robots. Screenshots of typical Modelica models in Dymola s object diagram editor are shown in the fig. 1 below. Fig. 1: Examples of Modelica models in different domains. In this report, the experience of applying the RealSim tools in the design of industrial robots is documented. Chapter 2 provides a brief description of the design process as seen by RealSim and the required functionality of the development environment. Chapter 3 describes the RealSim tools for the initial design of a robot. Chapter 4 focuses on the RealSim optimisation tool and its application. After a promising design has been achieved, the results can be verified through real-time simulation as shown in Chapter 5. 7

8 Chapter 6 describes the optimisation case study that has been conducted to assess the optimisation tool. Chapter 7 finishes with a brief summary. 8

9 2 Functionality Specification 2.1 RealSim Development Process With the tools developed in the RealSim project, the design of a new industrial robot will follow a certain typical sequence (see fig. 2): After the initial specification of the robot (desired payload, work space, etc.), a first model of the robot is created. In the robot component library, the data of older designs are available, which will serve as a reference. The initial design is carried out following heuristic rules. Static calculations are performed to check the joint torques in different arm configurations and adjust the kinematic parameters. Model of robot based on component library (calibrated with CAD - data of old robots). Specification of a new robot (payload, size of workspace,...) Initial design by heuristic rules using using static/dynamic calculations Parameter optimization for a specified set of paths Design verification using real - time simulation (optional) best compromise Design of CAD model Product finalisation Fig. 2: RealSim design process for industrial robots. 9

10 The initial design is followed by a min/max parameter optimisation phase in which a good compromise candidate is determined by minimising the maximum of a set of (scaled) criteria. Finally, the design can be verified in a real-time simulation using the actual robot control hardware before resources are allocated to build a prototype. 2.2 Required Calculation Functionality The first design steps with the RealSim system make use of the static calculation function. By this tool, not only the initial shape of the robot is defined, but it is also very important for the safety of the robot system: in order to fulfil the EC-machine guideline, the robot has to be stable in every load case and in every position. So the initial dimensioning of the gears, motors and brakes will take care to satisfy this criterion. Even in later steps of the robot design process, the static calculation tool helps to find possible problems or to give a quick overview on the torque situation of the robot. The second set of calculation functions are those for dynamic calculation. This tool provides the means to investigate the motion performance of the robot. It calculates the working torques on the motors and gears of the robot axes. Thus, the designer is able to define speed and acceleration for the different axes. The data for the first calculations are based on heuristic rules and are taken from former robot types. Even if the two tools for static and dynamic computation are comparatively simple, with the right way of usage and some experience by part of the designer, the result is an 10

11 initial robot design that could already be utilised and serves as a basis for all further design steps. 2.3 Required Optimisation Functionality Tools for mathematical optimisation of the robot parameters have been used little in industrial practice so far, but have a great potential for accelerating the design process and enhancing the quality of a design if employed properly. With the optimisation tool developed in RealSim, several robot parameters shall be optimised, particularly the ratio of the gears, the length of the structure parts and the parameters of the counterbalancing system. The optimisation of structure part lengths is useful only in the first steps of the design. At that point of the development process, there is not enough information available to use a detailed data model. So a simplified data model has to be used which may not give the same results as a more detailed model. In a further step of the robot design, the optimiser is used with a more detailed robot model. It is utilised for the final tuning of the robot and optimises easy to change but important parameters which have a high impact on the results. Generally speaking, optimisation with respect to different robot paths will give different results. It is therefore important that several robot paths that are representative for the envisaged application are utilised in an optimisation run and that the best possible compromise is determined (= multi-criteria optimisation). 11

12 3 Data Management and Initial Design Before an optimisation can start, a reasonable initial design has to be available. This is a difficult task by itself since all components such as motors, gear units, counterbalancing system, structural parts etc. need to be designed in such a way that the essential requirements are already fulfilled and the robot is functional, i.e., simulations can be carried out. Otherwise, the optimisation task is too difficult to be solved with today's optimisers in an acceptable period of time. In the RealSim robot development environment, the starting point for the design is a data base which contains models as well as data of components and of previous designs. In order to verify that the initial design meets the requirements, heuristic tools for static calculations are provided. Both data base and calculation tools are described in some more detail in this chapter. The following section 3.1 discusses the underlying data management concept for the RealSim prototype. An overview of the software architecture is given in section 3.2. Section 3.3 specifically addresses the robot component library that has been developed within the project. Section 3.4 describes the usage of the tools when defining a model and performing calculations. 3.1 Data Management Concept During the initial phase of the RealSim project, it quickly became obvious that the data of a large number of simulated systems had to be stored in a useful and systematic way. The reasons for this are mostly due the modular mechanical structure of KUKA robots: 12

13 The same type of gears and motors are used in a large number of robots. Some structure parts are used in different robots. Some robots are very similar to each other and distinguish only in small parts. The values used for the calculations have to be stored as well as the calculation results. This is necessary to allow a duplication of the development process at later points in time. All users of the program should use the same data to avoid conflicts of double storage. This would end in conflicting data sets for the same robot. A standard user should not be able to change the equations. A time-consuming re-generation of the model should only be necessary if the structure of the model is changed. Thus, the new prototype software needs an extreme high grade of modularity and a central data storage to avoid conflicts in practical usage. The equations are not stored in the data base, but in the library components. This is the only way to keep all robot models on an actual state, even if the parameters of one part are changing. In addition, it is ensured that everybody will always get the same results. 13

14 3.2 Software Architecture The RealSim tool for performing data management as well as static and dynamic calculations consists of four parts (see fig. 3). The three main parts are the Matlab program, the data base and the calculation kernel under Dymola. These parts are strictly divided. The communication between the Matlab GUI and the Dymola part runs via a transfer file. The fourth part is the robot component library, which is used by Dymola to build up the robot structure model. Data base Matlab GUI File File Robot component library Dymola Modelica translator Fig. 3: Architecture of the calculation tool Matlab program All front ends of the RealSim data management and calculation tool are implemented in Matlab from MathWorks. The database is filled from this program part via an interface. Also all pre-processing and post processing features are integrated, such that all general conditions for any calculation are defined here. 14

15 The main reason for using Matlab is the fact that it is in widespread use and offers great benefits in the post processing because of its many integrated analysis functions Data base The data of the robot components, such as motors, gearboxes, and structural parts, as well as the designed robots using these components are stored in the data base. To be open for all future extensions, the data base is not strictly designed for 6 axes robots, but to store any kind of kinematic system. The electro-mechanical parameters are stored in appropriate tables. So the data base is quite complex, yet powerful. As mentioned in section 3.1, there is a strict splitting between data and equations. The data base only stores the actual parameters, while the Modelica library components contain the model equations only. Thus, it is ensured that the program always provides consistent results for all users: every user works with the same parameters, and the equations are not accessible to the ordinary user. The mechanical structure is split into parts of the drive trains and structure parts. This splitting is necessary to keep the complexity of the data input as low as possible. Parts such as casting parts of the structure are from the class structure parts. Parts of the drive train are the inertia of smaller rotating pieces or the axis coupling. These parts have no geometrical size and no mass, or the mass of a single part so small that it is handled with the corresponding structure part. Motors and gears are part of both groups. 15

16 3.2.3 Modelica under Dymola Right from the start, it was intended that the ordinary user of the program wouldn t ever have to directly deal with Dymola. Nevertheless, Dymola fulfils a very important part within the architecture. When the complete robot is created in the Matlab user interface, the Matlab data structure is stored as a Modelica model on file using the actual parameters from the data base. Afterwards Dymola is started and reads this file, performs the required calculation on this model and stores the simulation result back on file. Finally, the result file is passed to Matlab for post-processing. For test purposes, it is also possible to start Dymola manually, read the generated Modelica file and use Dymola s object diagram editor to graphically browse the Modelica model. Note, that in the data base system no information is stored about the graphical placement of the components in the Modelica object diagram. For this reason, an automatic placement of the objects and the connections is performed when generating the Modelica file. The result is reasonable but could be improved if edited manually. 3.3 Robot Component Library Public robot component library As a basis for modelling robots of all kinematics, a Modelica library was developed to model arbitrary 3-dimensional mechanical systems, see fig. 4 and 5. 16

17 Fig. 4: Highest level of the multi-body library. Fig. 5: Sublibrary Joints. The Modelica multi-body library can be combined with the existing 1- dimensional mechanical Modelica libraries. It is also possible to define multi-body systems that contain kinematic loops. A unique feature is the efficient treatment of joint locking and unlocking. This allows, for example, easy modelling of friction or brakes in the joints. This library is freely available and can be either downloaded from the Modelica home page [1] as part of the Modelica Additions library or from the RealSim project home page [3]. In fig. 6, an example is 17

18 shown how to model a typical robot with this library. The robot model is composed of basic mechanical components such as joints and bars as shown in the right part of fig. 6. At every joint, a drive train is present. Each drive train contains a motor, a gearbox and an actuator as well as a control system. The elasticity of the gears of the first three joints is modelled by one spring for each gearbox. The elasticity of the last three joints is neglected. The figure also shows the model of the motor and the actuator of a joint. This component is defined, most naturally, as an electrical circuit. The control system for one driving axis is defined in block diagram format. Fig. 6: Robot modelled using the Modelica multi-body library. 18

19 3.3.2 Proprietary KUKA robot component library From the public robot component library, a KUKA-specific robot component library was derived for use in the system shown in fig. 3. This proprietary library contains components specific to KUKA robots, such as counterbalancing systems, wolfram/cycloid gears including realistic friction models, axis coupling elements and others. As an example, the axis coupling element is discussed in more detail: For the wrist axis of industrial robots, it is very common to place the motors not directly at the wrist joints. Usually the motors are placed near the joint no. 3, and the rotation is transferred to the wrist joints via spur gears, drive shafts and spur belts to the gear boxes. For kinematic reasons, it is necessary that rotating parts of the drive train pass coaxially through other joints (e.g. the drive train of joint 6 is passing through the joints 4 and 5). If these passed joints (e.g. joints 4 and 5) are moving, the passing axes (e.g. joint 6) are also influenced, as there is a relative rotation around the passing drive trains. Usually, a higher number of joints (up to all 6) are active during a robot movement. The relative rotation must be known to reach the target position precisely or to realise an accurate path movement, so that the robot is able to compensate for the axis coupling. This effect has been implemented as an individual Modelica library component called Relative Rotation. The usage of the new component can be seen in fig

20 Motor 6 Joint 6 Motor 4 Joint 4 Joint 5 Motor 5 Fig. 7: The relative rotation component (blue) in a structure. 3.4 Developing an Initial Design Specification of the robot The design and optimisation of a robot will only have a successful outcome if the specification is sufficiently exact. Certain general requirements must be defined in every case in order to avoid wasted development work. As a starting point, the following parameters are of utmost importance: Robot payload: the definition of the masses, moments of inertia, and load centre distances of main loads and supplementary loads essentially determines the range of application of the robot. These parameters also have a major influence on the performance of motors and gear units. Robot work envelope: the size of the work envelope is determined by the link lengths of the manipulator and the permissible robot axis angles. These values are only defined later, however. The 20

21 work envelope may vary depending on the planned area of application. Robot dynamics: the final velocity of the robot and the motor and gear torque available for acceleration. The dynamics also largely determines the size of the motors and gear units. As a general rule, it is always desirable to keep these parameters as large as possible. Two factors must be borne in mind, however. Firstly, the space required for the robot is then prohibitively large for certain applications. Secondly, the increased performance, which is usually not required in all cases, causes the cost of the robot to rise massively Defining the model The graphical user interface of the RealSim tool set provides the user with an intuitive means for defining new parts, modifying existing ones and defining complete robots (components and how components are connected together). A screen shot of the interface for defining a new part is shown in fig. 8. Means are provided to enter the (electro-) mechanical parameters of the part as well as the kinematic frames which define the geometry for connecting the part. 21

22 (Electro-) Mechanical parameters Geometry is defined by frames Fig. 8: GUI for the definition of a part. Fig. 9 shows the equivalent screen shot for the structure definition of a new robot. In the user interface, it is defined which parts are connected as well as how they are assembled with respect to their kinematic (definition of rotational or translational degrees of freedom, etc.). The parts for the new robot may already be available in the database from previous designs, or they are actually designed from scratch. 22

23 Define which components are assembled Define how they are assembled Fig. 9: GUI for the definition of a kinematic structure. Another important step is the definition of the drive trains. The drive trains reflect the whole drive system beginning with the servo controllers, the motors, transmission elements and finally the gears. Fig. 10 shows the screen to define these connections. To make data management simple and well-defined, the drive train parts do not have mass or centre of gravity of their own. Compared to the mass of the structure parts, they are too small anyway to make them relevant. The only mechanical parameters of those components are the ratios of the gears and transmission elements and the rotating inertia. Components like motors and gearboxes are dual by nature: The mass parameters are part of the mass topology, the drive parameters of the drive topology. This is handled automatically and the user does not have to deal with it. 23

24 Fig. 10: Definition of the drive trains Performing static calculations The first step in performing calculations is the static analysis of the structure. It shows the torque which works on the motors and the gearboxes of the robot. The functionality allows the user to dimension the gearboxes and the motors such that the robot is able to hold every position in every load case with some margin for acceleration. There are 3 different types of analysis realised for static computation: 24

25 1. Input of a single position of the robot and a single load case. The result of this calculation is a bar chart that shows the actual torque and the maximum allowed ones of all robot axes (see fig. 11). Fig. 11: Result screen of the static analysis. 2. Motion of a joint. In this analysis, a number of axes move over a specified joint angle. The calculation is still static on an adjustable number of points on that angle. This tool helps to analyse the static situation in the whole work space. 3. Search mechanism to find the worst case automatically. This tools helps to find critical robot positions. The function analyses the whole workspace to find the most critical position for every axis. This functionality is really helpful to find the weak spot of the robot s static design. 25

26 3.4.4 Performing dynamic calculations The second step in performing calculations is a rough dynamic analysis. The goals are quite clear: The motors and gearboxes have a certain torque capacity. One part of that capacity is used to carry the static load of the axes. The rest may be spent to accelerate and decelerate the robot. In a standard robot design process, it would be required to manually check the torque in a large number of different joint configurations and motion conditions. However, with the RealSim tool set, an automatic optimiser will take over the fine tuning of the robot model. Therefore, only a relatively simple tool for a rough assessment of the initial design is needed. There are two alternative functions that are offered by this tool: 1. The first function is the specification of the robot s position and axis acceleration. The result of the computation is the necessary torque at the motors and gears. 2. The second function uses fixed values for the torque of the motors and gears. The robot position is also specified. The result is the maximum acceleration of the individual axis. Now the robot is pre-dimensioned. A robot manufactured according to this initial design would move and would be stable in every position. The initial design forms the starting point for the optimisation. 26

27 4 Optimisation In the preceding sections, a method has been devised for simulating industrial robots. The aim now is to expand this capability to allow for automatic optimisation. This optimisation procedure is relatively complex and it is not always clear which (and how) parameters are to be optimised. In order to illustrate the complexity of the task and the interaction of the elements to be optimised, an overview of all aspects to be considered is given. For this purpose, the relevant criteria for optimisation are described in section 4.1. The impact of the selection of the (set of) robot paths is discussed in section 4.2. Section 4.3 generally describes the robot parameters manipulated in the optimisation process, while section 4.4 specifically focuses on the problem of computing the mass parameters of structural parts between the different optimisation runs. Section 4.5 then finishes with the description of the optimisation system itself. 4.1 Optimisation Criteria Every optimisation needs a goal, otherwise it would be neither practicable nor useful. In general, there are three criteria which a robot arm should optimally fulfil. The cycle time required for a work cycle should be as short as possible. The energy consumption should be as low as possible 27

28 The price and maintenance costs of the machine should also be very low. Since the cost question cannot be answered by means of a simulation, the following two criteria remain for the design of the robot: cycle time and energy consumption Cycle time The guiding principle in a manufacturing system is Time is money. Manufacturers are always at pains to manufacture as many units as possible within a given period of time. Consequently, as short a manufacturing cycle as possible is desired, which also leads to a short robot cycle time. One can state without exaggeration that a robot cannot be too fast, because if the maximum achievable velocity were indeed too high for any reason, then it could still be limited by controller-based measures. The criterion here is thus: the cycle time must be as short as possible. Of course, it should also be borne in mind that the costs of the robot will be driven up greatly by this criterion Energy Subordinate to the cycle time criterion is the energy consumption of the robot. Of course, a very high energy consumption gives rise to costs due to the increased costs for cabling and running costs. To a certain extent, however, these costs are subordinate to the gain in cycle time. Nonetheless, energy consumption is still an important criterion for certain areas. If energy were not used as a criterion, however, then the cycle time would be the only decisive variable. The result of this would be that 28

29 of several motor and gear unit sizes available for selection, the most powerful would always be chosen. In order to avoid this development and to achieve an adequate optimisation, a balanced weighting of the two criteria is therefore necessary; this may need to be adjusted from case to case. 4.2 Selection of the Robot Path One crucial optimisation criterion is the type of path data. The term path is used to describe the motion sequence of a robot. Two different types of path data are of relevance here: path data in joint coordinates and in Cartesian coordinates. Both have advantages and disadvantages: Path data in joint coordinates This type of path data has the advantage that one data set can be used for all robots of a given series. This means, for example, that all six-axis robots with the same axis configuration can use these data, irrespective of the overall size of the robot. In this way, the quantity of path data required can be significantly reduced, with the additional advantage that it is not necessary to integrate an interpolator into the optimisation tool to determine the position. This type of data is suitable for optimising the motors, gear units and counterbalancing system. However, the suitability of this type of data for optimising link lengths is limited. It must also be borne in mind that the original path was programmed for a specific robot of a defined size. Optimisation of a robot of a different size is thus only of limited use, because a robot of a different 29

30 size might use a completely different motion sequence to execute the task in hand. Certain paths are also unsuitable for robots of certain sizes. The validity of optimising a small robot using a path programmed for press linking is thus dubious Path data in Cartesian coordinates Path data in Cartesian coordinates consist of 6 values, as is the case for joint coordinates. Here, however, these values specify not axis angles, but space coordinates measured from the robot base and rotational angles about each coordinate axis (see fig. 12). These coordinates uniquely define a single point to which the robot tool must move. In order to convert these coordinates back into the axis angles required for the structure, an interpolator must be integrated into the controller. Furthermore, the ability of a robot to reach the points on the path indicates, as early as the design phase, whether or not that robot is suited to a specific application. This means, however, that different path programs must be available for different robot sizes in order to ensure that optimisation can be carried out in all cases. The definition of the path data in Cartesian coordinates thus enables realistic results, but requires greater effort. 30

31 Fig. 12: Points of a Cartesian robot path in a graphical simulation Path layout The layout of the path also has a major influence on the optimisation of the robot, particularly where the cycle time is of overriding importance. A path with long motions and few intermediate points is generally optimal in terms of cycle times, with as high a final velocity as possible maintained for as long as possible. Such paths are encountered in certain press linking or handling applications. In spot welding programs, on the other hand, paths have a large number of points with relatively short gaps between them. The robot rarely reaches its final speed, but high acceleration is nonetheless very important. The final speed is less important here. The user must, therefore, have a clear idea of the planned application profile of the robot and choose the paths used for optimisation purposes accordingly. Most robots are built to cover as 31

32 wide a spectrum of applications as possible. In this case, a compromise must be found between final speed, acceleration and energy consumption. Of decisive importance here is the choice of path for which optimisation is carried out. This factor represents a major potential source of errors and cannot be automated. At the end of the day, what counts here is the experience of the user. 4.3 Optimisation Parameters The component of the robot modified in the optimisation process are the motors, the gears, the counterbalancing system and the dimension of the structural parts. The following subsections describe the nature of the parameters that describe these components Motors The motors used today are standard components and a single motor type is usually used in several different robot types. The number of different motor types currently used is relatively low and these can be exchanged, with certain restrictions, using a small variety of different flanges. For reasons of cost, the number of different motor variants should not be increased unless absolutely necessary. The relationships between the electrical and mechanical parameters of a motor are highly complex and cannot be approximated easily. Even if an optimisation would give satisfactory results, there is no guarantee that the motor manufacturers would be able to meet the required parameters. There is thus no point in carrying out extensive simulation and optimisation of a motor. 32

33 In order to optimise motors, the following procedure is thus adopted: the program chooses from the motors contained in the database and recommends the optimal type. Individual parameters are not optimised. The following criteria are relevant for motors: The built-in brake must be able to hold the axis safely. The motor must produce sufficient acceleration torque to allow high robot dynamics. The final speed of the motor must be great enough to ensure that the planned axis velocity can be reached. Secondary criteria defining the optimisation more precisely can also be introduced. One must carefully consider first, however, whether the potential benefit outweighs the additional effort required to integrate these criteria into the simulation and whether or not it is actually possible to simulate and optimise these values meaningfully. Even in the case of an uncontrolled stop, e.g. following a power failure, the braking torque must not be so great that other components, such as the gear unit or the brake, are damaged. The power input must be compatible with the power cables, servo drive modules and energy consumption requirements Gears Unlike with motors, the number of different gear types is relatively high. The main reasons for this are the different gearing principles, gear ratios and sizes. Since the gear units and connecting elements are positioned between two structural components, the installation 33

34 situation is of importance. It is not at all possible to produce a series of standard flanges as for motors. For these reasons, it makes more sense to optimise the individual gear parameters. Value windows of ±10% are assigned to the values determined in the preliminary design. This margin ensures that the initial values are not distorted too greatly. Should it prove necessary for the values of a parameter to exceed these limits, the user has the option of allowing greater deviations. It is important to check, however, that this change in value is still realistic. The following parameters are relevant for gear optimisation: Gear ratio. This value can only be implemented with restrictions in the real robot. Manufacturers are often only able to supply certain gear ratios. This is frequently due to structural constraints. Permissible gear torque. The torque is usually decisive for robot operation. Since the other value of the Emergency stop torque is directly dependent on this, it need not be optimised separately. As well as these values, the tilting stiffness and torsional stiffness of the gear unit are also highly relevant. Both of these values should be as high as possible. These values are almost impossible to influence and are dependent on the gearing principle, the design of the gear unit and the type and quality of the bearing Counterbalancing system In the case of larger robots, the static torque about axis 2 is so great that technical factors and cost restraints make compensation using just the gear unit and motor impractical. For this reason, a counterbalancing system is installed on axis 2 to generate a 34

35 supporting torque. Such systems are generally designed as tension cylinders, attached at one end to the link arm. Deflection of the link arm results in an angle between the counterbalancing cylinder and the component, thus giving rise to a compensatory torque (see fig. 13). Fig. 13: Two extreme positions for the counterbalancing system. For various reasons, counterbalancing systems are closed devices which cannot be adjusted during operation. Furthermore, their torque is determined solely by axis 2; other robot axes and special load situations are not taken into consideration by the real system. The counterbalancing system must enable the robot to maintain any position safely irrespective of the load carried. The compensation setting has a major effect on cycle times. In practice, however, there will always be certain positions and motion situations for which too high a compensation torque is unfavourable and other positions for which the same torque is required. 35

36 Of the numerous different counterbalancing systems that are technically possible, 2 principles have proved to be particularly useful: Pressure based systems Steel spring based systems The configuration of the systems on the robot is always the same so some of the parameters are identical for both systems. These parameters are usually dependent on the configuration of the robot and can only be modified with great effort once the robot design has been finalised. Most of them are also largely dependent on structural factors which cannot be simulated. Whether or not it makes sense to carry out automatic optimisation must be decided on a case by case basis. The following parameters can be optimised: Distance between the articulation points on the rotating column and link arm in the neutral position Length of the effective lever arm on the link arm Pre-tensioning of the steel spring Spring rate of the steel spring Effective piston area in the case of pressure systems Accumulator volume in the case of pressure systems The design of the counterbalancing system has a major influence on the motor and gear unit of axis 2 and these three components should be optimised together wherever possible. 36

37 4.3.4 Link lengths of structural parts Optimisation of the link lengths is subject to very far-reaching restrictions. The axis angles are generally predefined and a specified horizontal reach must be achieved. Taking these restraints into consideration, the robot must be able to cover as large a work envelope as possible with the best possible cycle times. Theoretically, the following link lengths can be usefully optimised in an industrial robot with 6 degrees of freedom: Horizontal distance between axes 1 and 2 on the rotating column Length of the link arm between axes 2 and 3 Overall length of the arm between axes 3 and 5 Distance between axes 5 and 6 To obtain an optimal work envelope, the distance between axes 1 and 2 should be as small as possible. For technical reasons, however, a certain minimum distance is required. Optimisation is thus neither necessary nor sensible. The distance between axes 5 and 6 is actually outside the reach of the robot. The generally applicable definition of the reach only goes as far as the wrist root point in axis 5. Since the wrist axes are actually only used for orientation of the tool, it is desirable to keep the distance between the wrist axes as small as possible. Here again, the minimum distance is determined by technical factors. Only the lengths of the link arm and the arm thus remain available for optimisation. 37

38 The actual optimal length in practice thus depends greatly on the specific application profile of the robot as defined by the motion paths selected. 4.4 Parameter Calculation for Structural Parts The representation of motor and gear unit bodies in the simulation system poses no great problems. The database already contains all the relevant parameters for an optimisation in which only the selection between existing components is allowed. Free optimisation of the parameters also poses no great difficulties. Motors and gear units can be represented as mass points with defined locations of the centres of gravity. An inertial tensor can be assigned to these points, thus completing the definition of the body. If the parameters are modified, it is essentially only necessary to adapt the mass of the component. This is possible by means of a simple reference to the initial mass and certain power ratings. The results are sufficiently accurate, especially if parameters for different designs and power classes are adapted. The locations of the centres of gravity and the mass inertia could be adapted in the same way, but there is little point in doing so. The compact design of these modules means that the moments of inertia and minimal displacements of the centres of gravity have little influence on the overall system. Furthermore, the design of these modules is largely dependent on the manufacturer and influence over the real component is only rarely possible. Due to their size, structural components have a much greater influence. Changes in length shift not only the centre of gravity of 38

39 these components, but also the locations of the centres of gravity of all subsequent modules. Additionally, their size results in much greater moments of inertia than in the case of motors and gear units. Furthermore, they are designed in-house, which allows a great deal of influence in terms of size and shape. It is thus necessary for simulation of the structural components to be as accurate as possible in order to obtain a sufficiently good overall result. The shapes of the real components vary greatly. Usually there is no simple proportional relationship here between length and mass, i.e. lengthening or shortening the component by no means implies that the mass is changed by the same fixed factor. The same applies, of course, to the mass inertia. Structural components are too complex and, depending on the place of use, too different to allow precise simulation by means of simple formulas and parameters Parameter calculation from CAD data In a early phase of the RealSim project, it was envisaged to have a CAD model of the robot inside the optimisation loop, from which the mass properties of the structural elements of the robot would be calculated. However, a more in-depth analysis revealed that this is not feasible: The CAD models of the robot parts are very complex and designed drawing heavily on free form modelling. It is thus impossible to change the shape of the parts merely by recalculating some parameters. For this, the model would have to be fully parametric. When a certain level of complexity is exceeded, it becomes very labour intensive to create a fully parametric CAD model, or this may not be feasible at all. 39

40 Even if a fully parametric model would be available, many difficulties with the robot structure would arise concerning the many mounting points on the body parts of the robot. These are not only used for cabling, motors and gears, but also for calibration marks, tool periphery cabling, axis range monitoring and so on. Some of them have to move when parameters are changed, others have to remain in their place. The problem is the fact that it is not automatically clear in which way a fixation point has to be handled. Thus, a parametric solution is not realistic. A data interface between CAD and Modelica makes little sense, as it does not fit with the design process described above. The initial idea required that the CAD File is available before the calculation starts, then the part would be optimised. In real life, the robot is calculated first with approximate kinematic dimensions, motor and gear data. Consequently, the parts get designed. The last step is the exact recalculation with the real numbers. The CAD interface would not be helpful during the critical first design phase, because there is no CAD part yet. Thus, the planned interface between a CAD system and Modelica was not implemented, but a simplified approach was chosen to compute the mass parameters of the structural parts Simplified structure parameter calculation In order to optimise structural components, a simplified model is thus required, which can be completely parameterised and can approximate all structural bodies. At the same time, this model must not be so complex that the computation effort is increased unnecessarily. 40

41 The substitute system is composed of two hollow cylinders joined together. The following conditions apply here (also see fig. 14): The origin of the two cylinders can be located at any point in the overall system. The contact point for the next robot structural component is situated in the end face of the second cylinder. The centrelines of the two cylinders are parallel, but can be offset in both surface axes. The end faces of the two cylinders touch. The geometrical measurements of the two hollow cylinders can be chosen freely and are defined from the origin. The densities of the two cylinders can be chosen freely and can be different for both cylinders. Fig. 14: Graphical schema of a substitute system. 41

42 The mass, location of the centre of gravity and the mass inertia can be calculated automatically from this system. The computation effort is relatively low here. If it is necessary to optimise the length of the structural component, the following conditions apply: The position of the origin is retained. The internal and external diameters and the density of the cylinders remain constant. The offset of the cylinder axes remains constant. The contact point with connected components is simply offset in the longitudinal axis (Z in the diagram). The length of the cylinders is adapted in proportion to the change in length of the overall system. The data thus obtained can now be used to recalculate all the data for the bodies. This system allows sufficiently accurate optimisation. Since certain influences, such as interference contours or attachments, cannot be taken into account in the optimisation in any case, even significantly more complicated substitute systems would not be able to produce more accurate results. 4.5 Optimisation System For the mathematical optimisation of robot models, the software system MOPS (Multi-Objective Parameter Synthesis) developed in DLR outside of the RealSim project is used. It is a modular Matlabbased software approach for practical design applications based on min-max parameter optimisation [4]. It is the major design tool in DLR's design process technology. A short overview of MOPS is 42

43 given in the following subsection. In subsection 4.5.2, it is described how the robot optimisation has been integrated into MOPS Overview over MOPS The main feature of the MOPS methodology is that the various kinds of design objectives can be taken into account in their most natural form and that design alternatives can be assessed most visibly with respect to given requirements. Multi-objective synthesis tuning by min-max parameter optimisation allows interactive compromising in the set of what can be best-possibly achieved within a chosen model structure. The main features of MOPS are: explicit formulation of design specifications as computational criteria simultaneous consideration of multiple criteria simultaneous handling of multiple models (scenarios) and cases (= several simulations with the same model for different operating conditions). parameter synthesis and tuning using optimisation algorithms (NLP, search methods, GA) automatic parameter studies on-line visualisation tools open architecture that allows use of arbitrary simulation/criteria - server MOPS is a general tool for solving multi-objective design problems, in which the computational chain from tuner parameters (that are to be optimised) to mathematical criteria (that reflect the design 43

44 specifications) have to be formulated individually. To support this, MOPS provides an application program interface and a graphical user interface written in Matlab. This allows the designer to formulate the individual problem in a well established language for technical computing. However, the computations need not be completely within Matlab. The open architecture of MOPS allows to use any simulation server to produce the required indicators or criteria. The interface between MOPS and the necessary computations is described in so-called run scripts. The Matlab implementation of MOPS supports also the multimodel/multi-case problem formulation for a structured approach of complex design tasks. The complete MOPS-data structure is as follows: Setup Version Tuner Model Case Parameter Result Criteria complete problem description, ready for execution occurrence of a set up (= different variants of optimization setup) optimization parameters (= subset of all model parameters) run script for interface, computation, and visualization model instantiation for a specific parameter set parameter set, defines cases and tuners any analysis/simulation results criteria and/or indicators Robot optimisation tool using MOPS Fig. 15 below shows how the robot definition and design tools have been integrated into the MOPS program: 44

45 Cycle time energy MOPS criteria analysis and evaluation tuners initialize Initial robot calibration data make copy of robot compute parameterized updated robot 1 robot components compute common center of mass/inertia + overall inertia of drive train database Simulation of robot movement Modelica-File updated robot 2 path definitions program (mfile,c-program) data program call data flow data flow during optimization iteration Fig. 15: Optimisation of the robot design. Tuner initial values and the constraint values are initialised by the initial robot from the data base system. The red arrows indicate the flow during the MOPS optimisation iteration. During these iterations, a copy of the initial robot data structure ("updated robot 1") is used and the parameters in this data structure, e.g., gear ratios, are overwritten with new values proposed from the optimiser. In some cases, the tuners used in the optimiser can be copied directly in the "updated robot 1" data structure. In other cases, additional computation has to be carried out in order to compute parameters of the robot structure from the tuners ("compute parameterised robot components"). For example, if a component length is used as a tuner, the mass, centre of mass and inertia tensor of this component is calculated for every length change based on calibration data from existing robot components and the heuristic with two hollow cylinders explained above. 45

46 In order to speed up the model simulation, the many bodies and drive inertia present in the "updated robot 1" data structure are summarised whenever possible (e.g., all the rotational inertias and gear ratios of one drive line are summarized to one overall rotational inertia ). The result is an "updated robot 2" data structure. The "updated robot 2" data structure is written into a data file in Modelica format ("Modelica-File") and is used as input for the robot trajectory optimization, together with the reference path on which the robot should move ("path definitions"). It serves as a basis for a simulation of the robot which produces the desired criteria variables, such as cycle time and energy consumption. In the actual implementation, the most important robot parameters defined in the data base can be used as tuners in the optimisation, especially Arm lengths. Gear ratios and strength. Parameters of the counterbalancing system, such as the mounting position and the filling pressure. Motor parameters are not optimised. Instead, in the current version complete motors are exchanged. In every optimisation iteration, several simulations may be performed in order to calculate the criteria values for different reference paths to take into account the wide spectrum of usage of the robot. For every reference path criteria are calculated: the cycle time (high priority) 46

47 the energy consumption (low priority). According to the philosophy of MOPS, all criteria are scaled and are minimised together in a min-max sense (= minimise the maximum criteria). Additionally, constraints have to be fulfilled along the reference paths during optimisation, such as All tuners have to be in a range of ± 10% in relation to the initial value. The maximum output torque of the gear units. The maximum motor torque. The maximum motor speeds. Fig. 16 below shows the robot optimisation setup in the MOPS GUI: Fig. 16: The robot optimisation setup in MOPS. 47

48 5 Real-time simulation The possibility to perform real-time simulations becomes particularly important in the later stages of the design process. The final design can be verified before one embarks on the costly and time consuming process of building a prototype. In a benchmark test, a detailed model of the mechanics and the drive system of a six-axis industrial robot with about 1000 algebraic equations and 80 states was used. Using a new technique for realtime simulation of stiff systems developed in the RealSim project by Dynasim and DLR [5,6], this model was then semi-automatically partitioned into the slow mechanical part and the fast drive system part involving much smaller time constants. The slow part is discretised with the explicit Euler method whereas the fast part is discretised with the implicit Euler method and both discretisation equations are then symbolically processed by Dymola together with the robot model to produce fast real-time code. This mixed-mode integration approach resulted in a performance improvement of more than 15 with respect to the high quality, variable step-size integrator DASSL and to the fixed step-size methods of explicit and of implicit Euler. The simulation model run on a 650 MHz desktop PC easily in real-time, while receiving input from a KUKA office PC running the original KUKA control software. The setup of the complete real-time simulation system is shown in fig. 17. In the simulation, the deviation between the commanded path of the robot and its real path was evaluated. During the motion of the robot, an online animation with robot CAD data, where the size and direction of the deviation was visualised on the desktop PC, gave immediate visual feedback (see figure fig. 18). 48

49 KUKA Office PC (robot control with realtime operating system) Desktop PC (online robot simulation + animation) KUKA Control Panel (teaching, program definition) Fig. 17: Real time optimisation system. Fig. 18: Visualisation of the deviation between commanded and real path in the simulated robot. 49

50 The simulation displayed a high correlation with the performance of a real robot of this type. A picture from the online teaching with the KUKA control panel and the online visualisation of the robot is shown in fig. 19. Fig. 19: Interaction and visualisation of robot real-time simulation. 50

51 6 Optimisation Case Study The performance of the tools developed in RealSim, particularly of the automatic optimisation tool, was investigated in a case study. Sections 6.1 and 6.2 describe the definition of the design task and the optimisation parameters in this study. The selection of path data is illustrated in section 6.3. Sections 6.4 and 6.5 focus on the optimisation procedure and the results gained from it. Validation was performed through real-time simulation on a real robot controller (section 6.6). The results of the study are discussed in section Task Definition To test the RealSim optimisation tool, the following task was defined: The KR 125/2 robot (see fig. 20), which was designed as a generalpurpose robot, is to be optimised for a specific application. The new special model is to be suitable in particular for spot welding. This task means that the robot requires high accelerations to be able to move quickly over the short distances between weld spots. The final axis velocity is reached only very occasionally. The mass, mass inertia and the location of the centre of gravity must remain the same for the load and any supplementary loads. The link lengths shall remain unchanged, as new structural components entail major changes to the structure of the machine, as well as being extremely costly. Since this also predetermines the form of the gear units, the size of these is also to remain unchanged. The motor types for the main axes may 51

52 be modified, as long as the new motor fits into the space available. The filling pressure of the counterbalancing system may be changed. Fig. 20: KR 125/2 standard robot. Selecting an existing robot design as a starting point for an assessment of the optimisation tool had a number of significant advantages as compared to designing a new robot from scratch: All the technical details of the design are known. If, therefore, parameters are changed as a result of the optimisation, then a comparison with reality is no problem. Cycle time comparisons can be simulated on the real robot controller for reference. And the technical viability of the optimisation results can also be easily determined. All this made it much simpler to assess the function and efficiency of the new optimisation tool. 52

53 6.2 Parameters for Optimisation In the case study, the parameters available for optimisation were the gear ratios, the main axis motor types, and the pressure parameters of the counterbalancing system Gear ratios The gear ratio has a substantial influence on the motion characteristics of the robot. On the one hand, it determines the torque load of the motor, and on the other, it has a considerable influence on the dynamic characteristics. A low gear ratio allows high final velocities for a constant motor speed. However, as the motor torque is also transformed only to a small degree, the acceleration characteristics are usually less favourable. Exactly the opposite effect can be observed with high gear ratios. A highly geared motor torque allows a favourable acceleration characteristic, whereas the final speed becomes much lower as the motor speed is of course also limited. As there are technical limits to the magnitude of the ratio change, the window of change was fixed at ±20% of the starting value. If a larger variation should become necessary, then it is left to the operator to allow this or not. In this way, it will be possible to take into account technical constraints which are not considered in the simulation Motor types Since the number of motor variants is to be kept as small as possible for technical reasons, only two motor types, both already in use, were made available for selection. The motor type was only investigated 53

54 for axes 1, 2 and 3, as different motor sizes are in use for the wrist axes. Furthermore, it seems likely that a variation of the wrist axis motors would only yield slight improvements, since the gear units are usually the weakest link in the drive chain in the robot wrist. Both of the motor types available for selection have a large enough holding torque to hold the robot in its current form safely in all positions and in all load conditions. If, however, the gear unit or the counterbalancing system is changed, then it will also be necessary to test the holding torque again. The motors can be characterised as follows: Motor 1 (currently used in this robot): Maximum speed not very high Favourable KT factor, resulting in efficient conversion of current into torque Low rotor inertia Motor 2 (alternative motor from another robot type): Much higher maximum speed KT factor somewhat poorer Somewhat higher rotor inertia Note: The KT factor specifies the ratio of the generated torque [Nm] to the input current [A]. The KT factor depends, among other things, on the form of the motor winding. For each of the three main axes, either motor may be used, irrespective of the choice of motor made for the other main axes. 54

55 6.2.3 Counterbalancing system The KR 125/2 robot under investigation is equipped with a counterbalancing system based on a gas spring, which applies a supporting torque to axis 2. Since the connecting dimensions of this system are directly dependent on the design of the castings, changes to the main dimensions are not possible here either. The only parameter that can be changed without major structural alterations is the system pressure. This can theoretically be increased right up to the technically permissible limit. However, this is subject to the constraint that the robot must be able to safely maintain any position with the set pressure, irrespective of the load carried. An excessively high pressure can have an adverse effect, particularly when the robot is not loaded. Here again, a permissible value window of ± 20% was set for the starting value, which may be modified if necessary by the experienced user. In general, the effect of the counterbalancing system cannot be precisely predicted. The force applied by the cylinder is an approximately linear function of the system pressure and the cylinder position. However, as the cylinder acts via a lever rotating about the robot axis, there is an additional component in the form of an angular function, which is difficult to calculate. 6.3 Path Data As described, the existing general-purpose robot KR 125/2 is to be optimised for spot welding applications. In order to achieve a useful result for as many applications as possible, the optimisation should also be carried out with a large number of different spot welding 55

56 paths. To keep the scope of the investigation manageable, only three robot paths were used. These programs, named TUER1, TUER2 and BMWTAKT2, are classic spot welding programs with the usual sequence: Start from the rest position Longer movement to the first weld spot and complete halt of the robot Several short movements to further weld spots, each with a stop Possible reorientation of the tool and motion to further weld spots Final return to the rest position. This basically similar sequence results from the line cycle of the automotive industry. But as most spot welding robots are indeed used in this sector, an adaptation to this sequence would certainly have great practical relevance. No idle times are included in the programs. These do not depend on the robot itself, but on the welding process or the overall system cycle. Idle times would only be of interest for the design if the cooling of the motor and gear units were included in the simulation. As this is not the case, the lack of idle times has no influence on the configuration of the robot. 6.4 Optimisation Procedure The optimisation procedure is relatively simple and always consists of the same steps. On the one hand, this was the precise intention, and on the other hand, certain steps based on experience (e.g. the selection of path data) cannot be automated. 56

57 Fig. 21: Input / Output screen of the optimiser. The following steps are performed (see fig. 21): Selection of the robot. Here it is assumed that the pre-design stage is already complete and that the robot has a functioning, but not yet optimised data set. Selection of the motor types used for every axis. Selection of the parameters to be optimised. In the present case, these are the gear ratios, the main axis motor units and the gas pressure of the counterbalancing system. Definition of the permissible value window. In a practical case, this window is likely to be ±10% for each parameter to be optimised, in order to prevent the results from drifting out of 57

58 range. In the current investigation, however, the value window was set to ±20% in order to be able to obtain the results more quickly. Here it is unlikely that a parameter will drift out of range, as the robot is already very well known. Selection of the path data. In the present case, the path data were selected individually. In the course of practical use, a database of path data is to be built up in order to provide a selection of practically relevant data. Definition of the optimisation criteria and their weighting. In the present case, only the criterion of cycle time was chosen, in order to make it easier to interpret the results. The cycle times of the paths are weighted relative to each other in order to define which path should be optimised most. In the example in fig. 21, the desired improvement of the three different active paths tuer1, tuer2 and bmwtakt2 are weighted equally. If the optimisation results in an unbalanced improvement of the paths (as this is usually the case), the user should increase the desired improvements for the paths where the cycle time was not improved enough. This will result in a different weighting of the path cycle times in the optimisation. Start and output of the result. Once started, the user has no influence on the optimisation procedure. The result statement contains not only the new parameter values but also the percentage improvement of the optimisation criteria (in this case, the cycle time). In addition, various states and changes are presented graphically. 58

59 Fig. 22: Automatic visualisation of the KR 125/2 robot in the RealSim tool based solely on the CAD and optimisation data. 6.5 Optimisation Results The optimisation results of this case study show quite clearly that limited mechanical modifications of the standard KR 125/2 robot would not lead to significant performance improvements in spot welding tasks. The percentage improvements of the cycle time to be gained can be seen from the table below: Robot path Original cycle time Optimised cycle time TUER1 18,097 s 17,842 s 1.41 % TUER2 12,514 s 12,335 s 1,42 % Percentage improvement BMWTAKT2 25,473 s 24,828 s 2,53 % 59

60 Note: The cycle times appear quite short. If one considers that the line cycle time in an automotive manufacturing system is barely shorter that 45 seconds, then these robot times are very short. However, it must be remembered that we are not dealing with a normal program running on a robot controller. The robot does not have to wait for any process signals and also always moves at maximum velocity, which is hardly possible in practice. Moreover, as already mentioned, these programs do not contain any process times of the weld gun or waiting times in the rest position. Changes in the parameters to be optimised: All gear ratios were slightly reduced. This resulted in a slight increase in the final velocity. Due to the changed torque situation, the load torque on the motor increased somewhat, while the mass moment of inertia of the drive train was reduced. This result was not entirely expected, but due to the power reserves of the motors, the result is not too surprising. The pressure of the counterbalancing system was increased by approx. 20 bar. Taking into account the reduced gear ratio of gear unit A 2, this would certainly seem realistic. In this way, the torque acting on motor A 2, which increased due to the change in gear ratio, is reduced again. Furthermore, the spot welding paths involve motion only in the front half of the robot s work envelope. Due to the overall design, an excessively high pressure can have an adverse effect, particularly in the rear half of the work envelope. The technically permissible limit for this parameter is also not yet reached. However, this effect does not occur here, and there is thus no obstacle to the increase. 60

61 On all three main axes, motor type 1 continues to be used. Due to the reduced gear ratios, the final velocity was increased, although the power potential of the motors is still sufficient for high acceleration. The required final velocity was not so great, however, to justify motors of type 2. These would most probably have been used if the gear ratios had been increased. These results lie within the expected range of values, although the improvements are relatively small. The reason for this presumably lies in the parameters selected for optimisation. As already mentioned, the KR 125/2 has been in service for a considerable time and already represents the first facelift of the KR 125 series. The system itself is thus already very well adapted, and spot welding applications would seem to differ too little from the design cases to yield any great changes. Furthermore, the performance of the modified components was not optimised. A significant improvement in the cycle time is only likely if the capacity of the motors and gears is increased, or with paths that differ considerably from the usual robot motions. However, such a robot would then be so different from the original type that it would have to be seen as an independent variant and not as a derived special-purpose version. 6.6 Validation of Optimisation Results Due to the fact that idle times could not be taken into account in the optimisation (as already mentioned), validation on a KUKA robot controller is difficult. Even simply deleting the idle and signal times does not produce a one-to-one result, since commands such as approximation of contour points in the path, various acceleration 61

62 parameters, and the switch between LIN and PTP motions cannot be taken into account to the same extent in the optimisation. For this reason, no direct time comparison was carried out. The programs were simulated in their original form on the robot controller and the results were recorded. A second simulation was then carried out with the changed machine data. Fig. 23 shows the controller simulation. Fig. 23: Visualisation of the KUKA controller simulation. Results of the validation: Robot path Original cycle time Optimized cycle time TUER1 38,8 s 38,1 s 1,80 % TUER2 35,4 s 34,7 s 1,98 % Percentage improvement BMWTAKT2 75,5 s 73,2 s 3,05 % 62