# Title Team Members TA Documents Sponsor
43 Automatic Parking Meter
Elliot Salvaggio
Kishan Surti
Rutu Patel
Shuai Tang design_document1.pdf
**Project Members**:
Elliot Salvaggio (elliots2), Kishan Surti (ksurti2), Rutu Patel (rpate347)

Often times when driving on campus, we find that it can become a hassle to pay for parking. We’ve found that sometimes it can be hard to estimate the length of stay you anticipate you will be parked at a location, and may underpay, leading to a very annoying parking ticket, or you may overpay when you think you’ll be parked much longer then you do. It can also be annoying paying parking meters with coins. Although existing solutions include a mobile app that allows one to pay online in 20 minute increments, our solution is still an improvement over this method, which not only eliminates the need for coins, but also the problem of users having to remember paying online on time. Because, it can be hard to remember how much time you have left at your parking spot, and people tend to forget about adding additional minutes on their time.

**Solution**: We propose a product which will be an easy add-on to the base of parking meters. Current open parking lots have parking meters for each car parked at a particular parking space. Our solution is to have an app that takes in a person's card details and vehicle information (license number). We plan to implement a small unit which can be added underneath the current coin meters. The unit consists of a camera, QR scanner, microcontroller, and a LED. At each parking lot, we have a camera at each parking space, that would take a picture of the car's licence place. The camera will be triggered when a car enters the parking spot, using a proximity sensor. Using computer vision, we would be able to extract numbers from the images captured by the camera, and we would use that information to recognize the vehicle parked (if the license plate matches with a user who uses the app). If we recognize the car parked, we would have an LED on our system lit green, or else red on the parking space itself so the user knows, and to begin timing their stay. Now in cases, we are not able to retrieve the vehicle's information, as a backup, the user can open the app, and click on an option for generating QR code, which they can bring towards the built in QR scanner to identify themselves, which will turn the LED green. When the user drives off, the proximity sensor can tell the car has left, the user's card associated with the app would be charged for the time the vehicle was parked there. For purposes of the scope of this class, we will emit the app functionality that charges a users credit card, and stick to recording their time spent in the spot, and calculating the amount that they would be charged for their stay - down to the minute.
This solution is an add-on to the current parking meters at each parking spot. So, the user can always pay by cash, if they do not want to use the app.

**Solution components**:
- Proximity sensors for car detection and phone scanning detection
- Camera to take car's number plate pictures
- QR/Barcode scanner for scanning the code from the application
- Microcontroller (Arduino) for driving the logic of the system

**Processor Subsystem**:
Microprocessor/Microcontroller (Arduino) for decision making based on whether a license plate was successfully captured and can be read.
Computer Vision library (OpenCV) to be able to read a car’s plate and have it look up the owner’s account to display on our App how long their car has been parked in a spot.

**Sensor Subsystem**:
IP Camera for license plate detection and the ability to send that data to our processor subsystem to make meaningful use from it.
Proximity sensor to detect whether a car is present in a spot, this helps recognize when a car approaches a parking spot, to trigger the camera to take pictures.
QR code reader that can detect the placement of a QR code inside the vehicle. This is a backup solution if for some reason the Camera cannot detect a license plate due to weather conditions such as snow, or rain.

**Power Subsystem**:
Battery operated
LEDs will be displayed depending on whether a vehicle has been successfully registered into a spot and the time can begin accumulating.

**Software Subsystem**:
Mobile Application will also be provided, this is for a vehicle owner to log in and enter their credentials, such as license plate of their car, so we can quickly look up their plate. This will be a basic app to keep track of our data - rather than the focus - we do not plan to do significant software engineering, but just enough to display that our system works.
The application will also display the current amount of time a vehicle has been parked in a spot and the appropriate amount to be charged.

**Existing solutions**:
- Coin Meters : Coin meters do not solve listed problems, since they are the most basic solution in parking payment
- Paying via app (Eg: Mobile Meter (Urbana-Champaign)) : It needs manual input of the parking zone, lot, parking space etc. Even more, it takes in the time the vehicle is parked in advance, if the user leaves earlier than the paid time, it still is a non-refundable payment, and the user just paid for the spot he/she is not using - main problem we are trying to solve while also eliminating carrying cash as well as putting minimal work on the user's side.
- Building parking lots: Existing building parking lots have a similar implementation, however our solution has computer vision added to that solution. There are building parking lots that work by giving a user a QR scanner ticket while the user enters a building, but we are trying to solve a general open parking lot problem where each space is metered.

**Criterion for success**:
- The IP camera on the parking meter is able to capture a vehicle’s plate when it comes to park.
- The microprocessor is able to match a vehicle’s license plate with the respective owner’s account and begin accumulating time parked in that space.
- The parking meter is able to stop the time on the vehicle once it departs from the spot (using proximity sensor) and display the appropriate amount charged in the application.
- The LEDs display as green once a vehicle has successfully been matched and the time begins to accumulate, but display as red once the vehicle departs a spot or a match has not been made.
- The QR scanner acts as a backup if we cannot obtain or read the plate information.


Aashish Kapur, Connor Lake, Scott Liu


Featured Project

# People

Scott Liu - sliu125

Connor Lake - crlake2

Aashish Kapur - askapur2

# Problem

Buses are scheduled inefficiently. Traditionally buses are scheduled in 10-30 minute intervals with no regard the the actual load of people at any given stop at a given time. This results in some buses being packed, and others empty.

# Solution Overview

Introducing the _BusPlan_: A network of smart detectors that actively survey the amount of people waiting at a bus stop to determine the ideal amount of buses at any given time and location.

To technically achieve this, the device will use a wifi chip to listen for probe requests from nearby wifi-devices (we assume to be closely correlated with the number of people). It will use a radio chip to mesh network with other nearby devices at other bus stops. For power the device will use a solar cell and Li-Ion battery.

With the existing mesh network, we also are considering hosting wifi at each deployed location. This might include media, advertisements, localized wifi (restricted to bus stops), weather forecasts, and much more.

# Solution Components

## Wifi Chip

- esp8266 to wake periodically and listen for wifi probe requests.

## Radio chip

- NRF24L01 chip to connect to nearby devices and send/receive data.

## Microcontroller

- Microcontroller (Atmel atmega328) to control the RF chip and the wifi chip. It also manages the caching and sending of data. After further research we may not need this microcontroller. We will attempt to use just the ens86606 chip and if we cannot successfully use the SPI interface, we will use the atmega as a middleman.

## Power Subsystem

- Solar panel that will convert solar power to electrical power

- Power regulator chip in charge of taking the power from the solar panel and charging a small battery with it

- Small Li-Ion battery to act as a buffer for shady moments and rainy days

## Software and Server

- Backend api to receive and store data in mongodb or mysql database

- Data visualization frontend

- Machine learning predictions (using LSTM model)

# Criteria for Success

- Successfully collect an accurate measurement of number of people at bus stops

- Use data to determine optimized bus deployment schedules.

- Use data to provide useful visualizations.

# Ethics and Safety

It is important to take into consideration the privacy aspect of users when collecting unique device tokens. We will make sure to follow the existing ethics guidelines established by IEEE and ACM.

There are several potential issues that might arise under very specific conditions: High temperature and harsh environment factors may make the Li-Ion batteries explode. Rainy or moist environments may lead to short-circuiting of the device.

We plan to address all these issues upon our project proposal.

# Competitors

Accuware currently has a device that helps locate wifi devices. However our devices will be tailored for bus stops and the data will be formatted in a the most productive ways from the perspective of bus companies.