University Students

Carpooling with UniRide

A Project Report
Presented To
The Faculty of the Computer Engineering Department

San Jose State University

In Partial Fulfillment
Of the Requirements for the Degree
Bachelor of Science in Software Engineering

by
Timothy Davis
Marta Malapitan
Akshat Sharma
Maninderjit Singh

May 2017
 1

Copyright © 2018
Timothy Davis
Marta Malapitan
Akshat Sharma
Maninderjit Singh
ALL RIGHTS RESERVED
 2

APPROVED FOR THE COLLEGE OF ENGINEERING

______________________________________________
Kaikai Liu, Project Advisor

______________________________________________
Professor Rod Fatoohi, Instructor

______________________________________________
Dr. Xiao Su, Computer Engineering Department Chair
 3

Abstract
UniRide Carpool Application and Parking System
By Timothy Davis, Marta Malapitan, Akshat Sharma, Maninderjit Singh

As a university in an urban downtown area, San Jose State University faces a seemingly
unsolvable issue of traffic congested streets nearby and within the campus parking lots. The
University’s website states there is an estimated number of 40,000 students, faculty, and staff
members; however, there are a total of only 6,543 parking spaces in the University’s parking
garages to accommodate everyone.

In hopes of mitigating traffic and understanding the difficulties of finding parking on

campus, the University has been providing alternate transportation solutions for its students.
These solutions include free-of-cost services like VTA Light Rail and busses. Though these
solutions are beneficial for reasons like savings on gas, they are extremely time-consuming,
insecure and may be inconvenient. Students who use these services schedule their time to
comply with the ​services’ planned schedules, and can cause inconvenience for those who have
early class schedules or live far from the stations. VTA Light Rail and busses can also
occasionally be off-schedule, which can cause a delay in the student’s schedule of the day.
Additionally, students share these services with strangers who may create an uncomfortable
atmosphere. Carpooling has been a system that has been frequently encouraged, though most
may not feel a significant incentive to participate in such a system.

This project engenders a convenient, reliable, secure, and cost-efficient carpooling

system for students. Students may utilize a student-only mobile carpool application, UniRide,
that has automated matchmaking and public transportation connectivity. Additionally, it includes
real-time incident reporting, transparent location reporting, and integration with the University’s
system for dedicated carpool parking spaces and a points system. In addition to the mobile
application, our parking system utilizes IoT technologies and sensors to determine parking
validation, and carpool verification.
 4

Acknowledgements
We would like to thank our Senior Project Advisor for providing us with direction and technical
support, and San Jose State University for giving us the opportunity to develop a system that can
make a difference.
 5

Table of Contents
Chapter 1. Introduction
1.1 Project Goals and Objectives
1.2 Problem and Motivation
1.3 Project Application and Impact
1.4 Project Results and Deliverables
1.5 Project Report Structure

Chapter 2. Background and Related Work

2.1 Background and Technologies
2.2 Literature Search
2.2.1 Traffic and Its Effects
2.2.2 Effects of Parking
2.2.3 Root Problem
2.2.4 Solution: Carpooling
2.3 State of the Art Technologies Summary

Chapter 3. Project Requirements

​3.1 Domain and Business Requirements
3.1.1 Process Summary Diagram
3.1.2 Process Decomposition Diagrams
3.2 System or Component Functional Requirements
3.3 Non-functional Requirements
3.4 Context and Interface Requirements
3.5 Technology and Resource Requirements

Chapter 4. System Design

4.1 Architecture Design
4.1.1 Mobile Application Architecture Design
4.1.2 Parking System Sensor Hardware Architecture Design
4.2 Interface and Component Design
4.2.1 Interface Design
4.2.2 Class Design
4.2.3 Database Design
4.2.4 Parking System Design
4.3 Structure and Logic Design
4.3.1 Parking System Algorithm
4.4 Design Constraints, Problems, Trade-offs, and Solutions
4.4.1 Design Constraints and Challenges
 6

4.4.2 Design Solutions and Trade-offs

Chapter 5. System Implementation

5​.1 ​Implementation Overview
5.2 Implementation of Developed Solutions
5.3​ ​Implementation Problems, Challenges, and Lessons Learned

Chapter 6. Tools and Standards

6​.1 ​Tools Used
6.1.1 Application Development Tools
6.1.2 Application Version Control Tools
6.1.3 Group Communication Tools
6.2 Standards
6.2.1 Design Standards
6.2.2 Documentation Standards
6.2.3 Version Control Standards

Chapter 7. Testing and Experiment

7.​1 ​Testing and Experiment Scope
7.1.1 Test Process of User-Interface
7.1.2 Test Process of Firebase Query
7.1.3 Test Process of Search Algorithm
7.1.4 Process of Sensor Data Accumulation, Analyzation, and Publication
7.2 Testing and Experiment Approach
7.2.1 Test Approach for User-Interface
7.2.2 Test Approach for Firebase Query
7.2.3 Test Approach for Search Algorithm
7.2.4 Test Approach for Sensor Behavior
7.3​ ​Testing and Experiment Results and Analysis
7.3.1 Test Results for User-Interface
7.3.2 Test Results for Firebase Query
7.3.3 Test Results for Search Algorithm
7.3.4 Test Results for Sensor Behavior

Chapter 8. Conclusion and Future Work

8​.1 ​Conclusion
8.2 Future Work
 7

List of Figures
Figure Title ​Page(s)

Figure 1. Prototypes of User Interfaces of UniRide Android Application 13

Figure 2. Fuel Consumption vs Speed 19

Figure 3. Energy Consumption vs Speed 19

Figure 4. Process Summary Diagram 22

Figure 5. Parking System Process Diagram 23

Figure 6. Carpool Process Diagram 24

Figure 7. Class Diagram of Business Classes 24

Figure 8. Carpool Process Diagram 25

Figure 9. Parking Spot State Diagram 26

Figure 10. Android Application Architecture Overview Diagram 34

Figure 11. Parking System Architecture Design 36

Figure 12. User Interfaces of UniRide Android Application 37 - 38

Figure 13. Simplified UML Class Diagram 39

Figure 14. Firebase Database Tree Structure 41

Figure 15. Components of UniRide’s Parking System 42

Figure 16. Arduino R3 Uno - Pseudocode 43

Figure 17. Raspberry Pi - Pseudocode - Python 44

Figure 18. Matchmaking Algorithm Flowchart 47

Figure 19. Color Scheme for Specified Purposes 56

Figure 20. Button Preview 56

Figure 21. Request a Ride Post Forms Views 57

Figure 22. Login and Sign Up Views 57

Figure 23. User-interface Components and Output 59

 8

Figure 24. Firebase Query and Database Results 60

Figure 25. Search Algorithm Preview 60

Figure 26. Functions that Send Commands to Sensors 61

 9

List of Tables
Table Title ​Page(s)

Table 1. System Requirements 27 - 30

Table 2. Non-functional Requirements 30 - 31

Table 3. Context Requirements 31

Table 4. Interface Requirements 32

Table 5. Technology and Resource Requirements 32 - 33

Table 6. Tools Overview 50

Table 7. Testing Table Structure 62

Table 8. Loading Post Feed Test 62 - 64

Table 9. Showing Post Details Test 64 - 65

Table 10. Get All Post in an Organization Test 65 - 66

Table 11. Retrieve All Posts With Selected Date Test 67

Table 12. Find Matchmaking Ride Request Posts Test 68

Table 13. Correct Trip Path Generated Test 69 - 70

Table 14. Sensor Detects Object Entering Parking Spot Test

70 - 71

Table 15. Raspberry Pi Gets Data From Sensor Test 71

Table 16. Raspberry Pi Sends Data to AWS IoT Test

72

Table 17. Loading Post Feed Results 73

Table 18. Showing Post Details Results 74

Table 19. Get All Posts in An Organization Results 75

Table 20. Retrieve All Posts With Selected Date Results 75

Table 21. Find Matchmaking Ride Request Posts Results 75 - 76

 10

Table 22. Correct Trip Date Generated Results 76

Table 23. Sensor Detects Object Entering Parking Space Results 77

Table 24. Raspberry Pi Gets Data From Sensor Results 77 - 78

Table 25. Raspberry Pi Sends Data to AWS IoT Results 78

 11

Chapter 1. Introduction
1.1​ P
​ roject Goals and Objectives

by Marta Malapitan

The primary goal of this project was to create a system that makes carpooling more
convenient, secure, and cost-efficient for university students. We also wanted to create such a
system that provides incentives to those who carpool. Because limited parking spaces are part of
the fundamental problem, we decided to focus our incentive plan on providing dedicated parking
spaces in campus or organization-owned garages that could be reserved by participating in a
carpool. To achieve these goals, we created two separate components that together creates our
system known as “UniRide.”

The two components of UniRide are an Android mobile application and a sensor-based
parking system. We developed a mobile application that allows users to easily create and join
carpools with their peers. It is user-friendly, has automatic matching abilities, and transparent
location reporting. In addition to the mobile application, we created a parking system that is fully
integrated with our application. This parking system is sensor-based and is installed in the
University’s parking garage to monitor and verify carpools. It utilizes IoT technologies and
sensors to detect if a car is parked in a specific space. It will then communicate with the UniRide
application to verify if the parked car belongs to a valid UniRide carpooler.

1.2​ P
​ roblem and Motivation

by Akshat Sharma

Traffic and air pollution are a couple major concerns in populated urban areas. San Jose
is no exception in this matter especially since the city has a State University in the very heart of
its downtown. 32,773 students are currently enrolled in San Jose State University. Out of which,
36.11% drive alone to school. This brings a swarm of approximately 11,000 vehicles in and out
of the city. Such a vast number of vehicles can result in major traffic problems.

Apart from traffic, parking is another issue. San Jose State’s parking structures hold
about 4,000 parking spots which are not nearly enough for a weekday traffic. In such conditions,
an apt solution would be to reduce the number of cars on the road which can be effectively
 12

achieved by an efficient carpooling system. Those who commute alone in separate cars can
travel together in fewer cars, and can decrease the traffic exponentially in an idle scenario. Doing
this will not only decrease traffic congestion and parking issues, but will also act as a significant
step towards an environmental-friendly society.

1.3​ P
​ roject Application and Impact

by Marta Malapitan

With our system, we strived to get the support and attention of areas that lack alternative
transportation solutions, and universities that have an exceedingly high amount of traffic-related
issues around their campus. We believe to have the ability to impact the following areas:

Society Impact:
Our project encourages unification within college communities as they participate in a safe and
convenient carpool system. Participating students also take part in maintaining the environment.
By choosing to carpool together, rather than taking their own cars to the same destination,
students are reducing their carbon dioxide emissions.

Academic Impact:
The mobile application component of our project utilizes a combination of existing APIs, and
research findings to build an optimized carpool application. Meanwhile, the parking system
component uses state-of-the-art IoT technologies that will contribute to the few existing parking
solutions. Every aspect of our work has been documented for academic purposes.

Industry Impact:
The future success of UniRide will have a major impact in the transportation industry. It has the
capabilities to compete with other transportation applications like Uber and Lyft, and because it’s
designed to service a specific group of commuters in need, other transportation solutions will be
highly affected–reducing the amount of their users.

1.4​ P
​ roject Results and Deliverables

by Marta Malapitan, and Akshat Sharma

As a whole, our project result includes a fully-functional Android mobile application that
is integrated with an accurate real-time sensing parking system.
 13

