DEPARTMENT OF MECHANICAL ENGINEERING

Development of a low-cost, extensible,

non-intrusive telemetry platform using
indirect sensing methods for a
Formula Student car

Shane Wimaladharma
Supervisor: Dr James Gopsill

Report Submitted for the Degree of Engineering June 2016

 Acknowledgements
I would first like to thank my supervisor Dr James Gopsill. He gave me great freedom
to explore the subject matter while consistently giving me renewed focus and advice if I
strayed too far from the objective. I am also grateful for his assistance in developing the
python code for the solution to the data acquisition issues.
I would also like to thank everyone in the DMF Lab for their enduring and infectious
positivity, even through the longest of days.
I acknowledge Guy Pearn for providing the linear potentiometer for the test rig.

DECLARATION
The accompanying research project report entitled: ’Development of
a low-cost, extensible, non-intrusive telemetry platform using indirect
sensing methods for a Formula Student car’ is submitted in the third
year of study towards an application for the degree of Master of En-
gineering in Mechanical Engineering at the University of Bristol. The
report is based upon independent work by the candidate. All contribu-
tions from others have been acknowledged above. The supervisors are
identified at the start of the report. The views expressed within the
report are those of the author and not of the University of Bristol.

I hereby declare that the above statements are true.

Signed (Author)

...........................................................................................................................................

Full Name

...........................................................................................................................................

Date

...........................................................................................................................................
 Declaration of Copyright
Certification of ownership of the copyright in a dissertation presented as part of and in
accordance with the requirements for the Final Degree of Master of Engineering at the
University of Bristol, Faculty of Engineering.

I hereby assert that I own exclusive copyright in the item named below. I give permission
to the University of Bristol Library to add this item to its stock and to make it available
for consultation in the library, and for inter-library lending for use in another library. It
may be copied in full or in part for any bone fide library or research worker on the under-
standing that users are made aware of their obligations under the copyright legislation,
i.e. that no quotation and no information derived from it may be published without the
authors prior consent.

Author

Title

Date of Submission

Signed (Author)
...........................................................................................................................................

Full Name
...........................................................................................................................................

Date
...........................................................................................................................................

This dissertation is the property of the University of Bristol Library and may only be
used with due regard to the author. Bibliographical references may be noted but no part
may be copied for use or quotation in any published work without prior permission of
the author. In addition, due acknowledgement for any use must be made.
Summary
Telemetry systems are often too complicated, expensive and time consuming for Formula
Student teams to use. While computer simulations offer little reliability in analysing
actual vehicle performance benefits; the students aren’t able to learn about vehicle setup
to develop a better performing car. This project aims to develop a low cost, extensi-
ble, non-intrusive telemetry platform using indirect sensing methods. A microphone was
used to approximate velocity through noise level, while an inertial measurement unit
(IMU) sensor was used to approximate velocity, position, suspension displacement and
wheelspin occurrence through accelerations and rotations. An Arduino Yun was used to
acquire and transmit programs through WiFi, with local storage of data to a memory
card achieved. A test rig using a modified remote controlled vehicle was developed in
order to evaluate the capabilities of the sensory platform, validated by directly sensing
the vehicle parameters. The raw data, analysed in MATLAB, from the IMU and micro-
phone had low signal to noise ratios due to the small scale test cases. Approximation of
suspension displacement was found to be possible through the orientation of the vehicle,
although the accuracy of which decreased over time. This was similar to the velocity and
displacement approximations, though the use of frequent data zeroing was identified as
a solution to the increased errors. The noise level to velocity approximation could not
be proved, and further investigation into frequency and pitch analysis was determined
necessary. Similarly, the vibration to wheelspin approximation could not be proved, it
was determined that completely dynamic test cases would need to be implemented in
order to better evaluate the hypothesis.

1
Contents
1 Introduction 4
1.1 Formula Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Formula Student Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Specification of Project Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Development of Sensory Platform 6

2.1 Telemetry in Formula 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Telemetry in Formula Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Review of Commercially Available Telemetry Systems . . . . . . . . . . . . . . . . . . . . 7
2.4 Selection of Parameters to Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Inertial Measurement Units & Inertial Navigation Systems . . . . . . . . . . . . . . . . . . 8
2.6 Theoretical Approximations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7 System Proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Development of Test Rig and Acquisition System 10

3.1 Test Rig Selection and Suitability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Data Capture Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Selecting the IMU and Microphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Approximation Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 Mounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7 Data Acquisition System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Evaluation of Sensory Platform Potential 17

4.1 Velocity and Displacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Noise Level to Velocity using Microphone . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 Accelerations to Velocity and Position in 1D using IMU . . . . . . . . . . . . . . . 19
4.1.3 Accelerations to Velocity and Position in 2D using IMU . . . . . . . . . . . . . . . 21
4.2 Orientation to Suspension Displacement using IMU . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Accelerations to Wheelspin using IMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Conclusion 27

6 References 29

2
List of Figures
1 Graph to show raw hall effect sensor data . . . . . . . . . . . . . . . . . . 12
2 Image to show redesigned chassis to be laser cut . . . . . . . . . . . . . . 13
3 Image to show bolted clamp design for potentiometer mount . . . . . . . 13
4 Figure to show the development of the RC vehicle to test rig . . . . . . . 14
5 Schematic to show layout of system . . . . . . . . . . . . . . . . . . . . . 16
6 Graph to show noise level in a quiet room . . . . . . . . . . . . . . . . . 17
7 Graph to show the noise level with loud music playing close to the microphone 17
8 Graph to show the noise level with loud music playing 6m from the micro-
phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9 Graph to show filtered result of microphone data . . . . . . . . . . . . . 18
10 Schematic to show layout of system . . . . . . . . . . . . . . . . . . . . . 18
11 Graph to show acceleration data for slow test . . . . . . . . . . . . . . . 19
12 Graph to show velocity data for slow test . . . . . . . . . . . . . . . . . . 19
13 Graph to show displacement data for slow test . . . . . . . . . . . . . . . 20
14 Graph to show acceleration data for fast test . . . . . . . . . . . . . . . . 20
15 Graph to show velocity data for fast test . . . . . . . . . . . . . . . . . . 20
16 Graph to show displacement data for fast test . . . . . . . . . . . . . . . 21
17 Graph to show averaging of inside and outside wheel velocities . . . . . . 22
18 Graph to show accelerations in X and Y compared to the hall effect accel-
eration of the vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
19 Graph to show the displacement of the vehicle in X and Y . . . . . . . . 22
20 Graph to show the comparison of the unadjusted displacement approxi-
mation and the potentiometer output . . . . . . . . . . . . . . . . . . . . 24
21 Graph to show the comparison of the adjusted displacement approximation
and the potentiometer output . . . . . . . . . . . . . . . . . . . . . . . . 24
22 Graph to show the rear wheel velocity for the static wheelspin vibration
test case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
23 Graph to show accelerations in Z for the static test . . . . . . . . . . . . 25
24 Graph to show the rear wheel velocity for the driving vibration test case 25
25 Graph to show accelerations in Z for the driving test . . . . . . . . . . . 26
1 Introduction
The search for optimum vehicle dynamics for a given test is an incredibly complex task
that spans multidisciplinary mechanics including aerodynamics and electronics. Teleme-
try systems in the motorsport industry play a vital role in providing feedback to engineers
so that they are able to evaluate the performance of their car. However, not exclusive
to motorsport, telemetry/system health monitoring is used in a wide range of appli-
cations from communications to transport and healthcare. The ability to monitor the
performance of a system is an invaluable tool and now common practice, especially when
system control must also be implemented. In Formula 1 (F1) and motor racing in general,
it is the only way to quantify and thus improve vehicle performance through setup or
design.
The F1 Championship began in 1950, and the first programmable computer had been
invented in 1949. Throughout the 50s, 60s and 70s the only way to assess a car’s per-
formance was lap timing and driver feedback. The best drivers were also competent
engineers who would know where performance in the car could be gained. In the late
70s downloadable data could be collected from about 14 parameters. In the 80s home
computing increased in popularity, technology became lighter and more powerful. It was
still mainly used on the car to relay data back by being downloaded in the garage. It was
mainly used for management and health monitoring for reliability and performance. By
the late 80s streams of data were able to be sent in bursts when the car passed the pit
boxes on the finish straight. And by the 90s more and more data could be sensed and
transmitted from anywhere on the track, to any part of the world where it was needed,
in hundredths of a second [1].
Today, telemetry technologies are used in all motorsports as an integral part of analysis.
It is used to optimise a cars setup to achieve the fastest time around a track, and for
validating/developing the design. It is used in vehicle health monitoring extensively to
improve reliability by monitoring when faults occur and assessing whether parts show
signs of a failure in the near future. It means failures can be predicted and accounted
for, potentially saving lives and the cost of fixing/replacing broken parts. Telemetry is
also expertly utilised in strategy, enabling the race technicians to assess the best time in
the race to refuel or change tyres. Often teams gain places by pitting just before the car
they are chasing ahead. They can monitor the life of the tyres they are using, and know
when they are losing enough grip to warrant coming into the pits to avoid losing more
time.
At the 2016 Australian Grand Prix in Melbourne, Mercedes AMG GP driver, Lewis
Hamilton improved on his Fastest Free practice 1 time of 1:29.725, to 1:23.837 in final
qualifying. Part of this significant time saving can be due to improvements to the setup
after telemetry analysis.

