PRE2019 4 Group8

Towards a Design and Model of a Parking Assistant Robotic System

Presentation: https://youtu.be/15LSWbLM3mA

Group Members

Name	Student ID
Sietse Backx	1255924	s.backx@student.tue.nl
Rien Boonstoppel	0946480	d.j.boonstoppel@student.tue.nl
Luc Geurts	1237117	l.p.a.geurts@student.tue.nl
Mandy Grooters	1236053	m.grooters1@student.tue.nl
Tar van Kieken	1244433	t.m.k.v.krieken@student.tue.nl

Introduction

Visiting the airport usually results in a lot of stress. You need to take your clumsy luggage through the whole airport, wait a lot in different lines and after that sit in a too-small chair in the plane before again entering different waiting lines at your destination. However, it can get worse by trying to park your car in what seems to be a never-ending, saturated parking lot on the airport. Parking demand often does not meet the supply and in combination with a shortage of parking staff, this results in leaving drivers with frustration.

A survey performed by the Airports Council International has revealed that up to 50% of the total revenue of an airport is generated by non-aeronautical services, including parking. For example in Denver, 13% of the total revenue from the parking services and in Minnesota even 30%. This also includes the rental of vehicles for people on their holiday or business trips. This shows that parking is a big and important part of the revenue of airports and that making parking more efficient and attractive for users, could have a big positive impact on the income of the airport.

When opening a parking lot for an airport, there are several key aspects to take into account with regard to transportation and vehicle placement or traffic management in general. Often, there is not a lot of road capacity at the airport, which makes it hard to build a big parking lot. Also are the costs a big and important factor for the building and maintaining of a parking lot, because a parking lot is a big investment of an airport. A solution to this problem is to use more public transport as a way to get to the airport. Schiphol, for example, has his own train station under the airport, to encourage people to get to the airport with the train. If all these measures still lead to congestion, a new solution must be found.

Analogously with airport parking lots, in large cities, parking is also a considerable problem. Nearly 30% of traffic congestion in cities is caused by drivers looking for a parking spot . Designing a parking system such that drivers can find a parking spot faster is therefore essential. Common solutions involve a LED system to indicate free and occupied parking spaces, however, these solutions do not control traffic flow. Another option which does take into account traffic flow is automatic parking spot assignment. Automatic parking assignment can compute optimal routes taking into account lot occupancy, travel distance, conflict avoidance and walking distance . Nonetheless, this solution is limited to mobile phone use.

Objectives

In this part is stated what the goal of the project is. The subject and problem statement is listed and RPC's are chosen to focus on in the project itself. In the end is decided which end products we want to deliver.

Subject

A robotic parking assistant which helps drivers to find a parking spot in a parking lot of an airport (in this case Schiphol) and simultaneously optimizes traffic flow for faster parking.

Problem Statement

In summary, the key issues to resolve are the enormous rise in demand of better parking conditions in parking lots. These issues result in congestion and frustration of drivers due to the delay suffered from finding a parking space. This project researches the possibility to improve the parking experience on parking lots. Focus is on parking lots with a proper road surface and a limited number of entrances/exit. These constraints exclude temporary parking lots on meadows or general parking spots along a road. In addition to the research, a partial solution is designed for the issue by making a design of the parts of the system that the user would interface with, and software to manage the parking lot plus a simple simulation.

RPC's

In order to investigate possible solutions, requirements, preferences and constraints have to be established.

Requirements

• The system should be able to know in which path and row in the parking lot it is located at any moment in time.
• The system should be able to operate autonomously.
• The system should regulate traffic flow for both entrance and exit of the parking lot, taking into account the total capacity of the parking lot.
• The system should detect if cars are parked on the wrong parking spot or more than 20 cm over the parking lines and take this into account in the determination of free parking spots.
• The system should not come closer than 0.7 meters to the secondary users
• The system should be able to detect when the secondary user needs a parking spot for disabled or older people.
• The system should be able to communicate with the secondary users in a clear way where they need to go for their designated parking spot (97% of the people should understand the communication).
• The system should have a help option to solve parking issues and if needed contact the primary user to help the secondary users
• The system should handle cars up to 5 meters in length and up to 1.8 meters in width.
• The system should be waterproof.
• The system should be cheaper to exploit than current valet-parking options over a span of 10 years.

Preferences

• The system should be able to handle payments at the exit.
• The system should be able to read the licence plate of the cars.
• The system should be able to guide the user to its car when they forgot their parking space, based on the license plate.
• The system should be able to investigate the parking layout by itself.
• The system should give users the opportunity to state their parking preferences and handle those accordingly.
• The system should be able to instruct the driver to park their vehicle properly if it is misplaced.
• The system should have a feedback option.
• The system should have an emergency option.
• The system should be able to fill a parking lot with cars in a shorter time than current valet-parking options.
• The system should be able to measure the length, width and height of the incoming car, in order to know whether it fits in certain parking spaces.

Constraints

• The system should be ground-based.
• The parking lot has clear entrance(s) and exit(s) which can be regulated and entrance.
• A parking space has the following dimensions in the Netherlands.
  • 5 meter length by 2.4 meter width, when perpendicular parking.
  • 6 meter length by 2.5 meter width, when parallel parking.
  • 6 meter length by 3.5 meter width for the disabled parking space when parallel parking.
  • 5 meter length by 3.5 meter width for the disabled parking space when perpendicular parking.

Airport

There is chosen for the focus of the parking robot on an airport parking lot. One property of such kind of parking lot is that there will be cars entering and leaving the parking lot the whole day. This is different from things like amusement parks, where you have a spike in people entering at the opening time and a spike of people leaving at the closing time. This results in that the robot needs to be good in the managing of the available parking spots in the lot. In an amusement park or event, it is easier to just fill the parking spots from the entrance until the back. However, in an airport parking lot are there continuously people leaving and entering, which makes it more of a challenge for the software to choose the best parking spot available at any time. Another parking lot, for example at a mall, could also be chosen for this project. This would also have the challenge of people continuously leaving and entering. There is however chosen for the airport parking lot application because there are more user preferences in an airport parking space. There are people with a lot of luggage, who want to park close to an elevator, people who want to park close to the entrance, people who only want to drop a person off and so on. This makes that there needs to be more focus on the users and thus more on the preferences of the car drivers. This must be incorporated into the software and result in a bigger challenge.

Deliverables

The goal of the project is to deliver a design for the parking robot. This design is dependent on the needs of the users, the requirements made earlier and the working space, which is, in this case, a parking lot on an airport, like Schiphol. Furthermore, a software needs to be developed, which recognizes parking spaces and gives the best parking spot dependent on the preferences of the user. This wiki page will also be finished in such a way that it shows the complete progress made during this project. Lastly, a presentation video will be made, that shows the steps that made in this project.

User, Society and Enterprise

There are different users which will use the parking robot. It is important for the design of the hardware and software to take the needs of these different users into account. This chapter lists the different users with their needs and researches the best way for the interaction of the robot with the users.

Users

The primary users of the parking robot are companies that are dealing with large parking lots. Such as airports. These companies want to improve the experience of their visitors by avoiding parking problems. The parking robot will significantly decrease the waiting times for a parking spot and thus increase the overall experience of the visitors.

The secondary users are the visitors of the airport that are directly interacting with the parking robot to find a parking spot. The parking robot can quickly guide them to a parking spot. Without the parking robot, visitors would have to wait longer which adds stress and frustration to their day which will decrease their experience . These secondary users can be divided into different categories which are again assigned to their designated parking areas. The primary users can assign these specific areas to their preferences and it depends on their targeted audience. As an example, one can have a different parking area for disabled people, an area for the elderly and an area for large families. These groups all have different preferences with respect to where they want to park. To elaborate on this, the elderly for example, they want to have parking spaces closer to their destination which will provide them with a shorter walking distance. Disabled people will also want their designated parking spots close to their final destination and extra room for parking as they sometimes are dependent on wheelchairs or other devices. As for the family category, they don’t need any special preferences as they can just be used to fill up the remaining parking spots when all the others have been assigned.

Society

For society, the parking robot can have great improvement opportunities. The parking robot will be more efficient than the current traffic controllers, which will improve the traffic flow around the parking lots. Consequently, the traffic flow on high- and motorways around the parking spot will improve. Therefore, people that do not visit the airport will not experience any delay in their travel due to this effect. Furthermore, congestion increases fuel consumption, environmental pollution and traffic accidents. So the parking robot will have a decreasing effect on these matters too.

