Embed Size (px)
Citation preview
CT6COPRE Product Development Document
Product Name: Bluetooth Arduino Control Car System for Unity 2017.1.1.f3
Author Name: Adam Cleaver
Version Date Comments
0.0.1 17/10/2017 Research into project background
0.0.2 03/11/2017 Collating research into project background
0.0.3 17/11/2017 Collecting hardware requirements for project.
0.0.4 02/12/2017 Research into software requirements.
0.0.5 16/12/2017 Collecting all software specifications for project.
0.1.0 13/01/2018 Outlining main requirements for the project.
0.2.0 27/01/2018 Update to hardware requirements.
0.3.0 10/02/2018 Further updates to hardware requirements from testing.
0.4.0 24/02/2018 Updates to requirements of project.
0.5.0 10/03/2018 Updates to requirements of project.
0.6.0 24/03/2018 Updates to software requirements of project.
0.7.0 07/04/2018 Final bug testing on project requirements
0.8.0 14/04/2018 Further bug testing on project requirements
0.9.0 21/04/2018 Last bug testing on product/project game made.
1.0.0 28/04/2018 Final tests and evaluation of product.
Contents 1. Introduction ................................................................................................................................................ 6
1.1 Purpose .......................................................................................................................................... 6
1.2 Scope .............................................................................................................................................. 6
1.3 Definitions, Acronyms and Abbreviations ...................................................................................... 6
2. System Requirements Specification............................................................................................................ 7
2.1. General Description ............................................................................................................................. 7
2.1.1 Product Perspective ........................................................................................................................... 7
2.1.2 Product Functions .............................................................................................................................. 8
2.1.3 User Characteristics ........................................................................................................................... 8
2.1.4 General Constraints ........................................................................................................................... 8
2.1.5 Assumptions & Dependencies ........................................................................................................... 8
2.2 Specific Requirements .............................................................................................................................. 8
Project Overview............................................................................................................................................. 8
2.2.1 Hardware Requirements .................................................................................................................... 9
H1 – Most Optimal Hardware Requirements (100M)............................................................................. 9
H2 – Arduino Uno (100M) ....................................................................................................................... 9
H3 – Arduino Sensor Shield V5.0 (100M) ................................................................................................ 9
H4 – L2989N Dual-H Bridge Motor Connector (100M) ........................................................................... 9
H5 - HC-06 Bluetooth Module (100M) .................................................................................................... 9
H6 – Two BRC 18650 4200mAH 3.7V li-ion Batteries and Power Pack (100M) ...................................... 9
2.2.2 Software Requirements ..................................................................................................................... 9
S1 – Unity Engine (100M) ....................................................................................................................... 9
S2 – Arduino Software (100M) .............................................................................................................10
2.2.3 Interface Requirements ...................................................................................................................11
I1 – Screen Design (100D) .....................................................................................................................11
I2 – Key Mapping (100D) .......................................................................................................................12
2.2.4 Functional Requirements .................................................................................................................12
F1 – Serial Port Integration (100D) .......................................................................................................12
F2 – Bluetooth Integration (100D) ........................................................................................................12
F3 – Movement (100D) .........................................................................................................................12
F4 – Position & Rotation Matching (100D) ...........................................................................................12
F5 – Collision Detection (100D).............................................................................................................12
2.2.5 Performance Requirements .............................................................................................................12
P1 – Frame Rate (100M) .......................................................................................................................12
P2 – Memory (100M) ............................................................................................................................12
P3 – Serial Port Communication Time (100M) .....................................................................................12
2.2.6 Reliability Requirements ..................................................................................................................13
R1 – File System Stability (60M) ...........................................................................................................13
R2 – Game Runtime (100D) ..................................................................................................................13
2.2.7 Design Constraints ...........................................................................................................................13
D1 – Hardware Specification.................................................................................................................13
3. Software Design Description .....................................................................................................................13
3.1 Detailed Design Description ................................................................................................................13
D1 – Loading Game Scene ....................................................................................................................13
D2 – Bluetooth Arduino Control Car Movement ..................................................................................14
D3 – Collision Detection ........................................................................................................................15
D4 – End Game State ............................................................................................................................15
3.2 Requirements Mapping ......................................................................................................................16
4. Project Plan ...............................................................................................................................................17
4.1 Project Organisation ...........................................................................................................................17
4.1.1 Life Cycle Model ...........................................................................................................................17
4.1.2 Project Organisational Structure .................................................................................................17
4.2 Managerial Process .............................................................................................................................18
4.2.1 Management Objectives & Priorities ...........................................................................................18
4.2.2 Assumptions, Dependencies & Constraints .................................................................................18
4.2.3 Risk Management ........................................................................................................................18
4.2.4 Monitoring & Controlling Mechanisms........................................................................................19
4.3 Quality Planning ..................................................................................................................................19
4.3.1 Code Implementation ..................................................................................................................19
4.3.1 Commenting Standards ...............................................................................................................20
4.3.2 File/Folder Naming Scheme .........................................................................................................20
4.4 Work Packages, Schedule & Budget ...................................................................................................20
4.4.1 Schedule .......................................................................................................................................20
4.4.2 Budget ..........................................................................................................................................20
5. Test Plan and Results ................................................................................................................................21
Reflection on Project ....................................................................................................................................24
Learning Outcome 1: Produce Functional Gaming Software ...................................................................24
Overall Reflection on Software Functionality .......................................................................................26
Learning Outcome 2: Critically Assess of Console Hardware ...................................................................26
Overall Reflection on Hardware Functionality ......................................................................................28
Learning Outcome 3: Applying Planning and Production Techniques ......................................................29
Overall Reflection on Planning and Production Techniques .................................................................30
Overall Project Evaluation ........................................................................................................................31
References ....................................................................................................................................................31
1. Introduction
1.1 Purpose This document’s purpose is to show the progress and implementation of an Arduino Uno and other
components, so that it is compatible with a Unity project. Using this document will ensure that the
project is kept on track, therefore meaning no-over scoping and wasted time will occur. The product
being developed will be initially outlined and any iteration will be marked with a version update on the
document. Doing this will ensure that I can see if my project will meet the given submission goal.
The software will be developed within Unity, which will communicate with the Arduino. Any changes
being made, be this to any software, hardware requirements will be later updated, therefore ensuring by
final release this document will follow alongside the application correctly. The project and this document
was made for the Console Programming Resolution unit at the University of Portsmouth.
1.2 Scope The main scope of this project is to create an artefact that can communicate with an Arduino. The chosen
software will be the Unity engine. From here the main goals is to create an executable that people can
use that will communicate with an Arduino driven robot. This will show clear understanding of the
Arduino hardware and components. Therefore, programming functionality for the Arduino hardware will
be achieved by using the Arduino software, and programmed in a similar language to that of C++/C.
Furthermore, Bluetooth will be used to communicate with the robot from the Unity project. It is vital that
any code being created can be adaptable and easily understood and used amongst a variety of people.
1.3 Definitions, Acronyms and Abbreviations
Acronym Definition Explanation
SDK Software Development Kit A set of software tools that allow for the creation of applications for certain software packages.
GPU Graphics Processing Unit A processer designed to handle graphics operations, including 2D and 3D calculations.
CPU
Central Processing Unit A component that allows the computer system to complete and execute program instructions.
GUI Game User Interface / Graphical User Interface
A user interface that allows for users to interact it from an electronic define. This will include graphical icons and visual indicators that clearly shows the user what each component does.
COM Communication Port Common name of the serial port interface, this will refer to physical ports, but also virtual ports created by Bluetooth or USB.
USB Universal Serial Bus Industry standard protocol that defines connections, communication and power supply between devices.
2. System Requirements Specification
2.1. General Description The factors that will affect the product and the requirements will be outlined in this section.
2.1.1 Product Perspective This product will make use of the Arduino Uno, an Arduino Sensor Shield v5.0, an L2989N Dual-H Bridge
Motor, four 35V DC motors and a HC-06 Bluetooth module. Other modules and components may be used
later in the development of the project; however, these are the main components that will allow the
hardware to function. These components will be programmed to communicate with the Unity game
engine. Therefore, the user must have access to the Arduino software to make any amendments they
wish to the given script, and using the correct version of Unity which will be later stated in the project.
The user must have access to a Bluetooth module, as this will allow them to communicate with the
hardware.
Arduino
Hardware
Bluetooth
Device / USB
Connection
Bluetooth
Component
COM Port Serial Port
Reader
Port Threading Unity Artefact
2.1.2 Product Functions This product will allow those using it to communicate with an Arduino driven robotic device from a Unity
application. The project will include a simple code base that the user can modify and create an
environment for their own Arduino interaction. The test project being created should allow the user to
freely drive the robot themselves via the Unity engine. The product is required to be flexible, therefore
should work on numerous PC’s. However, the main hardware itself must be built to the right
specification.
2.1.3 User Characteristics The tool itself is being developed for the use of the COPRE unit. Therefore, it should be used for
educational purposes. However, if the tool is robust enough to be used amongst various users it can be
released publicly. Tests will be carried out throughout the project to ensure that the tool is robust and
easy enough to use. The scripts being created should be optimised and commented thoroughly.
2.1.4 General Constraints The project itself will be constrained with the hardware built for the Arduino. Arguably these components
can be switched out, however it is advised that the user only adds those components that have been
outlined in this document. As the project will be programmed in Unity. It will be constrained to the use
within this engine.
2.1.5 Assumptions & Dependencies After thorough testing it is assumed that the project can run on various computers and will adapt to the
COM port being sent from the computer. However, one will have to consider errors and other
occurrences that may arise on certain machines. Therefore, it is important that the project is using a
version of Windows 7 or above.
2.2 Specific Requirements
Project Overview This project will make use of the following devices listed above. They will be engineered together in such
a way that they can communicate with one another. The main component, the Arduino Uno will work as
the motherboard for rest of the components, this will allow you to upload data or sketches to the device.
The robot itself will be relayed to communicate with Unity. This will make use of SerialPort class, to
access this within Unity you must use the namespace System.IO.Ports. Information on how this is used
can be found on the Microsoft Developer Network. This is a class that allows for communication over a
COM port. However, throughout this project scripts will be used, researched and written from scratch.
Above are examples on how the SerialPort class can be accessed and set up. The class itself requires you
to pass two conditions at a minimum, this includes the COM port that the Arduino is accessing. One thing
to consider when defining the COM port is that it may change depending on the machine you are using.
As the Arduino will be using Bluetooth instead of being directly plugged into the PC. A COM port
connection must be set-up within the Bluetooth setting window, this will allow you to send signals from
your computer.
Alongside Unity the Arduino software will be used. This will be written in a form of C/C++, and uploaded
to the Arduino hardware directly. This is where motor speed can be accessed via the Bluetooth module.
Within the Arduino software you can also check the Port the Arduino is using and stating which board
you are using. For this project the board is use will be an Arduino/Genuino Uno.
2.2.1 Hardware Requirements
H1 – Most Optimal Hardware Requirements (100M) The project itself will require minimal hardware requirements, the graphical side of the project will not
require high performance. From this one can say that project will able to run on different set-ups. Below
are the specifications that the project itself was built on.
PROCESSOR Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
GRAPHICS CARD NVidia GeForce GTX 980
MEMORY 32.0gb Ram
H2 – Arduino Uno (100M) The Arduino Uno will be used as the base plate for the hardware. This will second signals from the PC to
the Arduino and upload the sketch to this. The Arduino will hold this data until another sketch is
uploaded. This will also detect power input from the battery pack. To extend the board an Arduino sensor
shield v5.0 will be attached. This will ensure enough pins are available for each component on the robot.
H3 – Arduino Sensor Shield V5.0 (100M) This will serve as an addition to the Uno. This will allow for Bluetooth integration, extended pins to allow
for 32 steering controls. This board also has 13 D0-13 Digital IO Ports. These will be used to power the
motors and the rest of the components. Furthermore, this board also comes with other features
including an ultrasonic sensor interface and SD card module communication interface, meaning it can
easily be expanded.
H4 – L2989N Dual-H Bridge Motor Connector (100M) This will be used to drive the motors themselves. This will allow you to control the speed and direction of
two DC motors. This can be used on motors between 5 and 35V DC’s. The main components include four
outs, two controlling the left hand-side motors and the other half controlling the right-side motors. The
back two components will be used to feed 12 volts to the L2989N Dual-H Bridge Motor Connector.
H5 - HC-06 Bluetooth Module (100M) This will be used to send signals to the robot and control it from Unity. The advantage of using the
Arduino Sensor Shield, allows for easy input, as you simply slot it into the APC220 Bluetooth interface.
This will hold the main connection from the game engine to the hardware.
H6 – Two BRC 18650 4200mAH 3.7V li-ion Batteries and Power Pack (100M) These will be used to power the entire Arduino system. It should be noted that these batteries must be
charged fully before using the Arduino to deliver exact results.
2.2.2 Software Requirements
S1 – Unity Engine (100M) The project will use Unity engine to access the hardware, this will allow for the serial port from the
Arduino to be read and any threading that is needed. The same version will be used throughout the
project to ensure no errors occur.
S2 – Arduino Software (100M) This will be used to send scripts to the Arduino hardware, this will hold data which can be access through
different ports through Unity.
Name Unity Engine
File Name Unity.exe
Size --
Version 2017.1.1
Download https://unity3d.com/get-
unity/download/archive
Name Arduino Software
File Name arduino.exe
Size --
Version 1.8.5
Download https://www.arduino.cc/en/Main/Software
2.2.3 Interface Requirements With all hardware and software requirements considered, an artefact will be developed that ties in the
Arduino robot’s functionality within Unity. The interface of this will represent an exact measured area for
the robot to map into the virtual world. It will show a top-down view so the user can clearly visualise the
area, and therefore see if the robot within Unity is matching with the real one.
I1 – Screen Design (100D) The screen below gives an approximation of what the application will look like once and Arduino
connection has been made between the robot and unity. The game itself will take a measured out
rectangular area and map those same dimensions into the game engine. The dimensions of the area will
be decided later in production; however, it is crucial that these measurements are exact to have accurate
results.
Throughout development the measurements of the area were decided. The rectangle itself was rotated
ninety degrees from the diagram above. The area itself would be 160x288cm, tiles were added, these are
32x32cm. To ensure the experiment matches up with that of the real world. When reusing the
application this area must be measured exactly to have accurate results. Furthermore, where ever the
virtual robot is placed within Unity. The real one must be placed in this same area. Cubes were also
placed within this area. These would act as obstacles for the robot. If the robot collides with one, the
robot in real life will stop, just as the robot in the virtual world will.
I2 – Key Mapping (100D) It was decided that to control the robot within Unity the player must use WASD. To move the robot,
forward the player must press the W key. To rotate the robot the player must press either A or D. To stop
the robot the player must press the S key.
2.2.4 Functional Requirements
F1 – Serial Port Integration (100D) This will drive the entire communication through Unity via a COM port which will communicate with the
Bluetooth device. This library is part of the .NET Framework; therefore, Unity must be changed to
become compatible with this. Constructors for the library can be found on the Microsoft developer
network (SerialPort Class, 2018). Appropriate methods must be used to enable a communication from
the engine to the Arduino board.
F2 – Bluetooth Integration (100D) With a serial port integration connected, the Bluetooth device must be modified to allow for an output
port. This will therefore allow a communication from the computer to the Arduino device. It is paramount
to use either the Arduino adapter HC-05 or HC-06. Later models use a different frequency of
communication via Bluetooth, therefore will not pair with current Bluetooth software on computers.
F3 – Movement (100D) With a communication made, the robots must be able to move via key inputs. Therefore, within the
Arduino code, a line must be outputted to read for input via write commands using the Serial Port class.
This will therefore identify the character being passed, allowing the Arduino hardware to access the
appropriate statement. For example, when the W key is pressed within Unity, this must send a W
character to the Arduino hardware, which will access the appropriate methods to drive the motors.
F4 – Position & Rotation Matching (100D) The Arduino control car must match the same movement and rotation speed as that of the virtual robot.
Therefore, testing will have to be conducted in ensuring the position and rotation is matched.
During testing it became apparent that the batteries powering the hardware needs to be fully charged to
match that of the in-game robot.
F5 – Collision Detection (100D) Collision detection will allow the real robot to react from the virtual robot’s interactions. For example,
when the in-game robot hits a wall, the real robot will respond to this, therefore mapping correct AR
behaviour.
2.2.5 Performance Requirements
P1 – Frame Rate (100M) Due to there being a serial port connection, it is recommended the project is running around 60fps. This
is to ensure the correct signals are being sent to the robot, and therefore allowing a clean connection.
P2 – Memory (100M) It is crucial there are no memory leaks within the project. All memory behaviour will be monitored inside
the game engine, if any lag is found, optimisation can be made.
P3 – Serial Port Communication Time (100M) This will rely on P1 and P2 being fully optimised. The serial port communication time should be swift and
react to actions when the user presses a key. For example, when the player moves the robot forward it
should seamlessly react to the virtual robot’s movements.
2.2.6 Reliability Requirements
R1 – File System Stability (60M) Throughout the project, files within the project will be sorted into their designated areas. This will ensure
the project is clean and easy to understand, not only for future production, but for those who wish to
study the experiment.
R2 – Game Runtime (100D) The game will be expected to run for a considerable duration. However, it is recommended that the
project is shut down if the experiment is not being conducted. This will ensure that the robot is
maintaining full battery power, therefore allowing the system to run functionally.
2.2.7 Design Constraints
D1 – Hardware Specification Due to the nature of the experiment, the project will run solely on the hardware specifications previously
outlined, furthermore, the correct area must be measured out for this experiment to function correctly.
3. Software Design Description
3.1 Detailed Design Description
D1 – Loading Game Scene The table below will give an idea of how the experiment will initially launch.
Sub-Components Unity Engine
Dependencies Unity Engine
Used By Arduino Hardware Components
Switch on Bluetooth Arduino Car.
Ensure LED light on Bluetooth device
is no longer flashing red and is a static
red.
Position robot in the same positioning
as virtual robot.
Press play within Unity.
Serial Port Communication & Reader
script allows for port communication
with Arduino controlled robot. Ensure
correct output port is given.
D2 – Bluetooth Arduino Control Car Movement Below shows how the robot will be moved within the Unity Engine
Sub-Components Unity Engine, Serial Port Communication, Movement, Position & Rotation. All Reliability & Performance Requirements.
Dependencies Unity Engine and All Hardware Requirements
Used By Arduino Hardware Components and Unity Engine
Begin
If W is pressed
Move Virtual Robot Forward
Move Real Robot Forward
Else if A is pressed
Rotate Virtual Robot Left
Rotate Real Robot Left
Else if D is pressed
Rotate Virtual Robot Right
Rotate Real Robot Right
Else if S is pressed
Stop Virtual Robot Movement
Stop Real Robot Movement
End
D3 – Collision Detection Below will give an overview, if the virtual robot collides with an object within the virtual world.
D4 – End Game State Below indicated how the serial port communication will be manged when the game is closed.
Sub-Components Unity Engine. All Functional Requirements. All Reliability & Performance Requirements.
Dependencies Unity Engine and All Hardware Requirements
Used By Arduino Hardware Components and Unity Engine
Sub-Components Unity Engine. All Functional Requirements. All Reliability & Performance Requirements.
Dependencies Unity Engine and All Hardware Requirements
Used By Arduino Hardware Components and Unity Engine
Begin
If virtual robot collides with
tagged object in the world.
Stop the virtual robots
movement.
Send signal to robot and stop
movement.
Ensure the player can no
longer move the robot unless
No longer colliding with
object object
End
Begin
If application is closed
Close all communication with
Arduino robot.
Ensures port can be re-opened
when project is next launched
End
3.2 Requirements Mapping
Requirements Design Mandatory Importance
H1 D1, D2, D3, D4 Y 100
H2 D1, D2, D3, D4 Y 100
H3 D1, D2, D3, D4 Y 100
H4 D1, D2, D3, D4 Y 100
H5 D1, D2, D3, D4 Y 100
H6 D1, D2, D3, D4 Y 100
S1 D1, D2, D3, D4 Y 100
S2 D1 N 60
I1 D1, D2, D3, D4 Y 100
I2 D2, D3 Y 100
F1 D1, D2, D3, D4 Y 100
F2 D1, D2, D3, D4 Y 100
F3 D2, D3 Y 100
F4 D2, D3 Y 100
F5 D3 Y 90
P1 D2, D3 Y 100
P2 D1, D2, D3, D4 Y 100
P3 D2, D3 Y 100
R1 D1, D4 Y 100
R2 D1, D2, D3 D4 Y 100
4. Project Plan
4.1 Project Organisation
4.1.1 Life Cycle Model Below shows the basic outline of the projects development. This should be followed throughout
development to ensure that the project will meet its end goal, ensuring all learning outcomes are met.
Ensuring there is a clear development cycle of my project is crucial. This would ensure that the scope of
my project is understood, therefore ensuring I will able to cope with the work load given. A prototype of
Arduino components will be implemented to ensure that this project is possible. This will test certain
functionality as previously outlined in this document. For example, this would be in the form of simply
turning an LED light on via a Bluetooth connection on the Arduino components. Testing the product is
extremely crucial in ensuring the experiment matches up with the previously outlined requirements. For
example, the position and rotation mapping will take a considerably long time, as one could argue that
mapping a virtual robot to a physical one will require numerous iterations of improvement.
4.1.2 Project Organisational Structure The project organisation regarding testing via peers and client reviewer will flow in the following manner.
Outline
Requirements Design Outline
Outline
Development Outline Testing
Prototype
Experiment
Development of
Main Design
Component
Creation Experiment Creation
Test Experiment
Features Review Testing
Feedback Make changes
based on feedback
Complete Reflective
Report
Student (Project
Manager, Developer)
Student Reviewer (Peer-
Reviewer)
Staff Member (Client
Reviewer)
4.2 Managerial Process
4.2.1 Management Objectives & Priorities To ensure the project is kept on track, discussion of the experiment will be conducted weekly with the
unit coordinator. This will ensure he is pleased with the project scope and the implementation of both
the hardware and software. Furthermore, this will allow for feedback, and any issues I pose could be
resolved in this time. Regular peer reviews will be conducted and verbal feedback on the project will be
conducted throughout the projects life cycle.
4.2.2 Assumptions, Dependencies & Constraints It has been stated that a certain number of hours is required on this project. Therefore, tasks should be
split into realistic goals, therefore meaning any assumptions, dependencies or constraints on the project
will not halter development. Due to the artefact submission being in the month of April, development on
the artefact, documentation and any work required should be worked on up to this time.
4.2.3 Risk Management Outlining any risks that may occur throughout development and creating contingency for them will
ensure that development is kept to the end due date. Furthermore, this will outline the severity of issues
if they arise, and what can be put in place to prevent these from happening in future development.
Event or Risk Probability Severity Preventative Steps
Contingency
Issues with Serial Port Integration
Very Likely Medium Thorough background and prototyping into how the serial port functionality works.
Ask for assistance on forums, and any create communication with those that have experience in this field.
Hardware Failure Very Likely Low Ensure that spare components are at hand if hardware fails.
Care must be spent managing the hardware. As short circuits is a high possibility with this hardware.
Corruption Medium/High Very High Ensure the project is thoroughly backed up.
Revert to a previous build when the project was working.
Delaying of Development
Medium Medium Ask peers and client for their opinion on the problem.
Consider another way I can approach the problem, perhaps one that doesn’t include such severity.
Loss of Time Management
Medium Medium Frequently keep up to date with the plan and ensure all tasks are being performed.
Able to adapt the project ready for the post project review.
Project Scope Low Medium Constant peer reviewing on their opinion on the project and what direction it’s taking.
May need to consider taking the scope down and creating something simpler.
4.2.4 Monitoring & Controlling Mechanisms Due to this project never being previously approached numerous reviews must be taken throughout.
Time management will be monitored to ensure that the project is still on track with the end hand in date.
Personal reviews and reflections will be made at the projects end date, this will ensure all learning
outcomes have been achieved. Furthermore, it will allow others who are interested in this field to see
any problems that rose during development, how to ensure these do not happen, and what the future
holds for this experiment.
With risks outlined, the project should flow to its finished end date with a finished product. It will ensure
any problems ran into can be resolved with any major impact to the study.
4.3 Quality Planning
4.3.1 Code Implementation To ensure that this project can be reused in future studies the code should follow standard coding
conventions. Within the Unity engine C# will be used throughout the development of this project.
Primarily this is due to the programmer’s personal preference on the project. However, this is also due to
the fact of the SerialPort API, which can be seamlessly accessed within C#. Throughout the whole project
an Allman-style indentation style will be used. This is due to personal preference from the programmer.
For any classes and functions within the project, pascal casing will be used, this is due to it being
consistent with .NET framework and is easy to understand for future developers. Furthermore, camel
casing should be used in function arguments and variables.
Below shows a pipeline on what should be followed for correct code implementation throughout
development.
4.3.1 Commenting Standards Comments should be created for functions or statements that are not entirely clear. These should be
placed on a separate line above. Summaries should be created for the scripts that are overly complex.,
these should give an overview of how the script functions and its overall use. Furthermore, pragma
regions should be used for functions that are overly complex, to give a clear overview of its use.
4.3.2 File/Folder Naming Scheme To ensure the project is reusable in future development, files should be given a clear description and
contained within their appropriate folders. For example, all scripts should be a clear indication of their
use before opening, and stored within a scripts folder.
4.4 Work Packages, Schedule & Budget
4.4.1 Schedule Below indicated the plan which was intended to be followed at the start of production. It will show a
breakdown of tasks, and at what point they will end.
4.4.1.1 Actual Plan Below shows the actual plan which was followed through the project. It became clear that testing began
at an earlier stage, due to challenges arising with hardware failures and integration. Furthermore, it
indicated that the development of the main design had to be constantly revisited throughout
development due to these challenges arising.
4.4.2 Budget The budget itself will cover costs for the hardware being built. This will require expenditure for all
hardware requirements and replacements if a fault is found within one of the units.
5. Test Plan and Results This section will outline all elements I have tested within the project. It will show how the design is lined
up with the requirements, all the test cases with the date it was passed. This will allow me to see if future
productions which areas need care in approaching, and what methods were deemed unsuitable.
Requirement Design Test Test Case Status
H1 D1, D2, D3, D4 T1 Does the project meet the optimal hardware requirements?
Passed
31/10/2017
H2 D1, D2, D3, D4 T2 Has an Arduino Uno been implemented within the hardware?
Passed
20/11/2017
H3 D1, D2, D3, D4 T3 Has an Arduino Sensor Shield V5.0 been implemented within the hardware?
Passed
20/11/2017
H4 D1, D2, D3, D4 T4 Has an L2989N Dual-H Bridge Motor Connector been implemented within the hardware?
Passed
23/11/2017
H5 D1, D2, D3, D4 T5 Has a HC-06 Bluetooth Module been implemented within the hardware?
Passed
11/01/2018
H6 D1, D2, D3, D4 T6 Have two BRC 18650 4200mAH 3.7V li-ion Batteries and Power with a power pack been implemented?
Passed
01/12/2017
S1 D1, D2, D3, D4 T7 Has the Unity project been set up?
Passed
04/12/2017
S2 D1 T8 Has the correct Arduino code been created for the Arduino Robot?
Passed
15/01/2018
I1 D1, D2, D3, D4 T9 Has a finished design been created for the experiment?
Passed
13/02/2018
I2 D2, D3 T10 Have the final key mappings been considered?
Passed
09/01/2018
F1 D1, D2, D3, D4 T11 Has a final serial port connection been implemented?
Passed
20/02/2018
F2 D1, D2, D3, D4 T12 Has Bluetooth integration been implemented?
Passed
01/03/2018
F3 D2, D3 T13 Has movement been successfully implemented?
Passed
20/03/2018
F4 D2, D3 T14 Has correct positioning and rotations been implemented?
Passed
14/04/2018
F5 D3 T15 Has successful collision detection been implemented?
Passed
16/04/2018
P1 D2, D3 T16 Has the final frame rate been reviewed?
Passed
17/04/2018
P2 D1, D2, D3, D4 T17 Have any memory leaks occurred? If not pass.
Passed
17/04/2018
P3 D2, D3 T18 Is the serial port communication time adequate?
Passed
17/04/2018
R1 D1, D4 T19 Are all the files/folders suitable?
Passed
18/04/2018
R2 D1, D2, D3, D4 T20 Does the game run without a serial port connection loss?
Passed
18/04/2018
Reflection on Project
Learning Outcome 1: Produce Functional Gaming Software Throughout development Unity was the primary choice of software. The chosen language was C#, this is
due to its integration with the chosen game engine. Moreover, it also allows for the integration of the
two classes which are part of the .NET framework. The Serial Port class (SerialPort Class, 2018) allowed
for a seamless connection to be made over virtual COM Ports. Within this project this involved
communicating with a Bluetooth driven Arduino robot car. Therefore, a virtual port output
communication had to be made on the device. From this a script was implemented making use of the
appropriate functions within the class. The most important features of this script were as followed.
Creating a static Serial Port which would define access to the designated COM port and the baud rate of
the hardware. In this case the hardware’s board rate is set to 9600, this specifies how fast the data
should be sent over the serial line, the units are then sent over in bits-per-second. Due to the overall
speed not being critical, the hardware would be set to 9600. It should be noted that these values can be
modified, depending on the COM port being accessed and the baud rate, and will not affect the overall
communication (Figure 1).
In addition to this, threading was implemented within the system. This made use of the System.Threading
namespace within the C# library (System.Threading Namespace, 2018). It was found throughout
development that errors would be thrown when running the application. From research this was due to
the COM port not being closed when it was accessed. This is due to the fact that a ReadTimeOut (Figure
2) had to be kept running. This works by obtaining the number of milliseconds before a time-out occurs
within the system, or when a read operation does to finish.
To solve this threading was implemented, this ensured that if a connection was made the COM port itself
would be closed, therefore not only optimising the overall connection by adding it to a thread, but
ensures safety within the system. Once the connection had been added to the thread it was locked,
ensuring that time out reading would be analysing only the thread instead of the whole COM port system
(Figure 3 & 4).
Figure 1
Figure 2
Figure 3
Overall the use of threading whilst accessing the Serial Ports within the system was extremely crucial. It
solved errors that impacted the overall connectivity with the Arduino system. Without the use of this, the
communication with the hardware would hold a delay due to the amount of errors being outputted
within the system. From this I have learnt how threading can be used with serial port connections, and
how this can be emulated in future projects that uses a similar method of functionality.
With this functionality implemented, communication could be made within the system. Throughout
testing to try and achieve a successful communication with the Arduino robot, it was found that an
enumerator had to be used to initialise states within the system. At the start of development, a Boolean
was created to initialise states, however it was found an additional check had to be fired to create a
communication, the diagram attached outlines how an additional enumerator check has to be given to
send signals over the COM port (Figure 5 & 6).
From this the Write function was implemented from the Serial Port class. This accesses the variable
stored within the Arduino hardware and runs the appropriate functionality. For example, when the W key
Figure 4
Enum State
CAR
FORWARD
START
Initialises the
forward
movement
Arduino code.
CAR
FORWARD
RUNNING
Runs the
forward
movement
Arduino code.
Figure 5
Figure 6
is pressed it will write a command of “f” accessing the forward functionality. This works in conjunction
with collision detection within this experiment. Once the virtual robot has hit a cube, the real robot will
react to this, being unable to move forward and only the ability to turn. To achieve this a Boolean check
had to be implemented which would turn off the forward functionality. Although there is the
functionality to check whether an object is staying collided with an object, it was found this lagged the
communication over the serial port due to the amount of checks being outputted. Therefore, a Boolean
check that would lock forward movement was found as the most efficient solution and allowed for the
experiment to be tested.
Overall Reflection on Software Functionality Looking at the overall software functionality it allowed for a seamless connection via a serial port
connection. With the use of the threading it allowed for an even optimised solution to send data to the
Bluetooth device. Numerous challenges were overcome to ensure that instant communication could be
made with the real robot reacting to its virtual copy. With the correct connection made it allowed for
thorough testing to be made for speed and rotation to be matched. Furthermore, these scripts will allow
for an integration of numerous other devices that communicate over a COM channel. From this process I
have learnt how to successfully create a connection from software to hardware.
Learning Outcome 2: Critically Assess of Console Hardware The hardware for this project makes use of four different components. The first of these being the
Arduino Uno board. This works as the microcontroller for the rest of the components, it includes a single
microprocessor and works at driving the rest of the hardware. This almost works as a motherboard for
the system, any code created for the hardware will be stored within this and can be externally accessed
via data being sent. A second hardware component, the Arduino Sensor Shield v5.0 is also used. This
serves as an extension for the Uno, and allows for extra functionality with plug-in pins and adapters, this
was extremely essential in testing components and ensuring the right connection is being made. The
L298N Dual-H Bridge Motor Module was also used in conjunction with the other hardware to drive the
motor speeds on the wheels. Connections were made from this to Arduino Sensor Shield in designated
pins in which the speed and rotation could be modified via the Arduino code. The last component was
deemed the one where a lot of knowledge was gained. During the start of production an Arduino
Bluetooth device, the HC-08 was used in the building of the robot. However, when moving into the
software development stage it was found this device would not be suited for this project. From research,
it was found that the HC-08 uses a different form of connection, Bluetooth Low Energy (BLE). This form of
communication is regularly found in components that draw little amount of power, for example in fitness
devices (Bluetooth Low Energy Overview, 2018). From further research it was found that this sort of
communication would not be deemed possible for this experiment, as a BLE connection cannot be made
to an integrated Bluetooth communication found in a PC or laptop. Although this posed a great challenge
to the overall experiment, from further research it was found older modules still use the Bluetooth
Classic connection. From here a HC-06 Bluetooth module was implemented with the project. From
testing it was found it could make communication with standard Bluetooth devices, therefore allows for
COM port communication. Although this was a major challenge to overcome, through development
numerous problems occurred with the hardware. The majority of these stemmed from hardware units
frying throughout development, problems with wiring and connection problems. Due to the
implementation of a risk assessment the majority of these were overcame and did not sway the project
from meeting a successful outcome. Furthermore, I have learnt from this what challenges can arise when
developing on this hardware, and what checks need to be made in the future to ensure no time is wasted
trying to find the problem. For example, during development it was found there was a problem with a
faulty wire connection from the motor module and the shield module. This led to one set of the motors
not moving, due to a faulty connection. However, from debugging the hardware it was the problem was
found, and therefore if this problem arises in the future a quick solution can be made.
As previously mentioned Arduino code had to be implemented onto the hardware. This was written
within the Arduino software, which is a form of C/C++, however also contains its own custom
functionality (Figure 7 & 8).
Figure 7 Figure 8
This software allowed for custom code functionality to be passed directly to the Arduino Uno. Arduino
functionality was used to access certain pins on the board and set the voltage of the motors. The pins
being accessed were declared as variables 5-10, the same input on the Arduino Sensor Shield (Figure 9).
From here custom voltage values can be set. For example, within the forward function, the analogWrite
function was used, therefore allowing to set custom voltages. This is different from digitalWrite, which
only allows you to declare whether the voltage is high or low. In some cases, for turning this was the best
option to set the motor speeds. Two additional important functionalities within this is Serial.begin() and
Serial.read(). The Serial Begin function sets the baud rate for the board. As previously outlined, this
should be set to 9600, as the data being sent does not need to match a set speed. The Serial Read
function allows for a set variable to be accessed via an outside communication. In context to this project
it would be sending data to access the function calls on the hardware, for example accessing the right
functionality when the W key is pressed within Unity. Looking into documentation a deep understanding
on hardware data and voltage access was understood from this. It became clear how additional
functionality could be created with this, and what components could be added in future development.
Overall Reflection on Hardware Functionality Looking at the overall hardware implementation it allowed for a seamless connection to be made on the
software. It was created in such a way so it is module with the use of an Arduino Sensor Shield which
allows for pins and modules to be plugged in. Although problems occurred, research in those areas were
made to identify the problem, and ratify these in future development. Therefore, one can argue this
experiment was an overall success. My overall goal was to create an augmented reality robot which
would react to the behaviour of the virtual robot, therefore with optimisation and the correct hardware
being chosen and programmed, this was achieved. From here this project poses numerous studies that
can be looked into. For example, one area that will be researched after development is how to achieve
pin-point position and rotation. Researching into other modules includes the use of a gyroscope, which
will be able to read the overall orientation and measures the rate of change on an axis. In theory, from
Figure 10
here calculations can be made to obtain the axis of the real robot and map that to the virtual one,
therefore allowing for a pin-point location being made. Furthermore, research can be looked into
emulating that of a tracked area by using an Ultrasonic sensor module, this would measure the speed of
sound from hitting an object. From here a formula can be made, time = distance / speed. For example, if
an object is 10cm away, and the sound being emitted is being sent at a frequency of 340m/s, the sound
wave could be travelling approximately 294 microseconds (UltraSonic Sensor HC-SR04, 2018). However,
as the Ultrasonic module will be bouncing between the object and itself, the value will have to multiply
the received time it takes for the sound to return to the module by its set value of 0.034 and divide that
by two. From here an overall calculation can be made (Figure 11).
Although this is all in theory, it poses some research and testing that be iterated upon this project in
order to read the objects position and speed.
Learning Outcome 3: Applying Planning and Production Techniques Throughout development two main principles of planning were used. The first of these making use of the
Strategic Systemic Thinking framework (SST) (Bednar, Gillian, Bain, & Eglin, 2004). This was used at the
start of development and was a crucial step in identifying what type of hardware I wanted to access, and
generate ideas from. These ideas could then be developed and continuously evaluated using this model,
to ensure not only is the scope of the project realistic but ensures that the developer has a strong
understanding of what they need to do, and how to finish development to a successful outcome (Figure
12).
Speed of sound:
v = 350 m/s
Distance:
s = time * 0.0.34 / 2
Overall calculation:
Time = s / v = 4 / 0.034 = 294 microseconds
Figure 11
Looking at this model in depth, it further allows for a process of evaluations on the project. This is
extremely important and became extremely useful when analysing the risks for the project, and what
alternatives could be created if a challenge could not be overcome. Although this model was used
throughout the development of this project it poses use in future development, and those projects that
require an iterative process. Overall, this process of initial project planning shows how it can be
successful implemented in a hardware development process. Furthermore, the use of this also allowed
for verbal feedback to be made weekly with the unit coordinator and peers, to ensure that my vision of
the project was deemed possible, and therefore would be possible for creation.
From using the SST, further project planning was made. This was in the form of a Product Development
Document, or ‘Document of Success’. This was created after the SST process, and allowed for splitting up
the project into designated areas, and what needs to be created from them in order for the project to
become a successful. One would argue this method of planning is extremely important in any software
and hardware development. Primarily this stems from the fact that this allows you to update the
document throughout the project. Therefore, allowing the reader to see where amendments had to be
made. As the programmer, this was extremely useful in ensuring I could see if the project was on track,
and that if all hardware and software functionality was identified. Therefore, from this a direct approach
could be made in implementing the artefact. Furthermore, due to the possibility of updating the
document this project and its planning methodology can be carried forward into future development,
allowing the reader to identify where the project started and what methods were used to iterate upon its
functionality. When creating this document, it was intended to meet professional standards and include
all details necessary. This was to ensure that if someone was to create this project on one similar they
could identify the functionality required for both hardware and software, and what test plans had to be
considered when testing the projects overall fidelity.
Overall Reflection on Planning and Production Techniques Looking at the overall planning techniques implemented one would argue these were extremely
important in ensuring this project was a success. The use of a continues SST iterative framework allowed
me to understand if the project was on scope. Furthermore, communicating with the unit coordinator
and peers further allowed me to see if my plan was reaching its overall end goal. Although from the
actual plan outlined in the Product Development Document showed some differences from the initial
one, this was primarily down to learning the hardware and software. If it was not for the use of a
Document of Success and a strong planning framework behind it, one could argue this project would lose
its vision, and the requirements of it would become convoluted. Therefore, one can summarise that
when creating any hardware or software project, both planning methodologies are extremely important
in ensuring it reaches a successful outcome.
Overall Project Evaluation At the start of development my vision was to create an Arduino driven robot that could map the
movement of a virtual one within Unity. One can say this was successfully achieved, and poses future
research that can be developed upon. The use of the SST and Document of Success were seen to be
extremely useful throughout the development of this project, and are seen to be extremely crucial when
planning future projects.
References Bednar, P., Gillian, G., Bain, A., & Eglin, R. (2004). Contextual Analysis in Practice. Systemist, x1-x9.
Bluetooth Low Energy Overview. (2018, April). Retrieved from Android Developer:
https://developer.android.com/guide/topics/connectivity/bluetooth-le
SerialPort Class. (2018, January). Retrieved from Microsoft Developer Network:
https://msdn.microsoft.com/en-us/library/system.io.ports.serialport(v=vs.110).aspx
System.Threading Namespace. (2018, April). Retrieved from Microsoft Developer Network:
https://msdn.microsoft.com/en-us/library/system.threading(v=vs.110).aspx
UltraSonic Sensor HC-SR04. (2018, April). Retrieved from How to Mechtronics:
https://howtomechatronics.com/tutorials/arduino/ultrasonic-sensor-hc-sr04/