1.1 Formula Student

Formula Student (FS) is a university level educational competition in which teams from
universities around the world compete to design and make small scale formula style
racecars. The competition is judged on the design and performance in various static

4
events including cost, sustainability, safety, tilt test, brake test and noise test. And
dynamic events including skid pad, Figure of 8, sprint, acceleration, endurance and fuel
economy. Formula student inspires young engineers to pursue careers in motorsport
engineering through the invaluable experience gained. Students experience working in
the multi-disciplinary environment and communicating with around 40 other students
(for Bristol). [4] FS gives young engineers great practical experience and can be seen as
a training ground for young engineers.

1.2 Formula Student Challenge

Given the success of telemetry to help support optimising the performance of motorsport
vehicles; it is argued that having this capability within FS is fundamental to achieving
a top performing race car. Evidence of this can be seen in this Formula SAE article
[5], where it is claimed telemetry usage closes the gap on design. Although there are a
number of challenges that need to be addressed in order to achieve this.
Where F1 teams have access to funding over £100M, Bristol Electric Racing (BER) have
amassed around £30k; most of this comes as sponsorship-in-kind and is used to purchase
the most important/integral parts of the car. These include parts like the chassis (£5000)
and wheels and tyres. As funds are acquired mainly through external sponsorship and
donations year on year, it is not known how much money a team will be able to spend.
Therefore telemetry systems are often overlooked in what is required to have a car that
works. They require many individual components which can be too expensive (£200
for a suspension displacement sensor), for a small FS team to be able to warrant its
necessity.
BER has around 40 student members designing the next car, most of which will be
working in a completely extra-curricular manner. As a result, organisation, efficiency of
delegation and the ability to maintain a good work ethic throughout the year become
key to a team’s success. Due to the time constraints and the difficulty in organisation,
actual testing time before competition can be limited to a couple of afternoons; even for
the teams that manage to develop a telemetry system. Due to the lack of manpower,
preparation up to testing day would be limited so, much of the sensor calibration and
setup of the telemetry system would be done on the day. Setting up and removing all the
individual sensors would limit the amount of time that can be used to collect data.
Computer simulations are often used as justification for design changes, however these
can be misleading if not executed adequately and so cant provide accurate indications of
alterations in performance. Theoretical performance must be supplemented and led by
real world testing. The larger teams in F1 are better able to analyse their performance
to pick out their weaknesses, and as a result they often expand the performance gap
to the smaller teams throughout the race season with design improvements. Similarly,
telemetry system use is generally reserved for advanced or well supported teams in FS
and they gain more points in competition as a result.

5
1.3 Specification of Project Outcomes

Given these challenges, the aim of this project is to develop a low-cost, extensible, non
intrusive telemetry platform using indirect sensing methods for a Formula Student car.
This means the final product should be significantly cheaper than the market competition
while remaining an easily extensible platform from which to build upon, to achieve greater
levels accuracy and insight into vehicle performance. It should utilise fast and simple
mounting procedures while not impeding the performance of any component, or sensing
device already present on the vehicle. Finally, the potential of indirect sensing methods
in FS should be explored. The three objectives are therefore:
1. To develop the appropriate sensing platform for approximation of FS vehicle per-
formance using a remote-controlled (RC) vehicle.
2. To develop an appropriate test rig and acquisition system for the evaluation of the
sensing platform.
3. To evaluate the potential of the sensing platform to inform on vehicle performance.

2 Development of Sensory Platform

This section covers the review of the literature that has been used to specify the perfor-
mance parameters that should be measured and the telemetry technologies available to
create the sensing platform. This leads to the proposal of the final system.

2.1 Telemetry in Formula 1

In F1 around 30GB of data can be collected from the 2 cars over a race weekend .
The cars can run with around 100-300 sensors depending on whether they are testing or
racing. These rage from tyre pressures and temperatures to engine management data and
aero performance. Most of the sensed vehicle parameters can be divided into reliability
(e.g. oil pressures) and performance (e.g. accelerations), with some falling into both
categories (e.g. tyre pressures). The limits of vehicle performance are being pushed in
F1, so there is a lot of emphasis on vehicle health monitoring. Although many FS teams
fail in reliability, it was decided many reliability parameters cannot be adequately tested
with an RC vehicle, especially due to destructive testing [2][3].

2.2 Telemetry in Formula Student

Telemetry systems can be broken down into acquisition, transmission, storage and anal-
ysis. Transmission has been well documented, with many FS teams producing papers
on live telemetry and data transmission including work on range and signal processing
[6][7]. There has not been much research into data storage as it is easy to overlook when
cloud sharing and folder systems can be used, although these have their drawbacks. Col-
laboration can be problematic when dealing with dozens of users and large complicated
files.

6
Telemetry in FS typically utilises an array of sensors connected to a data logger which
can transmit live readings to a computer in the pit garage. Usually the data can be saved
locally to be downloaded through physical connection upon the cars return to the garage.
Data acquisition methods have not progressed much past this point. Any sensors that
are not vital to immediate track performance and more importantly, health monitoring,
wont often feature on the vehicle during an event. The analysis of data requires human
input to be able to tell whether a lap performance is good or bad, logically if a lap time
is slower than another it is bad, but if other factors like track conditions can be taken
into account you see how good the setup actually is.

2.3 Review of Commercially Available Telemetry Systems

There are a number of commercially available telemetry systems that provide data loggers
and telemetry interfacing software simplifying analysis. These include the RaceCapture
Pro 2, at up to $600, depending on the communication options selected. This price
doesn’t include the cost of the sensors required to collect the data needed so is out of the
budgets range [8]. Another interesting system is the RaceCloud which uses a modular
design for Go-Karting purposes. The 3g internet module is separate from the main
computer box as are other sensors, these include an RPM sensor, a temperature sensor
and an accelerometer. Apart from the RPM sensor all the data is transmitted wirelessly
between components to the main hub. This is also too expensive at $999 [9]. National
instruments often provide telemetry solutions to FS teams, however they’re CompactRIO
line of products can cost up to £5000, without including any sensors [10].

2.4 Selection of Parameters to Measure