Enterprise

From an enterprise perspective, multiple groups can take advantage of the parking robot. First, the organization of airport parking garages. They don’t have to deploy traffic controllers anymore. Which eventually could decrease their overall costs. Secondly, the research that will be done is interesting for the development of other robots. The navigation and communication technique used in the parking robot could be applied in other areas as well. When the parking robot will be developed on a larger scale, robot companies have to produce more robots than they do now, which will eventually decrease the cost per robot. The profit companies make, because of the enhanced traffic flow caused by the parking robot, could be used to do more research on parking robots or robots who use this navigation and communication technology in general. Such can lead to the continuous improvement of the used techniques.

When summarized, the following user groups can be identified:

• Deployer companies: The companies deploying the system.
• Drivers: The people that need to park their car.
  • Disabled people: People that need to find a parking spot suitable for people with physical disabilities.
  • Infirm people: People that have walking difficulties.
  • Bad drivers: People that have more difficulty with driving and parking.
  • Average people: People that don't have special needs of any type.

Human Robot Interaction

It is very important that the robot can interact in a clear way to the primary and secondary users. In this chapter, research is done in the different ways that the robot can interact with the users. These different ways are first listed and then is a survey under secondary users done to decide on the best way to let the robot interact with the user.

Communication Methods

4 different communication methods between robot and user are listed below with a drawing in the end to show how this will look like in the case of our robot.

Touchscreens

Because of the current state of the world about the coronavirus touch screens might be a debatable choice. Although it is not yet scientifically proven that this virus is spreading over surfaces, it is widely proven that touchscreens are a possible contamination hazard.

When looking into possibilities to keep touchscreens clean and safe to use, two options where found. The first option is the so-called ‘NanoSeptic Continuously Self-Cleaning Surfaces’. This company makes mats that keeps its surface clean by using mineral nanocrystals, which are powered by light and generate an oxidation reaction stronger than bleach[1]. Those mats are also produced in clear films, which can be applied to touchscreens. The latest test by an independent FDA-compliant US lab showed that the NanoSeptic surface eradicated the human Coronavirus in less than 30 minutes. Results from overseas research centres have also confirmed its effectiveness. [2] The second option isn’t available (yet). It is based on a patent that Microsoft filed a couple of years ago [3]. Using a UV backlight in the touchscreen panel, germs and viruses are killed. With a combination of total internal reflection and proximity sensor the panel will make sure the user isn’t exposed to the UV. However, because the first option is already on the market and proven to be effective, it is best to use a NanoSeptic clean film, instead of investigating in the possibilities of the UV backlight.

Speech-based

The voice is the most prominent and the primary method of communication among human beings. With speech, humans can also communicate with robotic systems. However, the possibility that the proposed system is going to be used in busy and noisy environments is quite high. So there needs to be some sort of enhancement over a simple microphone. In 1990 already the research on the use of microphone arrays in order to enhance speech recognition based on beamforming. In recent days, Google has made huge improvements with their Cocktail Party challenge. With only a single audio track but with an added video feed, they were able to completely isolate voices. So possibly by combining those both solutions will lead to a great performance on speech recognition in busy and noisy environments.

Gestures based

The second possible way for interaction with the robotic system is gesture-based. Some research is done on the use of gestures for the interaction. For example by using cameras or a Kinect to view gestures of the secondary users. However, this can be difficult because of the restricted space a driver has behind the wheel. Maybe using hand signals is possible.

Touchless display

A different, more experimental approach is more like a classic touchscreen. However, without touching the actual screen. A touchless display is developed which can sense local variations of the humidity in the air. When you point a finger, local air humidity changes, which can be translated tot spatial information using those ultrasensitive humidity sensors. The simplicity of the interaction via a touchscreen-like display is already widely acknowledged, so that is an advantage. But it is a very experimental display so its reliability has yet to be proven.

The partial solutions to driver communication.

Survey

A survey was done to investigate the secondary users’ opinion about communication with the parking robot. The goal was to determine which form of user-robot interaction is preferred. This was done by asking questions about the way of communication between the robot and the secondary users and about what people would do in situations that may occur. Such as what they would do when they don’t understand the robot. This data is used to determine the way the robot will communicate with the secondary users.

A total of 175 people have filled in the survey. The largest part of the people (around 60%) are in the age group of 18-30 years old. The other 40% consists of mostly people between 31-50 years old (25%) and people between 51 and 70 years old (15%). Furthermore, there is asked about the education, if the person has a driver license and if they have a technical background. The education was found out to be quite split between high school (28%), vocational education(19%), university of applied sciences (25%) and University (26%). Over 85% had a driver licence and over 60% had a technical background, which can be a technical study or working in a technical company.

There was also asked about the affinity the participants have with robots. Because this may influence their opinion on the parking robot. And with this data the participants general view on robots can be compared and connected with their view on the parking robot. People could rate their affinity with robots with a grade between 1-10. Where 1 means no affinity at all and 10 means that they have a lot of affinity with robots. The average grade people gave was a 5.7.

To determine the participant's opinion about the ways of communication, several scenarios were presented in which they could choose their preferred way of communication. For example, people could choose how they want to be greeted by the robot and how they would like to communicate any special preferences they may have.

The robot can communicate with the secondary user in several ways and each method has its own advantages and disadvantages. Touchscreens are a common and easy way to communicate. However, touchscreens are a source of bacteria and the current coronavirus might change the participants opinions about touch screens. Another option is to use speech, but this can be hard to communicate clearly if, for example, someone doesn't master the language or if the communication takes place in a noisy environment. These disadvantages were also presented to the participants such that they could take this into account while answering the questions.

Touchscreens/speech

Despite the coronavirus, 60 % of the participants preferred to communicate their preferences with the use of a touchscreen. Only 4% of the participants would like the robot to communicate via speech at which they have to react via speech. So, there is concluded that the parking robot will communicate with the secondary users by using a touchscreen. And since it is necessary to make the touchscreen clean and safe to use, a self-cleaning surface will be used.

Text/icons

Furthermore, some questions were asked about the way that the parking place should be communicated in the best and clearest way to the driver. There is chosen for the options of icons, text or icons with text to communicate with the driver. There was also an option of an attached arm to the robot, which shows the direction where the driver needs to go. From these questions, it was found that most of the participants want to have text, sometimes accompanied by icons because they think that this is the clearest method. The only option in which they did give this answer, was with the arrow icon, which when you arrived at your parking spot. The conclusion from this is that it is only chosen for non-ambiguous emojis. The arrow emoji is in this situation the only emoji from which it is immediately very clear what it means without more explanation with text. From this data, it is decided that arrow icons are used to point at the designated parking spot, but a combination of icons and text is used at the arrival and departure.

Preferences

In the beginning of the survey was asked if the user would want to give preferences to the parking robot when they enter the parking lot. Over 75% of the users did want to communicate their preferences to the robot if that means that they get a better parking spot that takes their preferences into account. When asked what preferences the users have in the survey, it was found that 63% of the people would like the parking spot closest to the entrance. There were also a lot of people who wanted to have the largest parking space or the easiest driving route. There were also some preferences added, such as the parking space with the easiest way out of the parking lot and the safest way to park their car. From these results can be concluded that the secondary users indeed have preferences with respect to their parking spot. Hence, the option that allows the secondary users to communicate their preferences will be included in the parking robot. The preferences of the users will be communicated with the robot via a touchscreen. As an addition, the parking robot will have the option to remember the preferences connected to each license plate. Such that people who visit the parking lot multiple times can be guided to their parking spot even faster. When someone enters or leaves the parking lot they will get the question if they want the robot to remember their preferences. Current parking lots also save license plates to keep track of the number of cars that are in the parking lot. The robot will also remember license plates for the same reason. When a car leaves the parking lot, this data will be deleted if the user did not give consent to save the preferences.

Correcting function of the robot

