Mathematical Modelling For The Continuous Simulation of A Bicycle - Research and Design

USING MATHEMATICAL MODELLING TO CREATE A
CONTINUOUS SIMULATION OF A BICYCLE

EXTENDED RESEARCH AND DESIGN
SEAN ROBINSON
Abstract This paper documents the necessary mathematics required to solve the individual
stages in creating a limited physics engine for a bicycle. These solutions are tested through a
series of experiments to prove viability and accuracy. The set of solutions is then amalgamated
into a full model to show how the inputs are used within the complete system to return accurate
and appropriate results. Using these solutions, a working system is designed through a series of
increasingly specialised diagrams that culminate to describe the complete structure and mechanics
of the final product.
CONTENTS
1.
Introduction .................................................................................................................................................... 4
2.
Refined Evaluation of Software Languages and Development Platforms ...................................................... 6
2.1.
Introduction ............................................................................................................................................... 7
2.2.
Modularisation .......................................................................................................................................... 7
2.3.
Mathematical Formula .............................................................................................................................. 8
2.4.
Operating System ...................................................................................................................................... 8
2.5.
.DLL Files .................................................................................................................................................... 8
2.6.
Conclusions ................................................................................................................................................ 8
3.
Extended Research ....................................................................................................................................... 10
3.1.
Introduction ............................................................................................................................................. 11
3.2.
Defining Constants .................................................................................................................................. 11
3.3.
Calculating Velocity ................................................................................................................................. 12
3.3.1.
Power .................................................................................................................................................. 12
3.3.2.
Surface Friction ................................................................................................................................... 12
3.3.3.
Braking ................................................................................................................................................ 12
3.3.4.
Slopes .................................................................................................................................................. 13
3.3.5.
Watts to Overcome Gravity ................................................................................................................ 13
3.3.6.
Watts to Overcome Surface Friction ................................................................................................... 13
3.3.7.
Watts to Overcome Air Resistance ..................................................................................................... 13
3.3.8.
Final Power Output ............................................................................................................................. 14
3.3.9.
Calculating Acceleration ...................................................................................................................... 14
3.4.
Integrating Velocity ................................................................................................................................. 17
3.5.
Calculating Lean ....................................................................................................................................... 20
3.6.
Calculating Steering Angle ....................................................................................................................... 24
3.7.
Integrating and Mapping Movement ...................................................................................................... 27
3.8.
Enhancements ......................................................................................................................................... 29
3.9.
Conclusions .............................................................................................................................................. 29
4.
4.1.
User Specification ......................................................................................................................................... 30

Introduction ............................................................................................................................................. 31
Page 2 of 50
Sean Robinson 2012
4.1.1.
Motivation ........................................................................................................................................... 31
4.1.2.
Scope ................................................................................................................................................... 31
4.1.3.
Definitions ........................................................................................................................................... 31
4.1.4.
Customer ............................................................................................................................................. 33
4.2.
Core Functionality ................................................................................................................................... 33
4.2.1.
Overview ............................................................................................................................................. 33
4.2.2.
Core Features ...................................................................................................................................... 33
4.2.2.1.
Calculate Acceleration ................................................................................................................ 33
4.2.2.1.1.
Inputs ..................................................................................................................................... 33
4.2.2.1.1.1.
Power ..................................................................................................................................... 33
4.2.2.1.1.2.
Brake ...................................................................................................................................... 34
4.2.2.1.1.3.
Slope ...................................................................................................................................... 34
4.2.2.1.1.4.
Watts To Overcome Friction .................................................................................................. 34
4.2.2.1.1.5.
Watts to Overcome Gravity ................................................................................................... 34
4.2.2.1.1.6.
Watts to Overcome air Resistance ......................................................................................... 34
4.2.2.1.2.
Output .................................................................................................................................... 34
4.2.2.1.2.1.
Acceleration ........................................................................................................................... 34
4.2.2.2.
Integrate Velocity ....................................................................................................................... 35
4.2.2.3.
Calculate Yaw ............................................................................................................................. 35
4.2.2.4.
Generate New Position .............................................................................................................. 35
4.3.
Constraints............................................................................................................................................... 36
4.3.1.
Interaction ........................................................................................................................................... 36
4.3.2.
Performance........................................................................................................................................ 36
4.3.3.
Structural............................................................................................................................................. 36
4.3.4.
Operational ......................................................................................................................................... 37
4.3.5.
Legal .................................................................................................................................................... 37
4.4.
Testing ..................................................................................................................................................... 37
5.
Refined UML Diagram ................................................................................................................................... 38
6.
Use Case Diagram and Specification............................................................................................................. 39
6.1.
Use Case Diagram .................................................................................................................................... 40
6.2.
Derive New State ..................................................................................................................................... 40
6.1.1.
Description .......................................................................................................................................... 40
6.1.2.
Actors .................................................................................................................................................. 40
6.1.3.
Preconditions ...................................................................................................................................... 40
6.1.4.
Flow of Events ..................................................................................................................................... 41
6.1.5.
Alternate Flow of Events ..................................................................................................................... 41
6.1.6.
Post Conditions ................................................................................................................................... 41
Page 3 of 50
Sean Robinson 2012
Get New Coordinates .............................................................................................................................. 42
6.3.
6.3.1.
Description .......................................................................................................................................... 42
6.3.2.
Actors .................................................................................................................................................. 42
6.3.4.
Preconditions ...................................................................................................................................... 42
6.3.6.
Flow of Events ..................................................................................................................................... 42
6.3.7.
6.3.8.
Post Conditions ................................................................................................................................... 42
6.4.
Get Lean................................................................................................................................................... 42
6.4.1.
Description .......................................................................................................................................... 42
6.4.2.
Actors .................................................................................................................................................. 42
6.4.4.
Preconditions ...................................................................................................................................... 42
6.4.6.
Flow of Events ..................................................................................................................................... 42
6.4.7.
6.4.8.
Post Conditions ................................................................................................................................... 43
6.5.
Get Pedal Difficulty Coefficient ............................................................................................................... 43
6.5.1.
Description .......................................................................................................................................... 43
6.5.2.
Actors .................................................................................................................................................. 43
6.5.4.
Preconditions ...................................................................................................................................... 43
6.5.6.
Flow of Events ..................................................................................................................................... 43
6.5.7.
6.5.8.
Post Conditions ................................................................................................................................... 43
7.
Sequence Diagram ........................................................................................................................................ 44
8.
Activity Diagrams .......................................................................................................................................... 45
9.
8.1.
Acceleration ........................................................................................................................................ 45
8.2.
Integration........................................................................................................................................... 46
8.3.
Distance ............................................................................................................................................... 46
8.4.
Position Plotting .................................................................................................................................. 47
8.5.
Lean Calculations ................................................................................................................................ 47
Conclusions ................................................................................................................................................... 48
Bibliography .......................................................................................................................................................... 49
1. INTRODUCTION
Following on from research previously carried out (1), this paper seeks to accumulate the gathered
information and refine the individual solutions before presenting an amalgamated solution to the
overall problem.
Page 4 of 50
Sean Robinson 2012
The initial stage of this paper will be comprised of the methodology used to develop the distinct
solutions into a completed system. Each of these stages will be carefully explained such that their
individual use and the way in which they fit into the general solution will be made clear.
Once the method has been successfully demonstrated, extensive testing and experimentation to
ensure accuracy throughout each stage will be completed and documented. The aim of this testing,
in addition to providing preliminary results, will be to form the basis of unit testing carried out on
the completed project in the development stage. By testing each component, this will translate into
either specific methods within classes or slightly higher level activities at a later stage.
The second part of this paper will serve as the completed design for the final system. Design will
take the form of a series of increasingly specialised documents and diagrams in order to provide a
full view of the completed system, from abstract concepts to program flow minutia.
The first document to be presented will be a user Specification; this will detail the exact nature of
the project including specific mechanics and more general constraints pertaining to client and
system requirements.
Beginning with a high level of abstraction, a Use case diagram will be developed and documented in
the form of a use case specification. As this project will have very limited user interaction, particular
emphasis will be placed on the activities taking place within each use case. Although these are not
strictly initiated by the user or another system, documenting a brief flow of events will be important
when specialising the design further.
Using the use case and specification, a sequence diagram will be developed that shows the
initialisation and interaction between classes throughout the chain of events described in the use
case specification. This will provide a graphical representation of events as they transpire within the
system. A sequence diagram is suited well to this task as the flow of events follow a linear path
through the different classes.
The lowest level of graphical description to be developed will be activity diagrams. Each activity
diagram will represent a distinct but significant section of calculations in the chain.
Throughout this design, a UML diagram will be built that represents a prototype of the system.
Testing scenarios will not be included as they will need to be developed as the build progresses in
the development phase. The UML will present the logic used in the engine and detail the
relationships that will be constructed between the different classes.
This paper will conclude with a detailed section reporting on the methods and experiments carried
out in the course of this design phase. Individual solutions, in addition to the general system, will be
examined and compared against other potential mechanisms. Any difficulties encountered in the
design of this solution will be documented here with solutions that will need to be incorporated into
the design before development.
Page 5 of 50
Sean Robinson 2012
2. REFINED EVALUATION OF SOFTWARE LANGUAGES AND DEVELOPMENT

PLATFORMS
PLATFORM AND LANGUAGE EVALUATION FOR USE IN

THE DEVELOPMENT OF A CONTINUOUS SIMULATION
SEAN ROBINSON
Page 6 of 50
Sean Robinson 2012
Abstract This document outlines to

necessary
qualities
and
technical
requirements for a project aimed at creating
a continuous simulation of a bicycle. The
programming
language
C++
and
development platform Visual Studio 2010 is
evaluated with these items in consideration.
This document concludes by indicating how
feasible it is to create this project using the
tools described and presents alternatives
should there be a more viable solution.
CONTENTS
1.
Introduction .................................................. 7
2.
Modularisation.............................................. 7
3.
Mathematical Formula ................................. 8
4.
Operating System.......................................... 8
5.
.DLL Files ....................................................... 8
6.
Conclusions ................................................... 8
Bibliography ............. Error! Bookmark not defined.
2.1.
INTRODUCTION
The C++ language (2) is under consideration as

