aut landspeed research groupplaygroundofmarcus.com/jetblack/documents/final repo… · web...

AUT Land Speed Research Group

Final Project Report Name: Marcus Ball

ID: 0943232

Supervisor: Dr. Robert Wellington

Marcus Ball 0943232 AUT Land speed Research Group

Table of Contents

Revisions___________________________________________________________________________________________________1

Acknowledgements_______________________________________________________________________________________2

1. Introduction_____________________________________________________________________________________________3

1.1 Abstract............................................................................................................................................................................... 3

1.2 Clients – AUT and Jetblack..........................................................................................................................................3

1.3 Motivation..........................................................................................................................................................................4

1.3.1 Current system........................................................................................................................................................5

1.3.2 Disadvantages of the current system............................................................................................................6

1.4 Project team...................................................................................................................................................................... 8

2. Sub-Products and Final Product_____________________________________________________________________10

2.1 Sub-Products................................................................................................................................................................. 10

2.1.1 Proposal, Requirements Analysis and Internal Project Evaluation...............................................10

2.1.2 Force Feedback Usability Evaluation..........................................................................................................10

2.1.3 Android Application Usability Evaluation................................................................................................11

2.1.4 Change Documents.............................................................................................................................................11

2.2 Final Products............................................................................................................................................................... 12

2.2.1 Force Feedback.....................................................................................................................................................12

2.2.2 Arduino....................................................................................................................................................................13

2.2.3 Android Application...........................................................................................................................................15

3. Project Evaluation_____________________________________________________________________________________19

3.1 Final Product Evaluation..........................................................................................................................................19

3.1.1 Force Feedback Evaluation.............................................................................................................................19

3.1.2 Arduino Evaluation.............................................................................................................................................19


3.1.3 Android Application Evaluation...................................................................................................................19

3.1.4 Product’s Significance.......................................................................................................................................20

3.1.5 Future Work.......................................................................................................................................................... 21

3.2 Process Management.................................................................................................................................................21

3.2.1 Applied Methodology and Evaluation........................................................................................................21

3.2.2 Communication with Stakeholder...............................................................................................................23

3.2.3 Risk Management................................................................................................................................................23

4. Theory and Practice___________________________________________________________________________________25

4.1 The Ability To Learn...................................................................................................................................................25

4.2 Software Development Methodologies..............................................................................................................25

5. Professional and Personal Development____________________________________________________________26

5.1 Professional Development.......................................................................................................................................26

5.2 Personal Development..............................................................................................................................................27

6. Conclusion_____________________________________________________________________________________________28

Appendix A: Sample Unity Update Script______________________________________________________________29

Appendix B: Sample code from inside Force Feedback DLL__________________________________________30

Appendix C: Eclipse IDE for Android Development___________________________________________________31

Appendix D: Android method for refreshing the UI when new data arrives_________________________32

References________________________________________________________________________________________________33


Revisions

File Name Completed Date Changes

Project Final Report

(Draft) 1.0

16th June 2013 Initial Draft Completed


(Draft) 1.1

16th June 2013 Added Appendices section to back up

work that was achieved, grammar

and spelling fixes.


2.0

17th June 2013 Expanded on team work, fixed some

inaccuracies


2.1

18th June 2013 Added more details on agile

processes.

Further expanded personal

development


2.2

19th June 2013 Fixed spelling and grammar errors

This report has been approved for release by Marcus Ball


Acknowledgements

I would like to thank AUT and team Jetblack for giving myself and my team the opportunity to work

on this project. Over the course of the past year, I have been given the chance to work on something

as fun and thrilling as the simulator for the world’s fastest car. I would like to thank AUT for

providing the resources as well as the training necessary to carry out such an enjoyable project and

for giving an undergraduate such as myself the privilege of working on a small but exciting part of

something which has the potential to be an entity that all kiwi’s would be proud to attach their

heritage too. I would also like to thank my supervisor, Dr. Robert Wellington, for teaching me

valuable lessons which forever will be scarred in my brain as well as being a figure I could depend

on and discuss various objectives with even when my team had deserted me. Robert’s honest and

critical evaluation of each product I produced was extremely helpful in developing my

understanding of how the real world functions, lessons I am glad I got before graduation. My client,

Dr. Stefan Marks, also deserves some praise for being a prime programming role model, teaching me

how code should be written properly, being a client who could always spare a minute to have a

quick informal meeting and actively caring about my progress throughout my project. Lastly I would

like to thank Gisela, the research and development lecturer, for giving me a strong base on the

development processes and giving me crucial feedback on elements which I was hesitant about. It

was because of these outstanding individuals that I was able to complete my project and walk away

with a product I am proud to say is my own.


1. Introduction

This section of the report will focus on introducing the various aspects of the project. This includes

an outline of the project, the stakeholders involved, the motivation and an overview of the current

system.

1.1 ABSTRACT

AUT Land speed Research Group is a group aimed at adding value to the current simulator

implementation of the Jetblack vehicle located within the Wellesley campus of AUT. The current

system consisted of a simulator built using a popular game engine known as Unity as well as a

physical environment consisting of a roll-cage frame, a Logitech G27 steering wheel and a wide area

for viewing the content. The purpose of this project was to find, evaluate and create multiple ways

of improving the current implementation of this simulator as to provide a more immersive and

accurate environment for the driver of the simulator.

This report will begin with a brief background of the company and individuals involved with the

project, a critical evaluation of the current implementation of the simulator and the objectives

formed and achieved by myself and the AUT Land speed Research Group. The report will also

analyse the processes involved with the creation of the solutions as well as the methodology used.

At the end of the report I will be evaluating my personal and professional growth, an evaluation of

my personal performance and also future learning requirements. I will then conclude with a

