3D Point Plotting Robot For Evacuation

3D POINT PLOTTING ROBOT
FOR EVACUATION
A PROJECT REPORT
Submitted to University of Mumbai in partial ful llment of the

requirement for the degree of
BACHELOR OF ENGINEERING
In
COMPUTER ENGINEERING
Submitted By
GAIKWAD KIRAN SUBHASH

GHATMALE PRERANA RAVINDRA
KHOPADE NIKITA BHIMRAO
JADHAV RAHUL ASHOK
Under the guidance of
Prof.VINOD N ALONE
DEPARTMENT OF COMPUTER ENGINEERING

PADMABHUSHAN VASANTDADA PATIL PRATISHTHAN’S
COLLEGE OF ENGINEERING
SION , MUMBAI-400022
UNIVERSITY OF MUMBAI
2018-2019
3D POINT PLOTTING ROBOT
FOR EVACUATION
A PROJECT REPORT
Submitted to University of Mumbai in partial ful llment of the

requirement for the degree of
BACHELOR OF ENGINEERING
In
COMPUTER ENGINEERING
Submitted By
KELSKAR RAJAN
JADHAV RAHUL ASHOK
Under the guidance of
Prof.VINOD N ALONE
DEPARTMENT OF COMPUTER ENGINEERING

PADMABHUSHAN VASANTDADA PATIL PRATISHTHAN’S
SION , MUMBAI-400022
UNIVERSITY OF MUMBAI
2018-2019
PADMABHUSHAN VASANTDATA PATIL PRATISHTHAN’S COLLEGE OF
ENGINEERING SION,MUMBAI-400022
CERTIFICATE
This is to certify that the project work, entitled 3D POINT CLOUD POINTING ROBOT FOR
EVACUATION has completed successfully for the award of the Bach-elor of Engineering in
Computer Engineering by
JADHAV RAHUL ASHOK
Prof. VINOD N ALONE
Project Guide
Department of Computer Engineering

PADMABHUSHAN VASANTDATA PATIL PRATISHTHAN’S
SION,MUMBAI-400022
PROJECT APPROVAL CERTIFICATE
This is to certify that the project work, entitled 3D POINT CLOUD POINTING ROBOT FOR
EVACUATION is approved for the award of the Bachelor of Engineering in Computer
Engineering completed by
JADHAV RAHUL ASHOK
Internal Examiner External Examiner
Name Name
Date Date
Project Convener Head of Department
Principal
ABSTRACT
Most developing countries in the world have pothole- lled roads mainly because they are unable
to allocate adequate funds for road maintenance. Absence of e ective systems to monitor road
surfaces also contributes to this otherwise preventable situation. A road - surface- monitoring
system, which helps to detect the damages to the surface before it gets worse, can bring down the
cost of road maintenance signi cantly. However, most government-funded road authorities in the
developing countries are unable to a ord such expensive systems. We have come up with a low-
cost, road-surface-monitoring method, named as Pot Holes and Pit Falls Spotter, which employs
a small device mounted on public transport buses, as a viable solution to this problem. The
information would be conveyed in the manner which can be understood and used by the o cial.
We in this project try to design and build such a system. In this system the access point collects
the information about the potholes in the vicinity of a wireless access point and captures images
and nds the location using GPS module in terms latitude and longitude and sent back to
authorized person.
ACKNOWLEGEMENT
The project report on Performance tracking System is the outcome of the guidance, moral
support and devotion bestowed on our group throughout our work. For this we ac-knowledge and
express our profound sense of gratitude to everybody who has been the source of inspiration
throughout project preparation. First and foremost we o er our sincere phrases of thanks and
innate humility to Mr.Vinod N. Alone, Assistant Professor, Computer Department, PVPPCOE
and guide of our project for providing help whenever required.
We also would like to express our deepest gratitude to Dr.M.A.Devmane, HOD, Computer
Department, PVPPCOE for providing the valuable inputs. The consistent guidance and support
provided by Dr.Alam Shaikh, Principal, PVPPCOE is very thankfully acknowledged for key role
played by him in providing us with precious ideas and suggestions and help that enabled in
shaping the project work.
We can say in words that we must at outset tender our intimacy for receipt of a ec-tionate
care to PVPPCOE for providing such a stimulating atmosphere and conducive work environment
SPONSORSHIP LETTER(if any)
Contents
List of Figures iii
List of Tables iv
1 Introduction 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Aim and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Motivation for the Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Scope of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Organization of the report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Literature Survey 5
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Existing System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Need of New System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Problem De nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Design and Implementation 9

3.1 Proposed System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Requirement Gathering and Analysis . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Hardware Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . 10
i
3.2.2 Software Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 All UML Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Cost Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7 Feasibility Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Results and Discussion 18

4.1 Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Software Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 Screen Shots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Testing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 Test Case Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6 Cost of the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5 Conclusion 40
5.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Future Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
References 42
PUBLICATIONS 43
ii
List of Figures
3.1 Fire Bird V ATMEGA2560 robot block diagram . . . . . . . . . . . . . . . . 11

3.2 Infrared Range nder sensor and its inside view . . . . . . . . . . . . . . . . 11
3.3 Atmel Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 AVR Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.7 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.9 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Image of pothole clicked by camera pod . . . . . . . . . . . . . . . . . . . . . 35

