Welcome to
SmartPark

VISION


How many times did you find yourself in a giant multi-storey car park, desperately trying to find a little free spot somewhere in the bowels of the earth? Isn’t it frustrating to roam two or three completely full storeys for hours, only to discover that the last one is nearly empty? Of course it was, but now SmartPark is finally here! Forget all those endless nerve-wracking hours looking for a needle in a haystack, SmartPark will do all the work for you: all you’ll have to do is to follow a LED strip on the ground!
At the entrance of the car park, a screen will give you some quick info on the situation inside (like how many free spaces there are for each storey, and how many drivers are already searching), so that you can choose which storey you would be the most comfortable in. If the situation is critical (too few free spots) the system will come up with a list of suggestions for the best parking space among all the storeys and display it on the screen; you will be able to select one of them through the screen, telling the system where to guide you. Through an initial profiling stage, which you can carry out at home, you can instruct the system on your personal preferences; it will recognise you through your plate number when you enter the car park, and will tailor its suggestions according to your profile.
Once you’ve picked your space and gotten to the storey, a LED strip on the ground will light up and lead you there; in case you change your mind and go to another storey, or someone takes your space, the system will quickly come up with an alternative, so that you’re not left behind. This same path will also show you how to properly enter the parking spot, in case it is very narrow or you’re just a bit clumsy: acoustic signals and flashing lights will warn you if something is wrong with your parking manoeuvre, and you risk hitting the wall or another car.

Sensing

Detection of occupied spaces, and of incoming and outgoing cars. Plate number recognition. Monitoring of the progress along the path provided, and in the parking manoeuvre.

Acting

Luminous pathway on the ground. Acoustic and visual feedback during the parking manoeuvre.

Reasoning

Understanding when it is appropriate to give suggestions; in that case, choosing the best storey to optimise load distribution. Choosing the options for the parking spot to prompt to the user, based on his preference and current availability.

Interacting

Provision of information on the current occupation of the spaces. Possibility for the user to tell the system which parking space it should lead them to, and to customise the options to be prompted through their profile.

AMI FEATURES


img02

Responsive

Follows the user’s indication in lighting up the right luminous pathway. Promptly responds to driver’s errors in the parking manoeuvre.

RESPONSIVE
img02

Sensitive

Detects which spaces are occupied. Recognises plate numbers. Tracks the user’s progress along the pathway, and in the parking manoeuvre.

SENSITIVE
img02

Adaptive

Tailors suggestions based on the user’s preferences and the current availability (i.e. how cars are distributed in the parking lot). Adjusts the target spot if it's taken before the user can reach it, or if they change their mind.

ADAPTIVE
img02

Transparent

Refrains from giving suggestions when they are not necessary. Seamlessly blends into the environment, requiring little effort of the user for interaction.

TRANSPARENT
img02

Ubiquitous

Gathers information from and acts upon the whole environment, from the entrance, to the aisles, to the parking spaces themselves.

UBIQUITOUS
img02

Intelligent

Assesses the current situation to decide whether or not to intervene. Optimises load distribution among and within storeys. Interprets user’s preferences.

INTELLIGENT

PURPOSE AND SCOPE


NOTE: Quoted text refers to the same element/condition referred to by the same text earlier in the section.