summary and conclusion of the project.

1.2 CLIENTS – AUT AND JETBLACK

Auckland University of Technology is a university situated primarily in Auckland City. AUT currently

has 3 campuses, each situated in the extremities of the Auckland City District; one campus resides

on the North Shore, another in Manukau City whereas the main campus is located at the heart of the

city’s centre.


AUT is New Zealand’s newest university, first established in the year 2000 and is the only university

in New Zealand to be established since the early 1960s. Prior to being recognized as a university,

AUT has been present in the education sector for over 115 years under multiple aliases.

As of 2011, AUT has around 26,000 students (18000 of which are full time).

The team within AUT we will be involved with during the project is known as Jetblack

(www.jetblacklsr.com). Jetblack is made up of a team of international experts employed to build and

prototype a four wheel vehicle which has the sole purpose of beating the world land speed record.

This aspect that AUT will be focusing on in regards to the vehicle is the simulator.

There are two lecturers within AUT involved directly with the Jetblack project. Doctor Robert

Wellington who is in charge of the cockpit design for the Jet Black vehicle and Doctor Stefan Marks

who is involved with the actual cock pit simulator software. In regards to this project, Doctor Robert

Wellington was my supervisor and Doctor Stefan Marks was my client.

Stefan Marks and Robert Wellington have provided me with access to the HCI laboratory located on

the first floor of the WT building on the AUT campus. In this room resides the simulator which had

been assembled and built by Robert Wellington connected to a computer and projector with the

simulator software created by Stefan Marks.

1.3 MOTIVATION

The state of the simulator prior to my involvement was near perfection. Doctor Stefan Marks had

programmed a physically accurate simulation environment taking into consideration everything

from a realistic representation of the landscape that the land speed event was to take place at, to the

turning ratio between the steering wheel connected to the simulator and the wheels within the

simulator. Doctor Robert Wellington had constructed an immersive frame and physical environment

for the driver of the simulator which also added to the realism of the accurate simulation created by

Stefan.

Although the simulator was effectively perfect and served its initial purpose of offering a driver to

practice and experience what driving Jetblack will be like, Stefan and Robert wanted to take the

experience a step further and find solutions to use technology to bury the user deeper into this

environment and give them the most realistic feeling a simulator could provide.


http://www.jetblacklsr.com/

1.3.1 Current system

The current simulator has been under constant development by both Doctor Stefan Marks and

Doctor Robert Wellington for the past 3 years. Due to the prototyping of the actual vehicle still

taking place, various components, performance and theoretical operations of the vehicle were

constantly being tweaked by the other external members of team Jetblack. For example, during my

project, one such change was the rocket deployment system which had changed from two separate

stages with two separate tanks to a single stage with controlled acceleration.

As this project was primarily a software development project, the majority of my time was spent on

understanding the code behind the simulator. Figure 1 shows the software used (Unity Game

Engine) to create the current Jetblack simulator. As the software was built using a language known

as Mono, which was unfamiliar to all of the group members, not only did we have to understand

how to use the Unity game engine but also how to program and structure code using the Mono

language in a way that adheres to the standards of the client.

Figure 1: Jetblack Simulator Unity Project


Figure 2 shows the physical aspects of the system. The system is made up of a modified Logitech

G27 steering wheel with slightly modified G27 pedals. The simulator also has a sturdy frame

surrounding the driver of the simulator. Speakers are also present directly behind the driver’s seat.

Figure 2: Jetblack Simulator

1.3.2 Disadvantages of the current system

One of the main disadvantages which plagued the system before I had entered the project, was that

the system had a very clunky and old interface for displaying data directly to the user. It was

originally done using an old tablet/laptop PC and the software was coded directly in Java. The

software was run using a simple batch file which compiled and ran the Java code. The current Java

code would receive packets over a LAN cable where the simulator would broadcast all these packets


onto every available port through UDP. Because this is using the AUT network, the team was unsure

of the impact this may have on the network and were hesitant to using this specific method.

Another disadvantage to using this display was the start up time for the program. As the computer

was rather dated, the time it took to start up and get to desktop was far too long. The simulator had

to be prepped well before a run was to commence if the user required to use the display on the

tablet. As shown in figure 3, without this display, the only other way the driver could see the various

status’ off his/her vehicle was to view the small white text located in the bottom left hand corner of

the simulation screen.

Figure 3: Simulator Main Screen

Another disadvantage of the current system was the lack of a physical representation of the forces

affecting the driver. A simulator should be as realistic as possible which should include an actual

feedback to the user to give them a deeper level of immersion in the system and give them the

impression that it was as close the reality as they would get, without actually getting in the actual

vehicle. One of the marketed features of the steering wheel was a feature known as force feedback.

Force feedback allows forces being applied on an in-game/simulator vehicle to be relayed on the

steering wheel (Logitech, 2013) . For example, a collision to the right of a vehicle would cause the


steering wheel to veer left or a bumpy road would cause the steering wheel to shift left and right

(vibrate) uncontrollably. This feature is just one example of transmitting such forces from the

simulated world to the physical environment and was yet to be fully implemented into the current

system.

1.4 PROJECT TEAM

Initially the project team was made up of myself Marcus Ball and Zaijun An. We are both software

development majors of the bachelor of computer and information sciences degree at AUT. However,

half way through the project, my partner Zaijun decided to voluntarily leave the project team hence

effectively leaving me the entire workload for the project. This falling out was due to Zaijun feeling

as though he had not put in enough effort or work into the project to warrant being a part of the

team any longer. I am partly to blame for this feeling as I had perhaps portrayed myself as being the

more ‘elitist’ coder and I have been known to be a hero programmer, where I would try and do as

