THE REAPER (Autonomous Home Security Robot)€¦ · Hafiza Samman Sohail Submitted to Faculty of Department of Computer Software Engineering National University of Sciences and Technology,

THE REAPER

(Autonomous Home Security Robot)

By

Muhammad Ameer Hamza Janjua

Mariam

Ajlala Bukhari

Hafiza Samman Sohail

Submitted to Faculty of Department of Computer Software Engineering National

University of Sciences and Technology, Islamabad in partial fulfillment for the

requirements of a B.E Degree in Computer Software Engineering, May 2019

In the name of Allah, the Most Beneficent, the Most Merciful

ABSTRACT

THE REAPER

With each passing year, information technology is becoming more advance and

able to solve complex Human problems. With the advent of emerging

technologies like Artificial intelligence, Machine learning, computer vision,

natural language processing, the world is moving towards undeniable automation.

This automation will make lives of human beings much easier, comfortable and

secure in the near future.

Every person needs security, especially home security and does not want any theft

or robbery to take place. Hence, traditionally, CCTV cameras are used for this

purpose. But these cameras only tell you about any theft or robbery after the

damage has already incurred. There must be ways to avoid theft or inform the

concerned person at the time something like theft is about to happen.

Therefore, we have developed an autonomous robot ‘The Reaper’ which aims to

solve the home security concerns by using cutting edge emerging technologies.

The reaper aims to provide a 24 hour alert security system that specifies an

intruder on spot and alerts the user and the concerned law enforcement agencies

.It uses computer vision technology i.e facial recognition to distinguish between

similar faces and intruders and also tracks the faces. Moreover, it can also

recognize voices and respond to them through natural language processing. It is

further inculcated with the ability to recognize and classify different objects with

99 percent accuracy. Thus, our solution will try to ensure a safer community with

a price tag easily affordable by any middle class individual and it will be an

addition to the innovations and the development of the world.

CERTIFICATE FOR CORRECTNESS AND

APPROVAL

It is certified that work contained in the thesis –THE

REAPER(Autonomous Robot) carried out by Mariam, Ajlala Bukhari,

Hafiza Samman Sohail, and Hamza Janjua under supervision of A/P Sir

Athar Mohsin for partial fulfillment of Degree of Bachelor of Software

Engineering is correct and approved.

Approved By

A/P Athar Mohsin

Department of CSE, MCS

Dated:

4th May 2019

DECLARATION

No portion of the work presented in this dissertation has been submitted in

support of another award or qualification either at this institution or

elsewhere.

i

DEDICATION

To our parents, without whose support and cooperation, a work of this

magnitude would not have been possible. To our supervisor,A/P Athar

Mohsin who has given us great support and valuable suggestions

throughout the implementation process.

ii

ACKNOWLEDGEMENTS

There is no success without the will of ALLAH Almighty. We are

grateful to ALLAH, who has given us guidance, strength and

enabled us to accomplish this task. Whatever we have achieved, we

owe it to Him, in totality. We are also grateful to our parents and

family and well-wishers for their admirable support and their critical

reviews. We would thank our supervisor, Sir Athar Mohsin for his

guidance and motivation throughout the journey of our project.

Without their help, we would have not been able to achieve

anything.

iii

Table of Contents

Chapter 1. Introduction ................................................................................................... 1

1.1 Overview .............................................................................................................. 1

1.2 Problem Statement ............................................................................................... 1

1.3 Approach .............................................................................................................. 1

1.4 Scope .................................................................................................................... 2

1.5 Objectives ............................................................................................................. 2

1.6 Deliverables .......................................................................................................... 3

1.7 Overview of the Document .................................................................................. 4

1.8 Document Conventions ........................................................................................ 4

1.9 Intended Audience................................................................................................ 5

Chapter 2. Literature Review .......................................................................................... 6

1. Using image processing ........................................................................................... 6

2. Using haar cascade ................................................................................................... 6

2.1 Face detection using image processing ..................................................................... 7

2.2 Face tracking ............................................................................................................. 7

Chapter 3. Software Req. Specification .......................................................................... 8

3.1. Introduction .............................................................................................................. 8

3.1.1. Purpose .................................................................................................................. 8

3.2. Overall Description .................................................................................................. 8

3.2.1. Product Perspective ........................................................................................... 8

3.2.2. Product Features: ............................................................................................... 9

3.2.3. User Classes and Characteristics ....................................................................... 9

3.2.3.1 End User (regular User) ................................................................................... 9

End user will interact with the Reaper ......................................................................... 9

3.2.3.2 Developer (occasional user) ............................................................................ 9

3.2.4. Operating environment .................................................................................... 10

3.2.5. Design and Implementation Constraints.......................................................... 11

iv

Hardware Constraints ................................................................................................ 11

Software Constraints.................................................................................................. 11

3.2.6. User Documentation ........................................................................................ 11

3.2.7. Assumptions and Dependencies ...................................................................... 11

3.3. External Interfaces Requirements .......................................................................... 12

3.3.1. User Interfaces ................................................................................................. 12

3.3.2. Hardware Interfaces ......................................................................................... 12

3.3.3. Software Interfaces .......................................................................................... 13

3.3.4. Communications Interfaces ............................................................................. 13

3.4. System Features...................................................................................................... 14

3.4.1. Face detection .................................................................................................. 14

3.4.2 Face Recognition and Tracking ........................................................................ 14

3.4.3 Voice Recognition ............................................................................................ 15

3.4.4 Wifi module and GSM module ........................................................................ 16

3.4.5 Object detection ................................................................................................ 17

3.4.6 GUI (Desktop Application) .............................................................................. 17

3.5. Other Nonfunctional Requirements ....................................................................... 18

3.5.1. Safety Requirements ........................................................................................ 18

3.5.2. Security Requirements ..................................................................................... 18

3.5.3. Performance Requirement ............................................................................... 18

3.5.4. Cross platform Requirement ............................................................................ 18

3.5.5. Software Quality Attributes ............................................................................. 19

Chapter 4. Design and Development ............................................................................. 20

4.1. Introduction ............................................................................................................ 20

4.2. Purpose ................................................................................................................... 20

4.3. Project Scope .......................................................................................................... 20

4.4. System Architecture Description ........................................................................... 21

4.4.1. Overview of modules ....................................................................................... 21

4.5. Structure and Relationships .................................................................................... 22

4.5.1 Block Diagram .................................................................................................. 22

4.5.2 Dataflow diagram (level 1) ............................................................................... 23

v

4.5.3 Use case Diagram ............................................................................................. 23

4.5.4 Sequence Diagrams .......................................................................................... 34

4.5.5 Activity Diagram .............................................................................................. 36

4.5.5 State Transition Diagram .................................................................................. 37

4.5.5 Class Diagram................................................................................................... 38

4.6 Detailed Description of components ....................................................................... 39

4.6.1 Input Hardware: ................................................................................................ 39

4.6.2 Application ....................................................................................................... 41

4.6.3 Subsystem ......................................................................................................... 43

4.6.4 Database............................................................................................................ 44

4.6.5 Output hardware (Servos, Speakers) ................................................................ 46

4.7. Reuse and Relationships to other Products ............................................................ 47

4.8. Design Decisions and Tradeoffs ............................................................................ 48

Chapter 5. Project Test and Evaluation ....................................................................... 51

5.1. Introduction ............................................................................................................ 51

5.2. Test Items ............................................................................................................... 52

5.3. Features to Be Tested ............................................................................................. 52

5.4. Test Approach ........................................................................................................ 53

5.5. Item Pass/Fail Criteria ............................................................................................ 54

5.6. Suspension Criteria and Resumption Requirements .............................................. 54

5.7. Test Deliverables .................................................................................................... 55

5.7.1. Acquire Video.................................................................................................. 55

5.7.2 Face detection ................................................................................................... 56

5.7.3. Face Recognition ............................................................................................. 58

5.7.4. Intruder Detection ....................................................................................... 59

5.7.5 Face Tracking ................................................................................................... 60

5.7.6. Notifications .................................................................................................... 62

5.7.7 Voice Recognition ............................................................................................ 63

5.7.8 Response Generation ........................................................................................ 64

5.7.9 Admin Login..................................................................................................... 65

5.7.10 Edit Dataset..................................................................................................... 66

vi

5.7.11 Live Video ...................................................................................................... 67

5.7.12. Object Detection ............................................................................................ 69

5.7.13. Hardware Integration ..................................................................................... 70

5.7.14. System Integration ......................................................................................... 72

5.8. Responsibilities, Staffing and Training Needs ....................................................... 73

5.8.1. Responsibilities:............................................................................................... 73

5.8.1. Staffing and Training needs ............................................................................. 74

5.9. Environmental Needs ............................................................................................. 74

5.10. Risk and Contingencies ........................................................................................ 75

5.10.1. Schedule Risk: ............................................................................................... 75

5.10.2. Operational Risks: ......................................................................................... 75

5.10.3. Technical risks: .............................................................................................. 75

5.10.4 Programmatic Risks ........................................................................................ 75

Chapter 6. Future Work................................................................................................. 76

Chapter 7. Conclusion .................................................................................................. 76

7.1 Objectives achieved................................................................................................. 76

APPENDIX A .............................................................................................................. 78

Glossary ..................................................................................................................... 79

APPENDIX B ............................................................................................................... 80

USER MANUAL .......................................................................................................... 80

Chapter 8 GENERAL INFORMATION ................................................................... 81

Chapter 9 SYSTEM SUMMARY ............................................................................. 82

Getting Started ........................................................................................................... 82

Chapter 11 GETTING STARTED ............................................................................ 82

Chapter 12 USING THE SYSTEM ........................................................................... 83

Bibliography .................................................................................................................... 85

vii

List of Figures

Figure 3- 1 user interface .................................................................................................. 12

Figure 3- 2 Arduino minimega ......................................................................................... 13

