i

T h e   A m e r i c a n   U n i v e r s i t y   i n   C a i r o  

Proposal  Document  Ahmed  ElHussiny,  Mohamed  ElShaer,  Omar  Abdelwahed,  Omar  ElSafty,  and  Nada  Hazem  Advised  by  Dr.  Mohamed  Shaalan  -­‐  Coordinated  by  Dr.  Ahmed  Rafea    

Spring  15  

08 Fall  

i

Table  of  Contents  

INTRODUCTION .................................................................................................................... 1  BACKGROUND ........................................................................................................................ 1  PROBLEM DEFINITION ............................................................................................................ 2  MOTIVATION .......................................................................................................................... 3  THESIS STATEMENT ................................................................................................................ 3  DOCUMENT LAYOUT .............................................................................................................. 4  

RELATED WORK ................................................................................................................... 5  ROAD ANOMALY DETECTION ................................................................................................ 5  

Reporting-Based Solutions ................................................................................................ 5  Sensor-Based Solutions ...................................................................................................... 6  

TRAFFIC ANALYSIS ................................................................................................................ 7  INTERFACING WITH THE CAR ................................................................................................. 8  

PROPOSED APPROACH ....................................................................................................... 9  STEPS REQUIRED .................................................................................................................... 9  

Goal 1: The Completion of the Cloud System .................................................................... 9  Goal 2: The Operability of the GIV Box ............................................................................ 9  Goal 3: The Release of the Mobile Applications ............................................................... 9  

DATA GATHERED ................................................................................................................... 9  TOOLS USED ......................................................................................................................... 10  EXPERIMENTS CONDUCTED ................................................................................................. 10  

SYSTEM DESIGN ISSUES ................................................................................................... 11  REPORTING-BASED DESIGNS ............................................................................................... 11  SMARTPHONE-BASED DESIGNS ........................................................................................... 11  DEDICATED HARDWARE DESIGNS ....................................................................................... 11  OUR DESIGN AND FINER DETAILS ....................................................................................... 11  

EXPECTED OUTCOMES .................................................................................................... 13  SOCIETAL IMPACT AND PRODUCT PROFIT .............................................................. 14  

THE SOCIETAL IMPACT OF POTHOLE DETECTION ................................................................ 14  THE SOCIETAL IMPACT OF TRAFFIC ANALYSIS ................................................................... 14  THE SOCIETAL IMPACT OF INTERFACING WITH THE CAR .................................................... 15  PRODUCT PROFIT .................................................................................................................. 15  

KNOWLEDGE, TECHNOLOGY, AND SKILLS NEEDED ............................................ 16  KNOWLEDGE NEEDED .......................................................................................................... 16  

Knowledge Needed for GIV Box Development and Implementation ............................... 16  Knowledge Needed for Cloud System Development and Implementation ....................... 16  Knowledge Needed for Mobile Application Development and Implementation .............. 16  

TECHNOLOGY ....................................................................................................................... 16  Technology Needed for GIV Box Development and Implementation .............................. 16  Technology Needed for Cloud System Development and Implementation ...................... 16  Technology Needed for Mobile Application Development and Implementation ............. 17  

SKILLS .................................................................................................................................. 17  Skills Needed for GIV Box Development and Implementation ........................................ 17  Skills Needed for Cloud System Development and Implementation ................................ 17  Skills Needed for Mobile Application Development and Implementation ....................... 17  

WORK PLAN ......................................................................................................................... 18  CONCLUDING REMARKS ................................................................................................. 20  

ii

REFERENCES ....................................................................................................................... 21  

1

Introduction  We have decided to focus our efforts on a new project intended to help the Egyptian community with one of the most common problems it faces daily: cars. 3arabeety attempts to resolve the most common issues faced with cars in Egypt: collision with potholes, ditches, and speed bumps due to a lack of proper warning or lighting, spending hours stuck in traffic with seemingly no way out, and not knowing if there is a problem with the car that is causing it to underperform and/or waste gas.

Background  Our project will combine a host of different areas to provide different the sets of features it provides. In order to build the dedicated hardware, we will need to rely on embedded systems. The data collected from the hardware will be coming to the servers so fast and so much that elements of big data and big data analytics have to be involved. When the data reaches our servers, we will rely on cloud computing to convert this raw data into usable information for the mobile applications. We will also build mobile applications to display the information on the server. An embedded system is a computer system with a dedicated function. What this means is that the components are usually highly customized for the function that they are to be used for, have a lower power consumption, are incredibly small, and are fairly inexpensive. They do, however, have their disadvantages. They are difficult to program, difficult to interface with, and have extremely limited processing power. Modern embedded systems are based on Microcontrollers, which are chips that are central processing units with embedded memory and peripheral interfaces. We plan on relying on a customized embedded system when it comes to the mass production stage of 3arabeety. In order for us to complete the prototype, however, we will instead rely on the Raspberry Pi microcomputer, instead of going through the difficulty of creating our own specific chips. Big Data are data sets that are too large and complex to manipulate or interrogate with standard methods or tools. In addition to Big Data being large in size and complexity, it can also be very large in speed, for example containing the data collected second-by-second from sensors, or tracking a user’s eye movements, etc. Due to the large size and fast speed of the data that will be coming from our dedicated hardware to our servers, it is certainly an element of big data. Its processing can rely on big data analytics. The one common type of tool that will always be necessary in a system with big data is the advanced analytics set of tools, powered by a Hadoop Distributed File System Platform. These tools are the ones that will be able to process the very large amounts of data being generated, and to start to create a comprehensive set of statistical data about the system data that help an application make sense of the system data. We will use this generated sensible information to develop predictions and reliable information about the existence of ditches, potholes, and speed bumps, and also for the analysis and understanding of traffic patterns. This will be done on the cloud. Cloud computing is the usage of shared network resources and computers to be able to perform complex functionalities. It is the ability to scale, as necessary, for the addition of increased resources dedicated to performing the necessary computations. In our case, we will be relying on the server itself to process, analyze, and generate sensible information from the raw data that is being provided to it. We will need to build interfacing APIs to interact with the servers.