it is one of the most widely used and powerful
tools available. While it can be used on a
variety of platforms, the dedicated IDE Visual
Studio (3) is the usual way in which to develop
with this language.
The criteria under consideration range from
fundamental technical requirements to more
abstract concepts that would benefit this
project.
Details such as modularisation,
support for mathematical formula, operating
system compatibility and the ability to
develop the solution as a .DLL file will all be
considered.
The research undertaken will evaluate the
way in which the language and platform
indicated support the different criteria. A
discussion regarding the effectiveness of this
support will conclude with the most feasible

solution.
Should these choices be deemed insufficient
for the needs, then other candidates will be
considered and subjected to a similar
feasibility test.
2.2.
MODULARISATION
The most critical factor in this project, with

regard to structure, is modularisation. Many
of the equations or solutions are highly
generalised and can be used for a variety of
different situations. In order to promote code
reuse within this project and also for
component reuse externally, it is important to
ensure that solutions remain distinct and
independent from the overall solution.
Through this, solutions can be reused for
different scenarios.
An example of this structure is integration.
When plotting the course of objects through a
simulation, integration is used to derive new
positions based on factors such as velocity
and current position. There are several
situations where integration can be used,
such as integrating the velocity based on
acceleration and position based on velocity.
To promote reuse, a general solution can be
developed and then used for both problems.
C++ supports modularisation in several ways.
The most fundamental structural advantages
here are methods and classes.
By
encapsulating general solutions in classes and
general equations into functions, either
internal or external to those classes, a library
of abstract solutions can be developed to
support both this application and others (4).
Modularisation also lends itself well to unit
testing.
By decomposing overarching
problems into individual and general tasks,
unit tests can easily be developed and applied
(5). This decomposition supports the project
methodology being applied elsewhere in the

application.
2.3.
MATHEMATICAL
FORMULA
It is important to note that this application
amounts to a limited scope physics engine
simply concerned with the propulsion and
steering of a bicycle. This in turn, indicates
significant use of mathematical and physical
mechanics. The language used to create this
application must be able to allow a developer
to make use of mathematical formula in order
to successfully model these equations.
It should be noted that this is an evaluation of
built in functionality and not simply the ability
to create the appropriate functionality using
the language.
Almost any language will support basic
arithmetic functions and it is unknown which
specific equations will need to be used until
further research has been undertaken. The
most basic requirements that can be
extrapolated initially include the use of
trigonometric functions for calculating the
gradient of a slope and possibly equations of a
circle for use with the steering methods.
Pre-existing libraries bundled with the C++
language provide extensive mathematical
ability that can be utilised throughout this
project (6). This reduces the volume of code
to be written and therefor, reduces elements
that require testing.
2.4.
OPERATING SYSTEM
The system that will be running this project is

Windows 7; the output of this project will
need to be in a format that this operating
system can use. In addition to running the
output, it is advisable to develop the solution
Page 8 of 50
in the operating system that it is being built

for.
As Visual Studio 2010 is a Microsoft product,
there is no difficulty in it running on their
standard operating system (7). It is also clear
that the output .DLL file will run with the
existing system, this is covered in more detail
under the following .DLL Files section.
2.5.
.DLL FILES
This project will generate a suite of classes

that provide the functionality specified.
Although they could simply be generated as
separate .CPP files, in order to provide a high
level of modularisation and protection for the
software, the solution will be built as a .DLL
file that can be used in the existing simulation
software.
Visual Studio 2010 provides functionality to
build a solution that outputs a .DLL file by
default (8). As long as the relevant access
points in the .DLL are properly exported and
the .DLL file is referenced within the existing
system, there is no difficulty and only a very
small difference in building the project in this
manner.
2.6.
CONCLUSIONS
It has been shown that the Visual Studio 2010

package in conjunction with the C++ language
is an ideal choice for building this project as it
satisfies all of the criteria indicated.
Modularisation was an important criterion to
consider so that the output of this project will
remain a protected, general solution with
extended elements pertinent to this specific
case. It has been found that C++ meets these
needs very well.
Support for mathematical formula has been
found to be extensive and more than capable
for the needs of this project.
Sean Robinson 2012
The development criteria required of the

Visual Studio 2010 package indicated that an
output be compatible with Microsoft
Windows 7 and have the ability to develop
the solution as a .DLL file. This paper has
documented that the chosen platform does
indeed conform to these standards.
Page 9 of 50
Based on the satisfactory way in which both

the language and platform chosen fulfil the
criteria indicated, this project will be
developed in C++ using the Visual Studio 2010
package. The solution will be built as a .DLL
file and then referenced in the existing
simulation package.
Sean Robinson 2012
3. EXTENDED RESEARCH
CREATING A CONTINUOUS AND INTERACTIVE

SIMULATION USING BICYCLE DYNAMICS AND
ACCURATELY MODELLED ENVIRONMENTAL FACTORS
SEAN ROBINSON
Page 10 of 50
Sean Robinson 2012
Abstract Following on from the work

completed in a previous paper, where the
specific dynamics and mechanics of
particular problems were investigated, this
paper sets out to compile these results and
demonstrate the significant steps needed to
be taken in order to develop a coherent
model.
Each stage required will be
introduced and explained before a
demonstration that shows the solution in
practice is given. These demonstrations and
experiments show how it is possible to
model a bicycles dynamics to a high degree
of accuracy in a limited scope and then
interact with the model using accurately
modelled environmental factors. This paper
will document the logical enhancements that
could be taken in order to extend the project
and then conclude with a summary of the
work.
TABLE OF CONTENTS
1.
Introduction ................................................ 11
2.
Defining Constants ...................................... 11
3.
Calculating Velocity ..................................... 12

I.
Power...................................................... 12
II.
Surface Friction ....................................... 12
III.
Braking .................................................... 12
IV.
Slopes ..................................................... 13
V.
Watts to Overcome Gravity .................... 13
VI.
Watts to Overcome Surface Friction ...... 13
VII.
Watts to Overcome Air Resistance .... 13
VIII.
Final Power Output ............................ 14
IX.
Calculating Acceleration ......................... 14
4.
Integrating Velocity ..................................... 17
5.
Calculating Lean .......................................... 20
6.
Calculating Steering Angle .......................... 24
7.
Integrating and Mapping Movement.......... 27
8.
Enhancements ............................................ 29
9.
Conclusions ................................................. 29
Bibliography ............. Error! Bookmark not defined.
3.1.
INTRODUCTION
Whereas the previous report was focussed

almost exclusively on finding solutions to
problems, this paper documents the timeline
that was taken in order to pipe those
solutions together. In some respects it is
more difficult to concatenate solutions
together as there is not usually an existing
perfect solution, the solution needs to be
developed dynamically for the particular
problem.
This paper takes a linear format as that is the
way in which the experiments were
completed. As each experiment is reliant on
previous work completed, it is necessary that
problems are accurately solved before moving
on. Some issues that were solved were found
to be simply too complicated or costly and it is
recommended that these are avoided in
favour of more simple solutions.
The experiments were simply completed in a
Microsoft Excel Workbook as this provided
immediate and clear results that could be
plotted to give a visual representation of
exactly what was happening. This workbook
can also form a core component of any testing
modules for work that expands on the basic
demonstrations given here.
Each experiment takes place over 30 steps
using a randomised delta based on 0.1
seconds. Using a randomised delta allows the
experiment to mimic to difference in screen
refresh rates if the model was developed for a
computer.
3.2.
DEFINING CONSTANTS
To provide a more interactive and dynamic set

of experiments, a single page in the workbook
was created to house the constants used
throughout the work. These constants range
from fundamental constants such as
acceleration due to gravity on earth, to more
technical data such as the bicycles wheelbase

length, to more arbitrary factors such as an air
resistance coefficient.
As this paper progresses, it will becomes clear
what each of these constants represent.
It is also important to note that by having a
single cell that is used throughout, it is easy to
modify certain factors to see immediate
changes in results. It would be the work of
seconds to see how doubling the riders
weight affects acceleration on a slope or how
much wind resistance would be required to
bring the rider to a complete stop.
Wheelbase
Caster Angle
Gravity
Centre of mass height
Tyre Thickness
Velocity
Dt
Randomise
Weight of Object
Maximum
Deceleration
Air Resistance
115
18
9.82
66
2.5
10
0.1
1
80
cm
Degrees
m/s/s
cm
cm
m/s
s
Boolean
kg
0.5 G
0.7 Coefficient
3.3.
CALCULATING
VELOCITY
3.3.1. POWER
The first item to consider when modelling the
propulsion of an object is the amount of
power that is being fed into it. On a bicycle
this is the amount of watts generated by the
cyclist pedalling. It would easy to simply forgo
this and use an arbitrary value for
acceleration but in order to accurately model
and allow for hardware integration, a power
output should first be defined. Based on
research by Coggan (9), a value of 100 watts
for an experienced cyclist has been used. This
Page 12 of 50
is achieved through 25 watt increases initially

to approximate a build up as pedalling
commences.
3.3.2. SURFACE FRICTION

Surface friction is a difficult thing to model in
a limited example as each surface will have a
very different coefficient for the friction
applied. In this limited experiment, a value of
0.1 has been used for a flat road based on
work by May (10).
In a more developed project, this value can
easily be changed to reflect the surface
currently being used. This could either be an
arbitrary value that seems to give an
appropriate feel or something more accurate
that has been researched.
3.3.3. BRAKING
Braking can be modelled in many different
ways. In bicycles, the brake force applied to a
machine is the result of friction generated
between the brake pad and wheel. In a
simplistic model, the velocity could simply be
reduced by a fraction of a certain value
defined as maximum brake.
In a more complex model, the brake force
could be modelled in a specific measure
relative to the actual physics, such a G
(gravity) or Newtons. In this model, the brake
force if modelled in gravities.
Should a user be allowed to apply excessive
braking then it will be quite likely that a crash
will occur at some point as the bicycle will
decelerate too quickly. As this is not a
concern of the basic model described here, a
maximum safe brake value has been defined
as 0.5g has been used based on a report by
Whitt and Wilson (11). Any brake measure
applied will be considered a fractional value of
its maximum, which is then applied to the
0.5g value in order to determine a brake force
Sean Robinson 2012
in gravities that need to be used to reduce the

