Virtual Driver Assistant

Supervisor:

Doctor Omer Raiz

Submitted by:

Muhammad Ali Hamza

Session:

BSCS (Morning)
Roll No. IU15M2ba013
Session 2015-19

Department of Computer Science & IT

 1

Table of Contents
Chapter 1. INTRODUCTION

1.1 Purpose

1.2 Scope

1.3 Technologies Used

1.4 Definitions and Acronyms

1.5 References Material.

1.6 Application and Docs Overview

1.7 Product Perspective

1.8 Product Perspective

1.9 User Characteristics

1.10 General Constraints

1.11 Assumptions and dependencies

Chapter 2. Software Requirements System

2.1 External Interface

2.2 Functional Requirements

2.3 Use Cases

2.4 Non Functional Requirements

2.5 Logical Database Requirements

2.6 Design Constraints

2.7 Analysis Model

 2

Chapter 3. SYSTEM DESIGN AND ARCHITECTURE

3.1 Architecture Design

3.2 Decomposition Description

3.3 Design Rationale

3.4 Data Description

3.5 Component Design

Chapter 4. IMPLEMENTATION & TESTING

4.1 Overview of UI

4.2 Development Tools

4.3 Coding Modules

4.4 Screen Images

4.5 Testing
 3

Chapter 5. Future Work

5.1 Lesson Learned

5.2 Prediction Module

5.3 Speedometer Module

5.4 General Overview

Chapter 6. Supporting Information

Appendix A--Background Research on

Appendix B--Data Dictionary

Chapter 1. Introduction

Virtual Driver Assistant is an Android application which can help the driver during driving
in different perspectives. To enjoy the features of this app, the user will have to sign in
 4

using his mobile number or Gmail address. The driver can check the moving speed of
the vehicle during driving. The user can calculate the distance between two points and
an average time will also be provided to cover the measured distance. Aside from this,
the app will use the camera to recognize and predict the traffic light indication. The user
can share his current real-time location with others through SMS using the mobile
number. A brief guide about traffic signs has also been provided in the ap, which will
help the driver to learn about traffic light signals and signboards.

1.1 Purpose:
In this document, we describe the software requirements for a yet unnamed mobile
application, further referred to as Virtual Driver Assistant, an android application. It will
explain the purpose and features of the system, interfaces of the system, what will the
system do, the constraints under which it must operate and how the system will react to
external stimuli. This document is primarily intended to be proposed to a customer or
supervisor (in my case) for its approval and a reference for developing the first version
of the system for the development team.

1.2 Scope:
This software system will be an android application for anyone who wants to use the
Virtual Driver Assistant APP in their daily life or for any other purpose.
The system will be designed to help the user to
Detect traffic light signal using image processing.
Specific traffic Signs boards detection using image processing.
Provide voice instructions on detection of traffic signs.
Provide voice instructions on detection of traffic signals.
Provide speed of the vehicle
Provide how much is traffic flow through the map on the road.
Provide calculation of the distance from one point to another.
Search the other users of the app in the same area.
Share the live location of the app with other apps.
Make the history of assistant either save in DB or not.
Provide documentation on the guide of Traffic signs.
Provide documentation on the guide of Traffic rules.

1.3 Technologies Used:

The system software is written in Java Programming Language by using Jetbrains
Android Studio which is an IDE for developing Android Applications. I will use the
Android SDK for the development of the system.
 5

The user interface of the system is to be written or created in XML while backend
programming will be implemented in Java for Android. Further, I will use SQLite for the
local database and Firebase for cloud storage if it requires.
Image processing will be used for the detection of objects through the camera. I will use
google maps for calculating speed by dividing the covered distance over time. The last
but not least, Google Maps API and GPS will be used for location manipulation.

1.4 Definitions, acronyms, and abbreviations:

Terms Definitions

System It’s the software application itself that is going to be

developed.

Android A mobile device operating system developed by Google Inc.

Android app An application that runs on the Android Operating System.

DB The database is the collection of all the information

monitored by this system

Software A document that completely describes all of the functions of

Requirements a proposed system and the constraints under which it must
Specification (SRS) operate. For example, this document.

Android SDK Android software development kit which helps us to develop

an android app.

GPS Global Positioning System