2

An Application Programming Interface is a set of functionalities that are provided to external systems to use within the system providing the features. This can be done either through the provision of libraries or web services through which other applications can interact with the provisioning application. The APIs that we will build will allow the dedicated hardware to modify the database through the addition of potholes and adding traffic analysis patterns to the processing queue of the cloud computing services. They will also allow the mobile applications to be able to interact with the server to be able to read the information contained in the databases. A mobile application is a simple computer program designed to run on smartphones, tablets, and other mobile devices. With over 97% of the market controlled by Google’s Android and Apple’s iOS, it is safe to assume that for an application to succeed, it is sufficient for it to exist on these two platforms. Development for Android is done by the Java Programming language on the Integrated Development Environment called Eclipse with the Android Development Toolkit. Development for Apple is done by the Swift Programming language on the Integrated Development Environment called XCode with the iOS APIs. Another important aspect of the success of mobile applications is whether or not it is built with an attractive, engaging Graphical User Interface (GUI) which creates an overall beautiful User Experience. Apps that have a successful user interface but reduced functionalities than an app with much more extensive functionalities and failed user interfaces are more likely to succeed. For this reason, we will rely on Google’s Material Design Methodology in the design of the Android application and Apple’s Flat Design Methodology in the design of the iOS application in order to guarantee a consistent, uniform user experience to which the user is already accustomed.

Problem  Definition  Picture this: driving in Cairo. That is not a very beautiful mental image you get, is it? One of the most common issues plaguing the Egyptian roads right now is the poor condition of most roads. It seems like one cannot drive simply without having the car bounce all over the place. It is slightly disturbing that one of Egypt’s newest cities, New Cairo, has extremely few well-paved roads. This poor condition of the roads in Egypt leads to a large number of accidents that end up hurting the car, the driver, or both. What this means is that average Egyptian drivers have to dedicate a part of their income, which is not that high to begin with on average, to fix their cars due to the condition of the roads. The reason for this that the drivers collide with these potholes, speed bumps, and ditches without forewarning. The signs that warn before a speed bump or speed bumps that are painted different colors to be more obvious to the drivers in the dark are extremely few. More often than not, there is no warning for a driver of an approaching obstacle other than the sound of her hitting that obstacle. This is clearly a safety concern. For this reason, the World Health Organization (WHO) created its RS10 (Road Safety in 10 Countries) project [22]. In it, they selected 10 less economically developed countries that are responsible for over 48% of traffic fatalities in the world. Egypt is one of those countries. What the program aims to do is “reduce deaths and serious injury on roads in low and middle income countries.” Clearly, one of the main contributing factors to the fact that Egypt needed to be included in this collection is the poor condition of the roads encouraging the existence of traffic accidents. Another extremely horrible problem with driving in Egypt is being stuck in traffic for hours. Due to the poor conditions of the road, poor driving decisions on the part of the

3

drivers, and unwise planning of the layout and density of the roads, Egyptians have to suffer an average of 60% of their time completely stopped in traffic [23]. A recent study on the traffic congestion in Cairo done by the World Bank [24] found that about 2.2 Billion Hours were wasted in traffic in 2010, that over 1.9 Billion liters of gas were wasted, completely stopped, and that 7.1 Billion Kilograms of Carbon Dioxide were released in the air in traffic. All in all, traffic was found to cost Egyptians 47.7 Billion Egyptian Pounds a year, clearly a very serious expenditure, especially to a less economically developed nation.

Motivation  As can be clearly understood from the Problem Definition section above, there are two main problems that we are attempting to tackle: pothole detection and traffic analysis. The reason we are tackling pothole detection is due to the very serious problem that it is. It affects a lot of lives on a daily basis whether or not drivers are able to foresee the existence of a road anomaly before they collide with it. Speeding cars, on colliding with a speed bump or pothole, can flip leading to serious injury or death. In the best case, the one where the driver isn’t hurt or causes damages to surrounding vehicles, pedestrians, or both, the vehicle itself is damaged. Therefore by warning the user ahead of time that a collision is about to happen, we are ensuring the user’s safety as well as maintaining the car free of damage. In addition to that, the traffic presents a very large problem for Egypt. As previously mentioned, the traffic is hurting Egypt’s people, economy, and environment. For this reason, we deem it as crucial to solve this problem in order to ensure that the Egyptian economy, people, and environment are maintained and well protected. Honestly, the idea for this project resulted from our own poor experiences with driving in Egypt. Our motivation is slightly selfish: to come up with a way for us to navigate the roads of Egypt without damaging our cars and without staying stuck in traffic for hours. Although the idea started as a selfish endeavour, it has grown to a system that users all over Egypt can employ and use to their benefit to have the same set of features that we selfishly deemed only our own. We hope that this solution will bring about an improvement in the Egyptian driving conditions.

Thesis  Statement  The objectives of this thesis are simple. We hope to build a system called 3arabeety that relies on dedicated hardware installed in the car to collect information about the car, about traffic, and about potholes and speed bumps and store them all in an online repository accessible by a mobile application that allows its users to turn it on as they drive. As the users approach an area where a pothole is detected, they are immediately warned to ensure that they do not collide with the pothole. In addition to that, the 3arabeety mobile application will also have a map of the immediate area of each driver with the roads highlighted in different colors respective of their current traffic status. The 3arabeety mobile application should also be able to interface with the car via the OBD-II interface to provide useful information about the car. Therefore in order for us to complete this thesis, we should have:

• The dedicated hardware deployed in the car functional and transmitting to the servers

• The servers ready for transmissions and processes the signals received from the hardware to create warning regions around potholes

4

• The servers analysing the transmissions received from the hardware to better understand the status of traffic in the different streets of Egypt