Besides the convenience it brings, our mobile application has the following features:
● Point system for ride-and-drive rotation
● Automated matchmaking for our carpool service
● Transparent location reporting
● Integration with University’s system to monitor carpool spaces

Additionally, our application has the ability to service a minimum of 5,000 participants as
we strive to continuously increase our user count. UniRide’s parking system utilizes IoT
technologies and sensors for parking validation and carpool verification. All data collected by the
sensors are visible through the correlating application component of our project.

Application Deliverables:

Figure 1. ​Prototypes of​ ​User Interfaces of UniRide Android Application

The user interfaces displayed in ​Figure 1​ were our initial desired designs. We wanted to
ensure they are extremely user-friendly​— ​appealing and easy to use.

Parking System Deliverables:

The importance of our parking system is to provide a space for our carpoolers to park in
when they arrive at their destination. This parking system consists of ultrasonic sensors, an
Arduino, Raspberry Pi, Avnet Cellular Shield, and Amazon AWS. Together, these components
play a significant role to capture the status of a monitored parking space using the sensors, and
 14

send the data to UniRide to allow that information to be visible to UniRide users. Additionally,
the parking system has another purpose: carpool verification. When a vehicle arrives at a parking
space, the parking system is able to detect that movement and will communicate with the
UniRide application. The UniRide application will then interact with the user to verify the
vehicle that has arrived at the space is in fact a UniRide carpool and not an unauthorized
commuter.

1.5 Project Report Structure

by Marta Malapitan

In this document, we will be discussing every aspect of our project. This includes
chapters about information obtained from research done, project requirements, system design,
and system implementation. The following list includes a number of details that will be
discussed in each chapter of this document.

I. Chapter 2 discusses background knowledge and technologies, and related work done for
the project. It will discuss the purpose of the components that were used to create our
system. This includes the following components: MVC, Java, XML, Android Studio,
Google Firebase, Google Maps API, Ultrasonic Sensors, Arduino UNO, Raspberry Pi 3,
Avnet Cellular Shield, Amazon AWS. It will also include our Literature Search in which
we describe the traffic and parking issues we are trying to solve, and the solution we
developed to solve those issues. Lastly, a state-of-the-art technologies summary discusses
the existing transportation solutions we have considered, as well as the the smart-parking
system that helped us improve our system design. This section includes information
about 511’s ridematch service, Scoop, UberPOOL, Lyft Line, Westfield Valley Fair Mall
smart-parking system

II. Chapter 3 consists of details of our project requirements. Here, we have diagrams and
tables that describe domain and business requirements, system functional and
nonfunctional requirements, context and interface requirements, and technology and
resource requirements.

III. Chapter 4 documents our entire UniRide system design. It contains architecture designs
of our mobile application as well as the parking system. It also provides extensive detail
of our interface design, logic design, database design, and parking system design. In
addition, the final section discusses our design constraints, problems, trade-offs and
solutions.
 15

IV. Chapter 5 explains our system implementation. The sections includes an overview of our
implementation, and what techniques and methods we used to implement our developed
solution to traffic and parking issues. It also describes the challenges we had during our
project and the learning outcome from this project.
 16

Chapter 2. Background and Related Work

2.1 Background and Technologies
by Marta Malapitan and Timothy Davis

To meet our primary goal of developing a carpooling system that is secure, convenient,
and cost-efficient for students, we designed it with inexpensive technologies that integrate
harmoniously together. We were able to learn more about technologies that we learned about in
previous courses as well as recent ones that improved our design.

Our Android mobile application was developed with a number of technologies that each
member of this project is now fairly familiar with. The application was created with Android
Studio, and was designed with Android’s programming architecture that is similar to a
Model-View-Controller architecture. It was also created with Java, therefore, a strong knowledge
in Java programming structures like anonymous inner class, various design patterns like Adapter,
and object-oriented design concepts were required to develop a proper Android application.

The back-end of the software uses Google’s Firebase Realtime Database. It uses a
semi-structured, non-relational database design, and requires no SQL code. In addition, Google
provides an online console for Firebase that allows developers to view and control their stored
data. The database stores all core model components of the system such as user information,
drive offer and ride request posts, and carpool data. Additionally, the front-end of the application
uses Android layouts with XML to design and organize the view components. It was essential for
each member to understand Android’s material design and design standards to create a
professional and easy-to-learn user interface. Furthermore, we have incorporated a few APIs for
Google Maps and Android Firebase.

In addition, our parking system component uses affordable hardware materials that
enables smooth communication and interaction with our application. The parking system uses an
ultrasonic sensor, Arduino, Raspberry Pi, Avnet Cellular Shield and Amazon AWS. Knowledge
in how each can be used and integrated together is significant to create the parking system.
Monitoring a parking space is achieved by using the ultrasonic sensor. We used an Arduino Uno
and Raspberry Pi 3 Model B together for data logic and analysis. The Avnet Cellular Shield
serves as our gateway to the internet, and Amazon AWS connects to the Raspberry Pi to store
and send data to our application.
 17

With the help of recent courses we have taken in our college years, we learned the fundamentals
of a few core technologies used in our system. A number of our undergraduate courses such as
Introduction to Java Programming, Data Structures and Object-Oriented Design allowed us to gain more
skills and knowledge in Java that are required to develop our Android application. We also become
familiar with Android mobile development after taking Wireless Mobile Development, and learned how
to effectively work with groups from Software Engineering courses. Furthermore, the most recent course
we have taken to strengthen our project idea was a course on IoT. In this course, we learned about
smart-parking, sensors, and Amazon AWS that are used for our parking system component.

2.2 Literature Search

2.2.1 Traffic and Its Effects

by Akshat Sharma

The United States is the 4th largest country in the world (​List of Countries by Area​), and
along with that the country ranks at 176th position in population density, with 32.45 people per
square kilometer (​Population Density - Country Comparison​). Such a low average population
density over such a vast area brings an essential market for cars. 83 million cars were sold in
2013, which included 15.6 million in the U.S alone (​Global New Car Sales in 2013 Top 83
Million​). That means on an average, 42,740 cars were sold in a day in the country. The
commercialization of personal vehicles is so extensive that they have become a significant part
of an average American’s life. So much so that on an average, each one of us spends 42 hours in
traffic in a year (​INRIX Global Traffic Scorecard​). Things get worse if we focus on the West
Coast, specifically California. Los Angeles has the most congested traffic in the world, where
according to research each driver spends an average of 104.1 hours in traffic annually, with
number four being San Francisco, another Californian city (​INRIX Global Traffic Scorecard​).
Vehicular usage of such scale brings vast amount of environmental problems with it. In 2016,
30.27 million short tons of carbon monoxide were emitted by the on-road vehicles of the country
alone (​Estimated National Emission of Carbon Monoxide​). This emission has catastrophic effects
since on an average, carbon monoxide causes 430 deaths per year (​Average Annual Number of
Deaths and Death Rates from Unintentional, Non-Fire Related Carbon Monoxide Poisoning​).
Apart from that, vehicles also emit other harmful gases such as nitrogen oxide. Over six million
short tons of nitrogen oxide were produced by vehicles in America in 2016 (​Estimated National
Emissions of Nitrogen Oxides​). Such a vast amount of nitrogen oxide leads to major
environmental concerns regarding climate change that will eventually lead to grave issues such
as rising in sea levels, which has already increased by 860% since 2005 (​Climate Change:
Global Sea Level​).
 18

2.2.2 Effects of Parking

by Marta Malapitan

In addition to traffic and pollution, parking is another major issue as it’s also another
cause of traffic and falls under an environmental concern. According to SanJoseCa.gov, the total
number of cars that go through the streets of Downtown San Jose is close to 10,000 a day.
Downtown San Jose “operates and maintains eight parking garages and nine surface lots with a
combined total of approximately 7,500 public parking spaces” (​Parking Garages & Lots​). There
are also about 50 private parking lots accommodating thousands of employees who are employed
at downtown businesses, adding another few thousands to existing parking spaces in the area
(​Lots and Garages​). To acquire as much parking as possible, garages are built floors beneath
skyscrapers and other buildings. However, there are also dedicated buildings for garages only, as
well as surface lots. The space that these garages and surface occupy can be used for much better
entities that serves the community, such as public parks and organic gardens.

2.2.3 Root Problem

by Marta Malapitan

Understanding the causes of these effects of traffic and parking problems leads us to the
root of the problem we focus on solving: excessive vehicles on the road. There have been
alternative transportation solutions that were put into effect, such as public transportation options
and ride-sharing applications, all of which aim to reduce the number of cars on the street. Each
alternative, however, has flaws of its own that defeats its initial purpose. Public transportation
options lack reliability as their arrival can be delayed. They can also be seen as a bit inconvenient
in terms of time and location of the stations. Safety is usually the biggest concern commuters
have as they ride with strangers on public transportations, as well as the costs for ride-sharing
services.

2.2.4 Solution: Carpooling

by Maninderjit Singh and Timothy Davis
 19

One of the most effective solutions to solve crowded cities is carpooling. It reduces
traffic and parking issues, as well as help our environment. As people carpool, they are cutting
down the fuel usage from two cars to one. In the article “Estimating the Energy Consumption
Impact of Casual Carpooling,” Paul Minett and John Pearce estimate that “casual carpooling in
San Francisco is conserving in the order of 1.7 to 3.5 million liters of gasoline per year, or
200-400 liters for each participant, much of which comes from the impact on the rest of the
traffic.” With this transportation technique, San Francisco saves over thirty million dollars per
year. Minett and Pearce declared that if it wasn’t for “casual carpooling,” the speed at which cars
arrived at the
Bay Bridge Toll Plaza would reduce from almost 40 km/hr to 27 km/hr. According to​ Figure 2
and ​Figure 3​ from the article, this would in turn cause the traffic to consume more energy by
thirty-five percent and fifteen percent according ​Figure 3​.

Figure 2​: Fuel Consumption vs Speed Figure 3​: Energy Consumption vs Speed

By carpooling, individuals can benefit by saving money and participating in maintaining

the environment (​South Florida Commuter Service​). The article, “Top 5 Benefits from
Carpooling,” states that the more people carpool, the lower the amount of cars there will be on
the road. Additionally, a commuter can divide the cost of the ride such as gas money or
maintenance fees when people switch cars between a certain carpooling group. Even on a
smaller scale, such as the San Jose State University, there are close to twelve thousand people
who drive to campus alone, according to a 2016 survey done by the university. Again, trying to
remove at least one third of this using carpool would mean removing close to three thousand cars
from the roads of San Jose and from the garages of San Jose State University. This would mean
that the roads would seem a bit more open, and therefore traffic will also move a bit more
 20

smoothly. The students of San Jose State will have to spent less time driving around looking for
parking, thus consuming less energy and producing less waste.
Knowing that the solution is carpooling has still not encouraged a huge increase in
carpooling, so focusing on finding new forms of encouraging more carpooling is also important.
By utilizing smart phone technology, mobile software applications that provide carpooling
solutions can reach an incredibly wide audience. Studies have shown that the more convenient
the carpool solution is for the user, the more likely they will use it (​Ridesharing to work: an
attitudinal analysis​). This also means that having a convenient user interface is also important.
Knowing the target audience is an important characteristic of a successful carpool
solution as well. Starting with the focus on university students may help to build the user base as
younger people are on average more likely to try carpooling (​Household choices of car-use
reduction measures​). Using application to manage the setup and suggest carpool matches
between students can increase the success of the program as a compilation of studies have shown
that the “implementation of a partner matching program, such as a searchable database of
potential carpoolers, was found to be effective in promoting carpooling” (​What encourages
people to carpool? An evaluation of factors with meta-analysis​). Studies have also shown that
carpooling systems implemented within organizations are more likely to succeed (​Evaluating
ride-sharing programs​). Therefore focusing on organization and university-specific grouping
may lead to a more successful carpool solution.