When someone is not parked neatly this could make that the parking lot cannot be used completely or that it is harder to park for other people. The participants were informed about this and were told that the parking robot can correct someone when they did not park neatly to solve this problem. The participants were first asked to rate how they would feel about a robot correcting someone in general with a grade between 1-10. Where 1 means that they do not like that idea at all and 10 means that they really like the idea. After this, they were asked to rate how they would feel if the robot would correct them. People rated correcting someone in general with an average of 7.0 and correction themselves with an average of 6.3. From this can be concluded that people like the idea of the robot correcting someone and this will be implemented in our robot. The robot can correct someone in several ways, the robot can display a text, show an animation of a car that parks again, or use augmented reality to show where the car is not parked correctly. The two options that were chosen the most were augmented reality (36%) and text (35%). Only 11% would like an animation that shows a car that parks again. There is chosen to combine text and augmented reality to give the clearest instructions to the drivers. When someone does not react to the robot the robot will try again by showing the text and augmented reality footage. There needs to be tested how many times the robot needs to continue with correcting the wrong parked driver. The robot should then be placed behind the parking spot, such that the driver can see the robot displayed in the rearview mirror, or in front of them if he is parked back first. When the driver still doesn’t park again the parking robot will registrate how the car is parked and will take this into account when assigning parking spots to other cars. When someone parked their car a large part across the line, the robot will check if cars are still able to park next to that car. And if necessary, the robot will only assign the partly occupied parking spot to a smaller car or registrate that no car will fit in there. Most importantly, the robot should always be kind to the drivers, and never be offensive or pushy, even when someone is not following the directions of the robot.

Not understanding the robot

It could happen that someone does not understand the robot and there is asked how people would react in such a situation. The two options that were chosen the most were that the person would drive off and just find a parking spot themself (50%) and that the driver would stand still and wait on clearer instructions (40%). The first option will not be a big problem for the robot, only that the robot does need to know where the user eventually parks such that the system will not see this as a free parking spot. The second option can be a big problem for the parking lot, because it obstructs the traffic flow when someone would standstill in the middle of the parking lot. The robot should be able to notice when someone is not understanding the directions and is standing still. When this happens the robot will show the directions once again. There needs to be tested how many times the robot needs to continue with giving explanations. When after some time the driver is still standing still, the robot will show a screen that says the driver can search for a parking spot on their own. After this, the robot should register their chosen parking spot. But there needs to be made sure that the communication between the robot and the user is very clear such that the previously mentioned situations will not occur often.

Finding back your parking spot

The parking robot could help people with finding back their parking spot by remembering their license plate. The participants were asked if they would like this feature. Most of the participants (79%) think this feature is useful. The other 21% has some objections towards this feature such as a lack of privacy or not wanting to remember their license plates themselves. People are not required to use this feature, so not remembering their license plates won’t be a problem.

When someone wishes to make use of this feature, one can walk to a dashboard at the beginning of the parking lot. Here can the user fill in their licence plate and the display will show a map of where their car is parked. One can read more about this feature in the recommendations.

Interface of the robot

Below one can see some parts of the interface of the robot that followed from the survey.

• 

  Welcome screen
• 

  Select your desired language

• 

  Communication of preferences
• 

  Remembering of the preferences

• 

  Follow the robot on your way to the designated parking spot
• 

  Arrived at the parking spot, arrow is pointing at the parking spot

• 

  Correction of bad parking
• 

  Final screen after wich the robot will drive off

Primary users

In the previous section, the different types of users were elaborated. In this section the needs of the primary user are discussed.

The primary users are the companies which own and manage the parking lot. In order for them to invest in the parking assistant robot, the robot needs to be more beneficial than the current system in several aspects. The first aspect is cost. If the robotic system offers similar benefits for a smaller price, companies might consider to buy the system. Another scenario might be that the robotic system is slightly more expensive, but offers features to increase parking lot profits. An example of this could be that lots which are close to the exits are made premium parking lots. The secondary user could specify to the robot that he/she desires a premium parking lot with additional charge. Another aspect is the amount of parking lots available. Currently, parking garages count the arriving and exiting cars at the barrier. This method is flawed as some drivers rapidly follow after the previous driver. On top of that, double parking is not accounted for. With the robot, a more accurate count can be kept of the available spaces so that a better indication could be given to arriving customers. Additionally, parking lots for regular customers with a subscription could also be used if the customers are not using the lots. The system could message these users. If an incentive is given to these users for offering their space, such as a discount, both the primary user and secondary user could significantly profit. Finally, the most important factor is safety. The primary user will not invest if the robot endangers users.

Software

The first deliverable is the software which can be used in the parking robot to determine the best free parking space in the parking lot dependent on the preferences of the users. This software is developed in this chapter of the wiki page.

State-of-the-art

A lot of technologies are produced for the tracking of the availability of parking spaces. The simplest and first technology for tracking the availability, is the tracking of the total capacity of the parking lot and the amount of cars which enter and leave the space. This is already used in a lot parking spaces of malls, theme parks or other parking lots with a clear enter and leave point.

The second method is to check if there is a vehicle on a parking spot with a detection unit on every parking unit itself. This detection unit can for example be an induction coil, ultrasonic sensor, infrared sensor, pressure sensor or a microwave sensor. The information of all detection devices is then gathered in one management system, to check the overall availability of the parking lot. The individual spots can be characterized by giving a value of 1 or 0 in the system or by setting them as “AVAILABLE” or “OCCUPIED” on the place where it is shown to the user.

Another method for the tracking of free parking spaces, is to use a given three-dimensional model of the parking lot. A capture device can then be used to represent an image of the parking lot, which can be compared with the three-dimensional model of an empty parking lot. From this comparison of the two three-dimensional models, the availability of parking spots can be determined and translated back to the user.

The parking lot can also be divided in different slots of a certain number of parking spaces. For example, ten parking spaces can be divided into two slots of five parking spaces. The GPS of cars can be used to track in which parking slot the car is located. From this information can be determined how many parking spaces are left in each parking slot and can the next car be directed to the parking slot with available parking spaces.

All the previous systems use some kind of tracking method to determine the availability of the parking spaces. Another method is predicting the availability of parking spaces by looking at patterns in old data. With this method is giving a precise number of available parking spaces not possible, due to the accuracy of long term predictions, the other parking lots in the area and the user behavior. However, if the accuracy of this method is high enough, can it still result in good approximations of the vacant places on parking lots.

Product

A prototype was written for the software that could manage the parking lot, the API. This software keeps track of the state of the parking lot, determines the best parking spaces given some preferences and calculates the routes for the robots to take. This software is not ready for real world usage, it covers most of the necessary managment but ignores important details.

The software relies on a simplification of the parking lot, in the form of a graph. This means that owners of the system will have to model their parking lot into a suitable graph. This graph is stored in a simple JSON format, similar to an adjacency list. In order to help the parking lot owner to create this graph, the software creates a simple graph editor with basic functionality. Every edge and node in the graph should be labeled with a relevant subset of the following node and edge tags:

Node:

type	description	color
Parking spot	Indicates that the given node is a parking spot	magenta
Vehicle entrance	Indicates that the given node is a vehicle entrance of the lot	green
Vehicle exit	Indicates that the given node is a vehicle exit of the lot	red
Pedestrian entrance	Indicates that the given node is a pedestrian entrance of the lot	dark green
Pedestrian exit	Indicates that the given node is a pedestrian exit of the lot	dark red
Robot queue	Indicates that the given node is a node that a robot can stand when idle, any edge leading up to such a node can be considered part of the queue	black
Robot spawn	Indicates that the given node is a node that a robot can be added at, and leads to a queue node through (implicit) queue edges	black

Edge:

type	description
Robot path	Indicates that the given edge may be traversed by a robot
Vehicle path	Indicates that the given edge may be traversed by a vehicle
Pedestrian path	Indicates that the given edge may be traversed by a pedestrian

Within the graph editor every node gets the color of the first assigned tag of the node to increase readability. A node can have multiple tags at once without issues, but only the color of the first tag will be displayed.

Because there was not managed to create a prototype of the robots during this project, the software contains a webpage that visualizes a simple simulation. This simulation uses the centralized API that the robots would also use, meaning that the parking lot information is shared between different clients. Every person that opens up this webpage will act as a robot in the system, thus adding 1 robot to the parking lot. In order to add multiple bots, one can simply open up multiple tabs with the same site. These tabs need to be visible however, or otherwise most browsers will go into a background mode that slows down the simulation.

User manual

The software is currently hosted at https://botparker.herokuapp.com/ for demonstration purposes. This site may be offline in the future, in which case the results can be viewed by manualy hosting the code. Instructions on how to achieve this are present in the implementation details section below.

Graph Editor

The graph editor can be reached at the /edit path of the website, E.g. https://botparker.herokuapp.com/edit. The editor consists of two section: The main section containing the graph on the left, and the controls section on the right.
The graph can be moved by dragging the mouse while holding down the scroll wheel, and can be scalled by scrolling while holding the ctrl key down.
The controls section contains 3 subsections: The view filters, IO, and tools sections. These controls are described below. Tools can be switched by either pressing the tab of the tool, or scrolling the mousewheel without holding down the ctrl key.