4.2 Firebird 5 used for testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 User Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
iii
List of Tables
3.1 Sharp IR Range sensors coverage . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Cost Estimation of the Project . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Testing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
iv
Chapter 1
Introduction
1.1 Introduction
Most developing countries in the world have pothole- lled roads mainly because they are un-able
to allocate adequate funds for road maintenance. Absence of e ective systems to mon-itor road
surfaces also contributes to this otherwise preventable situation. A road surface-monitoring
cost, road-surface-monitoring method, named as Pot Holes and Pit Falls Spotter, which employs
a small device mounted on public transport buses, as a viable solution to this problem.
1.2 Aim and Objectives
A developing country undoubtedly needs a network of healthy and travelable roads to meet the
demand of ever increasing tra c. However, many countries, such as Sri Lanka, have roads dotted
with potholes, but no road monitoring system to watch the road condition before the damage to
the surface due to wear and tear becomes very expensive to repair.
1
There are several advantages of having an e ective road surface monitoring system, though
they are very expensive. Such a system can identify problem areas early and the relevant
authorities can be alerted in time to take preventive measures. Preventive measures always save
money. Besides, the studying of the data collected through a monitoring system leads to a better
understanding of the road deterioration process, which will come in handy when new road
networks are being planned. Although, in the long-run, a monitoring system helps the cost of
road maintenance outweigh its initial investment cost, developing countries always look for a
low cost apparatus to solve their problem. We stumbled upon a low cost solution for road surface
condition monitoring while designing the Pot Holes and Pit Falls Spotter. We are developing a
hardware which could be attached over the public transport vehicles and the functionality of the
hardware is to detect any pot holes or pit falls on the road, take the picture of the scene, nd the
exact location of it using GPS navigation in terms of latitude and longitude and nally send the
data to the respected authority. Similarly all the data related to the location of the potholes would
be sent to the authority. A server side technology will be used by the authorities, which would be
useful to get the statistical data view to the user. The collected data can be then processed to
locate potholes along the path traversed earlier by the vehicle. Herein we present a technique to
analyse and process the acceleration data obtained from the sensors to achieve the
aforementioned objective with a reasonable accuracy.
1.3 Motivation for the Work
With the increase in worlds population, there has been increasing load on the infrastructure.
Roads have been ooded with the vehicular tra c. It has become increasingly di cult to manage this
tra c. This is the prime motivation behind making a vehicle intelligent enough to aid driver in
various aspects. One of the increasing problems the roads are facing is worsened road conditions.
Because of many reasons like rains, oil spills, road accidents or inevitable wear and tear make
the road di cult to drive upon. Unexpected hurdles on road may cause more accidents. Also
because of the bad road conditions, fuel consumption of the vehicle increases; causing wastage
of precious fuel. Because of these reasons it is very important to get the information of such bad
road Conditions.
2
But there are various challenges involved in this. First of all there are various methods to get the
information about the road conditions. Then this information must be collected and distributed
over a database with sessional arrangements.Lastly the information must be conveyed in the
manner which can be understood and used by the o cial. We in this project try to design and
build such a system. In this system the access point collects the information about the potholes in
the vicinity of a wireless access point and captures images and nds the location using GPS
module in terms latitude and longitude and sent back to authorised person
1.4 Scope of Project
Many of the key imaging functions break down into highly repetitive tasks that are well suited to
microcontroller used, especially those with built-in hardware multipliers and onchip RAM. The
remaining tasks require hardware more suited to control ows and decision making such as
camera pod and Sharp IR range sensor. To gain the full bene t of both approaches, systems are
required that can e ectively combine both Camera and sensor within itself and use a single
transmission channel. With the addition of standard imaging functions written MATLAB of the
key building blocks are available for making an image processing system. Using the MATLAB
functions provided with the camera we can implement the hardware for the project. This project
could be an excellent learning experience in various engineering disciplines. The Digital Signal
Processing algorithms are now to be implemented in MATLAB so that the results can be
compared as well as simulations can be done for optimum performance.
3
1.5 Contribution
The major contributions are,The development of the pot holes and pitfalls nding system. In this
system the access point collects the information about the potholes in the vicinity of a wireless
access point and captures images and nds the location using GPS module in terms latitude and
longitude and sent back to authorized person.
1.6 Organization of the report
The organization of the report is as follows: Chapter 2 presents the Literature Survey and a brief
insight into related work. Chapter 3 is a technical chapter in which we have briey discussed
about the Design and Implementation. chapter 4 is the Result and Discussions chapter Finally in
chapter 5 we present the conclusions.
4
Chapter 2
Literature Survey
2.1 Introduction
Interest in Pot Holes and Pit Falls Spotter comes from the problems caused by tra c con-gestion
worldwide and a synergy of new information technologies for simulation, real-time control and
communications networks. Tra c congestion has been increasing world-wide as a result of
increased motorization, urbanization, population growth and changes in population density.
Congestion reduces utilization of the transportation infrastructure and increases travel time, air
pollution, fuel consumption and most importantly tra c accidents. The core reason for this
increase in congestion is the untreated pot holes or may be pit falls. The government are unable
to allocate adequate funds for road maintenance. Absence of e ective systems to monitor road
surfaces also contributes to this otherwise preventable situation. A road-surface-monitoring
developing countries are unable to a ord such expensive systems.
5
2.2 Existing System
Presently in the Concrete Jungle as we say, have the solution to ll the potholes but there is no
solution to detect the pothole. That is there is no mechanism which could be helpful in
monitoring the presence of pothole or pit falls on the road and send the details with the location
and how serious matter the particular part is to the authority. This has motivated us to come up
with this project and provide the same to the government. Our hardware could be precisely
attached to the base of the government vehicles or propriorily to BEST buses in the country. This
hardware could be placed adjacent to the stroke absorber of the vehicle. The functionality of the
hardware is to detect the pot hole as such it is encountered and capture the image using the
camera installed in it, nd its location using the GPS module and navigation chip in terms of
Latitude, Longitude and Altitude to be more precise. The server side will maintain a database
send by the hardware and will have a ne proper categorization of the location based pothole and
sort it out as per the priority of the treatment.
2.3 Need of New System
One of the increasing problems the roads are facing is worsened road conditions. Because of
many reasons like rains, oil spills, road accidents or inevitable wear and tear make the road di
cult to drive upon. Unexpected hurdles on road may cause more accidents. Also because of the
bad road conditions, fuel consumption of the vehicle increases; causing wastage of precious fuel.
Because of these reasons it is very important to get the information of such bad road Conditions
to the respective o cials because they have devices to automatically full the pot holes but nothing
to collect this information and distribute it to o cials. But there are various challenges involved in
this. First of all there are various methods to get the information about the road conditions. Then
this information must be collected and distributed over a database with sessional arrangements.
6
A road-surface-monitoring system, which helps to detect the damages to the surface before it
gets worse, can bring down the cost of road maintenance signi cantly. However, most
government-funded road authorities in the developing countries are unable to a ord such
expensive systems. We have come up with a low-cost, road-surface-monitoring method, named
as Pot Holes and Pit Falls Spotter, which employs a small device mounted on public transport
buses, as a viable solution to this problem.
We are developing a hardware which could be attached over the public transport vehicles and
the functionality of the hardware is to detect any pot holes or pit falls on the road, take the
picture of the scene, nd the exact location of it using GPS navigation in terms of latitude and
longitude and nally send the data to the respected authority. Similarly all the data related to the
location of the potholes would be sent to the authority. A server side technology will be used by
the authorities, which would be useful to get the statistical data view to the user. The collected
data can be then processed to locate potholes along the path traversed earlier by the vehicle.
Herein we present a technique to analyse and process the acceleration data obtained from the
sensors to achieve the aforementioned objective with a reasonable accuracy.
2.4 Problem Definition
Pot hole detection system is a system that aims at warning the respected authority about the
uneven roads and potholes in its path, giving them a clear idea of the priority based problem
solving. We study the di erent ways in which goal of the system can be achieved. We justify the
methods we have chosen in this project. And then we give details about the working of the di
erent subsystems.
The problem statement can be given as follows. This system consists of three main components one is
the IR sharp range sensor, second is the camera pod and other is the GPS module. Access points
responsible for storing the information about potholes in its vicinity,
7
taking the feedback from vehicles, updating the information in repository and broadcasting the
information to the authority over the server side. Whereas this project hardware which is the small
device placed in vehicle is responsible for sensing those potholes which it did not have previous
information about, locating and warning the driver about the potholes which it has information about,
and giving the data about newly sensed pothole to access point.
The whole scenario works as follows. The IR sharp sensor will constantly check for the
patches of pothole using distance calculation. When the distance is exceeded beyond the prede
ned value, it means the pothole is spotted at the area and the camera will be positioned at the
pothole capturing image of the pothole, at this time the GPS module will trigger and will use the
tracking satellites and will trigger the transmitter to transmit the data based on the location the
module. This data, image and the location, will be send to the server side using the Zigbee
module installed over the robot, to the authority holding the receiver. The receiver will have a
clear map APIs to get the location of the Pothole with marker and layer facility.
8
Chapter 3
Design and Implementation
3.1 Proposed System
Most developing countries in the world have pothole- lled roads mainly because they are unable
to allocate adequate funds for road maintenance[1]. Absence of e ective systems to monitor road
surfaces also contributes to this otherwise preventable situation. A road-surface-monitoring
cost, road-surface-monitoring method[2], named as Pot Holes and Pit Falls Spotter, which
employs a small device mounted on public transport buses, as a viable solution to this problem.
We are developing a hardware which could be attached over the public transport vehicles[2] and
the functionality of the hardware is to detect any pot holes or pit falls on the road, take the picture of
the scene, nd the exact location of it using GPS navigation in terms of lat-itude and longitude and
nally send the data to the respected authority. Similarly all the data related to the location of the
potholes would be sent to the authority. A server side technology will be used by the authorities,
which would be useful to get the statistical data
9
view to the user. The collected data can be then processed to locate potholes along the path
traversed earlier by the vehicle. Herein we present a technique to analyse and process[3] the
acceleration data obtained from the sensors to achieve the aforementioned objective with a
reasonable accuracy
3.2 Requirement Gathering and Analysis
We have come up with a low-cost, road-surface-monitoring method, named as Pot Holes and Pit
Falls Spotter which requires the following hardware and software gathering
3.2.1 Hardware Requirement
 Firebird 5
The Fire Bird V robot is the 5th in the Fire Bird series of robots. First two versions of the robots
were designed for the Embedded Real-Time Systems Lab, Department of Computer Science and
Engineering, IIT Bombay. Theses platforms were made commercially available from the version
3 onwards. All the Fire Bird V series robots share the same main board and other accessories. Di
erent family of microcontrollers can be added by simply changing top microcontroller adapter
board. Fire Bird V supports ATMEGA2560 (AVR), P89V51RD2 (8051) and LPC2148 (ARM7)
microcontroller adapter boards. This modularity in changing the microcontroller adapter boards
makes Fire Bird V robots very versatile.
 Sharp IR Range Sensors
For accurate distance measurement, robot uses Sharp IR range sensors. Robot can be tted with ve
IR range sensors as shown in gure 3.29. Sharp IR range sensors consists of IR LED and linear
CCD array, both encapsulated in the housing with precision lens assembly
10
Figure 3.1: Fire Bird V ATMEGA2560 robot block diagram
mounted in front of them. IR LED with the help of the leans transmits a narrow IR beam. When
light hits the obstacle and reects back to the linear CCD array, depending on the distance from
the obstacle, angle of the reected light varies. This angle is measured using the CCD array to
estimate distance from the obstacle. It gives same response to di erent coloured objects as
measured distance is function of the angle of reection and not on the reected light intensity.
Sensor gives out analog voltage corresponding to angle of reection.
Figure 3.2: Infrared Range nder sensor and its inside view
Relationship between the angle of reection and output voltage is not linear because of
trigonometry involved. These sensors have blind spot in the range of 0mm to some speci c
distance depending on the type of the sensor. In the blind spot region sensor gives incorrect
readings. Table 3.9 gives information about sensing range and the blind spot distance for the
particular sensor.
11
Table 3.1: Sharp IR Range sensors coverage
Sensor Range Blind Spot
GP2D120X 30cm to 20cm 4cm to 0cm
GP2Y0A02YK 80cm to 10cm 10cm to 0cm
3.2.2 Software Requirement
 Atmel Studio
AVR studio is an Integrated Development Environment (IDE) for writing and debugging AVR
applications. As a code writing environment, it supports includes AVR Assembler and any
external AVR GCC compiler in a complete IDE environment. AVR Studio gives two main
advantages:
1. Edit and debug in the same application window. Faster error tracking.
2. Breakpoints are saved and restored between sessions, even if codes are edited.
Middle window shows current code under development. Window on the left side shows view of
source les, header les, External dependencies, and other les. Right side window shows all the ports
and other peripherals status. Bottom window is known as Build window. It shows results of the
compilation, errors, HEX le size and other warning messages etc.
 AVR Boot Loader