Figure 3- 3 Servos ............................................................................................................. 13

Figure 4- 1 System Component Diagram ......................................................................... 21

Figure 4- 2 Block Diagram ............................................................................................... 22

Figure 4- 3 Dataflow Diagram .......................................................................................... 23

Figure 4- 4 Use case Diagram ........................................................................................... 24

Figure 4- 5 Voice Recognition Sequence Diagram .......................................................... 34

Figure 4- 6 System Sequence Diagram ............................................................................. 35

Figure 4- 7 Desktop application Sequence Diagram ........................................................ 36

Figure 4- 8 Activity Diagram ............................................................................................ 36

Figure 4- 9 State Transition Diagram ............................................................................... 37

Figure 4- 10 Class Diagram .............................................................................................. 38

Figure 4- 11 Design Pattern .............................................................................................. 49

viii

Figure 5- 1 Face detection................................................................................................. 57

Figure 5- 2 Face recognition ............................................................................................. 59

Figure 5- 3 Intruder detection ........................................................................................... 60

Figure 5- 4 Notifications ................................................................................................... 63

Figure 5- 5 Live Video ...................................................................................................... 68

Figure 5- 6 Object Detection............................................................................................. 70

Figure 5- 7 Hardware Integration ..................................................................................... 71

Figure 5- 8 System Integration ......................................................................................... 73

ix

List of Tables

Table 1- 1 Deliverables .................................................................................................................... 4

Table 4- 1 UseCase 1 ..................................................................................................................... 26

Table 4- 2 UseCase 2 ..................................................................................................................... 26

Table 4- 3 UseCase 3 ..................................................................................................................... 27

Table 4- 4 UseCase 4 ..................................................................................................................... 28

Table 4- 5 UseCase 5 ..................................................................................................................... 29

Table 4- 6 UseCase 6 ..................................................................................................................... 29

Table 4- 7 UseCase 7 ..................................................................................................................... 30

Table 4- 8 UseCase 8 ..................................................................................................................... 31

Table 4- 9 UseCase 9 ..................................................................................................................... 31

Table 4- 10 UseCase 10 ................................................................................................................. 32

Table 4- 11 UseCase 11 ................................................................................................................. 32

Table 4- 12 UseCase 12 ................................................................................................................. 33

Table 4- 13 UseCase 13 ................................................................................................................. 33

Table 4- 14 Description of Classes ................................................................................................ 38

x

Table 4- 15 Input Hardware ........................................................................................................... 39

Table 4- 16 Application ................................................................................................................. 41

Table 4- 17 Subsystem ................................................................................................................... 43

Table 4- 18 Database ..................................................................................................................... 44

Table 4- 19 Output Hardware ........................................................................................................ 46

Table 5- 1 TestCase 1 .................................................................................................................... 56

Table 5- 2 TestCase 2 .................................................................................................................... 57

Table 5- 3 TestCase 3 .................................................................................................................... 59

Table 5- 4 TestCase 4 .................................................................................................................... 60

Table 5- 5 TestCase 5 .................................................................................................................... 62

Table 5- 6 TestCase 6 .................................................................................................................... 63

Table 5- 7 TestCase 7 .................................................................................................................... 64

Table 5- 8 TestCase 8 .................................................................................................................... 65

Table 5- 9 TestCase 9 .................................................................................................................... 66

Table 5- 10 TestCase 10 ................................................................................................................ 67

Table 5- 11 TestCase 11 ................................................................................................................ 68

Table 5- 12 TestCase 12 ................................................................................................................ 69

xi

Table 5- 13 TestCase 13 ................................................................................................................ 71

Table 5- 14 TestCase 14 ................................................................................................................ 73

The Reaper

1

Chapter 1. Introduction

1.1 Overview

Humans have innate ability to recognize and distinguish between faces, and

thanks to modern science, computers and robots have proven capable of this

same ability, as well. We can inculcate the vision ability of Human beings in

Robots which can be useful for many purposes, and in our project we are

creating this ability in a robot for home security purpose specifically .We

present a surveillance robot which can secure our places/homes through facial

recognition and it will also be a kind of social robot which can recognize

voices and respond along with many other features and capabilities.

1.2 Problem Statement

Everybody wants a protected world in which one’s office, home, parents,

children, material possessions are being secured and protected from the caution

of theft and robbery. According to Pakistan bureau of statistics over 64874

cases of theft and robberies have been reported in 2017, and these are the ones

that actually got reported. Traditionally, CCTV cameras and security guards

are being used for security proposes. But the real problem is that no

technological solution for home security exists except CCTV cameras and

security guards .CCTV cameras only show proof of the theft after it has

occurred. Therefore, a better solution from this security problem needs to be

implemented.

1.3 Approach

The project involves implementation of an autonomous robot, which will

detect and recognize faces, detect intruders, notify authority, along with

The Reaper

2

features such as object detection, voice recognition and speech. The reaper

aims to provide a 24 hour alert security system that specifies an intruder on

spot and alerts the user and the concerned law enforcement agencies .Thus our

product will also help the common man who wants to secure his household by

providing a new and effective home security system

1.4 Scope

The REAPER will be an autonomous robot for facial detection, tracking

facial recognition and voice recognition along with other features and will be

used for home security purposes and in places where guards are not permitted

.Along with that ,it can also act as a social robot.

Hence it will be a kind of providing security as well as interaction with

humans. Our project will use cutting-edge technologies such as Artificial

intelligence, Computer Vision, Kinematics, and digital image processing.

For Home security and other places and also where guards are not

permitted

What An autonomous robot for tracking purposes by detecting and

recognizing human faces.

The Reaper (autonomous robot)

Is Also Controlled by a desktop application.

That Detects and recognizes faces and objects autonomously and takes

voice commands and responds to it with speech or movement.

1.5 Objectives

The foremost and most important objective of this system is to provide home

security in the best possible way by replacing CCTV cameras and to notify the

concerned person(s) thus providing more efficient, productive, and less costly

home security than CCTV cameras and security guards. Other sub-objectives

The Reaper

3

of this system include bridging the communication gap between humans and

robots, through features of our system such as voice recognition, object

recognition and speech.

During the course of this project, all the aspects of software engineering are

covered i.e. survey and feasibility analysis, requirement gathering, architectural

and detailed design, implementation and testing along with documentation

(SRS, SDS, Test Document, Final Report and User manual).

Students are also expected to develop extensive knowledge and technical

skills in the following fields:

1. Artificial Intelligence. 2. Computer Vision. 3. Image processing. 4. Python programming.

5. Kinemetics and Control theory

1.6 Deliverables

Sr Tasks Deliverables

.

1 Literature Review Literature Survey

2 Requirements Software Requirements Specification document Specification (SRS)

3 Detailed Design Software Design Specification document (SDS)

4 Implementation Project demonstration

5 Testing Evaluation plan and test document

The Reaper

4

6 Training Deployment plan

7 Deployment Complete application with necessary documentation

Table 1- 1 Deliverables

1.7 Overview of the Document

This document shows the complete working process of our system “THE

REAPER”. It starts off with the literature review which shows past work done

in similar field, requirement analysis of the system, system architecture which

highlights the modules of the software and shows the various components of

the system through component diagram, Use Cases, Sequence of the system

and general design of the system. Then it will move on to discuss the detailed

Description of all the components involved. Further the dependencies of the

system and its relationship with other products and the capacity of it to be

reused will be discussed. At the end test cases and any future work proposal

has been presented.

1.8 Document Conventions

1. Heading are prioritized in a numbered fashion, the highest priority

heading having a single digit and subsequent headings having more

numbers, according to their level.

2. Font used in text is Times New Roman.

3. All the main headings are of size 18 and bold.

4. All the second level sub-headings are of size 16 and bold.

5. All the further sub-headings are of size 14 and bold.

6. All references in this document are provided where necessary,

however where not present, the meaning is self-explanatory.

7. All figures in this document are numbered. Context and flow diagrams

are based UML standards.

The Reaper

5

8. All ambiguous terms have been clarified in the glossary at the end of

this document

1.9 Intended Audience

The intended audiences for “The Reaper” include the project supervisor, the

BESE 21 FYP group (developers), UG project evaluation team, and other

persons at MCS CSE Department.

1. Developers: (Project Group)

To ensure that they are developing the system according to its required

requirements and specifications.

2. Test Persons: (Project Group, Supervisor)

To check the features and functions of the project against its

aforementioned requirements.

3. Users:

To use the system and pinpoint any loopholes in it as well as to

use/respond in failure situations and mention new features that can

further enhance the capability of the project.

4. Document writers: (Project Group)

To get to know about the various requirements of the system and its

design features. Which technologies will be used in the system and

what failures and bugs can happen while its testing and functioning.

5. Project Supervisor: (Sir Athar Mohsin)

This document will be used by the project supervisor to check whether

all the requirements have been understood and in the end whether the

requirements have been implemented properly and completely.

6. Project Evaluators: (CSE Dept. MCS)In order to know the

scope of the project and evaluate the project throughout the

development for grading

The Reaper

6

Chapter 2. Literature Review

No such project related to our autonomous robot has been made previously

in military college of signals, NUST.

Due to rapid development of robot technology, People learn about serve

robot. In future an intelligent robot industries is considered to be the most

emerging and powerful industries. As the internet is used widely the internet

communication and online chatting becomes a part of daily life activities.

In recent years a lot of research has been made on face recognition and face

tracking. This technology is been used in many fields like Judicial Expertise,

Access Control, Human-computer and so on. Human face detection is a part

of human face recognition. Many kinds of algorithm are been used for this

purpose. Instant message Robot detects face through human skin detection

and Adaboost face detection algorithm which is a feature of Haar algorithm

that will be described further.

The key element of human robot interaction is the ability to recognize

human faces. A robot can learn faces and recognize them in real-time and in