Parking lot editor page

View filters What nodes and edges are shown in the graph section can be altered using the filters in the controls section. The top area shows two dropdown boxes in which tags can be selected. Only nodes and edges containing these tags will be shown in the graph section. A special 'tag' with the name empty is also provided to include nodes that don't have any tags. IO This section contains two buttons, for importing and exporting the graph. Both of these buttons bring up a modal box with a textbox that can be used to either copy the graph from or paste it to. The graph is represented in a json format and can also easily be modified programmatically using for instance javascript. The type of the graph can be described using the following TypeScript code:

   type IParkingGraph = {[ID: string]: IParkingNode};
   type IParkingNode = {
       x: number;
       y: number;
       edges: INormalizedParkingEdge[];
       tags: IParkingNodeTag[];
   }
   type IParkingEdge = {
       end: string;
       tags: IParkingEdgeTag[];
   }
   type IParkingNodeTag =
       | "spot"
       | "entrance"
       | "exit"
       | "pedestrianEntrance"
       | "pedestrianExit"
       | "botQueue"
       | "botSpawn"
   type IParkingEdgeTag =
       | "carPath"
       | "pedestrianPath"
       | "botPath"

Selector tool The selector tool can be used to select and edit nodes and edges. When the tool is selected, clicking in the graph will result in selected nearby nodes and edges. Only a single node or edge can be selected at a time, and it will cycle through nearby nodes and edges on every click to make all accessible (even if they overlap). Both nodes and edges will show a delete button when selected, in order to delete them from the graph, as well as a dropdown to select the tags to apply. In addition, nodes show their name and location, while edges show the IDs of the start and end location. Node tool The node tool can be used to add new nodes to the graph. When the tool is selected, clicking in the graph will result in a new node being created. This node will simply get a new unique ID by counting upwards, but can be renamed later using the selector tool. The node tool allows you to specify the position precision, in order to snap nodes to locations in the grid. If E.G. 0.25 is selected, both the x and y coordinates will automatically become a multiple of 0.25 when the node is created. In addition a tags dropdown is provided in order to specify the tags that newly placed nodes should spawn with. Edge tool The edge tool can be used to add new edges to the graph. When the tool is selected, clicking a node and dragging to another node will create an edge from the start to end node. A toggle is provided to allow edges to be created in both directions with a single drag. In addition a tags dropdown is provided in order to specify the tags that newly added edges should spawn with.

Simulation

The simulation can be reached by going to the root path of the website, E.G. https://botparker.herokuapp.com/. The editor consists of two sections: The main section containing the graph on the left, and the controls section on the right.
The graph can be moved by dragging the mouse while holding down the scroll wheel, and can be scalled by scrolling while holding the ctrl key down. Each client that connects to the simulation will provide their own robot to guide customers and add it to the simulation. This robot should automatically become visible in the graph.
The controls section contains 3 subsections: The view filters, customer controls, and override controls.

Parking lot editor page

View filters What nodes and edges are shown in the graph section can be altered using the filters in the controls section. The top area shows two dropdown boxes in which tags can be selected. Only nodes and edges containing these tags will be shown in the graph section. A special 'tag' with the name empty is also provided to include nodes that don't have any tags. The API creates routes for customers while performing its calculation to find the optimal parking spot. When a robot requests a parking space, this route is returned as well. The last dropdown box can be used to show or hide sections of this planned customer route.

Customer Controls Customers can be added using the 'Add customer' button. This button will spawn a new car at the lot entrance and store the preferences in the customer. These preferences can be entered using the two textboxes above: walk cost and turn cost.

The walk cost represents how much someone dislikes to walk, in relation to driving. If E.G. '5' is entererd, it means that the customer would rather drive 5 meters than walking 1 meter. So if you want to be as close as possible to the pedestrian exit, you would want to enter a very high number here, lets say 1000 000 000 (since we can quite safely assume no parking lot would ever require you to drive this far). This way the cost of walking totally outweighs the cost of driving. This could however result in having to drive very far in order to get close to an exit, while perfectly fine parking spots are available nearby, which may also be close to exits. This high of a walking cost is probably not preferable in practice. On the other end of the spectrum, we could set the walking cost to 0. This would result in the system totally ignoring how far away the parking spot is from a pedestrian exit. It would instead make sure that the parking space is as close to the vehicle entrance and exit as possible, such that the least amount of driving is required.

The turn cost represent how much someone dislikes to take turns, in relation to driving straight. If E.G. '5' is entered, it means that the customer would rather drive 5 meters than to take a turn of 90 degrees. So if you want a path with as few turns as possible, you would want to enter a very high number here (E.G. 1000 000 000 as mentioned before). This can be used to find simpler routes, at the expense of being longer, in order to accommodate people with poor driving skills.

Customers will automatically be assigned to robots in the simulation, which will guide them to the best available spot according to their preferences. These preferences would of course not be presented using numeric inputs like this in practice. It would instead provide a couple of buttons with preset values. This simulation provides them as numeric inputs such that people can experiment with precise values andd really see what impact they have on the result. Some of these results are discussed in a section that will follow.
When a customer reaches their parking spot they will leave the car and head to the pedestrian exit. After a random amount of time between 20 seconds and 5 minutes have elapsed, the customer will return to their car and leave the parking lot. Once they fully left the lot, their parking space will become available to the system again. When the API plans a route, it considers the worst case scenario. This means that it will be able to drive cars across unclaimed parking spaces in order to reach their parking space right now, but cars can not cross any parking spaces on their way out. It may be that a driver can take a significantly shorter path on their way out by driving over an empty parking space, but we can't ensure this parking space will be available when the customer leaves. Therefor the spot finding algorithm simply ignores this possibility and may therefor choose an option that turns out to be worse in hindsight. The simulation is based on these routes that the API calculates. This results in cars and pedestrians sometimes taking longer illogical paths on their exit route, simply to not cross any parking spaces (even though they may be traversable).

Override controls

When a client disconnects from the simulation, it will also destroy their robot and all the customers that it added. If any of the customers still occupied a parking spot, this could result in parking spots still being occupied according to the API, and never becoming available again on their own. In order to manually fix this, a 'Release all spaces' button is available. This will simply tell the API that all parking spaces are available again, even if it's still occupied in reality.

In addition, we can control parking space state for each node individually. We can select a parking space by clicking on it, which results in an extra dropdown appearing in the controls area. Here we can select whether the parking space is available, claimed or taken. This allows us to manually create specific scenerios and see how the spot search algorithm handles it.

Results

Note that that in all images below, the darker magenta parking spaces indicate that the space is claimed or taken. In addition, not all visible edges are edges that all entity types may traverse. Edges allowed to be traversed by cars can be seen below:

Car paths of the parking lot

When the turn cost is put to a high value, there can be seen that the search algorithm chooses a very simple path, which only requires the customer to make two 90 degree turns. The customer will however have to walk slightly further to get to the pedestrian exit. It seems like the API could have chosen an alternative driving route to the same space that requires the least amount of walking, while also requiring only two turns. This is however only true in case that the parking space in front of the car is still available when the customer returns, which may not be the case. As discussed in the customer controls section, the API will simply ignore the possibility of these spaces being available at all.

• 

  Car route when there are no turn costs
• 

  Pedestrian route when there are no turn costs

• 

  Car route when there is a turn cost
• 

  Pedestrian route when there is a turn cost

When we decrease the walking cost to 0, we see similar result to a high turn cost in an empty lot, since this simpler path also requires less driving.

Car route when there are no walking costs

We can however see a difference between a high turn cost and low walking cost in more complicated situations, like the one below.

Car route when there is a normal walking cost and no turn cost

Car route when there is a normal walking cost and a high turn cost

Car route when there is a high walking cost, and no turn cost

Known issues

Known breaking bugs

Robot collision When multiple robots run into one and another heads on, neither of them will proceed. This results in the whole simulation halting, until one of the robot's client disconnects to remove the robot. This is the result of the simple code used to make the robots properly wait in the queue. Proper collision avoidance was too difficult for this project, see limitations.

Car collision When a car gets to close to a robot it will stop moving. If another robot than the one guiding the car gets in front of the car, the car won't be able to proceed. Once again the client will have to disconnect in order to resolve the issue.

Minor bugs