It is intuitive to justify the measurement of a vehicle parameter based on the competition

and events the car will be entered into. The acceleration and skid pan tests of the
competition would imply it would be useful to sense whether or not wheelspin occurs,
in order to perfect the launch sequence with the driver, and maintain control of the car.
Wheelspin occurs when the torque supplied to the wheels is greater than the friction force
between the tyre rubber and the surface. The wheels slip on the surface as layers of the
rubber are vapourised, this is undesirable as it reduces the lifetime of the tyres through
an increased reduction in grip over time.
Accelerations and yaw/roll/pitch rates would be useful when assessing performance of the
car during the figure of 8 and the endurance events. Accelerations are useful indicators
to how fast a car can travel through the corners while maintaining traction, how well the
aerodynamic parts are performing as well as the mechanical traction. Yaw, pitch and
roll are useful to monitor how the load transfer on each wheel changes throughout the
lap.
There isn’t much that can be changed on a vehicle to alter the performance while testing,
however the suspension setup usually allows for a lot of customisation. Ride height,
camber, caster, toe and damping are a few of the parameters that can be adjusted, which
result in different performance characteristics on the track. Ideally the tyre should be
pushed into the tarmac at all times, ensuring the maximum contact patch between the

7
road and tyre is achieved, so that optimum traction is maintained when accelerating or
decelerating. The suspension displacement can be monitored to analyse how it reacts to
bumps and irregularities in the surface. If it oscillates a great deal after a bump then
more damping may be required to oppose the spring oscillations (in a MacPherson strut),
as these oscillations could distract the driver and make controlling the car more difficult
and potentially dangerous. The centre of mass of the car moves during accelerations,
and this causes a load transfer between the wheels. This unequal spread of load between
the wheels can cause a slight reduction in overall traction. So to maintain high levels of
traction spread equally between all the wheels, the spring rate (stiffness of the springs)
can be increased to keep the car level.
All these parameters become more informative when combined with other data, including
the track position which can highlight where on the track the above data relates to. It can
show how different racing lines can lead to different lap times. It can teach a driver the
fastest way to traverse a certain corner and eventually the entire lap. The performance
of a car can be more accurately analysed and understood with more data from a wider
variety of sensors. One sensors indications can be misleading, so using another parameter
to check/validate is a useful tool. Relationships can then be built up between sensor
results and certain performance parameters.
Although the downfall of many FS teams is reliability, especially in the electric motor
category, reliability and vehicle health parameters should be ignored as it would not
be possible to test components like the drivetrain and suspension up to the limit of
destruction with an RC vehicle test rig.
The throttle and brake inputs would not be a required sensing parameter of the system
as they must be directly monitored to provide input to the electric motor. Aerodynamic
performance could be measured, however the relatively low velocities achievable in testing
with the RC vehicle limit the effect of any aerodynamic changes.

2.5 Inertial Measurement Units & Inertial Navigation Systems

GPS is only accurate to around 5-10m 95% of the time. Errors include: multi path,
satellite clocks, selective availability atmospheric, and receiver clocks [11]. Carrier phase
differential GPS (DGPS) can be used to increase the position estimation accuracy to 1
to 3 cm [12]. This technique employs a static GPS receiver or base station with known
coordinates, this can transmit the known timing errors to readjust the moving target
receiver. With this technique signals may still be blocked or multipath (which is not
solved through DGPS) may reduce accuracy. It is for this reason that other methods are
employed to aid positioning. Such as inertial navigation systems (INS), which can be
used to get short distance accuracy as the error in these accumulates with time. Inertial
measurement units (IMU) can be used by re-calibrating the position at time steps using
GPS data. IMU and INS technology development has been moving towards lower cost
products that maintain high performance, so that tasks can be achieved even while GPS
calibration is unavailable. [13]

8
 Table 1: Table to show theoretical approximation possibilities

Sensors
Vehicle Parameter IMU Microphone Camera Infrared Camera
Velocity Accelerations Noise Level Frame rate timing Heat of motor
Track Position Accelerations - Track recognition -
Suspension
Rotation angles - Horizon tracking -
Displacement
Wheelspin Accelerations - - Heat of wheels
Throttle/ Longitudinal
- - -
Brake input Accelerations
Steering Input Roll rates - - -

2.6 Theoretical Approximations

Sensors can usually be defined as contact or non contact. An ultrasonic sensor vs a

potentiometer for distance. We can expand this to indirect approximation. Indirect
approximation will be defined as measuring one parameter and inferring data about
another parameter, this may mean that it is not in contact with what it is measuring,
for example, getting distance from light sensor.
So having introduced the idea of using an IMU to approximate track position. Can
this ideology be used to calculate/approximate any other parameters? The IMU can
output acceleration data, and using double integration, velocity and then displacement
can be found. From this same ideology it should be possible to approximate throttle and
brake inputs if the longitudinal accelerations during those events could be characterised.
The gyroscope pitch data could be used to characterise the throttle/ brake inputs as
the car dips and raises in these events. The rotation angles in the roll axis could be
used to characterise the steering rates. The roll angles could be used to approximate
the suspension displacement. Vibrations could also be used to determine whether or
not wheelspin is occurring. Table 1 shows the parameters and the sensors considered to
approximate them.
It was theorised that a bottom mounted camera could use track recognition for position
mapping. This idea was not deemed feasible as it would be too expensive to put into the
low-cost system. The use of an Infrared camera was also discarded as heat generation
from wheelspin at this scale would be minimal and would again be too expensive to
implement within the budget restrictions.

2.7 System Proposition

It had been decided that the sensor box use an IMU and a microphone to sense multiple
vehicle parameters. These parameters were:
• Velocity and displacement through:
– Microphone noise level
– 1 dimensional (1D) accelerations

9
 – 2 dimensional (2D) accelerations
• Suspension displacement through:
– Orientation and pitch angles
• Wheelspin through:
– Characteristic increase in vibrations

3 Development of Test Rig and Acquisition System

In order to evaluate the proposed system a test rig had to be designed based on an RC
vehicle. This section covers the development and suitability of the test rig, the data
acquisition methods and the result validation methods.

3.1 Test Rig Selection and Suitability

The design of the test rig is important as the quality of that will affect the quality of
the results. The test rig should be able to house the appropriate sensors, it should have
similar dynamic parameters to the FS vehicle - It should have adjustable suspension, 4
wheels and preferably an electric motor. It should have space to mount a sensor box in
an accessible place.
As the University of Bristol is yet to make a full car, testing the sensor box would not be
possible on a similarly sized racing vehicle. It would not be possible to acquire the use of
another universitys car for regular testing to develop the system, as they would want to
perform their own tests to their own schedule. A normal road vehicle could not be used
either as it would require too much space to test. A Go-kart could not be used either as
it doesnt have suspension. A Remote Controlled car was selected to be the test rig as it
would be easy to maintain and manage, and any spare parts are relatively inexpensive in
comparison to that of the previous suggestions. Sensors used to validate data on the scale
useful to an RC car would be much cheaper than that of the actual FS car. There are
also many customisability options available with a test rig the size of an RC car. Rapid
prototyping and laser cutting can enable modifications beyond that possible with larger
scale test rigs.
The HPI Jumpshot MT, see in Figure 4a, was selected as it’s novel twin plated chassis
and standard size bolts enabled simple modification and its modular design allowed for
easy maintenance. It had large wheels, oil filled adjustable shocks and was rear wheel
drive like the FS car would be. Also, importantly it had an electric motor just like the
FS car, so the noise output should be similar.

3.2 Data Capture Method

The objectives for data transmission and storage come in 3 stages. The first would be
to achieve local storage of data that can be transferred through wired connection to a
computer for post processing. The second stage would involve the ability to wirelessly