All AVR microcontrollers can be programmed using In System Programming (ISP), external
programmer or using boot loader. Advantage with the boot loader is that you dont need any external
hardware to load .hex le on the microcontroller. It also protects robots hardware from possible
damage due to static electricity and prevents any accidental changes in the fuse settings of the
microcontroller. If Bootloader rmware is loaded on the microcontroller,
12
Figure 3.3: Atmel Studio
it allows in system programming directly via serial port without any need for the external ISP
programmer. Code responsible for In System Programming via serial port (boot loader) resides
in the con gurable boot memory section of the microcontroller. When signaled using external
switch while resetting the microcontroller it gets active and waits for communication from the
PC for copying .hex le on the microcontrollers ash memory. PC sends the .hex le to the
microcontroller. Code residing in the boot section loads the .hex le on the microcontrollers ash
memory. After the boot loading process is complete, newly loaded code can be executed by
pressing reset. Once the code is loaded on the microcontroller UART is free and can be used for
other applications. Bootloader get invoked only if boot switch is kept pressed while
microcontroller is reset using reset switch. 2.6.2 Programming the robot via Bootloader from
NEX Robotic.
13
Figure 3.4: AVR Loader
3.3 Design
3.3.1 All UML Diagrams

Write here explanation about the your class diagram in 2 to 3 lines
Figure 3.5: Class Diagram
Write here explanation about the your sequence diagram in 2 to 3 lines

Write here explanation about the your activity diagram in 2 to 3 lines
Write here explanation about the your data ow diagram in 2 to 3 lines
14
Figure 3.6: Sequence Diagram
Figure 3.7: Activity Diagram
3.4 Algorithm
1. Initialise all the ports and LCD device to reset state.
2. Move the bot in forward direction, forward();
3. Move the bot with constant velocity(150,150);
4. Rotate the servo motor mounted with the IR Sharp Sensor within a range of 0-180 degrees.
15
Figure 3.8: Data Flow Diagram
5. Constantly check for the value of Sharp IR Sensor
6. If the value is constant or is less than or equal to threshold value, then go to step 4,
7. Else a pothole is detected, hence stop the servo motor and move camera pod to the
direction of pothole.
8. Capture image, camera(); and locate the pothole using GPS module, locate(latitude,
longitude);
9. Send both the data to server.
10. Go to step 4.
3.5 Timeline Chart
3.6 Cost Estimation
Write here about the cost estimation techniques such as COCOMO Model
Table 3.2: Cost Estimation of the Project

Equipment Description Cost
Sharp IR sensor Used to measure distance and nd pot Rs. 150
hole
GPS Module Used to get the location of the Pothole Rs. 1400
in terms of latitude and altitude
16
Figure 3.9: Timeline Chart
3.7 Feasibility Study
The practical application of the project goes like by providing the hardware to the govern-ment
for instance the BMC. Now the client will be provided with the hardware and the website
wherein the hardware will be attached to the vehicles and the software will con-stantly keep
updating the o cials with the required details and updates on the same i.e. the location of the
pothole will be provided along with the prioritized categorization of the place to be treated
formerly and e ciently. The authority must install the package provided by us. The package will
have the required settings to be done over the server side. After that, the client just needs to start
with the website and click on the view map link. This will be redirecting them to Google Maps
API with marker and layer system to get the location of the map. By moving the cursor on the
marker, he can view the location address and by clicking on the advance view, he could set
priority based deduction to view the result. Thus the o cial can think on lling mechanism of the
pothole. Once done, the software will rescan the place to see whether the place is normalised and
the appropriate updates will be provided.
17
Chapter 4
Results and Discussion
4.1 Codes
#d e f i n e F CPU 14745600
#d e f i n e RS 0
#d e f i n e RW 1
#d e f i n e EN 2
#d e f i n e l c d p o r t PORTC
#d e f i n e s b i t ( reg , b i t ) r e g j= (1<<b i t )
#d e f i n e c b i t ( reg , b i t ) r e g &= ~(1<< b i t )
#i n c l u d e <avr / i o . h>
#i n c l u d e <avr / i n t e r r u p t . h>
#i n c l u d e <u t i l / d e l a y . h>
#i n c l u d e <math . h> // i n c l u d e d t o s u p p o r t power f u n c t i o n
void timer5 init();
void velocity(unsigned char , unsigned char);

void motors delay();
void init ports();
18
void lcd reset();
void lcd init();
v o i d lcd wr command ( u n s i g n e d c h a r ) ;
void lcdwrchar(char);
void lcd line1();
void lcd line2();
void lcd string(char );

unsigned char ADC Conversion ( u n s i g n e d char);
unsigned char ADC Value ;
unsigned char sharp , d i s t a n c e , a d c reading;
unsigned i n t temp ;
unsigned int unit;
unsigned int tens;

unsigned i n t hundred ;
unsigned i n t thousand ;
unsigned int million;
unsigned int value;
void buzzer pin config (void)
f
DDRC = DDRC j 0 x08 ;
PORTC = PORTC & 0xF7
g
void lcd port config (void)
DDRC = DDRC j 0xF7 ; // a l l t h e LCD pin ’ s d i r e c t i o n s e t a s output

PORTC = PORTC & 0 x80 ; // a l l t h e LCD p i n s a r e s e t t o l o g i c 0 e x c e p t PORTC 7
19
void adc pin config (void)
f
DDRF = 0 x00 ; // s e t PORTF d i r e c t i o n a s i n p u t
PORTF = 0 x00 ; // s e t PORTF p i n s f l o a t i n g
DDRK = 0 x00 ; // s e t PORTK d i r e c t i o n a s i n p u t
PORTK = 0 x00 ; // s e t PORTK p i n s f l o a t i n g
g
void servo1 pin config (void)
f
DDRB = DDRB j 0 x20 ; // making PORTB 5 p i n output
PORTB = PORTB j 0 x20 ; // s e t t i n g PORTB 5 p i n t o l o g i c 1

g
void motion pin config (void)
DDRA = DDRA j 0x0F ;

PORTA = PORTA & 0xF0 ;
DDRL = DDRL j 0 x18 ; // S e t t i n g PL3 and PL4 p i n s as output f o r PWM g e n e r a t i o n

PORTL = PORTL j 0 x18 ; //PL3 and PL4 p i n s are for v e l o c i t y c o n t r o l u s i n g PWM.
g
void port init (void)
f
motionpinconfig();
buzzerpinconfig();
20
lcd port config();
adc pin config();

servo1 p i n c o n f i g ( ) ; // C o n f i g u r e PORTB 5 p i n f o r s e r v o motor 1 o p e r a t i o n
g
void timer5 init()
f
TCCR5B = 0 x00 ; // Stop
TCNT5H = 0xFF ;
TCNT5L = 0 x01 ;
OCR5AH = 0 x00 ;
// Output compare re gis ter high value f o r L e f t Motor
OCR5AL = 0xFF ;
// Output compare r e g i s t e r low v a l u e f o r L e f t Motor

OCR5BH = 0 x00 ;
// Output compare re gis ter high value f o r Right Motor
OCR5BL = 0xFF ;
// Output compare r e g i s t e r low v a l u e f o r Right Motor
OCR5CH = 0 x00 ;
// Output compare re gis ter high value f o r Motor C1

OCR5CL = 0xFF ;
// Output compare r e g i s t e r low v a l u e f o r Motor C1
TCCR5A = 0xA9 ;
TCCR5B = 0x0B ;
//WGM12=1; CS12=0, CS11=1, CS10=1 ( P r e s c a l e r =64)
g
voidvelocity(unsignedcharleftmotor,unsignedcharrightmotor)
21
OCR5AL = ( u n s i g n e d char)left motor;
OCR5BL = ( u n s i g n e d char)right motor;
g
void motionset (unsigned char Direction)
f
u n s i g n e d c h a r PortARestore = 0 ;
D i r e c t i o n &= 0x0F ;
// removing upper n i b b e l f o r the protection
PortARestore = PORTA;
// r e a d i n g t h e PORTA o r i g i n a l status
PortARestore &= 0xF0 ;

// making l o w e r direction nibbel to 0
PortARestore j= Direction;
PORTA = PortARestore ;
// e x e c u t i n g t h e command
g
void forward (void)
f
m o t i o n s e t ( 0 x06 ) ;
g
void stop (void)
f
m o t i o n s e t ( 0 x00 ) ;
g
void buzzeron (void)
f
unsigned char portrestore=0;
22
port restore = PINC ;
port restore = p o r t r e s t o r e j 0 x08 ;

PORTC = p o r t restore;
g
void buzzer off (void)
f
unsigned char port restore=0;
p o r t r e s t o r e = PINC ;
port restore =port r e s t o r e & 0xF7 ;
PORTC = p o r t r e s t o r e ;
g
void adc init()
f
ADCSRA = 0 x00 ;
ADCSRB = 0 x00 ;
//MUX5 = 0
ADMUX = 0 x20 ;
// V r e f=5V e x t e r n a l ADLAR=1 MUX4: 0 = 0000
ACSR = 0 x80 ;
ADCSRA = 0 x86 ;
//ADEN=1 ADIE=1 ADPS2: 0 = 1 1 0
g
void timer1init(void)
f
TCCR1B = 0 x00 ; // s t o p
TCNT1H = 0xFC ; // Counter h i g h v a l u e t o which OCR1xH v a l u e i s t o be compared w TCNT1L = 0