Space claim When a client disconnects while still occupying parking spaces, those parking spaces will never become available again on their own. Someone will manually have to indicate them to be available again in order to be usable by the API.

Node tag indication Only a single tag of a node is visualized by giving it the corresponding color. This means that if a node is both the parking lot entrance and exit, it will appear to be only the entrance or the exit. This doesn't affect functionality, only visuals.

Limitations and future work

Collision detection

In order to focus on the parking spot assignment and the user preferences aspects, no time was invested in the guiding robot software. This software would handle the collision detection, and other important difficult aspects of guiding the customer. Since the simulation is only meant to visualize the tasks that the API handles, collision detection has been left out. Properly handling all the dynamics that arise in real world scenarios when guiding customers was too difficult to be added to the simulation with the limited available resources. This results in people visually being run over by cars in many situations. This obviously isn't the desired real world behavior of the system.

Dynamic planning The system is currently rather static. The API doesn't consider routes that other robots are taking to guide users, nor locations where people are walking, etc. The efficiency in real world scenarios could probably be increased by using this information while planning a route. It could for instance be beneficial to guide people to different aisles in order prevent them from slowing each other down while parking. This is something that could be researched in order to augment the current spot assignment algorithm.

Extra user preferences More user preferences could be considered while looking for parking spaces. A couple of possible preferences that have been suggested are listed below.

• Option to park closer to an elevator (compared to staircase exit, in case they are some distance apart)
• Option to specify preference for perpendicular parking, angle parking or parallel parking (in case a parking lot has different space types)
• Option to specify what direction they have to head in (in case there are pedestrian entrances and exits at multiple sides of the building)

Production readiness The software is currently generally not in a state to be deployed. There is no proper way specifying the graph of the parking lot, the API provides no security, and the way of installing the software is not as easy as it could be. It is currently in more of a research/test state than anything else, so if someone would want to deploy it with its current feature set it would still need to be finalized.

Implementation details

Installation

The source code for the software can be found at https://github.com/TarVK/parkingBot. This code can be cloned using git.

In order to run this code, NodeJS has to be installed.
Then using node, the dependencies of the project can be installed by calling npm install in the terminal within the root of the project.

Production

Currently there is no way to specify the parking lot graph without altering code, so there is no fully proper way of deploying the software.

The parking lot graph would have to be added or replaced here and the correct graph would need to be imported here.

The code can be built by running npm run build in the terminal within the root of the project. After which npm start can be ran to start the application.

Development

The source code is split into two sections, the API (server) and the simulation (client). These can be ran independently (althrough the simulation requires the API to be running somewhere), or together in one process. We can run them in development mode, which will make sure to automatically compile the code and restart the software whenever a change is made. The following commands can be ran from the terminal to achieve this:

• npm run dev-server (To only run the development mode of the server)
• npm run dev-client (To only run the development mode of the client)
• npm run dev (To run both the development mode of the server and client in one process)

Used technologies

The main software that was written is the API. This API is able to run on a local server at a parking lot, and all robots are able to communicate with it over an internet connection. It's written in TypeScript and runs in NodeJS. It uses Socket.io in order to facilitate symmetric communication. In addition, a front-end web application is provided through the server, in order to show a simple simulation of the parking lot. This was added to show the capabilities of the system without having to create the physical robots. This application is also written in TypeScript and uses the following important libraries:

• React for view creation
• Model-React for data management
• PixiJS for dynamic graphics
• React-Pixi-Fiber to use PixiJS with React
• Fluent UI for UI components

Algorithms

Search algorithm Dijkstra's algorithm together with a min-heap is used to perform the search. This algorithm can find the cheapest path between two nodes in a graph, in an efficient manner. It computes the cheapest path from a start node to any node in the graph. This by itself is not sufficient for our search however, since we aren't just interested in the distance between two points. We want to consider a number of variables, including:

• Total driving distance from entrance to exit
• Total walking distance from parking spot to an pedestrian exit
• Total walking distance from a pedestrian entrance to the parking spot (in case there are seperate entrances and exits)
• Difficulty to get to a parking spot (based on E.G. number of turns required)

In order to consider all these aspects, graph transformations are used to obtain graphs that Dijkstra's algorithm can be used on.

Graph transformations Given the graph of the parking lot, the software will create so called 'search graphs'. These are graphs where the physical location of nodes is abstracted away. These do not represent the parking lot in a physical manor anymore, but all relevant information to determine the ideal spot is retained. This relevant information is encoded in the form of edge weights, which can be used to determine costs from one node to another. This way the cost to get from the entrance to a parking spot can still be determined, without having to consider physical location. Each node also contains a reference to the node it was created from, in order to translate path found in the search graph back to a physical route. The system creates 3 different search graphs, which are all used in the final search that combines the information:

• Pedestrian entrance to spot graph
• Pedestrian exit to spot graph
• Vehicle entrance through spot to exit graph

These graphs are only created once when the system starts up, therefor efficiency of creating these isn't a major concern.

Pedestrian entrance to spot graph This graph is a simple graph that uses Euclidean distance as weights on all edges, and only retains nodes and edges that may be traversed by pedestrians. This graph therefor allows the distance between a given entrance and any parking spot to be determined

Pedestrian exit to spot graph Similar to the other pedestrian graph, this graph uses Euclidean distance as weights on all edges, and only retains nodes and edges that may be traversed by pedestrians. In addition, it reverses all edges, such that if you were only allowed to walk towards the exit over a path, you are now only allowed to walk away from the exit over said path. This graph therefor allows the distance between a given exit and any parking spot to be determined

Vehicle entrance through spot to exit graph This graph only retains edges traversable by vehicles. It first creates two instances of the graph, where the first doesn't contain any vehicle exits, and the second doesn't contain any vehicle entrances. Then it connects the two graph through the parking spots. An example illustration is provided below.

• 

  A simple parking graph before applying the routing transformation
• 

  A simple parking graph after applying the routing transformation

This way we can search for the cheapest path from a vehicle entrance to a vehicle exit, which has to pass through at least one parking spot. In this graph, all edge weights are simply the euclidian distance between the nodes.

A second transformation is applied to this graph, which introduces costs for each turn taken. In most graph algorithms like Dijkstra's algorithm, the position of nodes is meaningless. When having to consider the costs of taking a turn, it is meaningful information however. So a transformation is performed that translates this meaningful position data into edge data. After the transformation has been applied, the node position is no longer meaningful. The transformation replaces every node in the original graph by the product of the set of incoming and exiting edges. This way we add an edge between any pair of incoming and exiting edges, and give it a weight relative to the turn that's required to make this transition. An example illustration is provided below.

• 

  A simple graph before applying the turn costs transformation
• 

  A simple graph after applying the turn costs transformation

Using this graph we can find the spot that requires the minimal distance to be driven, and fewest turns to be taken.

Graph search In the search algorithm, the information of all 3 graphs is combined. First a search is executed on both pedestrian graphs in order to determine the cost to reach any spot by foot. In this search a 'walk cost' is used to multiply the distances with in order to consider user preferences.

Then a search is done in the vehicle graph. In this search any turn edge is multiplied with a 'turn cost' to once again consider user preferences. When the search algorithm encounters an edge through a parking spot, the walking cost calculated in the previous spot is provided. In addition an infinite cost is provided in case the parking spot is already taken. The result of this search will is the cheapest path from the entrance to the exit of the parking lot, passing through a parking spot. The parking spot is extracted from this path in order to retrieve the pedestrian paths to and from this spot as well, and all paths are returned as the search result.

The costly graph transformations are only executed once, and per search we only have to use Dijkstra's simple and efficient search algorithm a couple of times.

Hardware

The second thing that will be delivered is a design with specifications of the parking robot. This design is developed in this chapter.

State-of-the-art

If the information of the available parking places is measured, it is important that the system can choose the best possible parking spot for the vehicle. There are different performance measures for the best parking spot, but the most used ones are a combination of that the time riding to the parking spot and the time walking from the parking spot to the destination are minimal.

When the optimal parking spot is chosen, this can be passed to the user in different ways. The first one is to show the route to the parking spot on the dashboard of the vehicle. A lot of cars nowadays have GPS on the dashboard and this can be used to show the information of the parking spots. This results in that there needs to be a continuous information flow between the vehicle and the availability of the parking space.

This can however also be done with predicted information of the availability of the parking spaces. This information can be given to the GPS of the vehicle, such that the route to the predicted available spot is displayed on the dashboard.