10
download the data once the car had returned to the pit garage, so that the data can be
analysed. A further addition to this stage would be to reduce the time and effort spent
converting data to useful forms, automating the analysis process so that very little human
interaction was required to acquire useful results. The final stage would be to achieve live
wireless data transmission and live analysis as the data is fed into the algorithms.
Next, the data capture method and device was to be selected. To collect and log the
sensor data a computing device could be used to take the inputs. It would need to be
small enough to mount easily to the RC vehicle detailed above. A Raspberry Pi is a
small computer that can run many complex tasks with it’s Linux operating system. An
Arduino is a small microcontroller that can loop through one program repeatedly. Both
have extensive documentation and help forums online. They are both small enough and
provide enough connections required for the sensors. The Pi offers great functionality
but can be quite complicated to use, whereas the Arduino is very simple to use but cant
be accessed so easily, like a computer. The Arduino Yún (a WiFi and Ethernet enabled
version of the Arduino) was selected as it should allow completion of the wireless data
transmission objective, without requiring additional WiFi transmitters or parts. It would
be more simple to create a data logging platform with the Arduino which would transmit
to an external computer where the post processing will occur. Therefore the additional
power of the Raspberry Pi is not required and unnecessarily complicates the matter.

3.3 Selecting the IMU and Microphone

The Adafruit BNO055 9DOF IMU was selected as it had built in sensor fusion. This
means it already utilised the complex algorithms required to convert raw accelerometer,
gyroscope and magnetometer data into useful units with quaternions, euler angles or
vectors also available. This greatly reduces the time needed to output meaningful data
from the sensor.
The Adafruit Electret Microphone Amplifier - MAX9814 with Auto Gain Control was
selected over the adjustable version as it was better able to reduce the effect of distant
noise in initial testing.

3.4 Approximation Validation

To validate the approximation results, directly sensing the chosen parameters should be
done. It was decided that the data from these would be acquired using the same Arduino
Yún mentioned previously. This is in order to ease analysis and reduce the components
to attach to the RC vehicle.
Table 2 shows the criteria for each parameter and the ratings out of 5 for a number of
different validation sensors and methods. The wheel rotations per second could be used
to calculate the acceleration, velocity and displacement of the car. There were a number
of methods to measure this and the hall effect sensor was found to be the best solution.
It was much cheaper and smaller than the other options which aids mounting greatly. As
the magnet travels past the hall effect sensor there should be an increase in the reading
and these spikes in the data could be characterised as rotations.

11
 Table 2: Table to show validation sensor selection process

Parameter Sensor Type Cost Range Dimensions Mounting Total

Wheel Speed Hall Effect 5 5 5 4 19
Inductive Sensor 2 5 4 2 13
Optical encoder 3 5 2 2 12
Variable resistor 5 4 4 1 14
Suspension LVDT 2 5 4 3 14
Displacement Potentiometer 5 5 4 4 18
Ultrasonic 1 5 4 2 12
Capacitive Sensor 2 5 4 2 13

Figure 1: Graph to show raw hall effect sensor data

Figure 1 shows raw data from the hall effect sensor. It can be seen that there are sharp
increases and decreases in the data due to the north pole of the magnet passing the hall
effect sensor just before the south pole. By collecting the time points of the spikes the
acceleration, velocity and displacement can be derived. Errors in this calculation can
occur when the resting value of the hall effect sensor fluctuates and makes peaks less
clear. Also, any large spikes in velocity calculations were considered erroneous and so
ignored.
The suspension displacement can be measured directly using a number of different meth-
ods and a linear potentiometer was found to be the best solution. Mounting would be
much simpler than the alternatives and one could be acquired from the technicians in the
university workshop.

3.5 Mounting

Mounting the direct sensors took more time than expected, especially as the car wasnt
designed to accommodate the sensors from the beginning and unique mounts had to be
designed. This revealed first hand that, even at this small scale, setting up direct sensors
took a large portion of time and effort that could be dedicated to analysing data and
performance. At the scale of FS, mounts for all of the sensors would have to be created,
designed and integrated before they can even be set up. They would have to be durable
and offer protection from the elements to the sensors. This highlighted the mounting
simplicity that would be required from the proposed system. The final sensor box should
reduce mounting time greatly, requiring only a few bolt holes on the bodywork to adapt
the FS car, beyond that it could be a designed in feature with mounting points already

12
on the chassis to provide a more reliable attachment.
The sensor box should be placed above the car for ease of access, and various chassis
mounting clips were theorised before it was deemed more beneficial to redesign the twin
chassis plates with raised top edges that could provide a mounting platform for the sensor
box, which is shown in Figure 2. The chassis was laser cut from 2mm acrylic due to the
constraint imposed by the suspension parts of the car. The 2mm acrylic is more flexible
than the aluminium, which could mean it is susceptible to unwanted vibrations and
extra noise could be present in the IMU data. Right angle brackets were cut from 3mm
aluminium and these were bolted to the underside of the sensor box.

Figure 2: Image to show redesigned chassis to be laser cut

Figure 3: Image to show bolted clamp design for potentiometer mount

A 3d printed bolted clamp design, shown in Figure 3 with a laser cut lower motion guide
was selected for the potentiometer mount as it allowed measurement of the actual shock
displacement without hindering the motion. Calculations can be done in post processing
to determine the relationship between vertical displacement and the displacement of the
suspension. The wheel speed hall effect sensors were mounted to the wheel hub with the
magnet attached to the inside of the wheel rim using sellotape as a quick but effective
solution. The components were secured firmly in place and experienced little vibration.
Calibration tests revealed where the optimum placement of the sensors would be and then
a final solution to the fixtures could be decided upon. It could use a product called sugru
which is a mouldable putty that hardens overnight to form a tough rubber that can stick
most things together. This simplifies the mounting procedure as the small suspension

13
and chassis parts to be used are intricate and would require more time to design around
them properly.
The microphone was mounted to the rear of the sensor box so that it would be closer to
the motor and subsequently would pick up less unwanted noise from head winds.

3.6 Scalability

The RC car’s performance parameters are scalable and similar to the FS car. Using
scaled down versions of the FS event tracks for testing should allow good transferability
of results. The suspension used in the RC car is a macpherson strut whereas the FS
car uses push rod suspension. Though the mechanics of how the two suspension types
differ, the vertical displacement of the body in relation to the wheels is still a transferable
parameter, with only the dimensions of the vehicle requiring input.
Wheel speeds are easily scalable, just requiring the circumference of the wheel to be
inputted. Knowing the size of the magnets, the minimum sampling rate to avoid missing
a revolution was calculated to be 45 samples per revolution. This can be used to calculate
the minimum sampling rate for a given speed in revolutions per second. A sampling rate
below the calculated minimum would still be able to detect a magnet pass, however it
increases the likelihood that a pass will be missed. Due to the larger circumference of the
FS car tyre the sampling rates used could be much smaller than those for the RC car for
the same velocity.
Systematic noise and zeroing errors in the IMU would be more pronounced as a proportion
of the data in the RC test case compared with the FS car. It would be more difficult to
filter this noise out to acquire meaningful data with the RC vehicle, but scaling up to the
FS car would be easier. The final test rig design is shown in Figure 4b

(a) Image to show original RC vehicle [18] (b) Image to show final test rig

Figure 4: Figure to show the development of the RC vehicle to test rig

3.7 Data Acquisition System

The design of the system, interfacing of the sensors and how the data was acquired is
detailed below.