Stakeholder Any person who has interaction with the system who is not a
developer.

IMP Image Processing.

AI Artificial Intelligence.

API Application programming interface

Firebase Google’s API for storing & retrieving data on/from the cloud.

VDA Virtual Driver Assistant

TL Traffic Lights

TS Traffic Signs
 6

Open-source software Software for which the code is freely available for use and
research

UI User Interface

Backend The code is written to perform different tasks in the

background either based on UI or not.

Android Studio IDE A programming environment by JetBrains to develop the

android app using Java, XML or kotlin.

Firebase ML Kit A Machine learning library powered by firebase.

1.5 References

● Roger S. Pressman, “Software Engineering a Practitioner's Approach.” The

McGraw-Hill 2010.
● Roger S. Pressman. Software Engineering: A Practitioner's Approach (Sixth
Edition, International Edition).
● IEEE Recommended Practice for Software Requirements Specifications IEEE
Computer
Society, 1998.
● IEEE STD 830-1998,
● Fowler, Martin. “UML distilled: a brief guide to the standard object modelling
language.” Booch Jacobson Rumbaugh, 2004.
● Android fundamental concepts and practical (Android Book by google 2016)
● Android advanced concepts and practical (Android Book by google 2016)
● Android official documentation https://developer.android.com.
● Firebase essentials (A Book on firebase by Neil Smyth 2017).
● The Institute of Electrical and Electronics Engineers, Inc., (IEEE ) IEEE, IEEE 1016
Software Design Document (SDD) Template for CENG491.
● IEEE, IEEE Std 1016-1998 Recommended Practice for Software Design Descriptions,
1998- 09-23.
● IEEE. 2009-07-20. Retrieved 2014-07-06
● Ian Sommerville. Software Engineering (Seventh Edition).

1.6 Application and Documentation Overview

The remaining portion of this document includes another four chapters. The chapter
second provides an overview of the system functionality, system interaction with other
systems, User characteristics, general constraints, and dependencies. This chapter also
introduces different types of stakeholders and their interaction with the system. Further,
 7

the chapter also mentions the system constraints and assumptions about the product.
It also provides the requirements specification in detailed terms and a description of the
different system interfaces, functional and nonfunctional requirements, logical database
requirements and design constraints. Different specification techniques are used in
order to specify the requirements more precisely for different stakeholders. In the end, It
deals with the prioritization of the requirements. It includes motivation for the chosen
prioritization methods and Analysis models including data flow, sequence and state
transition diagram. The third chapter will explain design and system architecture. The
actual implementation of the project will be provided in the fourth chapter.
The main goal of the project is to create a virtual driver assistant for the stakeholder.
The final product of the VDA project will be a mobile platform for Android mobile phones
or tablet systems that will enable third-party mobile application developers to easily
develop Android-based collection applications by utilizing the common Android services.
The VDA project will be an android application that is designed for users who want to
need help or assistance during driving. This project gives the user to an application
interface, by using this user can open camera of the application.
The system will capture images and process them with Image Processing techniques to
detect traffic light signals and traffic signs. Firebase machine learning kit will be used to
process the image and give predictions. If the system gets it, it will give instructions to
the user or more specifically to the driver using the voice. In this way, the driver will be
aware of each sign board or signal that will have passed.

1.7 Product Perspective

The system is divided into three parts: one is providing assistant through image
processing, the second is providing assistant without image processing and the third
part will provide documentation to stakeholders for learning about traffic rules or all the
stuff is needed for traffic guidance. Two parts are shown in the figure:
 8

In the first part, the system will be required to detect the traffic lights and signals
through camera using image processing.
In the second part, the system will have to do a lot of work. The system will be able to
give the user the distance between two points. Such means that system will use GPS to
calculate the distance between one place to another place which stakeholder selects.
Let’s talk about saving the history of system’s work into a local database so that
stakeholders will be able to see it later. Whenever the system detects any traffic signs
or light, it will immediately store it into the local DB. The system will need GPS or
accelerometer if available in the device to provide the driver his speed of the vehicle
during driving using. Same as it is the app will be needed GPS to share his live location
with other apps
Finally, the app will need to provide guidance to the user to learn about traffic rules.

1.8 Product Functions