A lot of the times, employers are deployed to guide the vehicles to the empty parking spots. This can be seen on parking lots for places like festival, amusement parks and museums. This can be replaced by robotic solutions. Signs can be set on the ground with information on where the vehicle needs to go for the empty parking spot. For example a sign with an arrow or an cross can be used to show in a simple way for the user, which way he needs to follow.

The employers can also be replaced by robotic vehicles that lead the vehicle to the best parking spot. These robots can fully ride the way of the beginning of the parking lot to the parking spot, or can be used as robotic employers, by going to the crossings and then showing the right way to the user in the vehicle.

Concepts

Obstacle avoidance and parking availability

In order for the system to avoid parked cars and guide drivers safely to their designated parking spot, the system should be able to observe its environment and determine its position. To be able to this, two types of sensors can be used, namely: dead reckoning sensors and environmental sensors. Dead reckoning sensor operate by integrating sensor data over time to determine the vehicles position. Environmental sensors are used to gather information about the vehicles surroundings.

The first sensor option is to use cameras which can observe in 360° short or long range. These cameras can be placed either on top of the vehicle, on the sides of the vehicles or externally placed (see figure below). The key application for this cameras is to recognize objects. Some tasks such as traffic light identification is only possible with the use of cameras. However, because of the great amount of pixels, camera data processing can be intensive. On top of that, camera quality is susceptible to environmental conditions such as rain, fog or snow.

Radar can also be used either at short or long range. Different objects reflect the radio waves differently. The advantage of using radar is that positional and velocity data can be acquired simultaneously. On top of that, radars are impervious to weather conditions. Despite, radar acquired data yields low resolution and a 2D image.

Lidar uses light to receive information about distances between objects. Lidar is used for short range applications. It is used to obtain position and geometry of an object. If multiple Emitter and receiver sets are placed on the vehicle, Lidar can be used to create a 3D image of the environment. Next to that, because dark and light objects reflect light at a different intensity, Lidar can be used to detect road markings. A disadvantage is that Lidar data can be affected by the weather.

Ultrasonic sensors are short range and unaffected by weather conditions. Currently, ultrasonic sensors are used for parking assist.

GPS can be used to determine the vehicle position globally. GPS, however, is not enough to determine the position with great accuracy, as GPS can only obtain an objects position with 1-2 m accuracy.

In general, all of the sensors considered above have pros and cons. Hence, these sensors are often used in combination in self-driving vehicles.

The partial solutions to obstacle avoidance and parking availability.

Vehicle motion

Another crucial aspect of the parking assistant robot is motion. The robot should both be able to operate on asphalt and rough terrain. Therefore, a solution must be found to allow smooth operation in both environments.

The first option is to use large wheels with a thick profile. If the wheels are independently propelled and sprung, the vehicle will even be able to have grip in a muddy and bumpy environment. Another option is to use tracks. Tracks are used in the most inaccessible terrains. However, tracks are not as suitable for use on asphalt. Another option is to use legs. The advantage of legs as that they can move the vehicle in nearly all environments. Nonetheless, legs often require complex mechanical actuating systems (see figure below).

Additionally, steering must be considered. This can either be done by rotating left and right wheels or tracks at different speeds or by turning the front or back wheels.

The partial solutions to vehicle motion.

Integrated solutions

Requirement: able to turn on its place Preference: as small footprint as possible

Solution 1

A two wheel based self-stabilizing robot – like a segway

• Display on eye level
• Sensors on top
• Weight distribution on top en bottom in order to maintain balance

Pros

• Small wheelbase, able to navigate to relative small places
• Agile
• Ability to keep itself upright after perturbation

Cons

• Possibly less stable
• Possibly dangerous movements when trying to keep itself upright

A two wheel based self-stabilizing robot.

Solution 2

A four wheel based robot – two powered wheels, two caster wheels

• Display on eye level
• Sensors on top
• Weight distribution on bottom in order to lower center of mass

Pros

• Stable from itself

Cons

• Less ability to react to perturbations to keep itself upright
• Because of the dimensions of the robot (way taller then wide) not that stable
• Bigger footprint then two wheel based

A four wheel based robot – two powered wheels, two caster wheels.

Solution 3

A two wheel based robot, with added extra control wheel. The arm of this of this extra control wheel is sprung and shock absorbing, the wheel can be a fixed one or a castor wheel and is in normal use not touching the ground.

Pros

• Same as solution 1

Cons

• More stable then solution 1
• Because of the added control wheel smaller correction suffice to keep upright, so it is less dangerous

A two wheel based robot, with added extra control wheel.

Solution 4

With the previous two wheel based solutions, stability is a key issue. Also, with a narrow base four wheel base robot, tipping over is a risk. Therefore, this concept has four wheels with a larger width and length to reduce this risk. The advantage of the two wheel concepts is the maneuverability. In order to have the same maneuverability, four omnidirectional wheels are used to allow the robot to rotate at its position.

A four wheel based robot, with omnidirectional wheels.

Detailing

The final design has several important features to fulfill the requirements, preferences and constraints. The first requirement applicable to hardware is the detection of correct parking. To allow the robot to do this, the robot has been fitted with a Lidar. This sensor can both create a 3D-image of the environment and detect road markings. If a car is double parked, the system will indicate this and try to guide the user to re-park their car. If the user refuses to do so, the parking robot can indicate that a double charge will be applied. On top of that, Lidar can be used to detect the size of an arriving car. This is important so that the system can select a large enough parking space for the user's vehicle. Secondly, the system should not come closer than 0.7 m from the secondary user when guiding. A large screen (55") ensures that readable instructions can be given to the secondary user at this distance. With regard to the input of parking preferences, the screen is also a touchscreen which is mounted on a pivot point (see the figure below). The system can drive next to the driver window so that the secondary user can reach the screen. Among the several preferences available to choose from on the touchscreen are a help function, feedback function and emergency function. Finally with regard to requirements, the body of the car ensures that the components inside remain dry.

Also a variety of preferences are taken into account. Concerning the parking payment method, two options are possible. The first option is that secondary users can pay contact less with a debit card at the exit. The parking charge is automatically coupled to the license plate. The second option is that for regular users a payment plan is coupled to a license plate so they can immediately leave the parking garage. With regard to appearance, the robot does not look like a human. The main reason for this is that the robot has four wheels which are at a relatively large distance from each other to increase stability. Therefore, it is not possible to create a human figure. Nonetheless, considering license plate recognition, the robot has a camera to be able to perform this task. The license plates are coupled to the specific parking spot and stored in a database. By doing this, the system knows where specific cars are parked and which parking spots are taken. Now, a tablet at the person entrance of the parking garage allows users to search their license plate to see where their car is parked.

Approximations

In order to find appropriate components for the robot, estimations have to be made. Therefore, in this section some global parameters are established.

In the figure at solution 4, the current concept is depicted. This figure gives a course overview of all the components that need to be present in the final design. The final design needs to have the following components; a screen or light display for interaction with the secondary user, wheels, suspension, actuators, sensors, a computer, a battery pack and additional lighting.

With regard to mass, the led screen of the robot has an approximate mass of 20 kg. Next to that, the four omnidirectional Mecanum wheels of 254 mm diameter have a combined mass of 12 kg . Concerning the sensors, these consist of Lidars, camera's and radar. The weight of these sensors combined is expected to be 1 kg. In order to compute the algorithm, hardware is needed. This hardware is guessed to be 10 kg.

All components have to be put together in a structure. This structure needs to be rigid and needs to resist minor crash loads. The structure combined with the spring dampers is expected to weigh 20 kg.

The wheels have to be individually propelled with actuators. These actuators need to accelerate and decelerate (using dc injection braking). The robot will travel at an average velocity of 15 km/h in the parking lot. If the robot has a maximum speed of 30 km/h and accelerates at a maximum acceleration of 2 m/s^2, for a robot weighing 100 kg, a force of 200 N is needed. Given a wheel diameter of 254 mm, the required torque is equal to 25 Nm and the total power 1700 W. To prevent needing a gearbox, the maximum rpm of the actuator should be equal to:

Hence, [math]\displaystyle{ \omega }[/math] is equal to 4000 rpm. The required power can be distributed over four actuators. Therefore, each actuator needs a power of 425 W, a torque of 6.25 Nm and a maximum of 4000 rpm. The Transmotec D123182-12 fits the power requirements running at a slightly lower rpm. This actuator weighs approximately 7.5 kg. In total the actuators have a weight of 30 kg.