2.3 State of the Art Technologies Summary

by Marta Malapitan and Timothy Davis

Today, there are a number of existing carpool solutions and a single successful smart
parking system. Each carpool solution has different yet similar approaches for carpooling.
Majority of these current carpool solutions are applications, but San Jose State University has
also introduced a new transportation solution that participates in carpooling. Additionally, the
smart parking system has been integrated in a highly crowded shopping mall in San Jose, and
works extremely well as a solution to parking issues. This section will briefly discuss the carpool
and parking solutions that we have considered during the phase of designing UniRide.

Many successful carpool solutions are in the form of mobile applications for portability
and mobility among their users. A number of popular mobile applications that specialize in
carpooling are Scoop, UberPOOL, and Lyft Line. These applications have similar features like
matching users with their neighboring coworkers, providing directions to destinations, handling
payment transactions, providing ability for users to choose who they want to ride with, allowing
users to schedule an upcoming trip hours ahead and other useful features like reminder
 21

notifications. However, while UberPOOL and Lyft Line is for any commuter, Scoop is currently
only used by large companies which are offering carpool services for their employees. Pricing is
unknown for Scoop as it is not open for the public, but UberPOOL and Lyft does their best to
provide a fixed low-cost price for carpooling. With UberPOOL and Lyft Line, passengers who
are located and have a destination that is near another passenger’s destination will automatically
be assigned to drivers. They also allow passengers and drivers to rate one another, as well as
leave reviews. UberPOOL can be used everywhere, meanwhile, Lyft Line is only available in
certain cities. Scoop, UberPOOL and Lyft Line all share common interest in keeping their users
safe, therefore, it is required for drivers to undergo background checks before being granted the
position. These applications are efficient solutions for commuters who are always on the go,
therefore, we have designed our system to be just as portable and easy to use.

There are other forms of carpool solutions that do not require installing applications into
one’s mobile. One was provided by the transportation and traffic information telephone hotline,
511. They released a free ridematch service for commuters in the Bay Area. Commuters will fill
out an online form with their schedule and the service will match them with other compatible
commuters. The user must then contact the other commuter directly via phone or email and set
up a carpool, discussing payment options and carpool details. Though the process may seem
tedious, it provides incentives for those participate. This service offers a tracking feature that can
be used to redeem various incentives and rewards, such as gift cards or specific employee
rewards. 511’s carpool solution provided us the idea of incentives that allows carpooling to be
more appealing to the community.

In addition to the listed carpool solutions, we have also considered Westfield Valley Fair
Mall’s smart-parking system to develop a stronger design for UniRide. Valley Fair Mall had
recently integrated a smart parking system in their newly constructed parking garages that
utilizes state-of-the-art LED lights, motion sensors and photo-sensors. The LED lights are
installed above each parking space, and turns green if the motion sensor identifies the space as
available or red when it’s taken by a vehicle. Also, the photo sensors assist returning shoppers
with finding their car. The sensors can identify where exactly a shopper’s car is based on the
license plate number they enter into the location kiosk. Inspired by such an innovative system to
tackle parking issues, we decided to incorporate such a system with our carpool service.
 22

Chapter 3. Project Requirements

3.1 Domain and Business Requirements

3.1.1 Process Summary Diagram

by Marta Malapitan

Figure 4​: Process Summary Diagram

 23

The process summary diagram in ​Figure 4​ illustrates the process of when our system is
being used by a carpooler. Assuming that the user has already been registered, the user will
interact with the entire system to accomplish arriving safely to their destination while carpooling
with peers, as well as utilizing the parking feature incorporated with our application.

3.1.2 Process Decomposition Diagrams

by Maninderjit Singh, Marta Malapitan and Timothy Davis

Figure 5:​ Parking System Process Diagram

The process diagram of our parking system above displays a breakdown of how it
functions when the system returns an output to our UniRide application that identifies which
parking spaces are available among those that are being monitored by our sensors. It describes
which components within the system are utilized to collect data, analyze data, transfer data to
Amazon AWS and finally, show the available spaces in the application.
 24

Figure 6​: Carpool Process Diagram

The process decomposition diagram above displays the components that are related when
a carpool is created. Like ​Figure 5​, the diagram is a breakdown of how the system functions
during a specific event. In this case, when creating a carpool object, it requires the following
components: a single driver, passengers, source and destination locations, date and time, and
status of the carpool (planned, ongoing, complete, cancelled).

Figure 7.​ Class Diagram of Business Classes

 25

Figure 7​ above illustrates our three businesses classes: user, carpool and parking. It
identifies the dependent relationships each classes have with one another as well as the attributes
of each class.

Figure 8.​ Carpool Process Diagram

The Carpool model and associated controller components are especially important for our
application’s main functionality. The process of the formation and completion of a Carpool is
shown in ​Figure 8​. After a user posts a drive offer post or a ride request post, other users can
respond to the post and join them, creating a planned Carpool object. A Carpool object must
have at least one driver and at least one rider to be considered planned and if at any point these
requirements are not met by the specified departure time, the carpool will be canceled. Once the
 26

carpool begins, the driver proceeds to pick up all passengers until there are none in the list of
passengers that have not been picked up. The carpool is considered complete once the final
destination is reached with all passengers picked up.

Figure 9.​ Parking Spot State Diagram

In order for the system to assign a parking spot to a carpool driver, the system must monitor the
designated UniRide parking spots and know which spots are currently available or occupied by
 27

another vehicle. Each designated UniRide parking spot will have a sensor that will send data to
AWS IoT to let our system know when a spot becomes free or taken. As seen in Figure 9, the
sensor system uses the change in distance between the sensor and the potential vehicle in the spot
to determine the availability of the spot. When the sensor is detecting a change in this distance a
vehicle is either entering or leaving the parking spot. Once there is minimal change in distance,
the sensor sends the availability status (Available or Occupied) to AWS IoT. Once the status of
the spot is stored, the application can access AWS IoT to determine if it should schedule a
carpool driver to park in this space. The system also needs to know if a vehicle parks in the spot
that was not assigned to the parking spot. A validation system will check to make sure only valid
carpools assigned to a particular parking spot are parked in the spot. If an invalid vehicle has
parked in the spot, actions need to be taken to ensure that this spot will not be wasted on the
invalid vehicle. The system should send a message to the parking monitor for the parking garage
notifying them that the parking spot is being misused. This could mean that the invalid driver
receives a ticket or other actions are taken to enforce the proper use of the parking spot.

3.2 System (or Component) Functional Requirements

by Maninderjit Singh, Akshat Sharma, and Timothy Davis

For this application to work with the desired manner we must follow through with the
standard we had set for it during last semester. Table 1 shows most of our functional
requirements.

No. Title Description

2. Sign Up Any user must be able to create an account. An email

address and a password are required to create an account.
An account is required to use most of the application
features, including joining an organization. Membership to
an organization is required to join a carpool.

3. Sign In The registered users must be able to sign into their account
using their registered email address and password.

4. Add Privileged users (such as admins) must be able to add new

Organization organizations. When creating an organization, the
organization’s name, type, and access credential options
(such as the email pattern required to join the organization)
 28

must be specified.

5. No duplicate An organization should not be added if another organization

organizations with the same name already exists. A user attempting to add
a duplicate organization should be notified that an
organization with that name already exists.

6. Join an A registered user for the app must be able to join an

organization organization they belong to, such as a university or other
organization. The user will be able to join the organization
with their credentials for that organization (such as a
university or company email address and corresponding
password).

7. Remove self A user who has joined an organization must be able to

from an remove themselves from an organization they have joined.
organization

8. Offer a ride A user must be able to post a drive offer post indicating that
they are willing to be the driver in a carpool. The post must
specify the source and destination locations, the date of the
carpool, and the time the user needs to reach the destination
by.

9. Request a ride A user must be able to post a ride request post indicating
that they want to be a passenger in a carpool. The post must
specify the destination location, the user’s pickup location,
the date of the carpool, and the time the user needs to reach
the destination by.

8. Post belongs to Every post must belong to a single organization. Only other
an organization members of that organization can view posts under that
organization. If a user is a member of multiple
organizations, then the user must be able to choose which
organization the post belongs to when creating a post.

10. Cancel any A user must be able to cancel any multi-step process, such
multi-step as making a post.
process

11. Delete a post A post can be deleted by the user that posted it.

12. Browse posts A member of an organization must be able to browse posts

for that organization. The post browsing area must be
divided into two sections to separate ride request posts and
drive offer posts. Posts should be ordered by date and
relevance.
 29

13. Search for posts A member of an organization must be able to search for
posts for that organization. The user must be able to specify
the kind of post (drive offer or ride request), the date of the
carpool, the source and destination locations, and optionally
a time that the user would need to reach the destination by.

14. Automatic post When a user posts a new post, the application should
matchmaking automatically display a list of potential posts or open
carpools that meet the requirements for the user’s post. For
example, if the user posts a ride request and there is a drive
offer that has been posted for the same destination, date, and
time, this drive offer will be shown to the user as a
suggested carpool to join (as long as the trip time of adding
this passenger would not exceed the necessary time for both
the driver and the passenger to reach the destination on
time). [See Chapter 5.2 for more details]

15. View all posts A user should be able to view all posts they have made and
view the details of each post.

16. Join in a carpool Passengers must be able to join a drive offer post to form a
carpool, or join an open carpool (a carpool that still has seats
available). A driver must be able to offer to drive for a
passenger (by responding to the passenger’s ride request
post) to form a new carpool.

17. Carpool A user who has joined a carpool should receive notifications
notifications when the carpool is starting, when the user needs to be
available to be picked up (if the user is a passenger), and if
the carpool is cancelled. A user should also be notified when
new passengers are added to the carpool.

18. View all carpools A user should be able to view all carpools (planned,
ongoing, or past) they have been a part of (either as a driver
or as a passenger). The user should be able to view the
details of the carpool.

19. Display map The application must display a map of the route between the
source and destinations on all post and carpool displays.

20. Connect to a The application must be able to connect to a designated

parking lot parking lot with parking spaces reserved for UniRide
application users. The system must be able to monitor the
availability (occupied or open) of each designated parking
space. The system should assign and reserve available
parking spaces when a carpool has started, making sure that
 30

the carpool driver has a space to park in. The system must
verify that the driver parked in the assigned parking space.

21. Validate users The application must be able to validate that each passenger
did actually in a carpool was actually pick up and joined the carpool.
carpool The system must be able to verify that all passengers
reached the correct destination.

22. Tutorial There should be a brief tutorial on each page where the user
has been for the first time to familiarize the user with the
content of the page.

23. Feedback Page There should be a page in the app that allows users to send
feed to the developers.

24. Security The user should have a way to report a driver or passenger
they are currently in a carpool with or have been in a
carpool with.

Table 1 ​System Requirements

3.3 Non-functional Requirements

by Maninderjit Singh and Timothy Davis

No. Title Description

1. Android mobile Application will be used on the Android platform.

application

2. Amazon AWS The application will be integrated to Amazon AWS IoT for
IoT checking if the parking garages of a certain organization has
any empty spots.

3. Google Maps The application will be integrated with Google Maps which
Api will allow users to look addresses for sources and
destinations.

4. Free of charge The application should not cost any money to use and
download.