SmartPark aims to enhance the user experience in a multi-storey car park. The main problem it tries to solve is that of having to drive for a very long time to find a free spot; additionally, it also tries to prevent excessive load imbalacement between storeys, and helps users in the parking manoeuvre.
At the entrance, a screen provides information on the situation inside: for each storey, it shows how many free spots there are, and how many drivers are already inside trying to park. In suitably defined critical conditions (i.e. when the user cannot be expected to easily find a parking space on their own), the system exploits the knowledge it has of the “situation inside”, and suggests a list of candidate spots to the user through the “screen”; the user can then select the one they prefer, and the system will lead them there.
This “list” is built following the preferences of the user, so as to give more relevant suggestions. These preferences are acquired through an initial profiling stage, which can either be carried out through an app or through a Website. Furthermore, the system also follows an optimisation logic, trying to prevent “excessive imbalancement between storeys”; if the user diverges from their initial choice (i.e. goes to another storey), or the chosen spot is taken before they can reach it, the system comes up with an alternative one to lead them to.
Once at the storey, the system actually guides the user to the target space through a LED strip on the ground: the LEDs turn off once the car has passed them, so as not to interfere with other strips; furthermore, all strips are of a different colour, so as to avoid ambiguity when two of them intersect. The system also provides parking assistance, informing the user through flashing lights and/or acoustic signs if they are about to collide with a wall or another car. Furthermore, it can project on the ground a video demo, showing the right steering angle to correctly enter the parking space.

PROJECT FEATURES


Priority legend: P1 P2 P3

  1. The system informs the user on the current availability of parking spots
    1. It shows the user how many free spaces there are, for each storey
    2. It also shows how many cars are currently searching for a parking spot, for each storey
  2. When it’s hard for the user to find a parking spot on their own, the system prompts a list of suggestions, aiming for optimal load distribution
    1. The user can select a spot from the proposed list, signalling the system to guide them there
    2. The choice is non-binding, i.e. the system adapts if the user changes their mind
    3. The proposed list is built according to an internal optimisation logic, which tries to prevent excessive imbalancement among and within storeys
    4. In non-critical situations, the system steps back and does not interfere with the user choices
  3. The system can record user preferences
    1. It provides an interface (Website / app) to the user for profiling purposes
    2. It uses such preferences to include more relevant suggestions in the proposed list
  4. The system guides the user to the target parking spot
    1. When the user enters a storey, a LED strip on the ground lights up to drive them to the target
    2. The “guidance” is unambiguous: every strip is of a different colour
  5. The system provides parking assistance to the user
    1. It gives visual or acoustic feedback when the car is about to collide with a wall or cross a line
    2. It projects a demo on the ground, showing the user the right steering angle to correctly enter the space

ARCHITECTURE


The User-Management Server hosts the database containing the user preferences and the interface to it, i.e. the Website for user profiling and the API to provide preferences to the Target-Decision Servers; it is global and separate from any particular parking lot, to allow for scalability, in case multiple parking lots need to access the same user profile.
The Target-Decision Server is the central one, unique for every parking lot. Its task is that of drawing up the list of candidate spots for a given approaching user, to manage the touch-screen in order to acquire his choice, and to communicate this choice to the competent Area-Control Server, when asked to. The user is recognised through a plate reader at the entrance, and their preferences are retrieved via the API provided by the UMS: to build the list of suggestions, it listens for data from the Spot-Occupation Sensors inside.
The Area-Control Server manages the storey-level events: when a car approaches, the user is recognised through another plate reader, and a target spot is asked to the TDS; the ACS also manages all the LED strips (using data from Path-Progress Sensors) and the parking assistance.
The Message Broker is a Publish-Subscribe Message Protocol Server, which relays messages from Sensor Gateways to Servers and from Servers to Actuator Drivers. Sensor Gateways are charged with translating raw sensor data into the common Protocol format; each sensor in the system interfaces with one Sensor Gateway, possibly shared among several ones.
Likewise, Actuator Drivers translate Protocol messages into commands to actuators; each actuator interfaces with one Actuator Driver, possibly shared among several ones. Despite having a diverse set of sensors and actuators, they are represented uniformly in the Architecture Diagram, withouth specifying their type or location, because they all communicate in the same way with the remainder of the system.



Only for prototyping purposes, the full-fledged system would require a much higher complexity.

Computational nodes
  • 1 notebook for User-Management, Target-Decision, Message Broker and Area-Control
  • 1 Arduino board, for interface towards sensors and actuators