• Android and iOS mobile applications that are capable of relaying and displaying the data on the server, in regards to the status of traffic conditions on the road, as well as the provide warnings of the different potholes upon entry of the immediate area of one. In addition to that, these mobile applications must also be able to interface with the car to provide sensible information of error codes provided by the car’s OBD-II interface and, in the future, other useful information about the car.

Document  Layout  This document is separated into ten main sections:

1. Introduction: This section provides a basic overview of the computing areas in which the project lies, what the problem this thesis is attempting to solve is, why we are attempting to solve this problem, and what we hope to create to be able to solve this problem. In addition to that, this section also provides metadata about the document, as to the layout of the document and where to find pieces of content readers may be looking for.

2. Related Work: This section provides an understanding of similar work that has been done in the past, and other solutions and approaches to solving the same problem that we are attempting to solve. It also classifies the solutions based on the different approaches that they relied on to solve the problem.

3. Proposed Approach: In this section, we describe how we are going to build our system. We describe the steps that we are going to follow, the data we are going to gather, the tools we are going to use, and the experiments we are going to conduct. This section basically provides an overview of the entire design of the system.

4. System Design Issues: In this section, we describe the rationale for selecting the approach that we did in the Proposed Approach section. We also describe other possible ways that we could have relied on to build the system and why we did not choose them.

5. Expected Outcomes: This section provides a more detailed insight into what we expect to be the deliverables of this thesis. In it, we provide a description of how we perceive the result of the thesis as a product.

6. Societal Impact: This section describes how this thesis affects the society in which it is deployed: Egypt. We also discuss how this thesis will generate profit, and how it will pay off its costs.

7. Knowledge, Technology, and Skills Needed: This section provides a brief overview of the knowledge that we are going to need to have to complete this thesis, the technology we are going to rely on, and the skills that we are going to use to finalize 3arabeety.

8. Work Plan: This section attempts to break down the grander set of steps and objectives established in the Proposed Approach section into smaller tasks and provide a timeframe for the completion of each task.

9. Concluding Remarks: This section concludes our discussion of 3arabeety as a proposal, summing up the most important points in its body, and referencing the societal impact of utilizing 3arabeety.

10. References: This section includes references, formatted in the IEEE style, to other works that have helped us complete our work.

 

5

Related  Work  Because the degradation of road quality over time is a universal problem, so is the problem of having potholes and ditches in the road. In addition to that, more often that not, in Egypt, we are faced with the problem of speedbumps that do not have a warning sign before them. It would be extremely inefficient and costly for government organizations to send out teams to scan every road for every road anomaly for every day of the year. For this reason, it becomes sensible for us to rely on the large number of drivers that use these roads every day. In addition to that, traffic is also an extremely common problem. Because these are such widespread problems, there have been prior instances of attempting to solve them in different cities of the world with a number of different approaches. In this section, we attempt to classify those approaches and provide some insight as to how the different solutions tackled the problems and attempted to solve them. In the next section, we are going to explain how our solution is different in their approach of tackling the problems.

Road  Anomaly  Detection  

Reporting-­‐Based  Solutions  In the past, applications have been developed focused on collecting information from users that would help improve the cities that they reside in. These applications were usually created and sponsored by the government of the city or the municipality of the area that it is governing. Part of the areas that those applications focused on was the existence of potholes in the road in order for the government to maintain them. An example for such functionality is "Find It, Fix It,” created for the city of Seattle, Washington [1]. This application relied on users to provide reports from within the application of problems in the city. These problems included, but were not limited to, potholes, graffiti, and abandoned vehicles. These reports were then directed to the appropriate department to be processed. One major problem with such an implementation is that it is not helpful to the end user. Another user accessing the application is not aware of a previously reported problem and is therefore ignorant about problems existent in the city. For this reason, another approach was created, one that relies on users informing one other of existent problems in their city. Examples of applications relying on this approach are Hofrah [2] intended for the Middle East, and Potholes Hunter [3] intended for Hungary. The main problem with those applications is that, although they inform the user, there is no direct connection between the application and the government. Therefore, the application is useful to the communities of users that use them, but they do not assist in the improvement of the condition of the road itself. In order to merge the two approaches and therefore provide a solution that is both beneficial to the users and informative to the government of necessary actions, applications such as Citizens Connect [4] intended for the city of Boston, Massachusetts, were created. It is important here to note that the development of such an application is difficult, as it requires a great coordination between the sectors of government responsible for reported problems and the actual reported problem. For this reason, the government has to sponsor such an application and promote its use for the users. This approach, although seemingly the best one, leaves it with the problems associated with reporting, in general. It is important to note that in order for the user to report the exact location of a street anomaly, she would have to do it while driving.

6

This means that the drivers has to take her eyes off the road to report the problem. Also, another important note is that a lot of users do not want to expend the effort of taking their phone out of their pockets, filling out the report form, and submitting it. For this reason, there have been many applications that failed because they relied on user-generated content. This is why an approach not relying on user reporting was created.

Sensor-­‐Based  Solutions  Instead of having the user directly interact with the application and create the report, approaches have been created where the application automatically generates the report for the user, relying on the sensors embedded in hardware in the car. It is important to note here that this hardware can either be a dedicated solution for the tasks associated with it, or instead rely on the hardware already existent in users’ smartphones. Another important note to make is that these applications need to provide the added functionality of filtering between normal speed bumps and other road anomalies as, in their respective cities, signs are placed before speed bumps that warn the users. Therefore, their recording is necessary neither to the user nor to the government.