The main functions of Virtual Driver Assistant are:

❖ User authentication through email or with Gmail.
❖ Detection of Traffic light signals through mobile camera using IMP.
❖ Detection of Traffic signboards through mobile cam using IMP.
❖ Giving voice instructions on detection.
❖ keeping history in local DB.
❖ Calculation of distance from one place to another.
❖ Providing speed of the vehicle.
❖ Sharing live location of Driver.
❖ How much traffic flow is on the road.
❖ Providing documentation of traffic guidance.
 9

The user will be authenticated using email or password If he doesn’t have an account
then the system will register the user with email or stakeholder can direct sign in using
Gmail.
The System will have the functionality to detect traffic lights or sign boards using the
camera then save it to the local database so that stakeholders could review it later.
Same as it is the system will be able to calculate the distance between provided any two
locations or speed of the vehicle and can share the live location of the driver with other
stakeholders or applications.

1.9 User characteristics

Users of this application are the android device user that loads the application and want
to use it. So all the users will be of the same type. That’s mean that There is only one
type of user on this app that will be the driver or person who will be driving vehicle and
want virtual assistance.
Operating environment is, as just mentioned above, is an Android OS mobile devices.
An android device that can support basic dependencies of the application is expected
for the proper user
Experience.
Only authenticated users will be able to use the services of the system and most of the
users would be the driver of the vehicle. So they are supposed to be the master of the
traffic rules and regulations but If they don’t have knowledge of traffic rules & regulation,
the system will provide guidance and documentation for the understanding of traffic
rules and all the related stuff of the traffic.

1.10 General Constraints

The mobile application is constrained by the system interface to the camera, GPS
system on the mobile phone. Since there are multiple systems and multiple GPS and
camera manufacturers, the camera will most likely not be the same for every one of
them. Also, there may be a difference between what camera features each of them
provides.
The Internet connection is also a constraint for the application. Since the application
fetches data from the GPS over the Internet, it is crucial that there is an Internet
connection for the application to function but the detection of traffic lights signals and
sign boards can be operated without internet.
Another important constraint is sensors which will be used in this app such as an
accelerometer is required by the system to calculate the speed of the vehicle. If the
mobile doesn’t have an accelerometer, the system will not be able to calculate the
speed of the vehicle.
 10

1.11 Assumptions and dependencies

One assumption about the product is that it will always be used on mobile phones that
have enough performance. If the phone does not have enough hardware resources
available for the application, for example, the user might have allocated them with other
applications, there may be scenarios where the application does not work as intended
or even at all.
Another assumption is that the GPS components in all phones work in the same way. If
the phones have different interfaces to the GPS, the application need to be specifically
adjusted to each interface and that would mean the integration with the GPS would
have different requirements than what is stated in this specification.
Same as it is a mobile device must have good Camera with handy features so that It
could detect the signs and signals properly. The camera will vary from device to device
which will also affect the performance of the system.
Last but not the least mobile phone is supposed to have good sensors such as an
accelerometer of calculation of the speed of the vehicle. So system also will depend on
it.

Chapter 2. Software Requirements System

This will be the largest and most important section of the document. This section
contains all of the functional and quality requirements of the system. It gives a detailed
description of the system and all its features.
 11

2.1 External Interface Requirements

This section provides a detailed description of all inputs into and outputs from the
system. It also gives a description of the hardware, software and communication
interfaces and provides basic prototypes of the user interface.

2.1.1 System Interfaces

In this cluster, the system interface is to describe. Each system interface and
functionality of the software to accomplish the system requirement and interface
description to match the system will be listed.
The system will be needed an interface through which stakeholders can open the
camera and camera will do its task. The system will need to used OpenCV API to boost
up the camera to detect the Traffic signals and signs boards.
Same as it is System will be needed an interface that enables the stakeholders to
calculate the distance of two places, for this system need to use google maps to find
places. The system will require an interface in which stakeholders can share their live
location and can calculate the speed of the vehicle.

2.1.2 Interfaces

In this bunch of paragraph, It is explained that how the system will interact with users or
stakeholders, is there any kind of GUI or the voice-based system will be there.
There will be a beautiful GUI provided to the system which is built using XML through
Android SDK and Android Studio. Material design guidelines will be implemented to
design the user interface for the system. The material design keeps stakeholder very
comfortable and easy to interact with the system by providing beautiful colour scheme
and animations.