Devices (sensors and actuators)
  • 1 presence sensor for each parking spot, to detect occupation
  • 1 camera, for plate recognition
  • 1 passage sensor at the exit of the storey, to keep track of circulating cars
  • 2 line-crossing sensor for each parking spot, for parking assistance
  • 1 LED strip
  • A number of presence sensors along the LED strip, for progress monitoring
  • 1 acoustic speaker, for parking manoeuvre feedback
User Interface Devices
  • 1 Tablet for touch-screen at the entrance


User Management
  • A Web Application for user interaction
  • REST API to provide information to Target Decision Servers
Message Broker
  • MQTT Server
Target Decision
  • Event processor: receives and dispatches events from Message Broker
  • Occupation tracking: keeps track of occupied spots and circulating cars
    • Listens to "Spot-occupation" sensors (via "Event processor")
  • Target spot assignment:
    • Provides a list of candidate spots for a given plate number
    • Provides the assigned spot, when given a plate number and a storey
    • Records user choice for favourite parking spot
  • Parking entrance: handles the arrival of a car
    • Receives events from plate reader at the entrance (via “Event Processor”)
    • Manages touch-screen interaction (via REST API), using info from “Target spot assignment” and “Occupation tracking”
    • Relays user choice to “Target spot assignment”
Area Control
  • Event processor: receives events from Message Broker
  • Car guidance:
    • Queries “Target spot assignment” (via REST API)
    • Manages LED strips
Sensor Gateway
  • Sensor adapter: translates physical input data from sensors into MQTT publish messages
Actuator Driver
  • Actuator adapter: translates received MQTT subscribe messages into physical commands to actuators
Touch-Screen
  • User interaction: displays information on the situation inside, and relays user choice to TDS


The network architecture consists of just three nodes: the notebook, the Arduino board, and the Tablet, all communicating within the same logical private subnet.
The notebook will host all the different servers in the project, which, in the real world, would communicate over the Internet: this behaviour is maintained in the prototype, as multiple processes/threads will exchange data via HTTP.

SELECTED COMPONENTS


HARDWARE

  • Active IR sensors, implementing presence sensors along the LED strip, line-crossing sensors, spot-occupation sensors and passage sensors at the exit
  • One speaker for parking assistance
  • One addressable LED strip
  • One notebook, hosting the User-Management, the Target-Decision, the Message Broker, and the Area-Control
  • One Arduino Yun, acting as Sensor Gateway and Actuator Driver
  • One Tablet, hosting the Touch-Screen utility
SOFTWARE

  • Flask framework for Web Applications in Python
  • Remote API (openALPR) for plate recognition
  • MariaDB server
  • Mosquitto for MQTT server
  • paho library for MQTT client in Python
  • PubSubClient library for Arduino-MQTT interaction

OPEN ISSUES


  • To what extent should we provide parking assistance? Proximity to wall or line crossing?
    Only line crossing, because of hardware availability
  • Should the parking assistance be "automatic" (acoustic speaker automatically responding to proximity sensor) or mediated by the Area-Control Server?
    Automatic (mediated by Arduino board) for simplicity reasons
  • How detailed should the profiles be?
    Just the possible preferences, against which the TDS tests the properties of each free spot
  • How should the system behave with one-time users (when no profile is available)?
    It only takes into account the free spots
  • How should we provide path unambiguity?
    Each strip is of a different colour
  • How should the TDS asynchrounously send the list of suggestions to the Touch-Screen?
    It doesn't, a normal website is more than sufficient

Our Team

author

ELIA ANZUONI

Backend Developer

236358

s236358@studenti.polito.it

Follow @elianzuoni

author

ANDREA BRUNO

Frontend Developer

234330

s234330@studenti.polito.it

Follow @AndreaBruno97

author

ALBERTO CASTRONOVO

Hardware Developer

246026

s256026@studenti.polito.it

Follow @albertocastronovo