VIRTUAL VEHICLE SYSTEMS SIMULATION A MODULAR MULTI-CPU APPROACH IN REAL-TIME by G. Edzko Smid A dissertation submitted in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY 1999 Oakland University Rochester, Michigan Doctoral Advisory Committee: Professor Ka C. Cheok Professor I. Schochetman Professor M. Das Professor K. Li Professor G. Honderd The Simulation of Automobile where the World is Virtual and Time is Real, will render a Sensation of Genesis and Creation of a Vehicle with Spirit and Feel. i Acknowledgements The research that is presented in this dissertation could not have been conducted without the fruitfull discussions and without the excitment and joy of creating the virtual driving simulation. I would hereby like to express my full appreciation to Ka C. Cheok who has been my advisor, collegue and best friend, for the scientific and moral support along the way. Furthermore I would like to thank my committee. A special appreciation to Jim Overholt for detailed discussions and good times. Coming to the United States I realized that Delft University of Technology had provided me with the sufficient background in systems and controls, to be able to adapt easily in a new environment and to contribute effectively on collaboration projects. The atmosphere in Delft will always be an example of a motivating environment with a good balance of professionalism and joy. In particular would like to acknowledge Ton van den Boom, Ben Klaassens, Stefano Stramigioli, Michel Verhaegen and Wim Jongkind. I owe my special thanks to Ger Honderd, as advisor for my Masters and also as doctorate committee member. My thanks go to Naim Kheir for the opportunity to come to Oakland after my graduation in Delft. In the first period of my stay, we have worked on a series of projects for TACOM, Ford, Chrysler, ITT Automotive and TechnoResearch. The teamwork during that time and the dynamic discussions were a strong motivation to continue my stay. Many thanks with this regard to Kazayuki Kobayashi, Teik-Khoon Tan, Shinishi Nishizawa and Sandro Scaccia. Also I would like to express my gratitude to Claudio Bonivento and Claudio Melchiorri and the students at the Laboratory of Automation and Robotics (LAR) for the opportunity and the joy to spend a summer at the Department of Electronics, Computer Science and Systems of the University of Bologna during my graduate time. The opportunity to be involved with the technology team at Echlin Automotive in spring 1996, and later with Dana Corporation contributed to my assistantship. It offered me the ability to combine graduate school with the experience in a proffesional environment. Therefore my respect to Mike Dougherty, Mohamad Qatu, Jack Dawson, Bill Spadafore, Devendra and Satyendra Kumar and Dave Llewellen. Beyond the work during the years of research that is described here, I have always enjoyed a wonderfull time and great hospitality with the family Cheok, who have soon become my host family in the United States. Also I’d like to thank my friends with whom I spent many weekends enjoying life and exploring the country. Last but not least, I would like to thank my parents and family for their inexhaustible support throughout my study. ii Preface In many countries one is not anymore considered to be privileged to own a vehicle. The automobile as a means of transportation has become a commodity, a requirement of mobility that one cannot do without. When we go shopping for a new vehicle, most of us will take technology for granted and we bargain on horse-power, sunroof, power windows and color. The understanding of the dynamics of driving and the capability to design safe and stable vehicles is the primary requirement for building quality cars. With increased development speed, the high level of quality and complexity and a growing competitive global market, a design process without virtual prototyping and simulation is becoming inadmissible. This dissertation presents a new simulation configuration for analyzing and designing vehicle dynamics systems. The configuration consists of a simulation network structure, a real-time modular vehicle dynamics model and a novel fuzzy-logic based tire model. The system that has been developed is an enabling tool to do just the virtual prototyping of mobility systems. Simulation studies are now possible where a human can drive a virtual vehicle in any maneuver, while analyzing the vehicle behavior. The manuscript is organized as follows. Chapter 2 presents the vehicle model in a modular configuration. The next chapter details the tire model tire that is incorporated in the vehicle model. Chapter 5 highlights on the ability to execute partitions of the simulation through the simulation network environment. This environment is especially configured for the purpose of simulating vehicle dynamics interactively by means of popular simulation tools like Simulink. Chapters 6.4 and 7 report on the study for timing and stability. Finally, Chapter 8 shows that the behavior of the system relates to actual driving an scenario, and presents the validation efforts of the model. Rochester Hills, Michigan G.E. Smid iii Nomenclature and Convention The variable naming convention in this thisis follows the standards used in most simulation and engineering literature. The coordinate systems convention can be seen from Figure 1, and is semantically described as “ forward, lateral left, and up, and up”. Typically the SAE standard and is characterized as “ forward and lateral right, and up”. The system in this dissertation complies with SGI graphics representation, but can be easily transformed to any other system. The coordinate system rotations and calculations are included in Appendix C. For vectors, variables and paramteres that apply to one of the corners of the vehicle, a lower right index is included in the subscript of the name, that denotes the corner which it applies to. The vehicle corner numbering can be read from Figure 1. Naming suffixes and indexes for vectors ( ) and matrices ( ) is according to notation frame Operation var,i from frame Operation to frame Frame can mean either of the three frames , or . The frame refers to the earth (or origin) frame, refers to the vehicle (or car) reference frame, and refers to the wheel frame. Forces are typically named , and torques with the subscript denoting the name or the origin of the force or torque. The overbar denotes explicitly that a variable is a vector (generalized vectors have an underbar). The following variable names are used in this thesis. ! ! " ! ! ! % " & ' & " &( " )+* " )-, " $# $# $# $# Transition matrix of a discretized system. Dependant on integration method Suspension anchor location with respect to the vehicle frame of wheel Length in -direction between c.g. and front axel Friction reduction factor Input matrix of a discretized system. Dependant on integration method Damping effect of the camber angle Location of the center of the wheel in the vehicle frame of wheel Length in -direction between c.g. and rear axel Damping effect in the dynamics steering model Location of the tire-ground contact point in the vehicle frame of wheel Modified longitudinal tire stiffness Modified cornering tire stiffness Damping coefficient of the brake Damping coefficient for the steering system iv X-axis TF 2 1 . Al C.G. Ai Y-axis Top-View Bl LT LS-δS 4 3 LT-δT Bi Ci TR Figure 1: Naming convention for the vehicle geometry. /-02143$5 /-62143$5 /-7 8 9 : ;+143$5 /=<>143$5 [email protected] ACB4D FGE @ H I J K 9L1 FE NPO K QR1 FE NPO K SR1 FE O T J JU1 FGE 7 J 9 V K 9+1 FGE 6 81 FE XP9 Y @Z1 FE [\1 FE ]\1 ^ 3$5 _a` b 5 b 7c5 ; faO g @ de ; fa7 O g @ dX ; fa7 O g @ hi ; fa7 O g @ hP0 7 Torsial damping coefficient for the transmission shaft Damping coefficient for the suspension model Slip damping coefficient in tire stick model Damping coefficient for the tire deflection Auxilary product matrix of a discretized system for non-linear terms Graphics update frequency, or frame rate Force vector for the suspension and wheel deflection of corner M Longitudinal shear friction force Lateral shear friction force Anti-roll force in the suspension 8W Slip force vector for the M wheel Stick friction force Aerodynamic force on the chassis Longitudinal shear force Lateral shear force Gravitational acceleration Integration step size per frame Integration step size per sub-sample Inertia matrix for the vehicle chassis Inertia for the wheel Inertia of the engine Inertia of the transmission v k man o p jk l q v r-s2t4u$ rxwyt4u$v r-z2t4u rx{yt4u r q | t4u r q | } s k=t4u r+~t4u r-2t4u r-2t4u u { u G~u Z q qG q Z t= t+w } t+{ u ¢£ ¢ s ¤u ¥ ¦u v v v § v ¨© v ¨q ª« Gq ª¬ G ª¥cv q ªw G ª q } l Gq q ª{ Gq ª®u ªu ¯ °u ¯ °u u ± m² ³u Kingpin inertia Stiffness coefficient for the steering system Torsial stiffness for the transmission shaft Anti-roll stiffness coefficient Stiffness coefficient for the suspension model Stiffness coefficient in the dynamics steering model Tire elasticity in the stick slip model Stiffness coefficient of the tire Longitudinal tire slip stiffness Lateral (cornering) tire slip stiffness Patch length of tire-ground contact {+ s } s } Nominal length of the suspension system ( G~L s } s } ) Nominal length of the tire radius ( ) Mass of the vehicle (diagonal matrix) Moment about the kingpin sub-sampling factor Mass of the wheel Brake pressure booster constant Gearbox ratio for gear ¡ Steering gear ratio Vehicle position in earth reference frame Transformation matrix for translating global to vehicle frame coordinates Effective wheel radius (with deflected tire) Euler angle transformation matrix Nominal wheel radius (for unloaded tire condition) Slip ratio Space trajectory of the vehicle corner by displacement and rotation Space trajectory of the wheel by spin travel in the steered direction Coriolis matrix Overhear time per frame Execution time for one iteration of vehicle dynamics Brake torque Enging shaft torque Frame rate interval time Torque from the transmission onto the axes Torque on the vehicle chassis caused by slip Torque on the vehicle chassis caused by the suspension Track width of the front wheels Track width of the rear wheels v Location of the vehicle corner on the trajectory v Location of the tire on the trajectory Patch width of tire-ground contact Terrain altitude vi ´ µ³¶ ·¸\¹ º » ·¼ ½¾¹ º » ·¿ ÀÁ¹ º » ÂÃ ¶ ÂÄ ¶ Å+Æ ÇÈ É Ê-Ë Ì Í È ÎÉ Ï Ï Ã¿ Ð ¹ º» Ñ µ³¹ º» Ñ Ò ÓLÔ ¹ º» ÑÕ ¹ º» ÑÒ ¹ º» ÖC¹ ºÔ » ×ÙØ Ú Õ ÛÜ¹ º» Ý Þß¶$à áaâ Ý µß¶$à áaâ ãÞä¶ ãµä¶ í ÈÉ Actual suspension length Brake pedal angle Kinpin angle Throttle angle Suspension deflection Tire deflection Understeer gradient Non-linear state driving functions Notation for the model of a simulation process. Model of the human driver and the terrain Index library index value of the function parameter Slip coefficient for tire-ground contact Membership value for the fuzzy tire model switch Vehicle Euler angles Steered wheel angle (i.e. actual wheel rotation) Steering wheel angle (i.e. steering setpoint) Angle at the steering gear pinion Camber angle Spoke angle Vehicle gyriscopic angular rates Wheel spin angle Spacial velocity of the vehicle corner by displacement and rotation Spacial velocity of the wheel by spin in the steered direction Ò æç Ò ëç Elevation of the anchor location above the terrain ãÞå Òè éì ê ç Elevation of the center of the wheel above the terrain ãµ$å è éê Non-linear output driving functions vii è éÒ ëç èé Contents Acknowledgements ii Preface iii Nomenclature and Convention iv 1 Introduction to Vehicle Simulation 1.1 Objective 1.2 Real time simulation 1.3 Approach 1 1 3 3 2 Virtual Vehicle Modeling and Simulation 2.1 Introduction 2.2 Modular Closed Loop Dynamics 2.3 Conclusion 6 6 7 11 3 Fuzzy model of tire traction dynamics 3.1 Introduction 3.2 Stick Friction with Fuzzy Logic Switching 3.3 Implementation 3.4 Simulation results 3.5 Conclusion 12 12 13 17 18 20 4 Numerical Integration of the Vehicle Model 4.1 Transformation and Integration Methods 4.2 Conclusion 21 21 30 5 Simulation Platform with Integrated Networking Environment 5.1 Introduction 5.2 Methods for multi-processing 5.3 Multi-processing of dynamics models 5.4 Implementation through Indexing 5.5 Virtual Environments 5.6 Modules for Subsystems 31 31 32 34 40 45 46 viii 5.7 Conclusion 48 6 Timing and Synchronization 6.1 Introduction 6.2 Human-in-the-loop Model 6.3 Real time versus Simulation time 6.4 Communication and Synchronization with SPINE 6.5 Prediction and Correction with Luenberger Observer 6.6 Conclusion 49 49 49 50 55 55 62 7 Stability 7.1 Introduction 7.2 Model Stability 7.3 Simulation Specific Stability 7.4 Application Dependant Stability 7.5 Conclusion 63 63 63 67 76 78 8 Verification 8.1 Introduction 8.2 Vehicle Kinematics and Dynamics 8.2.1 Static load at the tires and suspension 8.2.2 Steady state cornering 8.2.3 Constant torque acceleration and braking 8.2.4 Ackermann Steering Verification 8.2.5 Stopping distance 8.2.6 Circular Skid Pad 8.2.7 Yaw acceleration while braking under split- î condition 8.2.8 Braking in a curve 8.2.9 Double Lane Change 8.3 Telemetry for Real-Time Verification and Validation 8.4 Tire model verification 8.5 Conclusion 80 80 81 81 82 84 85 86 88 90 92 92 94 96 96 9 Conclusion and Recommendation 9.1 Conclusions 9.2 Recommendations 9.3 Retrospect and Prospect 97 97 98 99 A Details on Modeling A.1 The driver environment A.2 Steering Model A.3 Engine and Transmission Model A.4 Brake Model A.5 Wheel Spin Dynamics 101 101 102 106 107 107 ix A.6 Suspension and Tire Deflection A.7 Anti roll A.8 The vehicle frame 108 112 112 B Details on the Tire Slip Model B.1 Theoretical Derivation B.2 Applicable formulas B.3 Considerations 114 115 119 121 C Coordinate Systems C.1 Displacement Coordinate Transformations C.2 Angular Velocity Coordinate Transformation C.3 Angular Displacement C.4 Linear Velocity Coordinate Transformation C.5 Coordinate Systems 123 123 126 127 127 128 D Software Reference D.1 File Structure D.2 User Interface D.3 Prototyping with Simulink 130 130 131 135 E Development and Implementation E.1 Geometry models E.2 Initialization procedures E.3 Main algorithmic cycle E.4 Vehicle Dynamics Implementation E.5 SPINE - server (VVSS) E.6 SPINE - client E.7 Parameter Defaul Values E.8 State Reference Index Library E.9 Peripherals and User Interfaces 138 138 139 141 142 145 147 147 149 149 Curriculum Vitae 154 Keyword Index 155 References 158 x List of Figures 1 Naming convention for the vehicle geometry iv 1.1 The Vision for the Virtual Vehicle System Simulation (VVSS) setup. 4 2.1 Overall virtual vehicle simulation system model with three partitions and human in the loop. Closed loop system interconnected model for the VVSS. 2.2 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 4.4 5.1 5.2 5.3 5.4 5.5 5.6 6.1 The general characteristic curve for the friction force as a function of sliding velocity. Schematic diagram of the modified fuzzy tire model. The stick tire model is modeled as a double spring-damper system between the trajectory of the vehicle and the trajectory of the wheel. Graphical display of the fuzzy logic sigmoid membership function. Polar slip friction coefficient representation. Simulation results with the fuzzy tire model for acceleration and braking. Graphical intepretation of different integration algorithms for the differential equation ðx ï ñò . Three different transformation methods for approximating continuous to the discrete time domain, with the corresponding stability regions. A general example of a second order mechanical model with force input and position output. interconnected discretized closed loop system. The proposed implementation for the Virtual Vehicle System Simulation (VVSS) in the Simulation Platform with Integrated Network Environment (SPINE). Three variations of configurations for Multi-CPU simulation models. Timing diagram for double dependant replaced state variable. Indexed states represent state values through indirect addressing. The simplified model of the underlying tree structure that represents the graphic virtual scenery The virtual environment can be adapted to meet the requirements of any intended study. The Optimal Control Model (OCM) for the human operator. xi 8 10 13 14 15 16 17 19 22 24 25 27 32 33 39 41 45 46 50 6.2 6.3 6.4 6.5 6.6 Snapshot of the VVSS simulation output with online statistics. Minimum integration interval selection for real-time simulation. SPINE communications timing diagram. Timing diagram in the scenario of synchronization failure. Example of a second order linear system for predicting state values. The root locations for a quarter car suspension model for various values of the stiffness and damping parameters. 7.2 Pole location transformation for various integration schemes. 7.3 Example of a second order linear feedback system with three general partitions. 7.4 Example of a second order linear system with three general partitions. 7.5 A general second order feedback system with forward and backward integration methods. 7.6 Stability regions for a second order polynomial and for the second order example feedback system. 7.7 Four stability regions for approximation variations on general second order system. 7.8 A simple open loop integrating system is used to test the accuracy of simulation results with SPINE. 7.9 Comparison of simulation output in the VVSS and in a Simulink model through SPINE. 7.10 Comparison of the values for position, simulated in the VVSS in the case when a submodel is being simulated in Simulink through SPINE. 52 53 54 56 59 7.1 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 8.17 Telemetry aquisition and communication system will be used for real-time on-line validation. Validation data for steady state load distribution. Suspension deflections, vehicle velocity and roll angle for steady state cornering validation test. The trajectory during steady state cornering. Lateral forces on front tires for steady state cornering. Torque profile and velocity and position output for constant torque accelerating and braking. Ackermann steering verification test. Typical trajectory profile for stopping distance. Typical trajectory profile for stopping distance. Throttle command and roll angle for circular driving test. Vehicle velocity and heading in a circular driving test. Planary trajectory graph for circular driving test. Trajectory and yaw profile for split- ó brake test. Tire forces under split- ó braking conditions. Trajectory and yaw profile for braking in a curve. Suspension deflections and heading profile when braking in a curve. Trajectory and asociated steering command for double lane change. xii 65 68 68 69 70 71 73 75 75 77 81 82 83 83 84 85 86 87 87 89 89 90 91 91 92 93 93 8.18 Lateral forces and lateral acceleration on the vehicle during lane change. 8.19 Dual-ô dynamic sliding and static stick friction verification test table. A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 94 95 The Motion platform with driving environment mounted on top. The graphical illustration of the definitions for caster and camber angle. The second order steering system model. Ackermann cornering geometry. Dynamic model of the powertrain. Schematic diagram of the hydraulic brake system. Model diagram for wheel angular dynamics. Schematic representation of the mechanical construction of the quarter car suspension model. Model for quarter car suspension translational dynamics. Front view of the mechanical configuration of the suspension system with lateral forces decomposition. Model for the vehicle frame translational dynamics. Model for the vehicle angular dynamics. 102 103 104 105 106 107 107 B.1 Tire-road contact patch geometry. B.2 Strain condition in non-sliding portion of the contact patch. B.3 Longitudinal and lateral normalized slip forces for different slip angles across slip ratio. B.4 Longitudinal and lateral slip against slip angle. B.5 Polar representation of the longitudinal and lateral slip. 114 115 C.1 Coordinate frames from reference to body. 124 D.1 Image of the graphical user interface for the Virtual Vehicle System Simulator. D.2 The VVSS library in Simulink with the blockset that provides the necessary functionality for SPINE. 134 E.1 Software flow model for Multi-CPU Simulation. E.2 Hardware setup of the Simulation Platform with Integrated Network. 143 145 A.9 A.10 A.11 A.12 xiii 109 110 111 112 113 120 121 122 136 List of Tables 7.1 Nomenclature and Convention. iv Transfer functions for four variations of integration methods for the linear system. 72 C.1 Advantages and disadvantages of the three most used transformation methods. 128 D.1 The list of file names with a short description, of the files that are associated with the VVSS and SPINE. D.2 Available command-line options with the functionality. D.3 Available Key-press options with the functionality. 131 133 133 E.1 E.2 E.3 E.4 139 148 149 150 Overview of the file formats that can be loaded into the geometry tree of VVSS. Default Parameter Values. Reference table for the VVSS indexes. Reference table for the VVSS indexes for the quarter vehicle corners. xiv Chapter 1 Introduction to Vehicle Simulation The revolution in the computer hardware industry has created the technology for conducting analysis and simulation of numerous engineering applications. We have arrived in a time where sufficient computer power is in most situations available, and where it has become the responsibility of the engineer to exploit the computers to solve the solutions to his problem. One of the successes of increased computer power is found in the area of solid modeling or Computer Aided Design (CAD), where high performance rendering of complex graphics models allows for interactive designing models. Also in the entertainment industry the use of high-end graphics computers for arcades and movie productions has shown to be successful. 1.1 Objective In this dissertation I will demonstrate a third use of the available graphic capabilities. It is in the area of the automotive industry. Whereas the aerospace industry has successfully adopted simulation technology for engineering and training, the automotive society is traditionally more used to conventional tools and engineering methods. It is only in recent years that the virtual simulation of full vehicle systems has become a serious effort for the automotive industry. Most of the large companies (the Big Three and their European and Japanese competitors) have developed their own facilities to simulate vehicles in virtual realistic environments. Each of them in a slightly different setting, each of them with different research objectives. Commercial packages like ADAMS, DADS or VDANL [1] are available, as well as commercialized academic packages like CarSim and Madymo. However, generally they contain black-box simulators and are expensive. This means that a file of configuration parameters defines the simulation environment, but there is no easy access to the models. Also, these simulators will typically utilize a pre-defined scenario for the driver. This can be either a driving scenario (steering, throttle and barke trajectories) or a driving behavior characterization (delay, bandwidth, gain). The simulators will usually generate graphical output in the form of curves and plots on axes. Additional 1 2 software needs to be aquired to vizualize the data in a 3D scenery. Hence, most of the commercial solutions will not be (or are expensive to be) customized and do not give the user the ability to run arbitrary interactive test scenarios, and do therefore not give the subjective feel of a systems performance. They are usually not designed for solving the vehicle dynamics model in real time or interactively. In January 1996 a collaboration was initiated between ITT-Automotive and Oakland University in which Oakland implemented a full-vehicle simulation for the purpose of real-time simulation with hardware-in-the-loop. The details about the modeling are described in the final project report [9]. The task was to develop and implement a full vehicle dynamics model with 16 degrees of freedom motion dynamics. The model was developed in MATLAB and later implemented in EASY-5 õ using FORTRAN code. The objective for ITT was to test and demonstrate their ABS system performance on the behavior of vehicles by allowing its engineers and customers to drive a vehicle in a virtual realistic environment, in which the vehicle dynamics were incorporated. The model was developed toward the application for ITT, and did not satisfy the requirements for conducting a wide variety of driving manouvers. The project was succesfully demonstrated at the 1997 SAE Congress in Detroit. Customers could drive a virtual vehicle on a test track (split- ö and slalom) and were able to turn the ABS system on and off. The Department of Electrical and Systems Engineering has since continued its efforts in the vehicle simulations (See [57], [35], [55], [56]). In the simulation of vehicle dynamics, a closed-loop system will be defined that includes the driver, a virtual environment and the mathematical synthesis of an automobile. The following statement phrases the objective of the research in this thesis, It is the principle objective of this research is to develop a system that can emulate the behavior of a vehicle, using a multi-processing environment, and that can present the solution in a user-interactive immersive virtual realistic environment, which can be used as a tool in the design process. The objective statement suggests a network for real-time multi-CPU simulation and the development of a driver interface with a graphics front-end that can provide the simulation output to the driver. Immersion of the human driver opens a wide area of research in the project. A human driver will feel to be immersed in the simulation when the environment looks, feels and performs realistically. In order to achieve this level of perception, the simulation required full 3D audio-visual feedback, force and motion feedback and an absolute alignment with absolute time. This term interactive in the objective implies the real-time evaluation of a full vehicle dynamics model. The research in this dissertation emphasizes on visual feedback and real-time simulation. ÷ EASY-5 is a unix-based simulation environment developed by the Boeing Company. Mainly used by large companies for complex simulations of hydraulic systems. 3 1.2 Real time simulation Real-time is typically referred to as the utmost strict requirement to provide a numerical output at a specified fixed time instance. Special-purpose computers with a real-time operating system are often used for the control of hardware-in-the-loop systems. For the purpose of interactive vehicle simulation, the human driver could be considered hardware-in-the-loop. The term real-time will have the similar definition. However, under-performance will not necessarily be disastrous. The term real-time in the context of simulating vehicle dynamics will be used in the following definition: The simulation of the vehicle dynamics is performed in real-time when the dynamics are numerically integrated, in parallel with the graphics rendering process, over a time interval that equals the graphics update frame interval, and the application is generating the virtual environment in the selected frame-rate. The objective for the multi-processing environment is to allow engineers to communicate with the real-time vehicle dynamics simulation. The simulation platform with integrated network environment (hereafter referred to as SPINE) combines the convenient accessible simulation interfaces like Simulink with the virtual realistic driving simulation. The bottom-line goal of the research is to provide a computational vehicle dynamics which is based on underlying physical relations. Vehicle dynamics is the branch of engineering which relates forces to overall vehicle accelerations, velocities and motions, using Newtonian laws of motion. It encompasses the behavior of the vehicle as affected by powertrain, tires, aerodynamics, gravitation and chassis characteristics. 1.3 Approach Towards accomplishing the objective on page 2, several problems have been solved. These problems and their solutions will be chronologically addressed in the successive chapters. These solutions are the contributions of this thesis. ø A well-defined set of vehicle dynamic relations has been compiled that synthesize a vehicle model for general driving purpose simulations and well fit for real-time digital simulation. ø A tire model has been designed, that relates physical parameters to dynamic behavior, and that will evaluate meaningfull results for all speeds in all directions. ø A multi-computer network structure has been developed and implemented which allows multiple computers to simulate vehicle subsystems concurrently in real-time. ø The vehicle dynamics model has been implemented in a graphics workstation, and a virtual realistic animation has been adopted to render the simulation output. Particular attention has been paid to the real-time requirement of simulation. 4 These solutions are the contributions of this thesis. The above items have been integrated in the virtual vehicle system simulator (hereafter referred to as SPINE). Two additional chapters address the studies for stability and validation. As is well understood, modeling and simulation can have no merit without validation and verification. The notion for ensuring the validity of a model for a system is an essential step in the systems engineering process [44]. The question that need to be answered is Are we doing the right thing, and are we doing it right? Figure 1.1: The Vision for the Virtual Vehicle System Simulation setup. A motion table with the driver seat and peripherals, surrounded by stereo vision and sound. The Vision for the Virtual Vehicle System Simulation setup. A motion table with the driver seat and peripherals, surrounded by stereo vision and sound. In order to validate the vehicle models, three methods can be used. First, validation with simulation data from an established software has been conducted for ITT-Automotive (See [9]). Second, offline validation would require a series of well-defined and well-excited scenarion test-data that can afterward be correlated with simulation results. In this thesis however, it is suggested that a real vehicle will be equipped with a tele-metry equipment. For now the system is exposed to a validity check in nine test scenario verification experiments. The intensions for the virtual vehicle simulation laboratory cover a large amount of effort. The conclusions in Chapter 9 cover the state of research and where it should go from here. The important aspect for an organized project management is to remain in focus with the objective, to understand the applicability and to emphasize on the benefits. 5 The research in virtual realistic driving is not finished upon the defense of this dissertation. The VVSS and SPINE will continue to be supported in the time to come. The vision for the virtual vehicle systems simulation is an interactive feedback motion platform as is illustrated in Figure 1.1. Features and functionality as well as performance criteria will have to be modified for the particular applications. Chapter 2 Virtual Vehicle Modeling and Simulation In this chapter the simulation model for the vehicle dynamics of the VVSS will be explained. The model is shown to consist of three partitions. The descriptor matrix for each partition is presented, as the representation of the nonlinear model. The chapter presents a compact but complete vehicle dynamics model for real-time simulation. The aspects of choosing the suitable integration method are addressed in Chapter 4. It is described there, how the models in this chapter are interconnected and numerically solved. The implementation is furthermore detailed in Appendix E. In particular, Section E.4 describes the resulting mathematical formulation for implementating the derivated models that have been presented here. Stability issues will be further addressed in Chapter 7. 2.1 Introduction The vehicle system is considered to be constructed from a rigid frame and four wheels, hence a five-body system. The frame has 6 degrees of motion freedom. The wheels will be able to spin, and move up and down along the suspension displacement. The two front wheels will be able to steer. A total of 16 degrees of freedom. The vehicle model was derived at Oakland and has been presented at CAINE [57]. The mathematical derivations that lead to the presented model can be found in Appendix A. The model, as presented here, should be viewed upon merely as an archetype. By itself, it is empty and purely formal, nothing but a facultas praeformandi, a possibility of representation which is given a priori. The character and behavior of any vehicle will come about during configuration and parameter value assignment. In such a way, it serves the objective for virtual vehicle driving, which is to retro-fit any wheeled ground vehicle in the simulator. The model can be partitioned in three submodels. Partitioning is beneficial for simulation, especially with the use of real-time integration methods [50]. 6 7 2.2 Modular Closed Loop Dynamics An important aspect in the modeling methodology is the modularity. Chapter 5 will explain about modularity in more detail. The derivations in this chapter for the dynamics will be targeted towards the capabilities for modular simulation. The most suitable modeling methodology, with respect to modularity and to digital simulation, is the discrete-time state-space representation, with extension to non-linear dynamics. The following paragraphs will discuss the sub-models that are part of the vehicle system model. In the Newtonian modeling method, the forces on a body are assumed as inputs, and the dynamic motion of the body is assumed as the states or the output. When the state-space matrices are derived, they can be substituted in the full system model. This strategy is also used for the modeling of the Jumbo Container Crane [32]. The alternative popular mechanical modeling approach would be Lagrange’s method. For a state ù and an input ú , the Lagrangian ûü ùý úaþLÿ +ü ùý úaþ -ü ù þ is defined as the difference between the kinetic and potential energies. The dynamic behavior resulting from Lagrangian dynamics has the form ü ý þ ü ý þ$ü þ (2.1) where is a set of generalized coordinates, and the sum of the forces and torques. The form can then be transformed into a state space model ù Lü ùý ú ý þ , where Lü þ represents the physics of the problem [40]. The advantage of Lagrange’s method is the consistency of modeling. If the designer is complete and accurate in formulating the problem, then Lagrange’s method provides almost like a “cookbook” solution. However, in solutions of control problems, using the Lagrangian method, the physical meaning and the interpretation of the resulting model is hidden, and it will be hard to analyze, modify or add physical components of the sytem. Also, a condition for the Euler Lagrangian dynamic analysis is that ûü ùý úaþ must be analytical in the region of interest. The VVSS is a closed loop system that incorporates the human driver in the loop. The user inputs will change the torque and angle on the wheels. The wheels on their turn will apply inputs to the vehicle frame model. The vehicle system will then be rendered in the drivers’ environment where the driver will react and generate new inputs to the simulation. This human-in-the-loop model is graphically illustrated in Figure 2.1. When the drivers’ actions and the terrain data are taken as inputs, and the vehicle configuration as a set of parameters, then a representation of the simulation system can be expressed in the following non-linear state-space form ! x¯ u¯ ü x¯ ý u¯þ x¯ u¯ ü x¯ ý u¯þ " x ¯ y ¯ For complex physical systems, the direct feedthrough matrix is generally zero. (2.2a) (2.2b) # µslip . zg zg $ Model Transmission Engine & Brake Model Steering Model % αth αb θcmd TG Tb & Model Tire Slip Wheel Spin & Tire Deflection & Suspension Model Suspension and Wheel Dynamics SII Fslip ωw Fdefl Model Dynamic Frame Vehicle Gravity G Wind Fwind Vehicle Properties SIII Θ p ' Terrain Model Driver Environment SI 8 Figure 2.1: Overall virtual vehicle simulation system model with three partitions and human in the loop. 9 )+( * , .( * , / with x u and x u being non-linear functions of the states x and the inputs u. Note that these ¯ ¯ ¯ ¯ ¯ ¯ non-linear functions are independant of time . Time varying parameters in these functions are considered constant or near-constant. This condition implies some limitations in the generality of the formulation in that Equations 2.2 model the system around a certain equilibrium condition. )( * 0 , 1 2 3 .( * , 4 The system is thus characterized by the four matrices , , and and the non-linear driving functions x u and x u . A compact descriptor model for the system can be formulated as ¯ ¯ ¯ ¯ follows 57x6 where, for a system with as D states and E ¯ y ¯ <=> 8:9; [email protected] B x ¯ u ¯ (2.3) F inputs and outputs, the descriptor matrix <== I1 H J HLK K KM1IH J N == .. . . .. == . . . == 1QN J HRK K KS1QN J N => 3IH J HLK K KM3IH J N ; 9 ... . . . ... G 3QT J HUK K KV3QT J N I2 .H J HOK K KM2IH .J P .. .. .. . 2QN J HLK K KS2QN J P 4:.H J HLK K KS4:H. J P .. .. .. . 4WT J HRK K K4WT J P ) H * x u¯. , ¯ . ). N * x. u- H * x¯¯. , , u¯¯ . T * x.. u¯, ¯ @ BB BB BB C:BBB X ; will be given (2.4) Using this representation in Equation 2.3, the vehicle dynamics model that is given in Figure 2.1 will be formulated. From Figure 2.1, it can be seen that the model can be partitioned in a series and , for the steering, brake and powertrain, for the suspension of three submodels , and wheel dynamics and for the chassis respectively. ;IY ;IY Y JZ ;IY Y Y In this section we will summarize the vehcile model in the representation of Equation 2.3. Appendix A contains the detailed derivations for each of the elements of the submodels. The appendix and the nomenclature are referred to for the explanation of the variables and parameters. The steering model, brake model and engine and transmission models are described by the analytical descriptor matrix => <== [ [O[O[ \ ]^ ^ [\[O[O[ `Wa]b * * _+_ c d - gh - @C B (2.5) B W ` j i O [ O [ [ [ B ,fe ;IYQ9 where x is empty. Hence, there are no dynamic states. The matrices 1 , 2 and 3 in Equations 2.2 ^ ¯ _ + _ are empty. The inputs are the steering command k l Pm , the brake and throttle angles and c d , 10 Interaction with human driver and terrain n op op p op p p Figure 2.2: Closed loop system interconnected model for the VVSS. t+v ws and the average wheel spin velocity and the steered wheel angle , rq s , and the outputs are the brake torque tu , the traction torque yzz w | }~ z{y t u z{ u u + : y¯ t+s v ¯ Qp x rq s p x w where the brake torque tu is given in Equation A.12, and W is the steering gear ratio. (2.6) The wheel spin, deflection and suspension deflection model is characterized as a double spring damper system plus an inertial spinning body. The inputs are the tire and suspension deflection and the torques acting on the wheel. The descripting matrix the becomes I s ª© © p (2.7) ¦ p ¦ ¬ ~ ® ¯ ¬ ° ¯ ± with yzz s yzz f yz{ z{M ² s z{ ´ y ¬ ¬ ~ ° ® ¯ x u (2.8) r A : + t v ¯ ¯ ¯ ³ ¯ p pQx s p pQx tu p p x ± ¬ ¬ ° where ~ ® ¯ is given in Equation A.21, in A.20 and ¯ in 3.4. s can be found in Equations A.19. This model applies to each corner of the vehicle. ± The wheel axle centerpoint ¨ yzz jOO zz OO zz ¢¡ ¡ jOO ¡ zz ¡¡ £¥ zz{ p ¦¤ ¨§ ¡ j«L jOO p p x jOO jOO 11 µ ·Q¶ ¸ is solely modeled as an additional output for the purpose of rendering graphics in the location animation stage. Finally, the vehicle chassis dynamic model is characterized by the translational and rotational motion dynamics. The inputs are the forces and torques that act on the body and the outputs are the position and the roll, pitch and yaw. Further details can be found in AppendixVDdetails Section A.8, Equations A.23, A.26 and A.27. The descriptor matrix is given by, ÀOÀÁÀÁÀ ÂÅÇ Ã¥Ä Æ À À Ï ÐÐ È Á À ÀÁÀ ÀÀÉ À À ÐÐÐ È È È À À ¥ Ã Ä O À À ¥ Ã Ä À ¹Iº º ºQ»½¼¾¾ ÀOÀ ÅUÊ Ë Å À ÀÀÉÅ À µ Ì Ê ÀÀ ÐÐ (2.9) ¾¾ À Î Ì Í Á À À À É À À À ¾¾ ÀOÀÁ ¾¿ Æ À Æ ÀÀÉÀ À Ñ where the coriolis and cenrifugal force matrix Ê Ë is explained in A.24 and the Euler angle transformation matrix ÌÎÍ inA.25. The inputs and outputs are given by × µ Ù¶ Ú Û Í Ü Ý ¸¥Þ µ Ù¶ ß Ü ¸ à Ý ¸¥Þ µ Ù+¶ á Ü Ü Ý ¸ âÞ µ Ù+¶ ã¸ ä Ú Ï ÐÐÐ µÓÓ ¶Ò Ï ÐÐÐ ¸GØ µ Ð º º º »èç µ Ó ¶ å¶ ºx º º » ¼¾ µ Ô ¶ uº º º » ¼¾ Õê é y × µ æ+¶ Ú Û Í Ü Ý ¸Þ µ æ+¶ ß Ü ¸ à Ý ¸fÞ µ æ¶ á Ü Ü Ý ¸ Ö µ ¶ ¯ Ñ ¯ ¾¾¿ µÊ Õ ¶¶ ÑAÖ ¯ ¾¾¾¿ ¸ µ (2.10) With the formulation in this section, the model for the vehicle simulation system can be depicted in a chain of submodels as in Figure 2.2. 2.3 Conclusion With the models in this chapter and the necessary details in Appendix A, a stand-alone basic scheme for a vehicle dynamics model has been formulated. Three partitions have been presented in Expressions 2.5, 2.7 and 2.9. Some of the submodels are simplified, but will suit general prupose vehicle driving simulation studies. Note that a novel tire friction model is developed in Chapter 3. Chapter 3 Fuzzy model of tire traction dynamics A fuzzy logic tire friction model is introduced to improve the representation of the characteristic of the friction behavior. The model is based on the model by Howard Dugoff with the addition to make the solution stable for low speeds. The new model constitutes from previous efforts by Dugoff, but incorporates an additional spring-damper system and a fuzzy logic “switch”. Without the modification, the existing Dugoff tire model is numerically unstable in the region where slip velocity is small, because of the possibility of division by zero. This chapter explains the details of the fuzzy logic tire model, demonstrates the implementation and shows simulation results. 3.1 Introduction One of the major barriers for the development of a ground vehicle simulator is the modeling of the constraints regarding the tire ground contact. The lack of these constraints is the major cause for flight simulators to be successfully used for many years. The tire dynamics in different driving scenarios have been investigated intensively. Some of the more outstanding efforts by Fiala [19], Howard Dugoff [16] and more recently for example by [3], [43] and the Delft University of Technology [49] and [51]. Empirical studies have been conducted as well [23]. Tire manufacturers have done extensive studies on tire behavior, however the results are of strategic value and thus proprietery. The general friction force curve is drawn in Figure 3.1. The problem with most of the existing tire models is that the solution of the slip force is a function of the slip velocity (like it is drawn in the figure). However, especially for low-order numerical simulation, the responce of the model for very low speeds will become noisy and inaccurate. In many situations it may even drive the simulation into a limit cycle. As a result, the vehicle model could only be simulated for a minimum velocity. It woult not be possible to come to a halt or to backup the vehicle. For the purpose of a the VVSS, a novel tire model has been developed, which overcomes this 12 13 |F| Fstick Fcoulomb Fviscous v Figure 3.1: The general characteristic curve for the friction force as a function of sliding velocity. problem. It is based on the work of Dugoff, but modified to incorporate stick friction at low slip velocity, by adding a differential position force feedback loop. The physical derivation as proposed by Dugoff is outined in Appendix B. The following sections discuss the fuzzy tire model in more detail. The objective is to relate the expressions for the forces between the vehicle and the terrain surface to physically meaningful parameters and variables. The “magic formula” by Pacejka, as well as many of the neural network based models do not. They will therefore not be considered any further. 3.2 Stick Friction with Fuzzy Logic Switching The derivation in Dugoff’s model solves for the forces on the tire and the wheel carcas caused by sheer and stress. The derivations imply that the tire should be rolling and the vehicle should be moving in order for the model to return meaningfull results. (This implication can also be noted from Equation B.3 where the expression for has the tire’s longitudinal velocity in the denominator.) ë ìí ëIîï As a result, a tire will not be exposed to any forces from the ground contact, when the slipratio . This can also be seen in the left graph in Figure B.3 in Appendix B. In practice, it means that a vehicle will slowly slide down a slope, eventhough the surface is very rough, thus having a high slip coefficient. In numerical simulation the model renders unstable results for slow speeds, and is singular for zero velocity. To compensate for this behavior, a feedback loop is imposed from the integrated slip ratio to the moving forces. The feedback is designed as a second order spring damper model between the tire carcas (which is the point where the rubber touches the rim) and the ground contact point. It is applied from the position output to the force input. Fuzzy logic is applied to transition between this spring damper model and the Dugoff tire model. The design of the combination of the Dugoff model with the additional feedback loop is shown 14 ΣF òp ð 1 õF ÷ Mvs vehicle model slip,i òp 1 s òp 1 s ñ Shear Friction υv + FFr |Fz| ö + Kstick ø slip angle Fuzzy Logic ô - slip magnitude µSt Stick Friction Dstick ö υw normal load on the tire FSt vv=p arctan(vv,vw) + δ=max(vv,vw) δ reset 1 s vw Re effective tire radium Re ð ΣT ð 1 Mws wheel spin model 1 s ωw 1 s ó θw Figure 3.2: Schematic diagram of the modified fuzzy tire model. On top, above the dashed rectangle, the simplified vehicle model. In the bottom of the dashed rectangle, the wheel spin model. The tire model consists of the Dugoff shear friction model, a spring-damper stick friction model and a fuzzy-logic switch. in the model diagram in Figure 3.2. The model shows that next to the dynamic friction force feedback, there is an additional force feedback from the integrated velocity difference. This force represents the stick-friction. Fuzzy Logic is an intuitive non-linear linguistic rule-based method of inferencing. Two rules are switching the force feedback, based on fuzzy sigmoid membership functions. The input force to the vehicle motion model (top of the diagram in Figure 3.2) for tire consists of the shear and stick slip forces as ù ú ú ú û ü ý þ ÿ þ û û ù ú û ú û (3.1) where the index denoting the corner of the vehicle for the slip force, is included for consistency in the overall vehicle model. Furthermore, , since both and represent the tire force, each for different operating conditions. The sum of the membership functions in Equation 15 v v v s w1 2 1 u v s v,t=kh w u w1,t=kh 3 4 Figure 3.3: The stick tire model is modeled as a double spring-damper system between the trajectory of the vehicle and the trajectory of the wheel. and are the trajectories for the vehicle and the wheel spin velicities, and and are the positions on these locations at time . ! 3.1 therefore needs to be always 1. The input torque to the wheel becomes # $" % & ' ( ) ' *,+ - % & ' ( ) . ) ' (3.2) /0 1 is a sigmoid membership function, given by /0 1 2435 6 7 8 9 : 2 ;=<?> @ A 8 ;=B C D (3.3) Figure 3.4 shows the plot for the membership function in Equation 3.3. In the equation, E represents the gradient factor and F represents the center of the switching region. This center point is based *,+ . This maximum defines the slip velocity, which is the command on the maximum of G and HI where value for the fuzzy switching. The following equation summarizes the fuzzy switched tire model JK / " 0 1 - 0 1 ) . N "- RS ) . V W / 0 1 Q 3 M P 2 O "- % & ' ( ) ' L /" 0 1 - 0 1 ) T N 3 M 2PU O /0 1 Q "- RS ) T X The stick model force - 0 1 is given by "- 0 1 ) . Y % 1 ' M ) . O Q 3[ % 1 ' 2 M ) . O Q \ BZ BZ (3.4) (3.5) 16 Membership functions for the fuzzy tire model 1 µ =1/ St 4(|x|−6) 1+e µ =1−1/ Membership Fr 4(|x|−6) 1+e 0.5 0 −6 0 6 max(v ,v ) v w Figure 3.4: Graphical display of the fuzzy logic sigmoid membership function. ]_I^` a b c de f#g b h i j kl c d4mn_g b h i jpo kl c d q (3.6) I^` a b , and to represent the physical In order for small numerical errors to accumulate in the force property that a pair of rolling tires will not accumulate opposite lateral forces, a high-pass filter with low cut-off frequency is applied. The trajectories and are thus computed as the high-pass filtered integrals of the differences of the vehicle and wheel spin velocities and . pl p^ l c j s?tevua bw p ^ l c j4m p ^ ] c j s?t4evua bw p ^ ] c j4m p] x^ l c j y x^ ] c j y r^ l r^ ] (3.7) (3.8) z In other words, the velocity difference is integrated, and the result is subjected to a “decay” factor in time. Using the discrete time domain, the trajectories can be expressed in the -transform representation as k^ l=w { ye uua a b b {=} t?x ^ l=w { y (3.9) o | u a b k ^ ] w { ye u a b {=} t?x ^ ] w { y (3.10) o| `~ c and `~ c d are depend on the particular The longitudinal and lateral shear friction forces terrain surface. Their values are derived from the Dugoff tire model in Appendix B. The inputu output map for , the most relavant factor in the expression for the friction forces is given for the 17 ν (vehicle speed) v Forward +µ −µ Braking µTraction ν (wheel speed) w Traction Braking Reverse Figure 3.5: Polar slip friction coefficient representation. longitudinal force in Figure 3.5. The absolute value for is read from the graph as a function of the vehicle and wheel speed velocities. When is to the upper-left side of the dashed line, its sign is negative. 3.3 Implementation At the implementation level, the algorithm can be assembled according to the above equations and the results of Appendix B (In particular Equations B.34 to B.43). The calculation of using the the dynamic equations in the Dugoff model, can result in time consuming numerical problems, especially when the velocities are small. A condition for computing the equations that relate to the Dugoff model is introduced in the actual code, since the equations need not be solved for low speeds, because the stick model will then be applied. if (fabs(WheelSpin)>fabs(WheelTravel[PF_X])) mspeed = fabs(WheelSpin); else mspeed = fabs(WheelTravel[PF_X]); membership = 1/(1+exp(4.0*(mspeed-6.0))); patch_dispx[i] -= (WheelTravel[PF_X] - WheelSpin)*dt; 18 patch_dispy[i] += WheelTravel[PF_Y]*dt; patch_dispx[i] *= membership; patch_dispy[i] *= membership; if (membership<0.9) { SlipDir = WheelTravel[PF_Y]/abs(WheelTravel[PF_X]); SlipRatio=(WheelSpin-WheelTravel[PF_X])/mspeed; Vs = WheelTravel[PF_X]*sqrt(SlipRatio*SlipRatio+SlipDir*SlipDir); mu = (mu0) * (1 - AS * Vs); CoefDen = mu*abs((FTire[i])[PF_Z])*(1.0-SlipRatio); SlipNorm = CS * SlipRatio / CoefDen; Alpha = CA * SlipDir / CoefDen; SlipMag = sqrt(Alpha*Alpha+SlipNorm*SlipNorm); if (SlipMag<0.5) CoefDen = (1.0-SlipRatio); else CoefDen = (1.0-SlipRatio)*SlipMag/(1.0-1.0/(4.0*SlipMag)); SlipForce.set( CS*(SlipRatio/CoefDen*(1-membership)+ (patch_dispx[i]-(WheelTravel[PF_X]-WheelSpin))), -CA*(SlipDir/CoefDen*(1-membership)+ (patch_dispy[i] + WheelTravel[PF_Y])), 0.0); } else SlipForce.set( CS*(patch_dispx[i] - (WheelTravel[PF_X]-WheelSpin)), -CA*(patch_dispy[i] + WheelTravel[PF_Y]), 0.0); 3.4 Simulation results Figure 3.6 shows a logic switched coupling of the stick friction model and the Dugoff model in the left, and a smoother fuzzy aggregated coupling of the models in the right hand side. For the fuzzy logic switched model, the membership functions in Figure 3.3 have been used. The figure shows a scenario for acceleration, and braking, followed by a positive constant torque forward, and reverse constant torque reverse. 19 Forces with Logic Switch Forces with Fuzzy Logic vv vw Speeds (m/s) Speeds (m/s) vv vw 6 0 10 20 30 40 50 0 10 0 10 20 30 40 20 30 40 5000 Forces (N) Forces (N) 5000 0 −5000 −10000 6 0 10 20 30 Time (s) 40 50 0 −5000 −10000 Time (s) Figure 3.6: Simulation results with the fuzzy tire model for acceleration and braking. The top graphs show the velocities, the bottom graphs the associated longitudinal slip forces. The left graphs shows the slip forces when using a digital logic switch for the friction models. The right graph shows the smooth transition when using fuzzy logic switching. 20 3.5 Conclusion A new fuzzy logic based dynamic tire friction model has been derived, to simulate realistic force response, for all vehicle and wheel speeds. The fuzzy tire model is based on physical characteristics and properties of slip friction and stick friction. The stick friction properties have been modeled as a spring-damper system for the longitudinal and the lateral directions for in case of slow driving scenario, hence in the situation of no slip. The model presents a set of analytical equations that is incorporated into the vehicle model, allowing it to simulate a vehicle in driving scenarios of any vehicle velocity. Chapter 4 Numerical Integration of the Vehicle Model The vehicle model and the fuzzy logic tire model have been defined in the precesing chapters. The next step towards implementation and numerical simulation is the selection of a suitable integration method. Integration methods are studied by many scientists in a wide field of research. The emphasis in this thesis is on the real-time application and the non-linear character of the model. In this chapter, first an overview of integration methods for real-time application and accuracy will be given. Then the discussion focuses on the interconnected system for digital real-time integration algorithms. Examples are given for illustration. 4.1 Transformation and Integration Methods The closed loop system of the vehicle system has been modeled in three submodels in Chapter 2. The next task towards simulating, is to translate this model so that its behavior can be calculated in a computer. This task is discussed in the following sections. When a continuous time system is simulated on a digital computer, its response is computed at closely spaced discrete times. Output results are generated by joining the closely spaced calculated response values with straight line segments, approximating a continuous curve. The accuracy and speed of computation depends on the integration scheme that is used and on the choice of the integration step size. Especially for the real-time simulation of continuous dynamic systems, the choice of numerical integration methods is an important consideration. In real-time simulations, the choice of numerical integration methods is generally based on different considerations than those used in numerical solutions in off-line predictive studies, when there is no real-time requirement. For example, in real-time simulation, a fixed integration time interval is used, since the simulation must always produce the next value of each dynamic state variable at or before the time the variable will occur in real-time. This requirement sets a lower limit on the mathematical step-size which 21 22 f f fn f fn+1 fn+1 fn fn+1 fn fn-1 t → nh (n+1)h x nh (n+1)h a. Forward Euler Integration n+1 x =x n + h (3f n -f n - 1 ) 2 n+1 fn+1 nh (n+1)h x n+1 =x n + h (f n+1 +f n ) 2 d. Bilinear Integration _ =xn+hfn+1 f fn fn+1 fn+0.5 fn-1 t → (n+1)h c. Backward Euler Integration f fn nh t→ b. AB-2 Integration xn+1=xn+hfn f (n-1)h t→ (n-1)h t→ x fn-1 nh (n+1)h h =xn+ (5fn+1+8fn-fn-1) 12 (n-1)h t→ x nh (n+1/2)h (n+1)h =x +hf e. 3rd Order Implicit Integration f. Modified Euler Integration n+1 n+1 n n+1/2 Figure 4.1: Graphical intepretation of different integration algorithms for the differential equation . 23 can be used for integration. The need for a fixed time-step is in fact somewhat of a blessing, since it means that the -transform methods, originally developed for the analysis of sampled data systems can be utilized for dynamic error-analysis of real-time digital simulations. Care has to be taken, to verify that stiff subsystems or marginally stable poles in the continuous sytem do not cause instability after transformation. From Figure 4.2 it can be seen that part of the left half plane in the -domain is mapped outside the unit circle for the forward Euler transformation. In other words, stable poles in the continuous time domain can result in unstable poles in the discrete-time domain when the unsuitable integration scheme is used. This aspect will be further addressed in the following section.. Another consideration is that in real-time simulation, the integration algorithms cannot require external input data prior to the time when it is available in real-time. This eliminates many implicit integration methods that are popular in non-real-time applications. To avoid this limitation, a suitable partitioning of the model into sub-models can be usefull in the sequencial calculation. An emphasis to partition the vehicle dynamics can therefore be noted from the preceding section concerning the development of the model. There will be a maximum allowable integration step size for any given dynamic simulation using a specific integration method, for which the dynamic accuracy of the simulation is barely acceptable. One important aspect is the computer power that is used. From the above real-time requirement, it follows that the CPU cannot take more than seconds to complete all the calculations associated with each integration step. Section 6.3 will discuss this matter as well, once the vehicle dynamics formulation has been defined. Hence, real-time simulation of a dynamic system must be considered as a sampled data system. . The system response is evaluated at equally separated points in time It must be understood that discretization of the system automatically implies the selection of an integration scheme. After the transformation, the linear system in Equation 2.2 is transformed to a system that describes the new states as a function of the previous states and the previous inputs and the new inputs . ? ? ¡ Since the resulting system incorporates an integration scheme, care must be taken in the selection for this integration method, as a more complicated scheme (like a order Runge-Kutta) will increasingly intensify the mathematical effort to compute the solution of the system. The advantage of a complex and more accurate integration scheme is that a larger step-size can be selected. However, this advantage fails when the system behavior is non-linear. Six of the popular integration methods are shown in Figure 4.1. From this overview it is clear that the methods in Figures 4.1a and 4.1c, respectively the forward and backward Euler integration methods, are the least computationally intensive. As the trade-off, they generate the largest simulation error, when used to compute the output response of a system. The next more complex method with improved accuracy, will be the bilinear (or Tustin, or trapezoidal) integration method. Note that the implementation of the modified Euler method in Figure 4.1f would result in the bilinear transformation scheme, when using a fixed integration step size. 24 ¢jω £ Im s-plane z-plane σ (a) Continuous Domain £ -1 Re (b) Forward Euler Transformation £ Im z-plane -1 1 1 (c) Bilinear Transformation Re Im z-plane -1 1 Re (d) Backward Euler Transformation Figure 4.2: Three different transformation methods for approximating continuous to the discrete time domain, with the corresponding stability regions. 25 § ¥ ¤ ©¨ ¦ ¤ ©ª ¦ ¤ © Figure 4.3: A general example of a second order mechanical model with force input and position output. The bilinear method is demonstrated in Figure 4.1d. These three methods have the following transformation equivalents ´ ±± µ·¶ ¤ ± ´ ¤ ² «¬ ¦®¯ ±± µ·¶ µ ¤ ±± ´¸ ¤ ±³ µº¹ µ·¶ ¤ °±± Forward Euler Approximation Backward Euler Approximation (4.1) Bilinear or Tustin Approximation Detailed derivations and formulation aspects on these three schemes can be found in Chapter 13 in [38]. An important consideration for the choice of integration approximation method is the mapping of poles from the -plane to the -plane. Figure 4.2 shows how the area of stable poles in the continuous domain is translated to the discrete domain. From a stability perspective, the better choice for the integration method will be either the backward Euler, or bilinear transformation. ¦ µ A combination of the forward Euler and Bilinear approximation methods in Equation 4.1 is used for the VVSS. To illustrate how they are implemented, consider the continuous time interconnected system in Figure 2.2. Subsystem Transformation » The computation of integrations inside the individual subsystems are implemented with the bilinear transformation method, shown in Figure 4.1 . For example, for a system with force input and position output, as given by Figure 4.3 we would integrate as follows: ©ª ¼ ½?¾ ¯ © ª ¼4¹ ¥ ¤ ¬ © ¨ ¼ ½?¾¸ ¹ ©¨ ¼ ® ´ ?¶ « ¿À©Iª Á µ Â ¯ ¥ ¤ ¬ ´¸ µ·ºµ ¹¶ ¤¤ ® ©I¨ Á µ Â and subsequently (4.2) 26 È ÃË Ä ÃÄ Å?Æ4Ç ÃÄ4ÈÊÉ#ÃË Ä Å?ÆÌÎ ÍÐÏÒÓ?Ñ Ô ÃIÕ Ö ×ÇØÉ ÏÌ ÖÖ È ÙÙ Í IÃ Ë Õ Ö × Ó (4.3) The selection of the above integration methods is based on the fact that maximum accuracy is desired for the dynamics response of the internal subsystems. At the same token, the simulation will have to be conducted in real-time. This means that a fixed integration step size will have to be used, and no iteration schemes can be applied for evaluating a single point in time. Hence, only explicit methods are applicable. Ú The application of the integration method leads to a discretized approximated system continuous system in Equation 2.3. It will result in the discrete state space system ÏÌ ÕÕ ÖÖ ÈÙÙ ×× É Ý Õ Ö × x ÈÞ_Õ Ö × u ÈvßÕ x u× Í Ó ¯ ¯à ¯ ¯ Çy á x Èâ u ÈãÕ x u× ä ¯ ¯ ¯à ¯ ¯ x ¯ Ö Ç ÚÜÛ of the (4.4a) (4.4b) åÇ æÏ È Ï The inverse -transform applied to Equation 4.4b will give the following solution to for the system response at Ä Å?Æ Ç Ýºç xÄ ÈvÞ ç Õ uÄ Å?Æ È uÄ ×Èè çºÉ ßÕ xÄ Å?Æ uÄ Å?Æ ×ÈßÕ xÄ uÄ × Í ¯ ¯ ¯ ¯ à¯ ¯ à ¯ Äy Å?Æ Çá x¯Ä Å?Æ Èâ u¯Ä Å?Æ ÈãÕ x¯Ä Å?Æ à u¯Ä Å?Æ × ¯ where the lumped matrices Ýºç , Þ ç and è ç are given by Æ Ï Ýºç ÇØÉ=é Ó Ì Ý Íê É éºÈ ÏÌ Ý Í Æ Þ ç Ç ÏÌ É é Ó ÏÌ Ý Í ê Þ Æ è ç Ç ÏÌ É é Ó ÏÌ Ý Í ê x ¯ (4.5a) (4.5b) (4.5c) (4.5d) (4.5e) System Interconnection ëì ëì ì í î ëì ì ì Now take the system in Figure 4.4. This system is a decoupled version of the model of the VVSS, given in Figure 2.2. Assume that the subsystems , and are discretized with the bilinear integration method, as discussed in the preceding paragraphs. The resulting transfer functions for the subsystems are now given by y ¯ Õ Ö ×Ç ë ç Õ Ö × u Õ Ö × , or in short y Ç ë ç Õ Ö × u ä ¯ ¯ ¯ (4.6) 27 Interaction with human driver and terrain u ¯ ï ôõ ö x ¯ ðñ ò ó ÷ ôõ ö x ¯ ðñ ò ó ó ø ôõ ö ðñ ò ó ó ó x ¯ ù ôõ ö Figure 4.4: interconnected discretized closed loop system. ú=û , each of the three subsystems will be In the process of evaluating the system at a given time computed consecutively. Figure 4.4 shows the model for the VVSS in discrete time representation. The submodel with the human driver and terrain is denoted by the operator . For the first subsystem , we must realize that the input u at is computed from the output of the ¯ third system at the previous time interval , hence ü ô ýö þ÷ ÿ ú ÷ uþ ÿ ü xþù (4.7) ¯ ¯÷ ÷ Obviously, if ü has any dynamics, they will be integrated using forward Euler. In the following ô ýö derivations, the subscripts , and will be employed for the system matrices and to ú ðó denote which subsystem they apply to. The output of the first subsystem is computed as x ¯ þ÷ ÿ ÷ þ÷ ñ òó x ¯ ñ òó ó x ¯ ñ òó ó ó x ¯ ñ òó u ¯ þ÷ ÿ ÷ u ¯ þ÷ (4.8) þ÷ Then, for evaluating the second subsystem, we realize that the input is the output x of the first ¯ subsystem that has just been computed. Incorporating this gives x ¯ þø ÿ ÷ And for the third subsystem similarly x ¯ þù ÿ ÷ þø þù ñ òó ó õ ñ òó ó ó x ¯ þ÷ ÿ x ¯ þø ÿ ÷ ÷ x ¯ þ÷ x ¯ (4.9) þø (4.10) The above equations can be formulated using the -transform for the linear terms, as x ¯ ÷ ôõ ö ô õ ñ ò ó ö ÷ ñ ò ó u ¯ xþ uþ ÿ xþ uþ ô ¯÷ ¯ ö ô ÷ ó ¯ ÷ ¯ ö ñ òó ó (4.11) 28 x x 8 9 x8 : x 8 9 x8 "! # $&%' ( # $ )*+, - . . ( /10 2, - . . 3 ¯ 40 %5, - . .67 . . # ¯ ¯ 0 ( %7 . . # ¯ ¯ 0 (1; 0 8 9 x x x8 : x 8 9 x8 x ¯ < "! # $&%' ( # $ )*+, - . . . ( /10 2, - . . . 3 ¯ 4%5, - . . .67 . . . # ¯ ¯ < (4%7 . . . # ¯ ¯ < ( ; 0 x ¯ (4.12) (4.13) The above process of evaluating system response implies the application of the Tustin bilinear method for the connecting subsystems. Notice that the matrices and have function for the subsystem interconnectivity, the 2, - . . 2, - . . . system can be completely described in a large state space representation as =>? $ x ¯ x0 ¯ x ¯< @A =>? B % =>? @ A =>? @A x +, - .DC C B x¯ 0 B 2, - . .E+, - . .DC ¯ % x CF2, - . . .G+, - . . . ¯< x8 9 x8 : x8 9 x8 5, - .H! 7 I . # ¯ x8 ¯9 < x8 : (%J7 I . # ¯ x¯8 < 9 (1x3 8 5, - . .H! 7 I . . # ¯ x8 ¯9 < x0 8 : (%J7 I . . # ¯ x¯8 < 9 (1x3 8 5, - . . .H! 7 I . . . # ¯ ¯ < 0 (%J7 I . . . # ¯ ¯ < 0 =>? @A 2, - . B C @AC u ¯ B (4.14) (13 It is important to notice that the above explicit formulation incorporates the bilinear integration scheme. This notion implies that the system matrix is not constructed from intuitive equations of motion anymore. Only forward Euler formulation will do so. The following example demonstrates this point. EXAMPLE 1 Embedding of integration scheme. Assume the following linear system of three integrators: O P KL 0 LM P LN P < Using the bilinear integration method, this system is described by the following set of simultaneous equations P 8 R KS TVU O 8 : R O 8 W 04Q 0 0 : P 8R M S T U P 8 : R P 8 W 04Q 0- 0 0: P 8R N S T U P 8 : R P 8 W 04Q < - U Y RZ W - 0 Notice that new state values (i.e. for X S ) appear in the right hand side of these Q equations. The above equations can be evaluated, using the new state values immediately in P 8 0P 8 P 8 <- : 29 the second and third equation. We can express the result of this implicit process in an explicit form by substituting the expression for [\ ] ^ _1\ in the second equation and then substituting the expression for [` ] ^ _1\ in the third. Rearranging of the result after substitution gives [\ ] ^ _1\4ab[\ ] ^ced fg ^ ` [` ] ^ _1\4ab[` ] ^ceh f[\ ] ^ced h f V i g^ ` j [ j ] ^ _1\4ab[ j ] ^cek f[` ] ^ceh k f i [\ ] ^cld h k f m g ^ From this last equation, we could not tell at sight that [j is the integral of [` . Generally, a system of simultaneous equations will be transformed to produce an explicit expression for the state values using linear algebra. The following example will show this process. EXAMPLE 2 Linear vector solution of differential equation using Tustin Take again the linear triple integrating system from example 1. Consider the set of three simultaneous equations. After separating state values for n4ao p cbq r f and n4abp f to the left and right side of the equal-sign, the following system will appear stu | } stu qwvxv y h z` q{v ~ y v k z` q | } tus | } tus | } tus |} [\ ] ^ 1_ \ q vv [ \ ] ^ df [` ] ^ 1_ \ ~ a h z` qv ~ [ ` ] ^ ~ c v ~ g^ [ j ] ^ 1_ \ [ j ]^ v vk z` q Multiplying left and right side with the inverse of the matrix on the left, will result in stu | } tus [\ ] ^ 1_ \ qwvxv y [` ] ^ 1_ \ ~ a h z` q{v y [ j ] ^ 1_ \ v k z` q stu |} qvv a h z` qv ~ h k z k z` q stu |} qvv a h fqv ~ h k z ` k fq | } \ stu qvv h z` qv ~H vk z` q | } stu stu qvv h z` qv ~ vk z` q stu | } stu [\ ] ^ df [` ] ^ ~ c d h z` d h k z [ j ]^ | } stu | } tus |} [\ ] ^ df v ~ g ^ ~ [` ] ^ ~ c [ j ]^ v | } tus |} [\ ] ^ df [ ` ] ^ ~ c v ~ g ^ [ j ]^ v |} ~ g^ The individual state equations of this solution are equal to the ones in the preceding example. For example the state equation for [ j is given by ` [ j ] ^ _1\4ab[ j ] ^clh k f V i [\ ] ^clk f[` ] ^ which cannot be immediately observed from the system model diagram. In this example we have transformed the discrete model into an explicit form. The representation is the solution to the state transition equation. 30 The method of matrix inversion of Example 2 cannot be used for the non-linear system of the VVSS. These linear examples with linear models however, illustrate the complexity of the approximated discretized model when using the bilinear integration method. The non-linear model is organized in such a way that the structure of the state transition matrix approaches lower triangular shape as much as possible. The lower triangular shape allows for immediate substitution of state values for Vb in the sequencial evaluation process, as was illustrated in Example 1. The ideal formulation for the system is thus given in Expression 4.14. The aim towards this structure fails whenever there is internal feedback. For internal feedback, only values at the previous time step " are available for the states that are fed back. The integration method for the feedback loops will thus be forward Euler 4.2 Conclusion The requirement of real-time simulation adds a serious constraint to the selection of a numerical integration method. The discussion in this chapter highlighted on the necessity for an explicit formulation of the state equations, after incorporating the integration approximation method. The bilinear integration method applies well in the case of decoupled interconnected systems. In cases when internal feedback appears, the forward Euler approximation method has to be used. The bilinear method is not too complex so that it can be used for real-time simulation, yet it is stable and sufficiently accurate to simulate the vehicle dynamic response in a reliable fashion. In the reccomendations, a Luenberger observer is suggested, to estimate state values, so that the bilinear integration method can still be used, but based on estimations of the state values. Chapter 5 Simulation Platform with Integrated Networking Environment In this chapter, the multi-processing configuration for real-time simulation is introduced. The name in the title will be referred to in short with SPINE. The objective is to implement the VVSS in such a way that other workstations can interact with the vehicle model during the simulation, while minimizing disturbance to the simulation performance. It will be shown that by simulating parts of the vehicle model in a remote workstation through SPINE, a change in integration scheme takes place. The implications of this change will be discussed. Furthermore an observer system will be introduced to predict simulation output when a workstation does not respond in time. 5.1 Introduction Modular thinking has introduced a new realm of engineering of a fundamental systems approach. Methods on modularity are diverse and are associated with many disciplines. The common philosophy, is that subsystems can be considered individually, without loss of generality in the overall systems requirements. The next step in the exploration towards virtual vehicle system simulation is modularity. The VVSS will become effective and efficient for virtual engineering and prototyping when partitions and submodules of the vehicle model or the virtual environment can be substituted. At the same time it will be beneficial in several ways, to simulate these modules remotely. It is beyond doubt that simulation performance can be improved, when different modules are executed on different machines. This will allow for multi-rate multi-processing in a integrated system structure. Furthermore, it will contribute to the generality of the simulator, when attributes to the virtual environment (like terrain, the vehicle platform, optional armor etc.) can be replaced as modules in a multi-purpose simulation facility. 31 32 Stereoscopic Scenery Display Full Observer/Commander Virtual Mission Immersion Pentium-PC Traction Control Pentium-PC Anti-Lock Brake model TCP-IP Pentium-PC Active Suspension Pentium-PC Collision Warning 100 Base-T Pentium-PC Driver Cab Interface Pentium-PC Intelligent Peripherals Human Driver Human Driver Pentium-PC Engine and Transm Contr Pentium-PC Trajectory, Navigation Silicon Graphics Reality Engine 250 MHz 4xR10000 CPU IRIX-Performer Stereoscopic Visualization Bilateral Force and Motion interface Surround Audio Figure 5.1: The proposed implementation for the Virtual Vehicle System Simulation (VVSS) in the Simulation Platform with Integrated Network Environment (SPINE). As a third, not the least important argument, system modularity allows the researcher to extract one module from the simulation, and replace it with another (high detail) module, in order to gain more fidelity and hence more accurate simulation results for the particular subsystem. Modeling several high fidelity models through SPINE in this manner implies the simulation of a high detail model with intelligent load distribution. Or an engineer could replace a submodel of the vehicle system to analyse new control concept systems. Finally, it will be advantageous to Oakland University, to be able to conduct additional research gradually, for future improvements on the VVSS. The modular design in this chapter contributes to these goals. 5.2 Methods for multi-processing Multi-processing needs to be viewed upon as a method for performing the computation task of, in this case simulation. To speak in general terms, assume the following model to be the system that we would like to simulate: ¡ ¢¤£ (5.1) Three methods for multi-processing in the application of simulation will be discussed, each with 33 CPU1 CPU2 CPU3 ¥¦ ¥§ ¥¨ (a) Configuration 1 CPU3 ®e± CPU2 ®e° CPU2 CPU1 ©H¬ CPU1 CPU1 © ª« ®e¯ © ª (b) Configuration 2 (c) Configuration 3 Figure 5.2: Three variations of configurations for Multi-CPU simulation models. 34 a different partitioning of ² . First there is the proper model partitioning method. As shown in Figure 5.2a. The model has internal chain connectivity. It must be object-oriented, decoupled and the total system will have to have a cascaded configuration. The disadvantage for multi-processing is that, if a model is divided into several partitions, each partition can only use the simulation results of the previous time step for every other partition, since the current results for the other partitions are being computed simultaneously in parallel. In other words, the decoupling introduces a time delay into the system, because the interconnection between the subsystems can only be defined in an explicit manner. As a result, the response of the system for input actions will be retarded and there is the possibility of the system becoming unstable. From the point of view of mathematical integration technique, the bilinear method is replaced with the Euler method at each subsystem interconncetion. A solution for the time delay and the instability problem would be, to cancel the delays by adding a zero in the origin of the pole-zero map of the system, for each interconnection. Technically this would change the integration method between the subsystems from forward Euler to backward Euler. The implementation however, would mean that the CPU’s have to wait for eachother to finish their computation. In other words, a system solution for ³ ´Jµ¶·¶ will be ready after ¸ simulation clock cycles, where ¸ is the number of interconnected subsystems. This solution would defeat the purpose of parallel computing and multi-processing. Then there is sequencial simulation, as demonstrated in Figure 5.2b. This method could be implemented using semaphores or waitstates to synchronize communication and processing. CPU 1 will evaluate a partition of the system, communicate with CPU 2, and then wait for the output of CPU 2 before it will finish the simulation cycle. This method does not exploit double computer power for parallel processing. In fact, the simulation is pseudo single-processing. The third method is based on concurrent computing of states, as shown in Figure 5.2c. The required inputs for solving the equations of a (submodel for a) state will be made available by the first CPU. In this fashion, high frequency dynamics in the model can still propagate high bandwidth to the output. However, the bandwidth of the output of the submodel will be limited. The last method results in a generalized formalization of multi-processing, at the cost of decrease of bandwidth for parallel simulated states. Since this configuration allows us to select parallel subsystems in the form of specific dynamic states, this method is adopted for SPINE. The next section will detail about the third configuration. 5.3 Multi-processing of dynamics models The setup for the multi-processing vehicle simulation is presented in Figure 5.1. The mathematical approach for the interaction of modules with the vehicle simulation is presented in the following paragraphs. The concept is to replace one or more states in the general vehicle dynamics state space system matrices, with outputs of a model that is simulated elsewhere on the integrated network. 35 For the interaction this means that in each integration step, the VVSS will request the modules for replacement of system states, and then return a set of updated states. The vehicle dynamics model has been presented in Chapter 2, and is given in the form of the nonlinear state space representation in Equation 4.14. To introduce the concept of replacing state variables in a system, a general case of state-replacement for a linear system will be presented as an example first. EXAMPLE 3 Substituting a state in a linear system and adding a state. º¤ ¹ »J¼ º½ ¾ ¿ ¿ ¿ ¾ º À ¾ ¿ ¿ ¿ ¾ º Á Â Ã Consider a linear homogeneous system, consisting of the state Ä »Å Æ ÇbÈ É Ê where each element is given by Ï Ï º À Ë Ì Í1½»bÎ ÏÐHÀ Ë º Ë Ì ¾ÒÑ ¾ ÓÔ¤Õ È ¾ Ö× × × Ø1Ù at (5.2) Suppose that state variable º Ú represents an element in the dynamic model. The equation for Ä the state º Ú at time »Å Æ ÇÈ É Ê is described by ßàà º½ Ë Ì ã ää ä àà àà ... äää àà º Ú â1½ Ë Ì ää Ûº Ú Ë Ì Í1½4»ÝÜ ÐÛ Ú Ë ½× × × ÐÛ Ú Ë Á Þ àà º Û Ú Ë Ì ää ¿ ààá º Ú Í1½ Ë Ì ää .. . º Á ËÌ (5.3) å Û The submodel for evaluating the state º Ú may contain additional states. In this case a state will be added to the total system. An additional row in the transition matrix will express the dynamics of the new state; ßàà àà àà ã ää º½ Ë Ì ää ää .. . àà º Ú 1â ½ Ë Ì à Û º Û Á 1Í ½ Ë Ì Í1½4»ÝÜ ÐHÛ Á Í1½ Ë ¡ ½ × × × ÐHÛ Á 1Í ½ Ë Á Í1½ Þ ààà º Ú Ë Ì àà º Ú Í1½ Ë Ì áà .. . º Á ËÌ º Û Á Í1½ Ë Ì ää ää ää ¿ ää (5.4) ä å Û and an additional column is added to represent the contribution of the added state º Á Í1½ to the Ä states º À for Ñ1»È4¿ ¿ ¿ Ø . The states are expressed for »bÆ Ê ÇeÊ , and are based on values for 36 the states at æçè computer. é . This means that the system is explicit can can be computed by a digital The above example mentions that the state value ë ê ì í î ï1ð is based on values of states at time ñHòóô . The same holds for the other states in the system. Whilst after each simulation cycle the state values for ñ¡òõóô will be exchanged. This notion will be important to understand the timing implications of parallel simulation. Since the vehicle dynamics model is nonlinear, we will discuss the state-replacement now for the nonlinear case. EXAMPLE 4 Substituting a state in a non-linear system. If each state ö ÷ is assumed to be described by a nonlinear function ø a nonlinear system as þÿÿ þÿÿ ö ð í î ï1ð ÿÿ ð ÿÿ ø ÿÿ ÿÿ ç ÿÿ í î ï 1 ð ÿ ö .. . þÿÿ ø þÿÿ ÷ ù öú û üú ý , then we can write ÿþ ö ð íî ÿ ü ð íî .. .. . û . ü íî ö íî ÿþ ö ð íî ÿ ü ð íî .. .. . û . ü íî ö íî .. . (5.5) ì For this case, replacing the functional model for state ö means that each model for ö ÷ , where ð ç that is dependent on the state value will be changed to reflect the new model ö ì . The superscript notation is introduced for state is computed in remote process 1. In formula þÿÿ ð íî ÿÿ ö ð ÿ ... ÿÿ ì 1ð í î ÿÿ ö ð ö ÷ í î 1ï ð çbø ÷ ÿÿ ö ì í î ÿ ö ì ï1ð í î .. . ö íî . It is used to denote that the new state ö ì ÿþ ÿ ü ð í î . û .. ü íî where for ö ì , the new model is given by öì for ç û ç (5.6) 37 ()) ,+, # $ 0 11 )) ,, . 11 )) ,, .. 11 ) , " . #$ 1 !" # $ % ' " ))) ,,, " # $ 111 & )) ,, 1 " % #$ 1 * - ... 2 / #$ Substituting Equation 5.7 into 5.6, shows that : # $ % time ;=<?> by means of " # $ . 6 77 77 +,, 4 0 11 777 #$ 7 . 3 - .. 2 777 9 4 5 #$ 7 8 (5.7) depends directly on states and inputs at The problem here is that the value for state @ is not updated until communication for exchange of data takes place. Hence, parallel simulation of a submodel will introduce time delay in the system. This notion can also be understood when considering that Equations 5.6 and 5.7 are concurrently computed for each integration step. Substituting 5.7 into 5.6 shows that A : # $ % B now depends on state values A C " # $ for the following integration steps D , before the value of state @ is updated. The concept of state equation replacement by a parallel model will thus introduce one integration time latency or phase lag. In order to understand the timing of the system, we will take a closer look at example 4. The evaluation of state A C " # $ % is based upon the state values at EFHG!I . Likewise the evaluation of the remaining system will be computed with values for the state A C " at time EFHG!I . The trade-off for using the method of parallel simulation that is presented here, is that “fast” states, or states with a large bandwidth will show degradation of dynamic performance caused by the inferior integration method, when simulated in a parallel CPU. Note that a submodel for state with a small bandwidth, which requires inputs with small bandwidth may still expose high frequency dynamic behavior internally. The system will experience minimum loss of fidelity when the bandwidth of the signals that are exchanged between the processes is low, with respect to the integration time interval. The selection of the integration step size in this respect is further discussed in Section 7.3. The phase lag increases when yet another state AKC LJ is remotely computed, on which The following example will illustrate this scenario. AC " depends. EXAMPLE 5 Simulation of a non-linear system with two dependant parallel subsystems. The possibility exists that the delay in the system will increase when two subsystems are simulated on SPINE. This happens when one of the subsystems is dependant on the other. For example, with , we would have MONP 38 YZZ ]\] R ef ZZ ]] S U V _ S fff .. ZZ ]] f ZZ ]] R T _ . U V _ fff ZZ ]] R Q S S S ff ZZ ]] T U V _ S ff ZZ ]] R T ` S U V _ S ff ff h . R!Q T S U V=W X Q T S ZZ ]] f ZZ ]] R a .. ZZ ]] Q _ S U V _ S fff ZZ ]] Rcab U V _ S ff Z ] R a ` S UV _ S f .. . [ ^ g R d UV _ S Q where for the additional replaced state model Rcab , YZZ \]] R ef ZZ ]] S U V _ b fff .. f ZZ ]] ZZ ]] R T _ . U V _ fff ZZ ]] R Q S S b ff ZZ ]] T U V _ b ff Z ] R T ` S U V _ b ff QR ab U V _ W X Q ab ZZZ ]]] ff . S ZZ ]] R a .. f ZZ ]] Q _ S U V _ b fff ZZ ]] Rcab U V _ b ff Z ] R a ` S UV _ b f .. . [ ^ g R d UV _ b k ll ll ll ll ll \]] i U V _ e ff ll S S ll l . ^ .. g ll h i j U V _ S ll ll ll m (5.8) k ll ll ll ll ll \]] i e ff ll S U V _ b ll h ^ ... g lll n i j U V _ b ll ll ll m (5.9) The time index in the above expressions is chosen so that the delay can be explained with Figure 5.3. RQ a U V _ b R S UV RQ T U V _ S RQ T U V _ S RS For example state depends on the output of state . Similarly, state requires as an input. Thus, the propagation of a dynamic behavior to a state will take as much as 3 integration step sizes, eventhough originally there might mathematically be a direct relation from input to output for this behavior. Time delay introduced in the system when a subsystem is simulated in parallel, technically, because the prediction of the dynamics of the state values in the system is lost when a state model is separated from the system model, and is simulated in parallel to the rest of the system instead. To compare the situation with teamwork, realize that efficiency is lost, when a task for one person is now being delegated to two persons who only communicate for one hour per week. 39 Simulation execution Communication checkpoint, exchange state values x1,k-3 o xn,k-3 o x1,k-2 xn,k-2 prq prq pts ~ xp,k-1 ~ x k-2 x1,k+1 xn,k xn,k+1 prq pts ~ xp,k ~ x q,k-1 k-3 o x1,k xn,k-1 prq pts ~ xp,k-2 o x1,k-1 q,k k-1 ~ xp,k+1 ~ x q,k+1 Time (T s) k+1 k Figure 5.3: Timing diagram for double dependant replaced state variable. As was explained in Chapter 2, the prediction is implicit in the vehicle dynamics system, since the continuous time model has been transformed to the discrete time model using the bilinear integration method. The remote states can be evaluated correctly, if the coefficients of the explicit state transition matrix would be available. However, this will require many of the vehicle dynamics modeling to be computed in the remote CPU. As an illustration of this argument, the following example will demonstrate the simultaneous simulation of a state in a parallel process. EXAMPLE 6 Parallel simulation of a state using SPINE. When a state model is simulated remotely through SPINE, a time delay is introduced. The cause for the delay is swiching of the integration method to forward Euler approximation. To illustrate this phenomenon, consider the integrating system from Example 1 Take the simple third order linear system from Example 1. Suppose we would like to replace the second subsystem, i.e. y uv z!{ zc| } wv In the simulation of the parallel process we will model state zc| } v wv z!{ v z~ xv zc} as 40 ! K are available, and we cannot use However, since only values at approximation method, the solution of the discretized state equation will be for the bilinear c K c ! which implies the application of forward Euler integration. The bilinear integration method could of course be solved by modeling state of and from the equation in Example 2, as ! K c as a function c c K c c! r This solution will generally require more state variables and the inputs to be available, and the explicit representation of the state equations. These two requirements are generally difficult to meet. If they cannot be met, it means that the simulation performance degrades. In the preceding example, two requirements for solving the delay problem are highlighted. They are: 1. All the state values and inputs need to be available, and 2. The explicit expressions for the state equations need to be known In the case of the vehicle dynamics model of the VVSS however, we do not have the explicit representation of the state equations since the model is non-linear. The conclusion is that the parallel simulation of the states will demand the use of the Euler integration method for the particular state. Only in some cases we could incorporate additional states and inputs to reconstruct the expression for explicit bilinear integration, but this is generally not the case. The implications for accuracy and stability of this conclusion will be discussed in Section 7.3. 5.4 Implementation through Indexing The objective for parallel simulation through SPINE, is so that states or submodels of the vehicle model can be selected and configured dynamically, without re-organizing the structure of the vehicle dynamics model itself. In other words, the system must be able to allow for any state at any given time, to be separated from the model and be computed in a parallel process through SPINE. The methodology that has been adopted to achieve this objective is called indexing, which makes use of a pointer table. The pointer table in the application of SPINE will be referred to as index library t . The method has been widely used in computer science, in the application of interrupt handling. The idea is that instead of the actual state values, a pointer is used in the state equations. The pointer directs the simulation to the location of the state value. The computer science community 41 !¡ t K ¦¤ ¡¥ K¤ ¡§ !£ ¡ .. t .!¡ .. t !. ¢c Figure 5.4: Indexed states represent state values through indirect addressing. The library index t !¡ allocates the pointer £ ¨ which is the index reference pointer for the actual state value !¡ . ¦¤ ¡¥ K¤ ¡§ The contents of the pointer can be changed to reference another state value, for example or . adopts the term indirect addressing for this method. This concept of pointer technology has been adopted from the science of computer architecture, where an interrupt pointer table is used to identify the locations of interrupt handler routines. The use of the index library is further explained in Example 9. In the application of the virtual vehicle system simulation, it means the following. As soon as we would like to replace a state with the output of a parallel simulation, we will only need to change the pointer for the particular state, to direct the execution of the simulation to the location of the £ new value. The notation is adopted to denote the pointer to the state value . The concept of the state value pointer is shown in the diagram in Figure 5.4. The following example shows the use of state pointers for a linear system. EXAMPLE 7 Parallel simulation using state pointers. Assume the linear integrating system in Example 1. The implicit state equations, using the bilinear approximation method will now be expressed in terms of the state pointers. © ¥ ª « ¬K¥¯© ® ¥ ª «°± ² ³ ® « © § ª « ¬K¥¯© ® § ª «°´ ²µr¶ © ® ¥ ª « ¬K¥!°·© ® ¥ ª « ¸ © ¹ ª « ¬K¥¯© ® ¹ ª «°º ²µ ¶ © ® § ª « ¬K¥K°·© ® § ª « ¸ ³« The input is considered to be a zero-order hold input for simplicity. By default the pointers represent the location of the state value; © ® ¥ ¶ » ¸¦¼ © ¥ ¶ » ¸ © ® § ¶ » ¸¦¼ © § ¶ » ¸ © ® ¹ ¶ » ¸¦¼ © ¹ ¶ » ¸ 42 When we would like to replace the model for state equation will be simulated in a parallel process, as ½c¾ , as in Example 6, the second state c½ ¿ ¾ À Á ÂKÃÄ¯½cÅ ¾ À ÁÆÇ È½!Å Ã É and the pointer to the second state will be changed to ½cÅ ¾ Ê Ë ÌÍ ½c¿ ¾ Ê Ë Ì Î The initialization of a remote process through SPINE takes place when a state request form is submitted to the VVSS. In the request form, the remote processor will list a set of state indexes (See Section E.7) which it will need to receive, and a set of state indexes for which it will submit values at each simulation interval. After initilization, the computation of the vehicle dynamics model will use the values of the remote process Ð Ï Ñ Ò Ó , for the states that are defined in the submitted request form as outputs of the remote simulation. When the remote simulation terminates, it will close the SPINE connection with the VVSS. The original state values will automatically be replaced in the vehicle dynamics model, and the pointer ÐÔ Ñ Ò Ó will be restored to direct to the original state value. Details on the technical implementation of the state pointer concept are explained in Sections E.2 and E.3. Parallel simulation has also an impact on the remaining vehicle dynamics system as it is simulated in the VVSS. Recall that state values are updated in each simulation before each integration step. This means that during the update of the states Ð Á ÂKÃ , each value for Ð Á is available. Only if states Õ and Ö are computed in the same process, and if Õ?× Ö , then the values for the states Ð Ø À Á ÂKÃ are available to Ð!Ù À Á ÂKÃ for evaluating bilinear approximation. Otherwize forward Euler approximation will be applied for evaluating Ð Á ÂKÃ . It is therefore important to consider the dynamic behavior of the state values that will be replaced in the vehicle model. The following example will demonstrate this case. EXAMPLE 8 Implication for integration when simulating ½c¾ in parallel. Consider the parallel simulation of a state in Example 6. The original system, using the implicit bilinear approximation for internal state integration was described by ½!Ã À Á ÂKÃÄ ½!Ã À ÁÆÚ cÈ Û Á ½c¾ À Á ÂKÃÄ ½c¾ À ÁÆÜ ÈÝ Ê ½!Ã À Á ÂKÃ!Æ½!Ã À Á Ì ½ Þ À Á ÂKÃÄ ½ Þ À ÁÆß ÈÝ Ê ½c¾ À Á ÂKÃKÆ½c¾ À Á Ì ÛÁ The input is again considered to be a zero-order hold input. By simulating the equation for in a parallel process, we cannot longer use for computing , nor for . The following table shows how the equations of the system approximation are ½c¾ ½ Þ À Á ÂKÃ ½!Ã À Á ÂKÃ ½c¾ À Á ÂKÃ ½c¾ À Á ÂKÃ 43 changed. The table is chronologically, in that is shows the exchange of state values, then the evaluation of the models in the main system (left) and the subsystem (right) for the integration . step at time àá â ã ä àá â ã àá â ã=íã å cç æ è é ê ç!ë é ê !å ì ç!ë é ê îKë á ç!ë é ê íï ãcð ê çcæ è é ê îKë á cç æ è é ê íñ ã ç!ë é ê ç ò é ê îKë á ç ò é ê íó ã çcæ è é ê (In case this document is in color, the equations for the states that are computed remotely are printed in red.) Alike in the preceding examples, the original system with bilinear approximation could be modeled, as the following set of explicit state equations ä àá â ã àá â ã=íã å cç æ è é ê ç!ë é ê ð ê å!ì ç!ë é ê îKë á ç!ë é ê íï ãcð ê cç æ è é ê îKë á cç æ è é ê íñ ã ç!ë é ê íï ñ¦ô è õ ð ê ç ò é ê îKë á ç ò é ê íó ã çcæ è é ê íOñ ó ô è õ ç!ë é ê íï ñ ó ô ÷ ö ð ê if they are available. This explicit form would not require a change of the integration method. The original system for the VVSS however, is not explicitly available in the bilinear approximation expressions. Implications for the stability of the system as a result of switching integration methods are discussed in Chapter 7. Besides the change in integration scheme there is another important consideration for using SPINE to simulate subsystems. In Chapter 6.4 the timing aspects of the total simulation and animation will be discussed. In the aim for real-time simulation there are two parameters that can be tuned for optimized performance. They are the frame-rate ø and the subsampling factor ù . The consideration here is that communication for data exchange on SPINE takes place only once per frame. Hence, the more integration cycles in a frame (hence, the higher the number ù ), the larger the integration interval for the state that is to be replaced. In order to administer replacements in the state variable pointer, a library index has been defined with the locations of the pointers to the actual values. The index library ú is a table which holds the pointers to the pointers ü û , which on their turn locate the current state value for ü . The contents of the index table ú can be found in Appendix E.7. In order to be consistent throughout the modeling, reference to state variables and parameters must always be made through the pointers ü û . The following example will be used to demonstrate the use of the pointer table. EXAMPLE 9 Replacing the model for braking (simple ABS) 44 A simplified model for ABS brake logic is presented as an example on how to use SPINE to replace a partition of the vehicle dynamics. The brake system computes a brake torque , based on the brake pedal angle . When the longitudinal vehicle speed is 10% larger than (spin times effective radius) than the brake torque will be minimized. the wheel travel The actual model for the brake torque is not of interest in this example. We will assume ýcþ ÿKþ ýcþ ÿKþ The diagram for the brake model is as follows. Brake Logic ÿKþ þ ýcþ In the index library in Tables E.3 and E.4 of Appendix E we find the indices for the following pointers as ! #" ÿK þ ýc þ ! #$ For implementation of this example it means that the first string will contain the indexes with a terminating character, 102 202 105 205 2 -160 -260 * The VVSS will respond by sending the values for the requested states. Realize that pointer that consists of three values. For example, is is a 12.34 12.34 12.34 -1.1 0.4 12.34 1.1 0.4 0.0 * From then on, the VVSS only expects the value of the states that will be sent from the remote process (the two brake torques ! ). ýcþ 0.0 0.0 *, and the VVSS will respond by sending the values for the requested states as before. The process will continue until the connection closes. The VVSS will then restore the pointers for the torque to the refer to the original torques. The process can be depicted in the following chronological order of tasks 45 root Viewpoint Vehicle Light World Figure 5.5: The simplified model of the underlying tree structure that represents the graphic virtual scenery Time %&' ( VVSS Values of Requested states %&' (-,#( 12.34 12.34 12.34 -1.1 0.4 12.34 1.1 0.4 0.0 * Values of Requested states %&' (-,#. ( 12.34 12.34 12.34 -1.1 0.4 12.34 1.1 0.4 0.0 * Values of Requested states %&' (-,#/ ( )* Submodel Request form of indexes *+ 102 202 105 205 2 -160 -260 * )* *+ )* Simulated state values 0.0 0.0 * Simulated state values *+ 0.0 0.0 * 12.34 12.34 12.34 -1.1 0.4 12.34 1.1 0.4 0.0 * .. . 5.5 Virtual Environments A powerfull feature for the VVSS is that the virtual sceneries, and therefore the simulation scenarios are uncoupled from the numerical simulation. It is possible to configure the VVSS to load different virtual scenes, so that the simulation can be used for a slalom test, an icy slope, for uneven pothole or ditch terrain driving or even for multi-vehicle traffic simulation. Furthermore, the VVSS can be configured to run any platform vehicle. This allows us to simulate a sports car, and compare performance with for example a HMMWV 0 in the same experiment. Or in another scenario, compare drivability of an armored Dodge truck with an armored HMMWV. These examples of applications are not random. Oakland University faces many opportunities to conduct research in these areas. The VVSS will be facilitated to comply with specifications of any 1 A High Mobility Multi-Wheeled Vehicle (HMMWV), generally called “hummer” is an all-terrain all-purpose military utility vehicle. The US-Army maintains approximately 500,000 of these vehicles. 46 Figure 5.6: The virtual environment can be adapted to meet the requirements of any intended study. of the required studies. In an overview of the variety of applications that VVSS can have, the next list is a collection of examples of modules that can be implemented for the VVSS. The VVSS has the default configuration as shown in Figure 5.6 with a Lotus Esprit, in a village landscape. 5.6 Modules for Subsystems As the application for VVSS, the PC’s that are connected to the VVSS can be used for detail studies on subsystems. During the studies, an engineer can simulate concept models, run test scenarios on a selected virtual test track, or actually drive a virtual vehicle, that is “equipped” with a concept system. The following is an overview of submodules that can be developed as extensions to the VVSS. Suspension The suspension module can be replaced, to account for a more accurate description of the mechanical behavior in a certain car. In particular this module can be replaced with a concept active suspension 2 system. For example in the tutorial by [17], the active suspension can be implemented and tested. With the facility for VVSS, future research activities like [7] can be evaluated in an interactive simulation environment, before heading to a test-track facility. 3 The objective for Active Suspension is to minimize the sprung mass acceleration with constraints on the suspension deflection and road holding. The desired dynamics of the system is that of a passive suspension with “skyhook damping”. 47 Steering System More accurate steering dynamics (See also Appendix A) can be simulated by developing a steering module. A steering module can be modeled for steering complience, electronic steer by wire, or to do more detail studies on noise vibration and harhness (NVH) characteristics of the steering models (for example, see [58], [52], and [53]) Tire Friction The tire friction dynamics model as it is implemented, is presented in Chapter 3.2. However, as was explained in the introduction of this proposal, that also other efforts have resulted in reasonable models for tire dynamics. A tire friction module can be implemented to study other friction models and support the effort for more accurate characterization of tire models. Free-Body A custom free-body model can be inserted in a situation where the vehicle platform cannot be represented by the presently implemented chassis model. A set of dynamic equations for a chassis, implemented as a submodel enables any vehicle platform to be simulated with the VVSS. Engine-Transmission Studies on engines or transmissions can be conducted using the VVSS. A model for an engine (for example, diesel injection engine or electric motor) or a transmission (hybrid vehicle or continuous variable transmission) can be inserted as a module that replaces the current generic model (see Appendix A). Traction Control Previous studies at Oakland University on traction control can now be conducted with the VVSS by replacing the traction module in the VVSS. (for example, Hydro-lock by Dana Corporation) Brake Systems Driving scenarios with advanced brake systems can illustratively be simulated using the VVSS, by replacing the current brake system with an ABS, or brake by wire. Advanced Controls Recent studies on driving safety have spawned many concepts for vehicle stability controls. Control systems for diagonal braking, or combined braking and suspension forces [2] can be evaluated by designing a module for the VVSS. Or control systems for multivehicle scenarios, like the leader-following project that Oakland University was involved with (See [10], [14], [11]), can be simulated in a virtual realistic environment, using the VVSS. Collision Avoidance Previous work at Oakland University for the US Army has been conducted in a contract to develop a collision avoidance and traffic monitoring system for a HMMWV (See [48]). Especially safety systems like collision warning and avoidance are investigated recently [63]. The VVSS enables these traffic safety systems to be evaluated, in a multivehicle traffic environment, using adequate sensor models. Navigation Systems The graphical interface and terrain models in the VVSS can be addressed to study control concepts for GPS and advanced navigation systems. Solutions for deadrecogning and signal filtering can be studied when a suitable model is developed for a module in the VVSS. 48 5.7 Conclusion The SPINE simulation network configuration has been introduced in this chapter. The application of pointer addressing of state values, for the purpose of a flexible reconfiguration of the dynamic model is new and allows for the setup of the general multi-CPU parallel simulation structure. This chapter discussed the impact on the simulation performance and in particular on the integration method in detail. The problem is that the separation of the model into different computer environments forces the integration of states to utilize the forward Euler approximation method. The effects on accuracy and stability that are implied from the change to forward Euler approximation are explained in Chapter 7. Chapter 6 Timing and Synchronization The issues of real time with respect to integration step size and communication delays are addressed in this chapter. Integration step size requirements are inferred from the frame rate and the execution performance of the computer hardware. A Luenberger observer is introduced that will predict simulation output from a parallel subsystem on SPINE, when it does not respond in time. 6.1 Introduction At this point we have developed a full vehicle dynamics model and a methodology for simulating partitions of the model on different processing units via SPINE. As was illustrated in Figure 2.1, the objective of virtual vehicle system simulation is to simulate the closed loop model which includes the human driver in the loop. The interface between the vehicle dynamics model and the human driver has not yet been discussed. Therefore, this significant aspect of the system will be addressed in the first section. Then the requirements and trade-offs for the system for executing in real-time will be addressed. If one of the processing units in SPINE is not able to compute its simulation output and return it to the VVSS host in real-time, the system could become unstable or generate unreliable output. This problem will be addressed in Section 6.4, and a suitable solution to resolve it is presented in Section 6.5. 6.2 Human-in-the-loop Model Since world war II, studies have been conducted to model human behavior as an active feedback control device. Several frequency domain methods have been published [45]. When time-domain control synthesis techniques became popular, an optimal control model (OCM) for the human operator was introduced [33]. The diagram of this model is shown in Figure 6.1. 49 50 disturbances Human Operator + 8ν 5Delay y Observation noise 6Estimator Corrector 7 Feedback Gains + 8ν Neuromotor Dynamics u δ 4 Virtual Vehicle System Simulator 9y Observation noise observed variables Figure 6.1: The Optimal Control Model (OCM) for the human operator. Different models for the human operator have been designed, depending on the particular application [25]. Through experimentation and identification [26] an average time constant of 0.15 seconds has been found for the neuromotor dynamics first order characteristics. This result allows us to conclude that an average data input rate of at least 15 Hz (less than is used for the visual output), will be sufficient to aquire human output data. Obviously, this assumption is based on the average human response time and general applications for driving simulation. When for example, performance vehicles like the Formula-1 race cars, with proffesional drivers are to be simulated, this OCM may have to be modified to reflect the appropriate responsive model. At this time we will assume the OCM to be sufficient : , leaving the reader with the remark that numerous research efforts are being conducted to characterize human responses in various scenarios. 6.3 Real time versus Simulation time The term “real time” was defined in the context of simulation in the introduction on page 3. In this section we will study the constraints for the integration process of the vehicle dynamics in order to meet the objective for real-time as stated. The vehicle dynamics model is simulated in a Silicon Graphics ONYX-II computer with 4 processors and reality engine graphics boards. The timing event for the visual output is generated by the hardware of the computer. This timing facility will be used as a reference to real-time. The hardware can be configured to generate a particular frame rate (i.e. 72, 36 or 24 Hz), and how to operate this frame rate ; . Figure 6.2 shows the profile of CPU utilization during a real simulation. The activity of CPU 4 is plotted at the line app. The graphics culling, database management and computing viewpoints is executed on CPU 2 (repectively called cull, dbase and compute). the actual drawing of the scenery is done by CPU 1 (task draw). In Figure 6.2, each color represents an individual simulation < The human response model will have to be revised when the motion platform is installed, and when force and audio = feedback are added to the human driver environment For the operation we can select from FREE RUN, PHASE LOCK, or PHASE LIMIT. The latter setting is used for the VVSS. 51 interval. For example, the interval with the white color will start by calling the application in CPU 4. It will pass its state information to the culling and database process in CPU 2 and 3. On their turn, they will pass their outputs to CPU 1, for the drawing task. However, as soon as data is passed from CPU 4 to the culling and database processes, another simulation interval will be computed in CPU 4, indicated in yellow. It will be the objective to fully exploit CPU 4. During each frame, a minimum number of tasks needs to be completed by the processor that computes the vehicle dynamics. Chronologically they are: 1. Compute the next state of the vehicle dynamics. 2. Update states from the vehicle dynamics which are animated in the animation to the graphic scenery rendering processes in CPUs 1, 2 and 3. 3. If there is data ready from SPINE in the network connection buffer, then (a) receive the data from the buffer. Interpret the input and insert the new values for the states into the vehicle dynamics model, (b) compile a set of current or future state values for the remote processes and pass them to the transmit buffer for SPINE. 4. Process keyboard and mouse inputs, and optionally receive peripherals for vehicle dynamics inputs. 5. Wait for the next frame rate synchronization > . Figure 6.4 shows a conceptual timing chart for the simulation. Vertically it displays the time in video frames. Typically CPU 1...3 will be dedicated to processing graphics. CPU 4 will be assigned to computing the vehicle dynamics and communication with the SPINE. As was eluded to before in Section 4.1, the selection of sampling time is critical with respect to convergence and real-time. In order to get more freedom for the selection of integration step size, we will apply subsampling for the evaluation of the vehicle dynamics. Subsampling means that for task 1 in the above task list, the output for the vehicle dynamics model will be integrated ? times, using a sub-sampling integration step size @BA . The result is a frame rate integration interval of @[email protected] F (6.1) The actual duration of one frame, hence one total simulation interval, depends on the selected video frame rate, GH C J I J =14, 24, 36, ... 96 Hz K Task 5 only applies for the selected timing operation property. (6.2) 52 Figure 6.2: Snapshot of the VVSS simulation output with online statistics. Each color represents the execution of an individual frame. Each row represents a processing unit. 53 Real Time Integration Step Size for Various Frame Rates 0.02 Frame rate (Hz) 0.018 14 18 24 36 48 60 72 Capacity Integration step size (s) 0.016 0.014 0.012 0.01 0.008 0.006 0.004 0.002 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Subsampling (n) Figure 6.3: Minimum integration interval selection for real-time simulation. It is now important to guarantee that execution of the task list (Tasks 1...4) will not exceed LM seconds. Denoting the time that it takes for the computer to execute Tasks 2...4 by N O , and the time that it takes to compute one iteration step of the vehicle dynamics model by N P , this requirement can be expressed by Q N ORSTN P-ULM (6.3) At the same time, we must guarantee that the simulation of the vehicle dynamcis will evaluate a total amount of LM seconds per frame, in order to be real-time. In other words, V PW L S M (6.4) From the above discussion, the maximum constraint for real-time simulation can be expressed for V P in terms of the time that it takes to execute the task list, V PX N OYRZS STN P This constraint is graphically represented in Figure 6.3, for several values of [ , where for N (6.5) OWE\ ] \ \ ^ _ The requirement in Equation 6.3 applies to the sequencial processing of the simulation of the vehicle dynamics. 54 Silicon Graphics ONYX CPU 1...3 CPU 4 TCP Buffer SPINE Buffer t=kh Video Frame 1/36 sec. 1 Vehicle Dynamics Read Peripherals (optional) `n Vehicle Dynamics Read new data Send current data Process Mouse and Keyb 1 Vehicle Dynamics State Update Information Video Frame 1/36 sec. Video Frame 1/36 sec. d Current State Information (data request) d (data reply) Read Peripherals (optional) Send to VVSS Wait for data Receive new data Computing states and outputs of the submodel (i.e. in "Simulink") a b n Vehicle Dynamics Update Graphic States if new data in Buffer: Read new data Send current data Process Mouse and Keyb 1 Vehicle Dynamics t=(k+2)h t=(k+3)h (i.e. in "Simulink") Graphic States bifUpdate new data in Buffer: t=(k+1)h PC-Pentium / DSP Receive new data Computing states and outputs of the submodel d Current State Information (data request) State Update Information (data reply) Read Peripherals (optional) c `n Vehicle Dynamics Update Graphic States if new data in Buffer: Read new data Send current data Process Mouse and Keyb 1 Vehicle Dynamics Send to VVSS Wait for data Receive new data Computing states and outputs of the submodel (i.e. in "Simulink") Current State Information (data request) Send to VVSS Wait for data State Update Information (data reply) Receive new data Computing states and outputs (i.e. in "Simulink") Figure 6.4: SPINE communications timing diagram. The vertical axis represents time. The left column represents the VVSS, the right column a parallel simulation process in Simulink. The arrows between the VVSS and the Simulink denote data exhchange of state values. sec, e fhgEi j i i k l sec, which are realistic estimates. For example, the VVSS is currently configured for mBfgni j i i o sec, and p#gnq at 36 Hz. If it was desirable to decrease the integration step size, we would need to lower the frame rate to 24 Hz, and use for example mBfgEi j i i r s sec at pTgnt k . The same idea applies to the modules. The sub-systems could be evaluated in a smaller integration step-size. The module will be integrated for the respective number of times, before actually communicationg with the VVSS. The advantage is that more accuracy or stability at greater stiffnesses can be achieved. That is, if the processor can perform the higher integration frequency in real-time. 55 6.4 Communication and Synchronization with SPINE Section 5.4 explained how remote simulation through SPINE is organized. The preceding section argued, that the VVSS must keep in pace with the frame rate timing event, in order to maintain real-time simulation results. A problem arizes when an update for the state values from a remote simulation process does not arrive in time. The timing diagram in Figure 6.5 illustrates this particular scenario. Consider the system outputs at time uvxw . The computation of the system outputs in y requires the previous system states z{ | } ~B{B z | } ~B{ and the outputs of the remotely simulated states z | } ~B{ to be available. However, the remote processor was not able to provide the states in time for the communication checkpoint. In this case, the VVSS will effectively use the latest values for z for for simulation, eventhough they are outdated. This method acts like a zero-order hold “prediction” on the state values. A stability problem occurs when this integration interval becomes too large for the solution of the simulation to converge. A secondary effect is that the accumulated time in the remote simulation will no longer synchronize with the accumulated simulation time in the VVSS. The implementation aspect of SPINE concerns with the network linkage between the processing units. A 100 base-T local network interconnects the units by means of a HUB. The simulation has shown to suffer under heavy network traffic, although this problem can easliy be eliminated, by disconnecting the local network from the internet backbone. Furthermore, the simulation applications on SPINE will communicate through a network adaptor, which will allow them to use buffered communication. The adaptors will then independantly perform the handshaking and protocol tasks to exchange data. Latency and transmission times are marginally if not degrading the performance of the simulation, and are therefore not further discussed in this dissertation. 6.5 Prediction and Correction with Luenberger Observer A more sophisticated method to solve the problem from the preceding section, is to try to use predicted outputs of the remote simulation, when the values for the states do not arrive in time. Several schemes are available to implement this method. The mechanism is generally referred to as an observer [20]. An observer will estimate the state of the process, based upon the observed output. The concept of an observer was introduced in 1966 by Luenberger [42]. The generic “Luenberger observer”, however, appeared several years after the Kalman filter, which is in fact an important special case of the Luenberger observer - an observer optimized for the noise present in the observations and in the input to the process [4]. Kalman filtering technique was successfully used for tracking application at Oakland University before in [48]. 56 Simulation execution Communication checkpoint, exchange state values x1,k-3 o xn,k-3 o x1,k-1 xn,k-2 prq k-3 x1,k-2 o xn,k-1 ~ xp,k-2 prq k-2 k-1 o x1,k x1,k+1 xn,k xn,k+1 prq ~ xp,k-1 ~ xp,k Time (T s) k+1 k Figure 6.5: Timing diagram in the scenario of synchronization failure. The design of observers and extended Kalman filters for non-linear systems has been addressed by several authors, such as Thau [62] and Kou et. al. [36]. At the same time, it has been proven that one can simplify the estimation of complex non-linear system states via the use of the so-called , , or T tracker formulation [39]. New techniques for neural networks could possibly be used for this application [61]. Generally the Kalman filter assumes the structure of the observed system to be known in advance. With the input measurement , the real-time estimation B of the state B , and the predicted result by the observer is B E hZ D (6.6) (6.7) where the term is the correction term, based on the error between the current output observations and the predicted output; The formalization of the optimization problem for choosing will result in the cost functional E (6.8) D that will minimize the error x ¡ £¢ E¤ ¥ ¦§ ¨ª© ¤ ¥ ¦B« , (6.9) The last term in the above expression has a physical meaning. It represents the sum of the variances D¬ for each state. The solution for the functional in Equation 6.9 results in a discrete-time 57 algebraic Ricatti equation ® , ² ¯° ±B²³E´-¯° ´hµD¶·¸°¹º´-¯° »µT¼ »ª¯° »µD¶½° ¾ ¿ ª » ¯° ´hµYÀ ¯° ±B² ½° (6.10) The solution represents the covariance matrix of the estimation error, the measurement, ·¸° is the excitation noise. The new correction gain isisthen or observation noise and given by ² ÁD° ±B²³E´-¯° ±B² »µ¼ »ª¯° ±B² »µD¶Z½° ¾ ¿ À ´ (6.11) From Equation 6.6 it can be seen that the transmission matrix must be known in advance and that the estimates will converge to reflect the measurements in the predicted output. These properties Á are in fact characteristic to the filter. The bottleneck is that for finding , we need to have statistical data on the state measurements and the noise. However, these statistical data are usually not available. It is insightfull to step away from the prediction correction technique and realize the timing problem of the VVSS that we face. That is: when an output value of the remote process arrives in time, it will be assumed to be error-less (i.e. no measurement noise), and the value will be used to estimate the prediction model parameters and predicted state values. If the output value does not arrive in time, the current state of the model will be solved to derive prediction of the value. In second consideration we must realize that the measured values will typically not reflect the output of a linear time-invariant system. This means that simply solving a least squares problem will not necessarily guarantee an accurate estimate. It is therefore important to select a system that contains sufficient dynamic behavior to track the observed signal and which has enough system parameters to correct the behavior to make it track appropriately Â . A general second order linear system will thus be used for predicting the observed signals, since it will naturally predict the dynamic behavior of an unforced mechanical system. From the above discussion, the following two tasks can be defined. Take for example the linear system Ã Ã Ã °Ä ±B²³E´ È °³» then for each time step Ê ³EË Ì Ã Ä h° ¶ZÅÇ Æ ° Ä°É (6.12) (6.13) , Í Jacopo Francesco Ricatti (1676-1754), Italian mathematician, who first introduced his equation in 1723. A general ÏYÐÑ£Ò Ó Ô ÏhÕTÖ Ò Ó Ô Ï ×ÐªØ£Ò Ó Ô . form Ù of the Ricatti equation is Î If the internal model structure would not be known, but we have observations of the internal states and inputs, then the system matrices could be directly found at equilibrium from the Jacobeans Ú ÕÛBÝ Ü Ò Ó£Ü Þ ß Ü Ô à ÕÛ Û Óá Ü â Ü Ò Ó£Þ ß Ô Ü Ü ÛBß Ü 58 ï ñ . If no observation of the output signal is 1. Predict the new system output ä ã å æBçèéê ë ì ã å íDîð available, this prediction will be used in the next integration step of the vehicle dynamics. If initially the system has not yet been defined (before the first correction) and the observation would not be available, then the zero-order hold function will be applied ( ä ã å æBçè ä ã å ). 2. If a series of ò observations of the output is available, then reflect the recent history of observations in the prediction model. In other words, solve for the state vector from the error in prediction and observation of the output ä å£óä å æBç ó-ô ô ô óä å æ£õ öBç . The prediction model will have to have a structure that will allow the state vector to be solved. This required property is in this situation usually referred to as observability . The following two examples are used to illustrate the above concept for predicting and correcting. The first example will show the application of an observable system. The second example shows how a general linear second order system is used as a predictor-corrector. EXAMPLE 10 Second order observable prediction model. Suppose we assume the following second order linear system for tracking the output signal of ÷ ÷ the remote process on SPINE. ç þ ÷ ø å ç åø æB÷ Yç ùûúªühý ÿ ú å ühý ù þ ø å å- (6.14a) (6.14b) which has, what is called the observable canonical form. Realize that a system with this type ç ý õ and ç õ that define its state of canonical form always has variables ý space model. With recent observations also the excitations as å å æ£õ öBç , define the expressions for the observations ù å å æBç .. . ù å å æBç .. . , and å æ£õ Bö ç å æ£õ ö We can show that ù "! ø å$# ! # % and the observability matrix "% are given by where the Markov matrix - .. ) - .. . .. ! , )+* )+* . # %hù&'' " % ù0&'' .. .. .. .. ''( ''( . / / .õ ö , .! , . )+* )+* õ öBç )+* (6.15) (6.16) (6.17) 59 :9 23 - ;>= 7 1 2 1 ;< 7 56 + 8 7 4 Figure 6.6: Example of a second order linear system for predicting state values. Notice that ?"@ has full rank by definition of observability, and will be square for A observations 8 9 . From the relationship in Equation 6.16 we solve for ; B as = ;+ B C ? EG D F 8I9 HKJ E : 9 LNM 7 (6.18) ; B O P =QCSR P D = ; BTVU W"RWM M MXR P D < W>Y :N9 M 7 D 7 (6.19) Using the system dynamics Equation 6.14, we can show that EXAMPLE 11 A general second order linear observer predictor system. Assume the strictly proper general second order linear system in Figure 6.6, for tracking the simulation output data from SPINE. Which is given by the state space system representation 3 H 4 ;+Ta[ 1 : 9 ; Z C\[ H ^ (6.20) 1 ]`_ ]b_ 7 7 8cCd (6.21) 6 e ; " 7 This system can be discretized and approximated for numerical simulation using the bilinear 5 transformation. This transformation results in a set of equations as in 6.12 and 6.13 where with integration step size f we find 3 3 T 4 < Hlk f < Hj f RC0ghi j 3 f T k 4 f Tbk 4 f f < Tbk T f j 3 3 H j3 f f H T j T j f mn k4f < 4 T k 4 f f < T k o 4 f < Tk (6.22) 60 |} pq0rst v w x+yv zu x x{Xy ~ v w x+yz x{Xy u u qc" (6.23) (6.24) For this discrete time system to allow itself to be corrected with the observed data, we will have to be able to reconstruct its states from the system output data. Furthermore, we need a minimum set of variables in the system matrices, to be able to find an explicit and nonambiguous expression for the model correction. As a result, the above discrete time system needs to be transformed to the observable canonical form. The canonical observable form has a particular property. The eigenvalues of the original q ) will be the elements in the first column of system (that is, the solutions of det I+ the transformed transition matrix . The necessary requirement for this transformation to succeed is that the observability matrix (Eq. 6.17) be non-singular. The transformation will then convert the system to be expressed q$ . The following system is achieved in a new coordinate system with N q y p q (6.25) (6.26) with \ q { b p \ q { q (6.27) (6.28) (6.29) The transformed system has the observability matrix " q qI Since with the coordinate transformation, " q " and hence, Kq " . (6.30) and q , we can find that The transformed system can now be corrected as in the previous example. After the correction procedure, we can find the correction for the original system, using the reverse transformation 61 ¡S¢£¡ ¤I¥N¦ § ¢$¤ § £ ¤ ¥N¦ (6.31) (6.32) The process is somewhat elaborate but will allow any linear strictly proper model to be used for tracking. Next is the third and final example of implementing a linear tracking system, now in a least-squares formulation. From Example 10 we conclude that the practical objective of the observer-predictor scheme is to adjust the system parameters and internal states, based on the recent values for ©>¨ ª and « ¨ ª , such that the linear system will predict the next state output « ¨ ª ¬ ¦ as accurately as possible. In the next example, the tracking system in Equations 6.14a and 6.14b is reformulated to realize a least-squares observer-predictor. EXAMPLE 12 A second order observer-predictor system with joint state parameter estimation. With the objective in mind that the state parameters will be adapted to track and represent the observed dynamics in ® and ¯ , the change of the system can be formulated as ° ¦ ±ª ¬ ¦ ° ´ ±ª ¬ ¦ µ ¦ ±ª ¬ ¦ µ ´ ±ª ¬ ¦ ¢ ° ¦ ± ª ²K³ ¦ ± ª ¢ ° ´ ± ª²K³ ´ ± ª ¢Sµ ¦ ± ª²K³¶ ± ª ¢Sµ ´ ± ª²K³· ± ª (6.33a) (6.33b) (6.33c) (6.33d) ³º ª » ¢ ± 0. Also, by where, with ideal tracking the expected noise or shaping inputs ¸¹ ¯ ª ¬ ½ ¦ substituting 6.14b into 6.14a, the following expression for ¼ can be formulated ¾ ½ ª ¦± ½´ ± ª ¬ ¦ ¬ ¦À¿ ¢ ¾ÁÃÂ ÁÁ ¾ ½ ª ¾ ¾ Ä ¦ ± ² µ ¦ ® ª² Ä ° ¦ ¯ ªÅ µ´ ¿ °´ ¿ ¿ ½´ ± ª ¿ (6.34) The set of states and parameters at a given point in time can be concatenated in a vector and expressed with the above equations. As a result, the following least-square problem is found ÆÇÇ ½ ª ¬ ÇÇ ½´¦ ± ª ¬ ÇÇ ± ÇÇÈ ° ¦ ± ª ¬ ° ´ ±ª ¬ µ ¦ ±ª ¬ µ ´ ±ª ¬ É Ê ÆÇ ¦ ÊÊ ÇÇ ¦ ÊÊ ÇÇ ¦ ÊÊÊ ¢ ÇÇÈÇ ¦ ¦ ¦ Ë ÁÃÂ ÁÁ ÁÁ ÁÁ ÁÁ ÁÁ Ä ¯ª Á ÁÌÄ ¯ª ÂÍÁ ÁÏÂ ÁÐÁ ÁÐÁ ® ª Á Á ®ª ÁÎ Á ÁÎÁ ÂÑÁ ÁÒÂ É ÊÊ ÇÆÇ ½ ª ÊÊ ÇÇ ½´¦ ± ª ÊÊ ÇÇ ± ÊÊ ÇÇÈ ° ¦ ± ª ° ´ ±ª Ë µ ¦ ±ª µ ´ ±ª É ÊÊ ÊÊ ÊÊ Á ÇÇ ÇÇ ÆÇÇ É ÊÊ ÊÊ Á ÊÊ ² ÇÈÇ ³ ¦ ± ª ³ ´ ±ª ³¶ ± ª Ë ³· ± ª ÊÊ Ë ÊÊ Å (6.35) 62 In vector-matrix expression, and with zero-mean inputs ÓÔ expressed as xÖ ¯ ×NØÙ$Ú x¯Ö Û Ý Ü Ö Ù$Þ xÖ ¯ ÕÖ , the system in Equation 6.35 is (6.36) with ÞSÙß àáIáIáIá+á âã (6.37) The inversion is only possible when the observability matrix has full rank, i.e. when the system is observable. This will be the case only, when the observations for å ä and Ý ä contain exciting data. Then the values for æ Ø and æ ç will appear in the above expression and can thus be solved. If the system is observable, we find the solution for the state values and system parameters by solving the expression èé èé éé ê éé ì íí é ÝÖ Ý Ö ×NØ íí .. . î Ý Ö ×>ë é Ù ê Þ Þ Ú + .. . Þ+Ú ë ì íí î íí Ü xÖ ¯ (6.38) to the solution for xÖ in the inverse observability matrix and recent observations, ¯ Ü xÖ ¯ Ù ï ñ ð Ø yä ã (6.39) ¯ 6.6 Conclusion In this chapter we have formulated the requirement for the integration step size for the vehicle dynamics simulation to perform in real-time. The concept of subsampling has been introduced to allow some freedom in the selection of the simulation integration step size, so that also the stiff subsystems will render stable solutions. Also the interaction of the simulation of the vehicle dynamics model and the simulation of a submodel has been discussed. Stability and accuracy problems may arise for simulating the vehicle synamics model when a remote simulation process on SPINE cannot provide simulation results in the required frame rate. Several obserber-predictor schemes have been presented to extrapolate simulation output values in this situation. The effects on stability of the simulation of the vehicle model and accuracy of the observer and predictor outputs will be further discussed in Chapter 7. Chapter 7 Stability Several aspects of stability that play a role in the simulation model are studied in this chapter. Stability is considered in three ways: stability of the open-loop dynamic vehicle model, stability of the integration method and stability of the human-in-the-loop vehicle model. Stability criteria are posed, however a closed form expression cannot be derived. Also the stability and accuracy aspects of parallel simulation through SPINE are addressed in this chapter. 7.1 Introduction The study in this chapter relates to the origin of the stability problem itself, which is to test for convergence of the system solution for frequency and magnitude bounded input signals. The discussion is broken up in three sections, regarding system related, simulation technique related, and vehicle dynamics (and control) related aspects of stability. 7.2 Model Stability There are many methods for testing system stability. Most of the profound methods however, apply to linear time invariant systems. The non-linear methods tend to be very conservative, as do the linearized models. Since the dynamic model of the VVSS contains many non-linear relations, many of the standard classical methods for testing stability cannot be applied. Many methods for non-linear systems (like Hyperstability by Popov [37] and Karithonov [46]) only apply for systems that do not have internal state products. Lyaponov stability theory can be used to analyze non-linear systems. However, application of these very general methods is often limited by finding suitable Lyaponov functions. Special cases of Lyaponov functions exist for non-linear processes, but the results are typically not usable, since the functions only satisfy the sufficient conditions and not the necessary 63 64 conditions. Necessary and sufficient tests do exist for systems with arbitrary non-linear, arbitrary fast linear time varying, or arbitrary slow linear time varying system parameters. Tests for these systems can be calculated in polynomial time [6]. In this section, we will study the stability of the different subsystems in the vehicle dynamics model. The closed-loop stability problem for driving will be discussed in Section 7.4. In the next paragraphs, each subsystem that contains a feedback loop will be tested for stability. Quarter Car Suspension It was explained in Appendix A that the suspension and tire deflection model depends on the suspension anchor locations ò+ó . Since the anchor locations depend on their turn on the suspension model, there is notice of an internal time-varying feedback loop. The loop can also be observed from Figure A.9. To study the stability of the double springdamper system in the quarter car suspension configuration, consider the model in Figure A.8 with spoke angle ôaõ÷ö for corner ø . If we take for the vehicle anchor elevation above the terrain ùQúlõüû ò+ó ý þcÿû +ó ý þ , and for the elevation above the terrain of the center of the wheel ùõ û +ó ý þIÿ0û +ó ý þ , then the two simultaneous dynamic equations are given by ÿù bÿ ÿ$úùQ ú+ÿ ù bÿ ù õ$ú ùQ ú+ÿ (7.1) ù bÿ Qù ú õ (7.2) or, in matrix form, !"# ÿ$ú ÿ ÿ ÿ ÿ ÿ ÿ $% ùQú õ &' ù ) ( $ú ' *( (7.3) The individual transfer functions for the forces on the masses $ú and to the mass heights ù and ùQú have the determinant of the above left matrix in the denominator. Hence, the roots of this determinant are the poles of the suspension system. ÿ$ú ÿ ÿ ÿ ÿ ÿ ÿ + ÿ -, õ ö (7.4) The parameter sensitivity for the solution to the characteristic equation, relative to parameter changes for damping and stiffness is simulated in Figure 7.1. 65 Suspension stiffness sensitivity Suspension damping sensitivity 10 14000 21000 28000 35000 42000 49000 56000 63000 70000 10 5 0 −5 4000 6000 8000 10000 12000 14000 16000 18000 20000 5 0 −5 −10 0 −10 Tire stiffness sensitivity 0 Tire damping sensitivity 10 80000 120000 160000 200000 240000 280000 320000 360000 400000 10 5 0 −5 20000 30000 40000 50000 60000 70000 80000 90000 100000 5 0 −5 −10 0 −10 0 Figure 7.1: The root locations for a quarter car suspension model for various values of the stiffness and damping parameters. Each graph shows the trend of the pole locations as one of the parameters in the . / 0 order corner model changes. The title of each graph contains the name of the parameter for which the value is changed. 66 It can be seen that the system has four poles in the left-half plane, which renders a stable system. However, if the value for on of the damping coefficients is decreased, the system becomes less stable. That is, the two complex poles will move towards the imaginary axis. From an engineering standpoint, it is understood that the system stability degrades for smaller values of the damping 1 . Wheel Spin Dynamics A second non-linear feedback can be found in the wheel spin dynamics. The rotation of the wheel causes it so slip on the terrain. The slip will result in a longitudinal and lateral force on the tire, which will in return make the tire spin. As shown in Chapter 3, the dynamics are based on wheel spin velocity. The Dugoff tire model cannot compute meaningfull solutions for the slip force when velocities are small. The model has been modified to incorporate additional stick friction. This contribution was discussed in Chapter 3. The tire slip force acts as a damping torque on the wheel spin. Hence, the force feedback from the tire slip model will always provide a torque to the wheel which is opposite from the wheel spin. Euler Angle Transformation method Another internal loop can be found in the chassis rotational dynamics. Figure A.12 shows two feedback loops. The first loop will configure the rotation matrix 2 345 . The rotation matrix is non-linear, but will never exceed the value of 1 for its gain. The second loop denotes the centrifugal and coriolis forces. The feedback loop causes the system to have poles that are the roots of the following expression 6 7 898;: 8 <>1 = < [email protected];B (7.5) With Equation A.24, the above expression can be worked out as CDE 7 A AGA AF 7 A A7IKH J 9 : DEC DEC 8 L 9SRPTRN 1 A8 M A N RAP 9SRL 8 AM N A A A8 PQKH J A A KH J 9S R NTRL 8 A PQKH J @A AOA A A A O CDE 8 L CDE or, 7VU W RPY9 U Z RN UX7 9 U X RP[ U ZU X RP U W RNO9\U W RL] U W7 KH J @)A;B UX UZ UZ (7.6) (7.7) The determinant, or characteristic equation of this matrix is computed as 7 R-L^ _ 7 R-N^ _ 7 R-P^ _ 7` b @A;a (7.8) After discretization, each particular integration approximation method also implies a maximum value for damping. This is related to the different methods of pole location transformation, as discussed in Chapter 4. 67 c dfeg;hFc which has the following three solutions: iSej k lk hmc neoj k lk p (7.9) The poles describe a pure harmonic with the frequency of the magnitude of the signal. This behavior is just what is known as the coriolis forces; the angular inertia torque. From Equation A.24 we can see that the diagonal of the feedback matrix is zero, which means that the feedback torque is cross-relational. A true concern in the system in Figure A.12 is the Euler transformation. Matrix qr translates instantaneous angles into independant Euler angles. The matrix is given in Equation C.11. in this matrix we find that stu e vQ w yx z { | }~ (7.10) d i which means that gains in the matrix will approach infinity when the roll-angle approaches to . Mathematically, the solution to the rotation g problem becomes non-trivial for square angles. This is a well-known problem for Euler angle transformations. Hence, the simulation will “crash” when the vehicle encounters a roll-angle of o. The problem does not involve the yaw-angle. Therefore in ‘normal’ driving conditions, the transformation will conduct its task. No more internal feedback loops can be found in the vehicle dynamics model. Closed loops that incorporate the human driver are discussed toward the end of this chapter. 7.3 Simulation Specific Stability In this section we will take a closer look at stability and performance issues that are simulation related. The first paragraphs are dedicated to the study of simulation stability of systems, that are internally transformed using different approximation schemes. Figure 7.2 shows the mapping of poles for different approximation methods. As was discussed in Chapter 2, the model for the VVSS can be considered as a chain connection of three partitions. The study on stability will therefore focus on a three-partition dynamic system. The following paragraphs will discuss issues that are related to the accuracy and timing of SPINE. Stability of integration scheme The stability and accuracy aspects of the numerical approximation scheme are of great importance to the performance of the VVSS. The discussion in Chapter 5 addressed many of the decision making considerations in this respect. 68 Pole locations in Laplace domain FDA Imaginary Im(s) 15 10 BDA 1 1 0 0 5 −1 0 −5 −10 −15 −30 −1 Bilinear TA −20 −10 0 Zero Order Hold 1 1 0 0 −1 Real Re(s) −1 −1 0 1 −1 0 1 Figure 7.2: Pole location transformation for various integration schemes. With the pre-assumption that the continuous time system will be stable, we will look at two general configurations for approximating a linear system. The configurations are not arbitrary, but they reflect the switching of integration methods that occurs when a submodel is being simulated through SPINE. The phenomenon was discussed in Chapter 5. Q \ Bilinear Euler Bilinear Figure 7.3: Example of a second order linear feedback system with three general partitions. The general linear system is given in Figure 7.3. It has the structure which coincides with the structure of the VVSS, in that it is subdivided in three partitions. By selecting one of the transformation methods from Equation 4.1, a discretized approximate expression can be derived for each of the subsystems. The total transfer function of the system is given by Q \ S\ f I ; I; I (7.11) As a result, it can be found that if the subsystem is discretized using Euler approximation and is stable, then, the total system will be stable . The problem becomes less obvious, when a feedback loop is introduced. Figure 7.4 shows the configuration. Note that the bilinear approximation method is inherent stable. 69 - Q ¡ ¢ £ ¡ ¢ \¤ ¡ ¢ Bilinear Euler Bilinear Figure 7.4: Example of a second order linear system with three general partitions. With the feedback loop, the transfer system is now given by \¥ ¦ § ¢f¨ § ¢ ©Sª § ¢ ¢ « § ¢ (7.12) § ¢ Using the transfer function polynomials ¬ , the poles of the feedback system can be § ¢ª § and ¢-¨> ® found as the roots of the problem ¬ . It is hard to express the effect of individual \¯ § ¢ § ¢ poles and zeros in the subsystems . When representing the system in state space form, i.e. °;± °;± ± ± ± the transfer of ² f¨³ ¶ ¨)· °;± ª´µ ª¸Qµ ± » ¹ º , is given by ± º ¶ ¨ § ¢¨)· § ¼½³¢ « Q ´ ª¸I¾ µ Using this formulation, the closed loop system \¥ ¦ § ¢ (7.13) (7.14) (7.15) in Equation 7.12 can be expressed as \¥ ¦ § ¢f¨¿ ·) § ¼½³¢ « Q ´ ª¸À¿ ¼ª·) § ¼½³¢ « Q ´ ª¸À « (7.16) As a result we can observe that a new set of poles is introduced by the second factor, which is § an inverse matrix. This inverse does not exist for any which is a solution of the characteristic equation of this matrix. In other words, the new poles are found from solving Á;Â ÃÄ ¼ª·) § ¼½³¢ « Q ´ ª¸Å¨®;¾ (7.17) The solution to this expression can be found numerically and will be a function of Æ , so that the system can be stabalized by changing tuning the integration step size. However, for the larger § § ¢ § ¢ systems it will be virtually impossible to find an expression for in the roots of ¬ and . As an illustration, in the next example we will analyzed the stability of a simple second order system subject to two different integration schemes. 70 Ï ÊË Ì Ç ÈÉ Ê Ë Ì ÈÍ Ê Ë Ì Ð ÊË Ì - Î É ÎÍ Figure 7.5: A general second order feedback system with forward and backward integration methods. EXAMPLE 13 Second order integrating feedback system with Forward and Backward Euler. Assume the seond order system that is given in Figure 7.5. With forward Euler and backward ÈÉ Ê Ë Ì and ÈÍ Ê Ë Ì respectively, as Euler approximation for the systems ÈÍ Ê Ë ÌÑ Ë Ë Õ Ò ;Ô Ö ÈÉ Ê Ë Ì Ó Ñ Ô ÕÒ Ë (7.18) the system is characterized by the transfer function ËÒ ÍÇ Ð ÊË Ì Ñ Í × × × Ê ÕSØ Î É Ò Î Í Ò Í Ì Ë × Ê ÔÕ Î É Ò Ì Ù Ï ÊË Ì Ë (7.19) The Jury stability criterion tells us that the roots of a second order polynomial Ú É will be inside the unit circle if words, × Ú É Ë ×IÚ Í ËÍ I Ú Í and (7.20) are inside the gray area in Figure 7.6a. In other ÔSÛ Ú Í Û Õ Ú É ÕÔ ÔSÛ Ú Í Û Ú É Õ Ô Ú ÉÜÝ Ö Ú ÉÞÝ when when (7.21) Ù (7.22) Applying these conditions to the system transfer function in Equation 7.19, we find that Ô-Û Ê ÔfÕ Î É Ì Û Õ Ê ÕSØ × Î É × Î Í Ò Ò Ò × × ÔSÛ Ê ÔÕ Î É Ì Û Ê ÕSØ Î É Ò Ò ÎÍÒ Í Ì ÕÔ Í Ì ÕÔ Ê ÕSØ × Î É Ò × Î Í Ò Ê ÕSØ × Î É Ò × Î Í Ò when when Í ÌÜÝ Ö Í ÌÞÝ Ù (7.23) (7.24) By solving the above constraints, a stability criterion can be found for the feedback system in É Í Figure 7.5, as an expression of the coefficients Î and Î , Î ÉfßÝ (7.25) 71 àα 2 a2 1 -1 4 2 h 1 àα 2 h 1 -1 a1 (a) Jury’s general stability area (b) Stability area for Example 13 Figure 7.6: Stability regions for a second order polynomial and for the second order example feedback system. á âSãä á âSåçæ âéê á ë è èì (7.26) á ôôõ õ õ á ô (7.27) The stability region is graphically illustrated in Figure 7.6b. Jury’s stability theorem can be ö . A set of secondary applied to any íî ï order polynomial coefficients á ÷ ø ë ðá ñ ò ÷ ó éwith ü ÷ á ÷÷ ø polynomials is recursively defined with coefficients á ÷ô á÷ ü ÷ ú á ù ÷÷ ùû ô á ôý ä ú ä ÿõõõÿ é ù , where (7.28) (7.29) á ÷ô , then the roots of ðñ ò ó á ÷ô theorem says that if will be inside the unit circle if and The only if all , for þ ú í are positive. If no is zero, then the number of negative is equal to the number of roots outside the unit circle. In the following example, the concept of the preceding one is used with the four variations of forward Euler and bilinear approximation. ë â and EXAMPLE 14 Stability regions of second order system in four variations of bilinear forward Euler approximation. Take the system in Figure 7.5. Table 7.1 shows the combinations for the resulting functions. ü ë transfer ü â ñò ó and ñò ó and From the characteristic equation (i.e. the denominator of the transfer functions), the coefficients and can be found, and substituted in the second order Jury conditions in Equations 72 FE FE FE BL BL FE BL BL Transfer function Table 7.1: The four transfer functions for four variations of integration methods for the linear system in Figure 7.5. The roots of the characteristic equation (poles of the denominator) must be inside the unit circle for the system to be stable. BL means bilinear approximation, FE means forward Euler approximation. ! 7.21 and 7.22. The resulting stability regions for and approximation. The regions are given in Figure 7.7. ! can be found for each variation of ! " ! It can be seen from Figure 7.7(a) that the forward Euler approximation will render a stable system for a small area in the -plane. The variation with bilinear approximation in Figure 7.7(d) results in the largest stability region, hence most combinations for the system to be stable. Typically the stability is increased for decreasing step size. This can be verified from Figure 7.7 as well. %$ Since the the system matrices of the state space model that represent matrices of the subsystems , i.e. &' x * + ./ &' 4353 * + &' 671 8 93 , ( ( x¯¯ , - 0 (2 6 ;6 1 8 x ) : : &' ) * + 1 ) ¯) @ -BA 8 8 C8 ( xx¯ , A :%) : :%) ) D x¯ :%) : : ¯) # , are made up of the * + '& 6 * + = > , ( 76 %, < ? 6 : ): : ) < D x ¯ x ¯ x ¯ (7.30) (7.31) This solution shows that the closed loop poles of the interconnected system can be traced to the roots of the subsystems. Hence if 73 E F a2 2 h a2 1 h E 2 h 2 h 2 h G a1 2 (a) Region for Combination FE-FE I a2 4 h2 E 2 h G a1 (b) Region for Combination FE-BL H a2 2 h I a1 a1 (c) Region for Combination BL-FE (d) Region for Combination BL-BL Figure 7.7: Four stability regions for different combinations of integration methods of the system in Figure 7.5. The combinations are given in Table 7.1. 74 Latency and Synchronization Problems Stability problems can occur when the remote processor cannot respond adequately fast to maintain control over the vehicle system. In effect the integration step size is increased when a communication point is missed. With the integration approximation being forward Euler, an increase in integration step will generally degrade accuracy and may lead to instability. Typically the remote processor will be assumed to be (and if not so, will have to be) sufficiently powerfull to evaluate the simulation results in the allowable time (by default 0.028 s). For a large complex system that cannot be simulated at the required rate, the options for compilation (Real-Time Workshop) and digital signal processing hardware must be considered. In particular situations when the simulation does not necessarily need to be computed in real-time, a solution to the problem of mis-synchronization is available. This solution involves a change in the communication protocol of SPINE, and requires the use of a command line option . See Section D.2. The command-line option -b can be used in the startup command line of the VVSS. Selecting this option will command the VVSS to not continue the simulation if data through SPINE has not yet arrived. An alternative method for solving the problem of mis-synchronization is to implement the observer technique from Chapter 6.4. Accuracy of communication through SPINE The accuracy of the simulation output when simulating in a remote process is subject to a number of approximating algorithms. The first approximation occurs in the exchange of data through SPINE. The communication is implemented as a string-representation of numerical values. A quanitzation error is introduced in the amount of 0.1% of the unit value representation . J The second approximation scheme is inherent in the numerical integration scheme that is applied. A study in Simulink of the simulation performance has been conducted to quantisize the effect. The double integrator in Figure 7.8, without feedback loops is selected as the test system. A sine wave signal is selected for the acceleration input signal . The integrator in red represents the model in Simulink that communicates with the rest of the model through SPINE. Figure 7.9 shows the comparison of the velocity from the VVSS and the velocity as it is computed in Simulink. The velocity is the state after the first integrator. The figure shows good approximation for bilinear integration. The continuous time integration scheme, using Runge-Katta shows satisfactory results as well. KL M N Figure 7.10 shows the comparison of the the position, when the velocity is computed in the VVSS (i.e. original position), or when the velocity is computed in Simulink (i.e. position through SPINE). A velocity integration error will integrate over time if forward or backward Euler approximation methods are used, respectively. This can be seen from the top two graphs in Figure 7.10. Bilinear O It is the recommendation for future improvements on the SPINE that the exchange of values should take place in binary float representation. 75 P Q Velocity P Q Acceleration Q Position through SPINE P Original Position Q P P Q Figure 7.8: A Double integrator system in the VVSS is used to test the accuracy of simulation results. The red integrator is modeled in Simulink, and communicates with the VVSS through SPINE. 3.473 x 10 4 Forward Euler Approximation 3.4725 3.472 3.4715 9.25 4 x 10 3.856 9.3 9.35 Backward Euler Approximation 9.4 9.45 3.855 3.854 3.853 9.7 4 x 10 2.6914 9.72 9.74 9.76 9.62 9.64 9.66 9.78 9.8 9.82 9.84 Bilinear Approximation (Tustin) 9.86 9.88 9.9 9.76 9.78 9.8 9.08 9.1 2.6912 2.691 2.6908 9.6 4 x 10 1.56 9.68 9.7 9.72 Continuous time 9.74 1.5598 Velocity through SPINE Original Velocity 1.5596 8.9 8.92 8.94 8.96 8.98 9 Time (s) 9.02 9.04 9.06 Figure 7.9: Comparison of simulation output in the VVSS and in a Simulink model through SPINE. This figure shows the error between the simulated values. Note the different scales in the vertical axes, which shows that the bilinear approximation method is five times more accurate then the forward or backward Euler method. 76 approximation is shows in the third graph, to be a better approximation method. (The integration solution for selection of continuous integration with Simulink is shown in the fourth graph for reference.) Stability of State Estimator The Kalman observer is identified from the history of state observations. The observable canonical form of the observer system has a convenient property. SR S Since has the poles of as coefficients in the first column, we can immediately test stability. The requirement is that the solution to the problem in Equation 6.35 must resolve in all . As long as this requirement is met, the system in Equation 6.13 will be stable. T UWVYX An effect that could however defeat the filter is the loss of observability through sampling. The effect relates to the nyquist frequency in digital signal processing. If the observer starts to oscillate in between observations, we will only observe zeros. This effect happens when the frequency of the oscillations is larger than half the sampling rate. 7.4 Application Dependant Stability The third study on stability in the context of vehicle dynamics is intensively condected in the industry. It is the area of driving stability. Driving stability is an application specific system problem. This means that no generalized theoretical performance criterion has been established and no particular definition of stability has been adopted throughout. Driving stability or vehicle stability control schemes are developed in a wide variety. The definition of the performance specification or the instability criterion will focus the designer on different objectives, and will thus lead to different control systems. The research in vehicle stability can be broadly classified in the light of a number of performance objectives. The overview here is not complete but covers the most important aspects of vehicle stability. Active Suspension is a control system that is designed to optimize vertical acceleration stability. This class of systems is devided with respect to two properties. The applicable bandwidth is determined by the performance objective. The term skyhook is typically referred to in this case, as is referres to an imaginary large mass in the sky. The system is designed from an imaginary damper between this mass and the vehicle. The objective is to stabilize the mass . Z[ The energy consumption of the system is characterizing the class of active suspension for its application platform. The terms semi-active suspension and active suspension are generally used to refer to low-energy and high-energy consuming solutions. Traction Control is a control system that optimizes the stability of the vehicle’s traction. The term stability here is used to refer to a reliable constant amount of torque on the wheels. 77 Forward Euler Approximation 200 100 0 1 2 3 4 5 6 7 Backward Euler Approximation 8 9 10 1 2 3 4 5 6 7 Bilinear Approximation (Tustin) 8 9 10 1 2 3 4 8 9 10 9 10 200 100 0 200 100 0 200 5 6 Continuous time 7 Position through SPINE Original Position 100 0 1 2 3 4 5 6 7 8 Time (s) Figure 7.10: Comparison of the values for position, simulated in the VVSS in the case when a submodel is being simulated in Simulink through SPINE. The integration errors for the forward and backward Euler approximation methods integrate over time, as can be seen from the first and second graph respectively. The third graph shows that the comparison using bilinear integration method is better. (The fourth graph shows the comparison when selecting continuous method in Simulink.) 78 The performance objective for the system is to minimize slip at the tire-terrain contact surface and to distribute torque to the wheels which have a high slip coefficient at the contact area. The implementation is usually achieved through measuring differential wheel speeds and individual braking. Yaw Stability The yaw rate of the vehicle is an idication for the cornering stability. Effects like spin-out, understeer and oversteer are used in the performance objective of the control system. Actions like vehicle speed, or more advanced: diagonal braking, are used as control output actions. Yaw rate will become unstable when the vehicle is in oversteer. In Equation 8.16 in the next chapter, oversteer is defined as negative understeer. The following simplistic model can be assumed. Steering Command Lateral Accel. - Dynamics Vehicle Yaw Rate Understeer Dynamics Tire ]\ ]\ The vehicle dynamics model is dependant on the vehicle speed . For some where the understeer gradient is negative, the above model will become a positive feedback system which will then destabilize the yaw-rate. As a result the vehicle will spin-out, turn backwards and face upcoming traffic. ^%_ Roll Stability is currently an indicator system that monitors the vehicle state and alarms the driver when the vehicle is on a course of a roll-over situation. The critical angle is unique to a particular platform. In some situations more generic criteria are used to indicate roll-over, like wheel lift-off, or the relative lateral load displacement [47]. The integration of different vehicle stability methods will lead to a systems approach to vehicle handling control, like is being developed by some of the auto manufacturers for the luxery class vehicles. 7.5 Conclusion This chapter highlighted on several aspects of stability. The dynamics equations of the vehicle model must be examined and understood in detail. The introduction of an integration approximation method is the most important consideration for the stability of the digital simulation. Especially 79 when a state is simulated through SPINE, then the numerical accuracy and the bandwidth of the state are limited. Studies for roll stability and yaw stability are applications of the VVSS that is presented in this thesis. It is important to understand the limitations of the VVSS with respect to simulation stability and accuracy, when applying the system to the study of vehicle dynamics response. Chapter 8 Verification The vehicle dynamics model is exposed to several standarized automotive test experiments. The output graphically shown and is analyzed in a numerical way to provide a validity check of the model response. The closing of the chapter recommends two validation studies to be conducted, at the time when the VVSS has to correlate with a particular target vehicle platform. 8.1 Introduction There is no technical merit to simulation and control of experimental systems without the models being validated carefully and accurately. Validation has been known to be a time intensive and laborous effort. However, validation and verification is an essencial benchmark for the quality of the developed model. Future experimental results, based on simulations with the model have no merit if the model has not been shown to correlate in a series of validation tests. This chapter details the verification experiments that are conducted to demonstrate that the VVSS simulation results will be meaningfull to design and test studies. Most of the experiments are common and well known in the automotive society are recommended as standard test procedures [59]. Verification is used to demonstrate the validity of the models. It does not prove that the simulation predicts the behavior of a particular vehicle within a certain margin of error. Validation encompasses the required experimentation with the vehicle and optimization of the dynamic models in order to correlate the behavior of a particular test vehicle with the simulation model. The chapter concludes with two recommendations for validation. 80 81 Figure 8.1: Telemetry aquisition and communication system will be used for real-time on-line validation. 8.2 Vehicle Kinematics and Dynamics The collection of submodels that make up for the overall vehicle dynamics model were explained in Appendix A. The kinematic and dynamic character of the model showed good correlation with simulation results by ADAMS, as was documented in the project report for ITT [9]. In the same report, also verification studies were conducted and graphically illustrated. In the following sections a series of verification studies is conducted that show the dynamic character of the vehicle model. It can be concluded from the simulation results and the numerical analysis of it, that the physics of the vehicle model are accurate. 8.2.1 Static load at the tires and suspension Figure 8.2 shows the settling character of the vehicle for symmetric load load distribution. The vehicle is not in motion. Each corner of the vehicle is loaded with a quarter of the vehicle mass kg. Hence the force in the suspension will be `abYc d d a b c d d cnobBn ef g h7b ` Y i j l i km k p qr (8.1) The tires have the additional unsprung mass a `sty bwv c d d i d y cn{b i etsug htbwv ` ; i x j i x z k m q | } r n km d d d r ~ sbBn } d m d d d r f g htb e f f g h b n n k d p d q d Y b d m n d | ~ k m The deflection for suspension and tires can be computed with the stiffness coefficients and , to be (8.2) ~ f#b (8.3) 82 Steady state deflection lengths for suspension and tires 0.12 Suspension Defletion Tire Defletion Deflection (m) 0.1 0.08 M =800 kg, K =19,000 Nm, K =150,000 Nm v S T 0.06 0.04 0.02 0 1.5 2 2.5 3 3.5 Steady state deflection forces for suspension and tires 3000 Forces (N) 2500 2000 1500 1000 500 1.5 2 2.5 3 3.5 Time (s) Figure 8.2: Validation data for steady state load distribution. u t u (8.4) 8.2.2 Steady state cornering Steady state cornering is the experiment where Ackermann steering geometry and lateral slip forces can be verified. The lateral slip forces compensate for the centrifugal acceleration of the vehicle as it maintains its velocity in a circular motion. C The experiment is conducted with a steering angle of . The mass of the vehicle is , and the wheels weight each. The centrifugal force that exerts on the vehicle in this test is given by ¤ l ¢¡£ ¦¥ o§ © ¨ ª £ ¬ ¤ « ¬ (8.5) where is the radius of the trajectory (See Figure 8.4). This total centrifugal force implies an average of per wheel of lateral force, which is a good estimate as can be seen in Figure 8.5. The verification of Ackermann steering geometry is addressed in Section 8.2.4. 83 Steady state cornering deflection lengths for suspension Deflection (m) 0.108 0.106 Left Front Right Front Left Rear Right Rear 0.104 0.102 0.1 0.098 0 10 20 30 40 50 60 0.01 5 0.005 Velocity Roll Angle 0 0 10 20 30 40 Angle (rad) Velocity (m/s) Vehicle Velocity and Rolling Agle for Steady State Cornering 10 0 60 50 Time (s) Figure 8.3: Suspension deflections, vehicle velocity and roll angle for steady state cornering validation test. Trajectory of Vehicle during Steady State Cornering test 100 80 60 r =50.6257 m s θ =0.05 rad cmd 40 20 0 −20 −60 −40 −20 0 20 40 60 Figure 8.4: The trajectory during steady state cornering. The vehicle is driving in clockwise direction. 84 Lateral Slip Forces during Steady State Cornering test 400 350 Lateral Slip Forces (N) 300 250 200 150 100 50 0 0 10 20 30 40 50 60 Time (s) Figure 8.5: Lateral forces on front tires for steady state cornering. 8.2.3 Constant torque acceleration and braking The equations of motions can be verified by applying a constant torque on the wheels. Simple Newtonian physics can be used to compute the velocities and distance for an accelerating body over a given period of time. The test is conducted in two stages. The vehicle is accelerated in the first 10 seconds by applying a constant torque of on the two front wheels (the vehicle is designed for front wheel drive). In the time interval of 20 - 25 seconds a constant brake torque of is applied to each wheel. This accelerating and brakng profile is shown in Figure 8.6 ® ®¯° ® ®¯ The acceleration of the vehicle in the first 10 seconds can be found from Figure 8.6 as ±%²´¶³·µ ²³ ¸²¹º » ² ® º ¹ » ° · ¼ µ º ® (8.6) This value for the acceleration compares with the vehicle acceleration that results from the tire forces ±%²¾Æ½ÇC¿ ÀÈ#Á Â É¿ Ã ÆÄ Å ÄÊ ¿ ² ¶ Ë Ì ÌÍ Í º » È È É ¶ Ë Ë É Î Ï º Ì ² ® º ¹ ¹ Ð ° · ¼ µ ®® ® (8.7) Furthermore, from Figure 8.6 it can be found that the final distance should compare with the area 85 Accelerating and braking Longitudinal Slip Forces Slip Forces (N) 600 Right Front Left Front Right Rear Left Rear 400 200 0 Mv=800 kg −200 −400 0 5 10 15 20 25 30 200 5 100 Velocity Position 0 −5 0 5 10 15 20 0 25 Distance (m) Velocity (m/s) Vehicle Velocity and pitch angle for accelerating and braking 10 −100 30 Time (s) Figure 8.6: Torque profile and velocity and position output for constant torque accelerating and braking. under the velocity curve. In formula this means, ÑÒÓ Õ Ô ÒÖ× Ø{ÙÚ Û ÜÝÜ Þ7ß#Õ Ö× Ø{ÙÚ Õ à Ý Õ Ü Þ # ß Ö× ØÙÚ Õ ÜÝ#Û Ü Þ Ò Û Û Ø× Õ àá (8.8) and computed with the acceleration, we can see that after the first 10 seconds, the vehicle has traveled ÑÒ ÕÓ ã â Ò ã Õ Ô â Ò Ú Ü× Ö Ø{Õ ä Û Ü Þ â ÒYå å × àá × (8.9) 8.2.4 Ackermann Steering Verification Ackermann steering geometry is verifying the input steering angle with the computed angle, from a circular driving test. Figure 8.4 shows this kind of test. The expression for Ackermann steering angles is given in A.6 and A.7. The steering angle can be computed from the circular radius in Figure 8.4 as æ ç èCé{êYë ì í î ë ïð7ñ{ò ßôó ò ê Õ à × ù à Ò Ü× Ü à õ ãú × õ öø÷ Ü (8.10) 86 Steering Wheel Angle (rad) Ackerman Steering Geometry 1 0.5 0 −0.5 −1 0 1 2 3 4 5 6 7 8 9 10 Wheel Angles (rad) 1 Left Right 0.5 0 −0.5 −1 0 1 2 3 4 5 6 7 8 9 10 Time (s) Figure 8.7: Ackermann steering verification test. Cornering geometry difference for left and right wheels will be shown by turning the steering wheel left and right with a sine input, on a standing vehicle. The input angle is shown in the top graph of Figure 8.7. The steered wheel angles and are shown in the bottom graph. û ütý þ û ütý ÿ The small difference in wheel angle at neutral steering angle position is called the toe-in angle, and was discussed in Section A.2. Given a track width of m and a gear ratio of , with an input steering wheel angle of rad, the steered wheel angles are computed with Equations A.6, A.7 and A.9, as û as can be seen at - ! ÿ þ $ ÿ " # " % ÿ & ý þ +* þ" # ÿ ÿ $ÿ "% & û ý þ û ,/. . 8.2.5 Stopping distance ' ( ) (8.11) ' ( , ) (8.12) 87 Stopping Distance Emergancy Brake Test 240 220 200 180 14 15 16 17 18 19 30 6 Velocity (m/s) 25 Velocity Acceleration 20 4 2 15 0 10 −2 5 −4 0 −6 −5 −8 −10 14 15 16 17 18 −10 19 Time (s) Figure 8.8: Typical trajectory profile for stopping distance. Stopping Distance Emergancy Brake Test 500 Longitudinal Slip Forces per Tire (N) 0 Left Front Right Front Left Rear Right Rear −500 −1000 −1500 −2000 −2500 −3000 14 15 16 17 18 19 Figure 8.9: Typical trajectory profile for stopping distance. Acceleration (m/s2) Position (m) 260 88 The distance that is covered between the moment when a hazard is recognized and the time when a vehicle comes to a complete stop is not rarely of crucial importance. It is the distance travelled during the retardation time, plus the distance travelled during decelleration, 0 123 4 5 687 ;:3 >< 9 = (8.13) The time that it takes to bring the vehicle to a complete stop is called stopping time, and is the sum of the latency and the decelleration time, 4 12?4 5 687 <3 where 4 56 (8.14) the time where no braking occurs D 4 5 [email protected]?4 A7B4 C7 4 E ; = (8.15) The the retardation time for pressure build up is given by 4 C , and 4 A is the human reaction time. The reaction time is not a fixed value, it ranges from 0.3 to 1.7, depending on the driver and on external factors. The retardation time varies per vehicle. Values between 0.36 and 0.53 seconds are generally used [5]. Figure 8.8 shows an emergancy brake test. From the position in the top graph, we can see that the ; F FGH; ; I 2 ; J/K at a velocity of ; ;/KML 0 , at the maximum possible stopping distance is around IEKML 0 9 . Figure 8.9 shows the associated longitudinal slip forces. The decelleration of close to N = forces at the front wheels are greater since the decelleration induces a load transfer to the front of the vehicle. 8.2.6 Circular Skid Pad An effective way of measuring steady state directional control is circular skid pad testing. The objective is to drive the vehicle in a constant radius at a range of speeds, starting from very slow (to establish Ackermann Steering, as in Section A.4) to near the limit of the vehicle. At each speed a number of measurements will be made. They include the steering wheel angle, vehicle velocity, lateral acceleration, roll angle and yaw rate. The circular skid pad test is particularly usefull to estimate the understeer/oversteer gradient. A vehicle is said to understeer when, as lateral acceleration increases, the slip angle at the front axle increases more than it does at the rear axle. (The opposite applies for a vehicle which oversteers.) The SAE definition for understeer gradient is given as O8P 2RQ S T UV Q T X W Y (8.16) 89 Vehicle Driving Commands 1 Steering Wheel Throttle Angle (rad) 0.8 0.6 0.4 0.2 0 0 20 40 0 20 40 60 80 100 60 80 100 Velocity (ms−1) 25 20 15 10 5 0 Time (s) Figure 8.10: Throttle command and roll angle for circular driving test. Vehicle Dynamics Response for Circular Skid Pad Cornering Radius (m) 100 80 60 40 20 Lateral Acceleration (ms−2) 0 0 20 40 0 20 40 60 80 100 60 80 100 15 10 5 0 −5 Time (s) Figure 8.11: Vehicle velocity and heading in a circular driving test. 90 Trajectory of Vehicle during understeer 100 100 80 80 60 60 40 40 20 20 0 −50 0 50 0 −50 First 80 seconds 0 50 Last 30 seconds Figure 8.12: Planary trajectory graph for circular driving test. The vehicle is driving in clockwise direction. with the lateral acceleration Z:[ Z ab c d e f \]^`gH_ h>iBj:gl]k (8.17) which states that the gradient is defined as the increase of steering angle per increase of velocity [47]. A Vehicle is said to be in oversteer if m8n is negative. From Figure 8.10 it can be seen that the vehicle will go in understeer after 80 seconds. Since the vehicle is front wheel drive, the rear tires are only exposed to the lateral acceleration forces and not to the traction forces.Z [ When at approximately 110 seconds also the rear tires start to slip, the vehicle becomes oversteer spins out, as can be seen in the trajectory in Figure 8.12. The lateral acceleration \] for the circular skid pad experiment is plotted in Figure 8.11. The lateral acceleration approaches a value of 9, which is just less than the gravity acceleration o . This Z ab c on d e f a dry surface, which is given by value coincides with the maximum slipforce prq s/t ] u^?vEw g [email protected] (8.18) Commercial test procedures for cornering tests are found in [30] and [59]. 8.2.7 Yaw acceleration while braking under split-v condition The correctness of the behavior of the vehicle, when the tire dynamics are exposed to different slip coefficients per wheel, can be verified with the split- v braking test. The setup is such that the left two wheels are in contact with dry terrain (high stiffness) and the right two wheels on slippery conditions (wet, icy, i.e. low stiffness). The test results are drawn in Figure 8.13. Figure 8.4 shows how the longitudinal and lateral tire forces build up during the test. 91 Split−µ Brake test Trajectory 10 5 0 −5 220 225 230 235 240 245 250 255 260 Yaw Angle (rad) 2.5 2 1.5 1 0.5 0 0 2 4 6 8 10 12 14 16 18 20 Time (s) Figure 8.13: Trajectory and yaw profile for split- y brake test. Longitudinal Tire Forces During split−µ Braking 0 −2000 Left Front Right Front Left Rear Right Rear −4000 −6000 0 2 4 6 8 10 12 14 16 18 20 16 18 20 Lateral Tire Forces During split−µ Braking 4 3 Tire Forces (N) Tire Forces (N) 2000 x 10 Left Front Right Front Left Rear Right Rear 2 1 0 −1 0 2 4 6 8 10 12 14 Time (s) Figure 8.14: Tire forces under split- y braking conditions. 92 Braking in a Curve 25 Trajectory 20 15 10 5 0 180 190 200 210 220 230 240 250 260 Yaw Angle (rad) 2 1.5 1 0.5 0 0 2 4 6 8 10 12 14 16 18 20 Time (s) Figure 8.15: Trajectory and yaw profile for braking in a curve. 8.2.8 Braking in a curve The combination of braking and cornering is probably one of the most common encountered manouvers in driving. A vehicle reaction to this manouvermust be characterized by the best possible compromise between steerability, stability and retardation. Several methods are available to conduct braking in a curve. Starting with the vehicle traveling in a straight line, the steering angle is changed to a specified angle. The vehicle response serves as the basis for evaluation. The most important quantities to be measured are yaw speed, vehicle speed and lateral acceleration. The trajectory, the yaw angle and the tire forces for this experiment are shown in Figures 8.15 and 8.16. Commercial test procedures for barkeing in a curve are found in [28] and [59]. 8.2.9 Double Lane Change The last test in this section of vehicle behavior verification check experiments is the double lane change. The test is a standardized procedure for characterizing vehicle handling in traffic manouvers. The vehicle dynamic lateral response is of particular interest. Figure 8.17 shows the commanded and the resultant trajectory, with in the bottom graph the associated steering command. The 93 Longitudinal and Lateral Tire forces for braking in curve 2000 Fslip,x (N) 0 −2000 Left Front Right Front Left Rear Right Rear −4000 −6000 3 0 x 10 2 6 8 6 8 10 12 14 16 18 20 10 12 14 16 18 20 4 Left Front Right Front Left Rear Right Rear (N) 2 1 F slip,y 4 0 −1 0 2 4 Time (s) Figure 8.16: Suspension deflections and heading profile when braking in a curve. Double Lane Change Manouver 10 Trajectory Driving Command Trajectory 5 0 −5 −10 200 205 210 215 220 225 230 235 240 Steering Wheel (rad) 0.3 0.2 0.1 0 −0.1 −0.2 15.5 16 16.5 17 17.5 18 Time (s) Figure 8.17: Trajectory and asociated steering command for double lane change. 94 Longitudinal and Lateral Tire forces for braking in curve 3000 Left Front Right Front Left Rear Right Rear 2000 F slip,y (N) 1000 0 −1000 −2000 Lateral Acceleration (ms−2) −3000 15.5 16 16.5 16 16.5 17 17.5 18 17 17.5 18 10 5 0 −5 −10 15.5 Time (s) Figure 8.18: Lateral forces and lateral acceleration on the vehicle during lane change. distance and time axes are aligned, so that the top graph correlates the distance with the steering command at the particular time instance. Figure 8.18 shows the lateral acceleration and the lateral tire forces in the same time frame. Commercial test procedures for lane change are found in [29]. 8.3 Telemetry for Real-Time Verification and Validation Additional experiments are planned for the future at the Oakland proving ground. This study will involve a telemetry data-aquisition system installed in a vehicle. It will enable the VVSS to log numerous vehicle sensory information through a radio-link in connection with the virtual vehicle in simulation. The driver inputs from the real vehicle will applied to the model as inputs for the simulation. The concept for telemetry is drawn in Figure 8.1. Using the telemetry configuration, different tests and experiments can be conducted, to validate the vehicle performance and driving behavior. It is the objective, that the solution of the simulation of the virtual vehicle correlates with the real automobile’s driving dynamics. At second instance, the telemetry configuration can be used to condect carefully designed experiments that will help identify vehicle parameters and therefore validate the simulation model against the real vehicle dynamics. Validation in this context is defined as the process of optimizing model 95 Mass High frame-rate video capturing µ1 Dual µ-surface sliding table µ2 α Figure 8.19: Dual-z dynamic sliding and static stick friction verification test table. parameters while minimizing the correlation error between simulation and empirical data { . For example, tire data is typically not well parameterized. Characteristic data can be found by carefully matching experimental data on the simulation results. Similarly, nonlinear suspension characteristics can be found and used to optimize the VVSS model. In order to aquire sufficient data for vehicle model optimization, the following set of sensors are required. | | Driver input sensors. Steering wheel angle, throttle and brake pressure will have to be measured. If brake pressure is not available then brake angle will be recorded. | Chassis motion sensors. Gyroscopic sensors and accelerometers for angular and translational motion for the six degrees of freedom are required. Additional (redundant) sensors like GPS will be beneficial for improving accuracy. | Suspension deflection sensors. Typically installed as an LVDT parallel to the struts, between the suspension mounts. Vehicle speed. A fifth wheel must be connected to the vehicle to measure unperturbed vehicle speed. From the vehicle speed, tire slip dynamics can be derived. The requirement of the availability of a restricted test area, the telemetry equipment and an experimental vehicle that is furnished with the necessary sensors and DSP equipment, must be met before experiments can be conducted. Hence, validation tests are time consuming and costly. } It must be realized that many characteristic data still cannot be found, using this method. For example, the engine torque constant map will require a dynamo to characterize. 96 8.4 Tire model verification A fuzzy logic tire model has been introduced in Chapter 3. The dynamic behavior of the model must be validated with experimental comparable friction measurements. For this study a tilted table with dual friction surface as is shown in Figure 8.19 is needed. The study involves the following experiment. A well known mass will slide down the low-friction surface and gradually accelerate as it does so. Once on the high-friction surface, it will decelerate until it comes to a complete stop. The friction coefficients must be known. During the experiment, the high-speed camera will record the motion of the mass. From the speed profile, it can be studied how the sliding and friction forces act on the mass, and thus validate the friction model. This validation experiment has not been completed for this dissertation. 8.5 Conclusion Verification of the vehicle model, as it was presented in Section 8.2 shows that the physics of the vehicle dynamics model are accurate, and that the response of the model compares with the expected behavior. The assumptions in the model designs and the level of detail of the submodels is discussed in the next chapter and in Appendix A. Verification and validation are two different necessary studies that need to be conducted before the simulation output can be related to the driving performance of any real vehicle. When the vehicle simulation will be used for predicting particular vehicle manouvring behavior, additional correlation studies must be conducted, to validate the vehicle model. A procedure for doing so was discussed in this chapter. Chapter 9 Conclusion and Recommendation The result of the research that is presented in this thesis is the successfull completion of the Virtual Vehicle System Simulation. The VVSS and SPINE have been implemented and are available for studying vehicle dynamics. The research efforts builds on various elements of systems engineering, including mathematics for modeling, computer science for implementation and communication, state-of-the-art technology for graphics, and engineering principles for dynamics and control. It is difficult to conclude on a research project that has numerous challenges for growth. This chapter is the conclusion of the research that has resulted in the virtual vehicle system simulation with the network for modular parallel simulation in real-time. In addition to the conclusions on the presented work, the succeeding sections address topics and issues for future work. 9.1 Conclusions It can be concluded that a system has been developed which allows a person to drive a vehicle model through a virtual world, and to utilize familiar simulation software like Simulink through a network to analyze and redesign parts of the vehicle system in real-time. With the mathematical vehicle model being a purpose-fit representation of a true vehicle, for analyzing vehicle dynamics, it must be realized that the system will not suit just any research application. Functional studies of stability and driving-aid systems can now be conducted at a desktop level. But the vehicle simulation is for example not designed for applications like crash analysis or safety tests. As the bottom-line question, “can the VVSS be considered a virtual proving ground ?” For analysis and design studies of vehicle dynamics related systems: yes. However, test tracks are intensively used for a wide variety of experiments, of which only a particular set can be conducted with the VVSS. The main contribution of this research lies in the accomplishment to develop a network structure for real-time simulation. The application of indirect addressing of the state values, to allow flexible reconfiguration of the vehicle model is a new approach for simulation, combining computer science 97 98 with systems engineering. Another contribution is the fuzzy logic tire stick-friction model. The tire dynamics formulation is still a physical based derivation. The feedback loop for stick friction, supervized by a fuzzy logic switching algorithm allows the vehicle to halt, backup and speed up, without encountering numerical singularities. The verification studies in Chapter 8 show the capabilities of the vehicle model and the dynamic response to a variety of driving manouvers. Further validation needs to be conducted to ensure that the numerical output correlate with any particular vehicle platform that is targeted for the simulation. 9.2 Recommendations In order to interpret and analyze the predicted vehicle behavior from the simulation, it is of absolute requirement to understand the fidelity and the limitations of the vehicle model. Conclusions on certain behavior cannot be drawn without insight in the underlying structure of the model and thus the origin of the behavior. The fidelity of the vehicle model can be learned from Appendix A and the verification studies in Chapter 8. Some serious assumptions which may have immediate impact on simulation results for particular scenarios are the following. ~ ~ The tire model is based on a single spoke model . The spoke is directed in the vertical plane, in the vehicle reference frame. This means that the tire force will have a small but non-zero longitudinal component, when the terrain is in an angle with the vehicle horizontal plane. As a result, the vehicle may slowly start to roll, when there is a pitch angle. A multiple spoke-model will solve this problem. ~ Currently the wheel spin dynamics do not incorporate gyroscopic, centrifugal and coriolis forces. Therefore the steering dynamics does not include an aligning force feedback at higher speeds. This assumption is valid for almost all driving conditions. ~ A strongly reduced engine and transmission model has been implemented in the vehicle model. Appendix A details about this drive-line. Basically, in the current vehicle dynamics model, a torque is applied to the front wheels that is proportional to the throttle angle, dependant on a gear troque conversion factor. The model for braking is simplified to be a friction, or a damper between the wheel spin and the chassis. The damping coefficient is dependant on the brake angle. Obviously the damping coefficient should be dependant on the brake pressure (i.e. the force on the brake pedal), and the appropriate parameter model should be incorporated as a lookup table. These improvements are recommended for future work. The integration methods have been discussed in Chapters 4 and 5. The fact, that integration accross SPINE can only take place with the forward Euler method, implies a serious constraint on the 99 performance and accuracy of the simulation. The bilinear integration method could be used, if updated values of the integrated states would be available. For this purpose a Luenberger observer can be used, to estimate a prediction of new state values. It is recommended that an observer algorithm of this kind is used for integration of states of the subsystems that are simulated through SPINE. Furthermore, the system leaves many parameters to be configured for the right application and many aspects to be improved upon. The network environment (SPINE) and the vehicle model (VVSS) have shown to respond appropriately for conducting analysis and design studies for stability and drivability systems. With the VVSS facility being modular, it is the objective that it will require minimum knowledge and effort from any engineer to implement concepts and to conduct simulation research. Some of the recent commercial collaborations involved research studies on a windhield wiper system, active suspension, automatic acoustic fueltank level measurement system, automated data validation, SAE-spike generator modeling [13], traction control for 4x4 trucks [8], and vehicle speed estimation [34]. In collaboration with the government, Oakland University has worked on a leader-follower project [10], ACC[14], [11], collision warning and traffic monitoring [48], active suspension [7] and steward platform kinematics determination [12]. The VVSS can be of considerable added value in a commercial design process. Benefits are in the process of virtual engineering, where the VVSS is a shining example of the application of innovative technology, for accelerating the design and development process of new products. Also in the area of education will the VVSS develop an indispensible intuitive understanding of vehicle dynamic properties and design. The ease and lack of investment with which design changes can be implemented and tested instantaneously, allow for students to conduct numerous educational lab-experiments, that will contribute to the learning process. As a showcase of modern technology and innovation, the VVSS will serve as a valuable asset in selling vehicle system performance to customers. Whether they are users, or purchasing for a manufacturing corporation. Last but not least, the vehicle simulation system is the exclusive tool for developing driving application systems such as traction controll, anti-roll, active suspension, etc. The rapid and cheap process of redesigning, testing and analyzing, the simulation provides the valuable capability of system design optimization. With minor additional changes to the simulator, it can will be usefull for collision warning, object avoidance, traffic monitoring and aspects of automated highway systems as well. 9.3 Retrospect and Prospect The long term vision for the development of the simulation facility requires the consideration for additional research efforts. The current environment of engineering, stimulates the use of simulation science and technology for the analysis and design of engineering systems. Human immersion was mentioned as one of the research aims for the VVSS. The current system 100 utilizes steering, brake and throttle peripherals for aquireing driver inputs, and generates a realtime stereoscopic image of the scenery from the driver’s viepoint. Human immersion however, includes force and motion feedback and appropriate audio cues, which relate the looks, the feel and performance to a real driving situation. The real-time interfacing mechanism between the simulator and the human operator was proposed to be interactive. A driver cab (vehicle interior, with dashboard, seat, steering wheel and pedals) will be mounted on a Steward platform. The platform will be actuated from the simulator, in order for the human driver to feel the forces and motion that are experienced in a real vehicle. Furthermore, the steering wheel and the brakes will be equipped with actuators, so that forces from the vehicle can be fed back to the driver. Together with 3D vision and surround sound, the objective of the interface is to immerse the human driver in the virtual realistic vehicle simulation. The efforts to complete the VVSS with the additional resources are recommended for future work. It has been goal of many years to develop a test-track on campus ground. Discussions with surrounding industry and government agency have ventilated the desire to facilitate an area for vehicle performance testing as part of the university. In the goal of the VVSS, to facilitate a wide variety of research applications, it will have to be able to adopt different vehicle platforms and different scenery. Together with the modularity for the mathematical submodels, there is a challenge to make the simulator fully modular and transparent to any particular research application. For future applications, sceneries will be designed for off-road and (automated) highway testing. Additional research on terrain modeling is conducted by Alexander Reid [54]. Additional models could be created from the Oakland University campus or for example the Chelsey proving ground. In this flexible setup, the VVSS facility will be of great benefit to the courses in Automotive Mechatronics at Oakland University [31]. Students can start a mechatronics design at a component level, based on systems originated requirements. They can then implement the concept and test and validate it against the intended requirements at the systems level. The total procedure procedure will be exercised in a classroom setting. Finally, the VVSS will be a usefull testing environment to study multiple vehicle scenarios. The applications therefore vary from traffic monitoring, road-sign detection, Automated Highways, Intelligent transportation to battlefield warfare. In the aim of facilitating this kind of applications, it will be beneficial and innovative to restructure the vehicle dynamics as an object, to be furnished in a High Level Architecture (HLA). Research for high level simulation architecture has recently attracted attention in the area of multi vehicle, warfare and traffic simulation. Also this aspect is mentioned here as a recommendation for further improvement and development toward application. These notes conclude the contributions of the conducted research, the status of the simulation system, and a preview of opportunities for future work. Appendix A Details on Modeling The derivations for the system dynamics are presented in the following sections. They are based on the Newtonian equations of motion and balance of forces. Additional resources for further reading on modeling vehicle dynamics are found in the fundamentals of vehicle dynamics [21], race car vehicle dynamics [47] and the report on vehicle dynamcis by ADI, Inc. [27]. A.1 The driver environment An important model in the loop of the VVSS, which has not been given much attention is the human operator, or the driver. The human driver is hard to identify and characterize in engineering terms. The optimal human control model 6.1 has been introduced in Section 6.2. Otherwize, previous work is referred to, since it is beyond the scope of this dissertation. The driver environment consists of the interface peripherals for steering, throttle and break and of the terrain model of the virtual scenery. The interface peripherals are mounted on a shaker table, so that when it is actuated correctly, the driver can experience the virtual realistic immersion in the simulation, while controlling the vehicle. The virtual scenery is displayed in front of the human driver, on a large screen high definition projection screen. The screen is connected as a monitor for the Silicon Graphics ONYX Reality Engine. The animation of the simulation output is rendered from the drivers’ viewpoint, in such a way that the driver has the impression of looking through the windshield of the virtual vehicle. The ONYX uses hardware graphics boards to generate the scenery, that are designed to generate 3D imaging, using Cristal-eyes goggles. The VVSS is setup to employ this stereoscopic capability. The motion system that holds the driver seat and console, can be actuated to represent the motions of the virtual vehicle. Special considerations need to be addressed like washout filters and bandwidth issues. The table in Figure A.1 is an example of a driver console on top of a motion platform. The 101 102 Figure A.1: The Motion platform with driving environment mounted on top. implementation aspects of the motion platform will be addressed in future efforts. A.2 Steering Model The steering wheel input is defined as the angle of the steering wheel. It is subsequently converted to the wheel angle + . The wheel angle is an input to the tire model (Appendix 3.2) which computes the the forces on the tires, caused by the ground contact. The tire forces cause a reaction force in the steering wheel. It is important to understand the mechanism of caster and camber angles and steering complience in order to understand the dynamics of the steering system. The model that is implemented will be a simplification of these dynamics; accurate enough to provide force feedback to the human driver. Camber Angle The Camber angle of the wheel is the inclination of the wheel axis away from the vehicle chassis in the vertical plane. Figure A.2 shows the camber angle in the right diagram. Camber angle improves lateral control of the vehicle. Depending on the tires, a camber angle of 0 to 3 degrees is typically employed. The dynamic equation for the camber angle is given by : + B' Br >' @ ' (A.1) 103 u Caster Angel α Kingpin Kingpin Camber Angel trail road-tire contact patch (arm moment) Fy (lateral force) Figure A.2: The graphical illustration of the definitions for caster and camber angle. where :¡ ¢ stands for the inertia moment of the wheel about the kingpin axis, £ ¤ holds the camber angle, ¥ ¦§H¨?© ª'« represents the effective tire radius, ¬¤ is the damping effect and r¤ is the equivalent stiffness coefficient of the connecting system. A simplification without dynamics is given by §'¯° ± ² ¢ ³ ´:¥ ¦§@¨H© ª« £ ¤>® r¤ (A.2) The camber angle will introduce a miss alignment of the tire contact surface area with the terrain. The derivation is given here for completeness. However, camber angle is not used in the VVSS vehicle dynamics model, since for the tire model homogeneous pressure distribution is assumed. Tire deformation forces, other than the deflection are not considered. Kinpin Angle The kingpin angle is the angle between the steering axis and the x-axis in the vehicle frame. It has effect on the steering feel and influences steering force feedback and the steering roll-radius. Caster Angle The caster angle µ in Figure A.2 is defined as the angle between the steering axis and the vertical plane. Together with the kingpin angle it infuences the camber change as a function of the steering angle, as well as self-centering effect on the steering. Toe-in Angle The toe-in angle is the offset angle for the steered wheel or bias on the heading for the non-steered wheel. It can also be defined as half the distance between the wheel’s front and read rim flange. The toe-in angle affects straight driving and steering. In the case of front-wheel drive vehicles it compensates for the elastokinematic changes in track (See [5]). 104 ¶AA θcmd Tire Angle ¶AP θw Steering Wheel Kst Stiffness Coefficient Gearbox Kingpin ¸ Mss ·N Sst Damping Coefficient Moment about Kingpin Figure A.3: The second order steering system model. Steering Compliance The model for the steering compliance has been adapted from [18]. The angle ¹ between the kingpin and the normal unit vector in the º -direction is referred to as the Caster angle. The distance between the center of the tire contact patch and the point where the axis of the kingpin intersects with the road surface will be called the »» . This is shown in the left of Figure A.2. The moment ¼½ ½ about the kingpin, caused by the lateral force on the wheel can be written as ¼½ ½¾À¿'Á½ Â Ã Ä Å Æ ÇÈ É Ê Ë ¹'Ì Ä Í where Ç is the Î by (A.3) Ï Ð:Ñ Ò , shown in Figure A.2. The dynamic equation for the steered wheel, is given Ó Õ½ Õ½ Õ½ Ì ÄHÖ8Ô ×@ØBÙ½ ÚlÖ8Û ×@ØBÜ@½ Ú Ö8×Ý¾ Ó Ü@½ Ú Õ Þ ßà ØBÙ½ Ú Õ Û Þ ßàâá ¼½ ½ (A.4) Õ is the angle of where Ì Ä stands for the inertia moment of the wheel about the kingpin axis, 8 Ö × ¿ the steering wheel, stands for the gear box ratio of the steering system, Ù½ Ú is the equivalent Õ damping coefficient and Ü@½ Ú the equivalent stiffness coefficient of the steering system. ½ is the steering angle at the steering gear. This model of the steering system is drawn in Figure A.3. Õ for one of the steered wheels is derived from the Ackermann cornering geometry. The actual ¿ The concept for Ackermann steering is explained graphically in Figure A.4. The concept shows that the steering wheel angle commands the vehicle to turn in a curve with radius Ï ½ , such that Õ½Í » : Â Ø Ù Â Ë » : Â Ø Ù Â Í È É Ê Ë Ï ½¾ ã ä å Ë Õ ½ Í ¾ (A.5) Ê æ å Ë Õ ½ Íèç 105 éθ cmd 2 TF 1 Al+Bl é θ éθ s,2 s,1 rs Figure A.4: Ackermann cornering geometry. With ê ë , the individual steering angle inputs per wheel can be derived. For the situation as drawn in Figure A.4, this leads to õ ì ùï úø ð ñ òóôñ M õ ö ó ì ë ü ýþMÿ ÿ ü õ ì ë ë û õ ì ùï úø ð ñ òóôñ M õ ö ó ì ë õ ì ü ýþMÿ ÿ ë ë ù ü ì í+î ïðñ ò ó ô ñ õMö÷ø ê ëû ì í+î ü ðñ ò ó ô ñ õMö÷ø êëù (A.6) (A.7) A simplified model that contains no dynamics will give the angle of the steering gear from the steering wheel angle as follows : ìë ð :ì û þ ë ø # î ! " ë ë ë $&% For the presence, the steering system is characterized by the steering angle gear ratio us with the model from which the steered wheel angle ì í+î ìë ð :ì can be derived with Equations A.6 and A.7. (A.8) , leaving (A.9) 106 .ΣT αth -rpm ) E TE - - 1' JEs 1' s ,B θE - + 1' s G JGs - θG ,B DG +- E (N TG KG slip G (N G TE TG αth,3 NG,1 +N G,2 +N αth,2 αth,1 *rpm G,3 TE Figure A.5: Dynamic model of the powertrain. A.3 Engine and Transmission Model The throttle angle /10 2 is read and converted as a torque to the transmission 354 , based on the 7 engine drive shaft rpm 6 4 , using the engine map. The output torque of the engine is loaded with the transmission through the gearbox, resulting in a transmission torque 318 . This engine and transmission model is drawn in Figure A.5. The model incorporates second order gearbox complience in the system with coefficients 9:8 and ; 8 for stiffness and damping respectively. Usually the stiffness of the gearbox is very high, so that the model can be reduced to the much simpler model, given by 7 7 318=<>85? @ 354BA /10 2 C16 41D (A.10) 7 where 354BA /10 2 C16 4D is the lookup table, shown in Figure A.5 and 6 4 the rpm of the engine, given as a function of gearbox ratio and the average wheel spin velocity FE G as 7 6 4H<>85? @ FE G (A.11) 107 A.4 Brake Model The brake angle is read and converted to a break pressure. The pressure on its turn is applied to the wheel and employs a damping effect on the wheel spin motion dynamics. In other words, the torque is proportional to the brake damping constant IJ , the brake booster constant KLJ , the brake angle M1N and the wheel spin P O . In Equation, this model is given by Q NRTSUIJKLJM1N P (A.12) Brake Pedal K V br Brake Piston X WD Nbr Brake Amplifier br Figure A.6: Schematic diagram of the hydraulic brake system. As a future extension, to model force feedback to the human driver through the brake pedal, the pressure in the hydraulic actuator will be transferred as the pedal reaction force. A pneumatic damper on the pedal will model the damping effect of the fluid in the brake piston. A.5 Wheel Spin Dynamics Z\[ ]^ _ ` a b c Q Q1Y N d ef d Ph g d PO g P Figure A.7: Model diagram for wheel angular dynamics. The wheel dynamics model describes the angular motion, caused by the torques about the wheel axle. The angular motion dynamics can be expressed as the sum of torques of the inertia, acceleration and break, and the torques caused by the slip forces. The sum is given in the following expression. 108 ji k lnmoqprmrp1st u1v w x1yzp5{1yn|} ~ \ (A.13) From this equation the spin velocity and wheel angle can be found by integration. The state-space representation of this model (in Figure A.7), is formulated as j i j L j m j y n Note that for front wheel drive vehicles p1s5 5m for 1m p1s p5{ |} ~ \L (A.14) . A.6 Suspension and Tire Deflection The wheel mounting and the contact of the tires with the gound are a rather complicated system. Figure A.8 shows in a diagram how the different components interact. The wheel basically acts as a free floating mass, connected to a double spring damper system, subject to gravity. In other words, the location of the wheel U , is a function of the tire-ground contact point U and the suspension anchor location on the vehicle frame U . The submodel for tire deflection and suspension derives the forces for the vehicle frame submodel and the location of the wheels. It will do this with the input information it has from the terrain map and the state of the vehicle frame. For example, ¡ U is the location of the suspension anchor in the vehicle reference frame. This point is a design parameter and is assumed to be constant during the simulation. The input from the terrain map is through the interaction point of the tire with the terrain. In the case of a smooth flat terrain, the contact point will always be perpendicular under the vehicle. However, when the scenery contains rough terrain (in technical terms: high bandwidth), we may need to scan the tire at different angles ¢ , so called “spokes”, for the true contact point. A model which incorporates this capability is called a multi-spoke model. The terrain map is modeled as a graphical lookup table. It can be accessed by intersectioning an arbitrary vector with the terrain sections . The terrain map will then return the 3D coordinate of the intersection point. For example, if £ U is known, then the ground-contact point £ U is found by extending the spoke from £ U , as À « £ U5m¤§© ¥ ¦ ª¨ ª¬ =® k ¡ ¯ U °z ¡ ±²³ Uy ¡ ¥ ¦µ ¢ 1º ¸ ¹ » ª¼ ¶ ´ · ¢ ½¿¾ r ª ´ Intersectioning is a service that is provided by the Silicon Graphics Performer Development Libraries (A.15) 109 Ai Â z =L +δ w S S KS DS Ãσ Å Á Bi LT+δT MW KT FZ DT Ä Ci Figure A.8: Schematic representation of the mechanical construction of the quarter car suspension model. It follows that the tire/suspension submodel needs to translate data from the terrain and the state of the frame into the anchor location and the tire-ground contact point. In other words, the vertical wheel motion, tire and suspension deflection have to be expressed as in terms of ÆUÇ and ÈUÇ . Consider the following assumptions: É Í Ê É Ë¿ÌÎÍÍ Ð É Í Ï Ç5Ñ Ï ÈUÇ ÍÍ Ê Ë¿ÌÒËÓÔ Ð Ô Ï Ç1Ñ Ï ÈUÇ Ê É ÕÌ ÍÍ Ð É ÍÍ ÍÏ Ç Í Ê ÕÌÒÖÕµÓÔ × Ð × Ô Ç5Ñ U Æ Ç Ø Ù ÌÒÖÕµÓnÊ Õ (A.16a) (A.16b) (A.16c) (A.16d) (see Fig.A.8) (A.16e) ÒË where Ú represents the spoke angle, and is the wheel radius under no-load condition. The dynamic equation of motion for the quarter car vehicle suspension system in Figure A.9 can then be expressed asÛ ÙUØ Ü Ù ÓÝ ÞLËÓàßËµá Ê É Ë1å1Ónæ ç è Ú åUÝ ÞÕµÓàß:Õá Ê É ÕåÌ ÑUé1ê âãHä ä âãHä (A.17) 110 øùUõ ú5ûýüUõ ú ø öì:÷ø ùUú5ûüUú ø öÖîµ÷ø þ ú5ûùUú ø ø1þ õ ú5ûýùUõ ú ø íLì ëì ð ë:î óò ô ï ñ õó ô ï ñ óô ï íî Eq. A.20 Eq. A.20 Figure A.9: Model for quarter car suspension translational dynamics. From this Newtonian equation, the total suspension length state space representation of the following form óô can be solved and expressed in the ÿ = ÿ ! ÿ * "" * "# $ % *& ') ( ,,, # $ % *& ') ( ! ,, + "" (A.18) This model for tire deflection and suspension is generally used to predict and control quarter car vehicle behavior, like in Louca [41]. One more step is to use Equations A.16 into A.18, in order to express ó ùUú üUú ò and . The function for ó ô then becomes òô in the trajectories of ï í ì1 2 3 4 576ûàø5ùUõ ú5ûýüUõ ú ø ÷nëì1 2 3 4 57684 öì=ûàø ùUú5ûüUú ø 6 L ó ò ô.- ð ÷ íî5ø ùUõ ú ø ÷àë:î4 öÖîLûàø ùUú5û þ ú ø 6 ô / \ 0 Now : ùUú can be expressed in terms of the rotation matrix, : ùUú - :< ì ;þ ; [email protected] > ú÷ ;þ ú 9 þ ú , (A.19) and the suspension defelction as ;8ABCED D I8LG JK M ó ôGF H (A.20) Note that the suspension deflection mechanism has only freedom of motion in the vertical ó direction with respect to the vehicle frame. As can be seen in Figure A.8, a spoke angle will employ a force in the longitudinal direction of the vehicle. 5 111 N NF Fbar FN FS bar FS FN Figure A.10: Front view of the mechanical configuration of the suspension system with lateral forces decomposition. This linear model will be valid for all driving conditions, except for a suspension rebounce, or when the wheels leave the ground. These two exceptional cases are detected with the limitations of the suspension deflection . OP In the first case, the suspension force on the chassis will consist of the force by the compressed suspension plus the forces in the tire, since it now connects to the chassis. In reality there will be considerable damping effect from the chassis deformation. This damping is not taken into effect. Q R STVUWR XT QZY\[]^0_b7` c a For the second case, as long as only by the wheel that is hanging on the chassis. , the force on the vehicle will be caused In other words, the total deflection force on the vehicle by the quarter vehicle model is given by q rsstvu w x)y zV{8| }~Z ~.~ ~ mm mm R [ pq } max . u y zV{ | } ~ ~ ~ ~Z. mm m Z ) ¡8 ¢ £ n R8e8d f g h i j T8k mm ¥ ¥7 ¡¥) ¢ ¥7 ¦ § ¤ ¨¡ ¢ £©« ªª mm 8¬®¯ mm mm ¯ mmo °±³²µ´· ¶ lmm Rebound hit Normal operation Tire liftoff (A.21) 112 A.7 Anti roll An additional force on the suspension called antiroll is introduced by the mechanical design of the vehicle to produce a counter torque when there is a roll of the vehicle. An additional “stabilizor” is usually mounted between the left and right wheel axel in the vehicle. This torque will be modeled here as an additional force at the suspension locations. The force is basically derived as a left and right suspension differential from (A.18), divided by the track width, which is a geometric constant, and then multiplied by an equivalent roll stiffness coefficient. This is written in formula as ¸7¹ º » » ¼ ½¿¾ÁÀÂÃ Ä ¼ ½Å ¸ Ã Æ Ä ¼ Æ ¸7¹ º » » ¼ É¾ÁÀÂ Ã Ä Ç¼ É¿È Å Ã Æ Ä ¼ Ê ¸ È ÈË ¸7¹ º » » ¼ Æ¾ÁÀÂÃ Ä ¼ ÆÅ ¸7¹ º » » ¼ Ê¾ÁÀÂ Ã Ä Ç¼ ÊÈ Å ÇÈË ¸7¹ º » » Ã¸ Æ Ä ¼ ½ Ã ÆÄ ¼ É (A.22) ÇÈË where and denote the track width of the vehicle for the front and rear axel respectively. in space will point in the positive -direction with respect to the vehicle Note that the vector frame. Ì Í A.8 The vehicle frame The frame or chassis of the vehicle has all six degrees of freedom. The frame is characterized by a mass which has a center of gravity inside the frame. The geometric dimensions as well as the suspension anchor locations are known properties of the vehicle. ÓÔ)ÕÖ × Ø Ù Ú Û Ü Ý Ô ÕÖ Þ ß Þ à Û Ü Ý Ô Õá ½ ÎEÏ º º º ãÌâ Ò Ñ º ãÌ ä Ò Ñ ãÌ ÐÌ Figure A.11: Model for the vehicle frame translational dynamics. The translational dynamics of the frame can be derived from the forces that act on the vehicle. These forces (including the wind and the gravity) are then integrated so that velocity and position are found. Graphically the model for translational dynamics is given in the circuit diagram in Figure A.11. For angular dynamics (roll, pitch and yaw), the torques about the rotation axes of the frame have to 113 è7 é ÷ø ù ú û ü ù þ ý ÿ û ù ü ù þ ý û û å æçè èê é ïVð ò)ó õ èZê é ô å é æö õ è êG é ë\ì èZêî é íïðñ Figure A.12: Model for the vehicle angular dynamics. be considered. Instantaneous or gyroscopic angular accelerations can then be found that have to be translated in the Euler angles. Figure A.12 shows the diagram of the model for angular dynamics. The feedback loop constitutes the centrifugal and coriolis forces. The combined dynamics for the vehicle body can be expressed in the following state space model è ê å ï ò)ó ï ð å ï ð æö ò)ó ô !" ! ï ð ò)ó å æçè è ê å & $# !" å %é å é (A.23) # where the centrifugal and coriolis forces feedback è êGë(' ï ð¿í è ê*) è ïð èê , with è , +.-/0-1 -/23+.-4 +.-15-46 (A.24) and the Euler angle transformation matrix, given in Equation C.11, in short, æö æ7/ æ71 æ74 89 æ7/ æ71:8; 7æ / <>8 = (A.25) ï ïð Avoid confusion in Equation A.23. is the unity matrix, and denotes the inertia matrix. Besides the gravity acceleration, the inputs to the vehicle frame dynamics model of Equation A.23 are the sums of all the forces and torques, projected on the frame center of gravity. The are respectively ? ? å %é å é ?A B ?A B @ ó @ ó AE FA ì å %é C D FA å %é G H ö D FA å %Jé I å D D ñ å %Jé K AL G A AE FA A FA A FA ì å M ë0å %é C D åN 0 ë å %é G H ö D å N E ë å %Jé I å D D ñ (A.26) (A.27) Appendix B Details on the Tire Slip Model In this appendix the tire mechanics model for the case of combined lateral and longitudinal slip is explained, as it was derived by Howerd Dugoff [16]. The model is derived from the classic analysis of the freely rolling tire by Fiala [19]. An application of the Dugoff model that shows a clear overview of the set of equations can be found in [18]. It is based on an idealization of the tire-road contact region geometry as shown in Figure B.1. The tire in considered to have zero inclination angle. The effects of inclination on the forces produced are accounted for approximately through the introduction of equivalent slip angle which is a function of the inclination angle and the tire’s camber stiffness. ξ Direction of wheel heading Direction of wheel travel 2 4 ξ 3 1 0 Oη 0 Oη Figure B.1: Tire-road contact patch geometry. 114 2 115 Q P’ Direction of wheel heading s carcas atch ct p a t n co ξ tan α 3 P α 0 Direction of wheel travel sξ ξ’ ξ Pη Figure B.2: Strain condition in non-sliding portion of the contact patch. B.1 Theoretical Derivation The line 0-1-2 in Figure B.1 is the longitudinal centerline of the tire-road contact patch. The ground plane coordinate system R - S has it’s origin at the tread touchdown point. From there the R -axis passes through 2, being the liftoff point. Line 3-4 represents the longitudinal centerline of the tire carcass. Each point on the carcass centerline is assumed to be elastically connected to the tread (line 0-1-2) through orthogonal springs that produce independant forces in the R and S directions. Thus a point on the tread follows the path of the carcass as long as no shear fore acts on it. In particular, points 3 and 4 lie on the vertical lines passing through the touchdown point 0 and the liftoff point 2, respectively. Point 1 on the tread centerline represents the “sliding boundary”. Points on the tread forward of point 1 (segment 0-1) make contact with the ground without sliding. At point 1 the elastic stresses due tread deformation reach the shear stress limit and the rubber begins to slide, relative to the ground. The shear deformation along line 1-2 is a function of the local sliding friction potential. It drops off monotonically, towards zero at the liftoff point 2. In Figure B.2 a situation is sketched of a typical point T$U RWV SYX in the non-sliding part of the contact patch, that shows the hypothesized deformation. The longitudinal coordinate of T is equal to the product of the tire’s longitudinal velocity ZY[ and the time interval \^] , from the instant when T entered the patch at 0, to the instant as shown in Figure B.2, i.e. R^_`ZY[J\^] (B.1) During the same time interval, point T7a on the carcass centerline (which coincided with point 3 at the start of the interval) has moved a distance R a , given by R a _`b*ced \^] where b is the wheel spin velocity and ced (B.2) stands for the effective rolling radius of the tire. The 116 longitudinal deformation of point f , relative to f7g is given by p*res hjih gYk`lYmJn^o iqp*res n^otkvuYw i lYm`x lYmJn^otk`y h (B.3) i}|:~W where y*k{z w ^ is, by definition, the longitudinal slip ratio. So the longitudinal component of stress at point f is equal to Y h k` $ y (B.4) where $ is the longitudinal tire stiffness in pounds per unit length, per unit width, per unit longitudinal deflection. The lateral deformation of f is given by (see Figure B.2) where to k i.h. (B.5) is the angle between heading and actual travel. The lateral stress component at f is equal Y k i $ J h (B.6) where $ holds the lateral stiffness in pounds per unit length, per unit width, per unit lateral deflection. YJsheer The maximum allowable total stress at any point in the contact patch is determined by the tire-road shear YJstress limit, , which varies over the contact patch. One of the main factors is the normal pressure distribution over the patch. For simplicity a uniform determining pressure over the patch is assumed, with a value given by k J where is the normal load on the tire, and J The shear stress limit accordingly becomes YJ (B.7) are the length and width of the patch respectively. k} k J (B.8) where is the coefficient of friction at the interface. With this equation for the maximum shear stress, we YJ can determine the sliding boundary point 1 in Figure B.1 where the elastic stress just equals , as J YJ . h k k J (B.9) Let denote the longitudinal coordinate of the sliding boundary point. Then, substituting from equations B.4 and B.6, we obtain w h k J J y $ $ (B.10) 117 Let ¡ £¢ denote the longitudinal coordinate of the point on the tire carcass associated with point ¡ £ , then from equation B.3, ¢ ¤¦¥ §¨q© ª ¡ £ ¤¦¥ §¨q© ª «.¯ ¬ ° J± ® ¬ ² ¡ £. § ¥ ³$´ © ª µ¶·¥ ³$¸>¹ º J» ¥ ¼ª ª µ (B.11) The actual deformation field of the sliding portion of the patch is approximated by a uniform deformation, in order to compute the resultant shear forces by a closed-form integration. Although compatible with the assumption of a uniform normal pressure distribution, this approximation is obviously considerably in error at points in the rearmost portion of the contact patch. With this assumption, the values of the longitudinal and lateral tire shear forces and J½ J¾ may be computed as follows Ã ¤`¿}À Á J ½ Â ÀÁ where from equations B.3 and B.4 µÊ ± ½ ÄÅ ¥ ¡ ¢ ª É ¡ ¢ ( ¿ ÆÈ ¶ ¿ Ç ½ Ç ½ ¥¡ ¢ª É ¡ ¢Ë É ½ ÄÅ (B.12) ³$´ © ¡ ¢ Ï for ¡ ¢JÒ ¡ £¢ § ¨Ñ© * Í ¤ Î Ì Î Ç ½ ³$´ © ¡ £¢ for ¡ ¢JÓq¡ £¢ ¨ © ÎÎÐ §*Ñ and Ã ½ ÄÅ ¥ ¡ ¢ ª É ¡ ¢ ¶ ¿ µ Ê ¥ ¡ ¢ ª É ¡ ¢ Ë É ± Å ¤ ¿}À ¿ ÆÈ Ç ¾ Ç ¾ J¾ Â ½ ÄÅ ÅÀ where from equations B.3 and B.6 ³$¸J¹ º »¼ ¡ ¢ Ï ¨ §*¨Ñ© ¤ ÌÎÎ $ Ç ¾ Í ³ ¸J¹ º »¼ ¡ £¢ ¨ §*¨Ñ© ÎÎÐ for ¡ ¢ Ò ¡ £¢ for ¡ ¢>Óq¡ £¢ (B.13) (B.14) (B.15) Note that the stress distribution is assumed to be uniform with respect to the contact patch width. Thus solving B.12 and B.14 and integrating along the patch width gives ¯ ° µ ± ³$´ © ¢ Ô ¯° Ï for ¡ £ § * q ¨ © ¤ ÌÎÎ ¯ ° ± $ Í ³ ´ © ¡ £¢ ± ³$´ ©:¥ ¡ £¢ ª µ J½ ¨ ¯ ¢ Õ ¯° for ¡ £ * § Ñ ¨ © ¥ § q ¨ © ª ÎÎÐ ¯ ° µ ± ³$¸>¹ º »¼ Ï ¨ §*¨q© ¤ÍÎÌÎ ¯ ° ± ³$ ¸W¹ º »*¼ ¡ £¢ ± ³$¸>¹ º »¼¥ ¡ £¢ ª µ J ¾ ¨ ¶ ¯ ¥ §¨q© ª §*¨Ñ© ÎÎÐ (no sliding) (B.16) £¢ Ô ¯ ° ¯° for ¡ £¢ Õ for ¡ (no sliding) (B.17) The derived results can be rewritten more consisely in terms of the following auxiliary variables ¼Ö ¤ ¯ °µ± $ ³ ¸>¹ º »¼ ¥ §*¨Ñ© ª «.¬ J® ¬ (B.18a) 118 × ÙÛÚ Ü Ý Þ7ß$à Ø Ø7 á.â ãJä:â å æçÑØ è Ø × éêÙ`ë Ø × í× Ýì Ý (B.18b) (B.18c) × Note that the variable Ø é may be considered to constitute a “resultant normalized slip vector”, × × whose components are í and Ø . Equations B.18 may be used together with Equation B.10 to rewrite B.16 and B.17 in the form Jã î á.â ãJä ãJï á.â ãJä where Ø × ãJé Ù × â Øé . á â ãJä â í × Jã é Ù × â Ø é á.â ãJä â Jã é ñ ò Ø× é æ ÙÍð * æ ç ø × á.â ãJä â Øé (B.19) (B.20) Ø× Ñ é óõôYö ÷ × for Ø éÑùõôYö ÷ for (B.21) Note from equations B.18c, B.19 and B.20 that the quantity ãJéêÙûú ã î Ý ì ã ï Ý (B.22) represents the resultant shear force exerted at the tire-road interface. Equations B.19 and B.20 may be rewritten in terms of the tire coordinate system as follows Ø × ãJé Ù × â Øé . á â ãJä â ×í Jã é Ù â Ø × é á.â ãJä â Now let us consider for a moment the special case when íêÙ`ô ã àü á.â ãJä ãJý ü á.â ãJä (B.23) (B.24) . For this case, Equations B.18 and B.21 may be used together with Equation B.23 to obtain whence, using Equation B.18b, But, by definition, ã Ùûç Ø × àü á.â ãJä â þþ þþ ÿ for Ø × éÑóõôYö ÷ ã Ù ç û àü Ø Ú Ü Ý Þ7ß$à þþ þþ ÿ ã Ù ç Øà ü þ û þ þþ ÿ (B.25) (B.26) (B.27) where is the longitudinal tire stiffness. Equations B.26 and B.27 may be used to rewrite Equation B.18b in the form × Ù Ø7 Ø á.â ãJä:â å æçÑØ è (B.28) 119 Similarly, by considering the case , we may show that Equation B.18a is equivalent to ! """ #%$ #%& " where (B.29) (B.30) The tire-road friction coefficient is known to be a function of sliding speed and normal pressure, as well as of a host of quantities describing the material and geometric properties of the road surface and any interface contaminents. The farmost important effect is that of speed, which can be approximated by a simple linear equation of the form where the total sliding velocity )*$ & (' $ )*$ (B.31) is given by )*$ + !, -/. - (B.32) The influence of tire inclination i.e. camber angle, remains to be taken into account. a simple linear expression for the equivalent slip angle is given by 1 /0 *2 41 3 2 1 3 is an empirically derived property of the tire. where the relative camber stiffness (B.33) B.2 Applicable formulas For the vehicle simulation, we will need equations B.28 and B.29. In addition, to calculate these two, we also need Equations B.31 and B.32. Assume we know the longitudinal and lateral slip, then also the slip angle can be calculated. With this and the wheel spin speed also the slip ratio can be derived with Equation B.3. With this, first the Equations for longitudinal slip ratio, slip velocity and friction will be calculated as 65 879;! : < (B.34) + )*$ + ! , -/. & (' $ )*$ (B.35) (B.36) With these auxiliary variables, the longitudinal and lateral slip coefficient can be calculated by using Equations B.28 and B.29. Also the total normalized slip can be derived with Equation B.18c, recall $ (B.37) = 120 Slipangle 200 150 100 Slipangle 150 0 15 30 45 0 15 30 45 100 Lateral Force (µ.Fz) Longitudinal Force (µ.Fz) 50 50 0 −50 0 −50 −100 −100 −150 −150 −200 −1 −0.8 −0.6 −0.4 −0.2 0 Slipratio 0.2 0.4 0.6 0.8 1 −200 −1 −0.8 −0.6 −0.4 −0.2 0 Slipratio 0.2 0.4 0.6 0.8 1 Figure B.3: Longitudinal and lateral normalized slip forces for different slip angles across slip ratio. > > E F G ?> ?A> @C B D HI JK I L MN(O P O [email protected] S O T/U ?/T (B.38) (B.39) The above Equations will be the basis for deriving the effect of slip on the motion of the vehicle. They are all normalized and depend on road friction, tire stiffnesses, and quantities describing the material and geometric properties of the road surface and any interface contaminants. To convert these coefficients to the actual shear> forces, we need one more > step where we multiply with the normal pressure of the tire on the road surface. /J V W X Y Z [;@]_ \^ ^` J/V W X Y Z [email protected] _ \^ > > > If we substitute for O , ? and O Q ^` > O > HI JK=I > M O O> Q H(fgMN h O Qi I JK I > ?/> HI JK I > ? H(f%MN M I JK I hOQ i OQ for O > Q(acb%d e for O > Q(jcb%d e for O > Qlacb%d e for O Qljcb%d e (B.40) (B.41) > then this can be written in a more direct way, as VO BM( > > _ J/V W X Y Z [;@ \^^ N O V O B O P O Q %f MN h O M Q i L M l N ^` BDME N(F G O ?> > _ J/V W X Y Z [email protected] \^ ? f M Q i ^^` L BMDNlE F O G P O Q MN h O for O > Qlacb%d e for O > Qljcb%d e for O (B.42) > Qlacb%d e for O Qljcb%d e (B.43) 121 Wheelspeed 200 50 100 50 z z Longitudinal Force (µ.F ) 100 0 48 96 144 192 240 150 Lateral Force (µ.F ) 150 Wheelspeed 200 0 48 96 144 192 240 0 0 −50 −50 −100 −100 −150 −150 −200 −50 −40 −30 −20 −10 0 10 Slipangle (deg) 20 30 40 50 −200 −50 −40 −30 −20 −10 0 10 Slipangle (deg) 20 30 40 50 Figure B.4: Longitudinal and lateral slip against slip angle. a Sweep analysis for slip ratio and slip angle can simulate the model and will give an impression of the behaviour of the resulting shear forces. Figures B.3 and B.4 show that the model output compares well with the graphs belonging to the Dugoff slip model, which are shown in [16]. The simulation can be represented in another form, where m%n is plotted against op;q . This is shown in Figure B.5 where the vertical axis represents the vehicle velocity m%n and the horizontal axis represents the wheel spin velocity op;q . Notice that the graphs show the normalized shear forces in the vertical axis. A complete study can be done for different nominal r -coefficients and tire stiffnesses and other parameters, to tune the curves accordingly. The paper of H. Dugoff is referred to for more intensive study. B.3 Considerations The principal simplifying assumptions involved in the tire mechanics analysis are as follows 1. Dynamic effects are negligible. This means that the dependance of the tire shear force on the time derivatives of the kinematic variables is not significant. 2. The deformation of the carcass centerline is constant throughout the contact patch. For the freely rolling tire Fiala assumes that the carcass centerline behaves as an elastically supported beam. 3. The deformation of the thread centerline is the resultant of two independant orthogonal components. 4. The vertical load supported by the tire is evenly distributed over the contact patch. This assumption is fairly realistic, except for the edges of the contact patch. 5. Aft of the point at which sliding between tread and road begins, tread deformation remains uniform. This greatly reduces the mathematical complexity of the analysis. This assumption 122 Polar representation of the Dugoff friction model 4000 3000 2000 vv 1000 0 −1000 −2000 −3000 −4000 −4000 −3000 −2000 −1000 0 v 1000 2000 3000 4000 w Figure B.5: Polar representation of the longitudinal and lateral slip. causes a slight error in the direction of the shear force. 6. The interfacial friction coefficient is independant of normal pressure and is a linear function of the relative sliding velocity. Appendix C Coordinate Systems In this Appendix presents the coordinate systems and transformations for the geometry of the chassis and wheels. There are many schemes for coordinate systems depending on the discipline and applications. We will adopt the coordinate frames shown in Fig. C.1. The coordinate system is widely used in aeronautical engineering in the analysis of missiles and space vehicle [22] as well as by the Society of Automotive Engineers in automotive engineering in the analysis of automobiles [24]. For ease of reference and tractability, we adopt the following notation for a vector t . s Ref. Operation Fn,Corner t s and a matrix Operation To frame For example, when the i-frame i rotated with respect to the o-frame, then vector u will be defined in the o-frame as w v in the i-frame w vx y u u v;x yz u v and a force vector for v { | | in the vehicle reference frame } w (C.1) for corner ~ will be denoted by (C.2) C.1 Displacement Coordinate Transformations The following vectors are related to each other through translation and rotational transformation. Referring to Figure C.1 we have 123 124 X1 Displacement Variables x: translation along X 0 (Latitude or side to side) y: translation along Y1 (Longitude or fore -aft) z: translation along Z2 (Elevation or heave) : rotation about Z3 (Heading or yaw) : rotation along Y4 (Attitude or pitch) : rotation along X5 (Bank or boll) O1 x X0 O0 y Y1 fx Z1 fy Z2 R-frame z fz Forces and Torques f x : force along X 0 f y : force along Y1 f z : force along Z2 : torque about Z3 : torque along Y : torque along X Velocity Variables x: linear velocity along X 0 y: linear velocity along Y1 z: linear velocity along Z2 : angular velocity about Z3 X3 O3 Y2 Y0 Z0 X2 O2 : angular velocity along Y Y3 4 Z3 , , 4 5 Note: The origins O3, O4, O5 and O6 are the same point in space. They are drawn as separate points here to illustrate the Euler angles. O4 : angular velocity along X5 and are the Euler angles. and are the Euler angular velocities. X6 X4 Y4 Z4 O6 X5 O5 Y6 R-frame: Reference Frame B-frame: Body-attached Frame Y5 Z5 Figure C.1: Coordinate frames from reference to body. Fi gure A. 1 Coordi nate Fr ames fro m Ref erence to Body Z6 B-frame 125 4 £ £ ± ± ¶ ¶ 44 ¡ ¢¡l£ ¤ ± ¦¥ § ¨*©«ª¢¨ ¬ © ¨ ¬ ©®¥ § ° ¨g© ¯ £ /± ± ¶ ¨*³ ¯µ ¨ ¬ ¥ § ´ ³ ª¢¨ ¬ ³ ¥ § ¨*³ ¶ ¶ ¯· » ¥ § g ¨ ¹ ¸ ¢ ª ¨ ¬ ¸ ¨ ¬ ¸º¥ § ¨g¸ » £ (C.3) The overall translation of a point ¼ with reference to the ½ -frame in the given by À % Á%Â ¡ ¾ where » » » £² ± ± £² ± ¶ ¶ ² ¶ » » ² ½ ¾¿ (C.4) (C.5) (C.6) coordinate system is (C.7) ± ± ¶ ¶ » ¦ ³Ãª¢¨ ¬ ©4¥ § ¨*¸ ¥ § ¨*©¨ ¬ ³/¨ ¬ ¸º¨ ¬ ©¨ ¬ ¸ ¥ § ¨g©¨ ¬ ³/¥ § g¨ ¸ £ ² ¥ ¨ §¬ ¨*© ²©¥ ¥ § § ¨*¨g² ³C ¥ § ¨g©¥ § ¨g¸ ¡ ¨ ¬ ©¨ ¬ ³/¨ ¬ ¸Äª¢¥ § ¨*©4¨ ¬ ¸ ¡ ¨ ¬ ©¨ ¬ ³/¥ § *¨ ¸ ª¢¨ ¬ ³ ¥ § ¡ ¨*³/¨ ¬ ¸ ¥ § ¨g¡ ³/¥ § ¨*¸ ÆÅ £ Ç Èc£ Ç ÉÊ£ Ç Ë Ì Íª ª whose columns are unit vectors along the axes of the Î ¾ ¿ frame, when reference from the Ï Ð Ñ frame. Since the rotational matrices are orthogonal, we note that ± ± ± ¶ ± ± ± ± ¶ » ² £¶ £¶ ²¦¶ÒgÓ £¶ ²Ô » ² ²¦ÒgÓ ²Ô ² ²¦ÒgÓ ²Ô £² and 126 Õ Ö×ØÀÕ Ö¦× ÙgÚ Ø × Ö Û Õ ØÀÜ ÖÛ ÕÝ Ö ÛÜ × Ö Û Ø¤Õ Ö Ü Ü Ö Ý Ö× (C.8) Ý Ý where the superscript Þ denotes the transpose operation on the matrix. We should note that ßÖ Õ Ø ×Ö Õ (C.9) C.2 Angular Velocity Coordinate Transformation Two equivalent vectors can be used to describe the angular velocity of a body B. They are: 1. 2. æ Õ à/á is the angular rates of the â Ø ç ê é ë é ì/é í Û à/á è -frame with respect to the ã äå frame, is the Euler angular rates as can be seen from Figure C.1. There are many ways to transform from instantaneous angular rates to Euler rates [15]. The angular velocities of the ã ä å frame can be expressed in terms of the Euler angles and angular rates as follows Õ4îïð à/ñ Õ à/á Ø à/ò ØÀÕ Ö à/ó¢öô õ îïð¢ù ÷ ÷ÿþ û ê Ø ÷Ãú¢û ü ý ê Ø Õ à/á æ æ Ü ÜÖ Ý ú¢û ü ý û üý ê þ þ û ê þ Ý Ö× îïðR÷ ÷ öô õ ø ìé ¢ îïð ê é ë û ë ëé û ë öô õ ì é öô õ ÕÖ Ü ÜÖ Ý îïð4÷ îïð ê é ë é öÍø Õ Ö Ü ÷ ö ÷ ôõ ÷ ôõ where the transformation matrix is îïðÍù Õ Ø ÷ ÷ æ ÷ þ û ê ú¢û ü ý ê ú¢û ü ý ë û üý ê þ û ë þ û ê þ û ë öô õ Conversely, we can show that the Euler angular rates are related to the ã îïð ê é îïðÍù û ü ý ê þ û ê à/á Ø ëé ö Ø ÷ æ ÷ û üý ê û ì é ôõ ØÕ gÙ Ú Õ à/á Ø Õ æ æ (C.10) äå frame rates as ý ë þ û ê ý ë Õ4îïð /à ñ ú¢û ü ý ê /à ò þ ë þ û ê û þ ë öô õ /à ó¢ôö õ Õ à/á 127 where +, $ ! " # (C.11) " % &' $ ( ) * " % ) Note that we can determine the angular velocities of the . / 0 frame with reference to the 1 2 3 frame as follows 4 4 56 57 + , 5 7 + , 5 8 4 : 5 6 4; < 7=< 8>< 9 ? 5 8 59 5 9 - (C.12) C.3 Angular Displacement The Euler angles (roll, pitch and yaw) are simply given by @ 6 =A 56CB D (C.13) where @ 6 ; =E ?F (C.14) C.4 Linear Velocity Coordinate Transformation The linear velocity of the 1 23 $ / 0 frame is KI +, G H 4 G%J I L I 2 MI frame with respect to the while the linear velocity of a point N on a rotating 1 by PJQ BD 4: 4JQU B BD P IH 4VT 4 : W 4 J Q T 4 : B P H Q P JIQ BSR P J 4T 23 frame with respect to the O B R 4: U 4 Q 4: B 4JQ PJ4 S J T BD T BD BD H Q (C.15) /0 frame is given 128 Euler Angles Only three differential equations are needed Direct initialization from , and X Y Z Direct cosines Differential equations are linear No singularities Transformation matrix can be calculated directly Quaternions Only four linear coupled differential equations are needed No singularities. It avoids the gimbal lock problem associated with Euler angles Computationally simple Differential equations are non-linear Singularity occurs as the angles apo proach which is called Gimbal Lock Transformation matrix is not directly available Order of rotation is important Nine linear differential equations (reducible to six) Euler angles are not directly available, which is required for initial calculations Computational burden [\ ] Initial calculations using the Euler angles is required if coordinate systems do not coincide at Euler angles are not readily available ^_`] Transformation matrix not directly available Table C.1: Advantages and disadvantages of the three most used transformation methods. where the useful relationship below for the time derivative of the transformation matrix }~ has been used. aSb#c dSe f c dSejVklj a gih hmnoqpsrtuvtw tuxpyrtz rtw{tz|p (C.16) C.5 Coordinate Systems Since the direct cosines transformation is computationally intensive, it is disadvantageous for the real-time application of VVSS. Like the quaternion method, it also has the Euler angles not readily available. The latter argument is decisive for the engineering aspect of the VVSS. 129 The transformation matrix is not directly available for Euler angle transformations, but is computed throught the Silicon Graphics hardware facility. Appendix D Software Reference This appendix explains the use and operation procedure of the VVSS. The software is merely a collection of codes that implements the functionality of simulating vehicle dynamics through SPINE. The following sections are structured chronologically. After the layout of the relevant files and folders, the usage and features of the software are explained. The last section will illustrate the use of the VVSS and SPINE in conjunction with Simulink, to analyze and design vehicle subsystems. D.1 File Structure The simulation platform that is presented in this dissertation is implemented in a software application that resides in a series of folders. The VVSS is implemented in a Silicon Graphics computer. The application folder contains the source codes plus a makefile, that is used for building the executable code. The subfolder /scene contains the geometry files for the graphical virtual realistic environment. This directory structure is crucial for the simulator to operate. The parallel simulation through SPINE is implemented for Simulink. However, the connectivity and protocol between in SPINE allows for many operating systems and simulation software tools that support TCP/IP, to communicate with the VVSS. Appendix E details about the handshaking and protocol that is needed to develop the interface drivers. The software structure for Simulink is not strictly defined. The minimum requirement is that the source code and the library for the SPINE driver need to be in the matlab search path, when a simulation is started. A simulink library called vvsslib (See Figure D.2) is provided which contains the necessary blockset to develop subsystems for the VVSS. When the force wheel 130 131 peripheral control block is used for user inputs to the vehicle simulation, then also the source code and library for the peripherals driver need to be in the matlab search path. Table D.1 shows the list of files that are associated with the VVSS and SPINE. Filename towndyn.C vd.h plugins.h cb.h perf.h fw.cpp fw.dll splugin.cpp splugin.dll map.mat vc.m console.m road.m road.asc Description Source code for VVSS. Contains the vehicle dynamics code. Include file for the VVSS with the initialization of the vector table and vehicle parapeters. VVSS header file with SPINE communication functions and the functions and initializationfor the graphical user interface VVSS header file with driver routines for the Cereal Box VVSS header file with graphcs scenery definition routines Force wheel driver source for Simulink Force wheel driver dynamic link library SPINE driver source code for Simulink SPINE driver dynamic link library This file is used with the navigation block in the library Matlab script used with the navigation block in the library Matlab script used with the dashboard in the library Matlab script to generate a test-track definition file Test track definition file for default world scenery Table D.1: The list of file names with a short description, of the files that are associated with the VVSS and SPINE. The VVSS software furthermore uses support from the xforms library and the Performer graphics developing environment. D.2 User Interface Each user on the Silicon Graphics host computer that executes the VVSS, can start the simulator by typing VV on the command line. The command will change the prompt to the application folder /usr2/VVSS/. From there it will execute the vehicle simulation. Command Line Options Command line options are a series of space-separated specific characters with a trailing dash and optionally an additional property value. These characters access features and properties that can The Cereal Box is a product of BG Systems, Inc. 132 be selected to configure the simulation at startup time. The following paragraphs summarize the available options and their meaning. -b Block VVSS communication. If this option is provided, the VVSS will wait for the parallel processes that are connected to the VVSS through SPINE, each frame, before it continues to simulate. -u # Define the subsampling . Subsampling # is the amount of simulation cycles that are computed per frame. The graphics update and the data exchange through SPINE takes place once per frame. Setting ' , together with the option ‘-b’ will guarantee the data exchange through SPINE at each integration step. -f Full screen display. By default the VVSS will display the animation in a resizable X-windows frame. -3 Display the animation in stereo vision. Make sure that the stereo scopic goggles are in line-ofsight with the synch. emmitters. -i # Set the interocular distance of the eyes for stereo vision to #. Only effective with option ‘-3’. -c # Set the convergence ratio of the left and right eye for stereo vision to #. Only effective with option ‘-3’. -s Small video (for remote simulation studies) -g Add Graphical User Interface in Figure D.1. By default the GUI will not show up. -w # Load virtual world number # at initialization time. The option ‘-w’ for world environment, will load one of the sceneries in the animation of the simulation output. The geometry data for the sceneries resides under the folder /scene/ in the application folder. If the option ‘-w’ is not provided, a flat terrain is loaded, with an optional road surface trajectory defined in the file road.asc. Section D.2 explains in more detail about the trajectory file. -h Short command line help that will diaplsy the command line options. Key Press Functions When the simulation is active, certain keys have special functionality for the simulation. Table D.3 shows a summary of the available functions for keys. Further development of the VVSS will include key-press functions for re-loading a test-track in the virtual scenery and for re-configuring the vehicle to another platform in run-time. 133 Index 1 2 3 4 5 6 Scenery The “Performer town” demonstration model A stripped down version of the “Performer town” model Formula 1 racetrack Large rugged world scene Simple city of San Francisco with Bridge 20 Miles of Country, city, village and highway Table D.2: Available command-line options with the functionality. Key v s g f .. Function Toggle the graphics viewpoint from the driver’s view to a chase view Statistics for the simulation and graphics are available with this key When the command line option ‘-g’ is provided this key toggles the GUI Toggle Fog in the virtual scenery. Fog is configured in the source code Move C.G. to the front in the vehicle Move C.G. to the back in the vehicle Move C.G. to the left in the vehicle Move C.G. to the right in the vehicle . The first four function keys restart the simulation in another location Esc Spc The Escape key exits the VVSS. All SPINE connections will be closed. Pressing the Space-bar will dump the current position and heading Table D.3: Available Key-press options with the functionality. 134 Figure D.1: Image of the graphical user interface for the Virtual Vehicle System Simulator. Graphical User Interface The command-line option ‘-g’ adds the feature of additional graphical user interface (gui) controls to the VVSS. The interface controls will initially be hidden behind the scenery, but can be brought to the front by pressing ‘g’ (toggle). A screen shot of the gui is shown in Figure D.1. The upper area serves as an indication for the active parallel processes on the VVSS through SPINE. Three indicated buttons are available for toggling statistics, fog and driver’s view. These features are available via key-press functions as well (resp. ‘s’, ‘f’, and ‘v’). The right side of the gui provides a slider for changing the sprung mas of the vehicle and for changing the -coeficient (friction) of the terrain. (The third slider is not yet assigned). In the bottom of the gui is an ‘Exit’ button that terminates the simulations. Simulation Definition Files The default virtual environment is a world scenery with a flat terrain, bounded at considerable distance with a mountain range. A configurable test-track can be added to the terrain. The track is defined in the text file road.asc, in three columns for road center coordinates , and an altitude. The file must be located in the subfolder /scene/testtrack/ of the application folder of the VVSS. The road will be 10 m| wide and will be created as polygons that connect the road points. As a sample, 135 Road : Sine Wave. Mu = 0.9 0.000000 0.000000 0.000000 1.000000 0.000000 0.003365 2.000000 0.000000 0.013308 3.000000 0.000000 0.029384 4.000000 0.000000 0.050870 5.000000 0.000000 0.076804 6.000000 0.000000 0.106022 The file road.m is a Matlab script file that will generate a test-track file and store it in the appropriate folder for the VVSS. It will be possible to re-configure the test-track in future revisions of the VVSS. Other extensions to the VVSS will provide for a configuration file for the vehicle and for the virtual scenery. The configuration file for the vehicle will have the name of the vehicle with extension .def and hold the parameter values that characterize a particular platform. The system will be able to load another vehicle configuration file in run-time. D.3 Prototyping with Simulink A Library with a blockset of communication modules for SPINE is provided for designing subsystems in Simulink. Figure D.2 shows the blockset. Read Scalar Connection input for reading a scalar value from the VVSS. In the property dialog box is an input for the index value that represents the value that is to be read. Write Scalar Connection input for sending a scalar value to the VVSS. In the property dialog box is an input for the index value that represents the value that is to be sent. Read Vector Connection input for reading a vector from the VVSS. In the property dialog box is an input for the index value that represents the vector that is to be read. 136 Virtual Vehicle Systems Simulation VVSS Read Read Scalar Shift Up Shift Down VVSS Write Write Scalar Mini World Button Right Navigation Map Button Left VVSS Read Lever Right VVSS Write INFO Lever Left Read Vector DASHBOARD VVSS Dashboard Force Wheel Control Write Vector Components Information © 1998 Oakland University. By G. E. Smid & Ka C. Cheok Department of Electrical and Systems Engineering General Dynamics Laboratory Figure D.2: The VVSS library in Simulink with the blockset that provides the necessary functionality for SPINE. The output of this block is a 3x1 vector. Access the individual values by de-multiplexing the signal first. Write Vector Connection input for sending a vector to the VVSS. In the property dialog box is an input for the index value that represents the vector that is to be sent. The input of this block must be a 3x1 vector. Combine the individual values by multiplexing the signals first. Dashboard A simple dashboard console can be added to the user interface in Simulink. The dashboard contains a speedometer and a gauge for rpm. When this block is inserted in the Simulink diagram, the file console.m must be available in the Matlan search path. Force Wheel Control The Saitek Forcewheel can be used as an input peripheral for the vehicle simulation. The block can be inserted into the Simulink diagram without any further configuration. The files fw.cpp and fw.dll must be in the matlab search path. Navigation Map The Navigation map can be inserted in a Simulink diagram, to study navigation and inertia systems. It will display a graphical map of the world, with a white trace that 137 represents the location of the vehicle. The files map.mat and vc.m must reside in the Matlab search path. Only world 1 or 2 are supported for Naviagtion map at this time. Components Information This is an online information block, which contains the component index. It is a reference to the engineer when designing a Simulink model. The possible index values and their is also listed in Tables E.3 and E.4. The model in Simulink will receive values for the input parameters and states through SPINE from the VVSS at each frame interval. The VVSS is currently configured to compute 7 cycles with an integration step of 0.004 seconds per frame. The Simulink model will thus communicate at an integration step size of 0.028 seconds. Currently this value is not configurable. Further development of SPINE will allow the VVSS to configure the SPINE driver module to configure the Simulink model with the appropriate interval size. The SPINE driver module will configure an independant fixed clock cycle in Simulink. Therefore the user will be more free to configure the integration method and timing in Simulink. The user is limited in the way that a fixed integration interval must be either a multiple or a divider of 0.028 seconds. Appendix E Development and Implementation The simulation structure that is presented in this dissertation involves many aspects of software implementation. For the purpose of reference and development, the sections in this appendix will present the construction and functionality of the various software components, implementation of the software, communication protocols, parameters and vehicle dynamics. E.1 Geometry models Section 5.5 explained the global geometry structure, as it is represented in the animation part of the software. Geometry models are simply loaded in memory and added to the graphics models tree structure. The following code example illustrates how this procedure takes place. pfFilePath("./scene"); pfdInitConverter("myworld.flt"); shared->town = (pfGroup *); pfdLoadFile("myworld.flt")); shared->root->addChild(shared->town); The pointer shared-> points to an area of allocated shared memory where the graphics models reside. A series of different data file formats can be used for the geometry models. Table E.1 lists the allowable formats. Geometry models can be designed with a variety of applications. Among them are products from MultiGen, ViewPoint, Coruphaeus, Pro-Engineer, AutoCad and Silicon Graphics. The models that are currently used for the animation of the vehicle dynamics are part of the Performer Development sample library. Future additions to the VVSS will provide for a more flexible scene definition file, in which the available world sceneries can be defined. 138 139 File Formats Coryphaeus Imagis Inventor Viewpoint MultiGen Unigraphics Autocad Paradigm Silicon Graphics Objects Virtual Reality Macro Language dwb iv iv flt dxf pfb iris obj vrml Table E.1: Overview of the file formats that can be loaded into the geometry tree of VVSS. E.2 Initialization procedures This section will consist of a walk-through of the initialization procedure of the VVSS. A number of data structures have to be configured and tasks have to be performed before the VVSS can start executing the main simulation cycle. First, the command line options need to be interpreted. Internal variables will be redefined from their default values to provide the requested options. If the VVSS code has been compiled with the support for the Cereal Box, then the serial port will be initialized and communication with the peripheral will be established To reset the Cereal Box, the VVSS will send a ‘T’ to the serial port. Then a bit-pattern will be sent to the port which represents the input-output data exchange format, to reflect the signals that are needed for the vehicle dynamics as inputs. The VVSS then allocates memory for the values of parameters and states of the vehicle dynamics. In conjunction with each memory location, a vector will be assigned to it, and referenced in the Component Library Index . The functionality of the Library and the vectors was presented in Chapter 5. Additionally to allocating the memory, the VVSS will assign default values to the vehicle parameters. Future revisions of the VVSS propose to store these default parameter values in a vehicle definition file that will configure the vehicle dynamics parameters, such that they characterize a particular platform. 140 A special set of commands are available in the Performer Development Library, that help to setup the graphics scenery and prepare the hardware for animation. The following code example illustrates a general initialization phase. pfInit(); pfMultiprocess( PFMP DEFAULT ); arena = pfGetSharedArena(); shared = (SharedData *) pfMalloc(sizeof(SharedData),arena); pfConfig(); pfiInit(); shared->scene = new pfScene(); shared->root = new pfGroup(); shared->dcscar = new pfDCS; /* Configure GL window and setup stereo */ p = pfGetPipe(0); pfFrameRate(FRAME RATE); pfPhase(PHASE); pw = new pfPipeWindow(p); pw->setWinType(PFPWIN TYPE X); pw->setName("Virtual Race Track"); if (CLfull) pw->setFullScreen(); else pw->setOriginSize(0, 200, 1100, 600); pw->setConfigFunc(OpenPipeWin); pw->config(); When the graphics object tree structure has been defined, the dynamics coordinate systems can be adjusted in the simulation loop, with the following commands. 141 Body2Wheel.makeEuler(theta w, 0.0, omega w); Body2Wheel.postTrans(Body2Wheel, x, y, z); shared->wheelCS[i]->setMat(Body2Wheel); Vehicle2Earth.preTrans(x, y, z, Vehicle2Earth); shared->dcscar->setMat(Vehicle2Earth); shared->view.hpr.set(alpha[PF Z], beta[PF Y], gamma[PF X]); shared->view.xyz.set(x, y, z); The simulation must be initialized, before the VVSS can render the first graphic state of the solution to the vehicle dynamics model. This task involves the initialization of the states and transformation matrices and the scene viewpoint. If the user has selected the option ‘-g’ for the graphical user interface (See Figure D.1), it will be initialized at this point. The VVSS makes use of the xforms library to design the interface in a X-window. Besides rendering the user controls, also the functions will be setup that will provide the run-time functionality of the GUI. The key ‘g’ can be used to toggle the GUI to be in front or behind the animation. The command pfFrame() will be issued to render the first scene. The final task before entering the simulation process is to initialize SPINE. This task involves the configuration of the network protocol for TCP/IP and setting up a service to a custom port that is user for SPINE only. The following code example shows briefly the initialization procedure. Additional information on controlling the network communication adaptors with TCP/IP protocol can be found in [60]. The exact sequence of the initialization steps is not strictly defined. However, some tasks need other tasks to be completed, which makes the presented process not arbitrary. E.3 Main algorithmic cycle When the initialization process has been completed successfully, the VVSS will start executing the main simulation loop. The loop will only break, when the Escape key or the exit button in the GUI is pressed. The simulation loop is executed at the frame rate for the video rendering. The task list inside the frame cycle is as follows: 142 When the Cereal Box is used for communicating user inputs to the simulation, it is accessed here to receive new input values. Compute the new solution of the vehicle dynamics. Execute this task times, where holds the value for supersampling. Update the coordinate system for all dynamic components in the graphic scenery. Rendering these updates encompasses the animation of the solution of the simulation. Process the communication task with parallel simulations on SPINE. – Communicate with the simulation processes that are running in parallel with the VVSS. The communication involves sending the current solution for the states that are used in the remote model, and receiving the current solution of the states from the remote model. – Check is there are any new requests for additional processes on SPINE. If so, initialize communication with these processes. The flow diagram for initialization and the simulation cycle is shown in Figure E.1. E.4 Vehicle Dynamics Implementation The solution of the vehicle dynamics model for each integration cycle is computed by solving a set of mathematical equations. The equations are implemented in the code of the VVSS and computed sequentially. The following is the summary of the equations as they appear in the VVSS. ( ( (% Isect ( ¢ ¡ ¢¤#£ ¥ ¦ § ¨ª© (%¨« ( © ¬®¯ª¨ ¦ ¯¬® § ¦ ° §#± ² ³ µ´¶ ¦ §#± ² ³ ¨ ¦ §#± ² ¥ ¾¿ · § ¸¹º » » ½ § ¦°§ À ¼ §¦ § ¬> ¦ Á ¯ÃÄ Â § · §#± Å ± ² ³ ¨ÆÄ Â § · ¯ ± Å ± ² ¨ Ç È The intersectioning function Isect returns the 3D coordinate of the point where intersection takes place. case the location is where a vertical line vector at the wheel location hits the terrain surface. In this 143 Silicon Graphics ONYX Interpret command-line Initialize Cereal-box comm. Setup component index library Initialize Virtual Environment and Graphics Engine. Create states and viewpoint. Initialize Graphical User Interface PC-Pentium 300 É Initialize system module plugin server SPINE Initialize Client Î Submit Shared Memory Request form Ê Process Inputs from Driver Interface peripherals Ï Ë Receive Shared Memory form n Compute Vehicle Dynamics Í Update Graphics Environment n Ð Compute Subsystem Dynamics ÌProcess clients: Check for new modules Receive module State(s) Send Module State(s) Send Shared Memory form Figure E.1: Software flow model for Multi-CPU Simulation. 144 Ò Ñ Ó Ô Õ Ö#×Ø Ò Ñ Ó Ô ÕÙÛÚÜÞÝ Ò ß Ó Ô Õ Ö#×Ù Ò ß Ó Ô Õ à Ò Ó Ô Õ Ö#×Ø=Ò Ó Ô ÕÙÛÚÜÞÝ Ò Ñ Ó Ô Õ Ö#×Ù Ò Ñ Ó Ô Õ à ëì ç á â%ã Øåæä ç éêÓ Ò Ñ Ó í ¢ Ó Ò Ó > Ù è á âî ï ð ð Ô ñØ èêò Ò Ó Ô ñ%õó`öøÒ Ó ÷ Ô ñ ô%× ï âù ð ñ úSØ ÷ û üSý Dugoff ï ó Ò ã ý Ù õ Ù õ ßþ Ø ó âù ð ñ ú Ô ÿ û ã ` þ Ñ Õ Ö#×Ø þ Ñ ÕÙÛÚÜ û ßþ Õ Ö#×Vó ßþ Õ ý þ Õ Ö#×Ø þ ÕÙ ÚÜ û þ Ñ Õ Ö#×Vó þ Ñ Õ ý ï ëì ï ñØ ü á á ñ%ó äåæ ç ÓªçóÞÒ Ó í á âù ð ñ ú Ô ñØ á ü âù ð ñ ú Ô ñ û ñ õ ó û ý ý Ñ Ø Õ Ö#×VØ ÕÙÛÚÜÞÝ Ñ Õ Ö#×Vó Ñ Õ à ëì ÿ ÿ Ñ Øåæ ä ÿ ! "$# % ó !ÿ " í # % ÿ & ÿ ç ' # ( " # % & ' # " ç Ñ Õ Ö#×VØ ÕÙ Ú Ü Ý Õ Ö#×Vó Ñ Õ à ï Ø ïü )ß á *+ ñ , 6 ëì û á âù 3 ù úÙ á âî ï ð ð ý 4 ó åæä ç ï ç5 í ï Ñ Õ Ö#×VØ ï Ñ ÕÙÛÚÜ û ï Õ Ö#×Vó ï Õ ý ) ) )ß )ß ï Õ Ö#×VØ ï ÕÙ ÚÜ û ï Ñ Õ Ö#×Vó ï Ñ Õ ý ) ) ) ) .0/ Ù2 1 . ã á âù ð ñ ú(Ù .0 / The tire slip forces are computed in the non-linear function Dugoff. The equations for the tire model can be found in Chapter 3 145 Pentium PC - Workstations MATLAB Environment SGI ONYX - Workstation IRIX Performer Development 7 Vehicle Dynamics Graphical Animation Simulink Model Control Diagram 7 Vehicle Dynamics Mathematical Simulation DDE Dynamic Linked Library TCP/IP Shared Memory Server TCP/IP Figure E.2: Hardware setup of the Simulation Platform with Integrated Network. E.5 SPINE - server (VVSS) During the initialization phase, the VVSS will setup a server application that allows other simulation processes to communicate with the vehicle dynamics through SPINE. The server utilizes the TCP/IP protocol with a custom port number that is not reserved for any of the standard internet applications ([60]). The following lines of code implement the server initialization task. serv fd=socket(AF INET,SOCK STREAM,0); gethostname(server hostname,sizeof(server hostname)); printf("host name = [%s]",server hostname); server host=gethostbyname(server hostname); bzero((char *)&server addr,sizeof(server addr)); server addr.sin family = AF INET; server addr.sin port = htons(PORT NO); memcpy((char*)&server addr.sin addr, (char*)server host->h addr,server host->h length); bind(serv fd,&server addr,sizeof(server addr)); listen(serv fd,5); Once the VVSS has entered the main simulation loop, it will make a call to the server once per frame, to identify any new process requests. If it there is one, it will initialize communication with the new process and store a handle to it in the list of active processes on SPINE. The list of active 146 processes can be monitored through the GUI. The actions that are taken to initialize a process on SPINE are the following. 1. Create a new instance of the SPINE object and accept the file descriptor in a member of its class. I.e. Spine->plugin fd=accept(server fd,&plugin addr,&addr len); 2. Receive the first character string as the title of the process. 3. Receive a string representation of an index value. Store it in the request form and do the following, depending on its value. 8 If the index is negative, return the value of the requested state or parameter. 8 If the index is positive, then store the vector of the state or parameter in a backup vector. Allocate a new memory location and create a vector to it, which is stored in the index library. 4. If the string representation of the latest input data was not terminated with the character ‘*’, then more requests are expected. Return to step 3. In the subsequent simulation cycles, the VVSS will communicate with the process through the server, to exchange values for the requested parameters and states. Once per frame it will therefore detect if new simulation output data has arrived. If not, it will predict the new values, as was discussed in Section 6.5. If so, it will perform the following tasks to execute the exchange of data, for each entry in the index request form. 8 If the request is for receiving data, store the values for the requested states or parameters in the server output buffer. 8 If the request is for submitting data, then interpret the data in the server input buffer and store it in the appropriate memory location. To finalize the exchange of data for the cycle, a terminating ‘*’ will be stored in the server output buffer. When communication with a simulation process on SPINE is terminated, the following list of tasks is executed to properly restore the state of the VVSS. 1. Close the network link, given by the file descriptor. 2. Restore the vectors for the states and parameters that were submitted by the remote process. These vectors have been backed up in the communication initialization process. Then clear the memory that was used for the submitted values. 3. Destroy the SPINE object and clean up the allocated work memory. 147 E.6 SPINE - client On the side of the simulation process, there is a network driver that allows the simulation to communicate with the VVSS through SPINE. The initialization phase for setting up the communication on the client side covers the following steps. 1. Create a new network communication link. The next lines of code encompass this task. pSocket = new CAsyncSocket(); pSocket->Create(); pSocket->AsyncSelect(FD READ, FD WRITE, FD CLOSE); pSocket->Connect(HOST, PORT NO); 2. Send the title of the simulation process to the VVSS pSocket->Send(title, strlen(title, 0); 3. For each instance of a state or parameter input in the simulation model, submit the index to the VVSS and receive the initial value for the input. 4. For each instance of a state or parameter output in the simulation model, submit the index to the VVSS. 5. Terminate the initialization procedure by sending a ‘*’. In the subsequent data exchange cycles with the VVSS, the simulation will send a vector of output values with a terminating ‘*’ to the server process through SPINE, and wait for the list of new values for the inputs. The client process that is described in this section has been implemented for Simulink. Appendix D explains how to use Simulink for simulating submodels of the vehicle system through SPINE. However, any hardware processor that has the facility of communicating on a local area network, using the TCP/IP protocol can be programmed to be connected to the SPINE. E.7 Parameter Defaul Values The VVSS will initialize the vehicle dynamics parameters to a set of default values, for the vehicle simulation. The list in table E.2 is an overview of the parameters that characterize the vehicle model for a particular platform. Typically the values for many of these parameters is difficult to identify. Hence one of the main concerns and most elaborate efforts for validating vehicle simulation data is to verify the accuracy of the parameter values. Future extensions to the VVSS will incorporate the facility for customizing a vehicle definition file with the parameter values. The file can the be loaded into the simulation to customize the vehicle or to select another platform. 148 Name 9 : + [email protected]: 9BA ?CA DFE HI HJ JK L O0K O R 0 SA ST: UV W V XY X[ U[ Default Value 4,000 15,000 4,000 150,000 300 1.62 1.62 0.3 9.81 40 800 0.3 0.5 1.225 1.225 40,000 10,000 0.03 Unit ;=<> ;=< ;=<> ;=< G < < < <> M&N P Q P Q < < < < Z Z 1 Table E.2: Default Parameter Values. 149 Scalar elements Throttle Angle Brake Angle Steering Angle Traction Sprung mass Camera Zoom factor Camera Azimuth value Vector elements Position Velocity Acceleration Euler Angle (roll, pitch, yaw) Euler Angle rate Gyroscopic Angle rate Gyroscopic Angle rate Inertia (about x,y,z) Center of Gravity Index 01 02 03 10 50 998 999 Index 00 01 02 03 04 05 06 50 90 Name \F] ^ \F_ ` a bdc eFf g0h Name ij i kj lFj m in i nk io i ok ph a qBr Table E.3: Reference table for the VVSS indexes. E.8 State Reference Index Library Chapter 5 introduced the concept of vectorized state values and parameters. The vector indices are used as a reference to the actual values in the submodels that arew connected to SPINE. Tables E.3 and E.4 present the summary of available vectors with their indices. E.9 Peripherals and User Interfaces The last section in this appendix gives an overview of the implementation of the tools and facilities that the VVSS uses to interface with the user. GUI and XForms The graphical user interface is an optional X-windows based set of controls that are rendered in a separate framed window in addition to the animation. The software uses commands from the xforms library to create the controls and add functionality to the program. The next code section is a sample of the definition commands for the initialization of the user 150 Scalar elements Wheel spin acceleration Wheel spin velocity Wheel spin angle Steering Angle Tire deflection acceleration Tire deflection rate Tire deflection Tire deflection elasticity Tire deflection damping Wheel radius (no load) Suspension deflection acceleration Suspension deflection rate Suspension deflection Suspension deflection elasticity Suspension deflection damping Wheel (unsprung) mass Wheel (spin) inertia Brake Torque Drive (traction) Torque Vector elements Location A Location B Location C Vehicle Velocity Anchor Location CG to Anchor vector Additional suspension force Suspension force Tire deflection force Slip force Index 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 50 51 60 61 Index 00 01 02 05 10 11 49 50 51 52 Name ts tu t vx y w s xuy xy z y y { | xs } w xu } x} z } } { y ~ w Name u B Table E.4: Reference table for the VVSS indexes for the quarter vehicle corners. Add to each index to indicate wich corner is referred to. See Figure for the corner referencing. 151 controls. The function *create_form_VVSS(void) is called in the initialization phase of the VVSS. FD_VVSS *create_form_VVSS(void) { FL_OBJECT *obj; FD_VVSS *fdui = (FD_VVSS *) fl_calloc(1, sizeof(*fdui)); fdui->VVSS = fl_bgn_form(FL_NO_BOX, 370, 400); obj = fl_add_box(FL_UP_BOX,0,0,370,400,""); fdui->hExit = obj = fl_add_button(FL_NORMAL_BUTTON,10,360,350,30,"Exit"); fl_set_object_lsize(obj,FL_NORMAL_SIZE); fl_set_object_lstyle(obj,FL_NORMAL_STYLE+FL_EMBOSSED_STYLE); fl_set_object_callback(obj,guiExit,0); obj = fl_add_frame(FL_DOWN_FRAME,10,190,350,130,""); fdui->Controls = fl_bgn_group(); fdui->hFog = obj = fl_add_lightbutton(FL_PUSH_BUTTON,30,240,100,30,"Fog"); fl_set_object_boxtype(obj,FL_EMBOSSED_BOX); fl_set_object_gravity(obj, FL_NoGravity, FL_NorthWest); fl_set_object_callback(obj,guiFog,0); fdui->hu = obj = fl_add_valslider(FL_HOR_NICE_SLIDER,150,240,200,30,"m"); fl_set_object_boxtype(obj,FL_EMBOSSED_BOX); fl_set_object_lsize(obj,FL_DEFAULT_SIZE); fl_set_object_lalign(obj,FL_ALIGN_LEFT); fl_set_object_lstyle(obj,15); fl_set_object_gravity(obj, FL_NorthWest, FL_NoGravity); fl_set_object_callback(obj,guiu,0); fl_set_slider_return(obj, FL_RETURN_CHANGED); fl_set_slider_bounds(obj, 0, 2*MU0); fl_set_slider_value(obj, (double) MU0); fdui->hplugin[0] = obj = fl_add_roundbutton(FL_PUSH_BUTTON,20,20,82,50,""); fl_set_object_color(obj,FL_MCOL,FL_RED); fl_set_object_lstyle(obj,FL_BOLD_STYLE); fl_set_object_callback(obj,guiplugin,0); fdui->hplugin[1] = obj = fl_add_roundbutton(FL_PUSH_BUTTON,20,120,82,50,""); fl_set_object_color(obj,FL_MCOL,FL_RED); fl_set_object_lstyle(obj,FL_BOLD_STYLE); fl_set_object_callback(obj,guiplugin,0); fl_end_form(); return fdui; } 152 The callback functions for the user control are defined in separate functions. For example, the callback function for the slider for the -coefficient, that is defined in the above sample, will be implemented as void guiu(FL_OBJECT *ob, long data) { (data); mu = (float) fl_get_slider_value(ob); } Forcewheel The Saitek force wheel peripheral is connected to a PC through the game port. Hence, in order to use this equipment to control the vehicle in the simulation, the PC that the force wheel is connected to, must communicate with the VVSS through SPINE. Appendix D explained about blockset library for the PC. The steering angle and angles for the pedals are accessed as if the force wheel was a regular joy-stick. The equipment must therefore be correctly installed in the Windows operating system. The dynamic run-time library that facilitates Simulink to communicate with the force wheel first has to initialize the communication with the game-port, before it can retreive values for the particular angles and buttons. The following command is used to extract data from the force wheel: joyGetPos((UINT)JOYSTICKID1,(LPJOYINFO)\&Joystick); Then the retreived values are stored in a JOYINFO Joystick where the variables Joystick.wXpos, Joystick.wYpos represent the angles of the interface, and Joystick.wButtons contains the button press information. In Simulink, a model needs to be designed that replaces the necessary states and variables from the VVSS to reflect the inputs of the force wheel. This model is available in the Simulink library blockset. Cerealbox If the Cereal box is used as an input device, then its inputs will be directly read by the VVSS. In this case, the VVSS will initialize communication with the device and poll its input buffer once per simulation frame. Stereoscopic Vision The aniumation of the VVSS supports stereoscopic projection, using special active goggles and synchronizing emitters. In the software, the following lines of code facilitate this feature. 153 shared->chan = new pfChannel(p); shared->right = new pfChannel(p); shared->chan->attach(shared->right); mask = shared->chan->getShare(); mask |= PFCHAN VIEWPORT; shared->chan->setShare(mask); leftArg = (int*)shared->chan->allocChanData(sizeof(int)); rightArg = (int*)shared->right->allocChanData(sizeof(int)); leftArg = 1; rightArg = 0; /* data never changes, so we only need to pass it once */ shared->chan->passChanData(); shared->right->passChanData(); eyeAngle = PF RAD2DEG(atanf(Iod *.5f /(Converge * (far - near) + near))); printf("Eye angle :%f",eyeAngle); view.hpr.set(-eyeAngle, 0.0f, 0.0f); view.xyz.set(-Iod/2.0f, 0.0f, 0.0f); shared->chan->setViewOffsets(view.xyz, view.hpr); view.hpr.set(eyeAngle, 0.0f, 0.0f); view.xyz.set(Iod/2.0f, 0.0f, 0.0f); shared->right->setViewOffsets(view.xyz, view.hpr); Curriculum Vitae Gert-Edzko Smid was born in Groningen on April 30, 1969. Prior to university, he attended the “Winkler Prins Scholengemeenschap” in Veendam, from which he graduated in 1988. He started a study in electrical engineering consecutively, at the Delft University of Technology. He graduated in 1995 on the design and analysis of a robust controller for the Bosch SCARA Robot. After graduation he conducted practical training at Oakland University for a period of six month. In Januari 1996 he enrolled into the graduate program as a graduate research assistant. During the practical training and the assistantship he worked on numerous collaboration projects between Oakland University, TACOM (US Army Tank and Automotive Armements Command) and commercial industry. In particular with Dana Corporation on the simulation of noise and vibrations in hydraulic power steering systems. In the summer of 1997 he spent three months at the Department of Electrical and Systems Engineering of the university of Bologna in Italy. As a visiting researcher he assisted in the design of a control algorithm for the VIDET (Visual Decoder by Touch) system. In 1998 he spent three months at the Delft University of Technology, modeling the Jumbo Container Crane 2000. 154 Index Terrain file, 134 Flowchart, 143 Force wheel, 136, 152 Forward Euler approximation, 25 Frame-rate, 51 Friction model, 12 Fuzzy logic tire model, 12 Ackermann geometry, 82, 85, 104 Active suspension, 76 Anti-roll, 112 Applications, 46 Assumptions Tire model, 121 Backward Euler approximation, 25 Bilinear approximation, 25 Brake in a turn, 92 Gearbox complience, 106 Geometry formats, 139 Gimbal Lock, 128 Graphical user interface, see User interface Camber angle, 102 Caster angle, 103 Centrifugal forces, 66, 113 CerealBox, 139, 152 Circular skid pad, 88 Command line, 131 Coordinate systems, 123 Coriolis forces, 66, 113 Coulomb friction, 12 Human in the loop, 49 Hyperstability, 63 Identification, 95 Implementation, 138 Vehicle Dynamics, 142 Index library, 40 Indexing Corner indexes, 150 Vehicle indexes, 149 Indirect addressing, 41 Initialization procedure, 139 Integration Accuracy, 74 Bilinear, 25 Euler, 25 Explicit, 29, 40 Implicit, 29 Phase Lag, 37 Stepsize, 23 Tustin method, 23 Dashboard, 136 Default Values, 147 Descriptor matrix, 9 Direct cosines, 128 Discrete State-spece model, 26 Dugoff, 114 Elastic stress, 115 Elastokinematic compensation, 103 Engine map, 106 Euler Rotation, 66 Euler rotation, 113, 128 File structure, 130 155 156 Intersectioning, 108 Jumbo Container Crane, 7 Kalman observer, 55 Karithonov, 63 Key-press functions, 132 Kingpin angle, 103 Lagrange model, 7 Lane change, 92 Lateral acceleration, 90 Lateral control, 102 Library index, 40 Limit cycle, 12 Load distribution, 32 Luenberger observer, 55 Stability, 76 Lyaponov, 63 Markov matrix, 58 Mis-synchronization, 74 Modeling, 142 Brake, 9, 107 Chassis, 11, 112 Engine-Transmission, 9 Partitioning, 32 Powertrain, 106 Steering, 9, 102 Suspension, 10, 108, 111 Tire, 10, 114 Wheel spin, 10, 107 Modularity, 31 Motion Platform, 101 Multi-processing, 32 Neural networks, 56 Neuromotor dynamics, 50 Newtonian model, 7 Nomenclature, iv Nonlinear state-space model, 9 Numerical Integration, 21 Observability, 58 Observability matrix, 58 Observable canonical form, 58 Observer, see Kalman observer Onyx-2, 50 Optimal control model, 49 Oversteer gradient, 90 Performer, 138 Peripherals, 101, 149 Pointer table, 40 Polynomial time, 64 Popov, 63 Profile, CPU usage, 50 Quaternions, 128 Real-time, 3, 50 Reality engine, 50 Rebounce, 111 Ricatti equation, 57 SAE Coordinates, iv Scenery, 133 Shaker table, 101 Shared memory, 138 Shear deformation, 115 Simulink blockset, 136 Skip pad, see Circular skid pad Slip ratio, 116 SPINE, 40 Client, 147 Server, 145 SPINE Synchronization, 49 Split- test, 90 Spoke model, 108 Stability, 63 Euler Angle Transformation, 66 Jury test, 70 Latency, Synchronization, 74 of Integration, 67 Quarter-car, 64 157 Roll-over, 78 Wheel Spin, 66 Yaw-rate, 78 State request form, 42 Static load, 81 Steady state cornering, 82 Steering Ackermann, 104 Complience, 104 Gear ratio, 105 Self centering, 103 Stereo, 152 Stick friction, 12 Stopping distance, 86 Sub-sampling, 51 Telemetry, 94 Thread deformation, 115 Timing, 49 Timing diagram, 53 Tire stiffness, 116 Toe-in angle, 86, 103 Traction Control, 76 Understeer gradient, 78, 88 Usage, 130 User interface, 131, 134, 141, 149 Validation Requirements, 95 Sensors, 95 Tire model, 96 Verification, 80 Virtual Environment, 45 Viscous friction, 12 Wheel Deflection model, 108 Lift-off, 111 Running model, 107 References [1] Vehicle Dynamics and Analysis Software. a comprehensive 6 degree of freedom vehicle simulation program for the PC. [2] A. Alleyne. Improved vehicle performance using combined suspension and braking forces. In Proceedings of the American Control Conference (ACC), Seattle, Washington, June 1995. [3] K. Araki, H. Sakai, and M. Yanase. Tire model consisting of theoretical and experimental equations for vehicle dynamics analysis. In Proceedings of ISATA, pages 145–153, Florence, 1996. Osaka Sangyo University and Sumitomo Rubber Industry Ltd. [4] Michael Athans. IEEE Handbook of Control, chapter 35, pages 589–594. CRC-Press, 1996. Kalman Filtering. [5] H. Bauer. Automotvie Handbook. Robert Bosch GmbH, P 30.02.20, D-70442 Stuttgart, 4th edition, 1996. [6] R. D. Braatz, M. Morari, and S. Skogestad. Robust reliable decentralized control. In Proceedings of the American Control Conference, Baltimore, Mariland, June 1994. [7] Ka C. Cheok, N. J. Huang, T. Horner, and T. Settle. Concurrent real-time simulation and animation of an active suspension using tms320c30 and graphics hardware. Simulation, pages 405–416, December 1993. [8] Ka C. Cheok, K. Kobayashi, and F. Hoogterp. Fuzzy logic based traction control of a 4wd truck. In Proceedings of the 13th IFAC World Congress, San Fransisco, July 1-5 1996. [9] Ka C. Cheok, K. Kobayashi, and G. E. Smid. Simulation and animation of a 16-degree of freedom dynamics of a vehicle in matlab. Technical report, ITT Automotive - Oakland University, 1996. Submitted to R. Romano and S. S. Vaidyaraman. [10] Ka C. Cheok, K. Kobayashi, G. E. Smid, P. Lescoe, and J. L. Overholt. In-line-of-sight leaderfollower hmmwv’s with fuzzy logic preview control. In Proceedings of AUVSI, Orlando, FL, July 1996. [11] Ka C. Cheok, K. Kobayashi, G. E. Smid, P. Lescoe, and J. L. Overholt. A fuzzy logic hierarchical intelligent control system paradigm for an in-line-of-sight leader-follower hmmwv. Journal of Robotic Systems, 14(6):407–420, 1997. [12] Ka C. Cheok, J. L. Overholt, and R. R. Beck. Exact methods for determining the forward kinematics of a steward platform using additional sensors. Joural of Robotic Systems, Vol.10(Num.5):689–707, July 1993. Special Issue on Parallel Closed-Kinematic Chain Manipulators and Devices. 158 159 [13] Ka C. Cheok, G. E. Smid, K. Kobayashi, F. Meisterfeld, and R. Hormel. Internal impedance characterization for black box signal source. In Proceedings of ECC, Brussels, Belgium, July 1-4 1997. [14] Ka C. Cheok, G. E. Smid, K. Kobayashi, J. L. Overholt, and P. Lescoe. A fuzzy logic intelligent control system architecture for an autonomous leader-follower vehicle. In Proceedings of ACC, Albuequerque, New Mexico, June 6-10 1997. [15] J. J. Craig. Introduction to Robotics. Addison-Wesley Publishing Company, Inc., 2 edition, 1989. [16] H. Dugoff, P. S. Fancher, and L. Segel. An analysis of tire traction properties and their influence on vehicle dynamic performance. In International Automobile Safety Conference, pages 341–365. Society of Automotive Engineers (SAE), 1970. Highway Safety Research Institute, The University of Michigan. [17] S. Dussy, L. E. Ghaoui, G. Mastinu, and M. Gobbi. Linear matrix inequalities in automotive applications: A tutorial. Laboratoire de Mathematiques Appliquees, Ecole Nationale Superieure de Techniques Avancees, Paris, France. [18] A. Seireg Y. Hossam El-Deen. Mechatronics for cars: Integrating machines and electronics to prevent skidding on icy roads. Computers in Mechanical Engineering, pages 10–22, January 1987. [19] E. Fiala. Seitenkrafte am rollenden luft-reifen (lateral forces on rolling pheumatic tires). Technical Report 29, V.D.I., October 1954. [20] Bernard Friedland. IEEE Handbook of Control, chapter 37, pages 607–618. CRC-Press, 1996. Observers. [21] Thomas D. Gillespie. Fundamentals of Vehicle Dynamics. Society of Automtive Engineers, 1992. [22] D. T. Greenwood. Principles of Dynamics. Prentice-Hall, Englewood Cliffs, NJ, 1965. [23] F. Gustafsson. Monitoring tire-road friction using wheel slip. IEEE Control Systems, 18(4):42–49, August 1998. Linköping University. [24] Gyliepse. Automotive Engineering in the Analysis of Automobiles. Society of Automotive Engineers (SAE), -. [25] R. A. Hess. Hunam-in-the-Loop Control, volume The Control Handbook, chapter 80, pages 1497–1505. CRC Press and IEEE Press, 1996. [26] R. A. Hess and R. Kalteis. Technique for predicting longitudinal pilot-induced oscillations. Journal for Guidance and Control Dynamics, 14(1):198–204, 1991. [27] Applied Dynamics International. Real-time seventeen-degree-of-freedom motor vehicle simulatin. Technical report, U.S. Department of Transportation, National Highway Traffic Safety Administration, 1995. (See DOT-HS-805-370, March 1, 1980). [28] ISO. Road Vehicles - Braking in a Turn. Open-loop Test Procedure. ISO/DIS 7975. [29] ISO. Road Vehicles - Double Lane Change, 1975. ISO, TR 3888. [30] ISO. Road Vehicles - Steady State Circular Test Procedure, no. 4138 edition, 1982. ISO No.4138. 160 [31] N. A. Kheir, Ka C. Cheok, G. E. Smid, S. Cole, and A. Cooprider. A first course in automotive mechatronics systems. In Proc. Of Advances in Control Education (IFAC), Istanbul, Turkey, July 14-16 1997. [32] J. B. Klaassens, G. Honderd, A. El Azzouzi, Ka C. Cheok, and G. E. Smid. 3d modeling visualization for studying controls of the jumbo container crane. In Proceedings of ACC, page Submitted, 1999. [33] D. L. Kleinman, W. H. Levison, and S. Baron. An optimal control model of human response. part i: Theory and validation. Automatica, 6(3):357–369, 1970. [34] K. Kobayashi, Ka C. Cheok, and K. Watanabe. Application of a fuzzy logic rule-based kalman filter for estimating absolute speed of a ground vehicle. International Journal of Intelligent Automation and Soft Computing, Vol.1(No.2):179–190, 1996. [35] K. Kobayashi, K. Watanabe, Ka C. Cheok, and G. E. Smid. A simple vehicle dynamics modeling by the object oriented approach. SICA, 1997. [36] S. R. Kou, D. L. Elliot, and T. J. Tarn. Exponential observers for nonlinear dynamic systems. Inf. Control, 29(3):204–216, -. [37] Y. D. Landau. Adaptive Control. The model reference approach. Marcel Dekker, Inc., 1979. [38] William S. Levine, editor. The Control Handbook. CRC Press, IEEE Press, 1996. [39] F. Lewis. Optimal Estimation. Unknown, -. [40] F. L. Lewis. Optimal control. In Handbook of Control, chapter 48, pages 759–778. Institute of Electronics and Electrical Engineers (IEEE), 1996. [41] L. S. Louca, J. L. Stein, G. M. Hulbert, and J. Sprague. Proper model generation: An energy based methodology. In 3rd International Conference on Bond Graph Modeling and Simulation, Phoenix, AZ, January 12-15 1997. [42] D. Luenberger. Observers for multivariable systems. IEEE Transactions on Automatic Control, 11:190–197, 1966. [43] F. Mancosu and G. Matrascia. Experimental tests and virtual reality determining the parameters of a two-dimensional tyre model for the study of comfort. In Proceedings of ISATA, pages 383–390, Florence, 1996. Pirelli Coordinamento Pneumatici SpA. [44] James N. Martin. Systems Engineering Guidebook. A Process for Developing Systems and Products. Lucent Technologies, 1997. [45] D. T. McRuer. Human dynamics in man-machine systems. Automatica, 16(3):237–253, 1980. [46] T. Meressi, D. Chen, and B. Paden. Application of kharitonov’s theorem to mechanical systems. IEEE Transactions on Automatic Control, pages 488–491, 1993. [47] W. F. Milliken and D. L. Milliken. Race Car Vehicle Dynamics. Society of Automotive Engineers (SAE) Publisher Group, 1995. [48] S. Nishizawa, Ka C. Cheok, G. E. Smid, L. W. Ten Berge, and P. Lescoe. Heads-up-display collision warning and traffic monitoring system. In The International Automotive Forum ISATA, Florence, Italy, June 16-19 1997. 161 [49] H. B. Pacejka. Magic formula tire model transient properties. an overview of developments, February 1997. IAVSD-Tyre, Berlin. [50] P. Y. Papalambros and N. F. Michelena. Optimal model-based decomposition of powertrain system design. Technical Report Technical Report UM-MEAM 95-03, Department of Mechanical Engineering and Applied Mechanics. University of Michigan., 1995. [51] J. P. Pauwelussen, S. T. Jansen, J. J. M. Van Oosten, and H. B. Pacejka. Testing and modelling of tyre behaviour in dynamic vehicle simulation. In Proceedings of ISATA, pages 137–144, Florence, 1996. TNO Road Vehicles Research and Delft University of Technology. No.96VR052. [52] M. S. Qatu, M. L. Dougherty Sr., and G. E. Smid. Effect of hose, tuner and fluid parameters on power steering noise and vibration. In Proceedings of SAE Congress, 1999. [53] M. S. Qatu, M. L. Dougherty Sr., and G. E. Smid. Measurement of fluid bulk modulus using impedance of hydraulic circuits. In Proceedings of the SAE Congress, 1999. [54] Alexander A. Reid. Correlated Parametric Terrain Surface Development for use with Computer Image Generators. PhD thesis, Oakland University, Department of Electrical and Systems Engineering, 1998. Doctoral Research Proposal. [55] G. E. Smid and Ka C. Cheok. Human integration in simulation. In Proceedings of International Workshop on Advanced Motion Control, pages 554–558, Coimbra, Portugal, June 29-31 1998. [56] G. E. Smid and Ka C. Cheok. Multi-conputer real-time simulation of vehicle control systems. In Proceedings of International Conference on Intelligent Systems (ICIS), Paris, France, July 1998. [57] G. E. Smid, Ka C. Cheok, and K. Kobayashi. Simulation of vehicle dynamics using matrixvector oriented calculation in matlab. In Proceedings of CAINE (ISCA), pages 115–120, Orlando, FL, December 1996. [58] G. E. Smid, M. Qatu, and M. L. Dougherty Sr. Optimizing the power steering components to attenuate noise and vibrations. In Proceedings of Conference on Computational Fluid Dynamics, pages 103–112, England, July 1998. [59] Society of Automotive Engineers, Inc, Warrendale, PA. Proposed Passenger Car and Light Truck Directional Control Response Test Procedures, sae xj266 edition, 1985. [60] W. R. Stevens. TCP/IP Illustrated, Volume III. Addison-Wesley Publishing Company, Inc., 1996. TCP for Transactions, HTTP, NNTP and the UNIX Domain Protocols. [61] T. K. Tan, K. C. Cheok, and G. E. Smid. Hypercube neural networks, modeling and training. In Proceedings of the International Conference on Intelligent Systems, 1998. [62] F. E. Thau. Observing the state of nonlinear systems. International Journal on Control, 17:471–479, 1973. [63] P. Tinker, R. Azuma, C. Hein, and M. Daily. Driving simulatin for crash avoidance warning system evaluation. In Proceedings of ISATA, pages 367–374, Florence, 1996. Hughes Research Laboratories.

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement