Embed Size (px)
Citation preview
Virtual Reality Simulation of Suspension Ruairi Purtill
Final Year Project – 2004
B.Sc. Computer Science and Software Engineering
Department of Computer Science
National University of Ireland, Maynooth
Co. Kildare
Ireland
A thesis submitted in partial fulfilment of the requirements for the B.Sc. Computer Science
and Software Engineering.
Supervisor: Dr. Andrew Crossan
Declaration
I hereby certify that this material, which I now submit for assessment on the program of study
leading to the award of B.Sc. Computer Science and Software Engineering, is entirely my
own work and has not been taken from the work of others – save and to the extent that such
work has been cited and acknowledged within the text of my work.
Signed: __________________________ Date: __________________
2
Abstract The goal of this project was to develop a visual and haptic simulation of a suspension system
in a car. The word 'haptic' comes from the Greek word ‘haptein’ meaning 'to touch'. The final
system would therefore allow the user to touch objects in the simulation. This is achieved
through use of the PHANTOM® force feedback device, developed by SensAble
Technologies. Using this device, the user can feel the effects of road disturbances on the
vibrations of the body of a car. The user can also adjust properties such as the roughness of
the road surface and the stiffness of the suspension springs, and feel the effect these changes
have on the vibrations felt by the car body. This demonstrates to the user how various spring-
damper systems behave under various road conditions. Hence this simulation could be used to
teach students about suspension systems in cars.
The author has a broad interest in computer science and its modern applications. Systems
which incorporate the use of haptic devices, and allow users to touch and manipulate virtual
objects were first introduced in the 1960’s for tele-operation systems. However, only recently
has this area been explored for the desktop market. Thus it provides a good example of a
modern application of computer science. Therefore the proposal of this project, involving the
use of industry standard graphics, and state of the art modern interaction hardware, attracted
the interest of the author.
3
Acknowledgements I would like to thank my supervisor, Dr. Andrew Crossan, for his time, help and patience
during the course of this project. I would also like to thank professor Peter Wellstead, of the
Hamilton Institute, NUI Maynooth, for his help in deriving the equations of motion, which
define the behaviour of our system.
Finally, I would like to make a very special acknowledgement for Brandy, my dog who sadly
passed away two days before this thesis was submitted, making the long hours and hard work
seem all that more difficult.
4
Table of Contents Chapter 1 Introduction……………………………………………………….6 1.1 Aims and Objectives……………………………………………………………………….6
1.2 Motivation………………………………………………………………………………….6
1.3 Method……………………………………………………………………………………..7
1.4 Overview of Technical Area……………………………………………………………….7
1.5 Overview of Report………………………………………………………………………...8
Chapter 2 Background and Problem Description………………………….9 2.1 Introduction to the Problem Domain………………………………………………………9
2.2 Literature Review…………………………………………………………………………12
2.3 Theoretical Development…………………………………………………………………12
2.4 New Materials and Skills…………………………………………………………………13
Chapter 3 Requirements and Design 3.1 Requirements…………………………………………………………………….….……15
3.1.1 User Requirements……………………………………………………………...15
3.1.2 System Requirements………………………………………………………….. 15
3.2 Design Issues……………………………………………………………………………...16
3.2.1 Design Criteria………………………………………………………………….16
3.2.2 Design Options………………………………………………………………….16
3.3 Algorithm Selection………………………………………………………………………20
Chapter 4 Implementation………………………………………………….22 4.1 Coding…………………………………………………………………………………….22
4.2 Validation…………………………………………………………………………………23
Chapter 5 Results……………………………………………………………25 5.1 Discussion of Test Cases…………………………………………………………………25
5.2 Output and Results……………………………………………………………………….27
Chapter 6 Discussion and Conclusion……………………………………...38 6.1 Evaluation of Project……………………………………………………………………...38
6.2 Proposals for Enhancement……………………………………………………………….38
6.3 Conclusion………………………………………………………………………………..40 References
5
Chapter 1
Introduction
1.1 Aims & Objectives The objective of this project was to implement a visual and haptic simulation of a car
suspension system. The aim of the implementation is to visually and physically display the
performance of different suspension systems under various road conditions.
1.2 Motivation This project involved the use of industry standard graphics libraries, namely OpenGL, and a
sophisticated force feedback device, namely the PHANTOM®. Furthermore, this project
required an understanding of the physics of suspension systems, and the development of a
representation of these systems comprising computer hardware and software. This application
of computer science to a real world situation provoked the interest of the author, and
contributed to the motivation of the author to undertake this interesting and challenging
project. It is the opinion of the author that applications similar to this one will become
widespread in the near future, such are their advantages. Graphical only simulations can
display mechanical behaviour visually, and are relatively easy and inexpensive to develop.
However, they lack the realism of a physical prototype, which generally, and in the case of
vehicle suspension in particular, can be rather expensive and time consuming to produce.
Physical prototypes are also inflexible; changes cannot be easily made without building a new
prototype. Virtual Reality (VR) applications such as this one combine the realism of a
physical prototype with the cost-effective advantages of a visual one, with regard to both time
and monetary costs.
1.3 Method This project was undertaken using recognised software methodology and engineering
practices, with regard to software development modelling, design, documentation and testing.
These methods are described in greater detail in their relevant chapters.
6
1.4 Overview of Technical Area Suspension Systems In modern passenger cars, a system consisting of a spring and a shock absorber is used to
suspend the car body and engine above the wheels. Its primary purpose is to lessen the
vibrations felt by the car body mass caused by disturbances in the road surface. The
suspension must also ensure that the wheels are kept in close contact with the road surface at
all times.
Virtual Reality (VR)
is defined in Encyclopaedia Britannica as the use of computer modelling and simulation to
enable a person to interact with an artificial three-dimensional visual or other sensory
environment. VR applications immerse the user in a computer-generated environment that
simulates reality through the use of interactive devices, which send and receive information
[1], [9]. This project employs the use of the PHANTOM® force feedback device (Figure 1.1),
along with three-dimensional graphics developed using C++ and OpenGL, in its efforts to
create a virtual reality application.
Figure 1.1: The PHANTOM® force-feedback device, by SensAble Technologies [1], [9].
7
1.5 Overview of Report This report introduces the reader to the fundamental concepts of suspension systems, and
shows how these are represented mathematically through dynamic equations of motion. It
also illustrates how a virtual environment is constructed, consisting of a road and a quarter-
car model, and how these equations of motion are implemented in the software to
demonstrate the behaviour of the system.
Chapter 3 details the requirements specification (Sect 3.1) and how these requirements
changed during the design and implementation stages of the project, and how the
requirements were met. This chapter also outlines any design issues (Sect 3.2) that arose
during the course of the project.
Chapter 4 gives an account of the physical realisation of the system. This summarises the
programming languages, tools, platform and physical architecture used (Sect 4.1). This
chapter goes on to describe the validation (Sect. 4.2) methods used, and any test scenarios
and outcomes.
Chapter 5 provides a discussion of test cases (Sect 5.1), followed by output and results of
testing (Sect. 5.2). This involves the exact details of test cases, results of these tests, and the
implications of the results. Conclusions drawn from the testing process are also discussed
here.
The final chapter of the report is a review of the entire project. It provides a critical
assessment of work done, as well as suggestions for system enhancement. Finally, a
conclusion of the report is given.
8
Chapter 2
Background and Problem Description
2.1 Introduction to the problem domain Suspension Systems In the interest of improving the overall performance of automotive vehicles in recent years,
suspensions incorporating active components have been developed. The designs may cover a
spectrum of performance capabilities, but the active components alter only the vertical force
reactions of the suspensions, not the kinematics (Active components that alter kinematical
behaviour do so to steer the wheels, and would be covered under steering systems) [7]. For
the purposes of this project, we are primarily concerned with the basic functionality of a
spring and damper system, and how adjustments made to the properties of the system affect
the behaviour of the overall suspension system.
The Physics of a Spring
Springs in modern suspension systems can be coil springs, which are made from metal, or can
be air or oil springs. When a spring is compressed it creates a force that wants to extend the
spring to its equilibrium state. An important fact to note on springs is that they return all of
the energy that is put into them. This means that if a spring is compressed a given distance, it
takes a given force and a given energy. When the spring is released, the same amount of
energy is released from the spring.
The Physics of a Damper
When a vehicle’s wheel encounters a variation in the surface of the road, i.e. a hole or bump,
the spring absorbs the resultant impact by expanding and contracting. This motion is restricted
by a shock absorber, to prevent the car body from shaking excessively. Shock absorbers are
also known by the more descriptive term dampers, and their function is to dissipate the energy
that is released from the springs. The type of damper generally found on modern vehicles is
usually a hydraulic type that has a casing of two tubes, with one telescoping into the other.
The spring must pull apart and push together the ends of the damper in order to expand and
contract, and so, the higher the level of damping we have, the quicker the motion of the spring
will die out, and thus the vibrations felt by the car body will be reduced accordingly.
9
Suspension systems, in general: • Provide vertical compliance so the wheels can follow the uneven road, isolating the
chassis from roughness in the road.
• Maintain the wheels in the proper steer and camber attitudes to the road surface.
• React to the control forces produced by the tires – longitudinal (acceleration and
braking) forces, lateral (cornering) forces, and braking and driving torques.
• Keep the tires in contact with the road with minimal road variations.
We use a quarter-car model to demonstrate the behaviour of our suspension system. A
quarter-car model displays one of the car’s wheels, its suspension system, which in our case
will consist of a spring in parallel with a damper, and some form of representation of the
car’s body mass. We are only concerned with demonstrating the first function, as the quarter-
car model in our VR environment will not have any steering or braking capabilities. We also
make the assumption that our tire is non-compressible, and will therefore be constantly in
contact with the road.
Second Order System: Our quarter-car is modelled as a second-order system [8], which is a
system governed by Newton’s Second Law of Motion: force = mass x acceleration. This
means that both the position and velocity of the road and the car body mass are known and
accounted for at all times. The position of the car body mass is the output, and so is
represented as a function of the current and previous inputs. A schematic diagram of our
system is shown below:
Figure 2.1: Schematic diagram of spring-damper system
10
Where:
m = car body mass
k = spring constant of suspension system
b = damping constant of suspension system
x(t) = height of the road surface
v(t) = velocity of the road – this is the input to the system
xm(t) = position of the car body mass – this is the output of the system
To model this system, we were able to derive the following equations:
)(
)(
tvm
Pmx
tvbm
bPmkxmP
k
k
+−=
⋅+−⋅=
&
&
Where is the spring deflection, is the momentum of the car body mass; and
are their respective derivatives, i.e. rates of change.
kx Pm kx& mP&
Virtual Reality We are required to construct a 3-dimensional virtual environment and haptic interface in our
virtual reality simulation. The word haptic, derived from the Greek term “haptein”, meaning
“to touch”, is defined by the second edition of the online Oxford Dictionary as “Of, pertaining
to, or relating to the sense of touch or tactile sensations”. Thus, a haptic interface involves
mechanisms that allow the user to interact with the machine through the sense of touch. We
will use the PHANTOM® force feedback device along with OpenGL 3-D graphics to create
our virtual environment. The PHANTOM® is a system of motor and levers, and allows for
six degrees of freedom for input; three for translation in the X, Y, and Z directions, and three
for rotation roll, pitch and yaw. It allows for three degrees of freedom for its output
(translation). The output of our system will be a force delivered in the horizontal Y direction.
The PHANTOM® is updated at 1000Hz and has sub millimetre resolution, providing high
fidelity feedback and allowing for a high level of control.
11
2.2 Literature Review There have been numerous models of suspension systems developed, such as the bus
suspension model developed as a group project in the University of Michigan [2], which is
rather heavily mathematics-based and uses a Matlab™ GUI (graphical user interface) to
present its results (Figure 2.2). This, and similar models, focus on the physics of suspension
systems, and the mathematics behind their development and improvement. There are also
physical prototypes, such as [5], but there are currently no VR haptic simulations available,
hence the proposal of this project.
Figure 2.1: Matlab™ interface, University of Michigan group project [2].
2.3 Theoretical Development Although there are many models of suspension currently published and widely available, and
several graphical applications incorporating suspension, such as [3] and [4], our model
introduces a haptic interface. Consequently, the behaviour of the suspension system is not
only demonstrated visually – using 3-D graphics, but is also communicated through the sense
of touch. This is an additional feature to all of the models studied, and offers the user a more
realistic simulation. There are several implications of this development. A haptic simulation
could help in the designing of suspension systems, unambiguously demonstrating how a
proposed system would perform under certain road conditions. An example of this kind of
idea is the study of hydraulic active suspension in Gifu University, Japan (Figure 2.3) [5].
12
However, construction of such a system can be extremely expensive. The flexibility of a VR
environment allows for the development of a system and the establishment good parameters
within the virtual environment, before construction of an expensive prototype. This would
also permit the testing of various arrangements of springs and dampers, before prototype
development began.
Figure 2.2: Quarter car test bench system of active suspension, Gifu University [5].
Another implication of our development is that it makes it possible to teach students about
suspension systems and how they work. The student would be able to adjust the spring and
damping values, and experience the effect these adjustments have on the movement of the car
body mass. The idea of our simulation being used for this purpose was an important factor in
the design and development stages of the project.
2.4 New Materials and Skills Visual C++
Prior to undertaking this project, the author’s experience of programming in C++ was through
the use of the GNU compiler, with compilation performed at the command line, and input and
output limited to text in the command prompt window. All coding for this project was carried
out in Microsoft’s Visual C++ 6.0 integrated development environment, with an executable
13
produced as the final system, consisting of a 3-dimensional virtual environment which
changes according to the output of the system, and a dialog box providing a graphical user
interface for inputs.
OpenGL
OpenGL graphics libraries were used in conjunction with the C++ code. OpenGL provided
the system with the facility to create 3-dimensional graphics to display our quarter-car model
and its environment.
GHOST
The GHOST API was used for programming of the PHANTOM®. The GHOST API, based
on OpenGL libraries, allows the creation of a 3-D haptic scene including basic geometric
objects. Alternatively, the program can directly send forces to the motors at 1000Hz, allowing
complex effects to be developed
14
Chapter 3
Requirements and Design
3.1 Requirements 3.1.1 User Requirements:
1. The system must provide a means of demonstrating how suspension systems work,
and how they behave in relation to various settings and road conditions.
2. The system must place the user in a virtual environment, in which system behaviour
can be seen and felt.
3. The system must allow the user to control relevant parameters to create different feels.
3.1.2 System Requirements:
3.1.2.1 Functional Requirements: 1. The user shall be able to adjust the roughness of the road surface, which is the
main input to the system, through a graphical user interface.
2. The behaviour of the suspension system, and its effect on the car body mass,
will be visually displayed through the use of a 3-dimensional graphical
representation of a quarter-car model.
3. The effects on the car body mass will be physically reflected through the use of
a haptic force feedback device (the PHANTOM®).
4. The user shall be able to adjust the settings of the suspension system, which
are the spring stiffness and damping value, and these shall serve as parameters
of the system. These will be adjustable in the graphical user interface, and
should be initialised to 1 and 0 respectively.
3.1.2.2 Non-Functional Requirements: 3.1.2.2.1 Product Requirements
1. The system shall not permit the user to set the spring stiffness to
a value greater than 100, or less than 1.
15
2. The system shall not permit the user to set the damping value to
a value greater than 10, or less than 0.
3. The system shall enable the user to reset the spring stiffness and
damping variables to their initial values.
4. The system is constrained by the use of the PHANTOM® force
feedback device, and consequently will only perform on a
machine with a properly configured PHANTOM® installed.
3.1.2.2.2 Organisational Requirements
1. The system is to be developed in Microsoft’s Visual Studio
development environment using C++ and 3-D graphics
libraries.
3.2 Design Issues The system was designed as a tool for teaching students how suspension systems work, and
this influenced many design decisions during the course of development. These decisions
determined the type of software process, process iteration, and prototyping methods used
during the implementation stage.
3.2.1 Design Criteria The main design criteria were:
• Satisfy the user and system requirements.
• Do so in an efficient and iterative manner.
• Protect the safety of the user – some force feedback devices, including the
PHANTOM®, can risk injury to the user. Therefore, restrictions were required to
ensure that unstable values were not selectable to the user as inputs.
These criteria were taken into account when considering all design options.
3.2.2 Design Options Software Process
An incremental development software process (Figure 3.1) was used. Incremental
development was suggested by Mills (Mills et al., 1980) as a way of reducing the amount
16
of rework in process iteration, and giving customers the option to delay detailed
requirements decisions until they had some experience with an early prototype.
Figure 3.1: Incremental Development Model [10].
It was chosen over the spiral model (Figure 3.2), based on the fact that the system
requirements were clear and unlikely to change, allowing for short release cycles of process
iteration, satisfying system requirements one at a time.
Figure 3.2: Spiral Model of the Software Process [10].
17
Another factor in this decision was the fact that several aspects of the project, such as the
use of the PHANTOM®, and the implementation of vehicle dynamics in software, were
exploratory areas of study for the author. This was considered too great a risk to
accommodate if a software process such as the waterfall model (Figure 3.3) was used, as it
was not feasibly possible to estimate time-spans for the design and implementation stages.
Hence the incremental approach to development seemed best suited to this project. This
meant that the requirements for any particular iteration were determined by previous
iterations, and the length of time taken to develop them. This allowed for rapid prototyping
in an effort to satisfy as many requirements as possible through the development of
separate systems, each satisfying different requirements, and iteratively undergoing further
development.
Figure 3.3: Waterfall Model [10]
An example of this can be seen by comparing the initial graphical prototype with minimal
functionality (Figure 3.4), to the graphical output of the final system (Figure 3.5). System
separation is evident in the use of Excel to test the output of our equations of motion. The
values obtained from the equations were written to a Microsoft Excel spreadsheet and their
18
values were plotted in a graph (see testing, section 5.3), before applying these to our
graphical model in the development of the final system.
Figure 3.4: The initial graphical prototype with minimal functionality .The sphere and red
cylinder slide up and down, with the blue cylinder telescoping the red.
Figure 3.5: The Final System. Note the improvement in graphical quality and user-friendly
interface.
Safety Issues:
Plotting of the outputs from our equations in Microsoft Excel was done in order to establish
stable values for the range of inputs to be selectable to the user. The behaviour of the
19
PHANTOM® is directly controlled the program. Therefore there are unsafe input values,
which could compromise the safety of the user. As the author and the project supervisor
would be the first users of the system, this was a primary issue, and stable inputs were
established before any programming of the PHANTOM® began.
Graphics Libraries
OpenGL graphics libraries were chosen for this project. There were several reasons for
this choice, over DirectX or similar packages:
• The GHOST haptics API is based on the OpenGL libraries, which allows for easy
integration.
• OpenGL is a powerful graphics library that is comparatively easy to learn, and
extensively documented.
• OpenGL is industry-standard, along with DirectX, but is becoming increasingly
more popular with developers.
3.3 Algorithm Selection An algorithm was developed (Figure 3.6) to implement our equations of motion, which are
continuously updated to determine the system’s current state. The PHANTOM® updates
all of the values of these equations at 1000Hz, which allows for high quality feedback to
the user. The forces we used from the outputs of these equations are scaled due to safety
concerns, but nonetheless simulate real forces.
OpenGL updates the graphics at 30Hz, and so the values of the equation were also used to
model the road. The road representation comprises a black rectangle, two green rectangles
and three white lines, as displayed in Figure 3.5. The height of these rectangles change
according to the height of the road in our equations, with the white lines being translated
continuously across the screen to give the illusion that the quarter-car is moving along a
surface.
Note: The values are approximations. Improved or even exact values could be achieved
through the use of numerical integration. This was researched by the author, but because of
complexity issues and time constraints, it was decided that approximations would suffice.
This decision followed the testing of outputs using the approximations, which were deemed
more than satisfactory for demonstrating how suspension systems behave.
20
//Spring and Damper values
k = 200.0; //Spring Constant
b = 10.0; //Damper Constant
//Constant Mass value
const m = 80.0;
//Initialise variables
Xk = 0.0; //Spring Deflection
ChangeXk = 0.0; //Rate of Change of Spring Deflection
Pm = 0.0; //Momentum of Mass
ChangePm = 0.0; //Rate of Change of Momentum of Mass
VMt = 0.0; //Velocity of Mass
ChangeVMt = 0.0; //Rate of Change of Velocity of Mass
XMt = 0.0; //Height/Position of Mass
Xt = 0.0; //Height/Position of Road
Vt = 0.0; //Input Velocity
dt = 0.1; //Timestep
ChangePm = Xk*k-((b*Pm)/m)+b*Vt; //Rate of Change of Momentum of Mass
ChangeXk = Vt-(Pm/m); //Rate of Change of Spring Deflection
ChangeVMt = ChangePm/m; //Rate of Change of Velocity of Mass
Pm += (ChangePm * dt); //New Momentum
Xk += (ChangeXk * dt); //New Spring Deflection
VMt += Vt - ChangeXk; //New Velocity of Mass
XMt += (ChangeVMt * dt); //New Position of Mass
Xt += (Vt*dt); //New Position of Road
Figure 3.6: Algorithm developed to model our equations of motion; values are continuously
updated
21
Chapter 4
Implementation
4.1 Coding Choice of Language C++ was used as the programming language. There were several reasons for this choice:
• It is a language familiar both to the author and the project supervisor. This reduced the
risk of project incompletion due to coding problems and/or errors.
• It is a well-documented object-oriented language, with texts and online resources
widely available.
• Its portability meant that coding could be carried out both on the Computer Science
Department’s machines, which run Windows 2000, and on the author’s home system,
which runs Windows XP.
• It supports the OpenGL API (Application Program Interface).
• It supports the PHANTOM® GHOST API.
Development Environment Microsoft’s Visual C++ 6.0 development environment was used. The primary reason for this
was that it was stated as an organisational requirement (Section 3.2.2.2.2). However, there are
many advantages associated with its use:
• It provides a GUI for adding, removing and modifying classes, functions and
variables.
• It provides an integrated compiler, which directs the developer to errors in the code,
and gives warnings of un-referenced variables etc.
• It provides a program debugger, which is a useful tool for removing run-time errors.
Code Design The coding for this project was divided into four separate applications:
1. An initial graphical model of our quarter-car, with basic motion (Figure 3.4).
22
2. A numerical program which modelled our equations of motion. The outputs of this
program were plotted in Microsoft Excel (see testing, section 5.3).
3. A dramatically enhanced version of the graphical model, combined with the behaviour
of the numerical program, which determined motion in the 3-D scene (Figure 4.2).
Figure 4.2: Enhanced graphical representation integrating functionality of component 2
4. The final system (Figure 4.3). This incorporated all aspects of 3, above. However, it
also included all PHANTOM® related code. This required that the outputs of our
equations were used to create a new class, which was a force effect to be sent to the
PHANTOM®. Added to this were the user controls, allowing the road roughness,
spring stiffness, and damping value to be adjustable.
4.2 Validation Validation is an evaluation of a system or sub-system to determine whether it satisfies the
user and system requirements. In order to validate our system, we first look at our
requirements, and inspect how each of these requirements was met. Overleaf is a table
outlining the user and system requirements, and stating how each one is satisfied.
23
Requirement Satisfied?
(Yes/No)
How Requirement Was
Satisfied
The system must provide a means of demonstrating how suspension
systems work, and how they behave in relation to various settings and
road conditions.
Yes (partial)
Development of final
system. Approximate
values were used.
The system must place the user in a virtual environment, in which
system behaviour can be seen and felt.
Yes
Development of final
system.
The system must allow the user to control relevant parameters to create
different feels.
Yes Sliders are provided in the
GUI
The user shall be able to adjust the roughness of the road surface, which
is the main input to the system, through a graphical user interface.
Yes
Sliders are provided in the
GUI
The behaviour of the suspension system, and its effect on the car body
mass, will be visually displayed through the use of a 3-dimensional
graphical representation of a quarter-car model.
Yes
OpenGL based motion
graphics
The effects on the car body mass will be physically reflected through the
use of a haptic force feedback device, the PHANTOM®.
Yes
Development of final
system.
The user shall be able to adjust the settings of the suspension system,
which are the spring stiffness and damping value, and these shall serve
as inputs to the system. These will be adjustable in the graphical user
interface, and should be initialised to 1 and 0 respectively.
Yes
Sliders in the GUI allow for
adjustment, the program
sets the initial values.
The system shall not permit the user to set the spring stiffness to a value
greater than 100, or less than 1.
Yes
Sliders in the GUI enforce
this restriction.
The system shall not permit the user to set the damping value to a value
greater than 10, or less than 0.
Yes
Sliders in the GUI enforce
this restriction.
The system shall enable the user to reset the spring stiffness and
damping variables to their initial values.
Yes
A reset button is provided
in the GUI.
The system is to be developed in Microsoft’s Visual Studio development
environment using C++ and 3-D graphics libraries.
Yes
All code was developed in
Microsoft’s Visual C++ 6.0
environment
As the table shows, all requirements were met, in full or in part, thus validating our system.
24
Chapter 5
Results
5.1 Discussion of Test Cases Unit testing: The fact that four separate applications were developed meant that some level
of testing was performed on each one individually. Although unit testing is normally
associated with testing of individual classes, testing of the first three programs served as unit
testing. The level of detail of the testing carried out varied for each component:
Component 1: Initial graphical model of quarter-car with basic motion.
The purpose of the development of this component was to introduce the author to OpenGL
and 3-D graphics, whilst beginning the constructing of our virtual scene. As the onscreen
graphics were instantly visible following every execution, and functionality was limited to a
basic vertical motion following the click of a button, no formal testing needed to be
performed on this component. Results were instantaneously displayed during development.
Component 2: Numerical program to model equations of motion.
This component was developed to test the validity of our equations of motion, which
determine the state of the system at all times. No formal testing was required; our equations
were mathematically sound, all that had to be done was work out sensible initial variable
values to correctly reflect the behaviour of a real mechanical system. This was done by
writing the relevant output values to a .csv (comma separated version) file, which opens with
Microsoft Excel. These values were then plotted as a line graph, where the change in values
over time could easily be inspected, in order to see whether or not our system would behave
as expected. Examples of these graphs can be seen in section 5.3, where we display our output
and results.
Component 3: Enhanced version of the graphical model, combined with the behaviour of the
numerical program.
This component was developed to apply the algorithm developed for component 2 to the
graphics, which were improved on from component 1 to bear more of a resemblance to a
25
quarter-car. Also introduced were several buttons, each setting a new value(s) for our main
input, the velocity of the road. As was the case with component 1, the results were
instantaneously visible, removing the need for formal testing.
Integration Testing: Integration testing tests functionality between combinations of classes
or sub-systems. Integration testing was carried out following the development of component
3, our enhanced graphical model, and the final system.
Component 3: Enhanced version of the graphical model, combined with the behaviour of the
numerical program.
Formal integration testing was not required here, for the same reasons it was not required
during unit testing. Once our equations were applied to the graphics, the integration of
components 1 and 2 was evident.
Final System: Our final system consisted of the graphics, which were initially developed for
component 1 but had subsequently been enhanced, the equations modelled by component 2,
and the code required to initialise and communicate with the PHANTOM®. This required that
a new class be created, modelling the values of the outputs of the equations of component 2 as
force vectors, which were sent to the PHANTOM® as a force effect. Similarly to component
3, once our new class was created and any errors were removed from the program, integration
of the components was evident upon execution. Thus no formal testing was required at this
stage.
System Testing: This is the process of attempting to demonstrate that a program or system
does not meet its original requirements and objectives [11]. This is a black-box type of
testing, where the system is given specific inputs, we derive expected corresponding outputs,
and the actual outputs are compared to these. For our final system tests, we used the projected
outputs from the unit testing performed on component 2 as our expected outputs, and
recorded whether or not these outputs were reflected in the behaviour of the PHANTOM®.
26
5.2 Output and Results The following charts display the outputs of our equations. Each chart displays the height of
the road and the height of the car body mass over a 15 second period, for all combinations of
low, medium and high spring stiffness and damping values. Tests were performed using
Microsoft Excel.
5.2.1 Pulse For this set of charts, a sharp increase in road velocity, followed by an equally sharp decrease,
was the input. This input was chosen as it demonstrates the behaviour of the system in a
simple manner.
Low Spring Stiffness
Low Spring Stiffness, Low Damping
-0.50
0.51
1.52
1
167
333
499
665
831
997
1163
1329
1495
Time(100/sec)
Hei
ght (
inch
es)
RoadCar Body
Low Spring Stiffness, Medium Damping
-0.50
0.51
1.52
115
731
346
962
578
193
710
9312
4914
05
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
27
Low Spring Stiffness, High Damping
-0.50
0.51
1.52
1
159
317
475
633
791
949
1107
1265
1423
Time (100/sec)
Hei
ght
RoadCar Body
These charts show the pulse input with a low spring stiffness of 1. Because there is very
little stiffness in the spring, the pulse is almost totally absorbed. As damping is increased,
oscillations appear to increase. This is due to the resistance of the damper, and is quickly
dispersed in all cases. Although this may seem like a good arrangement, as there is little
disturbance to the car body, in practice this is not the case. The looseness of the spring
would cause severe swaying of the car body upon encountering any corners. Limousines
generally have this style of suspension, and consequently travel smoothly in straight lines
over rough roads, as shown by the graphs.
Medium Spring Stiffness
Medium Spring Stiffness, Low Damping
-0.50
0.51
1.52
1
169
337
505
673
841
1009
1177
1345
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
28
Medium Spring Stiffness, Medium Damping
-0.50
0.51
1.52
117
835
553
270
988
610
6312
4014
17
Time (100/sec)H
eigh
t (in
ches
)
RoadCar Body
Medium Spring Stiffness, High Damping
-0.50
0.51
1.52
1
177
353
529
705
881
1057
1233
1409
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
These charts show the pulse input with a medium spring stiffness of 50. By comparing the
three charts, it can be seen that as damping increases, the size and number of oscillations
decreases. This was the expected output, as the higher damping value leads to a higher rate of
dispersal of energy from the system. This type of arrangement is generally used for systems
that will be used on normal road surfaces.
High Spring Stiffness
High Spring Stiffness, Low Damping
-1-0.5
00.5
11.5
2
1
177
353
529
705
881
1057
1233
1409
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
29
High Spring Stiffness, Medium Damping
-1
0
1
2
1
167
333
499
665
831
997
1163
1329
1495
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
High Spring Stiffness, High Damping
-1-0.5
00.5
11.5
2
1
177
353
529
705
881
1057
1233
1409
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
These charts show the pulse input with the maximum spring stiffness of 100. As expected,
this causes increasingly large oscillations. When the damping level is 0, these do not decrease
at all over the 15-second time period, as no energy is being dissipated from the system. They
actually appear to increase; this is due to our approximate values. However, as damping is
increased, the oscillations decrease in size, and have nearly stopped at the end of the time
period in the case of maximum damping.
5.2.2 Sinusoid For the following set of charts, a sine wave was used as the input to the system. This input
was chosen, as it is a standard test technique for cars.
30
Low Spring Stiffness
Low Spring Stiffness, Low Damping
-0.50
0.51
1.52
2.5
1
177
353
529
705
881
1057
1233
1409
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
Low Spring Stiffness, Medium Damping
-10123
1
167
333
499
665
831
997
1163
1329
1495
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
Low Spring Stiffness, High Damping
-0.50
0.51
1.52
2.5
1
177
353
529
705
881
1057
1233
1409
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
Inspection of these charts show similar trends to the pulse output according to the spring and
damper constants. With a low spring constant and zero damping, there is an extremely small
effect on the car body. As damping is increased, oscillations increase, due to the resistance of
the damper to a very loose spring.
31
Medium Spring Stiffness
Medium Spring Stiffness, Low Damping
-4-20246
1
167
333
499
665
831
997
1163
1329
1495
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
Medium Spring Stiffness, Medium Damping
-4-2024
1
167
333
499
665
831
997
1163
1329
1495
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
Medium Spring Stiffness, High Damping
-2
0
2
4
1
167
333
499
665
831
997
1163
1329
1495
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
This set of charts show the same examples as before, with a spring stiffness of 50. As shown
in the charts, when there is some level of stiffness in the spring, higher levels of damping
reduce the oscillations. When this is compared to the charts overleaf, it can be seen that
medium spring stiffness is generally the best setting for changing terrain, with a higher level
of damping for rougher surfaces. This is because both large and small variations in the road
surface can be absorbed quickly.
32
High Spring Stiffness
High Spring Stiffness, Low Damping
-2-10123
1
167
333
499
665
831
997
1163
1329
1495
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
High Spring Stiffness, Medium Damping
-2-10123
1
167
333
499
665
831
997
1163
1329
1495
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
High Spring Stiffness, High Damping
-2-10123
1
167
333
499
665
831
997
1163
1329
1495
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
This set of charts show the same examples as before, with a maximum spring stiffness of
1000. As shown in the charts, when there is a high level of stiffness in the spring, higher
oscillations occur, but higher levels of damping reduce these oscillations. This type of
arrangement would be suitable for a smooth surface with small variations, as the stiffness of
the spring is too high to cope with any large road disturbances.
33
5.2.3 Rough Road Surface The following sets of charts display the outputs when the input is changing extremely quickly,
to simulate a rough road surface. Random numbers were generated for the inputs.
Low Spring Stiffness
LowSpring Stiffness, Low Damping
02468
10
1
170
339
508
677
846
1015
1184
1353
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
Low Spring Stiffness, Medium Damping
-5
0
5
10
1
170
339
508
677
846
1015
1184
1353
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
Low Spring Stiffness, High Damping
-5
0
5
10
1
170
339
508
677
846
1015
1184
1353
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
These charts display similar trends to previous examples where a low spring constant is used.
As damping is increased, oscillations of the car body also increase. The results of all of the
charts where a low spring value is used suggest that this not a very useful arrangement.
34
Regardless of damping values, except on very smooth, straight surfaces, which is not very
practical.
Medium Spring Stiffness
Medium Spring Stiffness, Low Damping
-5
0
5
101
170
339
508
677
846
1015
1184
1353
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
Medium Spring Stiffness, Medium Damping
-5
0
5
10
1
170
339
508
677
846
1015
1184
1353
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
Medium Spring Stiffness, High Damping
-5
0
5
10
1
170
339
508
677
846
1015
1184
1353
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
This set of charts show the results of our three damping values with a medium spring value of
50. As was the case of low spring stiffness, the number of oscillations appears to increase as
damping is increased, although these oscillations are smaller. This does not concur with the
same arrangement using the pulse and sinusoid inputs. This suggests that this type of
35
arrangement could be suitable for rough terrain, and so could be used, for example, on a rally
car.
High Spring Stiffness
High Spring Stiffness, Low Damping
-5
0
5
101
170
339
508
677
846
1015
1184
1353
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
High Spring Stiffness, Medium Damping
-5
0
5
10
1
170
339
508
677
846
1015
1184
1353
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
High Spring Stiffness, High Damping
-5
0
5
10
1
170
339
508
677
846
1015
1184
1353
Time (100/sec)
Hei
ght (
inch
es)
RoadCar Body
This set of charts show the results of our three damping values with a maximum spring value
of 100. This means that the spring has very little capability for expansion and contraction, and
so is almost solid. This is reflected in the greater amount of oscillations shown in comparison
to medium spring stiffness with the same input. This shows that some level of flexibility is
36
required in the spring, and that oscillations do not merely reduce upon the increase of spring
and damping values.
37
38
Chapter 6
Discussion and Conclusion
6.1 Evaluation of Project The main objective of this project was to create a virtual reality application to simulate a
suspension system. This application should therefore encourage the user to “suspend their
disbelief” when using the system. “Suspension of Disbelief” is defined by Wikipedia, the free
online encyclopedia [6], as, “a willingness of a reader or viewer to suspend their critical
faculties in order to “go along for the ride”.” The author believes that this objective was met,
to a certain extent. Although the behaviour of the system is based on approximate values, the
basic idea of how a suspension system operates is intuitively communicated to any user.
When the height of the road in the VR environment changes, the effect this has on the car
body is seen and felt by the user. Furthermore, the function of the suspension system is
demonstrated to the user; this is particularly evident upon clicking of the “Pulse” button,
whereby a sharp increase in road height is immediately followed by an equally sharp
decrease. The level of disturbance transmitted to the car body in relation to the sharpness of
the change in road height, and the oscillations felt after the road height has levelled off, give a
good indication of what the suspension system is doing.
6.2 Proposals for Enhancement It is the opinion of the author that this project meets the basic requirements set out at the
beginning of the development cycle. However, there are several aspects, which could be
improved on. For example, in the test cases where there is no damping, oscillations actually
increase, which does not reflect real behaviour. This indicates a sampling error, which occurs
because we have modelled a continuous system as a discrete system. Numerical integration
methods would solve this problem, giving more accurate values, or alternatively, the
minimum damping value could be restricted to a value above 0. The graphics, although
relatively pleasing to the eye and more than adequate for communicating the idea of what the
system is doing, could be enhanced to provide a higher level of VR. Also, a more detailed
model could be constructed, for instance a half-car model, which would take into account
steering, and possibly braking.
39
It is the opinion of the author that this project provides a strong foundation for future projects
of a similar nature.
6.3 Conclusion This project has provided me with the opportunity to research and develop a novel system of a
modern nature, involving sophisticated hardware, namely the PHANTOM®, and a powerful
graphics tool, OpenGL. These factors made for an interesting and exciting project. Over the
course of the project, I have gained experience in software engineering practices, such as
design and testing.
40
References [1] http://www.sensable.com, SensAble Technologies Homepage.
[2] http://www.engin.umich.edu/group/ctm/examples/susp/susp.html, University of
Michigan group project - Modelling a Bus Suspension System using Transfer
Function
[3] http://www.cgw.pennet.com
[4] http://www.cgsd.com/DrivingSimulator/ds100.html
[5] https://journal.fluid.power.net/issue10/fprcentre10.html
[6] http://www.wikipedia.org
[7] Gillespie, T. D., "Fundamentals of Vehicle Dynamics", Society of Automotive
Engineers, 1992.
[8] R. J. Jagacinski and J. M. Flach, “Control Theory for Humans”: Lawrence Erlbaum
Associates, 2003.
[9] T. H. Massie and K. Salisbury, "The Phantom Haptic Interface: A Device for Probing
Virtual Objects," in Proceedings of the ASME International Mechanical Engineering
Congress and Exhibition, Chicago, IL, 1994, pp. 295-302.
[10] Ian Sommerville, “Software Engineering”, 6th Edition, Pearson Education Limited,
2001.
[11] Edward Kit, “Software Testing in the Real World, Addison Wesley, 1995.
41
![State of Augmented Reality, Virtual Reality and Mixed Reality · State of Augmented Reality, Virtual Reality and Mixed Reality [Microsoft Hololen] [Ready Player One] Augmented Reality](https://img.dokumen.tips/doc/110x75/5f82ab6da2d89130b90d78c7/state-of-augmented-reality-virtual-reality-and-mixed-reality-state-of-augmented.jpg)
