SimMechanics, MapleSim and Dymola: a first look on three multibody packages
J.J.P. van Boekel DCT 2009.060
Bachelor Final Project report
Coach(es): dr. ir. I.J.M. Besselink
Supervisor: prof. dr. H. Nijmeijer
Technische Universiteit Eindhoven Department Mechanical Engineering Dynamics and Control Technology Group
Eindhoven, June 2009
Contents
Abstract4
Introduction5
1 Building a half-car multibody model7 1.1 Construction of a half-car model...... 8 1.2 Simulation performance...... 14
2 Verification & error handling 16 2.1 Testcase 1: absent connection between joint and car-body.... 16 2.2 Testcase 2: mass not specified, equal to zero...... 18
3 Numerical accuracy 20 3.1 Analytical model...... 20 3.2 Simulated model...... 22 3.3 Comparison...... 25
4 Visualisation of multibody models 27
5 Parametrisation of model variables 30 5.1 Specifying global parameters in Simulink/SimMechanics..... 30 5.2 Specifying global parameters in MapleSim...... 31 5.3 Specifying global parameters in Dymola...... 32 5.4 Dymola’s ’Experimentation Package’...... 32
6 Exporting and interchangeability 35 6.1 MapleSim...... 35 6.2 Dymola...... 36
7 Closed-loop systems behaviour 38
2 CONTENTS 3
8 Dymola Vehicle Dynamics Library 43 8.1 Introduction...... 43 8.2 Adaptability...... 43 8.3 Visualization...... 47 8.4 Performance...... 48
9 Conclusion 50
References 53
A SimMechanics windows 54
B MapleSim windows 56
C Dymola windows 59
D MapleSim C-code 65 Abstract
In this report, an comparison between three multibody packages (Simulink/Sim- Mechanics, MapleSim and Dymola) is made in order to check whether or not MapleSim or Dymola would be an suitable alternative to the now used multi- body software SimMechanics. Some important aspects are investigated by us- ing some simple models. A half-car is constructed and analysed from which is concluded that no big differences in simulation speed are present, but this is mainly due to the simplicity of the investigated models. Based on two testcases, an opinion regarding verification and error handling is given. By using a double pendulum system, a comparison is made based upon the accuracy of all three packages. This is done by comparing the results that the software gives with the results of an analytical derived equation of motion. Both MapleSim and Dymola are offering build-in functionalities for parametrization of model vari- ables which are investigated in this report. It is concluded that most of these functions could also be accomplished by making a few lines of code in MAT- LAB. The interchangeability functionalities are also investigated. In MapleSim, C-code can be exported use in for example MATLAB/Simulink. Dymola offers a functionality called the ’DymolaBlock’. This block can be used in a Simulink environment to load a model made in Dymola directly into the Simulink model. Closed-loop behaviour is checked by means of deliberately miss-aligning two component of a closed-loop system. It is checked how the software reacts to this and if and how the error is reported. Finally, the ’Vehicle Dynamics Library’ from Dymola is studied. An example model is investigated and a conclusion is made regarding adaptability of models. Also, visualization and performance aspects are discussed.
4 Introduction
Because of the continuous increase of computer power, the use of simulation tools is still growing. Multibody software for vehicle dynamics has been gaining popularity thanks to advantages the use of this type of software brings. Nowa- days many companies produce multibody software tools and thanks to this, the software is still getting better, faster and more reliable. Until now, Eindhoven University of Technology (TU/e) has primarily been using the multibody software called ’SimMechanics’ which is part of MAT- LAB/Simulink. This product is very widely used and has a great number of users around the world. One drawback of SimMechanics is the limited process- ing speed which makes it nearly impossible to perform real-time simulations. Another drawback is the lack of modern and fast visualization possibilities. An overall view concerning SimMechanics is that it lacks development pace over the past years. TU/e is exploring alternatives concerning multibody packages that can perform at least the same tasks as SimMechanics and should be faster regarding com- putation speeds and offers better possibilities to create code which is used for real-time capable models. In order to find a possible substitute for SimMechan- ics, two new multibody packages have been examined. The first package that is examined and compared to SimMechanics is called ’MapleSim’ (version 1.0). This package is created by the company ’MapleSoft’ and runs on the mathematical engine from Maple (version 12.02). The second package is called ’Dymola’ (version 7.1) and is created by the company ’Dynasim AB’. In chapter 1, a simple half-car model is build in all three packages, so that user friendliness of the software can be examined. Also, different aspects of building and analyzing a model are treated in this chapter. In chapter 2, the same half- car model is used to investigate how the packages deal with modelling errors and how they do inform the user. After this, in chapter 3 a double pendulum model is constructed. By means of this model, the numerical accuracy of all three packages is studied. In chapter 4, the visualization possibilities of the three multibody packages is explored. Chapter 5 deals with the parametrisation aspect of multibody models. By parametrize specific model variables, a model can be evaluated by varying some pre-defined model-properties. In chapter 6, interchangeability is discussed. By exporting models to C-code, this fast and efficient code can be used to perform for example ’Hardware In the Loop’ (HIL) simulations. Chapter 7 deals with a special but common kind of multibody
5 CONTENTS 6 systems, so called ’closed-loop systems’. In this chapter we investigate how the packages deal when components are not fully aligned to each other. Chapter 8 of this report handles the Dymola Vehicle Dynamics Library. Different aspects of this library are discussed and explained.
Acknowlegments
First of all, special thanks goes to my supervisor Igo Besselink for the help with the project and creating the report. Furthermore, I want to thank Gosé Fis- cher of CANdiensten, for providing MapleSim and helping me with problems or questions about MapleSim. Also I want to thank Mike Dempsey of Claytex Ser- vices Limited for providing Dymola and helping me with problems or questions concerning Dymola and the Vehicle Dynamics Library.
Disclaimer
This report is the work of a Bachelor student and does not necessarily reflect the opinion of the Eindhoven University of Technology in gen- eral. The student has previous experience with MATLAB/Simulink, but no experience with SimMechanics, MapleSim or Dymola at the start of the project. The student has spent about 15 weeks to study the different packages and to do the analysis described in this report. Chapter 1
Building a half-car multibody model
In this chapter we will consider how models are constructed in both Simulink/Sim- Mechanics, MapleSim and Dymola. In the first section of this chapter, the Modelica Language is discussed. This language is used to construct models in both MapleSim and Dymola. In order to give an objective view of all three packages, in the second section a relative simple half-car model is modeled. Dif- ferent aspect regarding usability of the software and construction of models are discussed.
The Modelica Language
Both Dymola and MapleSim make use of the Modelica language. Modelica is a free object-oriented modeling language with a textual definition to describe physical systems in a convenient way by differential, algebraic and discrete equa- tions. An example such a textual representation of a model is showed in figure 1.1. The text in this figure represents a parallel spring-damper component. In the top of the screen some parameters and input files are stated after which the actual equation of motion (f = c(s − s_unstretched) + ds˙) is introduced. One can easily identify s as being the prolongation of the spring and c and d as being the stiffness and damping-coefficient of respectively the spring and the damper. der(s) means the derivative of s, the elongation of the spring. The Modelica language is suited for multi-domain modeling and involves for example mechanical, electrical or hydraulic applications. In order to guarantee the interoperability of the modeling language, a free ’Modelica Standard Library’ is available. Furthermore, more both free and commercial Modelica libraries are available. An elaborate description of the Modelica language and a user manual/handbook can be found in [4].
7 CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL 8
Figure 1.1: An textual representation of a parallel spring-damper component
1.1 Construction of a half-car model
In order to give an opinion about the user friendliness of all three packages, a half-car model (illustrated in figure 1.2) is constructed. The model consists of a sprung car-body mass and two unsprung masses that represents the suspension- and wheel-masses. Two spring-damper components represents the suspension of the half-car. Tyre-stiffness is introduced by means of a spring between the road-profile and the unsprung masses. CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL 9
The numerical values of the model parameters are:
m_sprung = 700 [kg] I_z = 1000 [kgm2] k_rear = 25000 [N/m] k_front = 18000 [N/m] d_rear = 1800 [Ns/m] d_front = 1500 [Ns/m] m_unsprung_rear = 45 [kg] m_unsprung_front = 40 [kg] k_tyre = 2e5 [N/m]
Because a variable road height profile is used as an input to simulate the re- sponse of the half-car, the vertical tyre force is dependent from both the vertical position of the unsprung mass as from the height of the road-surface. Therefore, the vertical tyre force is calculated as the distance between the road and the unsprung mass multiplied with the vertical tyre stiffness. The resulting signal is applied to the unsprung mass as a force which is acting in vertical direction.
m_sprung I_z Sprung mass
k_rear k_front d_rear Spring/damper d_front
m_unsprung_rear Unsprung mass m_unsprung_front
k_tyre Tyre spring k_tyre
Road profile
Figure 1.2: A graphical representation of a half-car model
SimMechanics
In SimMechanics, models are constructed by dragging components from the ’Simulink Library Browser’ into the modeling window. The SimMechanics model of a half-car is showed in figure 1.3. By clicking a specific component, parameters and settings can be changed (see figure A.1 in Appendix A for CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL 10 the car-mass block). In SimMechanics, coordinate frames are attached to the body. Subsequently, joints are attached between these coordinate frames. A ’planar’-joint is placed between the car-body and the ground-frame to enable a 2D-motion of the model. The spring and damper are accounted for by attaching a so-called ’Joint Spring & Damper’ to a prismatic joint between the unsprung mass and the car-body. By attaching a ’Body-Sensor’ to a coordinate frame port of the unsprung mass body, the height of the body can be measured and again be used as a input signal. Since this component measures the position of the body in all three directions, the easiest way is to use a so called ’demux’-block. Using this block, we can specify which components of the signals to use. The number next to the line between the ’Body-Sensor’ and the ’demux’-block indicates that we are dealing with 3 signals. From the ’demux’-block it is unclear which signals we selected, so this has to be determined by experimentation. The road-profile is introduced by specifying a road-height signal (as a function of the horizontal coordinate) in a 1D look-up-table. Depending on the horizontal position of the unsprung mass, a road-height is calculated, which is subtracted from the vertical position of the mass. By multiplying this signal with a constant (tyre-stiffness), a vertical spring-force is obtained. This force is applied to the unsprung mass using a ’Body-Actuator’ that is connected to the desired coordinate-system of the body.
Figure 1.3: The half-car model in SimMechanics CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL 11
Results can be loaded into the MATLAB Workspace by connecting a ’To Workspace’- block to a specific signal obtained from e.g. a ’Body-Sensor’. During simulation, signals can be graphically presented using a ’scope’ (see figure A.2 which repre- sents the vertical position of the unsprung mass). This ’scope’ can be attached directly to a signal-line and is showed automatically when simulating the model. When double-clicking a specific component, the parameters-window appears where also a brief description of the component is found. When right-clicking a model and choose ’Help’ a more elaborate description of the specific model is showed in a separate screen.
MapleSim
Just like with SimMechanics, components are dragged from the ’Library Browser’ into the modeling screen. As can be seen in figure 1.4 just like SimMechanics, the model consists of a sprung mass, two unsprung masses, a world frame and other components needed for simulating the tyre-force. The main difference with SimMechanics is the construction of coordinate frames. In contrary to SimMe- chanics where these frames were specified within the body block, in MapleSim extra frames are constructed by adding so-called ’Rigid Body Frames’. These blocks can be used to construct a fixed translation and rotation with respect to another coordinate frame. Another difference with respect to SimMechanics is how the spring-damper is constructed. Whereas SimMechanics requires the use of an extra ’Joint Spring & Damper’-block, MapleSim has an option to specify stiffness and damping directly within the ’Prismatic Joint’-block. Tire stiffness is accounted for in basically the same way as was done in SimMechanics, again the ’demux’-block does not specify which signal is extracted. By clicking a com- ponent, the ’Parameters’ window on the right of the screen displays the possible parameters that are applicable for the concerning component. An example of such a screen is given in figure B.1 for one of the unsprung masses. As can be seen, for this component, mass-properties can be specified as well as some initial position and orientation properties. A nice feature of MapleSim is the ’Components’-window (see figure B.2). In this window, a hierarchic view of the model is given. Using this window, all components that are present in the model can be seen at a glance. When selecting a component, the connection-ports of that specific part are displayed. After right-clicking a component and selecting the ’Help on ...’ line, elaborate information about the specific component is showed in a separate help-window. As can be seen in figure 1.4, for some specific components MapleSim uses differ- ent colors for connection-lines and different connection-port-symbols. By doing this, it’s easy to make a distinction between different sort of signals such as multibody-signals, 1D-mechanical-signals or normal signal lines and between inputs or outputs. A elaborate explanation about all signals and symbols are found in the MapleSim user-manual. Results can be plotted by attaching probes to the connection lines of the model. In contrast to the probes in SimMechanics, MapleSim cannot ’live-visualize’ sig- nals. When attaching a probe, a screen appears in which the desired output signal(s) can be chosen (see figure B.3). After attaching probes and specify- CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL 12
Figure 1.4: The half-car model in MapleSim ing signals, x- and y-axis variables have to be chosen (see figure B.4). After simulating, a ’Plot Window’ appears (see figure B.5). In this window, line and axis properties can be changed. Also, graph can be exported to various type of image-formats.
Dymola
In Dymola, the half-car model is constructed in basically the same way as was done in MapleSim (see figure 1.5). Again, components are dragged from the li- brary into the modeling-window. The car-body is modeled as a ’bodyShape’ which can be interpreted as being a mass with two coordinate-frames, just like what was done in MapleSim using a body block with two ’Rigid Body Frames’. By using an ’Absolute Position’-block, we can extract the horizontal and vertical position signal of the body. Here, we don’t need an ’demux’-block because Dymola directly asks which signal to use when dragging a line from the ’Absolute-Position’-block (see figure C.1). Parameters can be changed by double-clicking a component, an example of the ’parameter-window’ is showed in figure C.2 for the car-body. Other than MapleSim and SimMechanics, Dy- mola shows some parameters such as mass and stiffness/damping directly into the top-view which is particularly handy when checking the model. By clicking CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL 13
’Info’ in the ’parameters’-window, an elaborate description of the selected com- ponent appears in a new help-window. Like MapleSim, Dymola uses different colors for connection lines specifying the signal-type. Similar to MapleSim, Dymola also offers a ’Component-Browser’, showed in figure C.3. Like MapleSim, the browser represents a hierarchic view of the components that are present in the model, as well as the connection-ports of a specific component. By right-clicking a component in the browser and choose for ’Info’, a similar information-window as discussed above will appear.
Figure 1.5: The half-car model in Dymola
An advantage of Dymola with respect to MapleSim and SimMechanics is that all input and output signals can be plotted after the model has been simulated. Therefore, in Dymola no probes have to be attached to the model and no axis- properties have to be specified before simulating a model. If needed, adjusting the plot characteristics can be done after simulating the model, using the ’plot- setup’-window (see figure C.4). CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL 14
1.2 Simulation performance
As will be discussed in more detail in section 3.3, when using default simulation settings, big differences in accuracy can occur. Inevitable, this also influences the performance and speed of a simulation. Therefore, the same simulation settings as described in section 3.3 are used, because these settings give basically the same results with respect to accuracy. By using these simulation settings, a global indication regarding simulation-speed can be given. To check performance, the half-car-model is used again. The half-car model is simulated for 10 seconds. The numerical integrator settings (error tolerances and algorithms) are adjusted so that they are identical (as far as possible) in all three packages. The simulations are done with the same 1.86 GHz processor laptop that is freshly started every simulation to guarantee identical circumstances. Nevertheless, no ’strict’ conclusions concerning simulation-speed can be made because of the relative simplicity of the half-car model and because of structural difference between the investigated multi-body packages. An example of this can be given when we look at the way results are presented; in Dymola all signals can be accessed after simulation, in SimMechanics and MapleSim distinctive result-signals have to be chosen prior to simulation. In SimMechanics, the total simulating time for the half-car model is about 22 seconds. No additional information regarding the time needed for compiling the model equations and solving the equations is available. Simulating the half-car model in MapleSim takes approximately 19 seconds in total from which, according to the status-window, about 7 seconds in used for compiling the model equations and about 12 seconds is needed for solving the equations and make data plots. When we, under similar conditions, simulate the half-car model in Dymola, we can see that Dymola requires about 13 seconds simulation time. The time needed for translating the model is about 10 seconds, the residual 3 seconds are used to integrate the model-equations and process the data. Another aspect of software-performance that has to be mentioned is startup- time. When we look at MapleSim, the software itself is ready-to-use in about 20 seconds and the half-car model is loaded in about 2 seconds. Dymola requires 10 seconds for initializing and a model is opened in approximately 5 seconds. Because the slow-loading MATLAB software is needed to use Simulink/SimMe- chanics, starting-up SimMechanics requires significant more loading-time com- pared to MapleSim and Dymola. SimMechics is ready-to-use after about 80 seconds (which includes starting MATLAB and Simulink). Opening a model takes another 8 seconds. From the preceding experience, we can conclude that Dymola is the fastest with simulating the half-car model, but the differences with MapleSim and Sim- Mechanics are not significant. Nevertheless, the results give a first indication regarding the simulation speeds. However, this simple half-car model does not represent the practical use of a multibody package where much more complicated models will be created. When we really want to check if major differences in simulation time would occur, three extensive identical models should be build CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL 15 in all three packages. What we can conclude regarding start-up time is that Simulink/SimMechanics needs significantly more time to start than MapleSim and Dymola. The start-up time differences between MapleSim and Dymola are in the order of seconds, in favour of Dymola. Chapter 2
Verification & error handling
When constructing complex models, it’s important that possible modelling er- rors can be traced efficiently. Therefore, error-messages given by the software should be clarifying in order to localize the error. In order to check error-messages and verification, two half-car model (see chapter 1) test-cases are examined in which we deliberately cause an error. In the first case, we ’forget’ to attach one of the prismatic joints to the car-body. In the second case, we don’t specify a mass-value to the car body. In both cases we investigate how the three packages react and how they report the error. The question ’can we efficiently trace the fault by looking to the error-message?’ is answered after that.
2.1 Testcase 1: absent connection between joint and car-body
SimMechanics
When performing testcase 1 to the SimMechanics model, an error-message as showed in figure 2.1 appears. The message is not directly indicating where the fault occurs in the model, but from the fact that there is, however, a ’Ground- block’ present in the model we can conclude that somewhere, the rest of the model is not connected to it.
MapleSim
If we look at the error-message which is produced in MapleSim (see figure 2.2) we see a error-message which is explained by means of an error in the mathematic calculation. From this message we haven’t got a clue where to find the fault and what causes it. Because of these ’cryptic’ error messages, in practice it’s very hard to construct a model for the first time because no clear information about
16 CHAPTER 2. VERIFICATION & ERROR HANDLING 17
Figure 2.1: SimMechanics error message belonging to testcase 1 the location and characteristic of the fault is given when the model contains an error.
Figure 2.2: MapleSim error message belonging to testcase 1
Dymola
When performing the same testcase in Dymola, an error-message like figure 2.3 appears. From the sentences "Connector frame-b of joint object is not con- nected" and "Connector frame-b of line force object is not connected" it becomes very clear what was done wrong and where the fault is located in the model. CHAPTER 2. VERIFICATION & ERROR HANDLING 18
Figure 2.3: Dymola error message belonging to testcase 1
2.2 Testcase 2: mass not specified, equal to zero
SimMechanics
When looking at the error-message produced by SimMechanics (see figure 2.4), from just reading the message that the mass of the car body is not specified.
Figure 2.4: SymMechanics error message belonging to testcase 2
MapleSim
In MapleSim, a value which is obliged (such as the mass of a body) cannot be deleted. When trying to escape the default value, it is changed into a value of 1 [kg].
Dymola
When in Dymola deliberately a mass-value is not specified, the program does not produces an error-message. Apparently, a default value is chosen if no value is specified. When we look at the plots to check this, we indeed can see that Dymola uses a default value of 1 [kg] for the mass of the car-body, without informing the user. This can be a bit tricky, because the behavior of the half-car CHAPTER 2. VERIFICATION & ERROR HANDLING 19 becomes completely different. What we do see is that the mass-value indicated in the top-screen of the model is changed into m which indicates that no numeric value for the mass of the car-body has been chosen. Chapter 3
Numerical accuracy
In order to check the numerical accuracy of all three packages a relative simple 2D double pendulum model is modeled. By comparing the resulting motion induced by two initial conditions (for both θ1 and θ2) with an analytical derived equation, the software accuracy can be checked. A schematic drawing of the analysed double pendulum is showed in figure 3.1. The masses m1, m2 and also the length l1 and l2 of the pendulum are kept constant in all simulations. The pi initial condition are also kept constant and will be θ1 = 4 and θ2 = 0.
l _
1
θ1
m_1
l_ θ2 2
m_2
Figure 3.1: The double pendulum reference model
3.1 Analytical model
The double pendulum system will be analysed by hand using the Langrangian method (3.1).
20 CHAPTER 3. NUMERICAL ACCURACY 21
d T, − T, + V, = (Qnc)T (3.1) dt ˙q q q Where the generalized coordinates are chosen to be:
q θ q = 1 = 1 (3.2) q2 θ2 and the kinetic energy:
1 T = ˙qT M ˙q (3.3) 2 with M the mass-matrix of the system:
n X T M = mi(ri,q) ri,q (3.4) i=1 where ri,q represents the derivative of the position vector of mass mi with respect to the generalized coordinates (3.2). The mass-matrix becomes:
2 (m1 + m2)l1 m2l1l2(cosθ1cosθ2 + sinθ1sinθ2) M = 2 m2l1l2(cosθ1cosθ2 + sinθ1sinθ2) m2l2 (3.5) and using this result the kinetic energy T becomes:
1 2 1 2 T = m l θ˙ + m (l2θ˙ + l2θ˙ + 2l l θ˙ θ˙ cos(θ − θ )) (3.6) 2 1 1 1 2 2 1 1 2 2 1 2 1 2 1 2 Because no springs are involved in the system the potential energy becomes:
V = U in(q) + V ex(q) = V ex(q) (3.7) and thus becomes:
V = −m1gl1cosθ1 − m2g(l1cosθ1 + l2cosθ2) (3.8)
And because no non-conservative forces are involved:
Qnc = 0 (3.9)
When vector equation (3.1) is evaluated and then rewritten to θ¨1 and θ¨2 as a function of θ˙1, θ˙2, θ1 and θ2 (angles and angular-velocity of both generalized coördinates), two second order differential equations of motion are obtained: CHAPTER 3. NUMERICAL ACCURACY 22
2 θ¨1 = m2gsinθ2B − m2l2θ˙2 A − Cgsinθ1− (3.10) 2 2 m2l1θ˙1 AB / Cl1 − m2l1A
2 θ¨2 = m2l2θ˙2 AB + Cgsinθ1cos(θ1 + θ2)+ (3.11) 2 2 Cl1θ˙1 A + Cgsinθ2 / Cl2 − m2l2B
With:
A = sin(θ1 − θ2)
B = cos(θ1 − θ2)
C = (m1 + m2)
Using Matlab’s ODE45 integration method, differential equations (3.10) and (3.11) are solved numerically. The results are plotted as θ1 against θ2 in figure 3.2 for 0 ≤ t ≤ 5s.
Figure 3.2: Plot of the double pendulum motion
3.2 Simulated model
The double pendulum system is modeled in all three multibody packages. By using the same parameters and initial conditions as in the analytical model, an indication regarding the accuracy of all three programs can be made. CHAPTER 3. NUMERICAL ACCURACY 23
SimMechanics
First off all, the double pendulum is modeled in SimMechanics. The model consists of a world reference, two point masses and two revolute joints. Two initial conditions are given via the ’Joint Initial Condition’ component in which the intitial angles θ1 and θ2 are specified.
Figure 3.3: Visualisation of double pen- Figure 3.4: Model of double pendulum dulum in SimMechanics in SimMechanics
MapleSim
The double pendulum is also modeled in MapleSim. Again, the model consists of a world reference, two body’s with zero inertia (point masses) and two revolute joins. The initial conditions are given within the joint-block in contrary to SimMechanics which uses an extra ’Initial Condition’ attached to the joint.
Dymola
Finally, the double pendulum is modeled in Dymola. As in SimMechanics and MapleSim, the model again consists of a world reference, two body’s and two revolute joints. The initial conditions are (as in MapleSim) specified within the joints. CHAPTER 3. NUMERICAL ACCURACY 24
Figure 3.5: Model of double pendulum in MapleSim
Figure 3.6: Visualisation of double pen- Figure 3.7: Model of double pendulum dulum in Dymola in Dymola CHAPTER 3. NUMERICAL ACCURACY 25
3.3 Comparison
In this section the absolute errors of the different packages with respect to the an- alytical model are examined. By choosing very small absolute and relative error tolerances (1e-9) for solving the stated ODE’s (3.10) and (3.11), this numerical solution can be interpreted as the ’exact’ solution of the double-pendulum prob- lem and therefore differences with respect to the ’exact’ solution can be fully attributed to errors made by the multibody package.
Default integrator settings
First, a comparison is made based on the default settings of the three multibody packages. Only the simulation time and the number of time-steps is adjusted (in order to compare the results).
−3 −3 x 10 Absolute error in θ1 x 10 Absolute error in θ2 2.5 3 SimMechanics SimMechanics MapleSim MapleSim 2 Dymola 2 Dymola
1.5
1 1
0.5 0 error [rad] error [rad] 0 −1
−0.5
−2 −1
−1.5 −3 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 time [s] time [s]
Figure 3.8: Absolute error on θ1 Figure 3.9: Absolute error on θ2
As can be seen in the preceding plots, the absolute error of Dymola is much greater than that of Simulink and MapleSim. This can be explained if we look at the simulation settings. Where Simulink and MapleSim both are using a default error tolerance (for both absolute and relative error) of 1e-7, Dymola uses an error tolerance of 1e-4. As well, by default Dymola uses a different numerical method for solving ODE’s, namely the ’Dassl’-algorithm, where Simulink and MapleSim both use an algorithm based on the ’Runga-Kutta’-method (for non- stiff systems). As can be seen, the absolute error for all three packages does not exceed 3 · 10−3 [rad]. CHAPTER 3. NUMERICAL ACCURACY 26
Manual setup
In this section similar settings as those of SimMechanics and MapleSim are choosen. The same error tolerance (1e-7) is chosen as well as a solver based on the Runga-Kutta method is used in all three packages. When choosing similar settings, we can check if the absolute errors stay small and see if the errors of all three packages are in the same order of magnitude.
−7 −7 x 10 Absolute error in θ1 x 10 Absolute error in θ2 5 3 SimMechanics MapleSim 4 Dymola 2
3 1
2 0 1 −1 error [rad] error [rad] 0
−2 −1
SimMechanics −2 −3 MapleSim Dymola −3 −4 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 time [s] time [s]
Figure 3.10: Absolute error on θ1 Figure 3.11: Absolute error on θ2
According to figure 3.10 and 3.11 the absolute error of Dymola is lowered with a factor 1e4. This was expected from the fact that the error tolerance in Dy- mola was lowered to 1e-7 (in consensus with tolerances used in MapleSim and Simulink). Also, a ’Dormand-Prince’ method (member of the Runga-Kutta solver) was now used for solving the ODE’s. The absolute error for both θ1 and −7 θ2 now stays within 3 · 10 [rad] for all three packages. What is notable is that the Dymola result is more noisy compared to the other packages and SimMe- chanics still has the smallest error, but is difficult to make a conclusion from this: although the three packages use a member of the Runga-Kutta method for solving the differential equations, the solvers still are not 100% comparable. Chapter 4
Visualisation of multibody models
An important aspect of multibody-software is visualization. With the help of a visualization screen, the assembly of a constructed model can be checked as well as the motion of the model that is being simulated. Possible errors that were made constructing the model (especially when it comes to composition of bodies) are noticed at a glance. Especially when first using multibody-software, such composition-errors are easily made and very hard to find if only plotted data is produced. The same half-car-model used in chapter1 is used here to examine the visualization-aspect.
SimMechanics
SimMechanics offers different ways of visualizing models. First of all, a default view can be used in which only ’centers-of-gravity’, ’coordinate-frames’ and ’body-geometries’ (geometries according to specified coordinate-frames) (see fig- ure 4.1). Since the R2008b-release of Matlab, SimMechanics offers an option to attach user-made .stl-graphics to bodies. In figure 4.2 this was done for the half-car-model by attaching simple rectangles to the sprung mass and the two unsprung masses. Graphics cannot be attached to joints or spring-damper components. During a simulation, the model can be turned, panned and zoomed to investigate a particular component. The animation can be stored into a .avi-file.
MapleSim
A big drawback of the current MapleSim release is that it does not include any visualization functionality. Therefore verification of a constructed model can only be done by checking plots, no visual inspection of the modelled system is possible.
27 CHAPTER 4. VISUALISATION OF MULTIBODY MODELS 28
Figure 4.1: Visualization of the half-car Figure 4.2: Visualization of the half-car model in SimMechanics model using user-defined .stl-graphics
It has to be mentioned that as of may 2009, a new MapleSim version is released (MapleSim 2.0). In this version, a powerful new visualization functionality is introduced. Because of the time-limitation to which this analysis is bound, this new functionality will not be covered here. However, the new MapleSim 2.0 visualization environment was tested briefly and from the first sight, the visualization functionality is working very smooth and responsive.
Dymola
Dymola also offers a visualization functionality, see figure 4.3 for the half-car- model. Nevertheless, it’s far more elaborate than that of SimMechanics. Where in SimMechanics no visualizations can be attached to components other than bodies, Dymola has a build-in visualisation for springs, dampers and joints, and by changing animation-parameters, the way components are displayed in the visualization can be changed. An example is given in figure C.5 where settings can be made for the spring-damper component. Again, the model can be turned, panned and zoomed similar to SimMechanics. One thing that is notable when using the Dymola visualization mode, is that it is working much ’smoother’ than that of SimMechanics. Especially when moving and zooming a model during a simulation, it is much more responsive and graphics are of much higher quality in comparison with SimMechanics’ visualization-mode. CHAPTER 4. VISUALISATION OF MULTIBODY MODELS 29
Figure 4.3: Visualization of the half-car model in Dymola Chapter 5
Parametrisation of model variables
An important aspect of multibody software is parametrisation of the model. By assigning global parameters to a model, multiple individual components can inherit the specified value of this parameter. Therefore, multiple model- parameters can be adjusted by just altering one global-parameter. Another important application of parametrisation is ’model-optimization’. By varing pre-defined parameters, physical models can be simulated for various con- figuration and by analysing the result an optimal value for a certain parameter can be chosen.
5.1 Specifying global parameters in Simulink/Sim- Mechanics
In SimMechanics, global parameters values are specified in the MATLAB workspace and called from the model block-parameters. By constructing a m-file with all parameter-values and calling the SimMechanics model directly from this m-file, parameter values can be set and modified (see figure 5.1).
Figure 5.1: An m-file which runs the model with predefined global parameters
30 CHAPTER 5. PARAMETRISATION OF MODEL VARIABLES 31
5.2 Specifying global parameters in MapleSim
In MapleSim, global parameters are assigned by clicking the ’parameters’ button which displays the ’Global Parameters’ view (see figure 5.2). After assigning some global parameters, the parameter name and default value are displayed in the parameters pane.
Figure 5.2: The ’Global Parameters’ view
Now, for example a global parameter called ’M’ can be assigned as a variable to a individual component and therefore inherit the value of the global parameter ’M’. Not only single global parameters can be assigned to model variables, but also functions of global parameters can be assigned to model parameters. MapleSim offers an application called the ’Parameter Optimization Template’. This template (which opens in MapleSim’s mathematical engine Maple) can be used to test different settings of the model by varying specified global pa- rameters. For each global parameter, a range of values can be specified (see figure 5.3) for which the model is simulated after which the simulation result is visualised in a plot automatically. The defined global parameters can also be assigned to a Maple procedure to perform further analysis tasks.
Figure 5.3: A part of the ’Parameter Optimization Template’ CHAPTER 5. PARAMETRISATION OF MODEL VARIABLES 32
5.3 Specifying global parameters in Dymola
Just like MapleSim, Dymola also offers a possibility to specify global parameteters and assign values to them. In Dymola however, parameters can be assigned as being real physical quantities such as length, time, volume, etc. By dragging a physical variable into the Modelica Text Representation, a window appears in which a discription, name and value can be assigned to a parameter (see figure 5.4) as well as some other parameter settings which is basically the same as was done in MapleSim.
Figure 5.4: The physical parameter declaration window
After specifing some global parameters and assigning values to the parameters, similar to MapleSim global parameters can be assigned to components parame- ters that inherits the numeric value of the global parameter. Dymola also offers the possibility to assign the parameter from a drop-down menu which is handy when many parameters are specified or when the exact name of the parameter is not known. After entering the Dymola Simulation screen, global parameter values can be varied between simulations.
5.4 Dymola’s ’Experimentation Package’
Similar to MapleSim’s ’Parameter Optimization Template’, Dymola offers a library called the ’Experimentation Package’ (see figure 5.5). The Experimen- tation Package provides several ways of analyzing the behavior of a model. The main functions are perturbParameters, sweepParameter, sweepOneParameter, sweepTwoParameters and MonteCarloAnalysis. By choosing the ’perturbParameters’-function, we can check the behavior of a model by pertubating from a nominal value of a parameter. After choosing the parameters to perturb and the percent change of pertubation from the nominal value, a plot can be created which (after selecting the variable to plot) displays the response of the selected variable when varying a parameter. The vertical displacement response of a mass-spring system is plotted in figure 5.6 where both stiffness of the spring and the mass were pertubated 20% from the nominal value. Another way of varying one parameter and check the resulting behavior of the model is done by choosing the ’sweepParameter’-function. With this function, CHAPTER 5. PARAMETRISATION OF MODEL VARIABLES 33
Figure 5.5: The ’Experimentation Package’ library one parameter can be varied over a specified interval by selecting the number of (equidistant) values between this interval. The resulting output variable can again be plotted in a specified time interval, for every parameter value specified. Some other methods for analysing a response are available, explanation and functionality of these methods can be found in the Dymola user manual. To study the dependence of one response with respect to two parameters at the end of the integration interval, the function ’sweepTwoParameters’ is to be used. The setup is almost identical to ’sweepParameter’ and ’sweepOneParameter’. The only difference is that two dependency variables are to be selected instead. Consequently, a 3D-plot is generated for each output-variable. Last but not least, a ’Monte Carlo Analysis’ can be used to analyse parameter behaviour. The ’Monte Carlo Analysis’ is widely used to explore the behavior of a model when the input parameters are multidimensional. For the exact usage and application of this function, the reader is referred to the Dymola manual. Off course, the functionalities regarding parameter-variation offered by MapleSim and Dymola, as discussed in this chapter are effective when it is necessary to vary parameters and investigate behaviour. Nevertheless, in MATLAB/Simulink most of the results acquired by these functionalities can also be accomplished by just making some loops in an MATLAB m-file, in which the model is called (see figure 5.1) and where also a range of values for specified parameters can be used. CHAPTER 5. PARAMETRISATION OF MODEL VARIABLES 34
Figure 5.6: Vertical displacement of the point-mass Chapter 6
Exporting and interchangeability
MATLAB/Simulink is used in all sorts off disciplines. In practice, multibody dynamics often have to cooperate with other engineering disciplines (like elec- trical engineering, systems engineering, control, etc.). Besides, the fact that MATLAB/Simulink is known by much TU/e students, the possibility to export the multibody model to MATLAB/Simulink is highly appreciable and of great interest. In both MapleSim and Dymola, the model is exported to C-code. Thanks to the compactness of this code and because it’s numerically very efficient due to symbolic preprocessing, the code can be used to do real-time simulations or use it in HIL (Hardware In the Loop) applications.
6.1 MapleSim
In MapleSim, C-code is generated directly from the model equations by using MapleSim’s mathematical engine, Maple 12. In this ’Code Generation Template’ variables can be assigned, inputs and output can be specified and parameter val- ues can be changed. In the ’Model Equations’ window (see figure 6.1) the model equations can be explored as well as the model’s parameters, initial conditions, probes and other information. In order to investigate the generated C-code and check if it is understandable even without knowledge of the model from which it arise from, an very simple (point)mass-spring system is modeled. By using distinct values for the mass (1.000123 [kg]), stiffness off the spring (1.23456789 [N/m])and the initial position off the mass (3.33445 [m] in vertical direction), we can easily identify them in the C-code which is found in appendixA. Firstly, some output and state variables are specified. We notice from the com- ment on line 17-31 that Probe1 is specified as an output variable. Some other variables from the model are specified as state variables. On line 146 we can
35 CHAPTER 6. EXPORTING AND INTERCHANGEABILITY 36
Figure 6.1: The ’Model Equations’ window identify our mass and stiffness (both are multiplied by 108. As can bee seen from the code, even for simple code as this it’s hard to identify parameters if the exact value of these parameters is not known. For this part of the code, it would be very handy if it had some more elaborate comment specifying which parameters are being used an what expressions are being solved (expressed sym- bolical). In the lower part of the code initial conditions are specified in which the initial position of the mass is found. Alternatively, MapleSim also offers a so called ’Connectivity Toolbox’. This toolbox enables users to export MapleSim models directly to Simulink. Models are automatically converted to S-function blocks which are directly usable in Simulink. Because this functionality is not a build-in feature of MapleSim and requires the installation of extra software, it has not been examined in this report.
6.2 Dymola
Similar to MapleSim’s ’Connective Toolbox’, Dymola offers a functionality to communicate with MATLAB/Simulink called the ’Dymola-Simulink interface’. Unlike the ’Connective Toolbox’ from MapleSim, this is a build-in feature of Dymola. To use this function, the user should include a Dymola-folder in the MATLAB search path that contains some m-files. After this folder is included, a ’Dymola-Simulink interface’ block called ’DymolaBlock’ appears in the Simulink Library browser (see figure 6.2). This block with the Dymola logo represents the model that is made using Dymola. The DymolaBlock is a shield around an S-function MEX block, i.e., the interface to C-code generated by Dymola for the Modelica model. After compiling the model, the lines left and right of the DymolaBlock are replaced by ports that can be connected to all sorts off CHAPTER 6. EXPORTING AND INTERCHANGEABILITY 37
Simulink-components.
Figure 6.2: Simulink Library containing the ’DymolaBlock’
By double-clicking the DymolaBlock, a Graphical User Interface (GUI) is dis- played (see figure C.6). Using this GUI the DymolaBlock can be configured which involves specifing the Modelica model, compiling the model into a Simulink MEX file, selecting compiler options, setting and resetting parameters and start values, etc. Dymola also offers some M-files that can be used to analyse and run models constructed with Dymola using MATLAB. These M-files run a program called ’Dymosim’. Dymosim essentially is a stand-alone program without any graph- ical user interface which reads the experiment description from an input file, performs one simulation run, stores the result in an output file and terminates. By using some pre-defined functions found in the M-files bundled with Dymola, output can be imported into MATLAB as plots, and signals can be extracted from files made by Dymosim. Also by specifying an input function, parameters can varied. Chapter 7
Closed-loop systems behaviour
Closed-loop (or closed-chain) systems are a special, but common kind of multi- body systems. These type of systems require so called ’cut-joints’ to take care of the closed loop. An extra step has to be taken when the equations of motion are compiled. The problem with modeling closed loop systems lies in the fact that the model can exhibit configuration singularities. Consequently, the solution of the kinematic analysis of such a system may, at a certain configuration, either not exists or not be unique. When modeling complex systems it is not always clear to see where and when these singularities occur. Therefore, in this chapter a simple 2D 3-link closed loop mechanism is introduced (see figure 7.1) in which the right ground-frame deliberately placed 0.0001 meter sideways with respect to the lower-end of the right link. This issue occurs in lots of multibody systems that contain a closed-loop, where two specific bodies are attached together (or to the ground-frame) and do not exactly align with each other.
Lateral position error of 0.0001 m.
Figure 7.1: A 2D 3-link closed loop mechanism
38 CHAPTER 7. CLOSED-LOOP SYSTEMS BEHAVIOUR 39
SimMechanics
As can be seen in figure 7.2, the closed-loop system as discussed above is modeled in SimMechanics. In this figure, we can see that a little red cross appears in one of the joints which means that this joint is used as a ’cut-joint’. By assigning a ’cut-joint’ in every independent closed-loop, the problem is solved in a standard way, taking into account that a closed loop is present in the system. A cut-joint is chosen automatically by SimMechanics but other joints can be specified as being the preferred cut-joint. After placing the right ground-block 0.0001 meters to the side (with respect to the lower coordinate frame of the vertical bar and simulating the model, we observe that no error-messages appears. Only after positioning the ground-block as much as 0.1 meter to the side, an error message as seen in figure 7.3 appears. From this we can conclude that SimMechanics is using a tolerance when working with closed-loop systems. This means that the problem found in closed-loop modeling as stated in the introduction above, only occurs when bodies are seriously miss-aligned.
Figure 7.2: The closed-loop mechanism modeled in SimMechanics
MapleSim
When simulating the modeled closed-loop system in MapleSim (see figure 7.4) and constructing the ground-frame 0.0001 meters sideways (as explained in the introduction above) a error-message appears. The error-message is viewed in figure 7.5. The same conclusions can be made as discussed in section 2.1: from this message we cannot identify the problem. According to the description in the error-message we can only conclude that the problem is acting in ’R4’ which is identified as the revolute-joint on the lower-right of the model, but nothing is mentioned about composition faults or a possible closed-loop error. CHAPTER 7. CLOSED-LOOP SYSTEMS BEHAVIOUR 40
Figure 7.3: SimMechanics closed loop error message
Dymola
First of all, when modeling a closed-loop mechanism in Dymola (see figure 7.6), the program advises you to use a so-called ’RevolutePlanarLoopConstraint’- joint in stead of the normal ’Revolute’-joint. This joint allows you to model closed-loop systems without having problems that are caused by singularities in the mathematical description of the model. How this is done exactly in Dy- mola, can be found in the user-manual. This feature can be compared with the SimMechanics environment where (for closed-loop systems) a cut-joint is automatically introduced. When simulating the stated model (with the right ground-frame positioned miss-aligned) Dymola behaves differently in compar- ison with SimMechanics: the placement of the right mass lower coordinate is changed so that it meets the stated positioning of the right ground-frame. By applying initial conditions to the revolute-joints, this ’problem’ can be tackled. After applying these initial conditions and placing the ground frame 0.0001 me- ters sideways, an error message as can be seen in figure 7.7 appears. In this message screen, the reason that causes the error is shown as well as possible solutions (removing one of the initial conditions from the revolute joints). It is not explicitely perceived that we are dealing with a closed-loop system, but from the hints stated in the error-message, we can conclude that the fault has to be found in the initial composition of the model. CHAPTER 7. CLOSED-LOOP SYSTEMS BEHAVIOUR 41
Figure 7.4: The closed-loop mechanism modeled in MapleSim
Figure 7.5: MapleSim closed loop error message CHAPTER 7. CLOSED-LOOP SYSTEMS BEHAVIOUR 42
Figure 7.6: The closed-loop mechanism modeled in Dymola
Figure 7.7: Dymola closed loop error message Chapter 8
Dymola Vehicle Dynamics Library
At the Eindhoven University of Technology, an important application of the multibody package is vehicle dynamics. Because of the drawbacks considering visualisation and speed of MATLAB/Simulink a fast vehicle dynamics package is highly appreciated. A free Modelica-based vehicle dynamics library is available, but this library is very limited and no further development on this library is done. A more extensive commercial vehicle dynamics library is available and is designed and maintained by Modelon AB, the same company that produces Dymola. Here, version 1.3 of the ’Vehicle Dynamics Library’ is used.
8.1 Introduction
The Dymola Vehicle Dynamics Library offers is, as with all Dymola libraries, based on the Modelica language which means that the details of the separate vehicle components are fully open to the user and gives more experienced users possibilities to adapt or design their own components. As was also mentioned in chapter1, additional Modelica libraries can be be used so that multiple engineer- ing domains such as control, hydraulics, powertrains and electrical system can be covered. Besides some ready-made components like suspensions, brakes and powertrain components, the Vehicle Dynamics Library also includes a 3D road builder, a number of open- and closed-loop driver models, athmosphere-blocks and some state-of-the-art tyre models such as Rill and Pacejka.
8.2 Adaptability
In nearly all cases, academic usage of multibody packages and in particular a vehicle dynamics library requires modeling custom (suspension-) components or editing existing components. Consequently, a component should be intuitively and clear. To check this, a ready-made ’Trailing Arm’ suspension is firstly
43 CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY 44 looked as a component itself. Adjustable settings and parameters are discussed after which the underlying methodology is checked.
Figure 8.2: Expanded view of the ’Trail- Figure 8.1: The ’Trailing Arm’ block ing Arm’ suspension
As can be seen in figure 8.1, the ’Trailing Arm’ block has got four frame connec- tions (rectangular ports), four spring-damper connections (square ports) that can be used to specify the position of both damper and spring mounts in the upright, see also figure 8.3, and one hub-flange (the rectangle with an circle inside) for attaching the wheel. By using the dotted lines in figure 8.1 and from the discription found when hovering over the ports, it is obvious how to attach the suspension to the chassis and connecting the wheels to the suspension. By clicking the ’Trailing Arm’ block, various parameters and settings considering the geometry of the suspension can be modified. As can be seen in figure 8.3, the meaning of specific parameters is very clear thanks to the elaborate discription and the drawing on the right. When we look to the underlying components of the ’Trailing Arm’-block in figure 8.3, we can firstly identify all of the nine ports discussed above. Secondly, two suspension links can be seen as well as a joint connected to one of the links. Thirtly, we see a spring and damper which are attached to the other suspension link. By clicking a component, again different parameters such as mass and inertia for the link and stiffness and damping coefficients for the spring and damper can be adjusted. When going deeper into the ’LowerArm’-link, we can see a number of parts, as can be seen in figure 8.4. We can see two ’FixedTranslations’ and three ’Rods’. The three ’Rods’-components are identified as being the three links of which the ’Lowerarm’ consists of. Again, different characteristics of the ’Rods’ can be adapted such as mass, inertia and geometry properties. In this case, geometry properties are constructed by declaring a function of some global parameters specified in second-level ’LowerArm’-block (which again are functions of param- eters specified in the top-level ’Trailing Arm’-block). An examle of this can be CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY 45
Figure 8.3: The ’Trailing Arm’ parameters window found in figure 8.4 where we can see that the position vector of ’link1’ is speci- fied as r = r0J1 − r0B (see the top of the figure) where both r0J1 and r0B are specified in the one level higher ’LowerArm’ block (not visualized here). Both ’FixedTranslations’ are needed to specify the position of the two ’Rods’ relative to both mounting-frames. Finally, when looking into the lowest-level ’link1’-block (see figure 8.5), we find two elementary Modelica-blocks, namely a ’body’-block which specifies the mass- and interia-properties whereas the ’frameTranslation’-block represents the position-vector of the rod. Parameters from both blocks are inherited from higher-level components. CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY 46
Figure 8.4: The ’LowerArm’-block
Figure 8.5: The ’link1’-block CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY 47
The hierarchic structure discussed above is (in a clarifying way) showed in the ’Component Browser’ (see figure 8.6). In this browser, all the different compo- nents with their specific ports can be found. By clicking on it, the component opens in the modeling-window. By right-clicking a component, parameters can be changed without opening the specific component. From the preceding text it can be concluded that the vehicle component that was looked at (the Trail- ing Arm suspension) is fairly understandable when going deeper into the model. Parameters and settings can be adapted easily. Also, it can be seen that the dif- ferent rods and links are easily identified and therefore their composition could be changed easily. The lowest level components are simple standard Modelica components which would make it possible to construct a suspension-part from scratch.
Figure 8.6: The Dymola ’Component Browser’
8.3 Visualization
A powerful aspect of Dymola’s ’Vehicle Dynamics Library’ is the visualiza- tion of models. Many basic ready-made components found in the library offer the possibility to be visualized while running the simulation. Some of the 3- dimensional illustrations used to visualize the components are deformable and movable. Thanks to this, springs for example can be visualized realistically. A number of properties of the 3D visualization such as color (material finish) and dimensions can also be changed (see figure C.7 for a spring-damper-component). CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY 48
Also road-surfaces can be visualized. During a simulation, models can be turned and scaled. In figure 8.7 a visualization of a 3D-car model is shown. Figure 8.8 shows a detailed view of the suspension.
Figure 8.7: Visualization of a car
Figure 8.8: Detailed view of the suspension with spring-damper, wheel and brake
8.4 Performance
Due to the fact no other similar vehicle-models are available in the other pack- ages, it’s hard to make conclusions considering simulation-performance. Other than that, comparable settings regarding the used algorithm and error-tolerances have to be chosen to give an objective view on the performance aspect. To check performance, let’s take the ’VehicleDynamics.Examples.GettingStarted.GettingStarted’- example model of a typical mid-size car provided standard in the library which CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY 49 performs a pre-defined steering-action. Among other things, the model con- sists of a ’tabular-data’-suspension, an ’Tabular89Bakker’-tire-model, elaborate mass- and inertia-properties, a flat road profile and an open-loop driver. On a 1.86 GHz processor laptop, a ten second simulation of this model requires in total about 150 seconds (using the ’Radau IIa - order 5 stiff’ algorithm with an error-tolerance of 0.0001). According to Dymola’s ’Messages’-window, about 20 seconds is needed for integrating the model equations; the rest of the simulation- time is uses to compile the model-equations needed for integration. Under same circumstances and with the same computer, SimMechanics requires about 4.5 minutes (270 seconds) which is almost a factor 2 in time to simulate a much less-complicated vehicle model, which indicates that when speed is concerned, Dymola’s ’Vehicle Dynamics Library’ is performing very well, considering the complexity of the simulated vehicle-model. Another aspect that has to be men- tioned is that with Dymola, no output variables have to be chosen before simu- lating the model. In the ’Variable Browser’ (see figure C.8) all variables can be plotted afterwards. Chapter 9
Conclusion
As always, new software takes time to get used to. However, the longer you work with a software package, the clearer it gets. Off-course, due to the lim- ited timespan that was involved for the project and because three multibody packages had to be learned and examined, only some global aspect were investi- gated. Also, because only very simple multibody models were used to check for simulation performance, just a small amount of the actual capabilities all of the three packages was utilized and no significant differences in performance occur. Therefore, it’s hard to draw a conclusion concerning simulation performance just from the results obtained from these simple models. Nevertheless, the overall ’feel’ of speed and performance when using both MapleSim and Dymola is much better compared to SimMechanics. This can already be seen when just looking at the startup time: Simulink/SimMechanics takes up to a factor 4 more time compared to MapleSim or Dymola. When looking at verification and error handling, we have seen some big dif- ferences. From the error-messages produced by MapleSim it was very hard to identify the location of the fault that was made because of the mathematical based error messages. In SimMechanics and Dymola, most of the times the lo- cation of the fault was specified or became clear from the error-message window. When numerical accuracy is concerned, no significant differences were observed although the error produced by Dymola stayed the highest when we compared it to those of SimMechanics and Dymola. A major drawback of the investigated MapleSim multibody package in contrary to SimMechanics and Dymola was the absence of a visualization environment. This made it very hard to verify models and check motion behaviour. Dymola does offer an elaborate visualization functionality. When parametrisation is concerned, all three packages have their own way of dealing with it. However, the methods used in MapleSim and Dymola could also be accomplished in MATLAB/Simulink with some lines of code which, in practice, turns outs to be the easiest method. In Dymola, models can be exported to MATLAB/Simulink easily by using the ’DymolaBlock’. MapleSim offers a possibility to export a model to C-code.
50 CHAPTER 9. CONCLUSION 51
This C-code was almost free from comments which made it hard to understand without having knowlege of the actual model. By investigating a simple closed-loop model, conclusions about how the model reacts to small deviations in composition were drawn. In both SimMechanics and Dymola, it was fairly clear from the error-message screens where the fault occured and what was done wrong. In MapleSim however, is was unclear what caused the error which makes it hard to solve the problem. Finally, the Dymola Vehicle Dynamics Library was investigated. It offers many pre-defined componenents and tyre-models. Also, components are fairly easy to understand and adapted. Moreover, a nice and elaborate visualization func- tionality is available. When the simulation performance is compared to a (much simpler) SimMechanics car-model, it can be also concluded that this Vehicle Dynamics Library also performs well regarding simulation speed.
Summary
In order to summarize the opininon regarding the three multibody packages, a table is made which containts the most important aspects discussed in the pre- ceding chapters. The ’Chapter’-column indicates in which chapter the specific aspect is discussed.
Table 9.1: Summary table CHAPTER 9. CONCLUSION 52
Recommendations
Off-course, because this conclusion is only based on the use of some simple models, a more thoroughly investigation would be necessary to investigate all the functionalities and give a more founded opinion. Nevertheless, an important aspect of multibody software is verification and error handling and according to this, it can be concluded that MapleSim is a less-suitable alternative for SimMechanics. In MapleSim 2 this aspect has not been improved, in contrary to the visualization functionality which is performing very well. The Vehicle Dynamics Library has proved itself to be a powerful application and therefore would be of great interest for the TU/e. When we take into account all the preceding observations, it has to be concluded that Dymola would be a suitable alternative to SimMechanics and can be used in cooperation with other applications written or modelled in Simulink and MATLAB. References
[1] I.J.M. Besselink a.o. Introduction to automotive technology lecture notes, 2007. [2] Bram de Kraker & Dick H. van Campen. Mechanical Vibrations. Shaker Publising BV Maastricht, 2001. [3] W. Kortüm and R.S. Sharp, editors. Multibody computer codes in vehicle system dynamics. Swets & Zeitlinger B.V., Amsterdam/Lisse, 1993.
[4] Modelica. Modelica - A Unified Object-Oriented Language for Physical Sys- tems Modeling, 2000. [5] N. van de Wouw. Multibody dynamics lecture notes, 2007.
53 Appendix A
SimMechanics windows
Figure A.1: The car-mass parameters window in SimMechanics
54 APPENDIX A. SIMMECHANICS WINDOWS 55
Figure A.2: A scope visualizing the vertical position of the unsprung mass Appendix B
MapleSim windows
Figure B.1: The MapleSim ’parameters’-window
56 APPENDIX B. MAPLESIM WINDOWS 57
Figure B.2: The MapleSim ’components’-window
Figure B.3: The MapleSim ’probe-properties’-window APPENDIX B. MAPLESIM WINDOWS 58
Figure B.4: Editing the axis variables
Figure B.5: The MapleSim ’Plot Window’ Appendix C
Dymola windows
Figure C.1: Selecting the signal to use
Figure C.2: Dymola’s ’parameter-window’ for the car-body
59 APPENDIX C. DYMOLA WINDOWS 60
Figure C.3: Dymola’s ’Component-Browser’
Figure C.4: Adjusting plot characteristics APPENDIX C. DYMOLA WINDOWS 61
Figure C.5: Animation settings for the spring-damper APPENDIX C. DYMOLA WINDOWS 62
Figure C.6: The DymolaBlock GUI APPENDIX C. DYMOLA WINDOWS 63
Figure C.7: Visualization-parameters window of a spring-damper-component APPENDIX C. DYMOLA WINDOWS 64
Figure C.8: A part of the ’Variable Browser’ Appendix D
MapleSim C-code
1 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ 2 ∗ 3 ∗ DO NOT EDIT MANUALLY! 4 ∗ Automatically generated by Maple. 5 ∗ Created On: Thu May 07 13:11:52 2009. 6 ∗ Model Name: Main 7 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/ 8 9 10 #include
65 APPENDIX D. MAPLESIM C-CODE 66
34 { 35 long i , j , k ,m; 36 double t ; 37 38 ip [ n−1]=1; 39 for ( k=0;k nb+k]+=A[ i ∗n+j ] ∗ t ; 76 } 77 } 78 } 79 for ( k=0;k 121 void simOut ( long N, double t , double ∗MAPLExx, double ∗ MAPLEdx) 122 { 123 MAPLExx[ 6 ] = MAPLExx [ 0 ] ; 124 i f ( N<1 ) { 125 return ; 126 } 127 MAPLEdx[ 0 ] = 0 . ; 128 MAPLEdx[ 1 ] = 0 . ; 129 MAPLEdx[ 2 ] = 0 . ; 130 MAPLEdx[ 3 ] = 0 . ; 131 MAPLEdx[ 4 ] = 0 . ; 132 MAPLEdx[ 5 ] = 0 . ; 133 } 134 135 136 /∗ Function: simDerOut ======137 ∗ Abstract : 138 ∗ f(N, t, x, xdot) 139 ∗/ 140 void simDerOut ( long N, double t , double ∗MAPLExx, double ∗MAPLEdx) 141 { 142 MAPLExx[ 6 ] = 0 . ; 143 i f ( N<1 ) { 144 return ; 145 } 146 MAPLEdx[ 3 ] = −123456789.∗MAPLExx[0]/100012300.; 147 MAPLEdx[ 4 ] = 0 . ; 148 MAPLEdx[ 5 ] = 0 . ; 149 MAPLEdx[ 0 ] = MAPLExx [ 3 ] ; 150 MAPLEdx[ 1 ] = MAPLExx [ 4 ] ; 151 MAPLEdx[ 2 ] = MAPLExx [ 5 ] ; 152 } 153 154 155 /∗ Function: simInitialize ======156 ∗ Abstract : 157 ∗ Allocate space. 158 ∗/ 159 void simInitialize( double ∗∗MAPLE_y, double ∗∗MAPLE_x, double ∗∗MAPLE_dx, double ∗∗MAPLE_u, double ∗∗ MAPLE_params) 160 { 161 ∗MAPLE_x = malloc (6∗ sizeof ( double )); 162 ∗MAPLE_dx = malloc (6∗ sizeof ( double )); 163 ∗MAPLE_y = malloc (1∗ sizeof ( double )); 164 } APPENDIX D. MAPLESIM C-CODE 69 165 166 167 /∗ Function: simGetSizes ======168 ∗ Abstract : 169 ∗ Return sizes of vectors. 170 ∗/ 171 void simGetSizes( int ∗ size_y , int ∗ size_x , int ∗ size_u , int ∗ size_params) 172 { 173 ∗ size_u = 0 ; 174 ∗ size_x = 6 ; 175 ∗ size_y = 1 ; 176 ∗ size_params = 0; 177 } 178 179 /∗ Function: simInitialConditions ======180 ∗ Abstract : 181 ∗ Initialize the states. 182 ∗/ 183 void simInitialConditions( double ∗MAPLE_x) 184 { 185 MAPLE_x[0] = 0.333445e1; 186 MAPLE_x[ 1 ] = 0 . 0 e0 ; 187 MAPLE_x[ 2 ] = 0 . 0 e0 ; 188 MAPLE_x[ 3 ] = 0 . 0 e0 ; 189 MAPLE_x[ 4 ] = 0 . 0 e0 ; 190 MAPLE_x[ 5 ] = 0 . 0 e0 ; 191 192 } 193 194 /∗ Function: simInitializeParameters ======195 ∗ Abstract : 196 ∗ Initialize the parameters. 197 ∗/ 198 void simInitializeParameters( double ∗MAPLE_params) 199 { 200 201 } 202 203 /∗ Function: simOutputs ====== 204 ∗ Abstract : 205 ∗ y=f (t, x, u, p) 206 ∗/ 207 void simOutputs( double ∗MAPLE_y, double t , double ∗ MAPLE_x, double ∗MAPLE_u, double ∗MAPLE_params) APPENDIX D. MAPLESIM C-CODE 70 208 { 209 double MAPLE_s[ 7 ] ; 210 211 MAPLE_s[ 0 ] = MAPLE_x[ 0 ] ; 212 MAPLE_s[ 1 ] = MAPLE_x[ 1 ] ; 213 MAPLE_s[ 2 ] = MAPLE_x[ 2 ] ; 214 MAPLE_s[ 3 ] = MAPLE_x[ 3 ] ; 215 MAPLE_s[ 4 ] = MAPLE_x[ 4 ] ; 216 MAPLE_s[ 5 ] = MAPLE_x[ 5 ] ; 217 MAPLE_s[ 6 ] = MAPLE_y[ 0 ] ; 218 219 simOut (7 , t , MAPLE_s, MAPLE_dx) ; 220 221 MAPLE_y[ 0 ] = MAPLE_s[ 6 ] ; 222 223 } 224 225 226 /∗ Function: simDerivatives ======227 ∗ Abstract : 228 ∗ xdot = g(t, x, u, p) 229 ∗/ 230 void simDerivatives( double ∗MAPLE_dx, double t , double ∗ MAPLE_y, double ∗MAPLE_x, double ∗MAPLE_u, double ∗ MAPLE_params) 231 { 232 double MAPLE_s[ 7 ] ; 233 234 MAPLE_s[ 0 ] = MAPLE_x[ 0 ] ; 235 MAPLE_s[ 1 ] = MAPLE_x[ 1 ] ; 236 MAPLE_s[ 2 ] = MAPLE_x[ 2 ] ; 237 MAPLE_s[ 3 ] = MAPLE_x[ 3 ] ; 238 MAPLE_s[ 4 ] = MAPLE_x[ 4 ] ; 239 MAPLE_s[ 5 ] = MAPLE_x[ 5 ] ; 240 MAPLE_s[ 6 ] = MAPLE_y[ 0 ] ; 241 242 simDerOut (7 , t , MAPLE_s, MAPLE_dx) ; 243 244 } 245 246 247 /∗ Function: simTerminate ======248 ∗ Abstract : 249 ∗ Free space . 250 ∗/ 251 void simTerminate( double ∗MAPLE_y, double ∗MAPLE_x, double ∗MAPLE_dx, double ∗MAPLE_u, double ∗ MAPLE_params) APPENDIX D. MAPLESIM C-CODE 71 252 { 253 f r e e (MAPLE_x) ; 254 f r e e (MAPLE_dx) ; 255 f r e e (MAPLE_y) ; 256 }