Finally, the actuators, screen and computer components have to be supplied with power. The actuators need to provide a mechanical power of 1700 W. The efficiency of an electric motor is dependent of the work load of the motor. If the efficiency is assumed 70%, the required electric power is equal to 2500 W. On top of that, the screen has an electric power of 130 W. Finally, the processing power of the computer is approximated at 1000 W. The sensors also require power combined with the additional lighting, this amounts to a total electric power of 4 kW. Assuming that the batteries can charge at the end of the day, the robot needs to be functional for eight hours. Therefore, the batteries need to store 32 kWh, if losses are neglected. The capacity of a lithium-ion battery is 265 Wh/kg . This means the battery pack would weigh 120 kg. This is not feasible, therefore, it is assumed that the robot can charge during the day. If the robot has an operating duration of two hours, the battery needs a capacity of 8000 kWh. This would result in a mass of 30 kg.

In total, the robot would weigh approximately 120 kg. Next to mass, volume is an important factor. The battery has an energy density of 693 Wh/L. Therefore, the battery pack has a volume of 12 L. The actuators have a combined volume of 9 L.

Appearance

If the previous approximations are taken into account, the parking assistant robot could take the following appearance:

A possible appearance for the parking assistant robotic system.

The interior of the parking assistant robotic system.

In the figure above, the interior of the robot can be observed. Each of the wheels is driven with a motor. Although the road in a parking garage is often smooth, the robot should also be able to cross speed bumps. For this reason, the motor and wheels are attached to the chassis with a double wishbone suspension. The spring-damper combination needs to be critically damped for the best performance. Hence, the spring stiffness and damping coefficient have to be determined. This can be done with the use of the following formulas:

With ω_n the natural frequency in rad/s, k the spring stiffness in N/m and m the mass in kg.

With ζ the damping ratio and c the damping coefficient in N s/m

With ω_d the damped frequency in rad/s .

The unsprung mass is equal to 50 kg. Hence, the sprung mass is equal to 70 kg.

Cost and profit

An important consideration is the cost of the system. If the robotic parking assistant system is more expensive than current solutions, primary users will not invest. Available solutions such as an indicator light can cost up to €200 to €500 per parking spot. These lights indicate with a red or green light if the parking spot is free. In order to do this, they make use of an ultrasonic sensor to detect a car. For a parking garage with a 1000 spots, this solution would cost €500.000. Therefore, the parking assistant robot system must be cheaper than this. In short, there are several costs which need to be taken into account. These costs are material/part cost, manufacturing cost, depreciation cost and maintenance cost. Concerning part costs, a single robot has €10.000 worth of parts. However, this becomes less as production scale increases. This also applies to manufacturing cost. If only a few robots are made, manufacturing cost will be considerable. If it is assumed that all parts are pre-made and can be assembled by several workers within a week, the manufacturing cost could be €5000. Together with profit to ensure financial growth of the manufacturer, a primary user would pay €20.000 per robot. Additionally, a charging station is needed which costs €2000 per robot with €2000 installation cost for the entire charging station.

In order to make the system profitable for parking garage owners, capacity needs to be considered. Parking garages often need to deal with rush hours. An important business model of this robotic solution is user experience. If 200 drivers arrive within 1 hour, but have to wait to be serviced, the experience is ruined. On the other hand, if the amount of robots is determined to be sufficient to cope with this peak efficiently, many robots will be stationary throughout the rest of the day. Therefore, the system mainly focuses on premium users. Secondary users can reserve parking spots prior to arrival. Once they arrive during rush hour, they are serviced first. Additionally, secondary users can be charged for other special treatments such as electric car parking spots, family parking spots, fast entrance and exit spots. If during rush hour 100 premium drivers arrive in hour, the robotic system needs to deal with 2 cars a minute. If the average interaction time of a robot is equal to 10 minutes, 20 robots are needed in the parking garage during rush hour. Therefore, the total system would cost €442.000. This is less than the previously specified cost of €500.000. Therefore, the parking assistant robot system offers a more advantageous solution and thus is profitable for the primary user.

Conclusion

In the beginning was decided to work on three different aspects of the parking assistance robot. Firstly, the users for the parking assistance robot were determined. The primary users are the companies that are dealing with large parking lots. They can benefit from the service of the robot by charging the customers for a more special treatment. This can be done with subscriptions for different parking spots in the parking lot or charging for customers to give their preferences. There is also thought about the cost of the robot and how this compares to the cost of sensors on every parking lot. The secondary users are the customers who park their car in the parking lot and the parking assistance robot can help them in finding the best parking spot depending on their preferences. For this to work, it is needed that the user-robot interaction is good. The robot must be clear and fast such that the user sees the benefits of the parking assistance robot over normal parking. Therefore, a survey was done under 175 people to get information about the wants and needs of the secondary users. This information is translated back in the ways that the robot interacts with the secondary users.

The second deliverable is the software which can be used in the parking robot to determine the best free parking space in the parking lot dependent on the preferences of the users. The delivered software can manage the parking lot. The software keeps track of the state of the parking lot and determines the best parking spots depending on the different preferences. The parking lot itself is simplified to the form of a graph and the software shows how the robot will drive through this simplified parking lot to the best parking spot for the secondary user.

The last deliverable is a design with specifications of the parking assistance robot. This design incorporates the sensors which are necessary for the robot to scan the parking lot and know its location. There is also thought about the way of driving of the robot. The interior is chosen in such a way that the robot can drive with 15 km/h and turn on his place such that it can come close to cars. The design of the robot is chosen to make it fit in a parking space and easy to use by the users. The design is made in such a way that the battery life is long and the touchscreen is big and easy to use by the users.

In conclusion, the hardware and software for the parking assistance robot is designed and the interaction with all the users is worked out to show how this robot can improve the current situation in parking lots.

Discussion

Overall should the different factors that are developed in the course be linked together. Now, we do have a software on a webpage and a design of the hardware, but if this project was picked up later the hardware should be realized in real-life. The software must then be incorporated into the design.

There is a lot of thought put into the user interaction with the parking assistance robot. There is now chosen for a survey to ask the opinions of the secondary users, but it would be better if the interaction of the user with the robot could be tested with a prototype of the robot. In this way can really be tested if the robot fulfils the requirements listed in the beginning.

The software should be improved more in the future. Now the software simplifies the parking lot in a graph, but in real life are parking lots much more difficult to map, because of gaps or different floors. Also, the robots in this software do not communicate with each other. If two robots guide a vehicle to a parking space and meet each other halfway, they will stop with driving. In the future, the software could be improved such that the robots communicate with each other continuously and change their route such that they will not get stuck with each other, implemeting obstacle avoidance. Safety is a big requirement which is set in the beginning, there was stated that the robot should not come closer than 0.7 meters to the secondary users. This can result in different problems in real-life if this 0.7 meters cannot be met and at this moment the software does not include the many pedestrians, which usually walk through the parking lot. The software should thus be improved in the future with how the robot must react to pedestrians and other things in the parking lot. Furthermore, there is not thought about the peak hours in a parking lot. For example in a parking lot for a big company are there some hours that there are a lot of people coming in and some hours that it will be very quiet in the parking lot. The software should also be changed in such a way that it can test how many robots there are necessary for a parking lot. In this way, there can be tested what the right amount of robots is for some parking lot, such that the service can still be given in a good way in the peak hours.

The design and specifications of the hardware are made in such a way that it will fulfill the RPC’s that were decided upon in the beginning. However, there are still some things that are not thought about and could change the design. The first thing is the charging of the robot. A lot of the time, there is not enough electricity in a parking lot for a lot of electronic parking spaces, so there needs to be thought about if there is enough electricity for the parking assistance robot to be recharged. It is also important to think about the place in the parking lot where the recharging can happen. There is usually not a lot of spare room in parking lots, so maybe the design should be changed such that it can be stored and recharged more easily. In conclusion, the design incorporates a lot of the requirements to make a good parking assistance robot. When this project would be picked up in the future, it is necessary to test the design more such that it can work in a real-life parking lot.

In the end, all the parts of the project should be worked out more for it to be able to be used in real-life. In the beginning, there was chosen to work on all the different aspects of the robot, such that the full picture could be shown in the end. This resulted in that there is made a good part of every aspect, but the detailing before it can be used in real-life could not be entirely done. However, the approach would not be changed in the future, because a good idea of the robotic solution is delivered and it is shown that it is a good solution for the parking problem.

Recommendations