realistic environment.it will learn a face based on a single frame. That frame

contain specific features of human face that will help him to recognize a

face in different environments.it can recognize a human face with a

preprocessing step to reduce effect of different illumination conditions, and

then identify 3 regions in human face i.e. left eye of face, right eye of face,

nose and a mouth.it will discard faces and consider them as intruders who’s

face are not matched with preexisting data set.

Two basic techniques commonly used for face detection are:

1. Using image processing

2. Using haar cascade

The Reaper

7

2.1 Face detection using image processing

A web came is used to obtain a video input stream or any other live video.

Video is divided into frames and then processed. Each frame will examine a

face.a bounding box is drawn around face once it is spotted. The coordinates

of box of frame is obtained.

MATLAB is used to execute first stage. MATLAB is a multi-archetype

numerical computing programming language that uses Viola Jones

algorithm for face detection. The coordinates which are obtained after

detecting face are send to arduino microcontroller.

Viola Jones algorithm is used for object detection that focuses on faces in an

image or a video. It is operative only on frontal faces.

2.2 Face tracking

Arduino microcontroller is used for tracing of face .Arduino is an open

source platform with both hardware and software applications.

Two servos are connected to microcontroller. The servos are centered before

tracking begins. The coordinated of face that are obtain by box around face

is used to track face the servos are moved and tilted for face tracking. The

webcam position changes as the person moves left or right and position of

webcam is changed by servos. The servos can rotate from 0 degree to 180

degree.

The drawback of Viola Jones algorithm is that it restricts the operation to

frontal faces only whereas KLT algorithm is used for continuously tracking

human faces in the live video stream.

Object detection in our project has been done using “coco” model

which is a classifier.

Voice recognition is done through “Natural language processing”.

https://ieeexplore.ieee.org/mediastore_new/IEEE/content/media/8241508/8256532/8256558/8256558-fig-2-source-large.gif




The Reaper

8

Chapter 3. Software Req. Specification

3.1. Introduction

The introduction of the Software Requirements Specification (SRS) provides

an overview of the entire SRS with purpose, scope, definitions, acronyms,

abbreviations, references and overview of the SRS. The aim of this document

is to present detailed description of the project “The Reaper” which uses

image processing techniques to detect diseases in crops reducing human

effort.

3.1.1. Purpose

This document covers software requirement specifications for project “The

Reaper”. This document explains the software requirements for “The Reaper

(autonomous system)”. This SRS specifies the detailed requirements and

features of The reaper is a robot which detects and identifies faces

autonomously and tracks them, respond to voice commands and act as a

domestic security system. This document explains system’s requirements,

and the constraints under which it must function and how the system will

respond to external stimuli. The system will further be designed on the basis

of its requirements which are gathered with the help of this document.

3.2. Overall Description

3.2.1. Product Perspective

The coming era is the era of Artificial intelligence and robotics. Currently a

lot of work and research is being implemented on building robots and making

them behave more human like. There are currently plenty of AI based human

like robots being created and studied worldwide. The reaper is another

The Reaper

9

contribution to the vast development of autonomous robots worldwide thus

increasing the innovation in the world using cutting-edge technologies.

3.2.2. Product Features:

The important features of our autonomous robot “The reaper” are given

below.

1. Audio input via microphone

2. Audio processing (Natural language processing)

3. Video input via camera unit

4. Image recognition and processing

5. Face Tracking

6. Ultra sonic sensor for distance measurement

7. Face recognition via data sets

8. Object detection using AI algorithms

9. Notifications through GSM module

10. Desktop application (GUI) features i.e admin edit/view dataset and live

video

11. Response generation using google assistant and servo movement

12. Real time implementation of neural networks and other algorithms

3.2.3. User Classes and Characteristics

3.2.3.1 End User (regular User)

End user will interact with the Reaper

3.2.3.2 Developer (occasional user)

Developer will use The Reaper to make amendments to the robot when

necassary

The Reaper

10

3.2.3.4 Developers

The developers will use this at the developing time and at the time of any

defect occurred in the product during maintenance.

3.2.3.5 Documentation Writers

The document can serve as a future reference for other versions of the SRS.

3.2.4. Operating environment

The system is made up of both hardware as well as software. Therefore,

it needs both to operate and these operating environments are

mentioned below:

Hardware

1. Acrylic parts

2. Arduino mini mega and Raspberry pi

3. Camera

4. Servos

5. Ultrasonic soundwaves sensor

6. GSM

7. Gtech Voice module

8. Microphone and joysticks

Software

1. Pycharm

2. Python 3 , PyQt

3. Anaconda

4. OpenCV

The Reaper

11

3.2.5. Design and Implementation Constraints

Hardware Constraints

1. Servos move 180 degrees

2. Reaper movement constricted by wiring

3. Camera works with lower FPS (15) on higher resolution of 1280x960 and

higher FPS (30) on resolution lower than 1280x720

4. Ultra sonic sound sensor has a range of 2-400cm with accuracy of 3mm

Software Constraints

1. Limited functionality without internet

2. The Reaper will face minor problems if a number of faces appear at a time

3. Various speech patterns and accents will effect communication

3.2.6. User Documentation

Although The Reaper is a fairly simple human like concept for regular users,

but for better understandability for research and professional users written help

can be provided on demand. We will facilitate with the help of a manual to the

users in which separate instructions will be given according to the particular

user. It will include the details of the software working as well as the

integration and working of separate parts.

3.2.7. Assumptions and Dependencies

1. Reaper will recognize faces when identified

2. Reaper will understand basic human speech in English.

3. The movement will be free of glitches and as smooth as possible

4. Responses will be life like and relevant

5. There will be a dependency on the internet for more relevant responses

The Reaper

12

6. Dependency of sending notifications upon GSM module

7. Night Vision affecting camera’s output

3.3. External Interfaces Requirements

3.3.1. User Interfaces

1. An executable python application which will encode users and friendly

faces and save them in the trained data set.

2. A simple GUI interface may be needed that shows the camera feed/input

that is sensed by the robot’s camera and also for monitoring

3. Arduino programming for hardware control and movement

Figure 3- 1 user interface

3.3.2. Hardware Interfaces

1. Arduino IDE is being used to program the hardware of the system

including the servos, sensors, microcontrollers and camera unit

2. Servos must be of the capability to move hardware effectively and in the

right direction

3. Joysticks for manual control /movement of the robot

The Reaper

13

Hardware interfaces mentioned in the text are shown below respectively.

Figure 3- 2 Arduino minimega

Figure 3- 3 Servos

3.3.3. Software Interfaces

1. Windows OS for processing of code

2. Directory traversal in python

3. OpenCV, Python 3.6, Processing IDE, for face detection and recognition

3.3.4. Communications Interfaces

1. Serial Port communication occurs between robot, its camera and other

sensors and the laptop/computer

The Reaper

14

2. GSM module for notification

3. ESP 8266 Wi-Fi network connection through Arduino

3.4. System Features

The System features that we are writing here will describe the capabilities of our

product or the functionalities it will provide as a whole.

3.4.1. Face detection

3.4.1.1 Description and priority

This feature enables the camera unit in the robot to detect that there is a person

or a face in front of it. This feature has high priority as without this nothing will

be detected and no further actions will take place.

3.4.1.2 Stimulus/Response Sequence

Camera feed will go to computer through serial communication and through the

applied algorithms and facial features acquired by camera input.it will be

successfully detected that there is a face in front of camera .

Alternate Data Flow

The camera is unable to detect faces correctly

3.4.1.3 Functional Requirements

REQ-1 The robot’s camera shall correctly detect faces according to facial feature

3.4.2 Face Recognition and Tracking

3.4.2.1 Description and priority

This feature holds a very high priority since it is a core feature of this product

3.4.2.2 Stimulus/Response Sequence

Basic Data Flow

The Reaper

15

After successfully detecting face, the system will recognize the person’s face

with the help of pre-defined datasets and it will also track the distance of

person’s face from its camera and its motion in other directions.

Alternate Data Flow

1. The robot is unable to recognize faces because of their absence in the

data-set.

2. The system is unable to track the location of face and move accordingly


REQ-1 The robot will correctly recognize faces from the data-set.

REQ-2 It system’s camera shall correctly identify the distance of person’s face

from it and track it in the right direction

3.4.3 Voice Recognition

3.4.3.1 Description and Priority

Voice recognition enables the robot to recognize voice of a specific

person(authorized) to which it is trained. It has high priority.

3.4.3.2 Stimulus/Response Sequences

Basic Data Flow

1. Robot recognizes voice and takes commands and takes actions according

to those commands.

2. It may respond to the voice commands when needed

3. It may respond by voice recognition through natural language processing

or through google assistant

The Reaper

16

Alternate Data Flow

1. Robot’s microphone is not able to send voice signals

2. Voice is not correctly recognized or actions are not taken accordingly

after voice recognition.

3. Questions are not correctly answered or movements are not correctly made

according to the command given

Functional Requirements

REQ-1 the reaper shall transmit all the voice signals correctly to computer

through serial port communication and after Natural language processing it

should be able to deliver output correctly.

REQ-2The system shall correctly take actions after voice recognition

3.4.4 Wifi module and GSM module


These feature enables the robot to connect with a Wi-Fi connection and also

with GSM module.


Basic Data Flow

1. Robot successfully connects to Wi-Fi after the network connection is

configured to it.

2. Robot notifies through the GSM module

Alternate Data Flow

The modules are not configured correctly and unable to function properly


The Reaper

17

REQ-1 The system’s network connection must be configured through the

Arduino IDE

REQ-2 The system shall notify through GSM module upon the detection of

an unrecognized face

3.4.5 Object detection


With the help of object detection the robot can classify different objects and label

them


Basic Data Flow

Objects are classified by the object detection algorithm e.g. Chair and bottle are

detected and classified for this test case