much work as I could without waiting for my team mates to catch up or help them catch up. I admit

at this point of my project I had very horrible interpersonal skills, especially whilst programming. I

would seclude myself from anyone else and learn at a pace which was unachievable by my team. I

would then allocate work and have some expectation that it would be completed within a specified

time frame without any issues, this is because I projected that I could have completed it within this

amount of time. However, I did not take into consideration how long it would take another student

who was not up to my perceived level. Back then I thought I had tried to avoid this issue by

constantly allocating work and having constant communication and I was ‘shocked’ that nothing

was ever received. Because I worked alone for the majority of the project, I did not have the

advantages of a proper team. For example during the last phase of my project, before Zaijun pulled

out, we decided to use SCRUM to manage our workload during the final stretch. However because

he dropped out and this methodology not being catered specifically towards a one programmer

group, I was unable to do some of the more critical and crucial aspects of SCRUM properly and

consequently was unable to use the agile methodology to its full potential. For example I was unable

to conduct a proper retrospective on each sprint as I was critiquing my own work which I would

assume was perfection without an external opinion. I have learnt a lot about the experiences I had

because of this group and I have made some effort to improve my interpersonal skills. I recognise

that when I get into the real world, I will be confronted with more elite hero programmers who will

probably do the same to me. I should therefore make an effort to not be a one man team and to

instead help those in my team so that the overall product and process benefit greatly.


During the second phase of my project when I got to work on the Arduino project, I had the

opportunity to work with my client Stefan Marks through peer programming. It was during this

phase where I was given constant and critical feedback on all code I had written. Stefan had drawn

up a list of bugs and improvements I could look into in order to improve the current

implementation and I spent the majority of the time improving my code to his standard and

integrating our code together in a unified repository. This gave me the first dose of how

programming teams would work in the real world and helped negate the idea that teams aren’t all

lopsided with some members doing significantly more work than the others. An idea brought upon

by the lack of motivation brought upon by my previous teams at AUT.

Towards the end of my third phase of my project, I was lucky enough to get a new group of students

added to the AUT Land speed Research Group. Jimmy Saha and Julia Romanov, two students who

had just entered the Research and Development project and opted to join my group. They had their

own project to worry about, integrating a control centre to control various aspects of the simulator,

but we worked together and found a way to integrate a very early prototype of their product into

my Android application. I was able to spend some time working alongside them and successfully

managed to add the feature. We had periodic meetings and conversations about how we would

implement such a feature and where to start. I was able to share the knowledge I had attained

through my project and gave them suggestions on what they could do. Any development that was

done during this time was shared and everyone was informed of how the person managed to get

that part done. We were a unit, a real team and I am pleased with the results we were able to

achieve because of this.


2. Sub-Products and Final Product

This section will be focused on highlighting the sub and final products that were produced during

the development of this project

2.1 SUB-PRODUCTS

Over the past two semesters, I have created numerous sub products and documents relating to my

project. Below is a description of what was done and what conclusions were drawn as a result. All

documents can be found on the project’s website http://www.playgroundofmarcus.com/JetBlack

2.1.1 Proposal, Requirements Analysis and Internal Project Evaluation

One of the requirements of the Research and Development paper was to create a project proposal to

present in front of a board at AUT for approval to start. During this process, I found it necessary to

carry out a requirements analysis as well as an internal project evaluation. The requirements

analysis was formed by actively meeting with the client and supervisor and concluding what would

be regarded to being in the scope of the project. Due to the changing nature of my project, I had

decided to do a project evaluation for each different phase (three in total) which combined the

requirements analysis and gave a quick outline of the deliverables, what is needed to be learnt and a

detailed project plan of the initial perceived timeframes. The main deliverable which was common

between all three projects was that the end product code had to be delivered to the client, fully

documented and integrated within the system. Ease of use was a common theme as the client

wanted the code to be scalable so that if a feature of the vehicle was changed, then the client could

easily adapt the software to reflect the new alterations. Along with the coding deliverables, the

client also wanted a usability test to take place to evaluate the effects that different colours and

layouts have on the driver. All of which were needed to justify a specific design and conclude with

creating an interface that is both functional and aesthetically pleasing to a mass audience.

2.1.2 Force Feedback Usability Evaluation

One of the requirements of the force feedback implementation was to make sure the feedback is as

realistic as possible and was not to exaggerate the forces so that the feature became a gimmick;

similar to how the majority of triple A driving simulation titles appear to do. Before I got into the

math and physics involved with the forces on the vehicle, I carried out a usability test to attempt to

evaluate what force ranges are acceptable as well as what forces individuals expect to be relayed


http://www.playgroundofmarcus.com/JetBlack

onto the steering wheel. This usability test was done by taking test subjects from multiple age

groups and driving experience and letting them play multiple games on the G27 while observing

and noting down in game reactions and comments.

2.1.3 Android Application Usability Evaluation

Due to androids flexibility with creating a user interface for the speedometer for the vehicle. It was

decided that I should carry out a usability test to test how useable the android application I created

actually was. After I had created the foundation and got the specifics working correctly, the final

step was to find a way to display the information in a way that is informative and not too distractive

for the driver of the simulator. I carried out the test by using my new group members Julia and

Jimmy as test subjects and took their feedback from using my application and have begun to

develop a new interface from the best aspects they liked from the four interfaces I had previously

created. I was also able to measure the impact of various colours by evaluating what Julia and Jimmy

preferred colour palette as well as the readability of the data. I had programmed the application so

that the user was able to select and change the colour of the components within the user interface.

From there I focused on testing each core main colour paired with their respective complementary

colour. I executed this usability test by putting each test subject into the simulator and let them go

through a few runs while cycling through the different interfaces and colours while taking notes. I