5. Regular Updates The application should receive regular updates ironing out
any defects or add new features.
 31

6. Google Play The application should be available to download from the

Store Play Store.

7. Data Usage The should use as little data as possible from the user.

8. Coherent Theme There must a consistent theme throughout the application.

Meaning if one page uses material design than all the pages
must also do so.

9. Readily The application will be readily available, meaning it must

Available stay connected to Firebase, and even if it does crash, it
should be back up in a day.

10. Parking check The part of the application that checks for parking
availability availability must come back online within 2 hours of
crashing.

11. Speed of Going from one page to the next must take no longer than
Application 1.5 seconds 99 percent of the time.

Table 2​ Non-functional Requirements

3.4 Context and Interface Requirements

by Maninderjit Singh
Context Requirements​:

No. Title Description

1. Android Studio All team members build and test code using Android Studio
version 3.0.

2. Android testing Application tested on Android OS version 7.1.1, 6.1.1, 6.0.1,

OS versions and 4.4.2.

3. Google Play Follow the launch guidelines specified in the Android

store app development lauch guide
requirements (https://developer.android.com/distribute/best-practices/laun
ch/index.html)

Table 3​ Context Requirements

 32

Interface Requirements​:

No. Title Description

1. Material Design Every application page must follow the standard of Material
Principles.

2. Help There must be a way for the users to get help regarding
features or trouble shooting in the application.

3. Page awareness Users should know which page they are on, meaning there
would be a title on each page.

4. Cancel any A user must be able to cancel any multi-step process, such
multi-step as making a post.
process

Table 4​ Interface Requirements

3.5 Technology and Resource Requirements

by Maninderjit Singh

No. Title Description

1. Firebase The application uses Google’s Firebase for data storage.

2. Android Studio The IDE we will using to work with android applications.

3. Android Phone An Android phone to test the application on.

4. Ultrasonic The device used to physically check for openings on a

Sensor parking spot.

5. Arduino UNO The Arduino will collect data from the sensor.

6. Raspberry Pi The Pi will be connected Amazon AWS to which it will be

sending the data.

7. AT&T shield This device will allow the Raspberry Pi to establish a

 33

connection to the internet.

8. Amazon AWS This part is the link between the parking sensors and the
application.

9. AWS Python This will allow the Raspberry Pi to interface with AWS.
SDK

10. Java This is the development language for the Android

Application

11. Python Is used to write the script that analysis the data from the
Arduino and sends it to AWS.

12. C The programming language that Arduino uses.

13. Google Maps Is what the Android application uses to use Google Maps in
API the application, and allows people to search for addresses.

Table 4 ​Technology and Resource Requirements

 34

Chapter 4. System Design

UniRide is composed of two major components. It has a software component that
includes the Android mobile application and Firebase Database. The UniRide mobile application
uses an MVC architecture, Google Maps API and Material Design to style the user interface.
This UniRide component handles all user interactions and it allows users to create and join
carpools together. Opposite of the software component is the hardware component. UniRide’s
hardware component utilizes IoT technologies such as ultrasonic sensors, an Arduino, Raspberry
Pi, Avnet Cellular Shield, and Amazon AWS. Its purpose is to monitor parking spaces within the
campus and assist users with parking once in the facility. Data gathered from the parking system
will be mirrored on the software component, the mobile application.

4.1 Software Component: Mobile Application

4.1.1 Mobile Application Architecture Design

by Timothy Davis
 35

Figure 10.​ Android application architecture overview diagram. Shows the general
Model-View-Controller architecture of the UniRide Android mobile application.

The project architecture is based on a Model-View-Controller (or MVC) architecture,

where components are classified under one of these three types.

The model components store the data that the application stores and accesses. This
includes a database that the team will create and maintain, and will store the main application
data such as data about user information, user posts, organization information, and trip data. Our
team plans on using a Firebase database. The application will also rely heavily on route, traffic,
and location data provided by the Google Maps Application Programming Interface (API).

The view components present the user interface. Android uses a number of predefined
layouts that are written in XML to define how the data and UI components should be displayed.

The controller components are the segments of code that make up most of the logic in the
system and link the data in the model components with the view components. These components
request data from the model components, then determine what data the view components should
be presenting. In an Android application, these components are Activity classes that manipulate
data to perform an action to be displayed to the user and services that perform actions behind the
scenes. Some of these services require access to additional services outside of the application,
such as email services.

Our architecture also shows device components that the controller components utilize.
These components are tied to the user’s physical device, and include location and notification
components. The location is the user’s location given from GPS that the device will provide to
our application. Our application will also provide notifications to be displayed by the mobile
device’s operating system.
 36

4.1.2 Firebase Database Design

by Timothy Davis

Figure 14.​ Firebase database tree structure

UniRide connects to a Firebase Realtime Database to store all persisted data. The
structure of the database can be seen in ​Figure 14​. This data includes user information, such as
name and email, university or organization information, such as location and website, and post
information, such as trip date and time. There are three types of posts. Ride requests are posts by
users looking for a carpool. Drive offers are posts by users who are offering to drive passengers
and carpool posts store the driver and all passengers in a carpool.

Since Firebase uses a tree structure to store data, each main model component has its own
branch, with further branches for the unique ID and data (the stored records for the model
component). Each major many-to-many relationship between the model components also has a
branch that connects the model components by their respective ID’s. For example, the User
branch is connected to the Organization branch, as each user can belong to multiple
organizations. Each user can also have multiple posts of each type.
 37

4.1.3 Mobile Application Interface Design

by Akshat Sharma and Marta Malapitan
 38

Figure 12.​ User Interfaces of UniRide Android Application

The figure above illustrates the design of our application user interfaces. It displays a
clean, professional and appealing user interface for our users to interact with. We chose colors
that are attractive while also keeping the display simple to avoid them being an eyesore. ​Figure
12​ has the following screens: login page, home page, process to request a ride, viewing an
existing carpool, and how the data captured by the sensors would be displayed on the
application. To avoid redundancy, we have only included views of process to request a ride as it
is similar to the process of offering a ride.
Using the figure above as reference, every user input retrieved from the text boxes are
instantly saved into our Firebase database. Data are stored in the proper branches like user
information is saved under the “user” branch in the database, and carpool details are saved under
the “carpool branch.”
 39

4.2 Hardware Component: Parking System

​4.2.1 Parking System Sensor Hardware Architecture Design

by Marta Malapitan

Figure 11.​ Parking System Architecture Design

The Parking System that will be integrated with the mobile application requires multiple
components, as shown in ​Figure 11​. Each parking space that is part of the system will have a
sensor that determines if a vehicle is parked on the parking space. The sensor will provide this
information to the AWS IoT Platform service through the Arduino and Raspberry Pi. The
UniRide mobile application will then take the data from the AWS IoT Platform service and use it
to pair the user will a parking space and validate that the user parked in a space is the designated
user assigned to that parking space.
 40

4.2.2 Parking System Design

by Maninderjit Singh

Figure 15.​ Components of UniRide’s Parking System

The figure above shows the following components of UniRide’s parking system: Ultrasonic
Sensor, Arduino, Raspberry Pi, and Amazon’s AWS IoT Platform service.

Our Android application makes use of the technologies above to update the status of the
monitored carpool parking spaces within the parking garage. The purpose of this component of
the project is to provide parking assistance for carpoolers to reduce the amount of time spent to
find parking.

Using​ Figure 15​, the following details describe the flow of the prototype from left to right:
1. The ultrasonic sensor will sense if the monitored parking space is available or taken by
detecting if there is an object in a short distance away from the sensor.
2. The ultrasonic sensor will then send the collected data to the Arduino it’s connected to.
3. The Arduino does not store the collected data, therefore, it sends the data to the
connected Raspberry Pi, which analyzes and configures the data received.
 41

4. After the data has been analyzed, the selected data will be sent to Amazon’s AWS IoT
Platform as the Raspberry Pi is connected to the Avnet Cellular Shield that provides
access to the internet.
5. The UniRide mobile application will then be connected to the AWS IoT Platform so that
the information collected will be visible to the users in real time.

4.2.2 Class Design

by Timothy Davis

Figure 13.​ Simplified UML Class Diagram. Shows the main model classes and their inheritance
and aggregation relationships.

The application architecture will be structured around the main model components shown
in ​Figure 13​. The main model components are:
● User​: the model component that represents the user and stores all personal data required
for the user.
● Organization​: the model component that represents the organizations and universities
that a user can join. Each post is associated with an organization and only other users
who have also joined this organization can respond to the post.
● Post​: the model component that represents the user offering to be a driver or a passenger
for a carpool trip. There are two subclasses: Ride Request, which represent the posts
where the user plans to be a passenger and is looking for a driver to take them to their
 42

destination, and Driver Offer, which represent the posts where the user plans to be a
driver and is looking for passengers to join.
● Vehicle​: the model component that represents a vehicle owned by a driver, storing data
such as the make, model, year, license plate number, and maximum number of seats of
the vehicle. A user can store a list of vehicles that they own and can choose to use for a
carpool they are driving for. Each carpool only uses one vehicle for the trip.
● Carpool​: the model component that represents a planned or ongoing carpool trip with
multiple users. A Carpool object is created once a passenger joins a drive offer post or a
driver joins a ride request post. The carpool object can only have one driver but can have
a list of multiple passengers. Each post can only belong to one Carpool object, if one has
been created.

Each model component will be associated with a number of Android Activity classes and
Fragment classes, as well as a number of Android Layout files. The typical Activity and
Fragment classes associated with each model class include “Detail” Activities (that show the
details of one record of a particular model component), “New” Activities (that are used to create
a new record of a particular model component), and “List” Fragments (that are used to display
different lists and ordering of all records of a particular model component, or just a subset of
them).
The main model components have the following relationships, also shown in ​Figure 14​:
● Each ​user​ ​joins​ one or more ​organizations
○ Each ​organization​ is ​joined by​ many ​users
● Each ​user​ ​posts​ zero or many ​posts
○ Each ​post​ is ​posted by​ exactly one ​user
● Each ​user​ ​owns​ zero or many ​vehicles
○ Each ​vehicle​ is ​owned by​ at least one ​user
● Each ​post​ is ​associated with​ exactly one ​organization
○ Each ​organization​ ​has​ zero or many ​posts​ associated with it
● Each ​post​ ​links​ to zero or one ​carpool
○ Each ​carpool​ ​links​ to one or many ​posts
● Each ​user​ can ​drive in​ zero or many ​carpools
○ Each ​carpool​ is ​driven by​ exactly one ​user
● Each ​user​ can ​ride in​ zero or many ​carpools
○ Each ​carpool​ is ​ridden by​ one or more ​users
● Each ​carpool​ is ​driven using​ exactly one ​vehicle
○ Each ​vehicle​ can be ​used to drive in​ zero or many ​carpools
 43

4.3​ ​Structure and Logic Design

4.3.1 Parking System Algorithm

by Maninderjit Singh and Akshat Sharma

The first algorithm is for the Arduino UNO which is the interface for the Ultrasonic
sensor. Although the file containing the code is much bigger than this, here is the brief
description of what the code primarily is supposed to be doing. The pseudo code in the figure
below is in style of C, because that’s the language that the Arduino uses.

while (true) {
current_dist = get distance from sensor;
if (current_dist is a significant amount bigger than previous_dist){
Output this value;
previous_dist = current_dist;
Wait for 500 milliseconds;
}
Wait for 1.5 milliseconds;
}

Figure 16.​ Arduino R3 UNO - Pseudo Code