Alternate Data Flow

Object recognized incorrectly


REQ-1 Object detection algorithm must work and classify different objects

REQ-2 Dataset for different objects must be available so that classification of

different objects can be made without any error

3.4.6 GUI (Desktop Application)


Admin can login, view dataset, edit dataset, encode and decode faces as well as

view live video.


The Reaper

18

Basic Data Flow

1. Admin can successfully login

2. Admin can view, edit data set.

3. Admin can encode decode faces

Alternate Data Flow

Username/password is incorrect and admin is unable to login and perform any

further operations


REQ-1 Correct username and password must be provided

REQ-2 Camera shall be working properly so that admin can view live video

REQ-3 Dataset must be available

3.5. Other Nonfunctional Requirements

3.5.1. Safety Requirements

1. This application must not take longer than 4 sec to response.

2. In case of data loss, system will back up the data and will restore it as per

demand.

3.5.2. Security Requirements

1. The system shall allow only authorized members to do administrator’s

task.

2. The system will encode image and save them in data set

3. The system will take information from environment and act as learning

base agent

3.5.3. Performance Requirement

Application shall run on 400 MB of memory and take up a 100 MB of disk space

3.5.4. Cross platform Requirement

The Reaper

19

The system will run on Microsoft Windows, Linux, and MacOS.

3.5.5. Software Quality Attributes

Usability

The system will work through voice commands after configuration

Reliability

Application shall not fail in retrieving information .the success rate of information

Retrieval must be 90%. That is 90% attempts of retrieving information must

succeed.

Availability

System must be available when required by the user. Failure rate for availability is

bearable up to 5%. System down time may not exceed one minute per day.

Database must be available 24/7

https://en.wikipedia.org/wiki/Microsoft_Windows

https://en.wikipedia.org/wiki/Linux

https://en.wikipedia.org/wiki/MacOS

The Reaper

20

Chapter 4. Design and Development

4.1. Introduction

Security is a real issue in Pakistan whether it is of home, office or any other

surveillance place. Traditionally used CCTV cameras and other devices have

many flaws and they are also costly. Therefore we are creating a home security

robot which can curb these issues of security with optimum cost, performance,

autonomy, and efficiency using cutting edge technologies such as Artificial

Intelligence, Computer Vision, and Image Processing. This document aims at

providing enough details about design and development of autonomous robot

4.2. Purpose

Having a solid architecture is very crucial for a system as it would provide a

basic blue print for the design and development of the project and act as the

main foundation of the project. Therefore, this software design specification

(SDS) document created by us will tell us about the design , features and

architecture of THE REAPER. Along with architecture the document contains

different design diagrams and their explanation along with the major

components, processing blocks and modules of the system, which will help the

developers in building and structuring the system accordingly.

4.3. Project Scope

The REAPER will be an autonomous robot for facial detection, tracking, facial

recognition and voice recognition ,speech, object recognition along with other

features and will be used for home security purposes and in places where guards

are not permitted .Along with that ,it can also act as a social robot.

The Reaper

21

4.4. System Architecture Description

A solid architecture is very important for a system and it would provide a basic

blue print for the design and development of the project and act as the main

foundation of the project. Therefore, the various diagrams given in this section

will describe the detailed system design and its architecture through the overview

of system modules, their structure and relationships, user interface.

4.4.1. Overview of modules

The reaper has the following modules:

1. Face detection module

2. Face recognition module

3. Face tracking module

4. Voice recognition module

5. GUI

Figure 4- 1 System Component Diagram

The Reaper

22

4.5. Structure and Relationships

The various technical details of “The Reaper” are covered in this section. The

relationship between hardware and software and their components are also

covered in this section. The structure of a system consists of high level and low

level details, user interfaces, along with its architecture and detailed system

design and all these things are explicitly described and shown through various

diagrams given below in this section

4.5.1 Block Diagram

This diagram exhibits the basic functionality of the components of the system

and how its software and hardware parts work together. These blocks are usually

connected by lines and such lines are known to be representing the relationships

of the blocks,

Figure 4- 2 Block Diagram

The Reaper

23

As shown in the above diagram, the basic functionality of our system starts when

a person comes in front of robot’s camera and its sensors provide camera input to

the system. After that, our robot/system detects that there is a face in front of

camera. Upon Successful face detection, face recognition and tracking occurs

through serial port communication after which arduino gives movement

instructions to servos which then give the output response. Voice recognition can

also occur in response to the voice commands given by authorized user. Admin

can also view the camera input through desktop application and give voice

commands.

4.5.2 Dataflow diagram (level 1)

Figure 4- 3 Dataflow Diagram

4.5.3 Use case Diagram

Use case diagram shows the ways in which user or actor interact with the system.

There can be more than one actor in the system which can use the system and there

can be more than one ways to use a system leading to many use cases.

The Reaper

24

Figure 4- 4 Use case Diagram

The Reaper

25

4.5.3.1 Actors

1. Admin

2. Robot

3. Dataset(Secondary actor)

4.5.3.2 Use Cases

Use cases for system as an actor:

1. Face detection

2. Face Recognition

3. Face Tracking

4. Voice Detection

5. Voice Recognition

6. Response Generation

7. Hardware Movement

8. Sends notification

9. Measures Distance

4.6.3.3 Use cases for admin as an actor

1. Login

2. Views Camera input/Video feed

3. Gives Voice Commands

4. Gets Notifications

5. View dataset

6. Change dataset

The Reaper

26

4.5.3.4 Description of Usecases

Table 4- 1 UseCase 1

UseCase Face detection

Actors Robot

Use case

description

This feature allows the robot to detect a human face when it

comes in robot’s camera view

Normal flow

(i)Person comes in front of robot’s camera.

(ii)Camera gives sensor input to the system.

(iii)After getting input ,robot detects the face

Alternative

flow

Face is not detected properly due to night vision or wrong

algorithm

Or changed features of person

Exception Face not detected due to camera lens issues which may include

dirt and night vision.

Precondition There must be a person in front of camera of robot so that it can

detect it

Post

condition

Face is successfully detected

Includes N/A

Extends N/A


Use case Face Recognition

The Reaper

27

Actors Robot

Use case description

Using this feature the robot will be able to recognize the detected face correctly

Normal flow (i)Robot will extract an image of face from camera input.

(ii)User After that, it will match the image of person with dataset

of previously stored images in the dataset.

(iii)Face recognized successfully

Alternative

flow

Face is not recognized and intruder is detected.

Precondition Face is properly detected because the robot will not be able to

recognize anything without prior detection

Post

condition

Face recognition occurs successfully

Includes Dataset

Extends N/A


Use case Face Tracking

Actors Robot

Use case

description

This feature will allow robot to track a face which is not

Recognized

Normal flow (i)Person’s face is not recognized

(ii)Robot identifies this face as an intruder

(iii)Robot sends alerts/notifications to admin and sends sends

instructions to servos(hardware movement) to move in the

The Reaper

28

direction of face track it

Alternative

flow

Robot is unable to move its hardware in the right direction and

face is not tracked

Precondition Face is not recognized

Post

condition

Face is tracked in the right direction

Includes N/A

Extends N/A


Use case Voice detection

Actors Robot

Use case

description

With the help of this use case , robot will be able to detect a

sound near it.

Normal flow Robot detects a voice through its sensors

Alternative

flow

Robot can’t detect that some voice commands are given to it or

voice

Precondition There must be a voice of a known person which must be

generated

Post

condition

Voice is detected successfully

Includes N/A

Extends N/A

The Reaper

29


Use case Voice Recognition

Actors Robot

Use case

description

robot/system will recognize voice of known users

or authorized person and it will understand voice commands and

respond to

them also

Normal flow (i)voice is detected by microphone

(ii)voice recognition module recognizes voice

(iii)response is generated in response to voice commands if the voice

is

of a known person to Robot

Alternative

flow

Robot can’t recognize voice of unknown persons

Precondition Voice is detected and

Post

condition

Voice is recognized and response is generated

Includes geetech hexadecimal dictionary for voice commands

Extends N/A


Use case Response Generation

Actors Robot

Description

of useCase

the Robot will generate response according to the

the given voice commands ,

Normal flow (i)Admin/known user gives commands

(ii) Robot gives instructions through serial port communication to

The Reaper

30

the

(iii)Hardware/servos to move accordingly

Alternative

flow

Hardware movement is not correct

Precondition There must be some commands/instructions given

Post

condition

servos/hardware move in the right direction

Includes move servos

Extends chat bot


Use case Send notifications

Actors Robot

Use case

description

This use case will allow robot to send notifications to admin in

case of an

intruder or unknown person

Normal flow (i)Face of unknown person/intruder is seen

(ii) Robot activates its GSM module which sends notifications to

the admin (iii) In the form of SMS alert

Alternative

flow

Notifications were unable to send ,GSM module was not activated

Precondition intruder/unknown person is seen

Post

condition

SMS alerts are sent through GSM module

Includes GSM

module/SMS

The Reaper

31

alert

Extends N/A


Use case Measure Distance

Actors Robot

Use case

description

Using this use case the robot can measure the distance between

itself and

person’s face and this is mainly used for face tracking

Normal flow (i)Person comes in front of robot’s camera

(ii) Robot measure distance using ultrasonic sound sensor

Alternative

flow

Sensor measures wrong distance ,face tracking doesn’t occur

properly

Precondition person must be in the region near to robot

Post

condition

correct face tracking and distance measurement

Includes Ultrasonic sound

sensor

Extends N/A


Use case Login

Actors Admin

Use case

description

User can see camera view ,change ,view dataset , through desktop

application by using this use case

Normal flow (i)User enters his username in the required field to log in to the

application. (ii)User types his password and presses the login

button

The Reaper

32

Alternative

flow

If incorrect username or password is entered show an error

message and

login will not be successful