Smartphone  Solutions  Smartphone solutions, although easier for the user, involve a very large element of machine learning, especially if we come to consider the fact that most of these applications are also trying to filter potholes from planned speed bumps. There is also a large element of loss of accuracy when it comes to either the user using her phone while the sensors are recording or changing the orientation of the phone as it is recording, affecting the accelerometer’s signals. The Boston government, very interested in the topic of pothole detection, created an improvement for the Citizens Connect application called Street Bump [5]. The way Speed Bump works relies on the user informing the smartphone when she is about to start a trip and when the trip is over. By leaving the smartphone securely mounted in a cradle for it, the smartphone is able to detect and record road anomalies. One of the main problems with this approach is that when the user picks up her smartphone, it is detected as a road anomaly, whether or not an anomaly exists. In addition to that, accelerometers in Android phones vary widely. For this reason, this creates problems with accuracy in Speed Bump. Another big problem with the application is that it is very battery intensive, meaning that users may not want to rely on the application for a large period of time to be able to use their phones later. Solutions that are more robust to user interaction have only, unfortunately, been restricted to the research phase. Projects such as Microsoft’s Nericell [6] and the Indian Institute of Technology’s Wolverine [7] have attempted to avert the erroneous data collected through user interaction by simply turning off the sensors when the user is using the phone. This is detected through unlocking the phone, tapping on the screen, or starting and ending a call. They are also more energy efficient. Unfortunately, these ideas remain in the research phase only.

Dedicated  Hardware  Solutions  Although dedicated hardware may be more costly, it provides a more accurate, more robust solution. It also is not as affected by erroneous data as there is no reason to interact with the dedicated hardware. Also, the dedicated hardware can rely on the car’s ignition to recognize when a trip is happening instead of relying on the user to inform the application when a trip is happening. This approach is not favoured as it

7

relies on the purchase of additional components and, therefore, increases the financial expenditure of the project. An example of an application that uses this approach is MIT’s Pothole Patrol [8]. Pothole Patrol relied on dedicated hardware composed of a GPS sensor, and a three-axis accelerometer connected to a Wi-Fi-enabled computer placed in 7 taxis in Boston. The use of dedicated hardware highly improved the accuracy of the solution to a whopping 99.8% over nearly ten thousand kilometres.

Figure  1:  Architecture  of  Pothole  Patrol  Detection  System  

As we can see from the above figure, Pothole Patrol relied on the sensors to create the pothole detector which then added the potholes in a database and relied on clustering to filter out erroneous data.

Traffic  Analysis  The issue of traffic analysis is also an extremely important one that has been tackled before. There are very popular solutions on both the national and international levels that attempt to tackle the problem of traffic analysis and providing the user with the information they need to navigate through the less crowded roads. One such example of an internationally popular traffic analysis application is Waze [9]. Waze, available in 56 countries, and used by Google’s own Traffic APIs, relies entirely on reporting. What this means is that the user, stuck in traffic or not, has to interact with the phone and fill out a form reporting on the status of the road. This creates the need for the user to be interacting with the phone as she drives, an element of great risk. Nationally popular applications, such as Bey2ollak [10] and Wasalny [11], also rely on the same concept of reporting, a simply inefficient way of receiving the necessary information. Another approach developed to handle this problem is one that is used by Google Traffic and Here [12]. Instead of relying on reports received by users, Google Traffic and Here rely on their own cars deployed in specific countries that report back to them. There are two obvious drawbacks to this solution: one is the need to have your own cars in the country you are testing at. The other drawback is that these cars cannot be in all of the streets at once. What this does is create a large information gap when it comes to the status of traffic at a certain time of day on certain streets. For this reason a novel approach is necessary when it comes to Traffic Analysis that avoids the aforementioned drawbacks.

8

Interfacing  with  the  Car  Connecting a Raspberry Pi computer to a car through the On-Board Diagnostics (OBD-II) port is no novel idea. Examples such as Carberry [13] and OBD-PI [14] exist. All of the available solutions, however, only display the information provided by the OBD-II. The most complex of these systems provides information on how to improve fuel economy. As of now, there is no solution that leverages this raw data for a higher purpose, involving machine learning to create sensible information.

9

Proposed  Approach  

Steps  Required  As this system can be broken down into three subsystems, we can also divide the steps into their respective goals. For this reason, we are dividing the steps below into three subsections based on the goals that they are trying to accomplish: the completion of the cloud system, the operability of the GIV box, and the release of the mobile applications.

Goal  1:  The  Completion  of  the  Cloud  System  First, we are going to need to reserve the necessary servers for the cloud system on Amazon Web Services where we will host the database and the logic conducted on the servers. Following this reservation, we will need to build the database and the APIs that allow the GIV box and the mobile application to communicate with the servers. We are also going to need to build the procedural logic and necessary algorithms to convert the incoming raw data from the GIV box to readily accessible information to the mobile application.

Goal  2:  The  Operability  of  the  GIV  Box  In order for the GIV Box to be operable, we will first need to research the necessary components. From our preliminary research, we found out that the following sensors and hardware components are needed to complete the functionalities required:

• Raspberry Pi [15], • OBD-II Bluetooth Adapter [16], • USB Bluetooth 4.0 Micro Adapter, • 3G/GPRS + GPS Shield for Raspberry Pi [17], • BerryIMU Sensor [18].

Following purchasing the necessary components, we will design the circuit combining them to complete the GIV Box. Afterwards, we will program the GIV box to capture the data from the sensors and accordingly send them to the cloud system to be processed.

Goal  3:  The  Release  of  the  Mobile  Applications  The mobile application is a crucial subsystem of our product as it acts as the medium through which the user is notified of upcoming road anomalies detected by the sensors and processed by the web servers. For this reason, we will design the GUI for the application to be both engaging and interactive. Following this, we will create the underlying functionality and interfacing with the web servers for the provision of the necessary information from the servers. Finally, we will undergo a process of testing and fine-tuning the application based on the gathered data.

Data  Gathered  The GIV box is the only subsystem that will be gathering data in 3arabeety. It will focus its data gathering to a set of measurements sent periodically to the server:

• Orientation of the car using the BerryIMU sensor, • Location using GPS sensor, • Speed and vehicle status using OBD-II.

This gathered data will be used to train the system in order for it, after processing this data, to alert the driver of upcoming road anomalies. It will also provide the system

10

with the necessary data to be able to dynamically change the style of the roads on the map to reflect the status of traffic in the given road.

Tools  Used  In order for us to complete 3arabeety, we will need a minimal set of tools as it relies almost entirely on products. We will need:

• The XCode Integrated Development Environment (IDE) with the iOS APIs [19],

• The Eclipse IDE with the Android Development Toolkit (ADT) [20], • The tools provided by Amazon Web Service to host and manage the different

components of the cloud system, • The tools necessary to combine the different components of the hardware.

This remains out of our scope of knowledge. This is referenced in the necessary knowledge to be acquired section below.

Experiments  Conducted  One very important part of our project is being able to distinguish a speed bump from normal driving. For this reason we are going to need to establish a baseline, and also recognize how sever an average speed bump is. Therefore, we will need at least two experiments:

1. Baseline experiment: We are going to drive for over 200 kilometers on the best-paved road in Egypt, the Katameya-Ain Sokhna Road to train our sensors to what driving on a smooth road is like.

2. Bumpy Experiment: We are going to drive in one of the very poorly paved roads in New Cairo to train our sensors to what driving in a rough terrain is like.

 

11

System  Design  Issues  Before explaining the rationale behind selecting the approach aforementioned, let us focus on the design alternatives and their disadvantages, which will clearly display why we chose to pursue the route we did.

Reporting-­‐Based  Designs  We could have relied on applications that have the user do the reporting as many others have. In the Related Works section, there is an abundance of such applications for both ditch and pothole reporting and for traffic reporting. Our main concern with relying on such an application was that it meant that the user would necessarily have to use her phone as she drove. This is something that we chose to avoid, as one of the main foundations this thesis is based on is the safety of the drivers. We simply could not compromise the safety of the user to have her take her phone out of her pocket, fill out a form, and submit it, all as she is driving. In addition to that, we would have to rely on User Generated Content, which can be erroneous. By removing the human factor from the collection of our data, we have successfully removed incorrect input submitted by malicious users. It also relieves the user of the headache of needing to report on the status of traffic and/or the existence of a pothole, ditch, or speed bump to be able to reliably use the service.

Smartphone-­‐Based  Designs  One easy way to avoid needing the users to report and, not incur any extra costs on them, is to use the hardware already existent in the users’ smartphones. As extensively discussed in the Related Works section, relying on smartphones both very seriously affects the battery life of the user’s phone, in addition to greatly compromising the accuracy of the data collected. This would both corrupt the data of the system, its most valuable asset, and it would discourage users from continuously using the application. Both solutions that attempted to improve either factor of accuracy or power consumption relied on the reducing the usage of the application and turning off the sensors, hence reducing the amount of reliable data that can be used. This is in addition to requiring the user to notify the mobile application of when the user is starting a trip, and hence when the application should start recording. For these reasons, we opted not to rely on the smartphone-based designs.

Dedicated  Hardware  Designs  Although they are not as widely implemented as solutions that rely on the users’ smartphones, solutions that rely on dedicated hardware exist and have been made before. It is important to mention again here that MIT’s Pothole Patrol, relying entirely on dedicated hardware, had an extremely impressive 99.8% accuracy when it came to the detection of potholes. In addition to this added accuracy, we are able to immediately detect when the user is driving and when she is not. We do not require the user to perform any action on the application, provide a certain report, or do anything else upon starting and completing her journey.

Our  Design  and  Finer  Details  For all of the aforementioned reasons, we have decided to rely on a dedicated hardware device placed in the car to collect and submit the information to our servers for processing. We chose to rely on a Raspberry Pi computer with added sensors to collect the information necessary for the prototype. This is both expensive and akin to using a gun to kill a fly. We have, however, chosen this design as it is the simplest to

12

implement as a thesis project. Upon entry into a mass production phase, if it does, 3arabeety would rely on customized embedded systems that do its own data collection, rely on minimal power usage, and are fairly inexpensive. This left us with the consideration of where to place the Raspberry Pi computer in the car. One idea that we had was to place the Raspberry Pi directly connected to the OBD-II interface. We even hoped to power the Raspberry Pi by relying on the power emitting from the OBD-II. This proved impossible. Therefore, we started considering powering the Raspberry Pi from the car battery, but also having it connected to the OBD-II. Although that is indeed possible, it would create a very serious discomfort to the driver, restraining the way her leg can move above the pedals. For this reason, we started considering placing the Raspberry Pi somewhere stable inside the car. Finally, we came to the conclusion that we should interface with the car wirelessly through a Bluetooth adapter connected to the OBD-II interface communicating with another Bluetooth adapter connected to the Raspberry Pi. As to where we should place the Raspberry Pi itself, we came to the conclusion that it should be placed on the dashboard of the car, away from sources of water (coming from cup holders, for example), and on a stable, fairly unused space so that it would not interfere with the user’s comfort. Finally, the dashboard, at the front of the car, is one of the parts that move the most when a user hits a speed bump. This would allow 3arabeety to detect speed bumps and potholes much more efficiently and accurately.  

13