There are three different Python program files that are working on the Raspberry Pi. The
first file is briefly explained in the first section of the figure below. The second section is about
the second file that runs parallel to the first file and needs the first file to run properly for it to
work properly. The third and final section is about the third file, which is used by the second
section.

The following equations are being used. The x is the position of the y, and y is the
distance recorded using the sensor and the Arduino:

m−1
J (θ) = 1
2m
∑ (hθi (xi ) − y i )2
i=0
Which is minimised by optimization of theta values (factor weights) using the batch gradient
descent equation:
θj = θj − α δθδ j(θ0 , θ1 , θ2 , ...θj )
j
 44

#------First section-----------
#set the connection to the arduino
establish a connection to the Arduino output port through the Raspberry Pi
Output the Arduino's output to a file on Raspberry Pi

#------Second section----------

#The output.txt file mentioned below is the one that the distance data
# from the Arduino is being stored in on the Raspberry Pi
#The state is the state of the parking spot this system will be deployed on

while(true)
Periodically check for new data in the output.txt file
and store it in an array
if (array is not empty)
Calculate linear regression of the distances in the array
Slope = Slope of the line produced in the step above
Set the state according the slope found above
Clear the array
if (slope changed)
Send the appropriate state to AWS
After 9 seconds clear the output.txt file's content

#------Third section-----------

#For AWS
Establish connection with the proper device on AWS
Send the passed in response to AWS

Figure 17.​ Raspberry Pi - Pseudo Code - Python

4.3.2 Search Algorithm

by Akshat Sharma and Timothy Davis

The search algorithm utilizes a variation of weighted squared error function, where the
weights are provided by the user. The algorithm first initializes a list of input where each element
corresponds to source, destination, and theta in the respective order. It also gathers a list of
carpools and posts that are potential candidates for a good match with the given list of inputs.
Each element of this list is a post, and each of these posts have their own source, destination,
and theta. The last variable used is the feature weights, which are also given by the user in terms
of how flexible they are with each of the factors from a scale of 1 to 10. For example, if a user is
very flexible with their timing, they may enter a value of 8. This value will then correspond to a
normalized value of 0.8 and will give extra weight to the time factor. Each factors of the input, as
well as potential posts, are also normalized. The normalization function used is:
 45

current value
normalized value = max value

With all of these values acquired, the algorithm calculates the difference between each of
the factors, squares them, and multiplies them with the added weight. Upon a summation of all
of these values, the result acquired would be a variation of weighted squared error that would
determine whether a given post is a good choice or not. The smaller the value, the better the
match. The equation for this algorithm is:
2
︿
S quared Error F unction = ∑ θi (y i − yi )2
i=0
︿
Where θ is the weight, y is the value from the given post, and y is the input value given
by the user searching. The summation goes from 0 to 2 since there are three factors to be added:
source, destination, and time.
items = list of potential carpools or posts
source, destination, theta, date = search inputs by user #inputs
input = [source, destination, theta]
normalize(input)
feature_weights #given by users where all the weights are between 0
and 1

search_result = []
for item in items{
normalize(item)
result = (input - item)^2 # element based operation
result = dotProduct(result, feature_weights)
search_result.append(result)
}

return search_result

The algorithm for determining which posts should be matched is displayed below:

# Determine posts to display in match:

# step 1: filter post type by user's role:

if ​user_role = driver​ {
all_potential_posts = filter to only have ride-request posts.
}
else if ​user_role = passenger​ {
all_potential_posts = filter to only have drive-offer posts
 46

or carpool objects where num_seats_available > 0

}

# step 2: filter posts by date:

for (post in all_potential_posts) {

if user_search_date == post.date { add post to updated list }
}

# step 3: filter potential carpools based on general area:

all_potential_posts = filter based on sub-algorithm as described in the

algorithm above.

# step 4: filter posts based on whether all users can guarantee that the
potential carpool will reach the destination on time:

user_dest_time = time user must reach the destination by

for (post in all_potential_posts) {

post_dest_time = time the other user must reach the destination by

part_a = time from driver to passenger location

part_b = time from passenger pickup location to final destination

if (start_time + part_a + part_b) < user_dest_time AND post_dest_time {

add post to updated list
}
}

return all_potential_posts
 47

Figure 18.​ Matchmaking Algorithm Flowchart

Figure 18​ explains the process in a flowchart. The algorithm works by getting posts from
Firebase that are from the same organization and are on the same day as the selected post. It also
makes sure that if a user is looking for a ride, then the matched posts will only be drive offers.
The application then uses Google Maps Directions API to check that only posts that form valid
carpools will be matched. A carpool is considered valid if all passengers will reach the
destination on time. The user is then shown a list of matching posts which they can join.

4.4​ ​Design Constraints, Problems, Trade-offs, and Solutions

4.4.1 Design Constraints and Challenges

 48

by Timothy Davis and Akshat Sharma

As we chose to design a mobile application, one of our first challenges was deciding
which platform to develop for. Because each operating system provides its own unique
challenges and benefits, we had to decide what aspects were important considering a prototype
application. Considerations for choosing which operating system to develop for include the
number of users of the particular operating system, the time it takes to learn the operating
system, and the resources the operating system provides and is compatible with (especially
mapping APIs available). The main two operating systems we considered were iOS and Android,
the two most popular mobile operating systems.

Depending on which system we chose, we would have to dedicate time and other
resources for learning the system and developing our application for it, so we had to determine if
it was worth it to develop for both operating systems or to just focus on one for the purpose of
creating our software prototype. Other resources include testing equipment, such as the specific
mobile devices that run the chosen operating system and which versions of the operating system
were compatible with which mobile devices. There are also many constraints on testing our
project, especially limited access to certain testing environments. We cannot reasonably test our
application a large range of device types and sizes without first acquiring this hardware. We also
cannot test our application on every possible version of the operating system we choose. It will
also be difficult to extensively test our application in its final environment: on the road and inside
parking garages. Another testing environment constraint will be testing the reliability of the
application with a large number of users accessing the system at the same time.

One important design constraint is the database that the application relies on. In choosing
a database we had to consider the flexibility of the database structure, the convenience to manage
the database, the cost of the database service, the ease of installation and hosting of the database
on a server accessible to our application, and the security and reliability of the service. We had to
consider if we preferred a traditional relational database and the structure it provides, or if the
freedom a non-relational database would be more convenient for our project.

Another one of our major design concerns is providing apt incentive for the uses.
Formation of a concrete user base is very essential for the success of any application. And
therefore, one of the incentives could be to provide verified drivers with parking spots. However,
the parking spots would have to be provided by the university. Moreover, the price of these
parking spots would have to be lower than the normal price of parking permit. But none of this
would be implementable if the university does not wish to support a carpool system. In that case,
a possible solution could have been to introduce money exchange amongst drivers and riders, but
that would not be possible due to legal complications.
 49

Another constraint is that some parking structures do not have wifi connectivity,
therefore, a traditional sensor setup would not be effective. Since the sensor would not be able to
connect with the servers, preventing the data transfer amongst sensor and user devices.

4.4.2 Design Solutions and Trade-offs

by Timothy Davis and Maninderjit Singh

Our group decided to choose Android as the mobile operating system we will develop our
application for. We chose to start with Android only for our prototype for a number of reasons.
One reason is because Android is currently the most-used mobile operating system, both globally
and in the U.S. Another reason is because the majority of our team members have access to
Android mobile devices, making testing more convenient. The fact that iOS development is
easiest on Apple computers and that most of our team members do not have access to these
computers, is another important reason for choosing Android. Another reason is because the Play
Store for distributing Android apps is far easier to get access to compared with the App Store
that offers iOS applications. Because our team has very little experience with mobile
development, choosing to develop exclusively for Android and not spending extra resources
trying to develop for iOS as well is the better choice for our team. We also recognize that this
application, while it should be usable, is primarily a prototype and can be expanded upon and can
be developed for iOS in the future.

We chose Firebase as our database service. The service is free to start and the Realtime
Database feature provides a flexible non-relational database structure that lets us determine our
data structure needs as we go. The service also has an extremely convenient web console that
allows complete access and management to the database from anywhere and the service hosts the
data online without any external requirements. Firebase also has an easy-to-use API for Android
and provides plenty of official tutorials and sample code resources.

For the parking lot incentive constraint we have come up with the solution of maintaining
the app’s integrability with the explained idea. At the same time ensuring the possibility of a
testing phase where a mock span of the application can be set with fewer parking spots and users
in order to generate viable results. Which could later on be used as a proof of efficient to help
university decide its implementation.
 50

In order to connect the devices installed in parking structures with servers, we have
decided to add another module to the hardware setup: an AT&T cellular shield that can utilize
the LTE connection to send and receive data from the servers.
 51

Chapter 5. System Implementation

5.1 Implementation Overview
by Akshat Sharma

UniRide has a hardware, as well as software components to it. The most essential
software portion is the application itself, and with it being an Android application, Uniride is
majorly implemented using Java 8 and XML. The Application uses Firebase as its major
database, and is developed using Android Studio as the main IDE (Integrated Development
Environment). Furthermore, the hardware sector of Uniride comprises of the parking system
which utilizes Arduino Uno, Raspberry Pi 3, and ultrasonic sensor. The software portions of the
parking system alone is written in C for Arduino functionalities, and Python 3 for the rest. Which
included the script for identifying the state of the parking spot, and AWS Python SDK which
sends the identified status to AWS IoT via MQTT topics.

The main implementation scope of UniRide consists of the user being able to create or
join an organisation, submit a post, browse through existing posts, and create or join a carpool.
Where a carpool is a model that consists of a potential carpool with a driver, and several riders.
Along with these major models, the application consists of two main functionalities: search, and
carpool validation. The searching involves queries based on the searcher’s source, destination,
time, and date. Carpool validation on the other hand, takes place while a carpool trip is going on.

5.2 Implementation of Developed Solutions

by Akshat Sharma

UniRide is developed upon traditional model-view-control methodologies. The major

models being, User, Post, Carpool, and Organization. The post model is divided into two
subcategories: Drive Offer and Ride Request. Drive offers are created by drivers, while ride
requests are created by riders looking for a potential carpool. Upon a successful match, the driver
may create a Carpool instance that takes on the maximum number of seats available from the
driver’s post. A carpool object must have exactly one driver, and at least one rider in order to
exist. Furthermore, for search, the algorithm takes in source, destination, time and date. Where
source and destination are mandatory while date and time are optional parameters. The algorithm
takes in the addresses and searches for similar posts in a circular region on the map where the
diameter of the circle passes through the source and destination locations of the subject query.
 52

Which allows the algorithm to not only match posts with similar source and destination, but also
to pair with posts whose route passes through or near the query source and destination addresses.
The other major functionality, carpool validation, uses various factors such as GPS location of all
the users involved in the carpool, and QR code generation and detection to verify that a carpool
trip took place under valid circumstances.

Furthermore, Uniride consists of two major algorithms: the parking sensor algorithm, and
the search algorithm. The parking sensor calculates distance of any object away from it. The
sensor performs this action at a rate of one recording every 2-3 seconds. The algorithm takes in
recordings from past 30 seconds and generates a gradient of all the recorded values by
considering a plot where y-axis is distance, and x-axis is time. The algorithm then sends the
status change to AWS and confirms the change by checking whether the distance remains
constant for next 1.5 minutes. The algorithm goes in a semi-idle state after the confirmation.
While in a semi-idle state, it checks for any change every 5 minutes, and initiates a 30 second
check if it detects any significant change.