Precondition Username and password of user must be already registered

Post

condition

The user successfully logs in

Includes Authentication

Extends N/A


Use case View camera input

Actors Admin

Use case

description

This use case provides Admin to view schedule

Normal flow Admin successfully logs in

Admin views the robots activity

Alternative

flow

Admin is not able to see camera view due to some technical faults

in camera or night vision

Precondition Admin is logged in

Post

condition

Camera view is displayed

Includes Video

Extends live video


Use case Gets notifications

Actors Admin

Use case Admin will be able to receive alerts and notifications using this

The Reaper

33

description use case

Normal flow Notifications are received by the admin

Alternative

flow

Unable to receive notifications

Precondition Admin’s number must be registered in database

Post

condition

Notifications received through sms alert

Includes N/A

Extends N/A


Use case Gives voice commands

Actors Admin

Use case

description

Using this use case the Admin can give voice commands to the

system also in case of an intruder

Normal flow Admin gives voice commands

Alternative

flow

N/A

Precondition Admin gives voice commands which must be recognized by the

voice recognition module

Post condition Serial port communication through arduino occurs and servos

move for response generation

Includes N/A

Extends N/A


Use case Changes dataset

Actors Admin

Use case

description

Admin can change the images folder in the data set through

which the system recognizes faces and can add more images

The Reaper

34

data set so that the system/robot can recognize more faces

Normal flow Admin logs in

Admin adds or removes images in data set and saves data set

Alternative

flow

Admin only views data set and makes no changes

Precondition the desktop application must be logged in by the admin

Post condition New images are added in data set or removed. Data set is altered

Includes N/A

Extends N/A

4.5.4 Sequence Diagrams

4.5.4.1 Voice Recognition sequence diagram

Figure 4- 5 Voice Recognition Sequence Diagram

4.5.4.2 System Sequence Diagram

The Reaper

35

Figure 4- 6 System Sequence Diagram

The Reaper

36

4.5.4.3 Desktop application Sequence Diagram

Figure 4- 7 Desktop application Sequence Diagram

4.5.5 Activity Diagram

Figure 4- 8 Activity Diagram

The Reaper

37

4.5.5 State Transition Diagram

In this section, state transition of application is shown how it changes to another

state.

Figure 4- 9 State Transition Diagram

The Reaper

38

4.5.5 Class Diagram

Figure 4- 10 Class Diagram

Table 4- 14 Description of Classes

Class Description

Main This is the main class.it will execute first and acquire video from

that video it will extract images and call for face detection method

Face

detection

In this class input from camera is taken in form images and then it

will detect human faces

The Reaper

39

Voice

recognition

Voice recognition class will call immediately after getting voice

commands from admin. It will match

Voice from data set and then actuate either by moving servos or

respond back

Admin

Admin can login to desktop application. it can add or remove

images from dataset as well as see the live video from camera

Voice commands can also be send.

Hardware

Hardware class will be able to move servos. It will be call after

face recognition class or after voice recognition. it can track face

by moving hardware part (servos) of The Reaper or actuate on

voice commands by moving servos e.g. for command like look

up it will move servos to look in the upward direction

Dataset This class will be called either for image recognition from dataset

or voice recognition or to add or remove images or authenticate

user id and password provided in desktop application

Face

recognition

After the face are detected this class will match face with

dataset if it matches with images provided in dataset it will go for

face tracking or again recognize the new images provided

4.6 Detailed Description of components

4.6.1 Input Hardware:

These include:

1. Camera

2. Sensors

3. Microphone, Arduino

Table 4- 15 Input Hardware

The Reaper

40

Identification Name: Input Hardware

Location: presentation layer of system architecture

Type Hardware components

Purpose

This is the component that is visible, and the user interacts with

directly. All input, voice or image is given using this component.

The requirements that this component fulfills are

1. Camera works with lower FPS (15) on higher resolution of

1280x960 and higher FPS (30) on resolution lower than

1280x720

2. Ultra sonic sound sensor has a range of 2-400cm with accuracy

of 3mm

3. Serial Port communication occurs between robot , its camera and

other sensors and the laptop/computer . ESP 8266 wifi network

connection through arduino

4. Camera feed will go to computer through serial communication

and through the applied algorithms and facial features acquired

by camera input.it will be successfully detected that there is a

face in front of camera

5. The robot’s camera shall correctly detect faces according to

facial feature

6. The system shall transmit all the voice signals correctly to

computer through serial port communication and after Natural

language processing it should be able to deliver output correctly

Function

This component sole purpose is to take input.

Input can be of 3 types:

The Reaper

41

Subordinates

Camera

Audio microphone

Ultrasonic sensor

Dependencies

This component 3.1 Input HW interacts with component 3.4

Database and 3.2 ‘application’ whenever user interacts with

the, Hardware, the voice clip and video are stored in database for

processing and are made visible in the application when required.

Interfaces N/A pins and ports to Arduino.

Resources Power supply provided to Arduino used to power up this component.

Processing N/A

Data Audio/video stream.

4.6.2 Application

Table 4- 16 Application

Identification Name :Application UI

Location : presentation layer of system architecture

Type

UI components

The Reaper

42

Purpose

If needed the user will interact with this component. The input

Stream provided by 3.1 input hardware will be displayed here

along with the faces recognized and command identified.

1. An executable python application which will encode users and

friendly faces and save them in the trained dataset.

2. A simple GUI interface may be needed that shows the camera

feed/input that is sensed by the robot’s camera and also for

monitoring

3. OpenCV, Python 3.6 , Processing IDE, for face detection and

recognition etc.

Function

This component will only be visible when the raspberry pi will

be connected to a screen,

Subordinates

This component has 2 subordinates ,one is responsible for

displaying feed other is responsible for recognizing new faces

and Commands

Dependencies

This component 3.2 interacts with 3.3 ‘subsystem’, 3.1 ‘Input

Hardware’ and 3.1 ‘Input Hardware’ and 3.4 ‘Databases’

This component is dependent upon ‘subsystem database and

subsystem where as in component is dependent upon this

component.

Interfaces

This component will provide interface to component 3.3 DB and

3.4subsystem when the raspberry pi will be connected to and

external screen using HDMI

Resources

Screen for display, storage device for logs in raspberry pi, HDMI

cable, power supply, python code embedded in the raspberry to

run the application

Processing Takes data from the database and sub system and displays it and

sets up databases for a new user

The Reaper

43

Data Faces and commands detected from the input units stored in

databases

4.6.3 Subsystem

This component has 7 sub-systems:

1. face detection

2. face recognition

3. face tracking

4. voice detection

5. voice recognition

6. voice commands

7. actuators

Table 4- 17 Subsystem

Identification Name: Subsystem management

Location: Processing layer of system architecture.

Type Processing component

Purpose

Input that comes in from the input devices component and data

Sets are extracted from the database and processing is done here.

1. It system’s camera shall correctly identify the distance of

person’s face from it and track it in the right direction

2. The robot shall correctly recognize faces from the data-set.

3. The system shall correctly take actions after voice recognition

4. The system shall transmit all the voice signals correctly to

computer through serial port communication and after Natural

language processing it should be able to deliver output correctly.

5. The system’s network connection must be configured through

the arduino

The Reaper

44

4.6.4 Database

Table 4- 18 Database

Identification Name: Database

Location: Application layer of system architecture

Type Data storage component

Function The function of this component is to use the input data stream

of Audio and video, take assistance from the internet and

provided data set, first detect faces and audio faces are

recognized using the ratio between different points on the face

and audio is recognized using the frequency matching. It then

keeps track of the face and generates appropriate response for

command. This component is also responsible for classifying

new commands and faces and updating database. Learning

process is also handled here.

Subordinates This component has 8 subordinates face detection, face

Identification, face tracking, voice detection, voice recognition,

voice commands, input stream and decision.

Dependencies This component is dependent upon 3.1 ‘Input HW’ and 3.4 DB

Whereas 3.2 application and 3.5 ‘output HW’ are dependent on

it.

Interfaces Saves and takes data from database and provides content for

actuators and application resides in Arduino minimega and

raspberry pi

Resources Hardware: all input hardware

SW: database, python and processing (java) code, Raspian.

Processing N/A

The Reaper

45

Data All data from input stream, database and internet.

Purpose To store data of different component and users

Following functional requirements are fulfilled by

this component

1. Application shall not fail in retrieving information .the

success rate of information

2. Retrieval must be 90%. That is 90% attempts of retrieving

information must succeed.

Function This component stores all the data fed into it at

development and all new data stored as the system

runs. Tables are kept and transactions are made in

this component

It interacts with (3.2)’application component’ and (3.3)

‘Subsystem component’

Subordinates This component has two subordinates

1. 1. Modify database

2. Send data to other components

Dependencies This sub system is dependent on (3.3) “Sub System

Component” and vice versa whereas (3.2)

application is dependent on this component

(3.1) Input Hardware is also dependent on this component

Interfaces SQL database server where all data will be saved

This component is provided interface by (3.3) “Sub System” for

data transaction

Resources Hardware: micro SD card on raspberry pi

Software: SQL server and python code

Processing Transaction performed to retrieve data from database to be used

by application and sub system

The Reaper

46

Data Information string, video stream, audio stream

4.6.5 Output hardware (Servos, Speakers)

Table 4- 19 Output Hardware

Identification Name: Output hardware

Location: Presentation layer

Type Hardware component

Purpose This is the component that is visible and the user

interacts with directly. Output whether by voice or

movement is generated by this component

The requirements that this component fulfills are:

1. Servos must be of the capability to move hardware

effectively and in the right direction

2. The movement will be free of glitches and as

smooth as possible

Responses will be life like and relevant

Function This component only shows output in form of movement or

sound via audio output unit

Subordinates This component has 3 subordinates

1. Servos

2. Audio output unit

3. Acrylic body parts

