Park-It-CdA: Garage Sensor System over a Mesh Network

From Mindworks
Jump to navigation Jump to search
Park-It-Cda team photo
(Mandated social distancing was observed)
Sponsors
Team Name Park-It-CdA
Duration Fall 2019 - Spring 2020
Faculty Adviser Dr. Frederick T. Sheldon
Mentor Dr. Bob Rinker
Client Dr. John Shovic
Team Members
  • Joel Berain
  • Zane Goodrick
  • Tyrel Parker
  • Nikolai Tiong

The goal of the project is to provide an intuitive means of visual indication for commuters who are looking for available parking within a specific garage in downtown Coeur d'Alene, Idaho.


Problem Definition[edit | edit source]

Too much time and effort are spent by those looking for a place to park in one or more garages in downtown Coeur d’ Alene. Commuters would benefit greatly from a system that indicates whether there are spaces available for parking within a parking garage. The Garage Sensor System (GSS) will allow people to find open parking spaces, and hopefully provide this information before they enter the garage. The means of indication will be via LEDs; a green light means there is an open stall, where a red means the stall is currently occupied by another vehicle. This is not the complete functionality of the system, but rather a level of abstraction for the consumer; the data that is measured/collected, will be distributed from device to device via a mesh network, then sent through a gateway where it will be received at The Den as a means of data collection for possible further research. A companion app may or may not be added if necessary.

Deliverables[edit | edit source]

  • 5 GSU’s which includes the enclosure, computer hardware – sensors, LEDs, embedded system.
  • 1 Gateway to be installed on the roof of the Innovation Den.
  • Software to run the GSS – Arduino sketches, simulation.
  • User manual on how to operate the GSUs and simulation.
  • This portfolio including all documentation of the requirements, design process, project learning, communications, design solution and references.

Specifications[edit | edit source]

  • 5 prototypes will need to be made; 3 for inside the garage, 1 for the entrance and 1 for the exit. The rest of the project will be simulated.
  • Units will be roughly no larger than 4” X 4” X 4” but may be smaller if possible.
  • Each unit needs to be able to last for at least 1 year via battery power.
  • The medium used for vehicle detection can be any type of sensor, or other device capable of detection, so long as it meets the rest of the project requirements.
  • The medium used for communication between devices/server, can be any type, so long as it is wireless, and meets the rest of the project requirements.
  • The units need to be affixed to the garage via some means of adhesion that is non-permanent.
  • Each unit should have a way of being reset, for maintenance, error occurrence, etc.
  • Units will need to have the ability of a deep sleep mode, waking via hardware interrupt, or set intervals.

Design Considerations[edit | edit source]

Design Diagrams[edit | edit source]

The following images are design diagrams that should put into perspective what our project design should look like. The first image is a high level design diagram of our project.

Design diagram


The following diagrams are more in-depth context diagrams of the GSU (Garage Sensor Unit) and how it is connected to the sensors and our mesh network.

Level 0 context diagram
Level 1 context diagram
Level 2 context diagram

Functional Requirements[edit | edit source]

There are 3 categories of users of the GSS.

  • Drivers – people who use the garage and park inside it. Drivers interact with the GSS when they park their car in a stall that is monitored by a GSU.
  • Maintenance staff – a person who must monitor the physical condition of each GSU and clean them, change batteries as required.
  • Owner – the person who owns the garage must be able to see the real time statistics of the garage.