Expected  Outcomes  When 3arabeety is complete, we expect to have a product that relies on an entirely new technique to deliver a host of services relying on the same components. These services are both highly needed in the Egyptian community and some of which remain not yet tackled by existing products and services. 3arabeety is a product in the sense that it is a device that the user has to buy and install in the car. This device, as a prototype, will be constructed of a Raspberry Pi computer. This computer will also come with an OBD-II Bluetooth adapter. The computer will be able to connect, via its own Bluetooth adapter, to the OBD-II interface. The computer will also contain an Inertial Measurement Unit (IMU), Global Positioning System (GPS), and a 3G/GPRS interface to be able to connect to mobile data networks. This Global Interfacing with the Vehicle (GIV) Box is dedicated to simply obtaining and recording data on the 3arabeety servers. The GIV box relies on machine learning and IMU sensors placed in dedicated hardware to detect and record speed bumps. This is a novel approach to solving this problem. As previously mentioned in the Related Works section, others have attempted to tackle this problem. Instead, they have relied on solutions based entirely in computer vision or the IMU sensors placed in cell phones. As discussed and rationalized in the Proposed Approach and System Design Issues sections, we are tackling this problem in an unprecedented approach, relying on dedicated hardware to provide the services that we do. The GIV Box is not the entirety of the suite that the solution relies on. Instead, 3arabeety also relies on a mobile application, yet another product, to be installed. This mobile application will be available for Android and iOS mobile phones. We also hope to make it available for Windows Mobile. The 3arabeety application, built with an attractive Graphical User Interface (GUI), will be able to provide the users with virtual “obstacles signs,” warning them of advancing obstacles, whether they are ditches, speed bumps, or potholes. The application will also contain a map of the immediate area of the driver with the roads colored in the level of traffic expected in those roads. In that sense, the 3arabeety mobile application is dedicated to obtaining rational information from the servers and displaying them in a visually attractive style. The application is considered the portal to providing the host of 3arabeety services. When it comes to the services 3arabeety provides, the main objective is to leverage the existence of hardware in the car, interfacing with the car, to provide all of the available functionalities. What this means is that we want to do pothole, ditch, and speed bump detection and warn users upon the entry of an area that contains such an obstacle. What this does is ensure that users and their vehicles are not affected by unexpected obstacles, but rather warned before collision. This provides an additional safety feature for both the driver and the car. We also want to rely on the premise that we have many users to leverage their speeds and driving patterns to provide us with the necessary data to be able to complete a functionality of traffic analysis. In interfacing with the car, we are also able to access a host of data that can then be used to provide the user with information about the car. This information, as a first step, will include an analysis of engine error codes to inform the user on the reason a “check engine” light is lit, if it is indeed lit. In the future, we hope to expand this interfacing with the car to be able to provide features such as vehicular tracking and analysis of fuel consumption, fuel economy, and other engine status indicators obtained from the OBD-II interface.

14

Societal  Impact  and  Product  Profit  3arabeety is a system clearly intended for drivers of all sorts, whether the driver is driving a private car, a taxi, a bus, or an emergency vehicle. It will help those users by warning them before collision with an unforeseen road anomaly. It will also guide them through the emptier roads in Egypt. This is in addition to interfacing with the car and providing a host of useful information coming from it.

The  Societal  Impact  of  Pothole  Detection  As aforementioned in the Problem Definition section, the condition of roads in Egypt is responsible for a large number of accidents, causing injury sometimes to a fatal extent. What this means is that maintaining those roads and improving their conditions is a necessary step in the assurance of Egypt’s future. 3arabeety improves the safety of the individuals using the system, as they will be forewarned before a collision with an unforeseen road anomaly. Although 3arabeety will not be able to fix the roads itself, it will be able to provide the government with the necessary information to do so. It will also be able to warn the drivers to avoid collision with an unseen obstacle before it happens. It is certainly an extremely important step in the reduction of road accidents in Egypt. Since we will have a wholesome database of potholes, ditches, and speed bumps, we will also be able to provide the Egyptian government with this information in order for them to be able to understand which obstacles are providing the largest inconvenience to drivers and halting traffic. With this information, they can then proceed to maintaining the roads and servicing them, thus improving road quality conditions in Egypt. Unlike other applications mentioned in the Related Works section, 3arabeety will not have a direct connection to the government. However, our database will be robust enough to be able to provide the government with information necessary for them to be able to improve the conditions of the road.

The  Societal  Impact  of  Traffic  Analysis  Not only that, but also aforementioned is the extent of traffic on the Egyptian economy. When our drivers, who will hopefully be many, are able to avoid this traffic, it will assist the drivers with their business initiatives. Simple events such as arriving on time for a business meeting, being first at snagging an opportunity, or quickly arriving to the location of an emergency will make a large difference when it comes to how 3arabeety is going to affect the Egyptian economy. Not only that, but if ambulance and police vehicles start relying on 3arabeety, they will be able to avoid traffic, thus arriving at the location of a crime or a medical emergency much faster than at the current rate. What this will do is improve the average expected wait time for police or medical officials to arrive at the scene, reduce fatalities, and reduce the rate of crime. In addition to that, 3arabeety will also provide the users with much higher fuel efficiency. This will come from their lack of need to stay stopped in traffic with the engine running, which would be consuming gas for no reason. What this means is that the utilization of gas in cars using 3arabeety will, almost always, be for the cause of moving the car. If all of the gas used by the car is utilized in motion instead of while stopped in traffic, then this means that, overall, there would be a considerably reduced amount of gas used. If that is the case, then this means a considerable reduction of carbon emissions

15

in the atmosphere by the cars. Therefore the air quality will improve in Egypt based on this fact.

The  Societal  Impact  of  Interfacing  with  the  Car  3arabeety’s connection to the car displays a host of useful information about the car. This includes the specific parts that need to be fixed in the engine when a ‘check engine’ light is lit. Therefore, what this means is that users of the system will have “healthier,” more efficient cars, thereby reducing the possibility of unforeseen car breakdowns, affecting traffic and causing accidents. Interfacing with the OBD-II also allows 3arabeety to be able to detect the location of the car and constantly submit it. In the unfortunate circumstance of car theft, users will be able to track their vehicles and report to the police the exact location of their car for quick and easy retrieval.

Product  Profit  Although 3arabeety is fairly expensive to produce as a prototype, when it enters the mass production phase, we will be able to simplify the designs of the 3arabeety GIV box, utilizing more customized and specific components, thereby greatly reducing the cost. For example, instead of relying on a full-fledged Raspberry Pi computer, we could rely on a Microcontroller chip, such as an Arduino chip. In its reduced cost state, 3arabeety will be able to make profit through its sale as a product to be installed in the cars of the users. As to why the users would buy the system, or how they would feel it has financially benefitted them, users will be able to see the reduction of gas consumption after installing 3arabeety. Users will also recognize the financial benefit of arriving to destinations on time, thereby recognizing the financial advantage of having 3arabeety installed. Finally, ditches and potholes in Egypt are no easy obstacle. Sometimes unexpected collision with such an anomaly can cause very serious damages to the car. Having 3arabeety installed prevents such collisions from happening, thereby protecting the integrity of the car and its parts.