The search algorithm is responsible for facilitating a search functionality. The algorithm
takes source, destination, time, and date as the inputs. These inputs are entered by the user trying
to search, and based on these factors the algorithm searches through the existing set of both,
posts and carpools. The algorithm first narrows down its search domain by only including posts
with same dates. It then narrows it further by considering an oval with the input source, and
destination points at its foci. The algorithm searches for any posts or carpools whose routes fall
under that oval while also including a vector factor that ensures the considered results are
moving from source to destination and not the other way around. Finally, the search results are
narrowed, and sorted based on the time factor. The user can choose a time deviation factor that
will be used by the algorithm to decide the final results.

5.3 Implementation Problems, Challenges, and Lessons Learned

by Akshat Sharma

One of the major implementation challenge has been to access multiple attributes from
different Firebase tree at the same time. Firebase utilizes database snapshots generated, and we
have had trouble acquiring snapshots of two tables where an activity requires attributes from two
different tables at the same time. We have decided to solve this problem by creating separate
tables for each of the models whose attributes are required in the same android activity.

Another challenge has been to devise a system to validate a carpool. This system would
have to ensure that some, or all of the riders took part in the carpool in order to assign a parking
 53

spot for the driver. We chose to do this with a tier based system where the several tiers are
comprised of GPS location of all the users involved in a carpool, and passengers can be verified
via NFC between phones, or entering randomly-generated codes or scanning QR codes. To
verify the carpool has reached the correct destination, the user must respond to a notification on
their phone to confirm the correct designated parking spot was taken. The only drawback of this
method is that it requires the device to be connected to internet at the end of the carpool. Another
approach that could be implemented in the future would be to have a camera scan the license
plate of the vehicle entering the parking spot to validate that it belongs to the vehicle registered
for the carpool.
 54

Chapter 6. Tools and Standards

6.1 Tools Used

Tool Name Tool Use

Software Development

Android Studio Application Development (IDE)

Firebase Dashboard Database Management

Firebase Cloud Function Hardware Integration / Notification

Management

Google Maps APIs Map generation, distance and route

information

Hardware Tools

Raspberry Pi Hardware Management

Ultrasonic Sensors Vehicle / Movement Detection

Raspberry Pi 3 Data analyzation and signal sending to AWS

Arduino Uno Data gathering from

ATT Shield Establish internet connection

Version Control

GitHub / Git Application Version Control

Communication

Google Drive Document Repository

Slack Group communication

Google Hangouts Group communication (video calls)

Canvas Event Tracking (Calendar), Communication

 55

Table 6.​ Tools Overview

6.1.1 Application Development Tools

by Akshat Sharma, Maninderjit Singh, and Timothy Davis

The primary tool to develop the application was Android Studio. Android Studio is an
Integrated Development Environment (IDE) based off of the IntelliJ IDE and is designed
specifically for Android mobile development. Android Studio was selected because it is the
official Android development IDE supported by Google and it is free to install and runs on Mac
OS, Windows, and Linux operating systems. Each developer had a copy of the software on their
local machine. All lines of the code written for the mobile application were written in Android
Studio. Android Studio comes with easy Firebase integration and other SDKs that made
communication with other external development tools, such as Google Maps APIs, relatively
simple.

For database management, we used the Firebase Dashboard web application. Developers
can log in with their Google account and view the database schema and all database records,
except for secure information, such as user passwords. Because Firebase is a cloud application,
these records include all of the records from all devices that are running the associate mobile
application because each device connects to the database over an internet connection. Records
can be manually edited or deleted from within the dashboard as well. Developers used this tool
to make sure the correct data was being stored in the correct structure and that communication
between the application and the database worked correctly. We chose Firebase because it is
extremely simple to setup and connect with Android applications.

For managing the communication channel between the parking space sensor and the
application, we plan on using AWS IoT Services and Firebase database. Essentially, the
Raspberry Pi analyzes the data received from the sensors and sends it to AWS IoT dashboard via
an MQTT topic. We are using Amazon’s Python SDK for MQTT publication and subscription to
topics. We plan on setting up an AWS Lambda function that sends the received data to Firebase
Database. The android application can then be notified of availability of this data and fetch it
from Firebase Database with ease. We chose AWS IoT services because of the availability of
documentation, and ease of integration with Firebase Database. We considered using Google
Cloud Iot since it would have been seamless along side of Google’s firebase database. However,
we found it to be complicated to integrate due to our lack of experience with the framework.

For managing the asynchronous notification features of the application, we plan on using
Firebase Cloud Functions. Firebase Cloud Functions is another functionality of Firebase which
 56

allows us to have server side functions that do jobs such as push notifications based on time,
matches of a certain thing found, upcoming events etc. for the users of the application. Since our
application is storing its data in another Firebase service, called Firebase Database, the
integration of the two, cloud and database, services might be considerably easier than if we were
to do use a similar but external service to Firebase Cloud Functions.

6.1.2 Application Version Control Tools

by Timothy Davis
Developers used GitHub to host the application code repository and used Git for the
application version control. Our team chose to use GitHub because of its popularity and
simplicity and because our team was already familiar with it. We used Git to concurrently
develop code on our local machines, push code to a single shared online code repository, and
manage any conflicts between developer code changes. Each developer had a GitHub account.
GitHub was also used to track the progress of various features through development branches,
which also allowed for the team to manage which developer was working on which features. All
code changes were also recorded on GitHub.

6.1.3 Group Communication Tools

by Marta Malapitan
We used Slack as our main communication tool. Slack has a desktop and mobile
application that instantly notifies each of us when responses were sent to our group and direct
messages. We use Slack to share important project files, inform one another on bugs that were
found, send reminders on what needs to be done, and task assignment. With Slack’s channel
feature, we’re able to easily organize the discussed topics and shared files by creating separate
channels for required purposes.

In addition to Slack, we utilize Google Hangouts to work together remotely. While most
group members are often able to meet in person, it is likely some are not able to. Therefore, we
use this tool to update one another on missed information from in-person meetings as well as
general voice and video communication. Google Hangouts also has a screen-sharing feature that
we use for bug and progress tracking.

We also use the learning management system, Canvas, for event tracking and as an
alternative tool for communication. Canvas is integrated with the university’s system as a student
resource. Students will find information about upcoming events, assignments, midterms and
general information about the current courses they are taking in a semester. Our group utilizes
Canvas to keep track of upcoming assignments and task deadlines. This helps us organize our
project schedule and plan accordingly. Canvas also supports direct messaging between students
and professors. Thus, if for any reason Slack, Google Hangouts and our email service providers
 57

fail, we can use Canvas to contact one another.

 58

6.2 Standards

6.2.1 Design Standards

by Akshat Sharma
We decided upon majorly utilizing Google’s Material UI as the global standards for our
application. Material UI uses the various design philosophies such as material, lighting,consistent
visual language, and motion. Android’s Material UI framework includes default UI elements that
have been designed on the basis of Material principles. We used the same framework, and
modified it around the same principles.

● Color Schemes

Main Application Color Scheme

Color Scheme for Specified Purposes

Figure 19.​ Color Schemes

We used a set of various shades of blue for the major color scheme of our application.
We also used a set of complementary colors used throughout the app with each serving a specific
set of purposes in the application’s user interface. The generated palettes using Colormind.io.

● Buttons

Figure 20.​ Button Preview

 59

For consistency, we used the same style for every button throughout the application. It
provides a repeating visual queue for a possible action to be performed.

● Colored Post Forms

Figure 21.​ Request a Ride Post Forms

● Gradient Backgrounds
 60

Figure 22​. Login and Sign Up Views

A distinguished gradient background for sign in and sign up pages in order to provide a
highly distinguishable visual queue for important input fields such as email address and
password.

6.2.2 Documentation Standards

by Marta Malapitan
In addition to a working system, our documentation is a significant aspect of our project.
We have recorded every aspect of our project in this document and provided a substantial
amount of detail about our project goals and objectives, research, system design, project
requirements, and system implementation. To ensure readability, we kept a consistent format and
style throughout the document, and we included user-interface mockup screenshots and diagrams
to display our intended work and progress.

6.2.3 Version Control Standards

by Akshat Sharma
We used GitHub as our version control platform. The standards of our version control involved a
few major aspects: repositories and branches.

● Repositories​: We set up an ‘origin’ repository in our GitHub organisation, and every

member of our team forked it in order to create personal repositories. For the most part,
every member worked on their own forks and updated the ‘origin’ repository whenever
required.

● Branches​: The origin repository had two main branches, master and develop. Except for
some cases, these branches never received directly pushed code, and were never used as
the base branches for development of any functionalities. Each new feature or aspect of
the application received its own branch in the origin repository. Each member managed
their repositories as per their own preference. Functionality code were pushed to their
respective branches in the origin from the member repositories, and upon completion of a
functionality, it’s branch was merged into develop via a systematic pull request with
functionality branch as the base. Upon completion of a certain number of functionalities,
the develop branch is merged with master.
 61

Chapter 7. Testing and Experiment

7.1 Testing and Experiment Scope
by Marta Malapitan

Our prime objective was to create a completed system that is optimized and bug-free. To
achieve this goal, frequent testing was required in the following areas: user-interface output,
Firebase query output, search algorithm output, sensor behaviour and output, and route results.
For each area, we performed unit testing, and used a combination of the white-box, black-box,
and gray-box testing. White-box testing was performed in areas that required extensive code
analysis such as the search algorithm, sensor functions, and routes created with input locations.
We carefully examined the data flow and control flow of each function to ensure they will output
correct results. These areas depended on other areas of our application, thus, integration testing
was essential for every stage of progress. Meanwhile, black-box testing was vital for design
phases and use of outside resources like Firebase and APIs. For this large group project, tasks
were divided among the team, and tasks that were completed by each member were tested by
other team members. To follow gray-box testing, we initially tested one another’s features with
little knowledge of how the source code was written and analyzed the results as well as its
performance.

7.1.1 Test Process of User-Interface

Figure 23.​ User-interface Components and Output

1. Modify user-interface components in the corresponding XML files in Android Studio.

2. Run the application on an Android device to display the actual user-interface that users
will be interacting with.
 62

3. Test each component in the user-interface to ensure functionality. Text fields must be
able to receive user input, buttons should be clickable and must perform an action when
pressed, intended color scheme and layout must be the same as what was coded, and
animations and images must be visible and positioned in the chosen activities.

7.1.2 Test Process of Firebase Query

Figure 24.​ Firebase Query and Database Results

1. Application is ran on an actual device.

2. User and application interactions such as entering data, pressing a button or using other
widgets that modifies the database must reflect in the Firebase database.
3. Perform the actions above and check Firebase database to ensure data within the database
is added, modified or deleted as instructed.

7.1.3 Test Process of Search Algorithm

Figure 25.​ Search Algorithm Preview

1. Analyze the code thoroughly and examine data flow and control flow
2. Run the application on an actual device
3. Perform the necessary actions to test the search algorithm
 63

4. Check the outputs to ensure they are the appropriate results

7.1.4 Process of Sensor Data Accumulation, Analyzation, and Publication

Figure 26.​ Functions that Send Commands to Sensors

1. Review the code of the function that commands sensors to retrieve the required data
2. Making sure the sensor and Arduino’s outputs are expected.
3. Ensuring the recorded data is being written into a file without any errors.
4. Making sure the file status is never corrupted, and the read data gives expected outputs.
5. Checking the MQTT topic is being published properly.
 64

7.2 Testing and Experiment Approach