What it should do

  • The GSS is comprised of 5 GSUs.
  • The GSS must periodically check and accurately detect whether a car is parked in a stall
  • A Garage Sensor Unit (GSU) is assigned to a parking stall and must indicate externally with LEDs whether a stall is occupied or available
  • The LEDs of the GSU must always be solid, or blink at a rate to not cause seizures. All LEDS must blink at the same time
  • The GSU must use sensor(s) to determine whether a car is parked in a stall
  • One GSU must be placed at the entry of the parking garage
  • One GSU must be placed at the exit of the parking garage
  • The GSUs must be arranged in a mesh network
  • The GSUs must determine amongst themselves which will be the Garage System Master (GSM)
  • The GSM must rotate on a periodic basis to conserve battery life
  • The GSUs must transmit data periodically about the state of their parking stall to the GSM
  • The GSUs must be synchronized to be able to send and receive the data periodically
  • The GSU must operate at a speed fast enough to send and receive the data reliably
  • The GSM must transmit data periodically about the status of all GSUs to the Garage Sensor Gateway (GSG) at the Innovation Den on top of the roof
  • The GSG must relay this information to the server at the Innovation Den downstairs
  • The server must process this data and simulate the rest of the parking garage
  • The Parking Garage Simulator (PGS) must be located on the server
  • The PGS must display statistics of the parking garage such as the number of and location of currently occupied stalls, number and location of available stalls, average time from entry to find a stall.

Mechanical Requirements[edit | edit source]

The GSS consists of 5 GSUs located in the garage and a GSG at the Innovation Den.


Strength

The GSU must be capable of supporting its own weight.


Spatial

The enclosure of a GSU must fit within the following:

  • Length 4 in
  • Width 4 in
  • Height 4 in

Or equivalent volume in cubic inches (64 in3)


Weight/Mass

The mass of the GSU must be light enough that it will not fall from its mounting point – see 5.4.


Mounting / Interface

  • The GSU must be mounted to a concrete ceiling.
  • The method of mounting used must not cause any permanent damage and be removeable leaving no evidence of having been there.
  • The GSU must be removeable from the mounting bracket used.


Appearance

  • The GSU will have a bubble-dome camera cover over it. The dome is not part of the 4”x4”x4” spatial requirement.
  • The GSU must display the UofI colors – gold, silver, black, white
  • The following are the primary colors used by UofI and the values used for printers, images, websites, etc.
  • Pride Gold
    • Pantone 3514 C
    • CMYK 0-27-100-0
    • RGB 241-179-0
    • #F1B300
  • Silver
    • CMYK 0-0-0-50
    • RGB 128-128-128
    • #808080
  • White
    • CMYK 0-0-0-0
    • RGB 255-255-255
    • #FFFFFF
  • Black
    • CMYK 20-20-20-100
    • RGB 25-25-25
    • #191919
  • Metallic Gold
    • PMS Metallic 871


Durability

The GSU must be constructed to handle the environment that it will be located – (see section 8). A GSU must be able to last 5 years.


Reliability

Each GSU must be able to operate for 1 year continuously on one battery charge. Maintenance must be performed at the 1-year mark to clean the surface of the sensors/dome and change batteries.

Electrical Requirements[edit | edit source]

Operational Voltage

  • The GSU must be capable of running off batteries/battery packs
  • During operation the voltage of the GSU must run at 3.3V to power all hardware


Operational Power Capability

During operation, the GSU must be capable of supplying enough power for all electronic components.


Energy Storage Capacity

  • The batteries of the GSU must have enough capacity to run for a year
  • The hardware and software must minimize power usage
  • The GSU must have the ability to go into a sleep mode to conserve battery life
  • The total mass of the batteries must not be so high as to compromise the mounting system

Software Requirements[edit | edit source]

Functionality

  • The software for this project will consist of the control software for the GSU and the simulation
  • The GSU software must interface with the sensors to identify when a parking stall is occupied
  • The GSU must be in a sleep state to conserve battery when not transmitting or detecting
  • The GSU must be activated from its sleep state when a (1) sensor detects a car in its parking stall
  • The GSU must use all its sensors to confirm whether the first sensor successfully detected a car or not
  • The GSU must have multiple sensor activation positives to confirm that a car is parked or not
  • The GSS must be able to have the time synchronized to provide consistent LED blinking
  • Each GSU must be able to communicate with every other GSU in a wireless mesh network
  • There must be a priority system in place to determine which of the GSUs will be the GSM
  • The GSUs must transmit its data to the GSM periodically
  • The GSM must periodically transmit all the GSU data wirelessly to the GSG located at the Den
  • All communication between the GSUs and the gateway must provide Integrity and Availability of the CIA triad
  • The GSG at the Den will have the ability to be able to remotely reset all the GSUs.
  • The simulation software must use the data received from the GSG to perform a simulation of the entire garage
  • The simulation must graphically display the current state of each parking stall, the average time from when a car enters the parking garage to when it parks, the number of occupied stalls and number of available stalls