Dependencies No component depends on this component whereas this

component is dependent upon (3.4) Database and (3.3) Sub

system component

Interfaces USB ports and pins used to connect to arduino/raspberry pi

The Reaper

47

Resources Hardware: Power supply provided to arduino used to run this

component

Processing N/A

Data Audio stream, electrical pulses

4.7. Reuse and Relationships to other Products

Our system, The REAPER autonomous robot is totally a new product and it has

not evolved from any of the previously existing systems neither it is an extension

of any other applications at any level.

1) Our autonomous robot can be evolved into a bigger and more complex system

with more features and functionality.

2) Various hardware used in our project can be reused by developers and can be

connected to other hardware systems to make a new enhanced system

3) We can further use the components of our system to create a robot that detects

targets autonomously with a laser pointer. (can be further equipped with light

and medium caliber weapons)

4) We can also reuse the robotic hardware and software components to evolve our

system to a larger surveillance system by creating AI algorithms through which

our system detects and targets ground combat units, sea and air-based combat

units autonoumously with a high power laser.

5) We can also incorporate possible applications of Machine Learning with our

project to further increase its capabilities of being autonomous .

6) Therefore, The practical usage of the system can be increased by adding more

and more services to system

The Reaper

48

4.8. Design Decisions and Tradeoffs

A Design Pattern is a way of solving a recurring architectural problem. An

architectural design is very crucial for developing a system because:

1) If a system is poorly designed it will consume more resources

2) The end product made will have very little efficiency and a slower response

time which directly affects the experience of the target user

3) Poor designs make testing and maintenance activities difficult.

We are using MVC (model-view-controller) in our project “The Reaper”.

An MVC pattern, divides an interactive application in to 3 parts as,

1. Model: contains the core functionality and data

2. view : displays the information to the user (more than one view may be

defined)

3. controller: handles the input from the user

MVC model is used for the objective to hide the complexities of the system from

the user by decoupling the various components of the system

Decoupling divides the system into modules and helps assure the code reuse

efficiently.

In our project, MVC will be implemented as shown in the diagram given below:

The Reaper

49

Figure 4- 11 Design Pattern

We are using Model-view-controller because it is applicable to more than one

views therefor it is specifically applicable to our project as we have two views

1) Desktop app view: as user or admin can view activities of the system robot/

through it

2) Servos (parts of hardware movement )

As shown in the above diagram controller receives input from sensors and these

inputs can be in the form of camera image of voice commands. Further, the

controller responds to the user input and performs interactions on the data model

objects. The controller receives the input, optionally validates it and then passes

the input to the model. In our case arduino acts a controller and sends the input to

model through serial port communication.

The Reaper

50

After that, model receives input from the controller, uses data set images as a data

and matches the image received from controller with the dataset and does further

operation i-e face detection, face recognition, voice recognition.

Model then updates the view as a view can be any output form of information.

Multiple views of the same information are possible and our model also uses

more than one views.so in case of face tracking our model updates view to by

providing movement instructions through arduino to servos which are responsible

for moving in the right directions to track voice or to generate accurate response

in case of response generation for voice commands. The second view is of the

desktop application and the model updates this view by providing information in

the desktop app.

Therefore MVC supports our project by separating different elements of the

system and providing support for more than one views.

The Reaper

51

Chapter 5. Project Test and Evaluation

5.1. Introduction

This test plan section describes the appropriate strategies, process and

methodologies used to plan,

Software testing determines the quality of software after it is developed. Project

testing improves consistency and performance.

This test plan document describes the appropriate strategies, process and

methodologies used to plan, execute and manage testing of “The Reaper". This

test plan document will ensure that our system meets the functional, on-functional

and customer requirements as per the standards.

We will be manually testing our system for checking the conformity of its

functional and non-functional requirements, and this procedure includes testing

the test cases without the use of automated tools by the tester. The tester acts as an

end user and identifies any failures and bugs in the system. Each Unit will be

tested separately and then will be integrated with other units; therefore, Unit

Testing and Integration testing will be followed. For each unit, Black box Testing

is done and for combined units Acceptance Testing is done.

This document includes the scope, plan, approach and method of testing of THE

REAPER. The pass/fail criteria of the test items are also defined. Each test case

specifies who will be performing the test, the preconditions required to execute

each test case, the specific item to be tested, the input, expected output or results,

and procedural steps where applicable.

The Reaper

52

5.2. Test Items

As per the requirements given in our Software requirements Document of THE

REAPER, we have taken the following modules, features and functionalities of

our systems to be tested:

1) Face detection

2) Face recognition

3) Acquire Sensor Readings and outputs through sensors/hardware parts.

4) Voice recognition and response

5) Desktop Application

6) Dataset

7) Notifications

8) Distance measurement and tracking

9) Object detection

The sequence in which these test items will be tested is given below:

1. Firstly, Developing the test cases.

2. Executing tests based on the developed test cases for the software.

3. Report defects from the executed test cases if any.

4. After completion of above steps, test report is formed.

5. Incorporate or manage changes later in the stage of the project

development.

5.3. Features to Be Tested

Following Features are tested:

1) The system shall be able to acquire video of the in real time for further

processing.

2) The robot’s camera shall correctly detect faces according to facial feature.

3) The robot’s shall correctly recognize faces from the data-set and identify the

face as a familiar or unfamiliar face i.e intruder.

The Reaper

53

4) The robot/system shall be able to measure distance and track faces if not

recognizable.

5) The ability of the system to recognize voice of the specific person and take

actions accordingly.

6) The ability of the system to move its hardware parts i.e servos correctly in case

of face tracking and response generation after recognizing voice.

7) The ability of the system to send notification to the admin in case of

intruders/unfamiliar person

8) Admin shall be able to login to desktop application

9) Admin will be able to change dataset (encode/decode faces) and view the

robots activity through the desktop application.

5.4. Test Approach

Our System the REAPER is an intensive system which needs different modules to

be developed and integrated. Further, it includes software along with hardware

parts also making it a complex system on which only one testing technique is not

sufficient.

Different approaches/testing techniques will be applied to our project on each

system module and functionality owing to its complex nature.

Overall strategy comprises of Unit Testing using White Box and Black box testing.

Integration testing is performed in order to successfully integrate the system.

At the end, user-acceptance test will be executed based on the acceptance test plan.

1) Unit testing: Unit Testing is done at the source or code level for language-

specific programming errors such as bad syntax, logic errors, or to test particular

functions or code modules. The unit test cases shall be designed to test the validity

of the programs correctness.

The Reaper

54

Developers are responsible for unit testing.

2) Integration test:

In this testing, we will test all the previous tested modules in a way that they are

functioning normally when they are combined together.

All the units after tested individually,will be tested in groups as modules. After

modular integration, black box testing is done

3) System Testing

In the end, system testing will ensure that all the modules are working, separately

and together combined. Then only the outcome of the program will decide the

correctness of whole system

5.5. Item Pass/Fail Criteria

The Test cases and their details are being specified in the section 7 of the

document i.e Test deliverables. A test item will be classified as pass or fail based

on the following conditions.

1. Preconditions are met by the test case.

2. Various Inputs are performed in the way mentioned.

3. If the result works as what is specified in the output then the test is passed.

Hence, Output => Pass

4. If the system doesn't produce the desired output as expected or it doesn’t

work or not conforms to the output specification => Fail.

5.6. Suspension Criteria and Resumption

Requirements

Unforeseen circumstances can always occur in the form of some major bugs

which may lead to hurdles and restriction during the testing process. These major

The Reaper

55

bugs can block some test cases as they are interdependent and can restrict further

testing.

5.7. Test Deliverables

Following are the test cases.

5.7.1. Acquire Video

Test case number TC 01

Name of testcase Acquire Video

Test items/features Video is acquired from the camera mounted on the

robot. This video will be fed into the system for further

processing.

Testing technique Component testing, Black box testing

Input Specifications Valid Input:

1) Camera’s footage feeding into this module.

(Camera feed will go through serial port communication

over arduino)

2) Arduino, servos attached to camera.

Invalid input:

1)Camera not properly configured with arduino

2) Camera cap is not removed.

3) Low or no light.

Steps Open the video capture mode using openCV function

The Reaper

56

Output

Specifications

Valid output:

1)Video is acquired through the camera with resolution

of 1280x960

2) Video is captured correctly and continuously.

3)Video acquired through the camera and the openCV

Function returned True and loads the video

Invalid output:

1) Video unavailable due to improper camera

configuration

2) Video not visible due to dim or no light.

Environmental needs Hardware: Camera

Software: Python3.6, openCV 3

Inter case

Dependencies

Not dependent on any test case

Table 5- 1 TestCase 1

5.7.2 Face detection


Test case name Face detection

Test items/features The robot’s camera shall correctly detect faces according

to facial feature extraction

Testing technique Black Box testing, component testing


1) Face of person at distance of 400cm

3) Video frame by frame

Invalid Input:

1) Face angle greater than 50 degree on either side.

2) Face covered with mask

The Reaper

57

3) Person out of camera’s range

Steps 1. Camera feed will go to computer through serial

communication for processing.

2. Haar cascades will extract the facial features and

facial co-ordinates will be identified in the video

stream/frame

3. Target will be locked depicting that face in front of the

camera is present

Output

Specifications

Valid Output:

1)Extracted facial features through haar cascade,

2)Locking of face coordinates

3)Rectangle formation around face coordinates

Invalid Output:

1)Face not detected

Environmental

needs

Hardware: camera, arduino

Software: openCV, numpy, python, face detection

algorithm, Processing IDE

Inter case

Dependencies

Dependent on video acquiring


Figure 5- 1 Face detection

The Reaper

58

5.7.3. Face Recognition


Test case name Face Recognition

Test items/features This test case will test the feature / ability of the robot to

recognize the faces encoded to its dataset successfully


Input