also created a pre and post evaluation test to get their thoughts on previous iterations of the

application and expectations they may have held going into the test.

2.1.4 Change Documents

Near the end of my first semester of the Research and Development project, my project had a

significant change in objective. I would no longer be focusing on implementing the force feedback

feature but I would not be adding value to the simulator through multiple physical peripherals. Due

to this drastic change, I decided to take the time to create a change document for each time my

project changed direction. In this document I evaluated the change, the impacts it would have on

any future developments and any recommendations I saw fit to make to my client before beginning

the new project. This allowed me to an initial scope of the proposed plan and investigate what new

criteria and choices may have arisen due to the changes.


2.2 FINAL PRODUCTS

This section will highlight the three different products I was able to produce during my research

project.

2.2.1 Force Feedback

Force feedback was the initial scope of my research and development project. The goal was to use

the feature of force feedback found within the G27, and implement it into the project. The proposed

solution was to construct a dynamically linked library (DLL) using the software development kit

(SDK) created by Logitech and using that DLL as a plugin for the unity project which should, in turn

be able to actively call methods which will manipulate that status and reactions of the steering

wheel while the simulator is running. After the first semester I had gotten the fundamentals of this

project working. I had created the DLL with methods which could simulate the road, the force

applied to the wheel in x, y and z axis as well as a method which simulates what would occur when

the vehicle was in a short flight. On top of this, I was able to get the L.E.D. lights on the steering

wheel to react to the Unity project and they were emulating the thrust of the vehicle where full

thrust would flash all the lights. A small example of the code used in my Unity script can be found in

Appendix A. This code has been put into the update method which is called once per frame. The

method gets the vehicledata object from the simulator and fetches the speed variable from this

object. The vehicledata is a class that was created by Stefan which has methods for fetching various

data about the vehicle. By calling vehicleData.speed, I am able to return a float value of the current

speed at that frame. MainDlgProc is a method which I had created within the DLL. This method

allowed me to send the vehicle’s speed directly to the DLL which I then adjusted the vibration of the

wheel as the speed increased. Appendix B shows the method I had called from within the DLL.

The software development kit supplied by Logitech for the G27 was written in C++ which I had

never used before. Fortunately, it came with some well documented code as well as a short example

on how one may implement the G27 features into their game engine of choice. The plugin created

was essentially a wrapper of the SDK with methods and parameters that were custom to the

Jetblack simulation project. The plugin feature of Unity was only allowed to be used on the ‘pro’

version. AUT had a single license which belonged to the simulator hence all testing and adjustments

had to be done within the HCI laboratory.


A representation of the product I had created can be viewed on my project website