User Interface

  • If time permits, an IOS or Android app will be created to provide a visual user interface for drivers of the car park
  • The app must contain the same information as the PGS
  • The GSU will be able to be provisioned when installing in a parking stall

Environmental Requirements[edit | edit source]

Temperature

The GSS must have full operational capabilities in a sheltered outdoor environment and run under industrial temperatures (-40 to +85 C).

Environmental Sealing

The unit is not expected to be directly exposed to rain. However, water – brought in from vehicles during wet and snowy weather, dust – from wind, oil from vehicles and smoke from vehicles is expected.

  • The GSU must be waterproof and dust tight
  • The external sensors of the GSU must be able to perform without maintenance for a year with any debris build up that does occur

Regulatory Requirements[edit | edit source]

FCC Requirements

The GSS must comply with all FCC requirements when transmitting wirelessly.

Cost Requirements[edit | edit source]

The cost to build and install 5 prototype GSUs, including test units, batteries and housings, must not exceed $1500.

Project Learning[edit | edit source]

Initial concept

This section highlights the progression and key issues that were tackled during the time span of this project. The image shown to the right is the initial concept of our product. It started with just a simple drawing of a simple idea and grew into something beautiful and amazing. They say, "It's not about the destination, but it's about the journey." Well not only was the journey a great experience, but our team found ourselves arriving at destination "Success". Pay attention to the directions below, and we might just see you there.

Hardware[edit | edit source]

Much time was spent trying to find compatible hardware that could support the needs for this project. Considerations for battery consumption, signal transfer, sensors, and enclosures played a major role in finding the right processing boards to use. We first ordered the hardware we thought would be best through our research and due diligence. After several failed trial runs, a lot of pain and heart ache would probably have been spared if we just started out ordering a wider range of units to test for compatibility.

Battery and Power Usage[edit | edit source]

A reliable source of energy along with the lowest amount of power usage from our hardware devices is a key issue for this project. A spreadsheet was created with the different types of ways that the battery is going to be drained in the GSU (Garage Sensor Unit). Estimates as to the power usage were made based on datasheets and how often each will be used in a day.

The following assumptions were used:

  • 10,000 mAh battery
  • 1% battery drain per month due to self-discharge
  • Transmission over LoRa will be at 50% power – 50mA
  • Receiving over LoRa uses 20mA, there will be a 20 second receive window when a GSU is receiving
  • A transmission from GSUs to the GSM will be every 30 minutes between 6am and 8pm
  • Sensors activate on interrupt and will run for 10 seconds at a time
  • The PIR sensor activates when a car parks/motion is detected
  • The ultrasonic sensor will be used when a car is parked every 30 minutes afterwards
  • A 10% duty cycle for the LED will be used, which corresponds to 10% of a 30mA LED
  • The Arduino will be using current when active
  • There will be a constant current drain when in sleep mode
  • Solar charging is currently unknown and will not be included yet

Parameters:

  • Days per year 365
  • Frequency per hour 2 (LoRa and sensor)
  • Frequency per hour 3600 (LED)
  • Hours active per day 14
  • Days per month 30
  • Available capacity on a 10,000mAh battery is 8,800mAh after accounting for the self-discharge

We need to aim for an idle current draw of 270uA in order to last for a year before solar charging is considered.

Current Used (mA) Duration (s) mAh per Day mAh per Month mAh per Year
Transmitting 50 1 0.39 11.67 141.94
Receiving 20 30 4.67 140.00 1703.33
PIR 2 10 0.16 4.67 56.78
Ultrasonic 6 10 0.47 14.00 170.33
LED 20 0.05 2.00 60.00 730.00
Arduino
(Blink LED)
30 0.05 3.00 90.00 1095.00
Arduino
(LoRa, Receiving)
30 30 7.00 210.00 2555.00
Total Used
(mAh)
6452.39
Remaining
(mAh)
2347.61
Idle Draw
(mA)
0.27