Specifications

Valid Input:

1) Video input

2) Face of person detected at distance of 4 meters

3) Encoded Dataset for face matching

Invalid Input:

1) Familiar face not encoded in dataset

2) Identical faces

Steps After face is detected by an algorithm, it is matched

with the dataset and it is recognized if it is a familiar

face.

Output

Specifications

Valid Output:

1) Recognized face (matched numpy array of face with

dataset)

2) If detected face is matched with dataset/database face

(stored as numpy array) is recognized successfully.

Invalid Output :

1) Identical faces not distinguish

2) Person wearing sunglasses is not recognized.

3) Person not recognized due to improper lights and

shadows.

Environmental

needs

Hardware: camera, arduino, raspberry pi

Software: openCV, python IDE, numpy, AI face

The Reaper

59

recognition algorithms

Inter case

Dependencies

Dependent on face detection


Figure 5- 2 Face recognition

5.7.4. Intruder Detection


Test case name Intruder Detection

Test items/features Robot shall distinguish between intruders and similar

faces and take actions in case of an intruder.


Input

Specifications

Valid Input:

1) Video frames containing face input

2) Detected face

3) Encoded dataset

Invalid input:

1) Error in dataset or limitations of dataset

The Reaper

60

2) Dataset not trained properly.

2) Person is not intruder but is not encoded in dataset

Steps The detected face is matched with the encoded

dataset/database for classification of the face as either

intruder or non-intruder/similar face to the robot

Output

Specifications

Valid Output:

1) Unmatched input of face with encoded dataset i.e

intruder detected.

2) SMS notification send to admin via GSM module

Invalid output:

Intruder recognized as friendly face

Environmental

needs

Hardware: camera, arduino

Software: openCV, python IDE, numpy ,AI face

recognition algorithms, dataset

Inter case

Dependencies

Dependent on test case 2


Figure 5- 3 Intruder detection

5.7.5 Face Tracking

The Reaper

61


Test case name Face Tracking

Test items/features The robot’s sensors will track the face of the person if

it’s distance is within the range of the robot’s distance

measurement sensor



1) Camera Video frames

2) Detected face within 400 cm distance

3) Correct Ultrasonic sound waves sensor readings

Invalid Input:

1) Person is out of camera’s range i.e 4m

2) Incorrect distance measured by ultrasonic soundwaves

sensor

3) Incorrect, jittery servo movement.

Steps 1) Face is detected and not recognized and is classified as

an intruder.

2) Ultrasonic sound waves sensor measures distance of

the intruder’s face. If the face is within the range of the

sensor then movement directions are given to the servos

via arduino which then track the face of intruder (locked

target)

Output

Specifications

Valid output:

1)Servo movements to track intruder’s face

Servo.write(up,down,left,write);

Invalid output:

1) Tracking discontinued due to incorrect sensor

readings and range limitation

The Reaper

62

Environmental

needs

Hardware: servos, ultrasonic sound wave’s sensor.

Software: python

Inter case

Dependencies

Dependent on test case 3,4


5.7.6. Notifications


Test case name Notifications

Test items/features Notifications will be to the admin in case of

intruders/unfamiliar person



1)Video frames, intruder’s face

2) GSM module

3) Admin information through database

Invalid input:

1)Incorrect admin information

2) GSM package unavailable

Steps If intruder is detected, notifications are sent to the admin

through GSM module of the robot in the form of SMS

alerts.

Output

Specifications

Valid output:

1)Notification in the form of SMS alerts send to admin

Invalid Output

2) Message/notification not sent or sent to wrong number

The Reaper

63

Environmental

needs

Hardware: GSM module

Software: Database, python

Inter case

Dependencies



Figure 5- 4 Notifications

5.7.7 Voice Recognition


Test case name Voice Recognition

Test items/features The robot shall be able recognize voice of the specific

person and take actions accordingly.



1) Voice commands to robot

2) Gtech hexadecimal dictionary for voice commands,

Invalid Input:

The Reaper

64

1) Voice commands in language other than English

Steps 1)Voice is detected by microphone

2)Voice recognition module detects voice

3)Voice commands are processed through Natural

language processing and output is generated

Output

Specifications

Valid output:

1) Servos movement (e.g. if turn right command is

given serial port communication via arduino will occur

giving one of the servo to turn right)

2)After natural language processing ,Voice is

recognized and respond is generated in the from servo

movement in 5 directions accordingly

Invalid output:

No response is generated

Environmental

needs

Hardware: geetech hexadecimal dictionary for voice

commands, arduino, microphone

Software: NLTK toolkit, natural language processing

Inter case

Dependencies

Dependent on voice and voice commands, not on any of

above mentioned test cases


5.7.8 Response Generation


Test case name Response generation (servos and Google assistant)

Test items/features The robot will be able to recognize voice commands and

generate response accordingly

Input Specifications Valid input :

1) Voice commands to Google assistant built in the robot

(e.g. Today’s weather)

2) Geetech hexadecimal dictionary for voice commands,

arduino, microphone, speakers

The Reaper

65

Invalid input:

Voice input in language other than English

Steps 1)Voice commands are given by admin and recognized

by the robot

2) Servos move, if movement (tracking etc. or response

to commands) is required.

3) Robot’s Google assistant responds in the response of

respective voice commands

Output

Specifications

Valid Output:

1) Google assistant of the robot gives correct answers.

2) Servos move in the right direction

Invalid Output:

1) Commands not understood

2) No response generated

Environmental

needs

Hardware: geetech hexadecimal dictionary for voice

commands, arduino, microphone, speakers

Inter case

Dependencies

Dependent on voice commands


5.7.9 Admin Login


Test case name Admin login (GUI application)

Test items/features This test case evaluates the functionality of system for

successfully logging in of the admin on desktop

application.


Input Specifications Valid input:

1) Correct User name and password given by admin

The Reaper

66

2) login button pressed

3) Internet is available

Invalid output:

1) Incorrect user login / password entered

2) Incorrect database

Steps 1) username is enteredin the required field to log in to the

application.

2)Password is entered by the user

3) Login button is pressed by the user

Output

Specifications

Valid Output:

1) Admin id and password are verified.

2)Admin is logged in and able to access the Desktop

application

Invalid Output:

1) Username not recognized due to limitations of database

Environmental

needs

Software: desktop application (GUI)

Inter case

Dependencies

No


5.7.10 Edit Dataset


Test case name Edit dataset (GUI application)

Test items/features This test case tests the feature that Admin to change the

images folder in the data set through which the system

recognizes faces and an add more images data set so that

the system/robot can recognize more faces



1)Images of faces to be added in dataset are given as

input in python desktop application

The Reaper

67

Invalid input:

2)Image file format incompatible

Steps 1) Admin is logged in

2)Admin clicks “Add User’’ to add new faces to

dataset(Encoding)

3)Admin clicks “ Delete ” button to decode any face

from data set

4) Admin can view on “Users” box see images in dataset

5) Admin can see recognized faces in “recognized face”

box.

Output

Specifications

Valid output:

1) New image is added to dataset

2)Editing, viewing of dataset is performed successfully

by the admin

Invalid Output:

Invalid format image not added in dataset

Environmental

needs

Software: desktop application (GUI)

Hardware: laptop containing GUI

Inter case

Dependencies

Dependent on desktop application login (test case 11)


5.7.11 Live Video


Test case name Live Video (GUI desktop)

Test items/features This test case examines the ability of the desktop

application (GUI) to show live video of the robot

Input Specifications Input values:

1) Admin is logged in

The Reaper

68

2) Wifi module is connected

3) Robot and GUI are connected

4) Camera feed is available

Steps 1)Admin logs in

2)Admin clicks the “Start” on the desktop application

(GUI) to view live video

Output

Specifications

Live video is show on the GUI about the activities of the

robot

Invalid output:

Video not available due to incorrect connections

Environmental

needs

Software : desktop application (GUI),

Hardware : wifi module, micro SD card on raspberry pi

Inter case

Dependencies

Live Video (GUI desktop)


Figure 5- 5 Live Video

The Reaper

69

5.7.12. Object Detection


Test case name Object Detection

Test items/features This test case examines the ability of the robot to detect

and classify different objects and label them



1) Different Objects in front of camera.

Invalid Input:

1) Object should be within range of the camera i.e 4m

2) Brightness should be present

Output

Specifications

Output values:

1) Objects are classified by the object detection

algorithm

E.g. Chair and bottle are detected and classified for

this test case.

Invalid output:

1) Object recognized incorrectly. (chair is recognized

as bottle)

2) Not happened yet but rarely possible.

Environmental

needs

Software : Keras, tensor flow library, python

interpreter

Hardware : camera, sensors

Inter case

Dependencies



The Reaper

70

Figure 5- 6 Object Detection

5.7.13. Hardware Integration


Test case name Hardware Integration

Test items/features This test case tests that the different hardware

components of the system are working properly after

hardware integration

Input Specifications 1) Camera with resolution 1280x960

2) Arduino mini mega,

3) Servos attached to camera

4) Ultrasonic Sound waves sensor

5) GSM module

6) Gtech Voice module

7) Joysticks and Microphone

The Reaper

71

Testing technique Black box testing

Output

Specifications

1) Camera acquiring video every second

2) Serial port communication with arduino

3) Servos showing movements with and without

joysticks

4) GSM module working

5) Gtech module and microphone detecting voice

Environmental

needs

Hardware: All hardware modules mentioned in input

specification

Software : OpenCV or Webcam to test camera, Serial

port communication to check servos

Inter case

Dependencies

No, some hardware modules are interdependent


Figure 5- 7 Hardware Integration

The Reaper

72

5.7.14. System Integration


Test case name System(Integration) Test

Test items/features the overall functionality of “The Reaper”, is checked

here, which includes testing of all the modules

altogether



1) Face in front of robot’s camera

