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.

CONTENTS
1. Introduction .................................................................................................................................................... 3 1.1. 1.2. 1.3. 1.4. 2. Motivation ............................................................................................................................................. 3 Scope ..................................................................................................................................................... 3 Definitions ............................................................................................................................................. 3 Customer ............................................................................................................................................... 4

Core Functionality........................................................................................................................................... 4 2.1. 2.2. 2.2.1. 2.2.1.1. 2.2.1.1.1. 2.2.1.1.2. 2.2.1.1.3. 2.2.1.1.4. 2.2.1.1.5. 2.2.1.1.6. 2.2.1.2. 2.2.1.2.1. 2.2.2. 2.2.3. 2.2.4. Overview ............................................................................................................................................... 5 Core Features ........................................................................................................................................ 5 Calculate Acceleration ...................................................................................................................... 5 Inputs............................................................................................................................................ 5 Power ....................................................................................................................................... 5 Brake ........................................................................................................................................ 5 Slope ........................................................................................................................................ 6 Watts To Overcome Friction .................................................................................................... 6 Watts to Overcome Gravity ..................................................................................................... 6 Watts to Overcome air Resistance ........................................................................................... 6 Output .......................................................................................................................................... 6 Acceleration ............................................................................................................................. 6

Integrate Velocity ............................................................................................................................. 6 Calculate Yaw .................................................................................................................................... 7 Generate New Position ..................................................................................................................... 7

3.

Constraints ...................................................................................................................................................... 7 3.1. 3.2. 3.3. 3.4. 3.5. Interaction ............................................................................................................................................. 7 Performance.......................................................................................................................................... 8 Structural............................................................................................................................................... 8 Operational ........................................................................................................................................... 9 Legal ...................................................................................................................................................... 9

4.

Testing ............................................................................................................................................................ 9

Page 2 of 9

Sean Robinson 2012

1. INTRODUCTION
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.

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.

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. 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.

Page 3 of 9

Sean Robinson 2012

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.

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.

2. CORE FUNCTIONALITY
Page 4 of 9

Sean Robinson 2012

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.

2.2.

CORE FEATURES

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.

2.2.1.1. INPUTS 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.

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
Page 5 of 9

Sean Robinson 2012

remove the requirement for calculating scenarios where the machine becomes out of the control of the rider.

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.

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.

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.

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.

2.2.1.2. OUTPUT 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.

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.

Page 6 of 9

Sean Robinson 2012

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:

=
Where: r: Radius w: Wheelbase in cm : Steering Angle : Caster Angle

()

The lean is then calculated by the following:

=
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.

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 coordinate (A point on a virtual circumference defined by the distance to move), the immediate choice is this equation.

3. CONSTRAINTS
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
Page 7 of 9

Sean Robinson 2012

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.

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.

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 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.

Page 8 of 9

Sean Robinson 2012

3.4.
o o o o o

OPERATIONAL
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.

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. 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 9 of 9

Sean Robinson 2012