x01 ;
23
// Counter low v a l u e t o which OCR1xH v a l u e i s t o be compared with
OCR1AH = 0 x03 ; // Output compare R e g i s t e r h i g h value for servo 1
OCR1AL = 0xFF ; // Output Compare R e g i s t e r low Value For servo 1
OCR1BH = 0 x03 ; // Output compare R e g i s t e r h i g h v a l u e for servo 2
OCR1BL = 0xFF ; // Output Compare R e g i s t e r low Value For servo 2
OCR1CH = 0 x03 ; // Output compare R e g i s t e r h i g h v a l u e for servo 3
OCR1CL = 0xFF ; // Output Compare R e g i s t e r low Value For servo 3

ICR1H = 0 x03 ;
ICR1L = 0xFF ;
TCCR1A = 0xAB ;
TCCR1C = 0 x00 ;
TCCR1B = 0x0C ;
g
void init devices (void)
c l i ( ) ; // C l e a r s t h e g l o b a l i n t e r r u p t s p
ortinit();
timer1init();
timer5init();
adcinit();
s e i ( ) ; // Enables t h e g l o b a l i n t e r r u p t s g
void lcd set 4bit()
f
delayms(1);
c b i t ( l c d p o r t , RS ) ;
c b i t ( l c d p o r t ,RW) ;
24
l c d p o r t = 0 x30 ;
s b i t ( l c d p o r t ,EN ) ;
delay m s ( 5 );
c b i t ( l c d p o r t ,EN ) ;
delay m s ( 1 );
l c d p o r t = 0 x30 ;
delay m s ( 5 );
delayms(1);
l c d p o r t = 0 x30 ;
delay m s ( 5 );
delay m s ( 1 );
l c d p o r t = 0 x20 ;
delay m s ( 1 );
g
v o i d lcd wr command ( u n s i g n e d c h a r cmd)
25
f
u n s i g n e d c h a r temp ;
temp = cmd ;
temp = temp & 0xF0 ;
lcd port &= 0x0F ;
lcd port j= temp ;

delay m s ( 5 );
cmd = cmd & 0x0F ;
cmd = cmd<<4;
l c d p o r t &= 0x0F ;
l c d p o r t j= cmd ;
delay m s ( 5 );
g
v o i d lcd home ( )
f
lcd wr command ( 0 x80 ) ;
g
v o i d l c d c u r s o r ( c h a r row , c h a r column )
26
s w i t c h ( row )
f
case 1 : lcd wr command ( 0 x80 + column 1 ) ; break ;
case 2 : lcd wr command ( 0 xc0 + column 1 ) ; break ;
case 3 : lcd wr command ( 0 x94 + column 1 ) ; break ;
case 4 : lcd wr command ( 0 xd4 + column 1 ) ; break ;
d e f a u l t : break ;
g
g
void lcd wr char(char letter)
f
c h a r temp ;
temp = l e t t e r ;
temp = ( temp & 0xF0 ) ;
l c d p o r t &= 0x0F ;
l c d p o r t j= temp ;
s b i t ( l c d p o r t , RS ) ;
delay m s ( 5 );
letter= l e t t e r & 0x0F ;

l e t t e r = l e t t e r <<4;
l c d p o r t &= 0x0F ;
l c d p o r t j= l e t t e r ;
s b i t ( l c d p o r t , RS ) ;
27
delayms(5);
g
void lcdstring(char str)
f
w h i l e ( s t r != ’ n0 ’ )
f
lcdwrchar( str);
s t r ++;
g
g
v o i d l c d p r i n t ( c h a r row , c h a r coloumn , u n s i g n e d i n t value , i n t d i g i t s )
f
unsigned char f l a g =0;
i f ( row ==0jjcoloumn==0)
f
lcd home ( ) ;
g
else
f
lcd c u r s o r ( row , coloumn ) ;
g
i f ( d i g i t s ==5 j j f l a g ==1)
f
m i l l i o n=v a l u e /10000+48;
lcdwrchar(million);
28
f l a g =1;
g
i f ( d i g i t s ==4 j j f l a g ==1)
f
temp = v a l u e / 1 0 0 0 ;
thousand = temp%10 + 4 8 ;
l c d w r c h a r ( thousand ) ;
f l a g =1;
g
i f ( d i g i t s ==3 j j f l a g ==1)
f
temp = value/100;
hundred = temp%10 + 4 8 ;
l c d w r c h a r ( hundred ) ;
f l a g =1;
g
i f ( d i g i t s ==2 j j f l a g ==1)
f
temp = value/10;
t e n s = temp%10 + 48;
lcd wr char(tens);
f l a g =1;
i f ( d i g i t s ==1 j j f l a g ==1)
f
unit= v a l u e %10 + 4 8 ;
lcdwrchar(unit);
29
g
i f ( d i g i t s >5)
f
lcdwrchar(’E’);
g
unsigned i n t Sharp GP2D12 estimation ( u n s i g n e d char adc reading)
f
float distance;
unsigned int distanceInt;
d i s t a n c e = ( i n t ) ( 1 0 . 0 0 ( 2 7 9 9 . 6 ( 1 . 0 0 / ( pow ( a d c reading,1.1546)))));
distanceInt=(int)distance;
i f ( d i s t a n c e I n t >800)
f
d i s t a n c e I n t =800;
g
return distanceInt;
g
u n s i g n e d c h a r ADC Conversion ( u n s i g n e d c h a r Ch)
f
unsigned char a;
i f (Ch>7)
f
ADCSRB = 0 x08 ;
g
Ch = Ch & 0 x07 ;
ADMUX= 0 x20 j Ch ;
30
ADCSRA = ADCSRA j 0 x40 ;
// S e t s t a r t c o n v e r s i o n b i t
w h i l e ( (ADCSRA&0x10 )==0);
// Wait f o r ADC c o n v e r s i o n t o complete
a=ADCH;
ADCSRA = ADCSRAj0 x10 ; // c l e a r ADIF (ADC I n t e r r u p t Flag ) by w r i t i n g 1 t o i t

ADCSRB = 0 x00 ;
return a;
g
unsigned int sharp s e n s o r ( c h a r row , char column , u n s i g n e d char channel)
f
s h ar p = ADC Conversion ( c h a n n e l ) ;
v a l u e = Sharp GP2D12 estimation ( s h a rp ) ; l c d p

r i n t ( row , column , value , 3 ) ; r e t u r n v a l u e ;
g
void servo1(unsigned char degrees)
f
float PositionPanServo=0;
PositionPanServo=((float)degrees / 1.86)+35.0;
OCR1AH = 0 x00 ;
OCR1AL = ( u n s i g n e d c h a r ) P o s i t i o n P a n S e r
vo;g
f
float PositionTiltServo=0;
PositionTiltServo=((float)degrees / 1.86)+35.0;
31
OCR1BH = 0 x00 ;
OCR1BL = ( u n s i g n e d c h a r ) P o s i t i o n T i l t S e r v
o;g
f
float PositionServo=0;
PositionServo=((float)degrees / 1.86)+35.0;
OCR1CH = 0 x00 ;
OCR1CL = ( u n s i g n e d ch a r ) PositionServo;
g
void servo 1 free ( v o i d ) // makes servo 1 free rotating
f
OCR1AH = 0 x03 ;
OCR1AL = 0xFF ; // Servo 1 o f f
g
f
OCR1BH = 0 x03 ;
OCR1BL = 0xFF ; // Servo 2 o f f
g
f
OCR1CH = 0 x03 ;
OCR1CL = 0xFF ; // Servo 3 o f f
g
void lcd init()
32
delayms(1);
lcd wr command ( 0 x0E ) ;
g
i n t main ( v o i d )
f
unsigned int value;
u n s i g n e d c h a r deg = 9 0 ;
i n t check =0;
init devices();
lcd set 4bit();
lcd init();
servo1(90);
s e r v o 2 ( deg ) ;
s e r v o 3 ( deg ) ;
while(1)
f
i f ( deg >=180)
f
check = 0 ;
g
e l s e i f ( deg <=0)
f
check =1;
33
g
i f ( check )
f
deg +=10;
g
else
f
deg =10;
g
s e r v o 3 ( deg ) ;
lcdcursor(2,3);
l c d s t r i n g ( " The SPOTTER" ) ;
forward();
velocity(150,150);
v a l u e=s h a r p s e n s o r ( 1 , 5 , 1 1 ) ;
i f ( value >600)
f
buzzeron();
s e r v o 2 (180 deg ) ;
delayms(500);
buzzeroff();
delayms(2000);
servo1free();
servo2free();
g
g
34
4.2 Software Results
Figure 4.1: Image of pothole clicked by camera pod
The hardware developed sends the following data to the receiver system, connected to the
database administrator provided to the client. The receiver will create the respective database and
will insert the data to the map marker on the screen. The image of the pothole
Figure 4.2: Firebird 5 used for testing
could be viewed by just clicking on the view image button provided on the priority screen. This
tag provides the image of the pothole detected by the camera pod while detection. As shown in
the gure, the image is captured by the camera pod and detected by the software TV Home Media.
35
4.3 Screen Shots
Write Here explanation about the screenshots
Figure 4.3: User Registration
Figure 4.4: User Authentication
4.4 Testing Results
Software testing methods are traditionally divided into black box testing and white box testing.
These two approaches are used to describe the point of view that a test engineer
36
takes when designing test cases.
Table 4.1: Testing Results