2.1.3 Hardware Interfaces

Since the mobile application has any designated hardware, it does not have any direct
hardware interfaces. The physical GPS is managed by the GPS application in the
mobile phone and the hardware connection to the database server is managed by the
underlying operating system on the mobile phone. The Accelerometer in the device
which is required by the system is managed in the app to calculate the speed of the
vehicle.
The most important hardware interface for efficient usage of the camera. Most of the
system is dependent on the camera, So the interface is needed which can take the
maximum advantage of the camera to perform functions part one of the system.
The interface will cooperate with followings:
 12

❖ Camera
❖ GPS
❖ Accelerometer sensor
❖ Other sensors
❖ CPU
❖ Speakers

2.1.3 Software Interfaces

The mobile application communicates with the Camera of the device to detect the traffic
sign boards and signals, the GPS application in order to get geographical information
about where the user is located and the visual representation of it, and the
accelerometer sensor to efficiently determined the speed of the vehicle. The last but not
least, system contacts with the database to store data in it.

2.1.3 Communication Interfaces

The communication between the different parts of the system is not much important since they
least depend on each other. However, in what way the communication is achieved is not
important for the system and is therefore handled by the underlying operating systems for the
mobile application.

2.2 Functional requirements

This section includes the requirements that specify all the fundamental actions of the
software system.
2.2.1.1 Functional requirement 1.1

TITLE: Enter in the system without registration

INPUT: App should be installed on the device and the stakeholder can skip the registration to
enter the app.
PROCESSING: Downloading and installing the application.
OUTPUT: System is installed on the mobile now, you have entered the app and ready to use.
ERROR HANDLING: Exception handling need to implement.
 13

2.2.1.2 Functional requirement 1.2

TITLE: User Account Creation

INPUT: The user should be able to register through the mobile application. The user must
provide user-name, password and e-mail address. The user can choose to provide a regularly
used phone number.
PROCESSING: Account creation using provided inputs.
OUTPUT: Account will be created and using can sign in now.
ERROR HANDLING: Exception handling need to implement.

2.2.1.3 Functional requirement 1.3

TITLE: Sign in with Google

INPUT: User able to sign in with already existed google account in the mobile.
PROCESSING: Google API will verify and then sign indirectly.
OUTPUT: User will be signed in without account creation
ERROR HANDLING: Exception handling is needed to implement.
2.2.1.4 Functional requirement 1.4

TITLE: Sign in with Email

INPUT: The user must provide a password and e-mail address.

PROCESSING: Signing the user into the app by validating the provided inputs.
OUTPUT: Signed into the app.
ERROR HANDLING: Validation of email and password.
2.2.1.5 Functional requirement 1.5

TITLE: Open Camera to detect traffic signals

INPUT: User will be able to open the camera with the provided interface.
PROCESSING: The system will detect the traffic signals and signboards through the camera.
OUTPUT: The Required object will be detected through the camera.
ERROR HANDLING: Poor camera quality could cause a problem.
2.2.1.6 Functional requirement 1.6

TITLE: Notify in voice stakeholder on detection of signals.

INPUT: Detection of signals and signs will be used as input for this FR.
PROCESSING: System will analysis the detection and then give instructions to stakeholders
over voice.
OUTPUT: Voice instructions or any other indication
ERROR HANDLING: Availability of resources.
 14

2.2.1.7 Functional requirement 1.7

TITLE: Determine the distance between two places

INPUT: User will give two places.

PROCESSING: The system will determine the distance between two places.
OUTPUT: Distance will be the output.
ERROR HANDLING: Accuracy of lat, long of the places should be verified.

2.2.1.8 Functional requirement 1.8

TITLE: Store the history in DB

INPUT: Data of part 1 will be used as input for this FR.

PROCESSING: The system will be needed to somehow store this data into the DB for later use.
OUTPUT: Data will be stored as output in local DB.
ERROR HANDLING: Exception handling in storing the data should be implemented.

2.2.1.9 Functional requirement 1.9

TITLE: Share the live location