velocity.
3.3.4. SLOPES
In this experiment, a slope was defined simply
by specifying a percentage; this percentage is
a fraction of angle defined on a road ranging
from 0 with a horizontal plane to 100 with a
fully vertical surface. Conversely, the value
can also be defined as a negative which is
indicative of a slope that is being travelled in a
downward direction. In order to output a
visual representation, this slope was tallied in
a separate column that provided a general
overview of how the landscape changed
within the experiment.
3.3.5. WATTS TO OVERCOME

GRAVITY
Following on from the slope definition is
something that directly affects the velocity
because of it. Gravity is apparent from any
cycling situation but it begins to affect the
machine and rider depending on the
steepness of the hill currently being traversed.
Travelling up a hill will increased the
gravitational pull, travelling downwards will
do the inverse and the rider will find himself
being pulled forwards. In this model, the
force isnt actually calculated but a value of
watts is given in the calculation below. This is
the amount of watts that should be
subtracted from the initial power in order to
compensate for the effect of gravity. Positive
and negative values are both used. The
formula, given by May (10) is:
=
Where:
G: Standard acceleration due to gravity
P: Weight of object is kg
: Slope Percentage
V: Current velocity in m/s
Page 13 of 50
3.3.6. WATTS TO OVERCOME

SURFACE FRICTION
Surface friction has already been discussed
and explained. Similarly to gravity, a formula
has been used to identify the amount of watts
required to overcome this friction. Provided
again by May, the formula is:

= .
Where:
0.1: Friction coefficient
P: Weight of object is kg
3.3.7. WATTS TO OVERCOME AIR

RESISTANCE
The final subtraction of power in the model
comes in the form of air resistance. Air
resistance plays a huge role in cycling and is
an important factor to consider when
attempting to model accurately. It would be
outside the scope of this project to determine
a truly valid coefficient for wind resistance so
0.7, a value based on work by May (10) has
been used in addition to the rest of the
formula for calculating the watts required to
overcome the resultant force. This formula
has been simplified as wind is not being
considered in this project, the referenced
website has further information that can be
used for an expanded model.
= ( )
Where:
: Air resistance coefficient
Sean Robinson 2012
object and a force acting upon it. Using the

following formula (12), this can be calculated:
3.3.8. FINAL POWER OUTPUT

=
The final power if what remains once all

subtractions for environmental factors have
been applied. The formula is simply:
Where:
f: Force
m: Mass
=

Where:
w: Power output in watts
p: Initial power output from pedalling
: Watts to overcome gravity
wf: Watts to overcome friction
wa: Watts to overcome air resistance
With regard to propulsion of an object, this is

the final step of the section. If a basic
integration method was being used, then this
acceleration could be simply added to the
existing velocity, which then could be used to
calculate the new position using an Euler
integration (13). As a runge-Kutta4 method is
going to be used, there is much more work to
be done in order to fully utilise the results so
far so this will be covered in the next section.
Below is the final datasheet from the excel
workbook that shows how user modified data
in the left columns propagate throughout the
rest.
3.3.9. CALCULATING
ACCELERATION
Acceleration was the goal of this section of
experimentation, a value that could be used
throughout further experiments that allowed
for the propulsion of an object.
The
acceleration is calculated using the mass of an
Power
Friction
Brake
Slope%
Veloc (m/s)
Gravity w
Friction w
Air Res w
Final P (w)
Accel (m/s)
0.1
25
0.1
25
0.3125
50
0.1
0.3125
2.5
0.021362305
47.4786377
0.593482971
75
0.1
0.905982971
7.24786377
0.520544838
67.23159139
0.840394892
100
0.1
1.746377864
27.43908899
13.97102291
3.728315818
54.86157228
0.685769654
100
0.1
2.432147517
38.21390179
19.45718014
10.07088828
32.2580298
0.403225372
100
0.1
2.83537289
44.54937884
22.68298312
15.95616754
16.81147051
0.210143381
100
0.1
3.045516271
47.85115165
24.36413017
19.77337543
8.01134275
0.100141784
100
0.1
3.145658055
49.42457936
25.16526444
21.78876296
3.621393228
0.045267415
100
0.1
3.190925471
50.13582099
25.52740377
22.74301417
1.59376107
0.019922013
100
0.1
3.210847484
50.44883567
25.68677987
23.17165592
0.692728541
0.008659107
100
0.1
3.219506591
151.7546627
25.75605273
23.35963193
-100.8703473
-1.260879342
100
0.1
1.958627249
92.32185402
15.66901799
5.25960848
-13.2504805
-0.165631006
100
0.1
1.792996243
84.51467091
14.34396994
4.034931616
-2.893572474
-0.036169656
100
0.1
1.756826587
82.80977801
14.0546127
3.795637475
-0.660028183
-0.008250352
100
0.1
1.748576235
82.42088941
13.98860988
3.742413358
-0.151912643
-0.001898908
100
0.1
1.746677327
82.33138248
13.97341861
3.730234105
-0.035035196
-0.00043794
100
0.1
1.746239387
82.31073974
13.96991509
3.727428992
-0.008083826
-0.000101048
100
0.1
1.746138339
13.96910671
3.726781956
82.30411133
1.028801392
Page 14 of 50
Sean Robinson 2012
100
0.1
-6
2.774939731
-130.7995591
22.19951785
14.95748945
193.6425519
2.420531898
100
0.1
25
-6
5.070471629
-239.0017507
40.56377303
91.25215113
207.1858265
2.589822832
100
0.1
25
-6
7.535294461
-355.1836397
60.28235568
299.5013087
95.39997532
1.192499692
100
0.1
25
-6
8.602794152
-405.5013052
68.82235322
445.6733175
-8.994365601
-0.11242957
100
0.1
50
-6
8.240364582
-388.4178249
65.92291666
391.685343
30.80956527
0.385119566
100
0.1
50
-6
8.375484148
-394.7868208
67.00387318
411.2707309
16.51221671
0.206402709
100
0.1
25
-6
8.456886857
-398.6238189
67.65509485
423.3792808
7.589443211
0.09486804
100
0.1
8.551754897
68.41403918
437.7879212
-406.2019604
-5.077524505
100
0.1
3.474230392
27.79384313
29.35444578
42.85171108
0.535646389
100
0.1
4.00987678
32.07901424
45.13267992
22.78830584
0.284853823
100
0.1
4.294730603
34.35784483
55.45054522
10.19160995
0.127395124
100
0.1
4.422125728
35.37700582
60.53287459
4.090119592
0.051126495
This data was mapped to several graphs in order to obtain an overview of the output. Some of the
more significant show the correlation between velocity and the height of a slope or the amount of
acceleration given by certain amounts of power in watts.
Height
60
50
40
30
Height
20
10
0
1
Page 15 of 50
11 13 15 17 19 21 23 25 27 29
Sean Robinson 2012
Velocity (m/s)
10
9
8
7
6
5
Velocity (m/s)
4
3
2
1
0
1
9 11 13 15 17 19 21 23 25 27 29
Final Power (w)

300
200
100
0
1
-100
-200
-300
-400
-500
9 11 13 15 17 19 21 23 25 27 29
Final Power (w)
Acceleration (m/s)
3
2
1
0
-1
5 7
9 11 13 15 17 19 21 23 25 27 29
Acceleration (m/s)
-2
-3
-4
-5
-6
3.4.
INTEGRATING VELOCITY
Using a base velocity calculated by adding the