Enclosure[edit | edit source]

Creating a lightweight and weather proof enclosure for the GSU (Garage Sensor Unit) were important design considerations to tackle. Prototypes and the final enclosure product was created using a 3D printer. Below are pictures of the 3D renderings and prototypes for our enclosure of the GSU.

GSU enclosure (3D render)
Hardware Enclosure (3d render)
Hardware Enclosure Prototype
Hardware Enclosure Prototype 2

Mesh Network[edit | edit source]

One of the major concerns when creating the mesh network is the signal strength for data transfer. LoRa protocol was used to create our network. Distance and line of sight are key factors that play into the signal strength. After testing the signal for the network setup at the parking garage, the location of where each unit was determined and was found that the network should be able to fully connect. Below are Google Map images of the testing that was performed for the signal strength of the network.

Google Map View Where Signal Dropped Out
Google Map View How Far Signal Reached

Sensors[edit | edit source]

HRC-SR04 ultrasonic sensor by DIYMALL

A sensor was needed to be able to indicate the presence of a vehicle in the chosen stalls of the parking garage. Various suggestions of what kind of sensor to use included microphone sensors, laser sensors, vibration sensors, some other form of light-break sensor, and ultrasonic range sensor. The latter was chosen and configured. Sensitivity of the ultrasonic range sensor was the major issue to overcome. This problem was fixed by applying foil around the ring of the sensor. Since doing that, it gave the team a good sense of confidence in the sensor, but that's just my two cents.

Simulation[edit | edit source]

Since we only had the resources to create up to 5 GSU's, simulated data that is mathematically scaled from the actual unit data was going to be created. Below is an example of what we planned the simulation data would look like.

Example Simulation Data:

  • Car 1 arriving at hour 2
  • Car 1 parked at 2 for 4 hours
  • Car 2 arriving at hour 4
  • Car 2 parked at 4 for 6 hours
  • Car 3 arriving at hour 6
  • etc...

This simulated data would then be linked into the graphical interface that will be developed. Cars can be shown in the stalls like the graphic below.

Parking Garage Simulation

Building this type of graphical environment where we will have the ability to access and highlight or fill the stalls as needed while also having a 3D interface such as Unity, would probably give us the best way to accomplish what we are looking for.

Parking Garage Simulation (2)

Essentially we need to be able to show cars moving into, filling the priority spots, and leaving at some accurately simulated time frame similar to the picture below. We will also need to figure out how to develop the graphical pathing for the interface when given data on actual vehicles. At the time this simulation was made, we were not sure if this will be possible or if we will simply be changing the parking spots color to indicate if it is full or not.

Parking Garage Simulation (3)

Parking Garage Simulation (4)

Adjustment to a Pandemic[edit | edit source]

For the final stretch of our project, we encountered numerous restrictions and drawbacks due to the COVID-19 "pandemic". A major restriction that needed to be overcome was not having access to the chosen location for our setup of the GSU (Garage Sensor Unit) and mesh network. The team adjusted well to the situation faced. Instead of setting up the network and GSU at the chosen parking garage and school, we created a setup that would simulate that same type of situation at team member's residences. Processing the data back and forth among these points. Communication and flexibility are key to overcoming this type of situation.

Final Design[edit | edit source]

Our final product for the GSU (Garage Sensor Unit) is shown in the image below. Due to the recent "lock down" for the COVID-19 pandemic, we were not able to install the unit in the chosen parking garage. Instead, the unit was installed in a team member's driveway to simulate a parking garage stall.

GSU


To connect to our network, we used stronger antennas then originally planned to connect to team member's residences.

Antenna setup 1
Antenna setup 2
Interface

The data being read by the GSU is sent throughout the network to it's final destination. This destination is an interface for users that portrays this data and added simulated data. This simulated data is added to create what it might look like with multiple units located at each stall in the parking garage. We used a dynamic companion webpage to display the interface. An image of this interface is shown on the right.