INPUT: Live location of the user will be used for this FR.
PROCESSING: The system will use the location to send it to the other stakeholders or maybe to
the other app.
OUTPUT: In the output, the location will be successfully sent to the required one.
ERROR HANDLING: Poor Internet connection or faulty GPS could cause the problem.

2.2.1.10 Functional requirement 1.10

TITLE: Determine the quantity of traffic flow on the road.

INPUT: Live location of the stakeholders will be used as input for determining the quantity of
flow.
PROCESSING: The google map API will be used to process the determination of traffic flow.
OUTPUT: The quantity of traffic flow will be determined.
ERROR HANDLING: Inaccurate location of the user could cause the problem.
 15

3.2.1.11 Functional requirement 1.11

TITLE: Provide documentation on traffic rules and guidance

INPUT: The system resources will be used to display documentation.

PROCESSING: Loading the data on the screen.
OUTPUT: Documentation will be displayed on the screen.
ERROR HANDLING: Exception handling is needed to implement.

2.3 Use Cases

The user has these user cases:
 16

2.3.1 Use Case (Sign Up)

In this case, the user enters his/her username, name, surname, password, mail address sets a
profile photo. When the user fills all necessary fields, an activation mail will be sent to
users mail address. The user will be able to login and start using the system just after activating
his/her account.
2.3.2 Use Case (Login)
 17

In this case, the user enters his/her username or email and his/her password and logs in the
system.

2.3.3 Use Case (Enter without register)

In this case, the user enters or logs in the System without registering.

2.3.4 Use Case (Traffic Signal detection)

 18

In this case, users will be able to detect traffic signals using the camera of the app.

2.3.5 Use Case(Detect Traffic signboards)

In this case, users will be able to detect traffic sign boards using the camera of the app.

2.3.6 Use Case (Voice Instructions)

In this case, voice instructions are provided to the user when the system detects any signal or
signboards.
 19

2.3.7 Use Case (Determine speed of the vehicle)

This case determines the speed of the vehicle and shows to the user.

2.3.8 Use Case (Determine traffic flow)

This case determines how much traffic is on the road and show to the user.
 20

2.3.9 Use Case (Sharing live location)

This case gets the user’s location and shares it with other apps.

2.3.10 Use Case (Documentation on traffic rules & guidance)

 21

This case gives the user proper documentation on traffic rules and regulations to learn about
traffic rules.

2.4 Non-Functional Requirements

A careful specification and adherence of non-functional requirements such as
performance, security, privacy, and availability are crucial to the success or failure of
any software system. Mobile devices are uniquely constrained in several aspects such
as multitasking support, available network bandwidth, screen real estate etc. These
constraints translate into strict bounds being imposed on the operating characteristics of
an application running on a mobile device.
Mobile applications need to operate successfully (or degrade gracefully) within a wide
spectrum of operating conditions, such as a range of supported screen resolutions and
form factors, network bandwidth situations and network types (2G, 3G, 4G, WiFi) etc.
Mobile applications sometimes need to interact with the device’s sensors such as GPS,
accelerometer, ambient light sensor, camera etc. The application must respect the
sensor’s operating characteristics such as its operating range, sensitivity, accuracy,
minimum polling interval etc.

2.4.1 Performance Requirements

Mobile applications highly dependent upon the performance because if a mobile

application is not beneficial for the stakeholder then no one would like to use that
application. And here comes the performance to play its part in the beneficiary.
In our system, performance is highly dependent upon the quality of camera because
above 70% of the application’s load based on the camera, so the device should have
the best available camera with the wide-angle and latest features should be available in
it. So that system could use the camera to detect the required object within a very short
time to facilitate the user.
The performance of the system also dependent upon the sensors if the device doesn’t
have proper an accelerometer sensor then the system will not be able to measure the
speed of the vehicle. So the device should have the latest accelerometer for high-level
performance.

2.4.2 Reliability Requirements

There are a few requirements which are needed for the system for 100 percent
reliability. These requirements are:
➢ High-speed internet (Wifi or 3/4G).
➢ Latest Android version
➢ Efficient CPU
➢ Long-lasting bigger battery.
 22

➢ Camera with a wide-angle or latest features.

➢ GPS for measuring the current location.
➢ Accelerometer for measuring the speed of the vehicle.