by Marta Malapitan, Timothy Davis, Akshat Sharma, Maninderjit Singh

As our system consists of two large components–software and hardware–we have two
different testing environments for the features within either component. To test our features that
live in our application, we use Java, Android Studio, an actual Android device, and the Firebase
database. For our parking system, we utilize the components that make up the parking system: an
ultrasonic sensor, Raspberry Pi, Arduino UNO, Arduino IDE, internet connection, AWS IoT
along with Python, C, Numpy and Matplotlib Python libraries, a text editor and the
command-line interface.
Our actual test strategy consists of a number of different possible conditions with more
than one test case, however, the documented test strategy is more condensed for clarity. In this
document, the test strategy for our application consists of a minimum of two different conditions
with at least one test case. The table below shows our testing method with the data inputted or
action done, as well as the expected output with a brief description.

Test Case Input / Action Expected output

1 Data input by current user Database modified

2 Action performed by current user UI displayed / database modified

Table 7.​ Testing Table Structure

7.2.1 Test Approach for User-Interface

Condition 1: Loading Post Feed

Ride Request Post Feed

Step 1: Current User Navigates to Driver Page

 65

Expected Output and Result

● User should be shown the Post Feed page.

● Only Posts of type Ride Request should be displayed.
● Only Posts of the user’s default organization should be shown when first loaded.
● No more than 100 posts should be displayed in the list.
● The post list must be scrollable.
 66

● A “Offer New Carpool” button should be displayed.

Table 8.​ Loading Post Feed Test

Condition 1 Test Summary:

After a current user has navigated to the home page and pressed the “Offer Drive” button,
the user should be directed to the Post Feed interface. This display must show a list of only Ride
Request Posts that belongs to the user’s default organization that was created by other users and
is stored in the database. There should be no more than 100 posts visible in the list and the “Offer
New Carpool” should be displayed. This is expected to pass as the code has been analyzed and
enhanced several times.

Condition 2: Showing Post Details

Step 1: User Presses a Post icon on Post list

Expected Output and Result

 67

● User should be shown the Post Detail page.

● The post’s source and destination should be displayed.
● The post’s date and arrival and departure time should be displayed.
● If the post is not the user’s post, a button for forming a carpool with the post should be
displayed.

Table 9.​ Showing Post Detail Test

Condition 2 Test Summary:

When a user presses a Post icon on the post list, the interface must change to the Post
Detail page. This page should include information about a user’s planned trip information
including their source and destination locations, arrival and departure time, and the date of the
trip. If this post was not created by the current user who is browsing, a button will be displayed
that allows the current user to join a carpool with the desired user. As long as there is at least one
post that exists in the database, this test should pass.

7.2.2 Test Approach for Firebase Query

Condition (Query) 1: Get All Posts in an Organization

Input: Firebase Query

 68

FiebaseDatabase.child("organization-posts").child(getSelectedOr
ganizationId()).child("driveOffers").limitToFirst(100);

Expected Output and Result

● A list of 100 or fewer posts.

● All posts should be of type Drive Offer.
● All posts should be from the selected organization.

Table 10.​ Get All Post in an Organization Test

Algorithm Process
1. Navigates to the “organization-posts” main database branch.
2. Navigates to the sub-branch with the selected organization ID.
3. Navigates to the sub-branch named “driveOffers”.
4. Retrieves a list of the first 100 posts in the sub-branch.

Condition 1 Test Summary:

The application back-end should navigate through the Firebase database to the instructed
branches and pull a list of the first 100 posts in the final sub-branch. In this condition, every post
retrieve should be a Drive Offer type belonging to the organization selected by the user. As this
query has been carefully created, this test should pass.
 69

Condition (Query) 2: Retrieve All Posts With Selected Date

Input: Firebase Query

FiebaseDatabase.child("posts").child("driveOffers").orderByChil
d("tripDate").equalTo(selectedTripDate)

Expected Output and Result

● All posts should be of type Drive Offer.

● All posts should be from the selected trip date.

Table 11.​ Retrieve All Posts With Selected Date Test

Algorithm Process
1. Navigates to the “posts” main database branch.
2. Navigates to the sub-branch named “driveOffers”.
3. Retrieves a list of all posts in the sub-branch with a “tripDate” attribute equal to the
selected trip date.
 70

Condition 2 Test Summary:

When the query is executed, the database pointer will navigate through the branches in
the database and land on the “driveOffers” branch where it will pull a list of posts with the
chosen trip date. Like the first query, this is also expected to pass.

7.2.3 Test Approach for Search Algorithm

Condition 1: Find Matching Ride Request Posts

Input: User’s Drive Offer Post

User Post: DriverOfferPost@4355a790

with source = 456 S 2nd St, San Jose, CA 95113, USA
and destination = 1 Washington Sq, San Jose, CA 95192, USA
depart @ 6:26 / arrive @ 18:26

Expected Output and Result

- Looking at postToCheck[0]: RideRequestPost@43831760

with source = 567 N 2nd St, San Jose, CA 95112, USA
- Looking at postToCheck[1]: RideRequestPost@9432473
with source = 789 Race St, San Jose, CA 95126, USA

● A list of Ride Request Posts.

● Only posts with trip date same as user’s post.
● Only posts with the same organization ID.
● Only posts with the driver’s departure time before the necessary time to leave so that
the destination is reached by the earliest arrival time of all the posts.

Table 12.​ Find Matchmaking Ride Request Posts Test

Condition 1 Test Summary:

The only parameter that our search method will take in as an input is a user’s Drive Offer
Post. The search algorithm must then be able to use this Post to list Ride Request Posts that
matches the same trip date as the current user’s post as well as the organization they are joined
in. Additionally, it will only consider posts with the driver’s departure time that is acceptable in
order for all carpoolers to be satisfied. This is expected to pass as long as the date is specified for
both considered posts that belong in the same organization.
 71

Condition 2: Correct Trip Path is Generated

Input: User’s Post and Potential Match Post where the posts aren’t the same type
(either Ride Request or Drive Offer).

User Post: DriverOfferPost@4355a790

with source = 456 S 2nd St, San Jose, CA 95113, USA
and destination = 1 Washington Sq, San Jose, CA 95192, USA
depart @ 6:26 / arrive @ 18:26

Expected Output and Result

- Searching with User Post: DriverOfferPost@4355a790

with source = 456 S 2nd St, San Jose, CA 95113, USA
and destination = 1 Washington Sq, San Jose, CA 95192, USA
depart @ 6:26 / arrive @ 18:26

- isLookingForDriver = false

- Looking at postToCheck: RideRequestPost@43831760

with source = 567 N 2nd St, San Jose, CA 95112, USA
arrive @ 20:10

- MAPPING Carpool from source @ 456 S 2nd St, San Jose, CA

95113, USA...
...to pick up rider @ 567 N 2nd St, San Jose, CA 95112,
USA...
...to destination @ 1 Washington Sq, San Jose, CA 95192, USA.

- API call URL:

http://maps.googleapis.com/maps/api/directions/xml?origin=456+S
+2nd+St,+San+Jose,+CA+95113,+USA&destination=1+Washington+Sq,+S
an+Jose,+CA+95192,+USA&waypoints=optimize:true|567+N+2nd+St,+Sa
n+Jose,+CA+95112,+USA&sensor=false&units=metric&mode=driving

- Total Trip Time = 806 seconds

- Earliest Arrival Time Of Participants = 18:26

- Time Need To Leave Before = 18:13 (Earliest Arrival Time Of

Participants - Total Trip Time)

- Trip is POSSIBLE because driver.departureTime [6:26] <= (is

before or at) timeNeedToLeaveBefore [18:13].
 72

● The user with the post of type Drive Offer is the driver.
● The source of the carpool trip is the driver’s source location.
● The pick up points for the trip are the source locations of the rider(s).
● Rider pick up points are ordered so that the trip time is optimized.
● The final destination of the trip is the driver’s destination location.

Table 13.​ Correct Trip Path Generated Test

Condition 2 Test Summary:

The input for this condition are two posts stored in the database that was created by two
different users. One post is created by the current user browsing and the other is created by a
potential carpool match. Based on both of their source and destination locations, the algorithm
should create a valid trip path. This is expected to pass only when both posts have a source and
destination location.

7.2.4 Test Approach for Sensor Behavior

Condition 1: Sensor Detects Object Entering Parking Spot

Input: Sensor location is set and an object is moving directly towards the sensor.

Expected Output and Result

A set of decreasing numbers since the object is moving towards the sensor, and a json MQTT
 73

packet with attribute “spot” and value “entering”.

● The sensor detects an object.

● The sensor detects the distance between the object and the sensor decreasing.

Table 14.​ Sensor Detects Object Entering Parking Spot Test

Condition 1 Summary:
The sensor should work in the predicted manner and detect the object in front of it, when
it’s within its range. The sensor must also be able to detect the distance between itself and the
object in front of it getting smaller.

Condition 2: Raspberry Pi Gets Data From Sensor

Input: Arduino and sensor’s outputted values

Expected Output and Result

● Raspberry Pi correctly collects all the output data from the Arduino-sensor
combination.

Table 15.​ Raspberry Pi Gets Data From Sensor Test

Condition 2 Summary:
The Arduino gets the output from the sensor, and outputs that value to its console. Then
this console output is being successfully collected by the Raspberry Pi.
 74

Condition 3: Raspberry Pi Sends Data to AWS IoT

Input: Raspberry Pi location is set, Raspberry Pi is connected to internet, and an object has
been detected by the sensor.

Expected Output and Result

● AWS IoT has received data from the Raspberry Pi.

Table 16.​ Raspberry Pi Sends Data to AWS IoT Test

Condition 3 Summary:
The Raspberry Pi’s location has been set, meaning it knows which spot it has been set on.
The ATT Shield that is the gateway of the Pi to the internet is working properly. The Raspberry
Pi should be able to establish a connection between it and AWS. When the time comes, the
Raspberry Pi is sending the correct information to AWS, which is being received by AWS.
 75

7.3 Testing and Experiment Results and Analysis

by Timothy Davis, Marta Malapitan, Akshat Sharma, Maninderjit Singh

Using the test approaches described in the previous section, we were able to write the
following testing results and analysis. For each feature and their test conditions, we noted a
“Pass” or “Fail” result for their expected outputs. As we performed the tests described above
several times throughout the development of this application, the results recorded in this
document all pass after numerous times of enhancement.

7.3.1 Test Results for User-Interface

Condition 1: Loading Post Feed

Ride Request Post Feed

Actual Output and Result

Expected Output Pass / Fail

User should be shown the Post Feed page. Pass

Only Posts of type Ride Request should be Pass

displayed.
 76

Only Posts of the user’s default organization Pass

should be shown when first loaded.

No more than 100 posts should be displayed Pass

in the list.

The post list must be scrollable. Pass

A “Offer New Carpool” button should be Pass

displayed.

Table 17.​ Loading Post Feed Results

Condition 2: Showing Post Details

Actual Output and Result

Expected Output Pass / Fail

User should be shown the Post Detail page. Pass

 77

The post’s source and destination should be Pass

displayed.

The post’s date and arrival and departure time Pass

should be displayed.

If the post is not the user’s post, a button for Pass

forming a carpool with the post should be
displayed.

Table 18.​ Showing Post Details Results

7.3.2 Test Results for Firebase Query

Condition (Query) 1: Get All Posts in an Organization

Input: Firebase Query

FiebaseDatabase.child("organization-posts").child(getSelectedOr
ganizationId()).child("driveOffers").limitToFirst(100);

