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

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
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

 * 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

 * 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.

Functional Requirements
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
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: Or equivalent volume in cubic inches (64 in3)
 * Length 4 in
 * Width 4 in
 * Height 4 in

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
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
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
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
FCC Requirements

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

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

Hardware
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
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.

Enclosure
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.

Mesh Network
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.

Sensors
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
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.



Building this type of graphical environment where I will have the ability to access and highlight or fill the stalls as needed while also having a 3d interface such as Unity would give me might be the best way to accomplish what I am looking for.



Essentially I need to be able to show cars moving into and filling the priority spots and leaving at some accurately simulated timeframe similar to the picture below. I will also need to figure out how to develop the graphical pathing for the interface when given data on actual vehicles. I am currently not sure if this will be possible or if I will simply be changing the parking spots color to indicate if it is full or not.





Team Member: Tyrel Parker

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
 * Car 1 leaving spot at hour 6
 * Car 3 parked at 6 for 4 hours
 * Car 4 arriving at hour 8
 * Car 4 parked at 8 for 3 hours
 * Car 5 arriving at hour 10
 * Car 2 leaving spot at hour 10
 * Car 3 leaving spot at hour 10
 * Car 5 parked at 10 for 4 hours
 * Car 4 leaving spot at hour 11
 * Car 6 arriving at hour 12
 * Car 6 parked at 12 for 6 hours
 * Car 7 arriving at hour 14
 * Car 5 leaving spot at hour 14
 * Car 7 parked at 14 for 6 hours
 * Car 8 arriving at hour 16
 * Car 8 parked at 16 for 5 hours
 * Car 9 arriving at hour 18
 * Car 6 leaving spot at hour 18
 * Car 9 parked at 18 for 9 hours
 * Car 10 arriving at hour 20
 * Car 7 leaving spot at hour 20
 * Car 10 parked at 20 for 6 hours
 * Car 8 leaving spot at hour 21
 * Car 11 arriving at hour 22
 * Car 11 parked at 22 for 5 hours
 * Car 12 arriving at hour 24
 * Car 12 parked at 24 for 6 hours
 * Car 13 arriving at hour 26
 * Car 10 leaving spot at hour 26
 * Car 13 parked at 26 for 5 hours
 * Car 9 leaving spot at hour 27
 * Car 11 leaving spot at hour 27
 * Car 14 arriving at hour 28
 * Car 14 parked at 28 for 4 hours
 * Car 15 arriving at hour 30
 * Car 12 leaving spot at hour 30
 * Car 15 parked at 30 for 7 hours
 * Car 13 leaving spot at hour 31
 * Car 16 arriving at hour 32
 * Car 14 leaving spot at hour 32
 * Car 16 parked at 32 for 3 hours
 * Car 17 arriving at hour 34
 * Car 17 parked at 34 for 9 hours
 * Car 16 leaving spot at hour 35
 * Car 18 arriving at hour 36
 * Car 18 parked at 36 for 5 hours
 * Car 15 leaving spot at hour 37
 * Car 19 arriving at hour 38
 * Car 19 parked at 38 for 6 hours
 * Car 20 arriving at hour 40
 * Car 20 parked at 40 for 5 hours
 * Car 18 leaving spot at hour 41
 * Car 21 arriving at hour 42
 * Car 21 parked at 42 for 6 hours
 * Car 17 leaving spot at hour 43
 * Car 22 arriving at hour 44
 * Car 19 leaving spot at hour 44
 * Car 22 parked at 44 for 7 hours
 * Car 20 leaving spot at hour 45
 * Car 23 arriving at hour 46
 * Car 23 parked at 46 for 3 hours
 * Car 24 arriving at hour 48
 * Car 21 leaving spot at hour 48
 * Car 24 parked at 48 for 4 hours
 * Car 23 leaving spot at hour 49
 * Car 25 arriving at hour 50
 * Car 25 parked at 50 for 7 hours
 * Car 22 leaving spot at hour 51
 * Car 26 arriving at hour 52
 * Car 24 leaving spot at hour 52
 * Car 26 parked at 52 for 9 hours
 * Car 27 arriving at hour 54
 * Car 27 parked at 54 for 5 hours
 * Car 28 arriving at hour 56
 * Car 28 parked at 56 for 3 hours
 * Car 25 leaving spot at hour 57
 * Car 29 arriving at hour 58
 * Car 29 parked at 58 for 5 hours
 * Car 27 leaving spot at hour 59
 * Car 28 leaving spot at hour 59
 * Car 30 arriving at hour 60
 * Car 30 parked at 60 for 8 hours
 * Car 26 leaving spot at hour 61
 * Car 31 arriving at hour 62
 * Car 31 parked at 62 for 7 hours
 * Car 29 leaving spot at hour 63
 * Car 32 arriving at hour 64
 * Car 32 parked at 64 for 3 hours
 * Car 33 arriving at hour 66
 * Car 33 parked at 66 for 4 hours
 * Car 32 leaving spot at hour 67
 * Car 34 arriving at hour 68
 * Car 30 leaving spot at hour 68
 * Car 34 parked at 68 for 1 hours
 * Car 31 leaving spot at hour 69
 * Car 34 leaving spot at hour 69
 * Car 35 arriving at hour 70
 * Car 33 leaving spot at hour 70
 * Car 35 parked at 70 for 5 hours
 * Car 36 arriving at hour 72
 * Car 36 parked at 72 for 3 hours
 * Car 37 arriving at hour 74
 * Car 37 parked at 74 for 3 hours
 * Car 35 leaving spot at hour 75
 * Car 36 leaving spot at hour 75
 * Car 38 arriving at hour 76
 * Car 38 parked at 76 for 8 hours
 * Car 37 leaving spot at hour 77
 * Car 39 arriving at hour 78
 * Car 39 parked at 78 for 2 hours
 * Car 40 arriving at hour 80
 * Car 39 leaving spot at hour 80
 * Car 40 parked at 80 for 9 hours
 * Car 41 arriving at hour 82
 * Car 41 parked at 82 for 2 hours
 * Car 42 arriving at hour 84
 * Car 38 leaving spot at hour 84
 * Car 41 leaving spot at hour 84
 * Car 42 parked at 84 for 4 hours
 * Car 43 arriving at hour 86
 * Car 43 parked at 86 for 6 hours
 * Car 44 arriving at hour 88
 * Car 42 leaving spot at hour 88
 * Car 44 parked at 88 for 4 hours
 * Car 40 leaving spot at hour 89
 * Car 45 arriving at hour 90
 * Car 45 parked at 90 for 9 hours
 * Car 46 arriving at hour 92
 * Car 43 leaving spot at hour 92
 * Car 44 leaving spot at hour 92
 * Car 46 parked at 92 for 10 hours
 * Car 47 arriving at hour 94
 * Car 47 parked at 94 for 8 hours
 * Car 48 arriving at hour 96
 * Car 48 parked at 96 for 5 hours
 * Car 49 arriving at hour 98
 * Car 49 parked at 98 for 5 hours
 * Car 45 leaving spot at hour 99
 * Car 50 arriving at hour 100
 * Car 50 parked at 100 for 4 hours
 * Car 48 leaving spot at hour 101
 * Car 46 leaving spot at hour 102
 * Car 47 leaving spot at hour 102
 * Car 49 leaving spot at hour 103
 * Car 50 leaving spot at hour 104

I then need to link this simulated data at a slower rate into the graphical interface that will be developed. I can then show cars in the stalls like the graphic below:



Building this type of graphical environment where I will have the ability to access and highlight or fill the stalls as needed while also having a 3d interface such as Unity would give me might be the best way to accomplish what I am looking for.



Essentially I need to be able to show cars moving into and filling the priority spots and leaving at some accurately simulated timeframe similar to the picture below. I will also need to figure out how to develop the graphical pathing for the interface when given data on actual vehicles. I am currently not sure if this will be possible or if I will simply be changing the parking spots color to indicate if it is full or not.





Vehicle Detection and Indication
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
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
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
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
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
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.

Additional Documentation
Project Portfolio

Project Portfolio