16

Knowledge,  Technology,  and  Skills  Needed  

Knowledge  Needed  

Knowledge  Needed  for  GIV  Box  Development  and  Implementation  In order for us to complete the GIV Box, we will need to know how to connect hardware components and to program them for Raspberry Pi. After merely programming them to interface with the Raspberry Pi, we will also need to know how to have the GIV Box form data packets to be sent to the cloud for processing. We will also need to understand how to interface with the OBD-II, and what each error code transmitted by the engine translates to.

Knowledge  Needed  for  Cloud  System  Development  and  Implementation  To complete the cloud system, we will need a deep understanding of big data and its management, relational and non-relational database modelling and management, the implementation of cloud applications that make sense of the raw data provided by the GIV box to be provided to the mobile applications, the implementation of interfacing web services using .NET suite for the GIV box and the mobile applications to interact with.

Knowledge  Needed  for  Mobile  Application  Development  and  Implementation  For building mobile applications on the iOS operating system, we are going to need knowledge of using XCode, the Integrated Development Environment (IDE) dedicated for developing iOS applications. We are also going to need to know how to use the Swift programming language as it is the only language with which iOS applications can be built natively. In order to develop Android applications, we are going to utilize our knowledge of the Java programming language, coupled with XML for the layouts. In addition to that, we are going to utilize our knowledge of using the Eclipse IDE, coupled with the Android Development Toolkit (ADT). In addition to this, we will need to learn to develop attractive, interactive GUI layouts for increasing user engagement and usage continuity. We will also need to rely on our knowledge of communicating with web servers and web database from within mobile applications the applications with the necessary information from the 3arabeety servers.

Technology  

Technology  Needed  for  GIV  Box  Development  and  Implementation  We are going to need to rely on the following technologies to complete the GIV Box:

• Raspberry Pi computers, • IMU Sensors, • GPS Sensors, • 3G Communication Hardware, • Bluetooth Adapters, • OBD-II Interfacing Adapters.

Technology  Needed  for  Cloud  System  Development  and  Implementation  We are going to need to rely on the following technologies to complete the Cloud System:

• Amazon Web Database,

17

• Amazon Compute Engines, • .NET Technology for developing web services.

Technology  Needed  for  Mobile  Application  Development  and  Implementation  We are going to need to rely on the following technologies to complete the mobile applications:

• A-GPS (Assisted GPS) Technology, • Push Technology.

Skills  

Skills  Needed  for  GIV  Box  Development  and  Implementation  We will need the following skills to complete the GIV Box:

• Connecting hardware components to a Raspberry Pi, • Programming the hardware components on a Raspberry Pi, • Forming Data Packets to be handled by the server and submitting them.

Skills  Needed  for  Cloud  System  Development  and  Implementation  We will need the following skills to complete the cloud system:

• Modelling and programming relational and non-relational databases, • Aggregating and analysing big data, • Programming cloud computing applications, • Programming web services.

Skills  Needed  for  Mobile  Application  Development  and  Implementation  We will need the following skills to complete the mobile applications:

• Programming in Java, • Programming in Swift, • Creating layouts in XML, • Interfacing with web servers and web databases.

18

Work  Plan  Goals Objectives Tasks Start Date

(M/D/Y) End Date (M/D/Y)

Cloud System Built

Rent Cloud Platform

Research Available Cloud Platforms

04/01/2015 04/07/2015

Select Cloud Platforms and services necessary

04/08/2015 04/08/2015

Purchase selected services

06/01/2015 06/01/2015

Build database

Create data model 06/02/2015 06/04/2015 Code database using SQL

06/05/2015 06/10/2015

Build interaction APIs

Create GIV (writing) web service

08/01/2015 08/15/2015

Create mobile application (reading) web service

09/15/2015 10/01/2015

Create collision trigger for database additions

08/15/2015 09/01/2015

Create Traffic Analysis Algorithm

09/01/2015 09/15/2015

Black Box Operational

Purchase black box components

Research sensor types necessary

04/09/2015 05/01/2015

Buy sensors 05/01/2015 05/15/2015 Build black box

Design black box circuitry

06/01/2015 06/07/2015

Build black box circuitry from purchased components and design

06/10/2015 07/15/2015

Program black box circuitry to properly interact with web services

06/10/2015 07/15/2015

Test black box

Ensure that black box is sending data correctly

07/15/2015 07/22/2015

Tune black box according to findings

07/22/2015 08/01/2015

Mobile Applications Released

Build mobile applications functionality

Build iOS application functionality (Swift)

10/01/2015 11/01/2015

Build Android application

10/01/2015 11/01/2015

19

functionality (Java)

Build mobile applications user interface

Build iOS application GUI

10/01/2015 11/01/2015

Build Android application GUI

10/01/2015 11/01/2015

Test mobile applications

Ensure that Android and iOS applications are receiving data correctly

11/01/2015 11/07/2015

Tune applications according to findings

11/07/2015 11/21/2015

Deploy mobile application to App Stores

Release Application on iTunes App Store

11/25/2015 12/10/2015

Release Application on Google Play Store

11/25/2015 12/10/2015

Place links on Website

12/10/2015 12/10/2015

   

20