Id Description Test Steps Test Type Expected Actual Op-
Output utput
T-101 Noti cation Read Ticket Unit testing Red color for Colors show-
about the Details the project ing status of
project start Carefully has not been the project
and end assigned dont change
yet Green properly
project
has been
completed
successfully
Yellow-
project in
progress
37
4.5 Test Case Report
38
4.6 Cost of the Project
39
Chapter 5
Conclusion
5.1 Summary
To gain the full bene t of both approaches, systems are required that can e ectively com-bine both
FPGAs and DSPs. With the addition of standard imaging functions written in either VHDL or C
all of the key building blocks are available for making an image processing system.Using the
DSP functions provided with the camera we can implement the hardware for the project.This
research has been an excellent learning experience in various engineering disciplines. The
Digital Signal Processing algorithms are now to be implemented in MAT-LAB so that the results
can be compared as well as simulations can be done for optimum performance. Various choices
for implementing the System have been studied. These choices were also compared to each other
on various criterions. We have speci ed the High level design choices of the Subsystems and justi
ed the corresponding selections. We did exper-iments on the platform called Firebird. We were
also able to characterize road condition into categories like smooth, moderately uneven and
highly uneven from the results of the experiments.
40
5.2 Future Scope
In future we propose to do more experiments with variety of the scenario. Our next and
immediate step is to use the Accelerometer on real vehicles and measure their response. Apply di
erent scenarios like potholes on the slopes, turns and see how the accelerome-ter readings can
characterize such condition. Along with that in remaining January and February we want to
come up with and formalize the alternate solution for the Localization subsystem. In next months
of March and April we perform simulations for given scenarios in Communication subsystem.
And we plan to come up with values for the related parameters. For example Loss in throughput
because of increase in number of vehicle, Loss in vehicle throughput because of the increase in
spee d. In the month of May and June we perform the more experiments regarding the
Localization system. If we are not able to come up with alternate solution; then we will perform
the experiments regarding integration of the rest of the system with GPS.
41
References
[1] John Crank. The mathematics of di usion. Oxford university press, 1979.
[2] Atul H Shintre and Shanta Sondur. Improved blocking expanding ring search (i-bers)
protocol for energy e cient routing in manet. In Recent Advances and Innovations in
Engineering (ICRAIE), 2014, pages 1{6. IEEE, 2014.
[3] CR Wylie and LC Barrett. Advanced engineering mathematics 6th edition. 1995.
42
Publications
Paper Published
43
Content Based Publisher/Subscriber Cloud Computing System
using Event Matching.
Mr. Vinod N. Alone , Prof. Sanjay B. Waykar,
Department of Computer Engineering, Department of Computer Engineering,
Sinhgad Institute,Lonavala , Sinhgad Institute,Lonavala , Pune.
Pune. sbwaykar@gmail.com
vinodalone4774@gmail.com
existing publish-subscribe system lead to low matching output

when we match a large number of subscription or interrupt
ABSTRACT dissemination when a large number of server gets failed.As we
are working with advent of cloud computing which requires
Due to increasing demand of data dissemination in large-scale
complex computing and robust communication, it provides us the
cloud-based software application where providing error-free,
best opportunity for this paper.
fast and reliable data we prefer to choose this topic for project
implementation. Today many social economic changes are
Hence we provide, a scalable and reliable event matching
impacting the real work scenario in the widespread
service (SREM) for content-based pub/sub systems in cloud
application like earthquake monitoring, natural disaster computing environment. To keep the routing latency low and
management, and social networking sites; one requires providing a robust link amongst all servers, we suggested a
scalable and reliable data. This leads me to take this topic to distributed dynamic overlay Skip Cloud to better organize the
do further research and implementation of the title. The server of SREM. To map the multiple subspace, we proposes
publish/subscribe (pub/sub) which is widely used for data hybrid space partitioning technique which ensures high
dissemination lead to low matching throughput when we matching throughput and certainly provides multiple
work on a large number of skewed subscription on cloud candidate servers for each
computing as well leads to many interrupt dissemination as a
server may get fail in large numbers.
Review of Literature
Hence we propose SREM, a scalable and reliable event Distributed Multidimensional Matching algorithm which is a
matching service for content-based pub/sub systems in cloud good algorithm to implement a pub/sub system over a
computing environment. To achieve low routing latency and Distributed Hash Table. In this we don‟t require any
reliable links among servers, we propose a distributed overlay centralized schema knowledge. We map the pub and sub into
SkipCloud to organize servers of SREM. A series of regions in a different dimensional space. Then this
dynamics maintenance mechanisms are extensively studied. multidimensional space is indexed with a distributed search
tree, which allows matching multiple publish/subscribe
attributes simultaneously. The multidimensional index gets
Keywords the advantage by storing subscriptions at multiple nodes so
Event Matching, Cloud Computing, Construction that it can achieve a bottom-up publication matching which
Overlay, space partitioning, Publish/subscribe will not allow root hotspots in the given index. It will also
lead to extends the traditional publish/subscribe signature
protocol; the matching algorithm highly supports publications
INTRODUCTION with different level of range values. The complexity of
Today making real-time decisions is very important to help subscriptions increases as the search tree grows. Two fault
the users to carry out their task, and hence data dissemination tolerance techniques, active failure detector, and period state
has become very important and critical in the large scale refreshing allow the algorithms to recover from any type of
emergency application like social networking, weather crash. Meghdoot implements a content-based publish/subscribe
Management and prediction, earthquake monitoring and system over a peer to peer based Distributed Hash Table to
many real-time natural disasters. improve scalability, based on CAN. P2P architecture offers the
freedom and flexibility of getting additional resources at any
Recently, data dissemination in these emergency applications time, thus providing performance scalability & reliability.
presents a number of fresh trends. One reasons for this the Meghdoot doesn't impose any restrictions on type of
rapid growth of the on-line live contents. For eg. Many social subscriptions and allows them to be specified in terms of range
sites like linked in, face-book, tweeter publishes large amount predicates over all attributes in a schema. Meghdoot uses the
of information contents per minutes as good as 100000 tweets semantics of the subscriptions and the events to store
averagely per minutes. For such a vast amount of information subscriptions and deliver matching events to them. Since real
publishing sudden disasters like earthquake or bad weather world datasets are not straight forward or we can say skewed,
may lead for failure of large number of users at one go and on most of the existing systems fail to distribute load among peers.
immediate basis. These characteristics require the data Meghdoot proposed and used the characteristics of the load and
dissemination system to be more robust, and scalable. On a used it very nicely and efficiently to distribute the load among
priority the system must be scalable to support a large amount various nodes on pub/sub module. Subscription load leads to zone
of live content. The key is to offer a scalable event matching splitting, while event propagation load leads to zone replication.
service to filter out irrelevant users. As the data size is To handle the fault tolerance, In Meghdoot subscriptions had
increasing day by day traditionally the publish-subscribe implemented very innovative and systematic way. As there are
model is most frequently used for data dissemination as always more publications than subscriptions it is not
pub/sub model has massive capacity to hold the data.But
when it comes to event matching services the
1
helpful to optimize the design of subscription state, which is done System Design
by Meghdoot. Scribe is channel/topic based publish/subscribe
system. The different mechanism of Pastry like fault-resilience,
locality, and scalability are used in scribe. The Pastry works on a SREM Design
mechanism which builds an efficient multicast tree. The groups
had been created by Scribe so that it can multicast them for To support large-scale users, we consider a cloud computing
balancing the load among the nodes who had participated. environment with a set of geographically distributed data
Pastry's properties enable Scribe to expressively use locality to centers through the Internet. Each datacenter contains a large
build an efficient multicast tree and to handle the decentralized number of servers (brokers), which are managed by a
order the group & join operations. As Scribe is channel based it datacenter management service such as Amazon EC2 or Open
has limited filtering capabilities. Hermes is a pub/sub system that Stack. All brokers in SREM as the front-end are low routing
is built over the Pastry DHT. Hermes uses special nodes which latency; these brokers are connected through a distributed
can be called as rendezvous nodes, which are set up through event overlay, called Skip Cloud. The entire content space is
type messages submitted prior to publishing. Herms use two types partitioned into disjoint subspaces, each of which is managed
of components event brokers and event clients. The broker‟s by a number of brokers. Subscriptions and events are
event implements all the functionality of the Herms and event dispatched to the subspaces that are overlapping with them
clients can be either publishers or subscribers in pub/sub model. through Skip Cloud. Subscriptions and events falling into the
Event brokers uses any type of services and event clients are same subspace are matched on the same broker. After the
always light weight. Herms supports two types of content-based matching process completes, events are broadcasted to the
routing: In type-based routing subscribers receives all the events. corresponding interested subscribers. The subscriptions
In type and attribute based routing allows subscribers to further generated by subscribers S1 and S2 are dispatched to broker
filter to the event type's attributes. In content based publish- B2 and B5, respectively. Upon receiving events from
subscribe system, Terpstra is built over the Chord DHT. Instead publishers, B2 and B5 will send matched events to S1 and S2,
of creating a single multicast tree from a root, it creates separate respectively.
multicast trees rooted at each broker and because of this it is able
to distribute node equally. This uses flooding of subscriptions to
create a multicast tree. Terpstra is built on top of a dynamic peer-
to-peer overlay network. Separate components in Terpstra ensure
that the network self-organises itself to maintain the topology and
can survive the simultaneous failure of up to half of its nodes.
The main disadvantage of Terpstra is its flooding mechanism
which may be drastic. Network coding, in which the intermediary
relay stations are allowed to perform encoding/decoding
operations on the information they receive. To perform the
multicast communication we prefer the Network coding
mechanism. If the intermediary nodes are allowed to perform
coding on the information they receive such as taking the EX-OR
Figure 2: An example of Skip Cloud with eight brokers and three
of two packets or other operations within the appropriate finite levels.
field, then we have a coding strategy. Network coding may
impact on the design of new networking and information Every broker is acknowledged by a binary string. All
dissemination protocols. datacenters due to the various skewed distributions of users‟
interests. The node failure may lead to unreliable and
inefficient routing among servers. To this end, it is organized
servers into Skip Cloud to reduce the routing latency in a
scalable and reliable manner. Such a framework offers a
System Architecture & Overview number of advantages for real-time and reliable data
dissemination. First, it allows the system to timely group
similar subscriptions into the same broker due to the high
bandwidth among brokers in the cloud computing
environment, such that the local searching Time can be
greatly reduced. Second, since each subspace is managed by
multiple brokers, this framework is fault-tolerant even if a
large number of brokers crash straightaway. Third, because
the data center management service provides scalable and
elastic servers, the system can be easily expanded to Internet-
scale.
SKIPCLOUD: Topology Construction

Skip Cloud systematizes all brokers into levels of clusters.
Figure 1: System Framework The clusters at each level of Skip Cloud can be treated as a
partition of the whole broker set. At the top level, brokers are
systematized into numerous clusters whose topologies are
complete graphs. Each cluster at this level is called top
cluster. It contains a leader broker which produces a unique b-
ary identifier with length of m using a hash function (e.g.
MD-5). This identifier is called Cluster ID. Individually, each
2
broker‟s identifier is a unique string and shares common Prefix Routing: Prefix routing in Skip Cloud is mainly used
prefix of length m with its Cluster ID. At this level, brokers in to efficiently route subscriptions and events to the top clusters.
the same cluster are accountable for the same content Note that the cluster identifiers at level i + 1 are generated by
subspaces, which provide numerous identical candidates for appending one b-ary to the corresponding clusters at level i. The
each event. relation of identifiers between clusters is the foundation of
routing to target clusters. Briefly, when receiving a routing
Since brokers in the same top cluster generate frequent
request to a specific cluster, a broker examines its neighbor lists
communication among themselves, such as updating of all levels and chooses the neighbor which shares the longest
subscriptions and dispatching events, they are organized into common prefix with the target Cluster ID as the next hop.
a complete graph to reach each other in one hop. After the top
clusters have been well organized, the clusters at the rest
The routing operation repeats until a broker can not find a
levels can be generated level by level. Precisely, each broker neighbor whose identifier is more closer than itself.
decides to join which cluster at every level.
Table 1: Skip Cloud Notations Algorithm 2 describes the prefix routing algorithm
in Pseudo-code.
Skip Cloud Notations ---------------------------------------------------------------------------
Algorithm 2. Prefix Routing
Nb The number of brokers in ---------------------------------------------------------------------------
Skip Cloud
1: l =commonPrefixLength(self.ID, event.ClusterID);
m The number of levels in 2: if (l== m) then
skip cloud 3: process (event);
4: else
Dc The average degree in 5.destB the broker whose identifier matches
each cluster of skip cloud event.ClusterID with the longest common prefix
from self.views.
Nc The number of top 6: lmax=commonPrefixLength(destB.
clusters in skip cloud identifier,event.ClusterID);
7: if (lmax <=l) then
8: destB the broker whose identifier is
Closest to event.ClusterID from view[l].
PROPOSED SYSTEM: 9: if (destB and myself is in the same cluster of Level
l) then
INNOVATIVE STRATEGIES 10: process (event);
11: forwardTo(destB, event);
HPARTITION: In order to take benefit of multiple
distributed brokers, SREM distributes the entire content space Use Case Diagram
among the top clusters of Skip Cloud, so that each top cluster
only switches a subset of the entire space and searches a small
number of candidate subscriptions. SREM employs a hybrid
multidimensional space partitioning technique, called HP
partition, to realize scalable and reliable event matching.
Generally speaking, HP partition divides the entire content space
into disjoint subspaces. Subscriptions and events with
overlapping subspaces are dispatched and matched on the same
top cluster of Skip Cloud .To keep workload balance among
servers; HP partition divides the hot spots into various cold spots
in an adaptive manner
-----------------------------------------------------------------------
Algorithm 1. Neighbor List Maintenance

-------------------------------------------------------------------------
Input: views: the neighbor lists.
m: the total number of levels in
SkipCloud. cycle: current cycle.
1: j =cycle %( m+1);
2: for each i in [0,m-1] do
3: update views[i] by the peer
sampling Service based on Cyclone.
4: for each i in [0, m-1] do
5: if views[i] contains empty slots then
6: fill these empty slots with other levels‟
Items who share common prefix of length
i With the Cluster ID of views[i]. Figure 3: Use Case Diagram
3
MODULES DESCRIPTION: tables, which are held in the router's memory. Most of the
We will be implementing following modules in the algorithms on routing uses only one network path at a time.
system through the methodology. Multi-path routing techniques enable the use of multiple
alternative paths to the user. Prefix routing in Skip Cloud is
mainly used to efficiently route subscriptions and events to
the top clusters. Note that the cluster identifiers at a level are
Datacenter / Broker creation: generated by appending one bare to the corresponding
clusters at level i. The relation of identifiers between clusters
In the first module, we develop the Datacenter creation and is the foundation of routing to target clusters. Briefly, when
Broker Creation. To support large-scale users, we consider a receiving a routing request to a specific cluster, a broker
cloud computing environment with a set of geographically examines its neighbor lists of all levels and chooses the
distributed data centers. Each datacenter contains a large neighbor which shares the longest common prefix with the
number of servers (brokers), which are managed by a data target Cluster ID as the next hop. The routing operation
center management service. Our approach is suitable for large repeats until a broker cannot find a neighbor whose identifier
and reasonably stable environments such as that of an is closer than itself.
enterprise or a data center, where reliable publication delivery
is desired in spite of failures. As future work, we would like
to exploit our scheme to allow for multipath load balancing Conclusion & Future Work
and support some of P/S optimization techniques such as In this paper, we have presented broker-less approach in the
subscription covering. It provides an abstract and high-level content-based publish-subscribe system for providing
interface for data producers (publishers) to publish messages authentication and confidentiality. The approach is extremely
and consumers (subscribers) to receive messages that match good for a number of subscribers and publishers in the system
their interest. and the number of keys maintained by them. The keys will be
in cipher-text format which is labeled with credentials
Clustering Method: assigned to publishers and subscribers.
This project introduces SREM, a scalable and reliable event
A cluster is a group of objects that belongs to the same class. matching service for content-based pub/sub systems in cloud
In other words, there are two cluster groups, one for similar computing environment. Scalable Routing and event
objects and other for dissimilar objects groups. Suppose we matching system connects the brokers through a distributed
are given a database of „n' objects and 'k' will be the partition overlay Skip- Cloud, which ensures reliable connectivity
of data in partition method. Each partition will represent a among brokers through its multi-level clusters and brings a
cluster and k ≤ n. It means that it will classify the data into k low routing latency through a prefix routing algorithm.
groups, which satisfy the following requirements: Through a hybrid multi-dimensional space partitioning
technique, SREM reaches scalable and balanced clustering of
Each group contains at least one object. high dimensional skewed subscriptions, and each & every
Each object must belong to exactly one group. event is allowed to be matched on any of its matching
candidate servers. Extensive experiments with real
deployment based on a Cloud-stack test bed are conducted,
producing results which demonstrate that Scalable Routing
Content Space Partitioning: and Event Matching is effective and practical, and also
presents good workload balance, scalability, and reliability
The content space is partitioned into disjoint subspaces, each
under various parameter settings.
of which is managed by a number of brokers. Then each top
cluster only handles a subset of the entire space and searches
a small number of candidate subscriptions. The whole content REFERENCES
space into non-overlapping zones based on the number of its
brokers. After that, the brokers in different cliques who are 1. Muhammad Adnan Tariq, Boris Koldehofe, and Kurt
Rothermel "Securing broker-less publish/subscribe systems
Responsible for similar zones are connected by a multicast using identity-based encryption"IEEE Transactions On
tree. Parallel And Distributed Systems, Vol. 25, No. 2, February
2015
Event Matching: 2. M. Ion, G. Russello, and B. Crispo, “Supporting
Publication and Subscription Confidentiality in Pub/Sub-
The data replication schemes are employed to ensure reliable Networks," Proc. Sixth Int'l ICST Conf. Security and Privacy
event matching. For instance, it advertises subscriptions to the in Comm. Networks (SecureComm), 2010
whole network. When receiving an event, each broker 3. L.I.W. Pesonen, D.M. Eyers, and J. Bacon, "Encryption-
determines to forward the event to the corresponding broker Enforced Access control in Dynamic Multidomain
according to its routing table. These approaches are publish/subscribe network", Proc. ACM Int'l Conf.
inadequate to achieve scalable event matching. Distributed Event-Based Systems (DEBS), 2007.
4. P. Pietzuch, "Hermes: A Scalable Event-Based
Routing Method: Middleware," Ph.D. dissertation, Univ. of Cambridge, Feb.
2004.
The routing process usually forwards the record on the basis 5. M. Srivatsa, L. Liu, and A. Iyengar, EventGuard: A System
of routing tables, where these tables maintain a record of the Architecture for Securing Publish-Subscribe Networks,”
routes to various destination of network. Hence, it is ACM Trans. Computer Systems, vol. 29, article 10,2011.
important for efficient routing; we need to construct routing
4
48
International Journal of Computer Applications (0975 – 8887)
Volume *– No.*, ___________ 2013
Offensive Protection in Android for RIG
Atul Chandrakant Jadhav Sunil P. Khachane

Department Of Computer Engineering Rajiv Gandhi Department Of Computer Engineering Rajiv
Institute Of Technology Mumbai, India Gandhi Institute Of Technology Mumbai, India
atulcjadhav@gmail.com sunil.khachane@mctrgit.ac.in
ABSTRACT runtime information gathering through common

Pilfering of sensitive data from apps is at all times measured communication channels (e.g., audio, Bluetooth) or open
to be one of the most precarious threats to Android arena. resources (e.g., memory, CPU usage). Delicate data could still
This can happen to the apps without palpable execution and be unprotected to the rogue app that constantly monitors the
implementation flaws, by molesting some design blemishes of decent app’s events and collects its runtime information from
the mobile operating system, e.g., common communication those public resources. Runtime information gathering
channels a rogue app needs to run side by side with the target posture severe threat to latest version of android systems and
app (such as phone book, Internet browser, Bluetooth control even to secrecy of its users[1].
service, messaging, dialer, IoT interface, etc.) to save its
runtime information. To dispose for protection from this new Runtime information gathering is an activity that comprise of
species of attacks, here is a research of a potent & advanced malevolently saving the data processed, produced, transferred
system which does not require any adjustment of principal or received by another app that does not mutually approves to
systems such as on operating system or existing applications. share its delicate or any other form of data during its
This system will be proactively protecting any app from any execution, in an effort to directly steal or indirectly conclude
category exist today in android arena. This new approach of delicate user information. Such an attack can chance by
protection, called Offensive Protection in Android from RIG molesting the permission the rogue app sanctioned by the
attacks, spoils a rogue app’s runtime monitoring encounter by user, e.g., a non-messaging app reading all inward and
suspending (ending & pausing) all alarmed background outward messages without user’s accord, recording phone
processes when the sincere app is running in the front, and dialogue by a non-dialer app [2], [3], which was approved
restoring the state of all alarmed background processes from RECORD_AUDIO permission at the time of install and
the state where they had paused after the sincere app finishes extracting subtle data such as transaction PIN or CVV no. [4].
execution entirely and its runtime environment is sterilized. Also, a Bluetooth activated medicinal device’s decent app can
The trial studies show that this new Offensive Protection is bounce out delicate & vital information [5]. A big
sovereign of OS version and works well with small impacts apprehension here is that even zero permission grants can still
on the ability of sincere apps and the routine of OS. Most gain greatly delicate & vital data from a variety of public or
essentially, the notion primary behind this approach, common channels, signifying the imperative vulnerability of
comprises providing security at the level of application, mobile systems in extrication of an app’s processes from its
defence at the level of common channel with no conciliation data. Examples can comprise Internet browsers give out web
to routine of the device because offense is the best defense. content and other delicate information detected by simply
reading the memory foot prints; phone’s accelerometer
Keywords coordinate values pilfered from public channel can reveal key
Mobile Security, Android Security, Offensive protection in strokes logged [6]. Case in fact comprises recording audio of
android, RIG Attack, Runtime Information Gathering. phone talks from the genuine phone app, gathering medical
history data to conclude the ailment condition of user, etc.
1. INTRODUCTION This runtime information gathering (RIG) threat is convincing
Android systems are enormously widespread because of and severe, as validated by earlier study and new discoveries,
masses of paid & free applications titled as apps. Apps are these malicious apps can read entire message threads, can
motive for huge spreading of android based mobile systems control Bluetooth data transmission, can read, alter and even
and nowadays become mandatory part of it with express spoof contact in the device (which can lead to a Social
development. Every now & then android market is engulfed Engineering attack through which device user can fall prey to
with newer apps from diverse categories with resolve to the name displayed but with attackers contact no. underneath,
provide facilities & services in fields such as Medical, and can misinterpret or overlook it as a trusted contact), can
Finance, Media, Education, Entertainment, Security, Banking, steal passwords and other credentials no matter if they are
etc. All of these apps desire to access, process and convey encrypted or plain format, can control IoT enabled devices
delicate information such as financial, personal, business which are connected by means of shared communication
related activities (e.g., investment secret, bank details, disease channel to handset, can disclose user location, can collect
and medical history, social media credentials, etc.) that needs phone call recordings and decipher pin from voice sample,
to be protected from illicit or rogue packages installed and etc.
residing on same device and running at concurrent time.
Android OS maintains security machinery for preventive apps In Android operating system applications are divided in front
from accessing each other’s data by providing sandboxing and background occurrences where any app can be stopped
atmosphere for apps execution and by providing unique and resume as per need of operating system. Offensive
process Id’s. This defense though is not adequate to protect Protection in Android from RIG takes advantage of this
1
Volume *– No.*, ___________ 2013
treatment given to applications by android systems. Offensive with suitable installation over millions of android devices
Protection in Android from RIG will also be sensibly across globe.
designed to select the true moments to start and end the
protection process, and efficiently defense itself against rogue Thus there is immense need to develop a security system
apps. The experimental studies show that this new Offensive capable to offensively defend known RIG attacks and provide
Protection in Android from RIG system is independent of OS secured environment for execution of target app and defend
version and works well with small influences on the efficacy user sensitive data from leaking through side & shared
of legitimate apps and also the performance of the OS is communication channels on the application level, without
affected marginally less. touching the OS or the target apps under protection, this
system will be called Offensive Protection in Android from
2. EXISTING SYSTEM RIG, that can be accessed from Google Play store and
Existing solutions for defying Runtime Information Gathering installed on any Android device to acquire immediate
attack needs a revision of either the Android Operating protection of user’s target apps by taking advantage of side
System or the unprotected applications which are at risk. channel information and detection of malicious apps with
Refining the access control mechanism in android system is suspending these malicious apps and avoid permission
also possible to dodge the risk of Runtime information exploitation granted at the time of install.
gathering but all of these approaches unenviably disturb the
system’s efficiency and usability and at the same stage are 4. CONTRIBUTION
time as well as resource consuming. Android provides In the aggressive world of information security, one must
security to each application by sandboxing its space which believe offence Is the best defence and applying the
delights each app exclusively and thus providing process philosophy “to catch a thief think like a thief” so in this
identification and file system access control. Each app is scenario of Runtime information gathering where side
treated as a user thus assigned a user ID (UID), in order to channels are exploited by misusing the permissions granted,
isolate them from each other. This keeps public and shared proposing here an offensive defense system called Offensive
resources out of the scope of this security mechanism causing Protection in Android from RIG where this system will detect
easy resource sharing such as Bluetooth, Internet connection, malicious apps by reading their shared channel data and other
audio, camera captures, etc. among multiple apps and users. logs representing their behaviour which is then stored and
Each app at the time of its installation must be granted a used for detection of these malicious apps. That means trying
permission to access these shared resources. There are Runtime information gathering (RIG Attack) on malicious
different protection levels [7] assigned to each permission, apps to see if they are involved in Runtime information
such as some permission are automatically granted to the apps gathering.
when prompted, some risky permissions need user’s consent,
and critical system permissions for system apps. Apps can Our system works in two different modes as workflow
access these shared resources only with a proper permission described and shown in Fig.1 & Fig.2 below. Our system can
granted. be started from any mode thus providing detection and
protection against unnecessary message reads by third party
There are some serious flaws in this security mechanism. apps or malicious apps.
Such as once a permission is granted then there is no control
of user or OS over how and when that permission grant is
utilized, For example, a non-messaging app with
MESSAGE_READ permission can access all messages as per
its will and wish, an app with CONTACT_READ and
INTERNET_CONNECT permission can transmit sensitive
contacts from phonebook, an app with AUDIO_RECORD
permission can catch all phone conversations and all of this
takes place without discrete knowledge of the user. Added to
this no protection provided to runtime information flow
between apps which can lead to a RIG attack. Rogue apps
running in the background can cause severe damage to
confidentiality of user and integrity of the system. When any
such specific RIG attack happens and identified then Google
& sometimes manufacturer of mobile handset come up with a
security patch which again does not possesses a huge scope of
success against the rest of the other types of RIG attacks.
Scope of application developers or android programmers
revisiting to develop patch for vulnerable app is too much
time consuming and technically impossible because no app
can override the permission grants given to any other app.
Fig 1: Detection Mode
3. PROBLEM DEFINITION
Android is ingenuous to endure the RIG menace. The
operational restrictions, such as public channels and shared
resources, expose it to abundant practices of runtime
information gathering, which resulting into the disclosure of
intense user information. This vulnerability is genuine,
persistent and severe, thus only new methodologies or
techniques can possibly tackle and provide actual solution
2
Volume *– No.*, ___________ 2013
in Table.1, and results of killing or pausing non sysyetm

messaging app is given below in Fig.3. Apps with more than
8 score were found to be killed or paused for more that 85%
on android device running more than 10 different applications
simultaneously.
Fig 3: Performance Measure for messaging service
4.2 Second Attack Vector

Second attack vector is also tried and tested. In this attack
vector another area in mobile systems which deals with the
contact details information called as Phone Book. The contact
details in the mobile device are very sensitive and should be
considered utmost private property of the mobile user.
Contact information is second most favourite thing in RIG
Fig 2: Protection Mode attacks that are besieged by malicious apps around the globe
where malicious app attempts to access, update, transfer &
wipe out partial or entire contact list without mobile user’s
consent in the runtime. Android operating system provides a
4.1 First Attack Vector permission grant control for protection of phone book
First attack vector is on messaging service where situation is information such as READ_CONTACT &
worst and even neglected by users & developers because WRITE_CONTACT but once these permissions are granted
READ_SMS permission is granted for more than 70% (i.e. then application is allowed to modify and play with phone
more than 2 million) of apps on Google play store. Whereas book information at its will. Because RW_CONTACT
95% out of these apps need not to read more than 1% of permission is granted for more than 82% (i.e. more than 2.4
messages out of message book during its entire lifecycle of million) of apps on Google play store. Whereas 98% out of
existence (i.e. between install till uninstall of that app) and these apps need not to read more than 2% of contacts out of
that too for reading verification code sent over message for 2- phone book during its entire lifecycle of existence (i.e.
way authentication. But with this READ_SMS permission all between install till uninstall of that app) and that too for
of these apps can read complete message book from user’s informing user about any contact in phone book is using this
device, where every user have one system message app for social networking or automatic service utilization. But
management app who reads 100% of messages all the time. with this RW_CONTACT permission all of these apps can
Thus absolutely no need of granting READ_SMS permissions read complete phone book from user’s device, where every
for any other apps. user have one system (default) phone book management app
who need to read 100% of contacts all the time. Thus
Table 1. Sampling results for messaging service
absolutely no need of granting RW_CONTACT permissions
App Kill/Pause% oom_score_adj Effective for any other apps.
Facebook 87 9 Yes
Table 2. Sampling results for Phonebook service
Google play 72 6 Yes
Imo 85 8 Yes App Kill/Pause% oom_score_adj Effective
Olacabs 91 9 Yes Facebook 85 8 Yes
Quickr 93 9 Yes Google play 90 9 Yes
Truecaller 88 8 Yes Imo 68 6 Yes
Twitter 95 8 Yes LinkedIn 83 7 Yes
Uber 94 9 Yes CiscoWebex 87 7 Yes
Kotak bank 69 5 Yes Truecaller 94 9 Yes
Amazon 89 9 Yes Twitter 75 7 Yes
Uber 81 8 Yes
Performance measurement is done against applications which are Kotak bank 62 4 Yes
not system’s default messaging apps but still aquired Amazon 94 9 Yes
READ_SMS permission at the time of install and tries to expose
user information recived or sent in the messaging service. The
performance of Our system is examined by sampling 100 to 200
attempts for each of the application listed
3
Volume *– No.*, ___________ 2013
Performance measurement is done against applications which 6. CONCLUSIONS

are not system’s default phone book management apps but
In Offensive Protection in Android from RIG a function is
still aquired RW_CONTACT permission at the time of install
introduced which exploit the runtime information, system
and tries to expose or misuse user information stored in phone
logs, and other related behavioral information ( such as no. of
book service. The performance of Our system is examined by
threads present, CPU usage when running in background,
sampling 100 to 200 attempts for each of the application
source of installation, category it belongs, etc.) of malicious
listed in Table.2, and results of killing or pausing non default
apps for killing or pausing them and avoid sensitive user
phone book management app is given below in Fig.4. Apps
information from malicious access. Concentrating on two
with more than 7 score were found to be killed or paused for
vectors type of RIG attack that is illegal message read &
more that 80% on android device running more than 10
exploitable Phone book access, it is examined that Our system
different applications simultaneously.
is found efficient against different category of apps who are
not message management apps or default system message
apps in case of first attack vector and default phone book
management apps in case of second attack vector but still
posing threat for stealing information in message system &
contact information in phone book of device. This approach
can be further extended to study and mitigate other types of
RIG attacks such as contact spoofing, phone call recordings,
Shared channel information stealing, etc.
7. REFERENCES
[1] Nan Zhang, Kan Yuan, Muhammad Naveed, Xiaoyong
Zhou and XiaoFeng Wang, “Leave Me Alone: App-level
Protection Against Runtime Information Gathering on
Fig 4: Performance Measure for Phonebook service Android” in IEEE Symposium on Security and Privacy,
2015. [Online]. Available:
http://ieeexplore.ieee.org/document/7163068/
5. EXPERIMENTAL RESULTS [2] X. Zhou, S. Demetriou, D. He, M. Naveed, X. Pan, X.
Wang, C. A. Gunter, and K. Nahrstedt, “Identity,
location, disease and more: Inferring your secrets from
android public resources,” in Proceedings of 20th ACM
Conference on Computer and Communications Security
(CCS), Nov. 2013. [Online]. Available:
http://www.cs.indiana.edu/∼zhou/files/fp045-zhou.pdf
[3] S. Jana and V. Shmatikov, “Memento: Learning secrets

from process footprints,” in Proceedings of the 2012
IEEE Symposium on Security and Privacy, ser. SP ’12.
Washington, DC, USA: IEEE Computer Society, 2012,
pp. 143–157. [Online]. Available:
http://dx.doi.org/10.1109/SP.2012.19
[4] R. Schlegel, K. Zhang, X. yong Zhou, M. Intwala, A.
Kapadia, and X. Wang, “Soundcomber: A stealthy and
context-aware sound trojan for smartphones.” in NDSS.
The Internet Society, 2011. [Online]. Available:
Fig 5: Testing Attack vector for messaging service http://dblp.uni-
trier.de/db/conf/ndss/ndss2011.html#SchlegelZZIKW11
[5] M. Naveed, X. Zhou, S. Demetriou, X. Wang, and C. A.
Gunter, “Inside job: Understanding and mitigating the
threat of external device misbonding on android,” 2014.
[6] L. Cai and H. Chen, “Touchlogger: inferring keystrokes
on touch screen from smartphone motion,” in
Proceedings of the 6th USENIX conference on Hot
topics in security, ser. HotSec’11. Berkeley, CA, USA:
USENIX Association, 2011, pp. 9–9. [Online].
Available:
http://dl.acm.org/citation.cfm?id=2028040.2028049
[7] “Android permission,”
http://developer.android.com/guide/topics/
manifest/permission-element.html/, 2014.
Fig 6: Detection of attack vector by our system

In our experimental results we have able to detect the attack
vector developed for testing shown in Fig.5 and prompted
user for its subsequent removal as shown in Fig.6 above.

3D Point Plotting Robot For Evacuation

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3D Point Plotting Robot For Evacuation

Uploaded by

Copyright:

Available Formats

3D POINT PLOTTING ROBOT

Submitted to University of Mumbai in partial ful llment of the

GAIKWAD KIRAN SUBHASH

DEPARTMENT OF COMPUTER ENGINEERING

Submitted to University of Mumbai in partial ful llment of the

DEPARTMENT OF COMPUTER ENGINEERING

GAIKWAD KIRAN SUBHASH

GHATMALE PRERANA RAVINDRA

KHOPADE NIKITA BHIMRAO

JADHAV RAHUL ASHOK

Prof. VINOD N ALONE

Department of Computer Engineering

PROJECT APPROVAL CERTIFICATE

GAIKWAD KIRAN SUBHASH

GHATMALE PRERANA RAVINDRA

KHOPADE NIKITA BHIMRAO

JADHAV RAHUL ASHOK

Internal Examiner External Examiner

Project Convener Head of Department

innate humility to Mr.Vinod N. Alone, Assistant Professor, Computer Department, PVPPCOE

and guide of our project for providing help whenever required.

List of Figures iii

1.3 Motivation for the Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Design and Implementation 9

3.7 Feasibility Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Results and Discussion 18

4.2 Software Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1 Fire Bird V ATMEGA2560 robot block diagram . . . . . . . . . . . . . . . . 11

3.3 Atmel Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.9 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Image of pothole clicked by camera pod . . . . . . . . . . . . . . . . . . . . . 35

3.1 Sharp IR Range sensors coverage . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Testing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

1.2 Aim and Objectives

1.3 Motivation for the Work

1.4 Scope of Project

1.6 Organization of the report

sort it out as per the priority of the treatment.

2.3 Need of New System

2.4 Problem Definition

responsible for storing the information about potholes in its vicinity,

Design and Implementation

3.1 Proposed System

which would be useful to get the statistical data

3.2 Requirement Gathering and Analysis

3.2.1 Hardware Requirement

makes Fire Bird V robots very versatile.

 Sharp IR Range Sensors

3.2.2 Software Requirement

compilation, errors, HEX le size and other warning messages etc.

 AVR Boot Loader

microcontroller. If Bootloader rmware is loaded on the microcontroller,

3.3.1 All UML Diagrams

Figure 3.5: Class Diagram

Write here explanation about the your sequence diagram in 2 to 3 lines

Figure 3.7: Activity Diagram

1. Initialise all the ports and LCD device to reset state.

2. Move the bot in forward direction, forward();

3. Move the bot with constant velocity(150,150);

5. Constantly check for the value of Sharp IR Sensor

9. Send both the data to server.

3.5 Timeline Chart