14
The range of the potentiometer was 0-100mm, selected to prevent the possibility of over
extension, which is more than sufficient for the suspensions maximum displacement of
27mm. It works as a potential divider and a simple mapping was performed from the
voltage levels (0-1023) to acquire the displacement in mm. It was considered sufficient to
analyse the microphone noise level data in terms of the voltage within the range 0-5V,
only the relative noise level would be required.
The IMU uses Adafruit libraries and sensor fusion algorithms to output a variety of
data in standard units, including, linear acceleration in m/s and absolute orientation
in quaternions or Euler angles. Figure 5 shows how the sensors were connected to the
Arduino using a breadboard. Where the blue wires connect to ground, the green to
analog inputs, the orange to the 5V voltage source, the red to the digital inputs for the
LEDs and the yellow providing connection for the SDA and SCL output of the IMU.
The four coloured LEDS were used to display live calibration values of the IMU. When a
maximum rating of three was achieved for the accelerometer (yellow), gyroscope (orange)
or magnetometer (red), the corresponding LED turned on to indicate completion of the
calibration. The blue LED indicated the calibration of the entire system. The other
sensors did not require calibration.
Different acquisition programs could be alternated between depending on what output
was required from the test cases to increase the efficiency of data capture. The chosen
program could then be transmitted to the Arduino over WiFi and the sensor data was
printed to the serial monitor. Each line of this output was then stored on the micro SD
card as a comma-separated values (.csv) file, the name of which could be changed in order
to create multiple new files. This allowed tests to be completed in batches, instead of
extracting data after every test through removal of the micro SD card. The data started
recording as soon as the initial setup processes completed, which was indicated by turning
on the board’s built in LED.
Early tests with the system revealed that the sampling rate decreased with the addition
of more sensors. The maximum achievable was 27Hz with the IMU and one hall effect
sensor attached, which reduced to 12-13Hz when the remaining 3 hall effect sensors the
microphone and the potentiometer were attached. This only allowed velocities up to 0.25
revolutions per second, which is only 0.095m/s. This was initially thought to be due
to the serial processing nature of Arduino. It processes items sequentially and without
overlap, in contrast to parallel, which processes multiple tasks simultaneously [14]. So it
acquired sensor data one by one and then saved that pass through as a line in the micro
SD card. This disparity in the sampling rate when more sensors were added indicated
that the time value printed at the beginning of each line would not be valid for sensors
at the end of the line. This introduces a temporal error when comparing different sensor
data.
Adapting the Yún to use a parallel port for the sensors was considered until an Arduino
UNO, without wireless internet capabilities, was tested which resulted in far higher sam-
pling rates. Upon investigation it was found that the Yún uses a ’bridge’ to communicate
between the Arduino and linux side of the board. The Arduino ’environment’ handles
the inputs and the programs, whereas the linux ’environment’ handles the internet capa-
bilities and the SD card interface. So the transmission of data across the bridge to the
micro SD card was slowing the system down.

15
Live transmission of the data through WiFi was attempted to avoid saving the data to
the micro SD card however, this proved to be even slower and was prone to more errors
and missed data due to the reliability of the WiFi signal. So, the bridge had to be
bypassed in order to save the data to the micro SD card. It was found that a python
script could ’kill’ the bridge in order to open a new serial connection to the micro SD
card, it’s only task would be to write any data from the serial to the micro SD card. This
script could be called within the Arduino program if saved in the micro SD card. The
code for the Arduino program and the python script can be seen in Appendix 1 and 2
respectively.
The sampling rate increased sharply and close to 1000Hz was achieved in initial testing,
although this was limited to 200-250Hz by the serial processing when all the sensors were
used. This meant a maximum velocity of 5m/s could be used in testing. The disparity of
less than 0.004 seconds between up to 13 data points in a line was considered adequate
for the task.

Figure 5: Schematic to show layout of system

16
4 Evaluation of Sensory Platform Potential
This section covers the evaluation of the processing methods and explores the poten-
tial of the platform to inform on vehicle performance through various test cases and
results.

4.1 Velocity and Displacement

4.1.1 Noise Level to Velocity using Microphone

It was initially hypothesised that the noise level of the motor could characterise the motor
speed and therefore the vehicle speed. From early experience with the RC vehicle the
sound emitted got louder with an increase in the throttle input.
A code from the Adafruit website [15] was used to determine the noise levels the micro-
phone was reading. The first tests of the microphone revealed issues with background
noise amplification, meaning speech or general noise was picked up even with the motor
running. The microphone with adjustable gain, amplified unwanted distant noise even
at its lowest gain setting. The auto gain control microphone had limited settings to alter
the gain, however the lowest of which was able to omit the distant noise far better than
the adjustable gain microphone.

Figure 6: Graph to show noise level in a quiet room

Figure 7: Graph to show the noise level with loud music playing close to the microphone

First, the unwanted noise omission was tested, this can be seen in Figures 6, 7, and 8.
The same sample of music was played close to the microphone and 6m away. The close
up test clearly shows large fluctuations in the noise level as expected, but the far away
test does not show any significant increase over the noise floor present in the silent test.
A perfect voltage source was assumed at the beginning of testing, however this may not
be true as exemplified by the mic data in quiet conditions. Due to the minimal effect
of unwanted sounds in the signal, results and conclusions can still be gained from tests
not performed in a completely silent room, provided the unwanted noise was at least 6m

17
Figure 8: Graph to show the noise level with loud music playing 6m from the microphone

away and below the level of the music. This is beneficial as external noise level is difficult
to control.
Figure 9 shows development of the raw microphone data over time to more usable noise
filtered data using a moving average technique. This is compared to the calculated
velocity from the hall effect wheel speed sensors in Figure 10. The testing procedure

Figure 9: Graph to show filtered result of microphone data

Figure 10: Schematic to show layout of system

and assumptions were as follows. The car was to drive along a straight 5m track from
stationary, with brakes applied at the 5m mark till the car returned to a stop. The
throttle applied was kept constant until reaching the finish line, and there wasnt any
noticeable external noise in the room. The data was far noisier in the driving test than
the static noise test, with variations up to 0.5V present in the data leading to a signal
to noise ratio of around 1. This could be attributed to the air passing over the car and
around the microphone. To reduce the effect of wind the microphone could be placed in
a covered housing, however this cant eliminate the effect of road noise from the tyres. It
was decided through trial and error that a moving average taken every 40ms could be
applied to smooth the data while keeping the underlying shape of the curve. Comparing
the wheel velocity and the averaged noise level shows little correlation between the two
variables. Beyond 113 seconds the microphone noise level oscillated around 0.5V which
implied a close to constant motor speed was achieved, whereas the wheel velocity kept
increasing till the end.
The initial hypothetical relationship between noise level and motor speed could not be
proved. However from later experimentation, the pitch of the noise emitted from the

18
motor appeared to increase with an increased throttle level. And so frequency analysis
of the motor noise could be done in future to better account for the noise floor without
losing data. The specific frequencies at each constant throttle level could be isolated and
quantified. This could lead to characterisation of the motor speed through the sound
outputted.

4.1.2 Accelerations to Velocity and Position in 1D using IMU

It is widely known that provided with acceleration data over time, the displacement
can be calculated through double integration with respect to time. A slow and long
test was compared to a fast and short test over the same 5m distance. The car would
start from stationary and brake at the finish line. The accelerations were only taken in
the longitudinal X-axis as the test was in 1 dimension the other accelerations were not
considered.

Figure 11: Graph to show acceleration data for slow test

Figure 12: Graph to show velocity data for slow test

Figure 11 shows the raw accelerometer data is extremely noisy, with the variation in noise
being significantly larger than the variations in acceleration. Again, a moving average
was used to pick out the underlying form of the data, this increased its usability for
data analysis. A zero error was present in the data and assumed to be a linear constant
allowing a constant offset to be applied. This would provide a better indication of what
happened in the system than previously. The filtered data can be seen to oscillate around
the true (hall effect sensor) value with an amplitude around 0.2. This noise left in the
data would lead to large growth in errors in the final displacement results, seen in Figure
13, this is due to the error increasing as a function of time2 .