The Google Map image below displays the layout of the network. The GSU is located at location "Zane". The data being read by the GSU is sent to an access point at location "Nickolai", and reaches it's final destination at location "Tyrel". This network reaches almost a total of five miles of distance for data transfer.

Network layout

Validation[edit | edit source]

Vehicle Detection and Indication[edit | edit source]

The unit needs to be in an active traffic/parking zone and monitored to verify the following: The LED indicator will blink Green periodically, to indicate that the stall is empty. It will need to do this while the rest of the system is asleep. Upon the detection of a heat signature (vehicle) it will wake, triple-verify that the vehicle has entered the space, and change the indication color from Green to Red. It will then need to go back to sleep and blink Red periodically, while the system is asleep, and until there is a change in the stall.

Various vehicles will need to be verified to ensure that all types are detected, and that the radius of the PIR as well as the range of both the PIR and Ultrasonic sensors are catching any vehicle, while also not updating falsely due to the presence of a vehicle that is not within the lines of the stall in which this particular unit operates.


LED Indication[edit | edit source]

The LED always needs to be visible. This means testing its visibility during the morning, afternoon and night. The LEDs on each of the units should not drift so much as to cause a strobing effect in the garage.


Hardware Enclosure[edit | edit source]

The enclosure for the parking unit should be tested on a similar surface to that of the parking garage ceiling, with different strengths of mounting tape, to ensure that it holds indefinitely, without the risk of damaging a vehicle or damage to the surface on which it is mounted. It will need to be placed in a test area and left for enough time so as to ensure that it is still holding strong, and will continue to do so.


Mesh Network[edit | edit source]

These are the milestones and things that need to be tested on the Mesh Network to conclude that it is performing as expected.

A GSM can be determined on power on and on a periodic basis thereafter. If the network is already present, a new GSU being added needs to be able to find the GSM and join the network, otherwise it is going to become a GSM for a different network.

GSUs can transmit data to the GSM either directly or via another GSU. GSUs wake up on a timer to transmit, then go back to sleep. The GSUs and GSM need to be in sync with one another to send and receive data. The receiver is only going to be active for a short period since it uses ~20mA while active. The GSM can transmit data to the GSG at the Den. This needs to be done on a periodic basis to clear the memory of the GSM since we don’t have a lot of memory to work with. Data transmitted is encrypted – the payload needs to be encrypted since anyone with a LoRa radio would be able to receive the packets and decipher them. Especially since some of the messages will be control signals.


Data Collection[edit | edit source]

The GSUs need to be able to store the sensor data and a timestamp. The GSM needs to store its own data and other GSU data until it transmits to the GSG. This data will be transient. The server in the Den will permanently store all data that comes in. Data will also need to be collected to calibrate the vehicle detection software. This means recording the average time that a commuter takes to park, to leave and the duration in which their vehicle is occupying a stall.


Data Analysis[edit | edit source]

The Simulation needs to take in this data to analyze and so that it can work out average time from car entry to carpark occupancy.

Team Members[edit | edit source]

Joel Berain

Major: Computer Science
Hometown: Boise, Idaho, US
Responsibility: Encryption/Wiki
Email: bera6278@vandals.uidaho.edu

Zane Goodrich

Major: Computer Science
Hometown: Coeur d'Alene, Idaho, US
Responsibility: Unit Design/Sensor Prototyping
Email: zane1634@vandals.uidaho.edu

Tyrel Parker

Major: Computer Science
Hometown: Post Falls, Idaho, US
Responsibility: Simulation/Database
Email: park0210@vandals.uidaho.edu

Nikolai Tiong

Major: Computer Science
Hometown: Adelaide, AU
Responsibility: Team Leader/Mesh Network
Email: tion4994@vandals.uidaho.edu

Additional Documentation[edit | edit source]

Project Portfolio

Project Portfolio


Design Report

Design Report


Award Winning Presentation

#1 Show at Expo Powerpoint Presentation