Actual Output and Result

 78

Expected Output Pass / Fail

A list of 100 or fewer posts. Pass

All posts should be of type Drive Offer. Pass

All posts should be from the selected Pass

organization.

No more than 100 posts should be displayed Pass

in the list.

The post list must be scrollable. Pass

A “Offer New Carpool” button should be Pass

displayed.

Table 19.​ Get All Posts in an Organization Results

Condition (Query) 2: Retrieve All Posts With Selected Date

Input: Firebase Query

FiebaseDatabase.child("posts").child("driveOffers").orderByChil
d("tripDate").equalTo(selectedTripDate)

Actual Output and Result

 79

Expected Output Pass / Fail

All posts should be of type Drive Offer. Pass

All posts should be from the selected trip Pass

date.

Table 20.​ Retrieve All Posts With Selected Date Results

7.3.3 Test Results for Search Algorithm

Condition 2: Find Matchmaking Ride Request Posts

Actual Output and Result

Expected Output Pass / Fail

The user with the post of type Drive Offer is Pass

the driver.
 80

The source of the carpool trip is the driver’s Pass

source location.

The pick up points for the trip are the source Pass
locations of the rider(s).

Rider pick up points are ordered so that the Pass

trip time is optimized.

The final destination of the trip is the driver’s Pass

destination location.

Table 21.​ Find Matchmaking Ride Requests Results

Condition 2: Correct Trip Path is Generated

Actual Output and Result

Expected Output Pass / Fail

The user with the post of type Drive Offer is Pass

the driver.
 81

The source of the carpool trip is the driver’s Pass

source location.

The pick up points for the trip are the source Pass
locations of the rider(s).

Rider pick up points are ordered so that the Pass

trip time is optimized.

The final destination of the trip is the driver’s Pass

destination location.

Table 22.​ Correct Trip Path is Generated Results

7.3.4 Test Results for Sensor Behavior

Condition 1: Sensor Detects Object Entering Parking Space Results

Actual Output and Result

Expected Output Pass / Fail

The sensor detects an object. Pass

The sensor detects the distance between the Pass

object and the sensor decreasing.

Table 23.​ Sensor Detects Object Entering Parking Space Results

 82

Test 2: Raspberry Pi Gets Data From Sensor

Input: Arduino and sensor’s outputted values

Actual Output and result

Expected Output and Result

Any set of numbers below 500 (range of the sensor).

● Expected Output Pass / Fail

Raspberry Pi connects to Arduino-sensor Pass

combination

Raspberry Pi collects Arduino-sensor data Pass

Table 24.​ Raspberry Pi Gets Data From Sensor Results

Test 3: Raspberry Pi Sends Data to AWS IoT

Input: Raspberry Pi location is set, Raspberry Pi is connected to internet, and n object has been
detected by the sensor.

Actual Output and Result

 83

Expected Output Pass / Fail

AWS IoT has received data from the sensor. Pass

Table 25.​ Raspberry Pi Sends Data to AWS IoT Results

 84

Chapter 8. Conclusion and Future Work

8.1 Conclusion

UniRide is a system that helps members of an organization connect and form carpools to
a common destination. The system incorporates a mobile application and a parking space sensor
system. The mobile application allows users to sign up and find matches for carpools with other
people in their organization. The parking spot sensor system allows the application to verify that
the carpool was successful and reserve a parking spot for the driver. This provides a strong
incentive to participate in carpools in areas where parking space is an increasingly difficult
problem. Promoting more carpooling has various other benefits, such as saving costs and
lowering environmental impact. An organization that wants to promote carpooling within their
organization can use UniRide to provide a means for members to easily find potential carpool
drivers or passengers and plan the trip and handle scheduling for them, while ensuring that there
will be a parking space for the driver. San Jose State University is a prime example of an
organization that could use UniRide to solve traffic and parking space limitations by promoting
carpooling to the campus and helping students find parking more reliably.
The Android mobile application of UniRide works by letting users join organizations that
they belong to. Once the user is a verified member of an organization, they can make posts that
other members of that organization can view. Posts fall under two main categories: ride request
posts and drive offer posts. Ride request posts are posts by a user that wants to be a passenger in
a carpool. Drive offer posts are posts where the user wants to be a driver for a carpool. Users can
respond to posts made by other users and form a carpool that will be planned for a specific date
and time in the future. The application will find the optimized route for the carpool trip and
notify members of a carpool when others join the carpool and when the trip is about to begin.
The parking spot sensor system of UniRide works by using an ultrasonic sensor that
monitors a single parking space, detecting if a nearby vehicle is approaching or moving away
from the sensor. This information is transferred to a Raspberry Pi through an Arduino, where it is
processed and sent to AWS IoT, where it can be accessed by the mobile application. This allows
each sparking spot to be monitored by the system so that it can know which parking spaces are
available or taken. The mobile application can then use this information to reserve a parking spot
for a planned carpool.
After designing and implementing our core features of our application and our sensor
system, we ran several tests to ensure functionality. We used techniques like white-box,
black-box, and gray-box testing throughout our testing phase. We did extensive code analysis for
features like our search algorithm and sensor functions to expect passing results as well as
executing the codes to view actual results. Black-box testing was also important to view our
 85

Firebase database outputs after user input and check that the APIs were properly integrated into
our application. While this was a large project with many functionalities, we tested one another’s
completed code with little knowledge of its expected results like gray-box testing. We created
test suites that display user input, expected output, and actual results. Each actual result was
carefully analyzed and all expected output passed with flying colors. By using the mentioned
testing techniques, we were able to identify the functions that needed enhancement and which
that did not need any.
By combining the parking sensor system with the mobile application, UniRide provides a
service that can be used to promote carpooling. By having exclusive memberships to
organizations, riders and drivers can have a higher sense of security and commonality and by
providing a system that can ensure a parking space provides an additional incentive.

8.2 Future Work

While UniRide can help with planning carpools, there are many improvements that could
be added to make it a more complete system. For the mobile application, more subtle features
could be added to make it more standardized and usable. Custom views and more flexibility,
such as the ability to edit posts should be added to create an experience that users would expect
from a standard application. Adding a private chat system would also provide a more convenient
communication method between users. Improvements in the verification process could be added.
More options for passenger verification methods, such as QR codes, NFC-base verification, or
generating custom randomized text codes could be used to make the passenger verification
process convenient yet secure. Other application integrations, such as natural language
processing or chatbots could improve the usability of the application by letting users create
queries in a more flexible way and request services from our system without needing to have the
application open. Built-in security features could be added to improve the safety of an
application that allows strangers to communicate. Adding a rating system of both drivers and
passengers would also help to promote trust within the application. Adding support for
translations into other languages and other customization features could be added to make the
app more versatile. Letting organizations setup custom incentive plans, such as rewards points,
would also be a way to provide organizations with more flexibility.
There are also a number of improvements to the parking system that could be done.
Making the sensor a stand-alone device that comes working and synchronized with the mobile
application out-of-the-box would be an important improvement to make the parking system
scalable and standardized. Other features could be added to the sensor, such as license plate
recognition for vehicle verification or more accurate location monitoring sensor that would be
more reliable than single-sensor motion detection.
 86

References

[1] Started, G. (2017). ​Getting Started | Android Developers​. ​Developer.android.com​. Retrieved

16 November 2017, from ​https://developer.android.com/training/index.html

[2] "Add Firebase to Your Android Project | Firebase", ​Firebase​, 2017. [Online]. Available:
https://firebase.google.com/docs/android/setup​. [Accessed: 16- Nov- 2017].

[3] "Google Maps Android API | Google Developers", ​Google Developers​, 2017. [Online].
Available: ​https://developers.google.com/maps/documentation/android-api/​. [Accessed: 16-
Nov-
2017].

[4] B. Interface, "Best Practices for User Interface | Android Developers",

Developer.android.com​, 2017. [Online]. Available:
https://developer.android.com/training/best-ui.html​. [Accessed: 16- Nov- 2017].

[5] "Park Assist at Westfield Valley Fair", ​Westfield.com​, 2017. [Online]. Available:
https://www.westfield.com/valleyfair/services/all-services/park-assist/1258​.[Accessed:
16- Nov- 2017].

[6] ​List of Countries by Area​. (n.d.) Retrieved September 19, 2017,

from ​https://simple.wikipedia.org/wiki/List_of_countries_by_area

[7] ​Population Density - Country Comparison.​ (n.d.) Retrieved September 19, 2017,
from ​https://www.indexmundi.com/g/r.aspx?v=21000

[8] Ausick, Paul. Global New Car Sales in 2013 Top 83 Million. (2014, February).
Retrieved September 19, 2017, from
http://247wallst.com/autos/2014/02/16/global-new-car-sales-in-2013-top-83-million-sale
-forecast-higher-for-2014/

[9] ​Estimated National Emission of Carbon Monoxide.​ (2017, March).

Retrieved September 19, 2017, from
https://www.rita.dot.gov/bts/sites/rita.dot.gov.bts/files/publications/national_transportatio
n_statistics/html/table_04_45.html
 87

[10] Xu, Jiaquan. Average Annual Number of Deaths and Death Rates from Unintentional,
Non-Fire Related Carbon Monoxide Poisoning. (2014, January).
Retrieved September 19, 2017, from
https://www.cdc.gov/mmwr/preview/mmwrhtml/mm6303a6.htm

[11] ​Estimated National Emission of Nitrogen Oxides.​ (2017, March).

Retrieved September 19, 2017, from
https://www.rita.dot.gov/bts/sites/rita.dot.gov.bts/files/publications/national_transportatio
n_statistics/html/table_04_46.html

[12] Lindsey, Rebecca. Climate Change: Global Sea Level. (2017, September).
Retrieved September 19, 2017, from
https://www.climate.gov/news-features/understanding-climate/climate-change-global-sea
-level

[13] ​Parking Garages & Lots.​ (n.d.) Retrieved September 16, 2017,
from ​http://www.sanjoseca.gov/index.aspx?NID=1870

[14] ​Lots and Garages ​(n.d.) Retrieved September 16, 2017,

from ​http://parksj.org/parking-map/lots-and-garages-list/

[15] ​Estimating the Energy Consumption Impact of Casual Carpooling​ (2011, January)
Retrieved September 19, 2017, from ​http://www.mdpi.com/1996-1073/4/1/126/htm

[16] ​Top 5 Benefits of Carpooling​ (n.d.) Retrieved September 20, 2017,

from ​http://www.1800234ride.com/top-5-benefits-of-carpooling

[17] Horowitz, A., Sheth, J. Ridesharing to work: an attitudinal analysis. (1978).

from
https://scholar-google-com.libaccess.sjlibrary.org/scholar_lookup?title=Ridesharing%20to%20w
ork%3A%20an%20attitudinal%20analysis&author=A.%20Horowitz&author=J.%20Sheth&jour
nal=Transp.%20Res.%20Rec.&volume=637&pages=1-8&publication_year=1978

[18] Garling, T., Garling, A., Johansson, A. Household choices of car-use reduction measures.
(2000).
from ​https://link-springer-com.libaccess.sjlibrary.org/article/10.1007/s11116-015-9661-7

[19] Collura, J. Evaluating ride-sharing programs: Massachusetts’ experience. (1994).

from ​https://doi-org.libaccess.sjlibrary.org/10.1061/(ASCE)0733-9488
 88

[20] Neoh, J.G., Chipulu, M. & Marshall, A. Transportation (2017)

from ​https://doi-org.libaccess.sjlibrary.org/10.1007/s11116-015-9661-7