19
 Figure 13: Graph to show displacement data for slow test

The same approach to smoothing and noise filtering was applied to a higher velocity,
shorter test to evaluate the development of error over time. Much larger accelerations
are observed in this test, as seen in Figure 14, as expected meaning the resulting noise
is not as large in comparison to the data, however still great. The filtered accelerations
here can be seen to generally follow the hall effect acceleration. The exception being the
first couple of data points seeming out of place for the hall effect sensor, which is due to
the first magnet pass counted as the starting point in the processing. Noise in both cases
could be due to a faulty connection/voltage source or the IMU sensor itself. Another
possible source of error could be the vibrations in the suspension transmitting through
the acrylic chassis into the sensor box. This could be minimised in future with a stronger
chassis and a smoother track surface as it was run on carpet. The filtered data in this
case is much smoother than the slow case.

Figure 14: Graph to show acceleration data for fast test

Figure 15: Graph to show velocity data for fast test

In both test cases the difference in the velocity calculations, as seen in Figures 12 and

20
 Figure 16: Graph to show displacement data for fast test

15, can be seen to begin to converge to a constant, which means predictably that the
displacement difference increases linearly after these points. The position difference after
20 seconds of the long test reached close to 4m whereas the faster test, seen in Figure
16, over three seconds just surpassed 2m. With the same distance being covered in both
test cases it can be said that the greater noise proportion of the slower test leads to more
inaccurate results. This could be due to the sensitivity of the IMU as it may not respond
as accurately to small accelerations and be more affected by noise.
In future, greater time must be spent investigating the elimination of noise from the data.
This would reduce the short term errors but would not prevent the integration errors over
increased time. It can be concluded that in order to acquire more accurate data, the tests
performed should be larger and faster to reduce the signal to noise ratio, and a method
to zero the data frequently should be explored.

4.1.3 Accelerations to Velocity and Position in 2D using IMU

Using the experience of the 1D case, a similar approach to the 2D case was selected. It was
hypothesised that the displacement in 2D could be approximated using the accelerations
of the vehicle. The initial test case used a single corner, but a circular track of radius
0.3m was selected instead as the variables were easier to control. The car would start
from stationary with constant throttle applied until 2 laps were completed returning to
the start/finish point. It was also clearer to evaluate the success of the test case as the
start/finish point was the same. It wasn’t considered necessary to track the car in 3
dimensions at this stage as it could be assumed there was no elevation change.
To validate the accelerations, the average velocity of the rear wheels were taken and
differentiated with respect to time. The inside wheels span slower than the outside
wheels due to the differential, this helps prevent understeer, and can be seen in Figure
17. So, both wheels speeds individually will provide inaccurate velocities for the whole
vehicle. The front wheels were excluded from this test as the steering moves the magnet
to a new position in relation to the hall effect sensor. This could lead to unexpected
errors.
Figure 18 shows that similarly to the 1D case, lag in the hall effect velocity appears to be
present. Intuitively, the X accelerations follow the averaged wheel velocity closely, this is
due to the wheel velocities acting in the longitudinal X-axis. It wouldn’t be possible to
validate the accelerations in the Y-axis as a result.

21
 Figure 17: Graph to show averaging of inside and outside wheel velocities

Figure 18: Graph to show accelerations in X and Y compared to the hall effect acceleration
of the vehicle

Figure 19: Graph to show the displacement of the vehicle in X and Y

Figure 19 shows the approximated displacement of the RC vehicle starting from the origin
in black, and a curve is displayed instead of the expected 2 circles. The actual path of
the car is plotted in red. The accelerations never became negative as the car was always
travelling forward and so a circle could not be plotted from the data given in this case.

22
To continue using the accelerations, a relationship to the steering angle would need to be
found. The IMU has a magnetometer which could have been used to aid displacement
tracking in 2D. The yaw rates would need to be acquired from the magnetometer to
be combined with the longitudinal accelerations; trigonometry could then be used to
calculate the distance moved and heading in 2D. This would still require validation, and
the steering servo angle was found to be too difficult to monitor requiring an intricate
mount for a rotary potentiometer.

4.2 Orientation to Suspension Displacement using IMU

The hypothesis is that if the angle rotated by the IMU can be logged, trigonometry can
be used to calculate the vertical displacement of the suspension and therefore the actual
displacement of the shocks. The suspension was compressed only in the pitch rotation
(front to back) to simplify result processing. The dimensions used in the trigonometric
calculations were the distance from the rear axle (the point of rotation) to the front
suspension and the distance from the centre of the IMU to the suspension in the lateral
direction.
Euler angles and quaternions are the two main methods used to obtain the orientation of
an object. Euler angles represent orientation through sequential rotations about the yaw,
pitch and roll axes. They are more intuitive to understand however, the issue that befalls
them is known as gimbal lock. Gimbal lock occurs when two rotation axes align, reducing
the available rotation directions to 2, so that the actual orientation of the system cannot
be represented. This can usually be accounted for by finding the direction the object
is least likely to face, so that gimbal lock can be made to occur at that point through
adjustment of the rotation order. Rotating all the axes at once to a new orientation leads
to unexpected arcs being formed, which is undesirable[16].
On the other hand, quaternions represent rotations through defining a three-element
complex vector about which the rotation occurs, and a single scalar element that specifies
the amount of rotation. Quaternions are able to represent complex orientations and
rotations better than euler angles and their use would not limit future expansion of the
test cases through gimbal lock. For these reasons, quaternions were selected for use in
processing.
The output had to be converted to Euler angles for use in the trigonometric equations
using the formula below:
 
2 (ab + cd)
φ = arctan (1)
a2 − b 2 − c 2 + d 2

Where phi is the angle in radians, a is the scalar and b, c and d define the rotation vector
in X, Y and Z respectively [17].
Figure 20 compares the potentiometer output to the to calculated displacement. The
first calculated displacement appears to be close to that of the potentiometer, though
with a zeroing error. The zero error was assumed linear and constant which allowed a
linear offset to be applied. Then the displacement from compression appears to reduce
over time and this is due to gyroscope drift. This is an unavoidable feature of gyroscopes
but the resulting error can be accounted for in a number of ways. The gyroscope drift

23
Figure 20: Graph to show the comparison of the unadjusted displacement approximation
and the potentiometer output

Figure 21: Graph to show the comparison of the adjusted displacement approximation
and the potentiometer output

rate could be quantified by leaving it static for a long period of time. This was attempted
with the system however drift only seemed to occur once the sensor was moved. So, a
linear drift rate was assumed using a trendline applied to the initial data, the equation
of which was used to offset the data further.
The results of the adjustments can be seen in Figure 21. Though the displacements more
regularly return to the same zero, the error in the latter compressions could still not be
accounted for. In future the technique of ’zeroing’ the output when the displacement re-
turns to it’s static start point should be implemented. The more regularly the output can
be zeroed, the more accurate the results will be, as drift won’t have enough time to make
a significant difference. The processing could intuitively be taken further to approximate
the rear suspension displacements as a result of a displacement at the front.
This method would ensure that the suspension displacements could realistically be ap-
proximated by the orientation of the vehicle. However, this only works for the static case.
In reality there may be changes in the gradient of the race track which could be seen as
suspension displacements to the analysis method. The whole car may also lower or raise
at once, and using the orientation would only allow the relative suspension displacements
to be produced. In order to counteract this flaw, the accelerations of the vehicle could
be taken into account. If the car began to drive downhill, the vertical accelerations could
be used to approximate the gradient knowing the longitudinal velocity.

24
4.3 Accelerations to Wheelspin using IMU