2.4.3 Availability Requirements

The system should have 100% availability of good internet connection, user live
location, good camera, powerhouse CPU and battery else the system will be affected
badly.
2.4.4 Security Requirements

Requirements of security for any software application related to the statement that it should be
secured according to the industry practices. Mobile application must use secure network
protocols so that no data could be leaked or hacked. Just like in our system, stakeholder’s data
in history must be protected from leakage.
2.4.5 Maintainability Requirements

Maintainability is the ease with which faults in a software system can be found and fixed. In the
system, faults could occur due to a slow internet connection or damaged hardware, So the
system can be recovered as soon as the internet connection is boosted or devices are
recovered.

2.5 Logical Database Requirements

In our system Virtual Driver Assistant, we don’t have much complex use of the database.
Because the system will only need to store the history of all the detections of traffic signals and
signboards by taking their snaps.

2.5.1 Entities

An entity is an object in the system that we want to model and store information about.
Entities are usually recognizable concepts, either concrete or abstract, such as a
person, places, things, or events which have relevance to the database.
The system has two entities:
➢ User
➢ Snaps
2.5.2 Attributes

An attribute is an item of information which is stored about an entity. For example, the
entity 'lecturer' could have attributes such as staff id, surname, forename, date of birth,
telephone number, etc.
The VAD system must have the following attributes across entities:
 23

➢ Username
➢ Email address
➢ Photo
➢ Last location
➢ Detect signal or sign snap
➢ Time at snap taken
➢ Location at snap taken.

2.5.2 Tables:

A table is a collection of related data held in a structured format within a database. It consists of
columns and rows.
The VAD system must have the following tables:
➢ User
➢ History

2.5.3 ER Diagram:

2.6 Design Constraints:

This section includes the design constraints on the software caused by the hardware.

2.6.1 Hard drive space:

The hard drive should have a minimum of 100MB space to install and run the application
successfully.
 24

2.6.2 Ram capacity:

The RAM should have a minimum of 1GB to run the application efficiently.

2.6.3 Camera:

The Camera should be above 5mp to capture and detect the required objects.

2.6.4 GPS:

The Mobile device should have a GPS feature to fetch the location of the stakeholder.
2.6.5 Accelerometer:

The Mobile device should have an accelerometer sensor to measure the speed of the vehicle.

2.7 Analysis Model

2.7.1 Data Model:

Data model have already described in the section 3.5 logical database requirements. Check that
section.
 25

2.7.2 Sequence Diagram:

2.7.3 Data Flow Diagram (DFD):

A data flow diagram (DFD) shows how information flows through an information system,
including inputs, outputs, where data is stored, and where it travels.
 26

2.7.3.1 Context flow diagram:

2.7.3.1 DFD Level 0:

 27

2.7.3.1 DFD level 1:

 28

2.7.4 State Transition Diagrams (STD):

Chapter 3. SYSTEM DESIGN AND

ARCHITECTURE
 29

3.1 Architecture Design:

The figure shows the general deployment diagram of the Virtual Driver Assistant
system.

Android Application will be developed as a single Android Client (apk) and it will:
❖ Capture images through camera and process it to identify specific objects.
❖ Voice instructions on object identification.
❖ Calculation of distance between two locations.
❖ Measuring the speed of the vehicle.
❖ Measuring Traffic flow.
❖ Providing Documentation

The camera will be used to capture images and process it to identify objects and maybe
to store them in the local database.
The GPS will calculate the location of stakeholder and store it in the local DB.
The sensors will use measure the speed of the vehicle.
 30

3.2 Decomposition Description:

In this section, the main components of the system are described in terms of the sequence
diagram.

3.2.1 Register Component:

3.2.2 Login Component:

 31

3.2.1 VDA Service Component:

 32

3.2.1 Distance Calculation Component:

 33

3.2.1 Speed check Component:

 34

3.2.1 Traffic Rules Component:

3.3 Design Rationale:

I wanted to develop a final year project that should not only be tagged as final year
project but also could be used by everyone who needs it. As we know that there are
above 85% users who use the mobile phone as a tech device as compared to PC or
other devices. And It’s very fascinating that above 90% of users are Android users.
Therefore, I decided to select Android as a platform for my final year project.
In the market, approximately 80% smart mobiles are Android in the mobile phone
market.
We use the following approaches and technologies for design and other prospective:
➢ XML for designing
➢ JAVA for backend (Android SDK)
➢ Firebase for cloud storage
 35