Concluding  Remarks  Driving in Egypt is no easy task. The two main reasons for that are both the incredibly horrible and quickly worsening road conditions and the overwhelming traffic that is prevalent in the Egyptian streets. The poor road conditions lead to accidents that can hurt the drivers, the vehicles, the pedestrians, and the surrounding vehicles. The horrible traffic congestion issues lead to massive economic losses every year, in addition to polluting the Egyptian air. For those reasons, we have decided to build 3arabeety. 3arabeety will rely on dedicated hardware deployed in the car that collects information about the traffic conditions, the road conditions, detects speed bumps, and receives information from the OBD-II interface in the car. This hardware then communicates the information it’s collecting to the servers to be processed and for this raw data to be generated to useful, reliable information. In the mobile applications built for Android and iOS, we will relay this information to the user in a visually attractive, engaging manner. This will be done through styling the streets in colors indicating the level of traffic expected in the street. In addition to that, upon entering the immediate area of a pothole, ditch, or speed bump, users will be warned so that they can either slow down or avoid collision with the road anomaly altogether. This will allow for increased safety, an overall improvement in the Egyptian economy, and an improvement in the air quality in Egypt, due to the removal of the emissions of the cars stuck in traffic. In order for us to accomplish this great task, we are going to need to build the dedicated hardware, connect it to the servers, build the cloud computing platform, build the mobile applications, and connect them to the servers. This will require us to learn many things about hardware design, cloud computing, and mobile application development. We will rely on this acquired knowledge to hone our programming skills into the areas necessary for the completion of the project such as embedded systems, big data analytics, and mobile application development. We are planning to complete 3arabeety as a functional prototype in a period of seven months from June 1st, 2015, to December 22nd, 2015.

21

References   [1] Seattle City Hall, ‘Find It, Fix It -- Service Request Mobile App - Customer Service Bureau’, Seattle.gov, Feb-2008. [Online]. Available: http://www.seattle.gov/customer-service-bureau/find-it-fix-it-mobile-app. [Accessed: 25-Mar-2015].

[2] A. Hejazi, ‘Hofrah - Social Street Condition’, App Store, 2012. [Online]. Available: https://itunes.apple.com/us/app/hofrah-social-street-condition/id597187259?mt=8. [Accessed: 25-Mar-2015].

[3] Plus Design Marketing, ‘Potholes Hunter’, Google Play, 22-May-2013. [Online]. Available: https://play.google.com/store/apps/details?id=cz.vymoly.android. [Accessed: 25-Mar-2015].

[4] New Urban Mechanics, ‘Citizens Connect’, New Urban Mechanics, Feb-2013. [Online]. Available: http://newurbanmechanics.org/project/citizens-connect/. [Accessed: 25-Mar-2015].

[5] New Urban Mechanics, ‘Street Bump’, New Urban Mechanics, May-2008. [Online]. Available: http://newurbanmechanics.org/project/3701/. [Accessed: 25-Mar-2015].

[6] P. Mohan, V. N. Padmanabhan, and R. Ramjee, ‘Nericell: Rich Monitoring of Road and Traffic Conditions using Mobile Smartphones’, 2008.

[7] R. Bhoraskar, ‘Wolverine  : Traffic and Road Condition Estimation using Smartphone Sensors’, 2012.

[8] J. Eriksson, L. Girod, B. Hull, R. Newton, S. Madden, and H. Balakrishnan, ‘The Pothole Patrol: Using a Mobile Sensor Network for Road Surface Monitoring’, 2008.

[9] Waze, ‘Free Community-based Mapping, Traffic & Navigation App’, Waze. [Online]. Available: waze.com. [Accessed: 25-Mar-2015].

[10] Bey2ollak, ‘Bey2ollak: Traffic Reporting’, Bey2ollak. [Online]. Available: bey2ollak.com. [Accessed: 25-Mar-2015].

[11] SocialFruits - www.SocialFruits.com, ‘ووصصللننيي - REALTIME Cairo Traffic MAP on the GO!’, Wasalny. [Online]. Available: http://wwweg.wasalny.com/Homepage. [Accessed: 25-Mar-2015].

[12]

22

Here, ‘Here - City Country Maps, Driving Direction’, Here. [Online]. Available: here.com. [Accessed: 25-Mar-2015].

[13] Carberry, ‘Carberry’, Carberry. [Online]. Available: carberry.it. [Accessed: 25-Mar-2015].

[14] Cowfishstudios.com, ‘OBD-Pi: Raspberry Pi Displaying Car Diagnostics (OBD-II) Data On An Aftermarket Head Unit’, Cow Fish Studios. [Online]. Available: http://www.cowfishstudios.com/blog/obd-pi-raspberry-pi-displaying-car-diagnostics-obd-ii-data-on-an-aftermarket-head-unit. [Accessed: 25-Mar-2015].

[15] Raspberry Pi, ‘Raspberry Pi’, Raspberry Pi. [Online]. Available: http://www.raspberrypi.org/. [Accessed: 25-Mar-2015].

[16] Z. Coffey, ‘Which OBD-II Bluetooth Adapters Offer The Best Value?’,Gas2, 26-Feb-2014. [Online]. Available: http://gas2.org/2014/02/26/turn-car-smart-car-bluetooth-obd-ii-adapter/. [Accessed: 25-Mar-2015].

[17] Cooking Hacks, ‘3G/GPRS shield for Arduino, Raspberry Pi and Intel Galileo (3G + GPS) + Audio/Video Kit’, Cooking Hacks. [Online]. Available: http://www.cooking-hacks.com/3g-gprs-shield-for-arduino-3g-gps-audio-video-kit. [Accessed: 25-Mar-2015].

[18] M. Williams, ‘New Kickstarter Launched - BerryIMU’, Ozzmaker, 19-Nov-2014. [Online]. Available: http://ozzmaker.com/2014/11/19/new-kickstarter-launched-berryimu/. [Accessed: 25-Mar-2015].

[19] Apple Inc., ‘Xcode’, Apple Developer. [Online]. Available: https://developer.apple.com/xcode/. [Accessed: 25-Mar-2015].

[20] Google, ‘Download Android Studio and SDK Tools | Android Developers’,Android Developer. [Online]. Available: http://developer.android.com/sdk/index.html. [Accessed: 25-Mar-2015].

[21] World Health Organization , ‘Road safety in 10 countries Countries’, Nov. 2010.

[22] Daily News Egypt, ‘Fixing Cairo’s traffic woes’, Daily News Egypt, 17-Sep-2012.

[23] Z. Nakat, S. Herrera, and Y. Cherkaoui, ‘Cairo Traffic Congestion Study Executive Note’, The World Bank group, 2010.