The initial hypothesis is that wheelspin occurrence could be characterised using the in-
crease in vibrations of the vehicle. When the rear wheels lose traction and spin faster
than the car is travelling there is a marked increase in vibrations of the vehicle. Due to
the wheels slipping and almost bouncing during wheelspin, the vibrations were assumed
to occur mainly in vertical Z direction to simplify analysis and could be approximated
by the increased noise in the data.
To simulate the vibrational effects of wheelspin the rear of the car was constrained lon-
gitudinally. The rear was then raised to the point where upon applying full throttle, the
motor was just able to overcome the frictional forces between the tyres and the floor.

Figure 22: Graph to show the rear wheel velocity for the static wheelspin vibration test
case

Figure 23: Graph to show accelerations in Z for the static test

Figure 24: Graph to show the rear wheel velocity for the driving vibration test case

25
 Figure 25: Graph to show accelerations in Z for the driving test

Figures 22 and 23 indicate there is a relationship present between the velocity of the
wheelspin and the absolute measurement of the Z accelerations. It appears that as the
velocity increases, so does the intensity of the vibrations.
In order to quantify if the wheelspin vibrations added significantly to the normal driving
vibrations, an experiment was carried out over a 5m long track. Figures 24 and 25 show
that the vibrations and corresponding velocities are of a similar order of magnitude for
driving and the previous test case. If the relationship was indeed present, the errors could
originate from the loosening of sensor box fixtures over time and the low stiffness of the
acrylic chassis. In future the test cases should both be dynamic. Wheels spinning while
driving may result in a significant increase over the normal driving vibrations. However,
this is difficult to achieve in practice with the RC vehicle as it has very grippy, chunky
tyres and the motor is not powerful enough to overcome the frictional forces between the
tyres and the surface. The tyres could have been replaced with laser cut acrylic wheels
with low friction or the test could be done on a surface with low friction, maybe icy or
wet. Wheelspin may be easier to achieve with the vehicle’s own power this way, thus it
may be easier to quantify.

26
5 Conclusion
To conclude, the attainment of the project aims and objectives have been evaluated. The
sensor box, at £98, is significantly cheaper than the market competition, many of which
are just data loggers and do not include any sensors. Another success of the project was
that the platform can be built upon and extended. This is due to the large number of
approximations that can be made across various parameters and data types, the extent
of which is explored in the future work to follow. The sensor box is portable, includes
its own rechargeable power supply and is afforded a quick and easy mounting solution by
the simplistic design. Only a few bolt holes and brackets on the bodywork or chassis are
required to fix the sensor box to any vehicle and therefore the design can be considered
non intrusive. The system was able to utilise wireless transmission of data acquisition
code, however starting and stopping the data capture would have to be explored further
before live transmission could be achieved. Though the creation of multiple files to be
extracted at once was not considered too time consuming, as it allowed regular checks of
data quality. Approximation of suspension displacement was found to be possible through
the orientation of the vehicle, although the accuracy of which decreased over time due
to gyroscope drift. This was similar to the velocity and displacement approximations,
though the use of frequent data zeroing was identified as a solution to the increased errors.
The noise level to velocity approximation could not be proved, and further investigation
into frequency and pitch analysis was determined necessary. Simiarly, the vibration to
wheelspin approximation could not be proved, it was determined that completely dynamic
test cases would need to be implemented in order to better evaluate the hypothesis.
From the experience gained over the course of the project, improvements to procedures
for future work were outlined.
Firstly, many of the results lost accuracy and reliability over time as errors built up. This
could be due to the low cost and intuitively, low quality of the IMU used. Though even
the most expensive IMUs still suffer from noise and gyroscope drift, so their use only
delays the build up of error. The low signal to noise ratio led to increased difficulty in
processing and limited the accuracy of the results. To increase the signal, the scale of the
test cases should be increased and in future, Bristol’s completed FS car could be used
as the test rig base. The dimensions, velocities and dimensions would be larger and so
actual performance would be easier to extract. Improvements to the RC vehicle could
be the use of aluminium for the redesign of the chassis, this would increase the stiffness
of the sensing platform and the car. Provided with more time, the sensor housing could
have been 3D printed with designed in mounts for each component. This would lead
toward developing a marketable product from the project.
Removal of spurious errors due to buffer overflow was time consuming and in future
parallel processing should be explored for application here to increase the accuracy and
speed of data acquisition further. Due to eventual errors from the direct sensors used a
separate method should have been used to check whether all the sensors produced the
same results. In future the direct sensors should be sampled with an external datalogger,
such as another Arduino, not to add pressure to the sensor box system. Issues with this
include syncing of the data and limited mounting space, however the possibility of greater
reliability in the data outweighs the former limiting factors.
The use of more robust methods to filter the data should be explored in future, including

27
the complementary and Kalman filters. These are often used in attitude and heading
reference systems for aircraft. Also, the reliability of the system should be quantified
over many repeated tests so that. Statistical analysis can then be used to prove whether
or not the approximations fall within a target percentage of accuracy. This could lead
to characterisation of the nature of errors for numerous test cases, in order to predict
and account for error in post processing based on the conditions and state of the test
case.
Finally, an important feature of the platform was that it could be expanded upon and
grown through added sensors and new approximations. Pitot tubes could be implemented
in future to monitor aerodynamic performance, as well as provide approximations to ve-
locity through validation with other sensors. Infrared cameras could also be implemented
to move towards vehicle health monitoring applications, including tyre wear, and more
approximations could be explored from this basis. The system would still remain self con-
tained and non intrusive and act as a central hub from which many vehicle parameters
can be monitored.

28
6 References
1. McLaren. (2016) A brief history of computing in Formula 1. Available from:
http://www.mclaren.com/formula1/team/a-brief-history-of-computing-in-
F1-1052199/ [Accessed April 2016].
2. Formula 1 Dictionary. (n.d.) Telemetry. Available from: http://www.formula1-
dictionary.net/telemetry.html [Accessed April 2016].
3. Metasphere. (n.d.) Telemetry Data Journey F1. Available from:
https://www.metasphere.co.uk/telemetry-data-journey-f1/ [Accessed April 2016].
4. IMechE. (2013) Formula Student. Available from: http://formulastudent.imeche.org
/formula-student [Accessed April 2016].
5. SAE. (2012) Telemetry helps Formula SAE team close the loop on design. Available
from: http://articles.sae.org/11264/ [Accessed April 2016].
6. ETH Zurich. (2013) Telemetry Unit for a Formula Student Race Car. Available
from: ftp://ftp.tik.ee.ethz.ch/pub/students/2013-HS/SA-2013-67.pdf [Accessed
April 2016].
7. University of Idaho. (n.d.) Telemetry System for the University of Idaho Formula
SAE Vehicle. Available from: https : //seniordesign.engr.uidaho.edu/20052 006/
witel/pdf /f inal.pdf [Accessed April 2016].
8. Autosport Labs. (2016) RaceCapture Pro 2. Available from:
https://www.autosportlabs.com/racecapturepro-2/ [Accessed April 2016].
9. RaceCloud. (2016) Go Kart Bundle. Available from: https://store.racecloud.net/en
/go-kart-bundle [Accessed April 2016].
10. National Instruments. (2016) CompactRIO. Available from: http://www.ni.com/
compactrio/ [Accessed April 2016].
11. Trimble. (n.d.) How Differential GPS works. Available from:
http : //www.trimble.com/gpst utorial/dgps − how.aspx [Accessed April 2016].
12. W. Li, H. Leung. (2003) Constrained Unscented Kalman Filter Based Fusion of
GPS/INS/Digital Map for Vehicle Localization. Proceedings of the 2003 IEEE
International Conference on Intelligent Transportation Systems, 2, 1362-1367.
13. N. Barbour, G. Schmidt. (2001) Inertial Sensor Technology Trends. IEEE Sensors
Journal, 1 (4), 332-339.
14. J. Townsend. (1990) SERIAL VS. PARALLEL PROCESSING: Sometimes They
Look Like Tweedledum and Tweedledee but They Can (and Should) be Distin-
guished. Psychological Science, 1 (1), 46-54.
15. Bill Earl. (2013) Adafruit Microphone Amplifier Breakout: Measuring Sound
Levels. Available from: https://learn.adafruit.com/adafruit-microphone-amplifier-
breakout/measuring-sound-levels [Accessed April 2016]
16. CHRobotics. (n.d.) Understanding Quaternions. Available from:
http://www.chrobotics.com/library/understanding-quaternions [Accessed April 2016]