➢ Google Maps API

➢ SQLite for local database
➢ OpenCV or Firebase ML Kit(Image processing).

3.4 Data Description:

3.4.1 Data Objects:

User:

id:
Identity number is given from the database for each user. This attribute is unique for any
user. It also will be the primary key.
name:
The first and last name of the user.
username:
The title of stakeholder’s account.
password:
The password that stakeholder uses on the time of account creation.
email:
This is optional if the user wants to register the account using an email address.
photo:
The photo that the user will be uploaded during account creation.
description:
A brief description where the user mentions about his/herself

Snaps:

id:
Identity number is given from the database for each user. This attribute is unique for any
id. It also will be the primary key.

time:
The date and time at which snap are taken.
photo:
The photo that is taken for processing.
location:
The location where the photo was taken.
 36

3.4.2 Relationships and Complete Data Model:

3.4.3 Data Dictionary:

Alphabetically list the system entities or major data along with their types.

User:
Parameter Parameter Type

id int

username String

name String

password String

photo bytes
 37

Snaps:
Parameter Parameter Type

id int

time String

photo bytes

3.5 Component Design:

The component design diagram of Virtual Driver Assistant is given below:

There are few major components in this system:

➢ VDA Dashboard.
➢ VDA Services
➢ Speed Calculation.
➢ Distance Calculation.
➢ Traffic Rules & Guide.
 38

Chapter 4. IMPLEMENTATION & TESTING

4.1 Overview of the User Interface:

The user will be prompted with the login screen when the application starts. Once the
user logs into the application successfully, the profile page of the user will be prompted
to him/her according to the user type. For the users who have not registered yet or don’t
want to register, there will be an option for skipping the registration process to enter the
 39

app directly. By using this application, users can open the camera. The camera will
keep the user alert through voice if any object it identifies.

4.2 Development Tools:

Virtual Driver Assistant Application has been built using Android studio IDE. Android SDK is
being used for development of Android apps in Android Studio. Java has been used as backend
language while XML as frontend language. Google maps have been used for location tracking
and distance measuring. Aside for this Firebase APIs have been used for cloud storage and
artificial intelligence.

4.3 Coding Modules:

4.3.1 Animations:
 40

4.3.2 Setup Firebase:

4.3.3 Sign In with Google:

 41

4.3.4 Phone Number Authentication:

4.3.5 Image Prediction:

 42

4.3.6 Speedometer:

4.3.7 Measure Distance:

 43

4.3.8 Fetch Location:

4.3.9 Share Location :

 44

4.3.11 Upload Image:

4.3.12 Store and retrieve data from Sharedpreferences:

 45

4.3.13 Setting the Camera API 2:

4.3.14 Sign out:

 46

4.4 Screen Images:

4.4.1 Sign in screen:
 47

4.4.2 Sign with google:

 48

4.4.3 Phone Authentication:

 49

4.4.4 Dashboard:

4.4.5 Prediction screen:

 50

4.4.6 Speedometer:

4.4.7 Measure distance:

51
 52

4.4.8 Share location:

 53

4.4.9 Guide Book:

 54

4.4.10 Profile:

4.5 Testing:

4.5.1 Sign in

S. Test Case  Expected Result Test Result

No
 55

1 Enter valid mobile number and click on Dashboard will be opened Successful
sign up button (Internet connected)

2 Enter valid mobile number or click on sign Sign in will not be Successful
in with google (Internet disconnected) proceeded.

3 Enter invalid mobile number (Internet It will show toast of Successful

connected) application defined error
and fields error

4.5.2 Prediction

S. Test Case  Expected Result Test Result

No

1 Process each frame Give prediction of traffic Successful

signal lights

2 Pick image from gallery Give prediction of traffic Successful

signal lights

4.5.2 Speedometer

S. Test Case  Expected Result Test Result

No

1 Fetch real time location from GPS Show real time speed Successful
 56

2 Couldn’t fetch the location from GPS Show speed 0KM/hr Successful