2) Camera acquiring video

3) Encoded dataset, Correctly mounted GSM module,

GUI application

4) Ultrasonic soundwaves sensor, Servos, arduino ,serial

port communication

Invalid Input:

1) Face behind camera or away from camera’s range

and angle

2) Dataset limitations , GSM module not configured

properly,

Output

Specifications

Valid output

1) detected face

2) recognized face and intruder detected

3) Tracked face

4) notifications send to admin

5) objects are detected

6) Admin is logged in and can view dataset and can see

live video.

Invalid output:

1) face not detected, familiar person is recognized as

intruder,

2) face is not tracked due to incorrect sensor readings

The Reaper

73

3) objects are not recognized due to camera range and

dim light

4) Dataset and trained model limitations


Figure 5- 8 System Integration

5.8. Responsibilities, Staffing and Training Needs

5.8.1. Responsibilities:

Every team member shall take part in the testing procedure of the project and

each one is responsible.

The Testing Procedures and testing methods are being carried out simultaneously

by all the members of the project i.e The Reaper .Therefore, all the developers of

The Reaper

74

the project are responsible for the completion of all components testing and

integration testing tasks.

5.8.1. Staffing and Training needs

The Testing of the System is a critical thing because it ensures quality in the

project.

Testing can’t be done efficiently without a sufficient knowledge base of the

various testing procedures such as unit testing, black box testing, white box

testing and integration testing. Basics knowledge of testing strategies and

techniques is needed for the testing of the project.

Therefore enough knowledge of these techniques is required by the developers to

critically evaluate the system in terms of testing techniques .

5.9. Environmental Needs

Hardware:

1) Camera with resolution 1280x960

2) Arduino mini mega,

3) Servos attached to camera

4) Ultrasonic Sound waves sensor

5) GSM module

6) Gtech Voice module

7) Joysticks and Microphone

Software:

1) Python 3.7

2) Pycharm

3) Anaconda for NLP

4) Java IDE

5) OpenCV

6) Coco for object recognition

The Reaper

75

7) Keras, tensorflow

8) PyQT (for desktop application)

9) Processing IDE, Matlab

5.10. Risk and Contingencies

There are various types of risk that may be associated with our project.

5.10.1. Schedule Risk:

While developing a project, situations can occur involving exposure to defect

and effecting the smooth execution of the project on the specified time.

The consequences of above mentioned circumstances may cause the project to

get behind schedule so in order to complete the project in time we will need to

increase the hours/day that the project is being worked on.

5.10.2. Operational Risks:

The operational risks in our project will be eliminated by:

1) Scheduling daily meetings

2) Incorporating regular deadlines in the tasks to meet the goals of the project

3) Maintaining communication within the group.

5.10.3. Technical risks:

Technical risks can occur due to not conforming to the given requirements and

these will be eliminated by keeping the once defined requirements constant.

5.10.4 Programmatic Risks:

The scope of the project will be limited in order to stay inside the constraints of

the project in order to avoid the programmatic risks.

The Reaper

76

Chapter 6. Future Work

This project consists of different hardware modules as well as software and it can be

used as a basis to understand and add features to make it into an even bigger and

complex system. Many features can be added to our project in its software as

well as hardware and its scope can be increased manifold. In our view the

features that can be added in near future in our project are as follows:

1. Creating a robot that detects targets autonomously with a laser pointer.

(can be further equipped with light and medium caliber weapons)

2. Adding an accelerometer and Gyro module

3. Possible applications of Machine Learning with the Reaper.

Chapter 7. Conclusion

The world nowadays is replacing traditional methods by automation. This

automation is especially taking place in the field of information technology.

Various technologies like artificial intelligence, machine learning, and computer

vision incorporated in robots is going to lead the world in the future.

7.1 Objectives achieved

Therefore, using these technologies we have created an autonomous robot

which is efficient, high in performance, optimized, cost effective and 99%

accurate in providing results. And these results constitute the tasks performed

by it which include face recognition, voice recognition, and object detection.

The reaper (autonomous robot) can provide home security better than guards

and CCTV cameras which need monthly subscriptions and it will be on duty

24/7.It will alert the authorities in case of a suspected person it sees thus

providing an efficient security system.

The Reaper

77

APPENDICES

The Reaper

78

APPENDIX A

The Reaper

79

Glossary

1. APP: Application

2. GUI: Graphical User Interface

3. DB: Database

4. SDS: Software Design Specification

5. UML: The Unified Modeling Language (UML) is a general-

purpose modeling language which is designed to provide a

standard way to visualize the design of a system

7. UI: User Interface

8. WBS: The project management Work Breakdown Structure

The Reaper

80

APPENDIX B

USER MANUAL

The Reaper

81

Chapter 8 GENERAL INFORMATION

System Overview:

Reaper is an autonomous home security robot that is designed to capture a set of

familiar faces using its camera unit at various angles and create a dataset at

installation stage. A separate dataset is created for each familiar person along with

their name.

This is the installation phase and this is done using the Reaper’s desktop

application. After the installation phase the Reaper works by continuously

recording a video of its surrounding recognizing faces of each person. If a person

appears that is not present in the reaper’s datasets, it will identify the person as an

intruder and will alert the user or admin via sound output through its speaker or

text message that an unknown person has entered its proximity. Along with this

the reaper also works as a home assistant which means it if fully functional of

holding conversations and doing small everyday tasks, much like Amazon Alexa

and Google assistant. The reaper is a self-sustained device that can perform

without an interface but it additionally is equipped with a desktop application that

can show the live stream of the input video and the faces it recognizes.

Organization of the manual:

The user’s manual consists of five sections: General Information, System

Summary, Getting Started, Using the System.

1. General Information section explains in general terms the system and the

purpose for which it is intended.

2. System Summary section provides a general overview of the system. The

summary outlines the uses of the system's hardware and software requirements,

3. system’s configuration, user access levels and system’s behavior in case of

any contingencies.

4. Getting Started section explains how to setup the system and configure it

for the first time. The section presents briefly system's settings.

5. Using the System section provides a detailed description of system

functions.

The Reaper

82

System Summary

Chapter 9 SYSTEM SUMMARY

System Summary section provides a general overview of the system.

System Configuration:

Reaper is a self-sustained device that is equipped with all the necessary

components to function. The reaper comes with a camera, a microphone, a

speaker, a set of servos pre-assembled with acrylic parts, a raspberry pie and an

arduino minimega, a GSM module and a port where it all connects. A working

smartphone will be required to receive the SMS sent by the Reaper as alert and a

working computer system with windows 7 or above will be required to run the

desktop application. Most of all internet connection would be needed to run the

Reaper’s assistant component.

User Access Levels:

The Reaper robot will be available inside the house and will be accessible to all

residents while the admin controls in the desktop application will be available to

the home owner or in charge and anyone who has accesses to the provided login

information.

Contingencies:

In case of any errors or system crashes, the database will not be affected and user

datasets will remain safe.

Getting Started

Chapter 11 GETTING STARTED

Getting Started section explains how to configure the system and install it for the

first time use. The section also presents briefly the system's menu.

The Reaper

83

Installation:

Reaper System:

1. Camera should be clean and camera cap must be removed.

2. All wire connections must be checked to see and fix any loose

connections.

3. All servos must be at 90 degrees angle.

4. Raspberry pie should have access to the internet.

5. Raspberry pie should have a working and stable power supply

Desktop Application:

1. Computer must have compatible windows of 7 or above.

2. Storage permission should be granted to the application

System Interface:

The first screen of the desktop application

It will allow the user to Login himself by entering his username and password.

Display Stream and Datasets

After successfully logging into the application the user can view the live stream

and enter the information of the users as well as view already stored dataset

Notification SMS

This feature will inform user via SMS about an intruder present in the Reaper’s

vicinity.

Using the System

Chapter 12 USING THE SYSTEM

The Reaper

84

This section provides a description of system functions and features.

Surveillance Mode:

1. The user will turn on the Reaper which will be making video of the

surrounding and looking for familiar and unfamiliar faces

2. Upon unknown face detection:

2.1. Notification will be sent to the user via SMS.

Login:

This option enables user to login himself into the desktop application. It asks

for:

3.1. Username

3.2. Password

Saving and Accessing Datasets:

1. The user will use the application to add new person by bringing the person in

front of the system’s camera unit and taking a number of shots from various

angles.

2. The user can view edit and delete previously existing datasets using the

desktop application

Notifications:

Notifications will appear on the smartphone via SMS

1. On smartphone a notification will appear every time an intruder is detected.

The Reaper

85

Bibliography

[1] https://en.wikipedia.org/wiki/Software_requirements_specification

[2] https://arduino.stackexchange.com/questions/19474/functions-of-gsm

[3] https://www.sciencedirect.com/science/article/pii/S1877050915021870

[4] https://www.journals.elsevier.com/artificial-intelligence

[5] https://www.explainthatstuff.com/voicerecognition.html

[6] www.robots.ox.ac.uk/~vgg/publications/2015/Parkhi15/parkhi15.pdf

[7] https://www.researchgate.net/publication/309210149_Natural_Language_Processi

ng_A_Review

https://en.wikipedia.org/wiki/Software_requirements_specification

https://arduino.stackexchange.com/questions/19474/functions-of-gsm

https://www.sciencedirect.com/science/article/pii/S1877050915021870

https://www.journals.elsevier.com/artificial-intelligence

http://www.robots.ox.ac.uk/~vgg/publications/2015/Parkhi15/parkhi15.pdf

https://www.researchgate.net/publication/309210149_Natural_Language_Processing_A_Review

https://www.researchgate.net/publication/309210149_Natural_Language_Processing_A_Review

Documents

THE REAPER (Autonomous Home Security Robot)€¦ · Hafiza Samman Sohail Submitted to Faculty of Department of Computer Software Engineering National University of Sciences and Technology,