Professional Documents
Culture Documents
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.
2.1.
Introduction ............................................................................................................................................... 7
2.2.
Modularisation .......................................................................................................................................... 7
2.3.
2.4.
2.5.
2.6.
Conclusions ................................................................................................................................................ 8
3.
3.1.
Introduction ............................................................................................................................................. 11
3.2.
3.3.
3.3.1.
Power .................................................................................................................................................. 12
3.3.2.
3.3.3.
Braking ................................................................................................................................................ 12
3.3.4.
Slopes .................................................................................................................................................. 13
3.3.5.
3.3.6.
3.3.7.
3.3.8.
3.3.9.
3.4.
3.5.
3.6.
3.7.
3.8.
Enhancements ......................................................................................................................................... 29
3.9.
Conclusions .............................................................................................................................................. 29
4.
4.1.
Page 2 of 50
4.1.1.
Motivation ........................................................................................................................................... 31
4.1.2.
Scope ................................................................................................................................................... 31
4.1.3.
Definitions ........................................................................................................................................... 31
4.1.4.
Customer ............................................................................................................................................. 33
4.2.
4.2.1.
Overview ............................................................................................................................................. 33
4.2.2.
4.2.2.1.
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.
4.2.2.1.1.5.
4.2.2.1.1.6.
4.2.2.1.2.
Output .................................................................................................................................... 34
4.2.2.1.2.1.
Acceleration ........................................................................................................................... 34
4.2.2.2.
4.2.2.3.
4.2.2.4.
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.
6.
6.1.
6.2.
6.1.1.
Description .......................................................................................................................................... 40
6.1.2.
Actors .................................................................................................................................................. 40
6.1.3.
Preconditions ...................................................................................................................................... 40
6.1.4.
6.1.5.
6.1.6.
Page 3 of 50
6.3.
6.3.1.
Description .......................................................................................................................................... 42
6.3.2.
Actors .................................................................................................................................................. 42
6.3.4.
Preconditions ...................................................................................................................................... 42
6.3.6.
6.3.7.
6.3.8.
6.4.
Get Lean................................................................................................................................................... 42
6.4.1.
Description .......................................................................................................................................... 42
6.4.2.
Actors .................................................................................................................................................. 42
6.4.4.
Preconditions ...................................................................................................................................... 42
6.4.6.
6.4.7.
6.4.8.
6.5.
6.5.1.
Description .......................................................................................................................................... 43
6.5.2.
Actors .................................................................................................................................................. 43
6.5.4.
Preconditions ...................................................................................................................................... 43
6.5.6.
6.5.7.
6.5.8.
7.
8.
9.
8.1.
Acceleration ........................................................................................................................................ 45
8.2.
Integration........................................................................................................................................... 46
8.3.
Distance ............................................................................................................................................... 46
8.4.
8.5.
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
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
Page 6 of 50
CONTENTS
1.
Introduction .................................................. 7
2.
Modularisation.............................................. 7
3.
4.
Operating System.......................................... 8
5.
6.
Conclusions ................................................... 8
2.1.
INTRODUCTION
2.2.
MODULARISATION
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
Page 8 of 50
2.5.
.DLL FILES
2.6.
CONCLUSIONS
Page 9 of 50
3. EXTENDED RESEARCH
Page 10 of 50
TABLE OF CONTENTS
1.
Introduction ................................................ 11
2.
3.
Power...................................................... 12
II.
III.
Braking .................................................... 12
IV.
Slopes ..................................................... 13
V.
VI.
VII.
VIII.
IX.
4.
5.
6.
7.
8.
Enhancements ............................................ 29
9.
Conclusions ................................................. 29
3.1.
INTRODUCTION
3.2.
DEFINING CONSTANTS
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
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
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.
=
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
= .
Where:
0.1: Friction coefficient
V: Current velocity in m/s
P: Weight of object is kg
= ( )
Where:
: Air resistance coefficient
V: Current velocity in m/s
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
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
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
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
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
D2:
D1:
(2 + )
Where:
t: Delta Time
T: Current Time
V: Current velocity in m/s
D1: Derivative 1
D2: Derivative 2
D3: Derivative 3
D4: Derivative 4
e: Constant
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
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
-1.68317
-1.25775
-4.6733
-4.0925
-1.50263
-1.60551
-3.05531 1.446341
-2.25642 1.937094
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
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
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
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
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
135<9 (. =8
5<9()
)
> . =8
Where:
: Caster Angle
t: Tyre thickness in cm
h: Centre of mass height
1 =
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
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
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
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
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
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
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
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
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
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
3.8.
ENHANCEMENTS
3.9.
CONCLUSIONS
4. USER SPECIFICATION
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
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
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.
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
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.
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.
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.
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
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.
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
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
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
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
Page 38 of 50
Page 39 of 50
6.1.
6.2.
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
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
Page 41 of 50
6.3.
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.4. PRECONDITIONS
6.3.5.A new state has been successfully derived.
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
6.4.3.Simulation Program
6.4.4. PRECONDITIONS
6.4.5.A new state has been successfully derived.
Page 42 of 50
6.5.
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
6.5.3.Simulation Program
6.5.4. PRECONDITIONS
6.5.5.A new state has been successfully derived.
Page 43 of 50
7. SEQUENCE DIAGRAM
Page 44 of 50
8. ACTIVITY DIAGRAMS
8.1.
Page 45 of 50
ACCELERATION
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
8.4.
POSITION PLOTTING
8.5.
LEAN CALCULATIONS
Page 47 of 50
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
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-
Page 49 of 50
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