acceleration to the previous velocity and
subtracting the deceleration due to braking,
the distance an object moves can be
calculated by integrating the velocity using
the Runge-Kutta 4 method developed by
Runge (14) and then modified by Kutta (15) .
RK4 is usually used to integrate a position but
can become very complex when using
multiple variables; a good balance can be
achieved by using RK4 to integrate the
velocity based on a differing delta time and by
then using a simple Euler to calculate the
distance moved.
The RK4 method works by taking several
derivatives of a value in a given time step and
then summing them using weights. This then
gives a good approximation of what the
velocity will be (16).
The first step is to calculate the derivatives.
Each derivative has a slightly different formula
but the one used here is as follows:
D2:
(2( + 0.5"1)$ + (%&.'() )

D3:
(2( + 0.5"2)$ + (%&.'() )

D4:
(2( + "2)$ + (%&.'() )
D1:
(2 + )
Where:
t: Delta Time
T: Current Time
D1: Derivative 1
D2: Derivative 2
D3: Derivative 3
D4: Derivative 4
e: Constant
This integrated velocity is now used in a basic

Euler by multiplying the current distance
moved by the derived velocity squared.
The derived velocity can now be calculated

using the following formula
*+ = + ,
dt
0.119469
0.015962
0.075284
0.037452
0.146287
0.139759
0.079715
0.076205
0.176485
0.16561
0.181669
0.103211
0.136179
0.121356
0.115821
0.12158
0.157394
0.082432
0.086196
0.172084
0.093859
0.047556
0.140591
0.053788
0.042478
0.114501
0.035488
0.188078
0.183596
"1
"2
"3
"4
.+, .+, .+, .
6
3
3
6
Time
Position
0
0.119469
0.135431
0.210715
0.248167
0.394454
0.534213
0.613928
0.690133
0.866618
1.032229
1.213898
1.317109
1.453288
1.574643
1.690464
1.812044
1.969438
2.05187
2.138066
2.31015
2.404009
2.451565
2.592156
2.645943
2.688421
2.802922
2.83841
3.026488
1
1.010457734
1.010577262
1.124207402
1.872906372
3.364996098
5.670564296
9.7632255
14.40583602
16.77196004
19.33180658
21.63840049
25.6630501
27.38580863
29.01672769
30.64073508
32.20963235
33.54231542
35.43910112
37.29940996
39.45501925
46.51701066
67.2604288
67.34025614
87.30281102
113.0938629
115.0140314
145.7179848
148.0187054
Page 18 of 50
Velocity
0
0
0.3125
0.905983
1.746378
2.432148
2.835373
3.045516
3.145658
3.190925
3.210847
3.219507
1.958627
1.792996
1.756827
1.748576
1.746677
1.746239
1.746138
2.77494
5.070472
7.535294
8.602794
8.240365
8.375484
8.456887
8.551755
3.47423
4.009877
In this manner, thought slightly convoluted in

parts, it is possible to obtain the accuracy of
using RK4, keep the cost of the program down
by using more basic approaches where
possible and obtain a solid value of distance
moved that can be used to accurately indicate
where the object is going to be at the next
step.
Below is the datasheet used to calculate the
integration during the experiment.
d1
0.119469
0.011154
0.003095
-0.04796
-0.44146
-0.63703
-0.43599
-0.45209
-1.08806
-1.0446
-1.15841
-0.66187
-0.53083
-0.43363
-0.40593
-0.42442
-0.54915
-0.28767
-0.30084
-0.95476
-0.95173
-0.71666
-2.41886
-0.88644
-0.71153
-1.9366
-0.60696
-1.30681
-1.47238
d2
0.099016
0.010889
0.029943
-0.03945
-0.6252
-1.21403
-1.07795
-1.2008
-2.37198
-2.34921
-2.51006
-1.72004
-0.77871
-0.60169
-0.55843
-0.57332
-0.68163
-0.42312
-0.4388
-1.81656
-3.96273
-4.89909
-15.3699
-6.54006
-5.46399
-12.8421
-4.82873
-2.99306
-3.9352
d3
d4
0.099283 0.097513
0.010889 0.010886
0.028646 0.02727
-0.04002 -0.03735
-0.54566 -0.36602
-0.8964 -0.62454
-0.8265 -0.62915
-0.90042 -0.69053
-1.33843 -1.13575
-1.33699 -1.12883
-1.3836 -1.20688
-1.14687 -0.88443
-0.66858 -0.45113
-0.53911 -0.38031
-0.50489
-0.3622
-0.51904 -0.36696
-0.62162
-0.3979
-0.38809
-0.3039
-0.40167 -0.31145
-1.199 -0.85455
-1.79124 -2.01853
-2.46003
-2.4499
-0.23682 -19.6798
-2.65754 -3.35287
-2.70574 -2.73098
-0.94909 -12.9081
-2.67346
-2.4525
-1.47123 -1.50911
-1.5315
-2.2554
dv
0.102263
0.010933
0.337091
0.865274
1.221511
1.51841
2.023033
2.154672
1.538221
1.599952
1.518747
2.006153
1.312539
1.277074
1.274365
1.252556
1.154419
1.377238
1.363931
1.468199
2.657441
4.554494
-0.28254
4.467948
5.078489
1.385701
5.541115
1.516813
1.566344
Sean Robinson 2012
0.195959 3.210084 150.4721404 4.294731

0.142212 3.406043 152.5640436 4.422126
Graphing this data can give a clear indication
of what is happening over time. The following
graphs indicate the movement of an object
over the steps based on the velocity shown.
The derived velocity is also given for
-1.68317
-1.25775
-4.6733
-4.0925
-1.50263
-1.60551
-3.05531 1.446341
-2.25642 1.937094
comparison. A correlation can be mapped

here that shows a higher velocity will push the
position of an object further from the origin at
a greater speed.
Position
160
140
120
100
80
Position
60
40
20
0
1
9 11 13 15 17 19 21 23 25 27 29 31
Velocity
10
9
8
7
6
5
4
3
Velocity
2
1
0
1
Page 19 of 50
9 11 13 15 17 19 21 23 25 27 29 31
Sean Robinson 2012
dv
6
5
4
3
2
1
dv
0
-1
11 13 15 17 19 21 23 25 27 29 31
-2
-3
-4
3.5.
CALCULATING LEAN
The lean, or Yaw, of an object is the amount

of angle by which it is rotated about a virtual
line drawn along the Z axis at the lowest part
of the plane.
For humans, this would
represent the angle our bodies make to the
perpendicular when swaying to either side.
The lean of a bicycle can be thought of in the
same way. As a machine goes around a
corner, a certain degree of leaning is
inevitable and this can be calculated.
Left
Turn
Right
Turn
0
5
5
0
15
5
8
0
0
0
0
Page 20 of 50
Change in
Steering
0
0
0
3
0
0
0
14
10
10
5
To provide some level of interactivity and

dynamism, functionality allowing users to
alter the angle of steering was provided. This
meant that at each step, or row, a certain
amount of steering could be applied either
left or right. These angles referred to a
change in steering, not the actual angle. From
here, the new angle was calculated. The
workbook that details the steering is quite
large so each section will be displayed
individually in order to provide easier viewing.
Steering
Angle
0
-5
-5
3
-15
-5
-8
14
10
10
-3
0
-5
-10
-7
-22
-27
-35
-21
-11
-1
4
Sean Robinson 2012
0
0
0
6
8
11
5
9
6
0
0
0
0
0
0
0
0
0
0
0
5
10
3
0
0
0
0
0
0
9
0
4
0
9
2
0
3
0
6
2
-5
-10
-3
6
8
5
-5
-9
-6
9
0
4
0
9
0
0
-3
0
-6
-2
In order to calculate the lean, something

called the radius of the turn needed to be
known. The radius of the turn is the radius of
an imaginary circle drawn based on the angle
of the steering. With the steering at a certain
angle and with a flat plane to experiment
with, riding a bicycle while maintaining the
angle will eventually lead the rider back to the
origin. This can visualised by imagining the
rider leaving a mark from the tyres wherever
they go.
When the radius of a circle is
mentioned in relation to steering in this
paper, metres is the measurement being
considered.
The upright turn radius of a circle is the radius
that would be made based on a bicycle with
no lean. This is simply a starting point and
gives a base to work with for refinement. The
formula, given by Sharp (17) is:
1 =
Where:
Page 21 of 50

345 ()
9
19
22
16
8
-3
-8
-17
-23
-14
-14
-10
-10
-1
1
1
4
4
10
12
r: Radius
w: Wheelbase in cm
: Steering Angle
: Caster Angle
The ideal lean can now be calculated. Ideal
here means ideal tyres and centre of mass,
infinitely slim and low respectively. As this is
never the case, a more developed solution is
required. This is a modification of the answer
given by the ideal lean formula given by
Fajans (18).
:;
= 1389( )
1
Where:
: Lean
v: Velocity
g: Acceleration due to gravity
r: Upright turn radius
The modification mentioned previous is a way
of giving the increase the lean should take as
a result of tyre and centre of mass
Sean Robinson 2012
considerations. The output of this formula is

added to the ideal lean in order to give a more
accurate representation. The formula, given
by Cossalter (19), is:
135<9 (. =8
5<9()
)
> . =8
Where:
: Caster Angle
t: Tyre thickness in cm
h: Centre of mass height
1 =
For the sake of this demonstration, the tyre

thickness has been given as 2.5cm. This was
simply the output from a brief averaging of
several tyres and types. The centre of mass,
given by h, was decided upon using a similar
measure.
The value now given is the amount of lean, or
yaw, which the object being modelled will
Upright Turn Radius
0
34.83177044
17.41588522
24.87983603
7.916311464
6.450327859
4.975967206
8.293278676
15.83262293
174.1588522
43.53971305
19.35098358
9.166255379
7.916311464
10.88492826
21.76985653
58.05295074
21.76985653
10.24463837
7.572124009
12.43991801
12.43991801
Page 22 of 50
need to be rotated by in order to map closely

to real world dynamics. A final value was
calculated that was to be an experiment in
how far it is realistically possible to pursue
accuracy in a limited model such as this. The
lean of a bicycle affects the radius of its
turning circle by a small amount. The new
radius was calculated using a formula given by
Cossalter (19).
Ideal Lean
0
0
0.000571009
0.003359537
0.039212037
0.093116958
0.163063977
0.113400991
0.063558452
0.005953483
0.024107832
0.05449215
0.042592919
0.041331104
0.028866895
0.0143012
0.005351622
0.014263006
0.03029816
0.103188813
0.207431862
0.435097909
345(?)
345 ()
: Caster Angle
w: Wheelbase in cm
: Steering Angle
a: Lean
The relevant sections of the data sheet are

included below:
Lean Increase Lean

Final Radius
0
0
0
0
0 34.83177044
-2.3402E-05 0.000547607 17.41588261
-0.000137686 0.003221851
24.8797069
-0.00160664 0.037605398 7.910714635
-0.003810765 0.089306193 6.424622346
-0.006653422 0.156410555 4.915224511
-0.004637643 0.108763348 8.244274485
-0.002603104 0.060955348 15.80321855
-0.000243994
0.00570949 174.1560136
-0.00098793 0.023119902 43.52807693
-0.002232182 0.052259968 19.32456481
-0.001745085 0.040847835 9.158609285
-0.001693416 0.039637688 7.910093436
-0.001182905
0.02768399 10.88075741
-0.000586095 0.013715105 21.76780906
-0.000219328 0.005132294 58.05218617
-0.00058453 0.013678476 21.76781998
-0.001241538 0.029056622 10.24031396
-0.004221561 0.098967252 7.535071618
-0.008440571 0.198991291 12.19443463
-0.017275416 0.417822493 11.36977004
Sean Robinson 2012
17.41588522
17.41588522
174.1588522
174.1588522
174.1588522
43.53971305
43.53971305
17.41588522
14.51323768
0.408403976
0.377953275
0.040993918
0.04179372
0.042735516
0.028223109
0.037588967
0.107433427
0.136358722
-0.016277156
-0.015124305
-0.001679609
-0.00171236
-0.001750923
-0.001156531
-0.001540169
-0.004394558
-0.005571199
0.392126819
0.36282897
0.039314309
0.040081361
0.040984592
0.027066577
0.036048798
0.103038869
0.130787524
16.09399126
16.28205025
174.0242783
174.0189765
174.0126022
43.52376544
43.51142584
17.32351469
14.38928732
200
180
160
140
120
Upright Turn Radius
100
Final Radius
80
60
40
20
0
1
11 13 15 17 19 21 23 25 27 29 31
0.5
0.45
0.4
0.35
0.3
Ideal Lean
0.25
Lean
0.2
0.15
0.1
0.05
0
1 2 3 4 5 6 7 8 9 10111213141516171819202122232425262728293031
Page 23 of 50
Sean Robinson 2012
200
150
100
50
Change In Radius
Change in Steering
0
1
11 13 15 17 19 21 23 25 27 29 31
-50
-100
-150
From the visual representation, it is very clear

that the difference between ideal and actual
lean is very small, as is the difference between
the initial radius and the final radius. These
changes are very small and will go unnoticed
in almost every application using these
equations. Unless a very high degree of
accuracy is required, there is little point in
making use of the full set.
3.6.
CALCULATING
STEERING ANGLE
As the radius of the turn changed slightly due
to the lean of the bicycle, it is apparent that
the angle of rotation will also be different. In
order to calculate this new angle, an
experiment was devised. The aim of the
experiment was to derive a new point on the
virtual circle based on the distance travelled
in the step. By taking the angle between this
new point and the origin, which would be the
top point of the circle at X = 0, Y = Radius, it
would be possible to accurately model the
slight change.
Despite several days of experimentation, this
method was never conclusively proved.
Discrepancies between the new derived angle
and the original steering angle were too large
to ignore. This coupled with the vast amount
Page 24 of 50
of time being tunnelled into the solution and

with the possibility of a very small return but
huge costs associated meant that the pursuit
of the solution was abandoned. The method
used to arrive at the results shown later will
not be detailed.
The first step in completing this was to derive
a new point based on the distance travelled;
the new point would be a new point on the
circumference of the virtual circle. The new
point was derived using formula from
MathWarehouse (20).
5 = 1@
A: Arc length
r: Radius
: Inner angle between both points in radians
With this inner angle, the new point could be
derived using the parametric equation of a
circle. An offset was then applied in order to
ensure the point had moved in the correct
direction around the circumference. The two
points now represented a coord across the
virtual circle and a tangent was given by the
original point. The coord tangent equation
given by Warendorff (21), states that the
angle between a coord and an angle is half of
the inscribed angle between the points. This
Sean Robinson 2012
means that by halving the angle already

calculated, the angle between the points
could be obtained.
At this point, the new angle showed large
differences to the original and could not be
consolidated despite attempting several
x1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
tweaks and rebuilds. There is no doubt a way

to realise this solution, but considering the
extra cost and complexity for such a small
reward in a small project indicates that the
matter should not be pursued further.
The relevant data is given below.
y1
Distance
In Angle
x2
y2
Angle
0
34.83177044
17.41588261
24.8797069
7.910714635
6.424622346
4.915224511
8.244274485
15.80321855
174.1560136
43.52807693
19.32456481
9.158609285
7.910093436
10.88075741
21.76780906
58.05218617
21.76781998
10.24031396
7.535071618
12.19443463
11.36977004
16.09399126
16.28205025
174.0242783
174.0189765
174.0126022
43.52376544
43.51142584
17.32351469
14.38928732
0
2.72365E-06
0.007671051
0.129164651
0.748529241
3.007668784
1.903198808
3.097967283
2.505435053
8.917113432
7.996715297
5.326940935
4.016425364
1.383989933
1.854653751
2.169375502
1.236323776
1.393239209
2.500530828
1.140764954
5.988721
2.865699468
0.189352234
1.803351402
17.67808631
6.62304149
0.762456583
1.493802479
11.89277748
12.81166186
4.241694814
0
4.48249E-06
0.025249469
0.297605718
5.424202687
26.8364621
22.19645682
21.54106847
9.08825408
2.935139
10.53137339
15.8019621
25.13929105
10.02984391
9.771170056
5.71298218
1.220833672
3.669049812
13.99786492
8.678639387
28.15238985
14.44846862
0.674449643
6.349128663
5.823287949
2.181743661
0.251175499
1.967476581
15.66833452
42.39477319
16.89829901
0
-2.7237E-06
-0.00767105
-0.12916523
-0.74964572
-3.11633219
-1.95040058
-3.17036212
-2.51591747
-8.92100915
7.951808532
5.259734204
3.888919047
1.376939439
1.845685906
2.165786218
-1.23641723
-1.39419027
-2.52530642
-1.14511771
-6.22656322
-2.89594476
-0.1893566
-1.80703613
-17.7084749
6.621442682
0.762454144
1.493509221
11.74525113
11.67532036
4.180530049
0
34.83177044
17.41588092
24.87937162
7.875327307
5.733370743
4.55134123
7.669026873
15.60502893
173.927777
42.79558648
18.59499937
8.291949872
7.789327054
10.72307443
21.65979874
58.03902182
21.72324838
9.93653189
7.448883917
10.75321483
11.01053452
16.09287737
16.18228539
173.1271446
173.8929575
174.0109318
43.49813316
41.89622005
12.79808797
13.76861497
0
2.24124E-06
0.012624735
0.148802859
2.712101343
13.41823105
11.09822841
10.77053424
4.54412704
1.4675695
5.265686694
7.900981052
12.56964553
5.014921957
4.885585028
2.85649109
0.610416836
1.834524906
6.998932459
4.339319693
14.07619493
7.224234311
0.337224821
3.174564332
2.911643975
1.09087183
0.12558775
0.983738291
7.83416726
21.19738659
8.449149507
Page 25 of 50
Diff
0
4.999998
9.987375
6.851197
19.2879
13.58177
23.90177
10.22947
6.455873
0.46757
1.265687
1.099019
6.430354
16.98508
11.11441
5.143509
2.389583
6.165475
10.00107
18.66068
0.076195
6.775766
9.662775
6.825436
1.911644
0.090872
0.874412
3.016262
3.834167
11.19739
3.55085
Sean Robinson 2012
15
10
5
0
-5
11 13 15 17 19 21 23 25 27 29 31
x1
x2
-10
-15
-20
-25
-30
200
180
160
140
120
100
y1
80
y2
60
40
20
0
1
11 13 15 17 19 21 23 25 27 29 31
40
35
30
25
Angle
20
Original
15
10
5
0
1
9 11 13 15 17 19 21 23 25 27 29 31
Despite there being a very close correlation

between the derived Y values and a broad
Page 26 of 50
Sean Robinson 2012
correlation between the original angle and

the angle considering lean, it is recommended
to use the angle of steering for these
calculations.
3.7.
INTEGRATING AND
MAPPING MOVEMENT
dt
0.068843953
0.074739419
0.022569843
0.021356104
0.076438383
0.014518368
0.025705863
0.114520799
0.06889548
0.127438314
0.023090648
0.180005126
0.029316446
0.118324639
0.025785655
0.10360612
0.100718349
0.002857348
0.044747185
0.188248492
0.065680894
0.169819225
0.120381681
0.107851001
0.126320329
0.077535861
0.087319371
0.19686197
0.051299809
0.064542392
Page 27 of 50
Time
0
0.068843953
0.143583373
0.166153216
0.18750932
0.263947703
0.278466071
0.304171934
0.418692733
0.487588213
0.615026526
0.638117175
0.818122301
0.847438747
0.965763386
0.991549041
1.09515516
1.19587351
1.198730858
1.243478042
1.431726534
1.497407428
1.667226654
1.787608334
1.895459335
2.021779665
2.099315526
2.186634897
2.383496867
2.434796677
Angle
0
-5
-10
-7
-22
-27
-35
-21
-11
-1
4
9
19
22
16
8
-3
-8
-17
-23
-14
-14
-10
-10
-1
1
1
4
4
10
The final stage in this process is to actually

plot some points to demonstrate the
movement. Movement is considered to be
the distance and direction travelled to the
next point. The angle of the turn and distance
travelled in the current dt is already known so
the new point can be calculated using the
parametric equation of a circle and then
adding the previous position, which will act as
the origin.
Movement
0
0.003972623
0.003054153
0.102812872
0.781158696
2.045595522
5.255263349
6.339302551
3.544323525
5.182484641
3.371261219
8.06788396
2.354997378
3.146233466
1.667161222
2.630018933
1.717853055
1.736843071
2.993869404
2.327484513
1.9700843
9.998422682
0.161225934
0.852591764
3.554743207
0.617145321
11.20717209
8.015844019
2.160636998
8.62022407
0
-0.000346062
-0.000876144
-0.013399561
-0.305885767
-1.234131248
-4.247093188
-6.517796338
-7.193746519
-7.284147499
-7.04909923
-5.78763868
-5.021300878
-3.843268943
-3.383963912
-3.018120376
-3.107980321
-3.349580411
-4.22447245
-5.133457079
-5.609826812
-8.027462416
-8.055444957
-8.203421671
-8.265429046
-8.254663835
-8.059170859
-7.500296855
-7.349654721
-5.853519662
0
0.003957521
0.006965322
0.109012618
0.833347296
2.65620806
6.962001044
12.88067184
16.35994197
21.54163809
24.90469541
32.87335081
35.10017344
38.01753968
39.62018294
42.22463262
43.9401338
45.66009114
48.52327432
50.66592014
52.57754354
62.27926989
62.43804892
63.27770099
66.83190334
67.44895477
78.65442168
86.65075929
88.80613842
97.29553433
Sean Robinson 2012
Angle
30
20
10
0
1
9 11 13 15 17 19 21 23 25 27 29
Angle
-10
-20
-30
-40
X
1
0
1
11 13 15 17 19 21 23 25 27 29
-1
-2
X
-3
-4
-5
-6
Y
140
120
100
80
Y
60
40
20
0
1
Page 28 of 50
11 13 15 17 19 21 23 25 27 29
Sean Robinson 2012
The graphs above clearly show the movement

between data points based on the criteria
previously explained. By comparing the X and
Angle graphs, it becomes apparent that
altering the angle of the steering has an effect
on movement, but even a sudden alteration
still describes a smooth curvature. This is an
ideal result as it satisfies many criteria with
regard to accuracy of dynamics but also
outputs a model that is highly indicative of
what would be expected.
3.8.
ENHANCEMENTS
Despite overall success in the experiments

detailed here, there have been some sections
that presented substantial difficulty.
A
complete solution would be providing proof
of the improved turning equations. Despite
the differences being too large, there is still
something to be gained for truly accurate
models if the problem can be solved or
conclusively proved.
Although the transition of the object can be
clearly tracked over the graphs, there are
issues that limit the model. The Z axis has
been completely ignored in this paper as the
values for it have no bearing on the research.
Converting to three dimensions requires the
alteration of the current Y axis becoming the
new Z component and a new Y set being
established to hold vertical data. At every
point in this model, the vertical component
will just be the height of the terrain currently
being used. As the equations are calculated
using the slope before any integration occurs,
the propulsion of the object has already
factored the modifications required by the
terrain. The object is then moved by the
specified amount in the indicated direction.
Improving on this would mean a substantial
overhaul to much of the system but would
allow the bicycle to potentially leave the
ground in moments of severe terrain by
utilising equations of inertia and momentum.
A final point to make is that a second run of

RK4 could be used to integrate the actual
movement more accurately. Although the
velocity
is
already
integrated,
as
demonstrated by the smooth curvature,
further refinement could be achieved with
little added cost.
3.9.
CONCLUSIONS
This paper detailed the pipeline of equations

and calculations necessary to model the core
features of a bicycle. Power is the first thing
needing to be calculated, this is a value
determined by the power being put in to
something minus the power being taken out.
These factors are usually the riders pedal
power and any environmental factors.
It was then shown how this power gave an
acceleration, which could then be integrated
using RK4 to give a measure of distance that
would be traversed during the current delta
time step.
The third stage was steering. The lean of the
bicycle was demonstrated to be easily
calculable but the addition of further
equations and complexity meant that choices
should be made with regard to specific
problems.
This paper recommends that
unless a very high level of accuracy to real
world dynamics is paramount, more basic
measures will easily suffice. The Yaw of a
bicycle should be calculated based on an
upright position and any small increase can be
safely ignored as the difference is infinitesimal
and will be unseen by any users.
Furthermore, any change in radius from lean
should be avoided in all but the most
important cases. The closest approximation
to a solution shown here clearly demonstrates
a very high cost and minimal return. Finally,
the movement of the object was plotted in
order to prove the accuracy and workings of
the solutions provided.
4. USER SPECIFICATION
MATHEMATICAL MODELLING FOR THE CONTINUOUS

SIMULATION OF A BICYCLE
SPECIFICATION
SEAN ROBINSON
Abstract- This document is a detailed specification of a limited physics engine currently in

development. The overview of the project is first explained so that the premise and overarching
aims are made clear. The functionality of the application will be listed with explanations of any
design choices made. In addition to the core system, there are certain project constraints that
need to be adhered to, these will be reported on with explanations. Project constraints range from
technical issues concerning interaction with the application to legal notes concerning the
intellectual property of the project. The testing that will take place following the completion of
the project will be documented in order to demonstrate completeness.
4.1.
INTRODUCTION
4.1.1. MOTIVATION
This application is the output of a level 3 project in Computer Games Development. The application
will exist as a suite of libraries tasked with dealing with the physics of the overall application, which
is a virtual bicycle simulator. The bicycle simulator, being developed by the Glamorgan Games
Company, will be a demonstration of the collaboration that exists between students and teaching
staff. The simulator itself works using a training bicycle providing feedback to a computer; this data
will be processed using the physics engine detailed here. The processed data will then be passed to
the front end of the application, which will use it to correctly output a graphical display indicating
the current state of the simulation.
4.1.2. SCOPE
The potential scope for an application of this type could be enormous; one of the more esoteric
tasks needing to be tackled is the evaluation of methodology and solutions in order to arrive at a
final product that is realistic within the time frame. Core functionality will be provided in order to
develop a working prototype that is fully tested. This prototype can then form the base of a more
detailed project. This document will detail only those aspects regarding an enhanced prototype, not
a complete solution.
Rationale: A complete solution would take much more time than is available for this project;
decisions will be made in order to ensure that a working product is delivered that achieves the core
functionality criteria detailed later in this document. Any remaining time can then be used to
enhance the application.
4.1.3. DEFINITIONS
Simulation A way in which a scene or group of objects can dynamically change over time and be
output in a relevant graphical format.
Mathematical Modelling A system of using mathematical equations to determine the relationships
between objects and factors and how both sides respond to alterations in their linked counterparts.
Prototype A basic model of the final solution that has been proved. This acts as the base for future
work.
Page 31 of 50
Sean Robinson 2012
Yaw/Lean The angle at which an object is rotated about an invisible line drawn along the base of
the Z axis in the current plane.
Turn Radius The radius of a virtual circle that would be drawn if an object completed a full circle by
travelling forward without change in the steering angle.
State The data currently stored in the environment variables that defines the way in which the
scene and all objects currently exist.
Acceleration The amount that the velocity is increasing or decreasing.
Velocity The rate at which the object is being propelled forwards.
Friction Refers to the friction of the floor surface currently acting to slow the object down.
Dt Delta time, the amount of time elapsed between game cycles.
Runge-Kutta/RK A method of integration that utilises weighted summations of derivatives in order
to generate a smooth curvature of movement.
4th Order A scale on the Taylor Series of Expansion
Axis An imaginary line drawn to indicate a direction in the current plane.
Euler A basic integration method that is very quick to calculate but lacks accuracy.
Wheelbase The distance between the centres of both tyres.
Caster Angle The angle at which the head tube is reclined from the perpendicular.
Head Tube The tube connecting the handlebars to the front fork of a bicycle.
Steering Angle The angle at which the handlebars are rotated about the Y axis.
FPS Frames Per Second, the rate at which a screen is redrawn.
Exponential A value raised to the power of another.
Cost In this circumstance, cost indicates computational costs.
Encapsulation The way in which certain functionality is removed and stored independently to
promote privacy and modularisation.
Modularisation By promoting encapsulation, the reuse of functionality rises.
Coefficient A multiplicative factor
IDE Integrated Development Environment, a platform used in the development of software.
DLL Dynamic Link Library A Microsoft implementation of a shared library concept.
C++ - A programming language.
Page 32 of 50
Sean Robinson 2012
4.1.4. CUSTOMER
The outcome of this project is to deliver an enhanced prototype of the engine detailed to the
Glamorgan Games Company. This document, in addition to any research papers and design
documents, will be delivered. Full testing reports and the commented source code will form the
core deliverable.
4.2.
CORE FUNCTIONALITY
4.2.1. OVERVIEW
The premise behind this application is simply the ability to move a bicycle across landscape using
propulsion based on the users output. The environment itself will modify the trajectory of the
machine based on factors such as friction and gravity. Steering the bicycle is accomplished by
turning the handlebars on the training machine; the value of turn is used to calculate rotational
details such as Yaw.
4.2.2. CORE FEATURES

4.2.2.1.
CALCULATE ACCELERATION
Acceleration is one of the most important considerations when modelling movement. This is
the amount that the velocity of an object must increase or decrease in order to reflect
changes made to the current state.
Acceleration will be calculated by modifying the force put into an object by the rider by the
force removed through environmental factors. These factors are gravity on slopes, friction
from the surface and air resistance. Acceleration will be measured in ms/s.
The acceleration value will be added to the current velocity to give a current speed; this will
then be integrated to calculate the distance travelled.
Rationale: By calculating the acceleration implicitly using the environmental factors, an axis
of calculation is effectively removed from the pipeline. By modelling a trajectory that utilises
all affecting factors, it is known that the height position of any point modelled will simply be
relative to its position on the bicycle and height of the ground. While this may lack accuracy
to a real world scenario, the lower computational and time cost is something that is
important to consider within the limited scope of the project.
4.2.2.1.1.
INPUTS
4.2.2.1.1.1.
POWER
The inputs required calculating acceleration will be a power indicating the pedalling
currently taking place; this will be delivered in Watts. A default value of 100 will be
used in the absence of external input.
Rationale: The energy input into a bicycle when cycling is often measured in Watts.
Furthermore, studies have shown that 100 watts of output is a good average for
amateur cyclists.
Page 33 of 50
Sean Robinson 2012
4.2.2.1.1.2.
BRAKE
The brake value will create a deceleration value that will be subtracted from the
final acceleration value. This will be measured in ms/s and will be the output of a
function taking a percentage of the maximum safe deceleration defined as 0.5g. The
fraction of this used will be defined by the percentage of brake applied.
Rationale: Research in this project has shown 0.5g to be a safe maximum
deceleration constant. By taking a fraction of this as defined by the percentage of
brake used, it can be ensured that safe braking will always take place and will
remove the requirement for calculating scenarios where the machine becomes out of
the control of the rider.
4.2.2.1.1.3.
SLOPE
The current slope will be defined using the Pythagorean Theorem to find the
hypotenuse between two points in 3D space defined by the centre of the tyres. This
value will be converted to a percentage that defines a slope. The percentage will
range from 0% on a fully horizontal plane, to 100% for a fully vertical plane.
Rationale: Calculations involving gravity that are detailed later in this document use
the slope value as a percentage. This can also improve integration with other
systems as many roads and hills in the real world are measured using percentages.
Should an environment be loaded that already has these values mapped, calculating
the slope becomes a simpler matter of returning a value instead of calculating the
hypotenuse between two points.
4.2.2.1.1.4.
WATTS TO OVERCOME FRICTION
The watts required to overcome gravity will be subtracted from the input force. This
is calculated by multiplying the velocity in ms/s by the weight of the object in kg by
the friction coefficient defaulted to 0.1. The formula and coefficient value are both
outputs from previous research.
4.2.2.1.1.5.
WATTS TO OVERCOME GRAVITY
The same format as friction, although the formula changes so that standard
acceleration from gravity is multiplied by the weight of the object in kg, the
percentage of the slope and the velocity in ms/s.
4.2.2.1.1.6.
WATTS TO OVERCOME AIR RESISTANCE
As previously, but achieved by multiplying the air resistance coefficient determined

by research by the velocity in ms/s cubed.
4.2.2.1.2.
OUTPUT
4.2.2.1.2.1.
ACCELERATION
After subtracting all environmental factors from the initial power, the acceleration is
achieved by dividing the force by the mass of the object. The mass in this case will
simply be the weight of the rider and bike in kg.
Page 34 of 50
Sean Robinson 2012
4.2.2.2.
INTEGRATE VELOCITY
The velocity will be integrated over the current dt using the Runge-Kutta 4th order method.
This will then be used in an Euler method to output the distance travelled in the current dt.
Rationale: Integrating the velocity instead of the position using RK4 is as effective as the
inverse but there is an added bonus of then being able to use integration for the position too.
While the cost may be a little too high to consider integrating both attributes using RK4, a
basic Euler method for position will provide a smooth integration curvature based on
derivatives of Velocity.
4.2.2.3.
CALCULATE YAW
The yaw of the object is calculated by following a series of equations that were developed or
researched previously in the project. The initial calculation generates a turn radius using the
following:
1 =

345 ()
Where:
r: Radius
w: Wheelbase in cm
: Steering Angle
: Caster Angle
The lean is then calculated by the following:
:;
= 1389( )
1
Where:
: Lean
v: Velocity
g: Acceleration due to gravity
r: Upright turn radius
Rationale: Increase in lean due to bicycle components and changes in turn radius due to lean
are not considered as research has shown the differences to be almost undetectable and
carry a high added cost.
4.2.2.4.
GENERATE NEW POSITION
The new position will be calculated using the parametric equation of a circle with the radius
set as the distance to travel, degree as the steering angle and the origin based on the
previous position.
Rationale: The equations have already been used and it is the obvious choice based on
information already known. With a radius and degree of turn and wishing to calculate a
Page 35 of 50
Sean Robinson 2012
coordinate (A point on a virtual circumference defined by the distance to move), the

immediate choice is this equation.
4.3.
CONSTRAINTS
4.3.1. INTERACTION
Interaction with this library will take place purely through the passing of variables within the
system. The bicycle will monitor the values required; this data is then fed into the library. The
important considerations are the power and brake factors for acceleration, friction and air
resistance coefficient if differing from the default provided and the steering angle. The slope of
the terrain is defined by the hypotenuse so the position of the centres of both wheels must be
supplied in order for the calculations to work.
The output of all this will be very small, simply new values for the centre of the wheels in 3D
space. From these values, the graphical end of the application can build the remainder of the
bicycle. These values will be given as floating point coordinate values in their own data type
consisting of an X, Y and Z component. In order to provide feedback to the bicycle, the
percentage of slope calculated will also be returned so that the servo controlling the difficulty in
pedalling can be adjusted appropriately, this will be returned as the percentage itself.
This cycle of processing will take place every time it is called, this will usually be done once per
game cycle as defined by the refresh rate. The structural considerations are detailed later in this
document.
4.3.2. PERFORMANCE
Performance has been an important area to consider when researching this application. As the
processing cycle is likely to take place very frequently, it is important to ensure that the pipeline
is as streamlined as possible. While accuracy is a notable goal, the pursuit of it becomes
exponential. It is quite cost effective to achieve a moderate accuracy rating, moderate defined
as something realistic to the user, but with greater accuracy comes increasingly large costs.
Research has shown that considering increase in lean due to turning circle and alteration of a
turning circle due to lean could effectively add an extra 50% of computations on top of the basic
model.
There is no defined time scale for completing these computations without extensive testing.
However, the entire cycle must be completed in enough time to allow the remainder of the
application to cycle and then refresh the screen quickly enough so the graphical output is
smooth enough to be realistic. A frame rate minimum of 30 fps is required.
4.3.3. STRUCTURAL
Structural in this context refer to the ways in which the interactions will take place between the
library and the rest of the application. The way to ensure modularisation is to create a static
instance of the engine at the start of the programs life. A method will need to be defined to take
the required inputs. This method will then initialise the pipeline of equations previously
documented and will finally output the necessary values. This structure ensures encapsulation
Page 36 of 50
Sean Robinson 2012
and a very clean interface with which to interact. It also means that users simply need to make a
single function call to calculate all of the necessary computations.
With regard to more fundamental issues, research has shown that C++ is the most optimal
language to develop this application with and the Visual Studio 2010 IDE to be the most
appropriate platform. Should there be enough time, it is optimal for the suite of libraries to be
consolidated into .DLL files.
4.3.4. OPERATIONAL
o
o
o
o
o
Built for Windows 7 Operating System

Does not utilise multi-core or hyper-threading processing
Dedicated graphics memory not required for logic
Screen resolution irrelevant, deals with floating point Cartesian coordinates only.
No human interaction required, processes based on system side functionality only.
4.3.5. LEGAL
This project is part of a SAW development and as such, all works produced will remain the
intellectual property of the Glamorgan Games Company. This includes all reports and products
created in the design and development of the project.
4.4.
TESTING
One of the most important aspects of this project will be testing. The pipeline of equations can
become quite complex and convoluted in parts so testing each section in addition to the whole
output will be vital. Unit testing is a modular system, which is quite appropriate as the
decomposition of tasks has already been defined.
The linear nature of the equation pipeline lends itself well to decomposition and each stage in
computing the output can be considered as a single unit. This is convenient as the experiments
already completed in the research and development of this system have output a large data set that
can be used to compare the application results against.
Unit testing modules will be written in the application to check each equations result during run
time. An initial testing phase will use the results already output as a benchmark to compare against.
The results of this testing will be output to file in the form of a test log that will form part of the
documentation delivered. This system will be modified to work at run time so that users can view
the decomposed results following either success or failure.
Page 37 of 50
Sean Robinson 2012
5. REFINED UML DIAGRAM
Page 38 of 50
Sean Robinson 2012
6. USE CASE DIAGRAM AND SPECIFICATION
MATHEMATICAL MODELLING FOR THE CONTINUOUS

SIMULATION OF A BICYCLE
USE CASE AND SPECIFICATION
SEAN ROBINSON
Page 39 of 50
Sean Robinson 2012
6.1.
USE CASE DIAGRAM
6.2.
DERIVE NEW STATE
6.1.1. DESCRIPTION
The core functionality of this solution is whereby the user tells the system to derive a new physical
state for the simulation based on current factors. This sets off a linear chain of events where
individual values are calculated by relevant specialised classes. These values are then often used by
subsequent classes. The final output of this use case is that all relevant values required to remodel
the state of the system become stored in the local variables of the physics engine.
6.1.2. ACTORS
6.1.2.1.
Simulation Program
6.1.3. PRECONDITIONS
6.1.3.1.
The physics engine library has been successfully referenced.
6.1.3.2.
A physics engine object has been successfully created and initialised.
6.1.3.3.
The variables required for deriving a new state have been accurately set
within the physics engine object.
Page 40 of 50
Sean Robinson 2012
6.1.4. FLOW OF EVENTS

1.
2.
3.
4.
5.
6.
7.
Simulation Program tells physics engine to derive new state, passing all variables.
Acceleration is calculated.
Velocity is Integrated
Distance to move is calculated.
New position is plotted
Lean is calculated
Pedal difficulty coefficient is calculated
6.1.5. ALTERNATE FLOW OF EVENTS

1. B: Invalid parameters passed.
1.1. Physics engine returns error message to Simulation Program.
1. C: Only critical parameters passed.
1.1. Physics Engine sets non-critical variables to defaults.
2. B: Derived acceleration fails testing.
2.1. Physics Engine returns error message to Simulation Program.
3. B: Integrated value fails testing.
4. B: Derived distance to move fails testing.
5. B: New position fails testing.
6. B: Lean value fails testing.
7. B: Pedal coefficient fails testing.
6.1.6. POST CONDITIONS

1. New coordinates for centres of both wheels are set in the physics engine object.
2. Lean of the bicycle is set in the physics engine object.
3. Pedal difficulty coefficient is set in the physics engine object.
Page 41 of 50
Sean Robinson 2012
6.3.
GET NEW COORDINATES
6.3.1. DESCRIPTION
The user requests the current coordinates for the centre of a tyre. This coordinate is the product of
the new derived state.
6.3.2. ACTORS
6.3.3.Simulation Program
6.3.5.A new state has been successfully derived.

1. User requests coordinates for a wheel.
2. System returns currently set coordinates for appropriate wheel.

2. B: No valid coordinates currently available
2.1. Return error message to system indicating problem.

6.3.8.1.
The currently known coordinates for a wheel centre is returned from the
system.
6.4.
GET LEAN
6.4.1. DESCRIPTION
The user requests the current coordinates for the centre of a tyre. This coordinate is the
product of the new derived state.
6.4.2. ACTORS

1. User requests coordinates for a wheel.
2. System returns currently set coordinates for appropriate wheel.
3.
Page 42 of 50
Sean Robinson 2012

2. B: No valid coordinates currently available
2.1. Return error message to Simulation Program indicating problem.

6.4.8.1.
The currently known coordinates for a wheel centre is returned from the
system.
6.5.
GET PEDAL DIFFICULTY COEFFICIENT
6.5.1. DESCRIPTION
The user requests the pedal difficulty coefficient in order to increase or decrease pedal
difficulty. This value is derived from a heuristic based on the amount of power lost due to
environmental factors.
6.5.2. ACTORS

1. User requests pedal coefficient.
2. System returns currently set coefficient.

2. B: No valid coefficient currently available
2.1. Return error message to Simulation Program indicating problem.

6.5.8.1.
The currently known pedal difficulty coefficient is returned to the Simulation
Program.
Page 43 of 50
Sean Robinson 2012
7. SEQUENCE DIAGRAM
Page 44 of 50
Sean Robinson 2012
8. ACTIVITY DIAGRAMS
8.1.
Page 45 of 50
ACCELERATION
Sean Robinson 2012
8.2.
INTEGRATION
8.3.
DISTANCE
An activity diagram has not been given for the distance calculations as the entire class currently
completes a single multiplication of the dt and velocity. This is considerably more complicated than
is necessary as this multiplication could easily be done in the Physics Engine class itself.
The reason for using distance as a class is for extensibility. This project will likely serve as a basis for
future enhancement and modification. By delegating the distance to move to a separate class, it
allows for future modifications to include various materials to move through. An example here
could be extending the solution to model submarines or other underwater entities. By passing an
integrated ideal velocity to the class, current material properties could be factored before modelling
the distance to move.
This scenario could be calculated within the acceleration class in place of air resistance. However,
adding a whole new set of complex equations into an already heavy class would reduce the
modularisation that has been so important to date in this project.
Page 46 of 50
Sean Robinson 2012
8.4.
POSITION PLOTTING
8.5.
LEAN CALCULATIONS
Page 47 of 50
Sean Robinson 2012
9. CONCLUSIONS
The purpose of this paper was to demonstrate the refined and compiled functionality that
represented individual solutions to the stages of building a physics engine for a bicycle.
Initially, the extended research completed was discussed and then demonstrated in isolation and
then as part of a completed model. Through detailed experimentation and output analysis, each
solution presented has been proven to be an effective method for completing the relevant task.
At this stage, it is not viable to perform further testing just using the mathematics. Once
development has started, and unit testing modules begin to be created, it will be possible to
accurately test individual components within the system and make modification where necessary.
Throughout the design stages of this paper, a smooth transition from high level abstraction to
detailed specification has been followed. This has given a full and complete view of the system
components and functionality. There appears to be a strong structure for the program with only
small considerations to take when development begins.
The UML currently provides an accurate representation of the overall architecture. User
interactivity has been documented through the use case and those use cases have been detailed
with the specification provided.
Each event within the use case specification has been documented further by using a sequence
diagram; this has provided a timeline for interactivity and delegation between classes during the run
cycle of this system.
To provide a lower level of detail, each event has been decomposed into an activity diagram that
details the actions taken in order to achieve the desired output.
These activities could be further decomposed by inserting the relevant equations detailed in the
research phase sections.
The largest concern for the physics engine is the Distance class. Unless significant justification can
be found for keeping the class then it will be removed during development and the functionality
passed to a more suited class such as BicycleMathematics.
Development for this project should proceed efficiently by following the detailed diagrams provided.
When testing begins, there may be cases for modifying the equations heuristically in order to output
a more pleasing simulation. For accuracy, however, this solution has been proven to provide an
appropriate level within its scope.
Page 48 of 50
Sean Robinson 2012
BIBLIOGRAPHY
1. Robinson S. Mathematical Modelling for Continuous Simulation. [Online].; 2011 [cited 2012 01 28.
Available
from:
interactive.html.
http://seanrobinson-level3project.blogspot.com/2012/01/creating-continuous-and-
2. Microsoft. Microsoft.com. [Online].; 2010 [cited 2011 01 28. Available from:

http://msdn.microsoft.com/en-us/vstudio/hh388567.
http://www.microsoft.com/visualstudio/en-gb?wt.mc_id=src-n-gb-Non-loc-F7-NonGA.
4. Balagurusamy E. Object Oriented Programming with C++. 7th ed. New Delhi: Tata McGraw-Hill; 2007.
5. Michaelis M. Microsoft.com. [Online].; 2005 [cited 2012 01 28. Available from:
http://msdn.microsoft.com/en-us/library/ms379625(v=vs.80).aspx.
6. CPlusPlus. www.cplusplus.com. [Online]. [cited 2012 01 28. Available from:
http://www.cplusplus.com/reference/clibrary/cmath/.
7. Catalyst. Catalyst. [Online].; 2012 [cited 2012 01 28. Available from:
http://www.catalyst.com/products/sockettools/windows7.html.
http://msdn.microsoft.com/en-us/library/ms235636.aspx.
9. Coggan A. Training Peaks. [Online]. [cited 2012 01 05. Available from:
http://home.trainingpeaks.com/articles/cycling/power-profiling.aspx.
10. May Q. MayQ. [Online].; 2010 [cited 2012 01 05. Available from:
http://www.mayq.com/Best_european_trips/Cycling_speed_math.htm.
11. Whitt FR, G WD. Bicycling Science. 2nd ed. Massachusetts: Massachusetts Institute of technology; 1982.
12. Newton I. Philosophiae Naturalis Principia Mathematica. 1st ed. London; 1687.
13. Euler L. Institutionum calculi integralis volumen secundum St. Petersburg: Imperial Academy of Science;
1769.
14. Encyclopedia.com. Encyclop. [Online].; 2008 [cited 2011 11 02. Available from:
http://www.encyclopedia.com/doc/1G2-2830903781.html.
Page 49 of 50
Sean Robinson 2012
15. GAP. http://www-gap.dcs.st-and.ac.uk. [Online]. [cited 2011 11 02. Available from: http://www-gap.dcs.stand.ac.uk/~history/Biographies/Kutta.html.
16. Fiedler G. gafferongames.com. [Online].; 2006 [cited 2011 11 02. Available from:
http://gafferongames.com/.
17. Sharp RS. Motorcycle Steering Control by Road Preview. Journal of Dynamic Systems, Measurement and
Control (ASME). 2007 July;(129).
18. Fajans J. Steering in Bicycles and Motorcycles. American Journal of Physics. 2000 July; 68(7).
19. Cossalter V. Motorcycle Dynamics. 2nd ed.: Lulu; 2006.
20. Math Warehouse. Math Warehouse. [Online]. [cited 2012 01 05. Available from:
http://www.mathwarehouse.com/trigonometry/radians/s=r-theta-formula-equation.php#.
21. Warendorff J. Wolfram Demonstrations project. [Online].; 2012 [cited 2012 01 05. Available from:
http://demonstrations.wolfram.com/TangentChordAngle/.
Page 50 of 50
Sean Robinson 2012

Mathematical Modelling For The Continuous Simulation of A Bicycle - Research and Design

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Mathematical Modelling For The Continuous Simulation of A Bicycle - Research and Design

Hochgeladen von

Copyright:

Verfügbare Formate

USING MATHEMATICAL MODELLING TO CREATE A

CONTINUOUS SIMULATION OF A BICYCLE

Refined Evaluation of Software Languages and Development Platforms ...................................................... 6

Mathematical Formula .............................................................................................................................. 8

Operating System ...................................................................................................................................... 8

.DLL Files .................................................................................................................................................... 8

Extended Research ....................................................................................................................................... 10

Defining Constants .................................................................................................................................. 11

Calculating Velocity ................................................................................................................................. 12

Surface Friction ................................................................................................................................... 12

Watts to Overcome Gravity ................................................................................................................ 13

Watts to Overcome Surface Friction ................................................................................................... 13

Watts to Overcome Air Resistance ..................................................................................................... 13

Final Power Output ............................................................................................................................. 14

Calculating Acceleration ...................................................................................................................... 14

Integrating Velocity ................................................................................................................................. 17

Calculating Lean ....................................................................................................................................... 20

Calculating Steering Angle ....................................................................................................................... 24

Integrating and Mapping Movement ...................................................................................................... 27

User Specification ......................................................................................................................................... 30

Sean Robinson 2012

Core Functionality ................................................................................................................................... 33

Core Features ...................................................................................................................................... 33

Calculate Acceleration ................................................................................................................ 33

Watts To Overcome Friction .................................................................................................. 34

Watts to Overcome Gravity ................................................................................................... 34

Watts to Overcome air Resistance ......................................................................................... 34

Integrate Velocity ....................................................................................................................... 35

Calculate Yaw ............................................................................................................................. 35

Generate New Position .............................................................................................................. 35

Refined UML Diagram ................................................................................................................................... 38

Use Case Diagram and Specification............................................................................................................. 39

Use Case Diagram .................................................................................................................................... 40

Derive New State ..................................................................................................................................... 40

Flow of Events ..................................................................................................................................... 41

Alternate Flow of Events ..................................................................................................................... 41

Post Conditions ................................................................................................................................... 41

Sean Robinson 2012

Get New Coordinates .............................................................................................................................. 42

Flow of Events ..................................................................................................................................... 42

Alternate Flow of Events ..................................................................................................................... 42

Post Conditions ................................................................................................................................... 42

Flow of Events ..................................................................................................................................... 42

Alternate Flow of Events ..................................................................................................................... 43

Post Conditions ................................................................................................................................... 43

Get Pedal Difficulty Coefficient ............................................................................................................... 43

Flow of Events ..................................................................................................................................... 43

Alternate Flow of Events ..................................................................................................................... 43

Post Conditions ................................................................................................................................... 43

Sequence Diagram ........................................................................................................................................ 44

Activity Diagrams .......................................................................................................................................... 45

Position Plotting .................................................................................................................................. 47

Lean Calculations ................................................................................................................................ 47

Sean Robinson 2012

Sean Robinson 2012

2. REFINED EVALUATION OF SOFTWARE LANGUAGES AND DEVELOPMENT

PLATFORM AND LANGUAGE EVALUATION FOR USE IN

Sean Robinson 2012

Abstract This document outlines to

Mathematical Formula ................................. 8

.DLL Files ....................................................... 8

Bibliography ............. Error! Bookmark not defined.

(2( + 0.5"1)$ + (%&.'() )

(2( + 0.5"2)$ + (%&.'() )

(2( + "2)$ + (%&.'() )