(http://www.playgroundofmarcus.com/JetBlack /force ). At the end of the first semester, my team

was informed that the project was to be discontinued as the client had found a solution which

enabled him to implement the function with little effort. As noted earlier, the majority of time on

this portion of the project was spent learning the languages and learning about game engines and

how the Unity game engine functioned. I had spent a fair amount of time going through all of my

client’s code and understanding each and every class and method call. The next step in the project

was supposed to be refining the force values on the steering wheel to reflect more accurate and real

life readings than what I had currently going but this was no longer needed. After a meeting with

the client and the supervisor when this change occurred, it was suggested that the project scope

would change from ‘Implementing Force Feedback into the Jetblack simulator’ to ‘Adding Value to

the simulator’. As I had a decent extensive knowledge of the simulator’s inner workings at this point,

I was fairly confident in my ability to add other necessary objects and peripherals to the simulator

in order to make the overall simulation feel more real.

2.2.2 Arduino

“Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use

hardware and software. It's intended for artists, designers, hobbyists, and anyone interested in

creating interactive objects or environments” (Arduino Home Page, 2013). The Arduino simply acts

as an interface/micro-controller for controlling and manipulating multiple peripherals. The client

requested that the next step in my project would be Arduino integration with the game engine. In

essence, the client desired two features to be enabled through the use of an Arduino controller. One

feature was that display and utilization of light emitting diodes (LED) mounted within the driver’s

vision to trigger an event which would cause the driver to react in a specified manner. The other

feature was a small liquid crystal display (LCD) screen which would take information from the car

such as speed, thrust status etc. and update them on the small display in front of the driver. In this

project I was able to work with the client and come up with an appropriate solution for achieving

the listed tasks.

The project was initially split in two, with my client handling the LED lights and myself working on

the LCD screen. This was my first attempt at programming anything for the Arduino platform and I

found everything generally easy to grasp and the community behind Arduino has provided a

massive treasure trove of platform information and tutorials. After a quick scope of the project, I



decided that the best solution to the problem was to send data over the USB serial connection from

the Unity game engine, analyse and process that information on the Arduino board which will then

send that data to be displayed on the connected LCD module. This solution became apparent as a

majority of forums and tutorials which focused on displaying information on an LCD screen, did so

by transferring data over the serial connection or a wireless module. I also knew from exploring the

Mono language, Unity engine and exploring options of sending data to the Logitech G27 over serial,

that there was support for sending this data over a USB connection.

The module that was provided by my supervisor took advantage of the plug and play Arduino shield

concept. This meant that the module simply clicked into the dedicated pin slots and worked without

the need of handling any wiring or soldering. After figuring out the ropes of Arduino development,

the next step was to install the manufacturers’ libraries for the device (Adafruit) and begin sending

data across. I used the provided terminal included within the Arduino SDK to conduct all my testing

before creating a compatible Unity script to add to the Jetblack simulator project. Figure 4 shows

the result I was able to achieve with the speed being updated periodically onto the display while the

simulator was running. This initial result was done by parsing the information received from the

simulator (similar to the information I was getting for the force feedback) into a byte array, sending

that data over serial with a baud rate of 115200, the Arduino would then receive the information,

set appropriate cursor configurations and deserialize the data back into a string of characters which

was then passed into the LCD module for display.


Figure 4: Arduino Display

The Adafruit LCD module, which was used for this project, also had additional features, which I was

able to exploit. Six buttons resided on the front of the LCD board, which I had programmed to switch

what data was being read as well as changing the integrated colour backlight to different colours.

After finishing the basis of the project and having a meeting with the client, it was concluded that

the small screen size as well as the slow refresh rate made this solution unsuitable for the fast paced

simulator. We had theorized that we could purchase a larger display for the information to be

displayed on; although this idea was inevitably thrown out in favour of adding Android tablet

support.

2.2.3 Android Application

Android is an open-source mobile operating system created by Google (About Page, 2013). The goal

of the third product of my research and development project was to create an Android application

with the purpose of replacing the Arduino LCD screen. As the Arduino LCD screen was already fully


functional with the simulator, it could still be used for displaying small specific information whereas

the Android tablet could handle the bulk of the important information in a catered graphical user

interface (GUI). Below is a list of the reasoning behind choosing Android as the platform of choice

for this particular solution:

The core programming language for Android application development is Java. I have spent

the majority of my time at AUT using the Java programming language however I had yet

done any application development

The requirements stated by the client is that he would prefer the screen to be completely

wireless. This is due to the mounting location of the device to be placed in the centre of the

steering wheel as it could obstruct the view of the simulator screen and the current LCD

module if placed any higher. Due to the steering wheel constantly turning and calibrating

itself on start-up, it would be easier to avoid wiring which has the potential to tangle or

interrupt the calibration sequence

As the device needed to be wireless, it had to have decent power management. At the time of

writing, only the ARM architecture found within these low powered mobile devices were

capable of driving a wireless tablet display for extended periods of time without the need of

charging

The two choices of tablet operating system which were mainstream were Apple and

Android. Programming an Apple device required a compatible laptop or desktop running

Apple’s Mac OSX. Android on the other hand only required a java integrated development

environment (IDE) known as Eclipse to function on all modern operating systems. The IDE

environment can be seen in Appendix C.

Apple has been known for restricting access to core functions of their mobile devices from

developers in order to keep the platform safe and secure for their user base. This may have

caused issues if we were to change technologies such as a different wireless protocol or had

a change in project scope where the device would be operated over a wired connection

Android devices are inexpensive compared to Apple’s alternatives and were therefore easier

to replace or get permission for units for developing

I was in possession of an Android device currently so I was able to start development

independently without having to wait for hardware

After doing an initial analysis of the project and its scope, I decided to use Bluetooth in order to

send data from the simulator to the Android device. Bluetooth appeared to satisfy all the conditions


of being a short range wireless protocol for sending data and it also operated similar to the USB

connection I had used for the Arduino project i.e. using serial communication ports to send and

receive data. My laptop that I was using for the development also had Bluetooth built in which made

rapid prototyping easier as I didn’t have to configure an external Bluetooth device. I was also

fortunate enough to get my hands on an Arduino Bluetooth module. At this stage I hypothesized

that I could use the Arduino already present in the simulator to not only send the data it received to

the LED lights and the LCD module, but also to the Android device through the use of this Bluetooth

module. I studied the Android SDK and created a basic Android application which took string values

over its Bluetooth receiver and displayed them on a text field on the device’s screen. I then

manipulated a version of the Arduino project to use the libraries of the Bluetooth module and send

all data it received from the simulator over the Bluetooth module’s serial ports. Once I had this

proof of concept working I decided to show it to my client and get his feedback on my prepared

prototype. One issue that was still present but not as apparent as before was the slow refresh rate.

The Android application was updating but was still not meeting the quick refresh standards that

were required by a proper speedometer for the simulator. We also ran into an issue where the

cheaper Android tablet’s lacked a Bluetooth radio (in order to keep costs down) hence making my

implementation incompatible. The client also brought up the idea of utilizing the Wi-Fi radio

instead of Bluetooth as it allowed for a higher bandwidth and hence a lot more information allowed

to be sent at once. The client also demonstrated a concern of putting too much reliance onto the

Arduino board when the computer itself is more than capable of offering the same functionality

without the use of a separate medium which has the potential to slow down the transfer of

information. At this point it was decided to discard the current build and start from scratch utilizing

Wi-Fi instead.

Creating the application using the different wireless protocol meant I had to re-learn my

networking knowledge and find a solution to send the data. Figure 5 shows the end product running

on two separate Android devices connected over the same wireless network. The application

utilised the Android’s canvas class that allows programmers to call draw methods to draw text and

shapes onto the screen. The application accepted UDP packets sent through a specific port

programmed into the application. The data received constructs a data object with parameters

relating to the statuses of the vehicle. As shown in Appendix D, the application then interprets this

data and feeds it into the user interface which redraws itself whenever a new object had arrived and

been constructed.


Figure 5: Android Application

After meeting with my new team members and discussing what their project entailed, I decided to

work with them on creating an initial prototype with limited functionality. Their control centre

application’s purpose is to send and receive data over a network to interact with the simulator. As

my android application already had receiving data, it wasn’t much of a stretch to include the ability

to also send data. It was decided that we would integrate a pause functionality on my application as

a start. The pause feature is called whenever the user presses the settings button on the application.

When this button is pressed, it would send a UDP packet back to the simulator. A small script was

created for the simulator to accept and receive UDP packets. This script had the added ability to

filter out the broadcasts sent by the simulator and only listen for a specific sequence of characters.

When the string “T pause” is sent through, the simulator ceases all processes and henceforth pauses

the simulation.


3. Project Evaluation

The section will focus on evaluating the final products of my project and how well I managed to

meet the proposed scope and objectives. I was also be describing the complexities involved with the

products and its significance for future research or expandability.

3.1 FINAL PRODUCT EVALUATION

Two of the three products I produced were of a final or near-final state. They include most, if not all

the intended functionality desired by the client.

3.1.1 Force Feedback Evaluation

It was unfortunate that I was unable to finish the work I had started on the force feedback project.

From what I had achieved, I am certain I could have delivered the product to the standards

presented by the client. During the project I had issues trying to extract work from my partner

which inevitably caused myself to wait until he was comfortable to move on. This waiting period

was indefinite and I decided to proceed in order to get something presentable before the end of the

first semester. This set back could have affected the entire project if it would have continued.

3.1.2 Arduino Evaluation

One of the complaints we got from the supervisor was that we did not contact the client enough

during the first semester of development. I tried to improve this aspect going in this project. Luckily

I was able to work directly with the client which meant constant communication and collaboration

about all ideas relating to the project. The Arduino project was successful and we were able to fully

implement all features and the only complaints made by the client were my programming skills.

3.1.3 Android Application Evaluation

Due to my lack of time during the second semester, as I had priorities related to my other papers, I

was unable to conduct the usability test for the Android application only towards the end of my

project. I had originally planned to take the results of this usability test to improve and develop the

user interface of the application so that it addressed any concerns which were raised during the

test. I also wanted to involve a larger audience of individuals, with different age groups and

backgrounds, in my test but was too pressed for time.


Another aspect which I am weary about is the process of connecting the Android device. I wanted to

aim for simplicity as well as reliability in regards to the operation of the Android application. In

order to use the application the user must ensure the following is met:

The wireless radio on the Android tablet must be turned on

The wireless router must be turned on

The Android tablet must be connected to the wireless network broadcasted by the router

The computer must also have its wireless radio turned on

The computer must not have a LAN cable inserted into the computer

The computer must be connected to the same wireless network as the tablet

These six steps are all crucial for the Android application to function properly. The reasoning behind

this over complicated process was due to the issues we encountered when trying to connect the

computer to the tablet using an ad-hoc connection. Using this method successfully would have

negated the use of a router and taken some complexity out of the starting process. Debugging the

connection would also be substantially easier as one would only have to debug two devices.

As my project has a huge emphasis on usability, I am also concerned with the overall usability of the

Android tablet. Being a personal advocate of the platform and being an avid user for the past four

years, I have become familiar with the operation of the Android environment. Android generally has

a decent score when it comes to usability (Jacob, 2013) however my client and supervisor were not

so adept and even though they had a lot of exposure to computers, it was immediately apparent that

they had some difficulty with performing medial tasks such as turning on the wireless radio. They

are not entirely to blame as how were they to know that they had to press the clock in the bottom

right hand corner of the screen, which opens up a menu that allows the user to slide a switch to

enable or disable the wireless. Making sure it is connected to the proper network involves opening

that menu again and pressing on the ‘Wi-Fi’ word which opens up the wireless settings. Although

this task involves a small amount of touches to execute it is obvious that it is far from intuitive.

3.1.4 Product’s Significance

The significance of my work was to attempt to further bring the simulation out into the physical

world. The purpose was to offer more interaction between the driver and the simulator in an effort

to not only make the simulator more ‘real’ but also make it more functional. The force feedback on

the steering wheel focused stimulating the driver’s senses and provide a haptic feedback to


complement what the user was seeing and hearing. The Arduino and Android application were both

created to give the driver more visual information than what was currently on offer. No longer does

the driver have a single visual source, they also now have a completely separate interface optimized

for displaying crucial information to the driver and consequently mimicking a common vehicle

layout with a speedometer in front of the windscreen. A simulators worth is always measured by its

ability to copy its real life counterpart and thanks to the work I have done as a result of my project, I

hope that the value of the simulator had indeed benefitted.

3.1.5 Future Work

The work I have done during this research and development could be further improved in the future

through further development. As noted earlier, I was unable to complete the usability test to a

satisfactory standard as well as improve the Android application further to accommodate the

study’s results. The code I have created has followed the model view controller methodology and

should allow for future developers to quickly pick up where I stopped. The quality of the application

could be further extended when newer, more functional versions of Android is released; with any

luck a better useable version of Android. The Android application is also coded to suit all screen

sizes and types which means it is also scalable to bigger or smaller devices. Android’s dominance

over the mobile market with no signs of slowing down, the application should be applicable for

years to come if the hardware was ever changed. The work I had done with networking will also

benefit the next AUT Land speed Research Group with their project as I am able to share what I have

learnt with the Unity engine and how everything works with them which should provide a good

solid foundation.

3.2 PROCESS MANAGEMENT

3.2.1 Applied Methodology and Evaluation

In my team’s original proposal, we had decided to utilize SCRUM for our projects development

methodology. However, this was one of the issues the panel had with our proposal and suggested we

research and use a different methodology. After doing a project evaluation on force feedback we

decided that its linear path and structured approach (William Fox, 2008) would suit the waterfall

methodology. We also concluded that this would be a good opportunity to use the waterfall

methodology after learning a fair bit about it over the years. We wanted to personally try the

waterfall methodology to see how it compared to the agile methods we had used during our study


at AUT and it has been noted as being the world’s first most popular process model (Casteleyn,

2010). We also felt that the requirements were set in stone and had no issues with getting a clear

and fixed understanding of what the project entails from the client which justified our choice as

waterfall has been known to be perfect for such linear projects. Waterfall is also known for taking

the complexity of project management out of the project itself and when used properly, would

produce significant time savings (Melonfire, 2013).

Right off the bat we were quite pleased with the results. As the waterfall model lent itself to linear

projects it was easy to get to gripes with it and structure our project around the different tiers of the

model. We also attained a greater understanding of the projects requirements initially from the

flurry of documents that were produced during the requirements and specification stages. We were

therefore very confident about the planning of the project and initially felt the waterfall model was

perfect for our needs. This feeling didn’t last long however. Although I was already creating quick

code to get the functionality working I was unable to find any crucial bugs with the implementation.

If I was to follow the methodology exactly, I would assume that these bugs would have been found

too late into the project and would require us to back pedal our development in order to come up

with a new solution. This was obviously against the whole concept of the waterfall model and a

large cause of failed projects are due to doing the waterfall model in an inaccurate order (Baecker,

1995).

When the force feedback project was cancelled, we threw out the idea of using waterfall and wanted

to try using our original methodology SCRUM. The Arduino was relatively short and therefore I

decided against using a methodology as the project wouldn’t have enough content to warrant the

hassle of maintaining SCRUM. The Android project however offered a long enough period for us to

have a change to use SCRUM. All of our documentation including user stories and acceptance tests

were all maintained in locally stored documents and uploaded to the website periodically. The

Android project began during the holiday break and getting any reply from my team mate became a

chore. I got the documentation ready and waited for my team mate to give me some sign of when he

is able to start a sprint and help further develop the prototype I had created.

As I was familiar with the SCRUM methodology, I was able to utilise and structure my project to

match SCRUM. I found this methodology to be perfect for what I was doing as my Android

application involved a lot of ambiguity. The requirements were very general and stated simply that

an Android device should connect to the simulator (wirelessly) and show that data on the screen.


How the data would look on the screen, what colours, what data? All questions that were constantly

assessed and asked during development.

3.2.2 Communication with Stakeholder

During the first semester, client meetings were few and far in-between. We extracted the

requirements after 3 meetings during the starting phase and then spent the rest of the time

independently developing the project. Our next formal meeting was towards the end of the first

semester when we informed of the project’s change of direction. During the second phase of my

project when I was developing the Arduino project, I was in constant informal communication with

the client. Stand up meetings occurred often during this phase as I would periodically show what I

had achieved and discus what I was planning on achieving next with my client. This style also

carried on throughout the beginning of the Android application development. This communication

was key as it allowed me to constantly change and adapt the Android application according to my

client’s suggestions. Since then my client, Doctor Stefan Marks, has shifted departments within AUT

which has made casual stand up meetings less frequent than before. I still keep in contact and if I

have any queries related to my project I am more than happy to approach Stefan. All formal meeting

minutes can be found on the project’s website (http://www.playgroundofmarcus.com/JetBlack).

3.2.3 Risk Management

Below is a risk management matrix which was created to help prepare and project for potential

risks which may occur during the development of the project.

Risk Involved

Affected Parties

Description Probability of Risk Occurring

Impact measure of Risk

Proposed solution

Sickness occurring

Team members

Sickness may cause the students to fall behind in deliverables during sprints.

Moderate Low Assign smaller workloads to the individual involved or delay/move feature to a later sprint

Insufficient knowledge of C++ and C#

Team members

As we have very basic/non-existent knowledge of the languages that are needed for this project, we have no

Moderate Moderate We intend to study and understand the languages and systems before commencement of development but as a cautionary will set aside time or reallocate sprints to enable us to



accurate way of estimating how long tasks will take to learn

attain a better understanding of the project.

Hardware malfunction

Team members

Our project depends on the full operation of the current simulator

Low Low We will collaborate with the client and supervisor if any hardware problems arise otherwise we will halt any testing and debugging until the system is fully functional and resume researching

Lack of time Team members

Due to other unforeseen priorities in other studies, we may have to halt development as to not dramatically affect our grades

Low Moderate Plan the project to allow time allocated for other topics

Definition of Probability of Risk Occurring:

Likelihood: Probability: Description: High 1/10 Happen quite often

Moderate 1/100 May happen

Low 1/1000 Not expected to occur at all

Definition of Impact of Risk:

Risk Level: Description: High High impact on the project and must be avoided, unaccepted risk.

Moderate Moderate impact, can be accepted but must be monitored.

Low Low impact, accepted risk.


4. Theory and Practice

Over the past three years I have spent doing the BCIS degree at AUT, I have expanded my skillset and

my knowledge in specific fields of computing. During my project, I have had the opportunity to put

all of these skills to use. In this section I would like to emphasize on two areas which were crucial to

the success of my project.

4.1 THE ABILITY TO LEARN

During the software development major at AUT, I have found myself doing very ambitious projects

and writing software that some would say was too complex for a first or second year student to do.

From what I have deducted, AUTs software development major doesn’t focus on learning as many

languages as possible (which is what I had initially thought the degree would entail) but instead

relies on teaching one language well, and then letting the students loose to do whatever we like with

that knowledge. Program design and construction and software development practice both focus on

managing your software project and not so much on what project you should do. This approach has

evolved my ability to teach myself new concepts and new ways of doing the projects I choose to do

and not limit myself to projects which can only be programmed in Java. I feel as though I am able to

learn and utilise any language I need and not have to rely on a lecturer or an assignment to teach

me. It has also given me good practice in how to plan and manage projects where I have had no

experience with the technologies involved.

4.2 SOFTWARE DEVELOPMENT METHODOLOGIES

Agile has always been an integral part of the software development major. A majority of the papers I

have completed during my degree have ‘drilled’ in the agile concepts and have always stated the

waterfall model as being the more redundant language. This knowledge has become key to the

organisation of my final year project and has made constructing the project a more logical and

simpler process. It wasn’t until the final project when I finally got the change to use waterfall

formally that I began to realize and appreciate the structure of agile methodologies and be thankful

for the wealth of knowledge that AUT has given me in that area.


5. Professional and Personal Development

Having the opportunity to work on so many different products for Jetblack has been not only a great

experience but also very fun. This project has helped me to refine areas of software development

that I was previously unsure of. In this section I am going to explain my professional and personal

development which has occurred as a result of this project.

5.1 PROFESSIONAL DEVELOPMENT

I am fortunate to be one of the few students to use such a large palette of different software tools,

languages and development methodologies. Previous to doing this project I had always desired to

find a reason to do a software project on Android. Learning Java since day one, I was always aware

that the language played a huge role in the development of Android applications. Mobile

applications have been a huge focus for software developers ever since the release of the original

iPhone. I think it is essential for my career to have some experience in this field and I’m glad I now

have an Android application under my belt. Doing the Android application meant that I got to not

only learn the process of developing an Android application but also how to use the Eclipse

integrated development environment which a lot of Java developers swear by.

Before I started the BCIS at AUT, I had done a year and a half of electronic engineering. During this

time I fell in love with programming while I was learning how to program primitive micro-

controllers. Since then, Arduino has become the board of choice for users who want to do anything

involving a micro controller. Being a student and also extremely busy, I had never been given the

opportunity to use this new development platform until this project. I am now extremely proficient

with Arduino thanks to its trait of being extremely easy to use and learn. The project has also

rekindled my love of micro-controller programming and was a great change of pace to see code

being translated to something in the real world as opposed to just a computer screen.


5.2 PERSONAL DEVELOPMENT

During the project, one main idea that I believe I have personally developed in is confidence. Doing

the majority of my project by myself, I have learnt to be more confident in my ability to program,

more confident in my ideas and more confident when doing presentations. All solutions and

problems had to be solved by myself and I have been extremely happy with the results of the work I

have done. On the other hand, working by myself has also brought out the idea the importance of

groups, especially group feedback. It wasn’t until I got to work with my client when I finally got

decent feedback on code I had written. That feedback was incredibly constructive and I have

learned a lot from that experience. That experience has left me to want more of this kind of

feedback particularly during my sprint retrospectives. Towards the end of my project when I got to

work as a part of a proper student team, I felt that my situation of being solo has made me more

appreciative of having a group and therefore I felt I had improved my communication with the team

members and perfected the workload balance to a state that was a lot more acceptable than my

initial group.


6. Conclusion

In conclusion, it has been a pleasure doing a project for team Jetblack. I have been fortunate enough

to have been given the opportunity to work on something truly exciting as well as work with a

plethora of different technologies. I have met all requirements set by my client and have managed to

adapt to the three different projects that I was given the chance to do. I have put a lot of effort into

this project and I hope it shows from the quality of work I was able to produce. All and all, I am

grateful for this opportunity to partake in this project and feel that I have learnt a substantial

amount which I believe, will come in handy when I finally get my degree and step into the real

world.


Appendix A: Sample Unity Update Script

/// <summary>/// This method is called once per frame./// </summary>///void Update() {

collector.GetData(ref vehicleData);Vector3 acc = vehicleData.acceleration;MainDlgProc(GetForegroundWindow(), WM_TIMER,

vehicleData.speed, 0);}


Appendix B: Sample code from inside Force Feedback DLL

#include "ForceV3.h"#include <iostream>#include "../ForceV3/Logitech Files/LogiWheel.h"#include "../ForceV3/Logitech Files/LogiControllerInput.h"

using namespace LogitechSteeringWheel;using namespace LogitechControllerInput;using namespace std;

Wheel* g_wheel;ControllerInput* g_controllerInput;

extern __declspec(dllexport) bool MainDlgProc(int hDlg, int msg, float currentVel, float thrust ){ int index; float speedParam[2] = {0.0f, 0.0f}; // velocity of the car in meters/second; int velocity = currentVel; // physics engine force acting sideways on the left front wheel int forceLeftWheelAmplitude; // physics engine force acting sideways on the right front wheel

int forceRightWheelAmplitude;

}


Appendix C: Eclipse IDE for Android Development


Appendix D: Android method for refreshing the UI when new data arrives

/*** Called when new data is received over the network*/@Overridepublic void newDataReceived(VehicleDataProvider provider) {

if (provider.isConnected()) {final VehicleData data = provider.getData();

speedometerHandler.post(new Runnable() {@Overridepublic void run() {

if (!speedometer.getConnected()) {speedometer.setConnected(true);

} else {//Sends new data to the current //speedometer.speedometer.setVehicleData(data);//Calling invalidate refreshes the UIspeedometer.invalidate();

}

}});

}}


References

About Page. (2013, June 16). Retrieved from Android: http://www.android.com/about/

Arduino Home Page. (2013, June 14). Retrieved from Arduino Main Site: http://www.arduino.cc

Baecker, R. M. (1995). Readings in Human-Computer Interaction: Toward the Year 2000, Second

Edition (Interactive Technologies). Calgary: Morgan Kaufmann.

Casteleyn, S. (2010). Engineering Web Applications. Philadelphia: Springer.

Jacob. (2013, June 15). Android vs iOS; A Usability Battle. Retrieved from SpyreStudios - Design and

Development Magazine: http://spyrestudios.com/android-vs-ios-a-usability-battle/

Logitech. (2013, June 17). Force feedback. Feel it. Retrieved from Logitech:

http://www.logitech.com/en-us/game-gear/articles/6099

Melonfire, C. (2013, June 15). Understanding the pros and cons of the Waterfall Model of software

development. Retrieved from Tech Republic:

http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-

model-of-software-development/6118423

William Fox, G. V. (2008). A Guide to Project Management. Durban: Juta Academic.