29
17. CHRobotics. (n.d.) Understanding Euler Angles. Available from:
http://www.chrobotics.com/library/understanding-euler-angles [Accessed April 2016]
18. HPI Jumpshot MT Image. (2016) Available from: https://www.emodels.co.uk/hpi-
1-10-jumpshot-mt-monster-truck-rtr-115116-radio-controlled-car-115116.html [Accessed
April 2016]

30
Appendix 1
// Setting some default variables
const int ledPin = 13; // LED on the Yun board
String incomingString = ""; // For reading data from the linino
boolean logging = false; // The trigger to say start sending data
int hallPin1 = A1; // Declare sensor inputs
int hallPin2 = A2;
int hallPin3 = A3;
int hallPin4 = A4;
int potPin = A0;

int val1 = 0; // Declare values to hold sensor data

int val2 = 0;
int val3 = 0;
int val4 = 0;
int pot = 0;
float x = 0;
float y = 0;
float z = 0;
float qW = 0;
float qX = 0;
float qY = 0;
float qZ = 0;

// Set sampling window for microphone

const int sampleWindow = 1;
unsigned int sample;

// Set up headers and libraries for BNO055

#include <Wire.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BNO055.h>
#include <utility/imumaths.h>
#define BNO055_SAMPLERATE_DELAY_MS (1)
Adafruit_BNO055 bno = Adafruit_BNO055();

// Declare Calibration LED Inputs

const int ledPinm = 7; // green light
const int ledPing = 8; // red light
const int ledPina = 12; // yellow light
const int ledPins = 4; // blue light

// Setup code here, to run once:

void setup() {
pinMode(ledPin, OUTPUT); // Setting up the LEDs on the Yun Board
pinMode(ledPinm, OUTPUT);
pinMode(ledPing, OUTPUT);
pinMode(ledPina, OUTPUT);
pinMode(ledPins, OUTPUT);

// Start the BNO055

if (!bno.begin()) {
}

// Flash the LED to signify starting (blink 3 times)

digitalWrite(ledPin, HIGH);

31
 delay(500);
digitalWrite(ledPin, LOW);
delay(500);
digitalWrite(ledPin, HIGH);
delay(500);
digitalWrite(ledPin, LOW);
delay(500);
digitalWrite(ledPin, HIGH);
delay(500);
digitalWrite(ledPin, LOW);
delay(500);

// Set-up serial connections

Serial.begin(115200);
Serial1.begin(115200);
while (!Serial1);
}

// Code here repeats continuously

void loop() {

// Choosing data to output from the BNO055

imu::Vector<3> linearaccel = bno.getVector(Adafruit_BNO055::VECTOR_LINEARACCEL);
imu::Quaternion quat = bno.getQuat();

// Acquiring calibration data

uint8_t system, gyro, accel, mag = 0;
bno.getCalibration(&system, &gyro, &accel, &mag);

// Turn on LEDs if calibration status = 3

if (gyro == 3) {
digitalWrite(ledPing, HIGH);
}
else {
digitalWrite(ledPing, LOW);
}
if (accel == 3) {
digitalWrite(ledPina, HIGH);
}
else {
digitalWrite(ledPina, LOW);
}
if (mag == 3) {
digitalWrite(ledPinm, HIGH);
}
else {
digitalWrite(ledPinm, LOW);
}
if (system == 3) {
digitalWrite(ledPins, HIGH);
}
else {
digitalWrite(ledPins, LOW);
}
delay(BNO055_SAMPLERATE_DELAY_MS);

// Check if communication to the Linino is available

if (Serial1.available() > 0) {

32
 char incomingChar = (char)Serial1.read(); // Read chars from linino
if (incomingChar == ’\n’) { // Checking for an end of line
Serial.println(incomingString); // Print the string before the end of line
if (incomingString == "START") { // If start then python script is ready to receive data
Serial.println("Logging Started");
digitalWrite(ledPin, HIGH);
logging = true; // Ready to start logging
}
incomingString = ""; // Reset string
} else {
incomingString += incomingChar; // Append char to string
}
}

// Define microphone output

unsigned long startMillis = millis(); // Start of sample window
unsigned int peakToPeak = 0; // Peak-to-peak level
unsigned int signalMax = 0;
unsigned int signalMin = 1024;

// Collect microphone data

while (millis() - startMillis < sampleWindow)
{
sample = analogRead(5);
if (sample < 1024) // toss out spurious readings
{
if (sample > signalMax)
{
signalMax = sample; // save just the max levels
}
else if (sample < signalMin)
{
signalMin = sample; // save just the min levels
}
}
}
peakToPeak = signalMax - signalMin; // max - min = peak-peak amplitude

// Define IMU data variables

x = linearaccel.x();
y = linearaccel.y();
z = linearaccel.z();
qW = quat.w();
qX = quat.x();
qY = quat.y();
qZ = quat.z();

// Read data from other sensors

pot = analogRead(potPin);
val1 = analogRead(hallPin1);
val2 = analogRead(hallPin2);
val3 = analogRead(hallPin3);
val4 = analogRead(hallPin4);

// Use milliseconds for timing intervals

unsigned long time = millis();

// if logging is true then send data for the python script to store

33
 if (logging) {
// Print data to serial
Serial1.print(time);
Serial1.print(",");
Serial1.print(val1);
Serial1.print(",");
Serial1.print(val2);
Serial1.print(",");
Serial1.print(val3);
Serial1.print(",");
Serial1.print(val4);
Serial1.print(",");
Serial1.print(x);
Serial1.print(",");
Serial1.print(y);
Serial1.print(",");
Serial1.print(z);
Serial1.print(",");
Serial1.print(qW, 4);
Serial1.print(",");
Serial1.print(qX, 4);
Serial1.print(",");
Serial1.print(qY, 4);
Serial1.print(",");
Serial1.print(qZ, 4);
Serial1.print(",");
Serial1.print(pot);
Serial1.print(",");
Serial1.println(peakToPeak);

// Set sampling rate (Delay between samples)

delay(1);
}
}

Appendix 2
# Import modules
import serial
import time
import subprocess

# Prepare data logging file

file = open("/mnt/sd/arduino/data_log.txt", "w")
file.write("-- Data Logging Started From Arduino --\r\n")
file.flush()

# Ending the bridge

file.write("-- Ending bridge connection --\r\n")
file.flush()
subprocess.call([’/usr/bin/kill-bridge’]) # This ends the bridge
file.write("-- Bridge Connection Ended --\r\n")
file.flush()

# Wait for 5 seconds to allow the bridge to close

34
time.sleep(5)

# Setting up serial connection

file.write("-- Set-Up Serial Connection --\r\n")
file.flush()
ser = serial.Serial(’/dev/ttyATH0’, timeout=None, baudrate=115200)
time.sleep(2) # Waiting for arduino to reboot
file.write("-- Serial Connection Made --\r\n")
file.flush()

# Send message to arduino to say ready to receive data

ser.write("\n")
ser.write("START\n")

while True:
# Write data that is sent from the arduino to the file system
file.write(str(ser.readline()));
file.flush()

file.close()

35