The parking robot could have some additional features to enhance its performance and employability that both benefits the primary and secondary users. These recommendations have been determined following the meeting with Ronald Freijns, Peter Steijns and Jordy van Senden. Ronald Freijns and Peter Steijns are currently working at Qpark. Jordy van Senden is a PhD student who is working on robotic systems, he also has his own company with Qpark as his main client.

Jordy van Senden mentioned that criminal activities are a great problem for parking lots. The parking robot could help with this. When the parking robot is driving randomly through the parking lot it could also keep track of suspicious behaviour and when necessary contact the police. Furthermore, Jordy van Senden is working on a litter detection robot to clean parking lots. The parking robot could be extended with this feature such that it can clean parking lots while guiding people to a parking spot and keeping track of criminal activities.

Ronald Frijns and Peter Steijns mentioned that people often call their information number to gain information about, for example, the location of the exit of the parking lot. In addition to our robotic system, a display could be added at the entrance and/or exit of the parking lot for frequently asked questions. Such that the parking lot has to employ fewer people for answering these questions and thus reducing their overall costs. The same display could also be used to help the users find back their parking spot. By, for example, entering their license plate number after which the display shows the shortest walking route to their parking spot.

The way the robot guides users to their parking spot could also be adapted. Instead of interacting with one parking robot from the entrance until the arrival at the parking spot, the drivers could, for example, communicate their preferences with a parking robot at the entrance after which this parking robot refers them to another parking robot to guide them to their parking spot. It is also possible that the before mentioned display is used at the entrance of the parking lot to communicate preferences. After which a parking robot comes to pick them up to take them to their parking spot. These changes can have the advantage that there is a shorter waiting time at the entrance of the parking lot. Making the whole process from entering till parking more efficient.

The parking robot is now only able to work on smooth and flat surfaces, this could be adapted such that it is also able to work on hills and rough terrains. Such that it, for example, can be used on (temporary) grass parking spaces too. When the robot could ride on those surfaces, it is possible to use the robot for different events which use a big grass field for a parking spot. In this way can maybe a rent system be used for the robots in case of temporary events.

People with a disabled parking card are allowed to make use of the disabled parking spots. With the current design, people can communicate their preference for a disabled parking spot after which the parking robot guides them there. The parking robot is not able yet to check if these people are actually allowed to. The design could be extended with a disabled parking card scanner to check if they are allowed to park there before guiding them to their spot. Such that there will be less misusage of the disabled parking spots.

Planning

	Activities	Person(s)
Week 1	Introduction lecture Brainstorm on possible subjects Choosing subject Literature study	All All All All
Week 2	Tutor meeting 1 Problem definition State of the Art research User analysis Possible solutions Planning Updating wiki page	All Sietse Luc Mandy Tar Rien All
Week 3	Tutor meeting 2 Improvement RPC's Research user interaction possibilities Concepting on hardware solutions Start on parking tracking software Updating wiki page	All Mandy + Luc Rien Sietse Tar All
Week 4	Tutor meeting 3 Reforming wiki page to make it more cohesive Research in hardware concepts necessities Continuing parking tracking software User interaction analysis and making survey Updating wiki page	All Luc Sietse Tar Mandy + Rien All
Week 5	Tutor meeting 4 First design hardware solution Distributing survey for user interaction methods Writing part about user interaction Translate user feedback in improvement points for design Continuing on software Updating wiki page	All Sietse Mandy, Rien All Luc, Mandy Tar All
Week 6	Tutor Meeting 5 Finishing hardware solution design, with user feedback Finishing software Finishing user, society and enterprise part in wiki Brainstorm and first start on the visuals Updating wiki page	All Sietse Tar Luc, Mandy Sietse All
Week 7	Tutor meeting 6 Start on presentation Finishing wiki page Writing conclusion Writing discussion Working on the visuals	All Rien Luc, Mandy Luc, Mandy Luc, Mandy Tar, Sietse
Week 8	Tutor meeting 7 Finishing presentation Final presentation Finishing visuals Finalizing project	All Tar, Sietse, Rien Luc, Rien Tar, Rien Luc, Mandy

Log

Week 1

Name	Hours	Summary
Luc	15	Introduction lecture, two meetings, brainstorm on possible subjects, literature study, written: State-of-art
Mandy	15	Introduction lecture, two meetings, brainstorm on possible subjects, literature study, written: User, Society, and Enterprise
Rien	15	Introduction lecture, two meetings, brainstorm on possible subjects, literature study
Sietse	17	Introduction lecture, two meetings, brainstorm on possible subjects, literature study, problem statement, RPCs
Tar	10	Introduction lecture, two meetings, brainstorm on possible subjects, literature study

Week 2

Name	Hours	Summary
Luc	10	Two meetings, RPC's
Mandy	10	Meeting with tutor, meeting with group afterwards, improved: user, society, enterprise, researched valet parking costs
Rien	10	Two meetings, RPC's
Sietse	9	Concepting: researching and drawing partial solutions, and drawing entire solutions.
Tar	6	Two meetings, Concept descriptions

Week 3

Name	Hours	Summary
Luc	5	Meeting Tutor + Meeting Group afterwards, Meeting RPC's with Mandy: improved RPC's
Mandy	5	Meeting Tutor + Meeting Group afterwards, Meeting RPC's with Luc: improved RPC's
Rien	5	Meeting Tutor + Meeting Group afterwards, concepting hardware solutions
Sietse	5	Meeting Tutor + Meeting Group afterwards, devising and drawing a new four wheel omnidirectional concept
Tar	18	Meeting Tutor + Meeting Group afterwards, wrote something about objectives and other small sections, started parking tracking software

Week 4

Name	Hours	Summary
Luc	10	Meeting Tutor + 2x Meeting group, changing wiki and making it more coherent, working on the survey for the user-robot interaction
Mandy	11	Meeting tutor + 2x Meeting Group, Meeting with Rien about the communication of the robot and the survey, meeting with Luc and Rien to finish the survey
Rien	15	Meeting tutor + 2x Meeting Group, About HRI and the survey, concepting and designing possible interaction methods for the survey,
Sietse	20	Meeting Tutor + 2 x Meeting group, researching and approximating important robot parameters (required motors, wheel, battery pack, etc.), creating 3D geometry of body, Rendering geometry.
Tar	18	Meeting Tutor + 2 x Meeting group, improved parking search algorithm, wrote some text about software, started parking lot editor

Week 5

Name	Hours	Summary
Luc	8	Meeting with tutor, finished the survey and spread the survey, worked on the wiki page, meeting to process the data obtained by the survey
Mandy	8	Meeting with tutor, finished the survey and spread the survey, meeting to process the data obtained by the survey
Rien	7	Meeting with tutor, finished the survey and spread the survey, meeting to process the data obtained by the survey, contact with Jordy Senden
Sietse	8	Meeting with tutor, creating 3D parking space environment for presentation video, writing the primary user chapter
Tar	13	Meeting with tutor, finished parking lot editor, created a simple parking lot, improved search algorithm and added spot management

Week 6

Name	Hours	Summary
Luc	10	Meeting with tutor, Meeting with Jordy Senden about our project, Meeting with group, 2 Meetings to work on the data of the survey
Mandy	10	Meeting with tutor, Meeting with Jordy Senden about our project, Meeting with group, 2 Meetings to work on the data of the survey
Rien	10	Meeting with tutor, Meeting with Jordy Senden about our project, Meeting with group, 2 Meetings to work on the data of the survey
Sietse	10	Meeting with tutor, Meeting with Jordy Senden about our project, Meeting with group, creating video and adding touchscreen in CAD
Tar	14	Meeting with tutor, Meeting with Jordy Senden about our project, Meeting with group, Started adding entities to the parking system in order to make a simulation

Week 7

Name	Hours	Summary
Luc	10	Meeting with tutor, preparing presentation
Mandy	10	Meeting with tutor, preparing presentation, starting interface of the robot
Rien	15	Meeting with tutor, preparing presentation
Sietse	20	Meeting with tutor, creating a 3D environment in CAD for final presentation, creating an animation of the presentation
Tar	X	Meeting with tutor, finished software simulation and documentation

Week 8

Name	Hours	Summary
Luc	18	Recording presentation, writing discussion + conclusion, finishing wiki
Mandy	14	Finished interface of the robot, writing recommendations, finishing wiki page
Rien	25	Conducting interviews, helping Tar with 3D demo, editting final presentation video
Sietse	23	Finalizing animations for the presentation, creating animations for the user interface
Tar	30	Worked on 3d demo for in the video

Peer review

References