4.5.4 Distance

S. Test Case  Expected Result Test Result

No

1 Calculate distance b/w two points Show real time distance Successful

2 Couldn’t fetch the location from points Will not show distance Successful

4.5.5 Share location

S. Test Case  Expected Result Test Result

No

1 Fetch real time location from GPS and Toast of “delivered” will be Successful
SMS it to given valid number shown
 57

2 Couldn’t fetch the location or number is Will not send sms or send Successful
invalid it with null msg

4.5.5 Profile

S. Test Case  Expected Result Test Result

No

1 Upload image from gallery Image will be displayed Successful

and stored locally

2 Update name Name will be displayed and Successful

stored locally

Chapter 5. Future Work

5.1 Lesson Learned:

At the end of the project, we have learned many things and we are probably smarter
than when the project started. We have experienced issues, probably several that were
complete surprises, and we hopefully worked our way around them. We have learned
some things simply by performing the project management practices throughout the
project and watching life-cycle processes play out. Our goal has been being able to
operate more effectively and more efficiently on future projects and to also being able to
share our experiences with our PM colleagues so that they may use this information
wisely as well. After all, why would anyone want to repeat the same mistakes former
seniors made?
 58

The lessons learned document contains information about all the project life-cycle
processes but most important the Executing and Controlling processes. These two
processes are when work of the project performed and when you will likely find
mistakes that were made in the planning document or processes. Anything you discover
that could have been clearer or any additional information that would have helped to
avoid confusion should be noted here. Process improvements, communication glitches,
or any other information that will you perform the next project better should be noted
here.

5.2 Prediction Module:

Currently, we are using Firebase Machine learning kit for image processing. The Application is
working well for processing the still images. But the problem arises once we start processing the
each frame. Each frame takes 105ms to complete processing. That means we can only process
less than 5 images in a second while when we run the app in real time, It takes more than 1
second to process each frame. So we can not process each frame due to high latency or
processing rate. This is the problem that we are facing while detecting the objects in real time.
So, In the near future, we may find some more efficient artificial intelligence library or tool for
faster process of an image. Or we can work with core machine learning algorithms or deep
learning algorithms for this purpose.
Aside from this, we can add more objects for recognition and prediction. we can apply our
algorithms on different sign boards and provide valuable information to the user. For example, a
sign board which tells about speed limit of moving bus on the road, suddenly pass through the
camera, our app will detect it and try to understand its meaning. After understanding the entire
sign board, app will tell the user that you should keep the speed of vehicle under that limit.

5.3 Speedometer Module:

We can bring improvements in speedometer by measuring the speed of vehicle with more
accuracy in no time. Same as it is, we can use different approaches to achieve this goal. For
example, currently we are using real time location lats and longs to calculate speed. Instead of
this, we may use accelerometer of mobile device or anything else to calculate the speed. In
future, we can do research on this point for the sake of reliability.

5.4 General overview:

As we know that this app has been a research based project, we can extend the
research work to bring improvements in many aspects. We can use better algorithms for
detection or recognization of objects. Even we can make better speedometer by looking
at other more advanced options such as use of accelerometer or any other technique to
calculate the speed of vehicle.
 59

Chapter 6. Supporting Information

7.1 Appendix A-Background Research on:

★ SDD IEEE format,rules and guidelines including IEEE 1016-2009.
★ OpenCV
★ Image Processing on Android
★ OpenCV implementation on Android.
★ Software engineering guidelines for app development.
★ Project management Practices
★ Google Cloud APIs
 60

★ Location APIs
★ GPS and Fused location API
★ Camera API
★ Camera API 2
★ Custom Camera Frame processing APIs
★ Google maps.
★ Sensors, camera angles and their working for IMP.
★ Firebase
★ Firebase ML Kit
★ Tensorflow Lite
★ UI & UX for mobile screens

7.2 Appendix B-Data Dictionary:

Term Definition

VDA Virtual Driver Assistant

VDAS VDA Services

API Application Programming Interface

UI User Interface

UX User Experience

ER Entity Relationship

DD Data Design

AD Architecture Design

DR Design Rationale.

UML Unified Modeling Languages.

ML Machine Learning

AI Artificial Intelligence

lat Latitude
 61

lng Longitude