PRE2019 3 Group12: Difference between revisions
TUe\20174056 (talk | contribs) (→Week 8) |
|||
(360 intermediate revisions by 6 users not shown) | |||
Line 19: | Line 19: | ||
|<center>Horea Breazu</center>||<center>1229343</center>||<center>Computer Science </center>||<center>h.breazu@student.tue.nl </center> | |<center>Horea Breazu</center>||<center>1229343</center>||<center>Computer Science </center>||<center>h.breazu@student.tue.nl </center> | ||
|} | |} | ||
=Deliverables= | |||
* Presentation: https://docs.google.com/presentation/d/1iAvQ0Z0fLYO_gdYZlJpNcMgUN7GqepjbUoVi02OU4tI/edit?usp=sharing | |||
* Video presentation: https://www.youtube.com/watch?v=wjVsYjUPT3s Sorry for the watermark, this was an oversight on our part and we were unable to remove it and we were not able to re-record the video | |||
* Demonstration: https://youtu.be/lkvP9rBYgNc | |||
=Subject= | =Subject= | ||
Line 24: | Line 28: | ||
==Problem Statement== | ==Problem Statement== | ||
During examination weeks many student want to work and study at the workplaces in the MetaForum. However, during the day it often very busy and it might take a while to find a place to sit, costing effort and precious study time. If | During examination weeks many student want to work and study at the workplaces in the MetaForum. However, during the day it often very busy and it might take a while to find a place to sit, costing effort and precious study time. If students knew the locations of vacant seats it would significantly reduce the amount of time it takes to find them and will probably also reduce the distance that needs to be walked, decreasing the noise for the people already studying. This same issue could arrive at various other places such as public libraries or flexible workspaces. An automatic method to determine the vacant workplaces would be ideal to deal with situations like this. | ||
==Objectives== | ==Objectives== | ||
Line 32: | Line 36: | ||
*Room reservation | *Room reservation | ||
It should be able to detect whether there are people in a room and if that's not the case for a certain amount of time, it should set the room to available for reservation. | It should be able to detect whether there are people in a room and if that's not the case for a certain amount of time, it should set the room to available for reservation. | ||
==Approach== | ==Approach== | ||
Line 100: | Line 90: | ||
*There probably will be a difference in the base temperature of the chair due to the difference in the weather over the year and even in a single day. A chair next to a window where the sun is shining on will probably have a higher temperature than a chair in the shadow. In the summer, unless the *temperature is really well regulated, the area in the view of the camera will have a general higher temperature than in the winter, which could make it harder to detect differences. So a lot of factors have to be incorporated into the design to even the effect | *There probably will be a difference in the base temperature of the chair due to the difference in the weather over the year and even in a single day. A chair next to a window where the sun is shining on will probably have a higher temperature than a chair in the shadow. In the summer, unless the *temperature is really well regulated, the area in the view of the camera will have a general higher temperature than in the winter, which could make it harder to detect differences. So a lot of factors have to be incorporated into the design to even the effect | ||
*Normal consumer thermographic cameras have a small viewing angle, and work precisely relatively close. If you want to detect objects further away the preciseness of the camera goes down so it means you must install more cameras on lower ceilings to have it accurate and it can become quite expensive. | *Normal consumer thermographic cameras have a small viewing angle, and work precisely relatively close. If you want to detect objects further away the preciseness of the camera goes down so it means you must install more cameras on lower ceilings to have it accurate and it can become quite expensive. | ||
==Users, Society and Enterprise== | |||
The primary users this project will be focused on are students of our own university. | |||
After the technology has been developed for our university it could be used in other places as well. Besides the similar possibilities like other universities or public libraries, there are also different settings that our technology could be applied to. If businesses can be convinced of the usefulness of our product the software could be sold to them. This would primarily target large businesses with flexible work spaces, since it is mainly in such environments that our product could provide a substantial increase in the efficiency of the use of work spaces. However, our product will only be attractive to businesses if it is already a polished product. Because of this a corporate application would only be of concern after the university has served as a training ground and the product has been thoroughly tested and refined. If eventually our technology were to become widely adopted by companies and public institutions alike, there might also be implications for society regarding privacy. Even if the recorded footage from the cameras isn’t saved or viewed by any humans, the widespread installation of cameras might still make people feel uneasy. This could contribute to the trend of rising societal concerns about privacy. For this reason, among other things, we have decided to inquire about the requirements and concerns of our users through a survey. | |||
==User Requirements Survey== | |||
In order to develop a sound engineering product it is important to not become out of touch with the actual requirements and needs that our targeted users have. Although we, as students, are for a large part also users ourselves, we can still get misdirected in our assumptions of what the user requirements and needs are by the anecdotal problems that we personally face. For this reason we have made a survey with the purpose of determining the stances on some aspects of our project. We have chosen to focus on multiple choice questions over open questions in our survey. The main reason for this is that open questions are a lot harder to properly analyze, since the answers can’t be easily quantified into different categories. However, open questions do have the advantage of removing some of the subjectivity of the creators of the survey from the answers. Although there will remain some subjectivity due to how the creators of the survey choose and formulated the questions, there is only subjectivity to how people will respond if the answers are pre-formulated as well. For this reason we have added a open question at the end that inquires about any miscellaneous thoughts or concerns that the students might have. This is important, since there might be aspects to our project that we have not yet considered and have therefore also not implemented into the multiple choice questions of the survey. The most prominent of these concerns, if there are any, should show up in questionnaire this way. There might also be correlations between answers to the different questions that could tell us more about our users | |||
In order to paint a clear picture of the application of our idea we have selected the library of Metaforum as an example setting for the survey, as it is the busiest and most popular of the open study spaces on the university. The following aspects are inquired about in the survey: | |||
*How often do you approximately study in Metaforum? This is asked in order to ensure the creditability of the other answers. | |||
*How often do you have trouble finding a place to study in Metaforum? This is asked to gauge how much need there is for a solution to our problem statement. | |||
*Would you appreciate and use an app that allows you to see a map of available open study spaces? This is asked to determine if our users agree that our idea is conceptually a suitable solution to the problem statement. | |||
*If you answered "No" to the question above, what is your main reason for doing so? (open question). By asking this open question we try to detect any unnoticed reasons that might obstruct the usage of our application among our users. | |||
*Would you have any concerns regarding privacy if the app made use of a network of cameras at these study places to determine where free places are available? This is asked to gauge of much our users are bothered by the privacy implications of the camera network that is necessary for our application. | |||
*How would you answer the last question if it would be ensured that the footage from the cameras is exclusively used by software for determining where free chairs are located and therefore cannot be viewed by anyone? This is asked to determine the effect of our largest privacy measure, which is keeping the camera measurements in a closed system. | |||
*When you are studying in Metaforum, what percentage of the time do you estimate you have your laptop before you? This is asked to check our assumption that laptops can generally be used to predict the status of a seat as being occupied. | |||
*Do you have any miscellaneous thoughts or concerns about our proposed solution? Finally, we ask another open question to ensure we haven’t missed any aspects of our application. | |||
The final survey can be found here: https://forms.gle/LnnYxHqzP3n6338g8 | |||
==Survey Analysis== | |||
After roughly three weeks we have gathered 19 responses. This is less than we originally anticipated. There seem to be two main reasons for this. Firstly, using the large group chats of students of each major to spread the survey turned out to be fairly ineffective. Although each group chat often contains well upward of a hundred people, very little people seemed to have followed through on filling in the survey. Secondly, after this setback became apparent, there were only a limited amount of options left to distribute the survey due to the Covid-19 pandemic. We did however manage to increase the amount of participants by approaching individual students or small group chats of students. This might have introduced some bias to our results, especially since the students we approached were generally friends or other people that we knew. We have chosen to do this anyway since the otherwise extremely low sample size would have definitely been more detrimental to the accurate exploration of our user’s requirements. | |||
'''1. How often do you approximately study in Metaforum?''' | |||
[[File:Q1.png|700px]] | |||
All respondents answered that they studied in Metaforum. This confirms that our survey has reached our target users and therefore allows us to analyze the rest of the questions of this survey. | |||
'''2. How often do you have trouble finding a place to study in Metaforum?''' | |||
[[File:picture2.png|700px]] | |||
The answers to this question were fairly evenly split between “often”, “occasionally” and “rarely”. Although this does show that our problem statement is far from shared by all students, it also equally shows that there is definitely a need for a solution to our problem statement. | |||
'''3. Would you appreciate and use an app that allows you to see a map of available open study spaces?''' | |||
[[File:picture3.png|700px]] | |||
Except for a single answer everyone responded that they would at least somewhat appreciate our application and would at least use it occasionally. | |||
'''4. If you answered "No" to the question above, what is your main reason for doing so?''' | |||
The single person that responded with “no” to question 3 answered here that finding a study place would be faster without using the app. This probably has to do with this person also answering “rarely” to question 2. | |||
'''5 & 6. Would you have any concerns regarding privacy if the app made use of a network of cameras at these study places to determine where free places are available?''' | |||
'''How would you answer the last question if it would be ensured that the footage from the cameras is exclusively used by software for determining where free chairs are located and therefore cannot be viewed by anyone?''' | |||
[[File:picture5.png|700px]] [[File:picture6.png|700px]] | |||
First, before the respondents knew that the footage is used exclusively by the software, roughly one-third of them (36,8%) did not like the idea of using cameras due to privacy concerns. After knowing that the footage is exclusively used by software, the amount of people, who initially said that using a camera was unacceptable, has decreased to roughly one-sixth (15,8%). So, more than half of them changed their minds after knowing that. The total amount of people who find it acceptable (or at least tolerable) to use cameras for finding vacant seats, after knowing the footage cannot be accessed by people, seems to be 84,2%. | |||
'''7. When you are studying in Metaforum, what percentage of the time do you estimate you have your laptop before you?''' | |||
[[File:picture7.png|700px]] | |||
This question was answered surprisingly unanimously, all respondents reported having their laptops in front of them at least 80% of the time, for an average of 94,7%. | |||
'''8. Do you have any miscellaneous thoughts or concerns about our proposed solution?''' | |||
About a third of the participants answered this open question. Two commented that they thought the application wasn’t necessary, another two commented that they had privacy concerns, one of which suggested using sensors rather than cameras. Lastly, one respondent replied that they would like to see an implementation with the planapp rather than the development of a new app. | |||
===Conclusion=== | |||
Our participants can be roughly divided into two groups, a larger group that occasionally or often has trouble finding a study place in Metaforum and would appreciate our app, and a smaller group that only rarely or occasionally has trouble finding a study place and that doesn’t see much benefit in our application. This doesn’t matter that much for the development of our technology, since unlike room reservations the use of our application is voluntary. While it obviously would be better if even more participants answered that they would like to use our app, the part of the students that isn’t interested in using the application doesn’t experience any negative consequences. Additionally, the fact that there is still a majority that would like to use our application confirms that there is definitely a need for the technology that we are developing. What does potentially pose a problem are the responses to the questions about privacy. Although most participants didn’t have any privacy issues, especially if the footage isn’t saved or viewed, there is still roughly 15% that do. Unlike the previously described situation, the people that are worried about privacy issues are still affected by those issues, regardless of them using the app or not. This means that we will need to further think about possible changes that we could make to our application that could resolve these issues. | |||
==State-of-the-art== | ==State-of-the-art== | ||
Line 171: | Line 238: | ||
====Seat or Workspace Occupancy Detection==== | ====Seat or Workspace Occupancy Detection==== | ||
A group students from the Singapore Management University have tried to tackle a similar problem.<ref>Nguyen, Huy Hoang, [https://ink.library.smu.edu.sg/cgi/viewcontent.cgi?article=4118&context=sis_research "Real-time Detection of Seat Occupancy and Hogging"], ''IoT-App'', 2015</ref> In their research they proposed a method using capacitance and infrared sensors to solve the problem of seat hogging. Using this they can accurately determine whether a seat is empty, occupied by a human, or the table is occupied by items. This method does require a sensor to be placed underneath each table and since in our situation the chairs move around, this method can't be used everywhere. | A group of students from the Singapore Management University have tried to tackle a similar problem.<ref>Nguyen, Huy Hoang, [https://ink.library.smu.edu.sg/cgi/viewcontent.cgi?article=4118&context=sis_research "Real-time Detection of Seat Occupancy and Hogging"], ''IoT-App'', 2015</ref> In their research they proposed a method using capacitance and infrared sensors to solve the problem of seat hogging. Using this they can accurately determine whether a seat is empty, occupied by a human, or the table is occupied by items. This method does require a sensor to be placed underneath each table and since in our situation the chairs move around, this method can't be used everywhere. | ||
A seat occupancy method using capacitive sensing has also been proposed.<ref>George, Boby, [https://ieeexplore.ieee.org/document/4745783 "Seat Occupancy Detection Based on Capacitive Sensing"], ''IEEE Transactions on Instrumentation and Measurement'', 2009</ref> The research focused on car seats and can also detect the position of the seated person. A prototype has shown that it is feasible in real-time situations. | A seat occupancy method using capacitive sensing has also been proposed.<ref>George, Boby, [https://ieeexplore.ieee.org/document/4745783 "Seat Occupancy Detection Based on Capacitive Sensing"], ''IEEE Transactions on Instrumentation and Measurement'', 2009</ref> The research focused on car seats and can also detect the position of the seated person. A prototype has shown that it is feasible in real-time situations. | ||
Line 179: | Line 246: | ||
A method using cameras is described in the research by the National Laboratory of Pattern Recognition in China for people in seats counting.<ref>Liang, Hongyu, [http://www.nlpr.ia.ac.cn/2012papers/gnhy/nh14.pdf "People in Seats Counting via Seat Detection for Meeting Surveillance"], ''Communications in Computer and Information Science'', 2012</ref> They propose a coarse-to-fine framework to detect the amount of people in a meeting using a surveillance camera with an accuracy of 99.88%. | A method using cameras is described in the research by the National Laboratory of Pattern Recognition in China for people in seats counting.<ref>Liang, Hongyu, [http://www.nlpr.ia.ac.cn/2012papers/gnhy/nh14.pdf "People in Seats Counting via Seat Detection for Meeting Surveillance"], ''Communications in Computer and Information Science'', 2012</ref> They propose a coarse-to-fine framework to detect the amount of people in a meeting using a surveillance camera with an accuracy of 99.88%. | ||
Autodesk research also proposed a method for detecting seat occupancy, only this time for a cubicle or an entire room.<ref>Hailemariam, Ebenezer, [https://www.autodeskresearch.com/sites/default/files/Hailemariam__Occupancy_Detection__2011-02-18_1357.pdf "Real-Time Occupancy Detection using Decision Trees with Multiple Sensor Types"], ''Autodesk Research'', 2011</ref> They used decision trees in combination with several types of sensors to determine what sensor is the most effective. The individual feature which best distinguished presence from absence was the root mean square of a passive infrared motion sensor. It had an accuracy of 98.4% but using multiple sensors only made the result worse, probably due to overfitting. This method could be implemented for rooms around the university but not for individual chairs. | Autodesk research also proposed a method for detecting seat occupancy, only this time for a cubicle or an entire room.<ref>Hailemariam, Ebenezer, [https://www.autodeskresearch.com/sites/default/files/Hailemariam__Occupancy_Detection__2011-02-18_1357.pdf "Real-Time Occupancy Detection using Decision Trees with Multiple Sensor Types"], ''Autodesk Research'', 2011</ref> They used decision trees in combination with several types of sensors to determine what sensor is the most effective. The individual feature which best distinguished presence from absence was the root-mean-square of a passive infrared motion sensor. It had an accuracy of 98.4% but using multiple sensors only made the result worse, probably due to overfitting. This method could be implemented for rooms around the university but not for individual chairs. | ||
A similar idea was envisioned a few years ago with the creation of an app called RoomFinder which allowed students at Bryant University to find empty rooms around campus to study in.<ref>Chrisni, [https://universitybusiness.com/app-helps-students-find-empty-study-space/ "App helps students find empty study space"], ''University Business'', 2014</ref> This system, created by one of the students, taps into the sensors used by the automatic lighting system in these rooms, to detect whether a room is currently being used and sends that information to the app. As that system was already implemented around campus, it didn't require any capital investment. | A similar idea was envisioned a few years ago with the creation of an app called RoomFinder which allowed students at Bryant University to find empty rooms around campus to study in.<ref>Chrisni, [https://universitybusiness.com/app-helps-students-find-empty-study-space/ "App helps students find empty study space"], ''University Business'', 2014</ref> This system, created by one of the students, taps into the sensors used by the automatic lighting system in these rooms, to detect whether a room is currently being used and sends that information to the app. As that system was already implemented around campus, it didn't require any capital investment. | ||
Line 206: | Line 273: | ||
==Schedule== | ==Schedule== | ||
Our current planning can be seen in the table below | Our current planning can be seen in the table below | ||
[[File: | [[File:Gantchart.png|1100px]] | ||
=Rooms= | |||
Besides the system to detect free workplaces, it should also be noted that the system to reserve rooms at the TU/e has some flaws. At first, there is currently no system in place to detect if the room is actually used. There have only been some pilots, plus there are no punishments for those who take advantage of the system. In this section there will only be a focus on suggestions and recommendations to "upgrade" the system. | |||
==State of the art at the TU/e== | |||
The current system which is used at the Technical University of Eindhoven is based upon Planon. This system manages the reservations for the rooms and the workplaces in auditorium and some others around the campus. Those workplaces are able to be recognised by the stickers and the QR-codes on the tables. | |||
The TU/e has also expended upon it by using BookMySpace in combination with Planon, reservations made by BookMySpace will be fed into Planon. This results in that BookMySpace is still limited by the possibilities by Planon. For example Planon can not handle that a reservation is shared between multiple people. Currently BookMySpace sends invites via outlook to create the meeting, but the actual reservation can only be made by one person. | |||
The system has also expanded upon by Pilots of BookMySpace. In the building Metaforum they implemented sensors in some room to detect no-showers, people who do not show up in time, and early leavers, people who leave earlier than expected. After 15 minutes of no movement the sensor could consider the room empty and cancel the current reservation. However there were some noticed problems with this system. While the system could detect no-showers correctly it had some problems with early-leavers. Since the detection of the system was based upon movement sensors it could happen that if a person was making a test or sits too still for 15 minute the system does not detect any movement and detects it as early-left. This could give the room free for other students to use while someone was in a test. That resulted into that the observer or examinee had to move or wave their hand every 15 minutes which was quite inconvenient. | |||
Also from sources from BookMySpace there probably will be another pilot in the upcoming future in the building Atlas at the TU/e campus. This system will probably use some form of detection systems in the lamps. One difference with this pilot in comparison to the pilot in Metaforum is that this detection will be based upon heat. This will result that the detection system can detect if people are in the room, and even how many there are in the room. This will probably reduce the chance of a wrong detection of early leavers in comparison to the old system. Which could result into a wide implementation of a no-shower and early-leaver system into Atlas. Since those lamps are at this moment only compatible with the building Atlas. | |||
Besides the pilots above there is also another system in place at the University in Flux. Those rooms are only reserverable by students of the faculties located in the building, however to access the rooms the reserving person has to enter the room with his or her student card so it can be noted who and when the room is entered. | |||
==Regulations== | |||
In comparison to the system with the chairs which will be explained below, it is possible to pursue people who do not follow the rules and regulations with the rooms system at the TU/e. People need to reserve rooms through their account, making it possible to make them responsible for what happens to the room as long as they have reserved it (name, picture of account holder, student number, etc. are all known once a person has reserved a room through his/her account). | |||
Following it is able to pursue people who do not follow the regulations, regulations can be determined and set up for the students including “punishments”. However also here there are some social norms which people must follow to make sure the system works efficiently. | |||
Some of the social norms to make the system more efficient could be: | |||
* A person can only make use of a room when he or she has reserved it. So, the room does not register that people are in the room and the room can be given as “free” in the system so it can be reserved in the system again. Plus, the system then always knows who has been in the room the latest. | |||
* A person only reserves the room for the time he is in the room, so during a planned lunch break the room can be used by other students or staff. | |||
* In case there is something wrong in the room it will be notified immediately to the university. If this is done the last person entering the room could be held accountable. | |||
There are of course also regulations for reserving the room in the system: | |||
* Rooms can only be reserved up to 7 days in advance by students and teachers for normal meetings. Exceptions are made for meetings for courses which can be reserved for a longer period. | |||
* Reservations can only be made when they are not already in conflict with another reservation. | |||
* A person cannot reserve more than one room in the same time period. This to prevent reserved empty rooms and that the reserving person is in the room. | |||
Next up are the regulations which are punishable, however between those most of them are hard to check if social norms are not followed so it is unknown who did it. | |||
* No vandalism or anything else of the sort. This one is difficult to punish as there could be a variety of people throughout the day in the room which could have vandalized the room and the last person reserving it is not always responsible. | |||
* The room should be left the same way it was found. If chairs and/or tables have been moved in the room, they need to be put back in their original positions before leaving the room. Other items that did not originally belong in the room should be taken away or thrown in the bin. | |||
* Every day, all items left behind found in the rooms will be stored safely and can be picked up at the help desk of the same building as the room where the object was left behind. | |||
* Rooms are only used for meetings in groups and not for single students to work in. | |||
Followed by the regulations which are could be punished if a system was in place to detect the presence of people in the room like at the pilots of the TU/e: | |||
* If no one is in the room after 15 minutes during the reservation, the reservation is cancelled and will be labelled as a no-show. | |||
* If the room is empty during a reservation for a period longer than 15 minutes the reservation is cancelled as well and will be labelled as an early-left. | |||
Now the regulations are in place it is possible to put up the punishments for those who violate the rules of the system. One thing to note is that there will be no punishment for an early-leaver, as this person or group are finished. There should be no punishment for people who are done earlier than expected and let the system detect the room as free. | |||
For the actual punishments those will be based upon the severity of the violation and the previous violations. For example, vandalism of the room can be considered as a higher severity than not showing up. Those violations will then be added up and when certain thresholds are reached limitations will be put upon the user. The reasoning a threshold is used it that someone is a no-show due to strange odds he or she will not be punished. After the passing of time and not violating any rules of the system the violations will disappear and if it is below the threshold less or no limitations are present anymore for the user. This system punishes the abusers harder while a rare no-show will not be punished to keep the system fair for everyone. | |||
It is recommended by bookmyspace to use as little thresholds and punishments as possible. Since the more thresholds and punishments are present within the system the harder it will get for the system to accommodate reservations for everyone and make the system work optimally. So only three thresholds will be suggested. | |||
The first threshold will only a simple limitation of that a person is only able to hold reservations with a total maximum time of 8 hours. This makes sure that person can reserve rooms for a day if needed or multiple smaller meetings during the week. But must think more clearly at what times he or she will be needing the rooms as there is a restriction. | |||
The next threshold will impose another extra rule on top of that which instead of reserving rooms 7 days in advance it is only possible to reserve rooms 3 days in advance. This will give users who do not abuse the system the first choice of rooms while the people who are violating the system have the “second choice” of rooms. It still should give the user enough time to find an empty room in the system though. | |||
The final threshold will reduce the maximum time from 8 to 4 hours of maximum time of reservations. It will it still make it able to reserve rooms and have meetings, as that should not be limited completely since he still is a student or employee of the university and the university provides those services. | |||
=Chairs= | =Chairs= | ||
Besides the problem with the room there is also the occasional problem that a student is not able to find an empty workplace in a reasonable amount of time. This is especially true during exam weeks. To solve this problem a system will be designed and proposed as a possible solution to this problem. | |||
== State of art at the TU/e == | |||
The current system which is used at the Technical University of Eindhoven is based upon Planon. This system manages the reservations for the rooms and the workplaces in auditorium and some others around the campus. Those workplaces are able to be recognised by the stickers and the QR-codes on the tables. These currently can be found in the buildings Auditorium, Vertigo, Flux and Cascade. These tables can be reserved using either Planon or BookMySpace | |||
Currently the system works by reserving the workplace, mostly looking at the table. This is another approach to our suggested system which will be explained further below where we look at the chairs instead of the table. Another distinction is that this system works by reserving the workplace in advance, you can look in BookMySpace or Planon to find an unreserved workplace and you could make a reservation for yourself. However it is concluded currently do not use this system much since in general there is enough place at the places this system is used. One advantage of this system that you could kick out people if you have reserved a chair, while this could lead to some inconveniences and arguments with students which might not want to leave. Which is in turn another distinction with our proposed system which mainly looks at the current empty chairs in an area where you cannot reserve a chair. | |||
==Regulations== | |||
In order to run the system as optimally as possible, it is highly recommended that people follow the proposed rules and regulations. The reason why these are "highly recommended" and not mandatory, is because it is not possible to persue people who do not follow these rules and regulations. Currently, the system is not able to tell who a person exactly is when they are detected by the program. It treats everything as different "objects" and therefore it cannot distinguish different people from each other. Furthermore, even if the system was able to tell who person is, distinguishing people from each other can also lead to some ethical problems. For instance, some people do not want the system to recognise who they are, which means that implementing this feature will induce some privacy issues. Therefore it is better to leave the system in such a state where it only detects people, but nothing more than that. | |||
*A person cannot stay at a workplace outside of the reserved time | This results that the rules and regulations should be considered more like "social norms" which people have to follow to make the system work optimally and more effecient. Which results into the following social norms: | ||
*A person cannot stay at away of the workplace for a longer period of time while holding the workplace. People who are leaving the chair for a minute to go to the toilet or strech their legs is not a problem. However, sometimes people tend to walk away from their spot for an hour while they still claim the spot with their stuff as a jacket or bag. This claimed spot then cannot be used for other people who might want to sit at that place to study while the other is gone. | |||
*A person can only claim one workplace for themselves. If people are claiming chairs for other people to mark them as occupied for the system and people people will not be able to sit there while the spot is still technically free. As no person is currently working at the workplace. | |||
*Chairs should not be removed from the table or workplace they belong to. This one depends more on the situation and the area, for smaller areas it is probably better to not move the chairs as much since non-occupied chairs also indicate a workplace which is empty. For bigger areas like the metaforum at the TU/e this is less of an issue as there are long table with lots of empty spots. | |||
==System Design== | |||
===Design Choices=== | |||
How the information is conveyed to the people is the next question. There are multiple options to collect and convey the information to the system users. In this part we will discuss some options that are available and could be used in a practical environment. | |||
====How should the information be collected?==== | |||
'''Which kind of system?''' | |||
As described in the approach, there are multiple ways to collect the data needed for the system. For detecting a chair and checking if it is occupied or not, a camera-based system or the thermographic-based system would probably be the best option. However, the camera-based system has one big advantage over a thermographic-based system, which are the costs. The cost of a thermographic camera is quite high when compared to a basic camera. A “cheap” small camera, which can be connected to something like an Arduino, will already cost 65 euros <ref>https://www.kiwi-electronics.nl/pim-366?gclid=Cj0KCQjwmdzzBRC7ARIsANdqRRkUsg-t0mHJsYqvDHnaXh2_9f-iEM5mh6Zx6nlUSVyonYZm-ykyR7gaAgL2EALw_wcB</ref> for a 32x24 pixel view of an angle of 56 degrees. While for 15 euros <ref>https://www.reichelt.nl/raspberry-pi-nul-camera-voor-raspberry-pi-nul-5mp-170-ov56-rpiz-cam-5mp-170-p242690.html?PROVID=2788&gclid=Cj0KCQjwmdzzBRC7ARIsANdqRRlsTczvVNw71UAnh9ichnF7q0_zseop_JK1u6pCXN6F1NoSeUuBMEIaAkxMEALw_wcB&&r=1</ref> it is also possible to get a 5MP camera with an angle of 170 degrees. A higher pixel count leads to more accurate data to analyse for the algorithm, which determines whether a chair is empty or not, which in turn gives a more accurate representation. In bigger buildings or campuses this could greatly reduce the costs, since less and cheaper cameras are needed for the system while also being more accurate. | |||
'''Implementation''' | |||
How the system will be implemented also depends on which building it will be implemented. Preferably, the cameras will be mounted to the ceiling to get a wide coverage of the area, which reduces the number of cameras needed for the system. It is possible to hang them directly above the tables. This lowers the chance of a chair obstructing the view of a camera, since it looks at them from a “bird eye” view. If the camera is in a corner of the ceiling, it will probably have a wider coverage of the area, but the view of an object can more easily be obstructed by other objects, or even other chairs. | |||
The actual system implementation will mostly depend on a couple of factors. Costs, space, and accuracy. At first you have the space available; the ceiling height can change the location of the camera. If the area has a lower ceiling, the “bird's-eye view” will rapidly reduce in visibility the lower the ceiling is ,while a camera in the corner has less problems with that. However, with a lower ceiling it could also be said that since there is more a linear view, there are more possible obstructions for the system. So here, the costs and accurateness of the system come into play. When an accurate system is needed and costs are less of an issue, you could opt to use more cameras in a bird's-eye view for a lower chance of obstruction. The other way around is of course also more possible. | |||
Another reason why the bird eye view can be made more accurate is that in bigger areas, where one camera cannot convey the whole room, it is easier to define boundaries of bird's-eye view cameras since they only must look in a certain “box”. The camera in a corner also has depth to consider, so it is harder to not have duplications in the system. This would also probably mean that the calibration of the cameras will take less time which could in turn also reduce the costs a bit due to less hours needed to implement the system. | |||
Another factor is how the cameras will be connected into the systems. You could opt for separate stations which process the data locally and then send them to the server. The other option is to collect the video tape at location and then send them to a central processing unit where every data is gathered. This will mostly depend on how much processing power you need and how many data you collect. For smaller systems a central processing unit would suffice since it does not handle that much data which makes it possible to queue up the data more easily. Also, a central processing unit is in general more powerful than a small station which also reduces the time needed to detect empty chairs. For bigger buildings with a lot of areas to be governed by the system multiple separate stations would probably be the better options. It will cost a bit more time to compute but it will have less data to process which as well should even it out. It also has the advantage that if one station goes down the system still partially functions while if the central unit goes down the whole system stops. | |||
'''Data handling''' | |||
Of course, the privacy of the users, and not users who are in the area is also something to consider. The data must be handled in such a way to make sure the system can be used, is privacy law compliant and is accepted by the people working there. Preferably the videos in the system should only be used to detect the chairs and for nothing else. This gives the highest probability that the people and the law are compliant with it, also in the future. To assure this the best option would be a “black box” model where the video tape goes directly into the system, and then the location of the chairs come out of it which will be send to the server. | |||
If the video tape cannot be accessed it results in that people cannot use the video to spy on the people working in the area, also the video tape should not be stored, or only stored locally for a small amount of time and should be deleted when the system is done processing the information, this also reduces the chance of someone accessing the video footage. One focus of the system also should be that it cannot recognise individuals but only a “human”. In case the system information is accessed the only things visible are object, human, empty chair, occupied chair etc. | |||
Preferably most of the communication of the system would be done via wired connections, since that could reduce the risk of that the system is hacked and information falls into the wrong hands. With a wired system the hacker must have access to the system locally and physically while a wireless system could be hacked remotely. This also includes a database which is located on their own system, so that third-parties are not able to access that data. | |||
====What functions should the application have?==== | |||
'''Accessibility''' | |||
At first the system should be easily accessible for the users. If the system is easily accessible it should have a higher likelihood of being used by the intended users. This means that for example a system which only uses some screens in the building is not preferable since that could lead up to a queue to use the system and with that people ignoring it. Preferably it would be a web application or an app for mobile phones. This gives everyone access when they want to use the system. Also, almost, everyone has a smartphone on hand which they could use to access the said web application or app. Plus as an advantage it is also mobile which could help people traverse through the environment. | |||
'''Favourite system''' | |||
Another feature to increase the accessibility and usability of the application is to have a favourite feature. This could save the favourite area of the user and put that into a list. This will make it easier for the user to access the areas the user prefers and go to that area directly within a few clicks. Preferably it is not only possible to save a specific areas into the list but also a building, or floor of a building to increase the convivence of the favourite system. | |||
'''Connectivity''' | |||
We also must look at the connectivity of the system. How will it be connected to the outside world, or will it be a completely closed system with no direct access to the internet. At first is a closed system with no internet access probably the most privacy secure option. Since people need to be hooked up directly into the system would they be able to break into the data. However, that means that the system can also not be used with mobile phones that well since there is no internet connection. That should result in a less accessible system which might be less used by the intended users. A further dive into the privacy will be done later. So, for it to be widely accessible it should have a connection to the internet so it can clearly and easily communicate with the people. | |||
In case an internet connection is used the system should update the information regularly into a database so the web application or mobile app can have accurate and reliable data. Otherwise users of the system could walk to already occupied chairs for a certain amount of time without being notified of it. This would lead to that preferably the system would be updated real time, however this can put a real strain on the server and system since they must analyse everything at every moment of time. To reduce the load on the system it would only have to update every 10 seconds or so. This gives the system move time to check for empty chairs which reduces the computational power needed for the system. Also, it reduces the load on the server since less data is send to the server. | |||
For the web application or mobile app, the same argument can be made. They could update in real time based upon the information they have gotten from the server, which is about every 10 seconds, or have a refresh function which must be activated manually. While a real time update gives the most accurate information it also increases the load of the system. If people accidentally keep the application option while not looking at it, it still asks requests of the server. If a lot of people are doing it, it might cause some unnecessary problem for the people who want to use the system, as it can reduce to slower loading times due to the higher strain on the server. So, the best option would probably be a refresh function, the moment the app is moment it asks the most accurate data of the server, then the people can press a button to refresh the data with the latest data of the server. To make sure it is not spammed it could be made that it can only be pressed every 5 seconds or so for those who want to play with the button. | |||
'''Login- / Access system''' | |||
Another debate can be what chairs should be made visible to who. At first the building might have restricted access area only accessible to a certain number of employees. Preferably those are not visible for those who should not be able to access that area. For example, at the TU/e in the Atlas building there are areas which are reserved for innovation sciences students. A mechanical engineering should preferably not be able to see the visible chairs at the location. This can be solved using a login- / access system, people can get different rights for certain areas to only see the areas which are accessible for them. This however can reduce the usability and accessibility of people since not everyone can access the system. This could lead to a problem where the system is not used in possibly busy public areas like a busy library since not everyone wants to do the hassle to make an account. To tackle this problem, it is an option to make certain areas publicly available without an account, while other areas are locked behind an account, in the same manner a mechanical engineer cannot see the area of innovation sciences. | |||
A bonus of using a login- / access system would be that users could be able to mark an area as a favourite area for them on their account. These could then be displayed in a separate list with is accessible with a single button press. As some users like to sit in the same area if they must be present at the location. | |||
'''Reserving a chair''' | |||
It can be argued that a possible function for the system is to the possibility to reserve a chair which the user might want to sit on. This makes sure that the user can sit at the location he or she wants you would think. However, this is difficult to implement into the system as this thought is based upon either of the following premises. The first premise might be that everyone uses the app, then everyone can see which chairs are empty and which are free to pick. The second premise is that the chair might be able to indicate that the chair is reserved but currently not occupied. Both these premises, if true, should both make it able to implement a system which the chair could be reserved as it is indicated while a chair is reserved or not. Sadly, the first one can be hindered by people who are not using the system and will then claim an already reserved chair while the person who reserved it will be left with no chair. The second one can be hindered by the costs of the system as every chair must have an indication that the chair is reserved to make the system work, plus that people do not claim an already reserved chair. | |||
'''Privacy''' | |||
The system also must take privacy into account while showing the information. The more data is stored in the application the more chance it must be less privacy compliant to laws or public reception. It should preferable only store the necessary data from the users to make it also future proof if laws might get changed later. | |||
For this system to work there is not that much necessary data which should be collected from within the application. The most prominent data collection from the user is the login- or access system. If it is opted to use such a system, it should store the user’s data to make sure he or she stays logged in to the system. Also, extra data from the user might be asked, like the role in the company for the system to know which area’s it can have access to. However, other personal data, as the name of the user, is not important for the | |||
Other commonly frequently asked permissions from an application should not be necessary. Agenda, camera, contacts, microphone, SMS and phone access should not be used within the app. One debatable access might be the use of location. If it is chosen to also incorporate a navigation to the chosen area or the chosen chair the person wants to sit on location access is needed. Storage access however might be needed, since this could store the login information or preferences from the user so he or she does not have to login every time he or she wants to use the application. | |||
====How should the information be conveyed?==== | |||
'''All chairs vs only non-occupied chairs''' | |||
At first there is the option to change the display of all the chairs, the occupied and non-occupied chairs. Both have their own advantages and disadvantages. At first if occupied chairs are shown the system has an additional functionality. Since all chairs are visible by the system the user should be able to see empty spots at the tables. If there is a distance between two (non)-occupied chairs you can consider that area empty. While if only non-occupied chairs are visible the user is not able to know if there is an occupied chair there or not. While this functionality for a single user doesn’t matter that much, for a group of users this could matter since it is easier to find places to sit. | |||
If occupied chairs are shown it can also lead to a small ethical problem. Since it can be argued that it is easier to track a person’s movement if occupied chairs are visible. If the occupier moves the chair it is visible, and the movement of the person can be tracked more easily in comparison to if the occupied chairs are not visible. Since movement of occupied chairs will then not be shown. | |||
'''Mobile application vs web application''' | |||
As discussed by accessibility the application should be accessible, preferably via phone. If this is done there are two options, a mobile application or a web application which both have their own advantages and disadvantages. As the "gathering" system is a very closed one and sends data to a database it has to be chosen how that data from the database is conveyed to the application user. | |||
A web-based application has one major advantage and that is that only one application must be designed which should be able to work on any mobile phone. As browsers and their applications can be accessed from Android, iOS, Windows and other systems with access to browsers. This decreases the development time of the application since it does not have to be ported to another OS, although it only must be working at Android and iOS to have 99% market share. <ref>https://gs.statcounter.com/os-market-share/mobile/worldwide</ref>Another advantage is that it can also work for laptops and computers, this results into that people at one place could look at their laptop to find a new one in case they have to move since the group size is increased for example. | |||
This could be compared to the major downside and that a browser tends to “forget” the login quite a lot more often. Since a mobile application can store the credentials and login information locally while a browser cannot. So, if a browser is closed the cookies and cache are lost and the user must sign in again which can lead to a small hassle for the users. This could lead to a decrease of accessibility and for that possible use of the system. | |||
'''Interface''' | |||
Next up is the actual interface of the application, as the information should work optimally to convey the information in a clear manner. At first there is the option for bigger campuses which use multiple buildings to have a list of the buildings with the number of non-occupied chairs or a map with all the buildings and the number of non-occupied chairs. The first option might be better suited for users who are already familiar with the campus since they know where each building is located. Plus, the information can be seen a bit clearer and faster since you do not have to scroll or zoom to the correct building. The second option is better suited for newer users who are not familiar with the campus yet. These users can then have an overview where the building is located with an immediate number for the number of empty chairs. | |||
Besides the number of chairs, it should be clear which facilities the building has to offer. For example, at the TU/e some buildings offer silent areas where it is expected of the students that they work in concentration silently without noise. Also, there are labs for students located all around the campus as well. Some areas also facilitate power outlets for the students or a possibility for a wired internet connection. This could help users of the system decide to which building they want to go in case they have specific needs. This is not only true for the buildings, but this information should also be visible at the selection of the floors and specific areas. | |||
Next up is the floor selection. The floor selection of a building can be kept quite simple as a simple list, with the possibility to look at the facilities of each floor of course. If a floor is selected there are a couple of options which can be chosen to display the next information. | |||
At first you have the possibility to show the entire floor map with all the (non)-occupied chairs visible. However, this has two downsides which must be considered. As all the chairs are loaded it asks the location of all the chairs, and their status from the server. This could add unnecessary load and strain on the server since more things must be asked individually. The same could be said for the app as well since more things have to be loaded by the application individually using that data. Next up is that it can also be confusing since a mobile phone screen can only show that much information at the same time at the relatively small screen. A person will probably have to zoom in the map at first to see the location of the chairs which decreases its ease of use. | |||
Another possibility is to divide the floor into different areas as well. It has the advantages of that less information is needed, since only the empty number of chairs is needed. Which in turn decrease the load and strain on the server and application. A bonus is that also more specific information of the area can be displayed to the user. As some areas will have a certain table height while another area has a different table height. It also can make it easier to differentiate areas to see if certain areas are only meant to be accessible by a certain people or the area is a laboratory. However, it only shows the number of chairs instead of the location of the chairs as well. | |||
The best option between the above would probably be to have the latter as a selection which then pulls up the map of the area with the (non)-occupied chairs. This has the best of both options as areas are easily differentiated by each other and reducing stress and strain on the application and server while it is also possible to see all the chairs at their location. | |||
===Recommended systems=== | |||
As seen in the above, there are a lot of debates and possibilities to incorporate into the design. The most important about it is that it can differ between different system-users what functionalities are chosen to incorporate into the design. | |||
====Universal recommendations==== | |||
At first there are the more universal options which should be recommended into every system. At first it is suggested to use normal cameras instead of the thermal cameras. Due to the higher accuracy of the camera it should be easier for the system to detect chairs. Plus, less cameras are needed which reduces costs and make it easier to incorporate it seamlessly into the environment. The cameras should be located at the ceiling, preferably directly above the area. As this will make it easier to create zones and know every location is checked for empty chairs. In case this is not possible it can be opted for a camera at the wall. Preferably the camera is located at 2 meters or more to have less chance of obstruction. | |||
In general, for system implementation it is recommended to have small processing units which only are connected to a couple of cameras or areas depending on the size of the area and the building. Those units process the data locally and then send it to the database. This should result in better reliability of the system as if one unit goes down the rest of the system continues working in comparison to one central computing system. Also, if maintenance must be done to the units only one unit has to be put offline and temporarily disabled. The latter is however only true if it is a system update to the units and not to the database. | |||
Next up is the data handling which should be as careful with the privacy as possible. This reduces the chance of it not being privacy compliant. That should result into that preferable the video tape should not be stored and not be accessible for people. However, this could lead to a problem in case something goes wrong. Since no one can access the system it can be difficult to locate the problem and fix it. A better suggestion might be that system administrators could access the live feed directly. In this system it is still only possible for the system to see a person as a human and not personally identify it. It increases the privacy problems a bit, but the system also should be able to be maintained to be useable. Also, as little as possible of information about the application user should be stored onto the system, which results in only the preferences, login information and access which should be stored. | |||
Another universal recommendation is to make the application very accessible by it being accessible via a mobile phone. This will also result into that the system is connected via the internet to the application user with updates of about 10 seconds to keep the data up to date and relevant while also reducing stress on the server and application. Also incorporate the favourite system into the application for ease of use, but not the reserving feature as this will possibility greatly increase the cost. | |||
The interface of the application should be easy and clear while reducing stress of the application and server. So, it is recommended to have, in case there are multiple buildings, first the option to select a building from a list or a map. Followed by a floor selection, area selection and then chairs will be visible. All with an option to see the facilities of the building, floor or area and the number of empty chairs in that building, floor or area. | |||
====Specific recommendations==== | |||
Besides the universal recommendations there are also more specific recommendations which might be true for one but not for another implementation. Here there will be a look at libraries, universities and enterprises with a lot of flexible workspaces as possible system implementation targets and the specific recommendations for these will suggested. | |||
'''Library''' | |||
Libraries are publicly accessible buildings; everyone can enter freely, and a lot of different people tend to enter the library. The employees of the libraries do not tend to work in the library itself but at their own offices. In this case a login system would not be very helpful as there are not a lot of specific areas only accessible for certain amount of people. To increase the usability even further it is recommended to use a web-based application instead of a mobile application. This since a website is easier accessed as the user does not have to download a mobile application beforehand. This will create the problem that favourite areas cannot be saved easily since no login is used and it is difficult for a browser to save data directly to the mobile phone or computer which can be accessed later. This should not be a problem for smaller libraries; however, this could be annoying for users in bigger libraries. In bigger libraries it can be decided to use a login system or an application to have the favourite feature as a possibility of the system. As libraries are commonly interconnected and share a lot of system the best solution would probably to have an optional login system for the libraries, small and big ones, where the favourite area could be stored. Users who don’t mind their preferences or favourite area could then use the application without any problem. As everyone can access the building and the system it is recommended to display only the non-occupied chairs to guarantee the privacy as much as possible. | |||
'''Enterprises''' | |||
First, since enterprises are, mostly, private buildings they are not accessible for everyone. This also leads to a recommendation of using a login for even using the system. So other people are not able to “spy” into the company’s work floor. As a login system is recommend it also would be preferable to use a mobile application-based system to convey the information. As this makes it easier to store the login information of the user and increase the application’s usability. Also, it is recommended that the system only shows the non-occupied chairs. A boss will then not be able to monitor the activity of the employees that easily, as some workplaces might not have a chair and chairs can be moved to other places. | |||
'''University''' | |||
The university is officially a publicly accessible building, which should suggest that an open system is recommended without any login. However, this is not always the case, areas in a university might be designated for only a certain type of student. This is mostly tied to the faculties; another problem is that at the university you have employees and students working in the same buildings. Some flexible workspaces might be specifically designated to staff while other are meant for students. A login system will be recommended for universities. This login system will put the specifically designated areas behind a login, while other areas which are open for all are not behind a login. | |||
Since a university campus can be quite large a system to store the favourite areas and preferences should be incorporated. This could either be done locally or to the account. To make sure that it is still very and easily accessible for everyone this would be recommended to do locally. As then everyone can still add their favourite spots without having to sign in. To save the data the system should be based upon a mobile application. As this will make it possible to store said data and login information more easily than a web-based application. | |||
It is recommended that the occupied chairs are also visible at universities. Universities tend to have large study rooms with a lot of big tables and a great number of chairs. By being able to look at the location of all the chairs, the occupied and empty ones, a student can also find a free spot at one of the tables. As non-occupied chairs might be located at places where there is not much room on the table to work at. | |||
To extend upon this it is specifically asked to people from bookmyspace of the TU/e how they thought about it. At first, they want to make all study places available for every student or staff but practically that is not the case at the campus. So, they agreed with the plan to have an access tool where everyone can see easily where they can and cannot sit integrated into the app. Further they also prefer that the study- / workplaces are only available for the TU/e students or personnel. Thus, bookmyspace would prefer that every area is behind a login and not only certain areas so other people are not able to tempted to sit at the university. | |||
=== Visualisation of system === | |||
So how will the information be conveyed to the people? At first the layout of the information does not change much if a web-based application is used or a mobile application. It must be considered that if it is a web-based application it could be used at laptops and computers which have bigger screens. Further is it still meant for both to be used on a mobile phone which makes it still very similar. | |||
For an example of visualisation of the system the campus of the TU/e will be used, as this campus covers multiple buildings with different facilities and flexible workspaces for students and staff. This example will cover almost all use-cases since a visualisation of a campus can be skipped in case it is only one building. | |||
As discussed above with a campus you have the option to see the campus on a map with the ability to look at the building with flexible workspaces available and what facilities they have. To be extra clear for people do buildings without flexible workplaces have a different colour than those who have flexible workspaces in their building. In the building who do have flexible workspaces a number will be shown which shows the number of free chairs in said building. Plus, it is also possible to click on the building to see the facilities which the building can provide for the student or employee. Those facilities could include laboratories, general workplaces or workplaces for concentration. | |||
[[File:TUplatV2.png|500px]] | |||
As seen at the above in the example, the building on the campus without any workplace are displayed in red. In case a building does have flexible workplaces but are all occupied the burning does not turn red, but instead the number 0 will be shown. This to make it clear that building still has workplace which might become non-occupied at the time of arriving. For the other buildings they have the number within them to make it clear how many non-occupied workspaces are available in the building. | |||
A map like this would be favourable for those who the campus is still unknown and do not know all the locations. A nice overview is shown, and they could also use it to navigate around the campus with it. For those who are already familiar with the campus can a map be inconvenient. A map can be zoomed out to much which could prevent finding the building with the highest number of chairs available or checking the building which he or she wants to sit at. As discussed before as well a list with the building would be more favourable for those. | |||
When a building is selected, via the map or list, a list of all the floors in the building should pop up. This list includes, as the building list also should, the facilities each floor can provide and the number of available workplaces at that floor. | |||
Following this a map of the floor will be given. Here the map is divided into separate areas with each their facilities and number of chairs available to sit at. In case a login system is used some areas might be greyed out for the user since he or she is not allowed to sit there. Using the example of the TU/e campus, a bachelor student from mechanical engineering is not able to see the flexible workplaces which are meant for employees of the university or for master students from other faculties. | |||
[[File:Metafloorplan.png|300px]][[File:Metafloorplaninfo.png|300px]] | |||
This | Subsequently if an area is pressed it will bring up a specific map of the area. This area will finally show all the occupied and non-occupied chairs available in that area. It can also be opted to only show the non-occupied chairs which will then in turn only show the available chairs and not the occupied ones. | ||
[[File:lightgreenarea.png|500px]] | |||
==App Creation== | ==App Creation== | ||
The | The App for the prototype is made in Unity. This is a program that can create various types of software on many platforms including Android an iOS apps. | ||
===App Design=== | |||
The design of the app consists of 4 screen levels. | |||
The first screen has a map of the campus with all the buildings that have free seats in beige and the buildings without available seats in red. It also shows the name and the number of currently available seats on the screen. There is a refresh button in the top right of the screen that can be used to refresh the data on the number of available seats. The user can click on a building to go to the screen of that specific building. Also each building has a info button with information about the seating in that building. | |||
[[File:Screen1FindaSeat.PNG|200px]] | |||
[[File:Screen2FindaSeat.PNG|200px]] | |||
This second screen a list of buttons is shown with the floors and other areas of the building. Here it again shows the number of available seats on each floor and there is again a refresh button to refresh this data. There is also a back button in the top left to go back to the previous screen. Every area also has a info button that when clicked will show a bar with information about the seats in that area. The user can click on a floor to go to the screen for that specific floor. | |||
On this screen it shows a map of the entire floor with the tables that have free seats in beige. This map will be divided in various areas with each showing the number of available seats. Again the screen has a refresh and back button. The user can click on one of the areas to go to the final screen. Also each area has a info button with information about the seating in that area. | |||
[[File:Screen3FindaSeat.PNG|200px]] | |||
[[File:Screen4FindaSeat.PNG|200px]] | |||
[[File:Screen5FindaSeat.PNG|200px]] | |||
On this final screen a map of the selected area will be shown with red and green dots on it, with a legend explaining this. These green dots represent available seats at their position and the red dots represent seats that are taken. Again the screen also has a refresh and back button. | |||
On the screens with the dots it currently takes the number of available and taken seats from the firebase database. As we don't know the positions of the chairs in our current prototype, this information is assigned to random chairs in random positions around the tables to show that different chair positions can be shown. | |||
At the bottom of the screen there will also be an image of the seating area to give the user an impression of what it is like. Unfortunately we weren’t able to take these pictures due to the coronavirus. | |||
===Chair coordinate transformation=== | |||
One issue that pops up when trying to show the positions of the chairs in the app is that the coordinates of the chairs on the camera feed don't align with the coordinates they should be at on top view used in the app. This is of course the case because the perspective of the camera is different. Therefore the coordinates determined by the neural network first need to be converted to a different plane. This can be done using perspective transformation. | |||
To illustrate this we can take one example image we made using our prototype: | |||
[[File:Transform1.png|400px]] | |||
[[File:Transform2.png|400px]] | |||
In this image the neural network has detected several chairs and knows their position on the camera feed. For this example we will only take the upper table and the surrounding chairs. To make the example clearer a simple drawing is made with only the outline of the table and the positions of the chairs. | |||
Next we make a drawing of the same table but in the view we want it in the app: | |||
[[File:Transform3.png|400px]] | |||
To find the transformation matrix of this transformation we need four coordinates, in this case the coordinates of the four corners of the table. These coordinates from both views can be used to define a transformation matrix. For this example we used the openCV module in python to get this matrix and transform the camera perspective image to the top view perspective image: | |||
[[File:Transform4.png|400px]] | |||
[[File:Transform5.png|400px]] | |||
Here the table has been converted to the right view and the chairs have been moved with them. We also added a clearer view of what the output will look like. These converted coordinates can than be used for the positions of the dots in the app. | |||
Obviously this transformation matrix is not the same for every room or area. Therefore this matrix will need to be calculated and hard-coded in the app or neural network for every room or area. The time it takes to do this is however very little as you only need to input the corner coordinates once during setup and, if we assume the cameras never move, this won't need to be changed afterwards. Perspective transformation is therefore a solid solution to this problem. | |||
===Requirements of the user interface=== | |||
{| border=1, style="border-style: solid; border-width: 1px;" cellpadding="3" | |||
!style="text-align:left;"| Id | |||
!style="text-align:left"| Description | |||
!style="text-align:left;"| MoSCoW | |||
|- | |||
| A1 || The app can retrieve the number of empty chairs for each area from the database. || Must have | |||
|- | |||
| A2 || The app has a refresh button that can retrieve the newest information on command. || Must have | |||
|- | |||
| A3 || The app can display the information of the number of free chairs on the relevant pages. || Must have | |||
|- | |||
| A4 || The app can display the information of the positions of free chairs and occupied chairs on the relevant pages. || Must have | |||
|- | |||
| A5 || The app can display the extra information about the chairs in an area if the user desires this. || Must have | |||
|- | |||
| A6 || The user can find their way through the pages to the intended area of the app without needing any outside guidance. || Must have | |||
|- | |||
| A7 || The user can understand the information about the number of chairs shown on the first 3 levels of the app. || Must have | |||
|- | |||
| A8 || The user can understand the information about the positions of free chairs and occupied chairs on the relevant pages of the app. || Must have | |||
|- | |||
| A9 || The app must be readily available to all TU/e users without much effort with installation. || Must have | |||
|- | |||
| A10 || The android app is accessible to everyone with a TU/e login and not to anyone else. || Could have | |||
|- | |||
| A11 || The app has all areas with available chairs on campus in the database. || Could have | |||
|} | |||
===Requirement Testing=== | |||
A1 | |||
* Testing plan: Open the app and navigate to a screen which shows the number of available chairs in an area. Check if the number shown in the app is the same as the number that's currently in the database. | |||
* Results: The number shown in the app is the same as the number in the database. | |||
A2 | |||
* Testing plan: Open the app and navigate to a screen which shows the number of available chairs in an area. Manually change the number in the database and then press the refresh button in the app. Check if the number shown in the app updates accordingly. | |||
* Results: The number shown in the app changed to the new number in the database. | |||
A3 | |||
* Testing plan: Open the app and navigate to a screen which shows the number of available chairs in a room. Check if the number shown in the app is the same as the number that's currently in the database. Then go a level back and check the number of rooms in an entire area and an entire building. Check whether the number are added up correctly. | |||
* Results: The number shown in the app is the same as the number in the database. It also adds the numbers up correctly. | |||
A4 | |||
* Testing plan: Open the app and navigate to a screen which shows the vacant and occupied chairs in a room. Check if the number of vacant and occupied chairs shown are the same as the numbers in the database. Also check whether the positions of the dots are in the right position on the screen. | |||
* Results: The numbers of vacant and occupied chairs shown in the app are the same as the numbers in the database. The positions of the dots are however at the moment randomly decided. As the prototype can currently not yet detect the positions of the chairs, the dots are placed at random positions around the tables. The positions are realistic but not accurate. It does however show that the system is capable of placing the dots at the right positions if this information were given. | |||
A5 | |||
* Testing plan: Open the app and navigate to a screen which has a information button. Click on the information button and check whether a information panel pops up with the right information. | |||
* Results: An information panel pops up when the information button is pressed. The information shown in the panel corresponds to the right area. | |||
A6 | |||
* Testing plan: Let test users try the app and see whether they understand how to navigate through the app to the right screen. | |||
* Results: All test users understood that on the first screen, the different building were buttons and could be pressed to navigate to that building. The screens with buttons showing different rooms and levels were also clear for all test users. Finally, all test users noticed the back button in the top left corner and understood its purpose. | |||
A7 | |||
* Testing plan: Let test users try the app and see whether they understand that the numbers shown on the different levels correspond to the number of vacant chairs in that area. | |||
* Results: As the test users knew the purpose of the app, it was clear to them that the numbers showed the available chairs. | |||
A8 | |||
* Testing plan: Let test users try the app and see whether they understand that the red and green dots correspond to vacant and occupied chairs at their positions. | |||
* Results: All test users realized that the positions of the dots around the tables corresponded to the positions of the chairs. They also realized that the green dots were vacant chairs. However, not all test user understood that the red dots were occupied chairs and were wondering what they meant. Maybe some sort of legend should be added to these screens to clear that up. | |||
A9 | |||
* This can not be tested at the moment, but it should be clear that if this app were uploaded to a public app store for free, every member would have access to it. | |||
A10 | |||
* This is also something that has not been implemented in the current prototype. | |||
A11 | |||
* Also not the case in the current prototype, but this could easily be implemented without issues. | |||
==Neural Network== | ==Neural Network== | ||
===Using the Yolo Algorithm=== | |||
The first thing that we thought of when the discussion of detecting objects came, was a Neural Network. In order to detect an object you need powerful type of algorithms that can classify that object, attributing it a label, which in our case is the name of "chair" and its states "empty" or "occupied". | |||
The chosen programming language was Python due to its vast Neural Network community and due to is clear and easier to read syntax. | |||
Building a Neural Network can be done in 2 ways: | |||
* Either create your own model, with your own functions and mathematic formulas behind | |||
* Either use an existing model and update in such a way to make it useful for your desired task. | |||
Due to lack of time to create our own Neural Network model, we chose the second option. | |||
In recent years, deep learning techniques are achieving state-of-the-art results for object detection, such as on standard benchmark datasets and in computer vision competitions. Notable is the “You Only Look Once,” or YOLO, family of Convolutional Neural Networks that achieve near state-of-the-art results with a single end-to-end model that can perform object detection in real-time. | |||
YOLO is a clever convolutional neural network (CNN) for doing object detection in real-time. The algorithm applies a single neural network to the full image, and then divides the image into regions and predicts bounding boxes and probabilities for each region. These bounding boxes are weighted by the predicted probabilities. | |||
YOLO is popular because it achieves high accuracy while also being able to run in real-time. The algorithm “only looks once” at the image in the sense that it requires only one forward propagation pass through the neural network to make predictions. After non-max suppression (which makes sure the object detection algorithm only detects each object once), it then outputs recognized objects together with the bounding boxes. | |||
With YOLO, a single CNN simultaneously predicts multiple bounding boxes and class probabilities for those boxes. YOLO trains on full images and directly optimizes detection performance. | |||
In this project we are using Yolo in order to identify the empty chairs of a classroom. | |||
The classification is done as follows: | |||
The chairs can be: | |||
* Empty | |||
* Occupied | |||
These two tags are attributed to the chairs after the following criteria: | |||
* If the chair is clean (it does not have anything in front of it or on it) then the chair is empty | |||
* If the chair is empty and someone puts an object in front of it, or sits on the chair, then the chair became occupied | |||
There also exists a small problem, which is that the algorithm does not know at its first look if where is a person there is also a chair. It has to see a chair first in order to give its tag. | |||
===Requirements of the model=== | |||
The model requires multiple objects to be identified accurately in order to function properly. Therefore, we have defined “accurately” in the requirements below as at least 80% percent for our project, where a proof of concept is the most important goal. For the theoretical application of our product a higher accuracy will be necessary. As an example, the Metaforum library has 950 study seats in total. In order to accurately inform users through the app that all these seats are occupied, an accuracy of over 99,9% would need to be achieved. It is true that such an accuracy would be more than enough for each individual chair, as it would be acceptable if only one in a thousand times a user is misled to a supposedly vacant chair that turns out to be occupied. However, when we consider all of the seats in the library together, a false-positive rate of just one in a thousand would still mean that there will on average be one chair available at all times when in reality each chair is occupied. Therefore the accuracy of the model should either be improved considerably or different measures need to be taken to improve the false-positive rate. A possible solution for this would be to let the model analyze multiple frames before determining the status of the chair and sending it to the database. This way a false-positive for a single frame won't immediately lead to a wrong chair count. In order to make this work the algorithm needs to remember chairs across multiple frames and link them as the same entity, which is beyond the scope of this project. | |||
We used the MoSCoW method for assessing the importance of every requirement. In the following table, "must have" means that the requirement in question is a mandatory requirement. Without it, the product does not work. "Should have" means that the product will run more efficiently or more smoothly with that requirement, but the product still works without it. "Could have" means that the requirement in question was possible to have without various constraints preventing it (time, computational power, etc.). Having the requirement in question will make the product more refined, but it works fine without it. "Won't have" means that the product will not work with the requirement in question. | |||
{| border=1, style="border-style: solid; border-width: 1px;" cellpadding="3" | |||
!style="text-align:left;"| Id | |||
!style="text-align:left"| Description | |||
!style="text-align:left;"| MoSCoW | |||
|- | |||
| M1 || The model accurately identifies empty chairs, taken chairs, people and laptops || Must have | |||
|- | |||
| M2 || The model accurately identifies miscellaneous objects that indicate a taken chairs, such as jackets, books or notebooks || Could have | |||
|- | |||
| M3 || The model accurately flags chairs with and without a person on it respectively as taken and available (if there are no other objects) || Must have | |||
|- | |||
| M4 || The model accurately flags chairs with and without laptops in front of it respectively as taken and available || Must have | |||
|- | |||
| M5 || The model runs in a loop and processes new images from the camera feed || Must have | |||
|- | |||
| M6 || The model processes at least 1 frame every 10 seconds from the camera feed || Should have | |||
|- | |||
| M7 || The model saves the number of empty chairs found for each area in a database in the cloud. || Must have | |||
|- | |||
| M8 || The model updates the database with this information at least once every 10 seconds || Should have | |||
|- | |||
| M9 || The model keeps track of objects that have been recognized as people. || Won't have | |||
|- | |||
| M10 || The model recognizes people's faces. || Won't have | |||
|} | |||
===Test Plan=== | |||
(This was our original plan before the Covid-19 outbreak made it impossible to fully perform. We will therefore only be able to perform a restriced version of the test plan that focusses more on validating the individual requirements) | |||
In order to confirm whether we have met our algorithm and user interface requirements the following test plan has been made. We have decided to use one of the OGO rooms in gemini north to test our application. In these rooms one of our laptops can easily be mounted in one of the corners of the room, close to the roof. This laptop will have its camera pointed towards the table below and will have the algorithm running on the images from the camera feed. | |||
We plan to make 10 short videos of 30 seconds with all five of us using the room in a variety of scenarios: | |||
*Sitting on chair with laptop | |||
*Sitting on chair without laptop | |||
*Sitting on chair with notebooks | |||
*Different sitting positions (straight/sloppy) | |||
*Walking out of the room | |||
*Walking into the room | |||
*Walking/standing still around the chairs | |||
*Repositioning the chairs | |||
Since our accuracy requirement was 80%, 8 out of 10 chairs need to be correctly identified as occupied or empty. The frames that were analyzed during the testing videos are also saved, so that we can later check how accurate the algorithm was. Additionally, it is also required that the amount of chairs available in the room also needs to be correctly calculated 80% of the time. Since there are multiple chairs, this requirement will most probably be harder to meet, which is necessary, as the amount of free chairs in an area is what is ultimately communicated to the user in our application and this should therefore be the main measure of accuracy. The app will be used to check the amount of free chairs calculated, thereby also validating the correct functioning of the database, where the information is stored and the app that displays the information and can be used to refresh it. | |||
===Test Results=== | |||
Unfortunately, due to the Covid-19 pandemic, we were not able to carry out our original test plan. The amount of footage we had to test our model requirements was limited to the "test" footage we shot before the pandemic. This footage consists of one video and some pictures. The video is about us sitting on chairs at tables with laptops in front of us and also walking around the room for a little bit to switch places. The pictures mainly consist of empty chairs at the table. This was shot in a OGO meeting room in Gemini-South. However, luckily enough the footage was good enough to confirm that every model requirement that was categorised as "Must have" has been met. This means that the model of the prototype was successful, according to our model requirements. If the pandemic did not take place, we would have wanted to shoot more appropriate videos in the same room to test everything else as well, but this unfortunately was not possible. | |||
===Detection Steps=== | |||
In order to manage to complete our final goal I decided to take the following approach in the code: | |||
First I had to be sure that the algorithm was able to detect 3 class in our frames: persons, chairs, and laptops because in a optimal environment, I concluded that these 3 classes can provide you a good model of occupied/unoccupied chairs. This will be discussed in the "Future Improvements"' subsection. | |||
In order to detect these specific classes, the Neural Network was trained in the cloud to get the optimal values of its weights and global parameters. After this an own model was created, using the Yolo method in order to find and display the results. | |||
Regarding the Yolo method, it has the following traits: | |||
* It take only one run of a frame in order to give a result. This implies that: | |||
* It trades quality of the result for performance or vice-versa. This means that if you change the input image of the algorithm form 416x416 pixels to 608x608 then the result will be better(a bigger image means a higher quantity of pixels from which you extract the features) but the performance will be lowered. | |||
This can be seen here in the first photo. Input image resolution was 416x416 | |||
[[File:cb.jpeg | 300px]] | |||
After the Neural Network was traded and the classes were identified, a start on the Classification problem has been made, which stated "How does the algorithm knows that a chair is occupied or not?" | |||
For this, the approach was a follows: | |||
* When computing the classes, we also save the number of items found of that specific class | |||
* When computing the coordinates of the framing boxes also compute and store coordinates of the centers of the objects | |||
* When the framing boxes are drawn also draw the center of the centers | |||
This me approach gave me the possibility to see each frame box ore clear and prepared the data to be classified. | |||
The classification was done as follows: | |||
* For each of the laptops detected | |||
**For each of the chairs detected | |||
****Compute the score between the the laptop and each of the chairs | |||
****Take only store the coordinates of the center of the chair that has the minimum score | |||
**Draw the line between the laptop and the chair | |||
**If the selected chair is already take by a laptop then take the chair that has the next minimum score | |||
The first iteration of the score formula was as follows: | |||
* Score = ceil((chair[0] - laptop[0])^2 + (chair[1] - laptop[1])^2) | |||
Where the chair and laptop a list of 2 elements: | |||
* First element [0]: the x coordinate of the chair's/laptop's center | |||
* Second element [1]: the y coordinate of the chair's/laptop's center | |||
The progress can be see in the following 3 images, where the last one has its input image resolution increased to 608x608 pixels in order to get much more information processed | |||
[[File:ci1.png | 450px]] | |||
[[File:ci2.png | 450px]] | |||
[[File:cf.jpeg | 450px]] | |||
Regarding the third variable in our process, the class of persons increases the difficulty of the object identification and classification. | |||
This can be seen in the following image that has a input image resolution of 608x608. | |||
[[File:cip.png | 450px]] | |||
The problem appears when a person is sitting on a chair but this we be debated in the subsection '''Future Improvements''' and in '''Problems encountered , solutions and workarounds''' | |||
===Data Classification=== | |||
The classes that our model can detect are as follows: | |||
person | |||
bench, | |||
backpack, | |||
umbrella | |||
handbag, | |||
suitcase, | |||
bottle, | |||
cup, | |||
fork, | |||
knife, | |||
spoon, | |||
banana, | |||
apple, | |||
sandwich, | |||
orange, | |||
chair, | |||
dining table, | |||
laptop, | |||
mouse, | |||
keyboard, | |||
cell phone, | |||
book, | |||
clock, | |||
scissors, | |||
The main 3 classes on which we are focusing, in order to prove our concept, are: chair, person and laptop | |||
We chose these 3 classes, because in an optimal environment to prove our concept, a student is coming to the classroom only with his/her laptop and either places the laptop on the table in order to take seat for himself for later or he sits on the chair and places the laptop on the table. | |||
Furthermore, a student can only sit on a chair thus occupying it. | |||
These are our 2 optimal case on which we focus to prove our proof of concept. | |||
===Problems encountered , solutions and workarounds=== | |||
'''Third class problem''' | |||
During the development of the algorithm, the following problems were encountered. | |||
The first problem was the presence of the persons: | |||
* A person can either sit on a chair | |||
* A person can stay near the table | |||
The problem was that if a person would sit on a chair, then that chair would be obstructed by the person and it would not be recognized by the algorithm. | |||
The solution of this problem was as follows. | |||
First, our algorithm assumes 2 things: | |||
* The number of the initial chairs from a classroom is known | |||
* Then number of chairs is fixed so no one can bring a chair with him from another classroom | |||
Secondly, whenever there are persons in the room, we estimate the total number of the empty chairs as follows: | |||
* Let n be the number of total chairs present in the classroom from the beginning. | |||
* Then after the algorithm complete the classification of the objects, the total number of occupied chairs is as follows: | |||
average_h_l = math.ceil((len(center_of_persons) + len(center_of_laptops))/2) | |||
estimated_value_of_occupied_chairs = math.ceil((len(chairsVisited) + average_h_l) / 2) | |||
After finding the estimated_value_of_occupied_chairs we can compute the estimated number of empty chairs | |||
emptyChairs = total_number_of_chairs - estimated_value_of_occupied_chairs | |||
These values estimate the real world behavior of a normal meeting group. Most of the assumptions will be checked via the questionnaire. | |||
= | '''Playback problem''' | ||
Another problem that we have encountered is the playback rate of the algorithm running on a video. | |||
The video can either be a live feed, either a video format file (.mp4, .vmw, etc) | |||
The solution for this has been discussed and stated as follows: | |||
* In order to check the state of the room(the state meaning how is everyone sited and where are the objects placed) we are checking one the 50th frame from a video thus from a video of 30 seconds recorded in 60fps(thus 1800 frames) we check only 36 frames distributed evenly, thus gaining some performance. | |||
===Future Improvements=== | |||
Future improvements can be done regarding 4 things: | |||
* Managing to find a accurate way in order to determine the solution for the '''Third class problem''' | |||
* Updating the classification problem with ore than 3 classes such as: books, pens, pencils, notebooks etc. | |||
* Finding a good way to save the real position of the chairs | |||
* Moving from notebook to cloud computing | |||
Regarding the '''Third class problem''' one improvement can be as follows: | |||
* Starting the algorithm before the students are present in the room and string the position of the chairs | |||
* Running a separate Neural Network that focuses only on persons and can identify if a person is either standing either is sit | |||
* If a person is sit on a chair then the result of these 2 Neural Networks will conclude that the person sits on that chair. | |||
Regarding the Classification problem an improvement can be done as follows | |||
* Taking into account more than 3 classes. | |||
* Adding more classes can increase the accuracy of the model | |||
* This technique increases the complexity of the model because then your cases will increase exponentially. | |||
* A better algorithm must be developed in order to link multiple object between them that will result in a occupied chair | |||
Regarding the third improvement a solution can be: | |||
* Using a TOF sensor, in order to measure the real world distances between the chairs and between the chairs and the tables and so on. | |||
* With this you could make an accurate map in the app and show exactly which chiar is placed where and which chair is occupied. | |||
Regarding the 4th and final improvement the solution is as it states. Moving our algorithm from our stationary pc(in our case my laptop) to the cloud will give us much more computational power. Thus moving from 0.5 fps playback on a random .mp4 file to more than real time detection. | |||
=IoT appliance= | |||
==What is IoT ?== | |||
The Internet of things (IoT) is a system of interrelated computing devices, mechanical and digital machines provided with unique identifiers (UIDs) and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction. | |||
The definition of the Internet of things has evolved due to the convergence of multiple technologies, real-time analytics, machine learning, commodity sensors, and embedded systems. Traditional fields of embedded systems, wireless sensor networks, control systems, automation (including home and building automation), and others all contribute to enabling the Internet of things. In the consumer market, IoT technology is most synonymous with products pertaining to the concept of the "smart home", covering devices and appliances (such as lighting fixtures, thermostats, home security systems and cameras, and other home appliances) that support one or more common ecosystems, and can be controlled via devices associated with that ecosystem, such as smartphones and smart speakers. | |||
==Where is our system situated== | |||
The requirements of our systems are a room or an open space area and the infrastructure of video surveillance. | |||
Our system sis an algorithm that runs on a set of cameras(at least 1) and by using machine learning techniques, it can determine whether or not there are unoccupied chairs in the current room. | |||
==Model and design== | |||
Regarding the design and the model of our system, our system uses the following design and model: | |||
===Design=== | |||
* A Raspberry Pie that is powered by an external power bank . | |||
* A camera connected to the Raspberry Pi | |||
* The classification algorithm that is running on the Raspberry Pi | |||
* The connection of the Raspberry with the Firebase Database Instance. | |||
* The connection of the Firebase Database Instance with the Android App. | |||
* The Android App. | |||
[[File:An1.jpg | 850px]] | |||
===Model's functionality=== | |||
In this subchapter will be discussing the base functionalities that each component of the system has to be able to complete. | |||
*'''The camera functionality:''' | |||
** It's main purpose is to take the live feed as frames and sent to the main processing unit on Raspberry every 60th frame in order to be processed. | |||
*'''The Raspberry functionalities:''' | |||
** It represents the main computational power of the entire system. | |||
** It's functionality is to be a bridge between the camera, the result of the classification algorithm and the firebase database. | |||
*'''The Classification algorithm functionalities:''' | |||
** Correctly determine the total number of the occupied chairs. | |||
** Correctly determine the objects present in the room in order to make the classification as unbiased as possible. | |||
*'''The Database functionality:''' | |||
** It's main role is to store the data in an understandable manner and provide an instant refresh capability. | |||
*''The Android app's functionality:'' | |||
** It's main role is to retrieve the data from the database and present it to the user in such a way that he/she will be able to determine if a room has or hasn't an empty chair for him. | |||
'''How the system works''' | |||
The camera is taking a constant feed of the room in which the system is placed. Every 60th frame of the live feed, is computed by the classification algorithm. The algorithm will find the following 3 classes in the frame: chair, person and laptop. (We considered that this was the necessary number of classes in order to prove our concept) | |||
After it identifies the classes present in the scene, the algorithm will start the process of constructing the occupied chairs by using the formulas stated in the''' Neural Network''' chapter. | |||
Furthermore, the algorithm will sent the following values to the database: number of occupied chairs, number of free chairs, and the rest of the chair data. If there will be some values already present in the database, the the algorithm will just update them. This process will be done once every 5 seconds. | |||
When the app is started, it will check if there was somethin changed in the database then it will pull the data and display to the user. | |||
=Privacy Policy= | |||
The Seat Finder app is built as a free app. This app is provided by us at no cost and is intended for use as is. | |||
This section is used to inform visitors regarding our policies with the collection, use, and disclosure of personal information if anyone decides to use the Seat Finder app. | |||
If you choose to use the Seat Finder app, then you agree to the collection and use of information in relation to this policy. The personal information that we collect is used for providing and improving the service. We will not use or share your information with anyone except as described in this Privacy Policy. | |||
1. Information Collection and Use | |||
For a better experience, while using our Service, we may require you to provide us with certain personally identifiable information. The information that we request will be retained on your device and is not collected by us in any way. The app may use third party services that may collect information used to identify you. | |||
2. Log Data | |||
We want to inform you that whenever you use the Seat Finder app, in a case of an error in the app, we collect data and information on your phone called Log Data. This Log Data may include information such as your device Internet Protocol (“IP”) address, device name, operating system version, the configuration of the app when utilising the Seat Finder app, the time and date of your use of the Seat Finder app, and other statistics. | |||
3. Cookies | |||
We use cookies and similar tracking technologies to track the activity on our Service and we hold certain information. Cookies are files with a small amount of data which may include an anonymous unique identifier. Cookies are sent to your browser from a website and stored on your device. Other tracking technologies are also used such as beacons, tags and scripts to collect and track information and to improve and analyse our service. You can instruct your browser to refuse all cookies or to indicate when a cookie is being sent. However, if you do not accept cookies, you may not be able to use some portions of our Service. | |||
Examples of Cookies we use: | |||
*Session Cookies: We use Session Cookies to operate our Service. | |||
*Preference Cookies: We use Preference Cookies to remember your preferences and various settings. | |||
*Security Cookies: We use Security Cookies for security purposes. | |||
4. Service Providers | |||
We may employ third-party companies and individuals due to the following reasons: | |||
*To facilitate our the Seat Finder app; | |||
*To provide the Seat Finder app on our behalf; | |||
*To perform the Seat Finder app-related services; | |||
*To assist us in analyzing how the Seat Finder app is used; or | |||
*With your consent in any other cases; | |||
We want to inform users of this Service that these third parties have access to your Personal Information. The reason is to perform the tasks assigned to them on our behalf. However, they are obligated not to disclose or use the information for any other purpose. | |||
5. Security | |||
We value your trust in providing us your Personal Information, thus we are striving to use commercially acceptable means of protecting it. But remember that no method of transmission over the internet, or method of electronic storage is 100% secure and reliable, and we cannot guarantee its absolute security. | |||
6. Children’s Privacy | |||
These services do not address anyone under the age of 13. We do not knowingly collect personally identifiable information from children under 13. In the case we discover that a child under 13 has provided me with personal information, we will immediately delete this from our servers. If you are a parent or guardian and you are aware that your child has provided us with personal information, please contact us so that we will be able to do necessary actions. | |||
7. Changes to This Privacy Policy | |||
We may update our Privacy Policy from time to time. Thus, you are advised to review this page periodically for any changes. We will notify you of any changes by posting the new Privacy Policy on this page. These changes are effective immediately after they are posted on this page. | |||
8. In the Event of Sale or Bankruptcy | |||
The ownership of the Site may change at some point in the future. Should that occur, we want this site to be able to maintain a relationship with you. In the event of an (actual or potential) sale, merger, public offering, bankruptcy, acquisition of any part of our business, or other change in control of the Seat App, your user information may be shared with the person or business that owns or controls (or potentially will own or control) the app, provided that we inform the buyer (or prospective buyer) that it must use your user information only for the purposes disclosed in this Privacy Policy. | |||
9. Your right to information, correction, deletion and disclosure of your data | |||
In accordance with legal provisions, you have the right to correct, delete, and block your personal data. Additionally, you have the right to obtain the following information from us at any time: | |||
*Which of your personal data we store | |||
*What our purpose for storing this data is | |||
*Requesting the origin and recipient, or recipient category of this data. | |||
If you wish to perform any of the aforementioned actions with your data, please contact us with the contact information provided in section 9. | |||
10. Contact Us | |||
If you have any questions, requests and/or suggestions about our Privacy Policy, do not hesitate to contact us at [Group 12 contact information]. | |||
=Logbook= | =Logbook= | ||
Line 315: | Line 1,003: | ||
!style="text-align:left;"| Total time spent | !style="text-align:left;"| Total time spent | ||
|- | |- | ||
| Boris || Meeting (0.5), Update planning (0.5), Clean up state-of-the-art (0.5), Group Discussion (2) || 3.5 | | Boris || Meeting (0.5), Update planning (0.5), Clean up state-of-the-art (0.5), Group Discussion (2), App Creation (8) || 11.5 | ||
|- | |||
| Horea || Meeting (0.5), Group Discussion (2), Neural Network Creation (6), Learning to create the Neural Network(4)|| 12.5 | |||
|- | |||
| Jelle || Meeting (0.5), User Requirements and questionnaire creation (4), Group Discussion (2) || 6.5 | |||
|- | |||
| Roy || Meeting (0.5), Keep in Contact with Peter Engels (0.5), Group Discussion (2), Design interface (7) || 10 | |||
|- | |||
| Winston || Group Discussion (2), write rules and regulations, mostly the chairs part (4)|| 6 | |||
|} | |||
==Week 3== | |||
{| border=1, style="border-style: solid; border-width: 1px;" cellpadding="3" | |||
!style="text-align:left;"| Name | |||
!style="text-align:left"| Activities (hours) | |||
!style="text-align:left;"| Total time spent | |||
|- | |||
| Boris || Meeting (0.5), Group Discussion (0.5), Contact Engels (0.5), App Creation (10) || 11.5 | |||
|- | |||
| Horea || Meeting (0.5), Group Discussion (0.5), Implementing Yolo object detection on live feed (5) || 6.5 | |||
|- | |||
| Jelle || Meeting (0.5), Group Discussion (0.5), Survey development (5) Contact Engels (0.5) || 6.5 | |||
|- | |||
| Roy || Meeting (0.5), Group Discussion (0.5), Design interface (5), Creating Mockups (2) || 8 | |||
|- | |||
| Winston || Meeting (0.5), Group Discussion (0.5), Contact Engels (0.5), adjust rules and regulations, mostly rooms (5) || 6.5 | |||
|} | |||
==Carnaval Holiday== | |||
{| border=1, style="border-style: solid; border-width: 1px;" cellpadding="3" | |||
!style="text-align:left;"| Name | |||
!style="text-align:left"| Activities (hours) | |||
!style="text-align:left;"| Total time spent | |||
|- | |||
| Boris || App Creation (3), Update Wiki (1), Discussing mockups with Roy (0.5) || 4.5 | |||
|- | |||
| Horea || Creating the database(3), Linking the database to the Neural Network(3), Finalizing the Frameowork (6), Update Wiki(1) || 13 | |||
|- | |||
| Jelle || Asking student outside our group for survey improvement (1), Survey development and layout (3), Researching survey analysis (3) Update wiki (1) || 8 | |||
|- | |||
| Roy || Searching for floor plans (0.5), Discussing mockups with Boris (0.5), Making disregarded mockups(4), Writing Wiki (1) || 6 | |||
|- | |||
| Winston || Adjusted Rules and Regulations (rooms), mostly punishment part (3.5) ; Asked people from other universities what rules and conditions apply (room reservations) and some online searching (3), research on privacy policy (2) || 8.5 | |||
|} | |||
==Week 4== | |||
{| border=1, style="border-style: solid; border-width: 1px;" cellpadding="3" | |||
!style="text-align:left;"| Name | |||
!style="text-align:left"| Activities (hours) | |||
!style="text-align:left;"| Total time spent | |||
|- | |||
| Boris || Meeting (0.5), Meeting BookMySpace (1), Group Meeting (1.5), App Development (11), Update Wiki (1) || 15 | |||
|- | |||
| Horea || Group Meeting (1.5), Updating the Model (5), Creating the Occupied Chair Classification (5), Linking the Final Model to the database (1), Polishing the code (6) || 18,5 | |||
|- | |||
| Jelle || User interface and model requirements for testing (6), Survey development (1), Survey testing (2), Survey analysis research (1.5), Group Meeting (1.5) || 12 | |||
|- | |||
| Roy || Meeting (0.5), Meeting BookMySpace (1), Writing SoA Planon (2), Adding Design Interface (0.5), Making Floor Plan MF 0 (9), Writing Wiki (0.5) || 12.5 | |||
|- | |||
| Winston || Meeting (0.5), Meeting BookMySpace and finishing the notes (2), Group Meeting (1.5), reviewed the wiki (1.5), continuing Privacy Policy (6) || 11.5 | |||
|} | |||
==Notes Meeting BookMySpace== | |||
*Pilots have been done in Meta (for about half a year) to prevent empty rooms from being on reserved. They wanted to test if 15 minutes of no movement in a room was a good way decide if a room should be set to available or not (they used movement detectors). It worked alright but there were some drawbacks (examples: some people don’t move a lot during studying or if someone wants to grab something to eat or drink it would also set the room to available after 15 min). | |||
*At the moment they are also looking at a new sensor from Philips. They have a sensor that can measure body heat and some other things (to prevent various problems of the motion sensor). The problem with this, is that it costs a lot of money, which is also why they didn’t couldn’t implement sensors for each reservable study/workplace. | |||
*Maybe it is possible to combine Planon with our project (but this is more for later if possible, probably not since we only have about 4 weeks left). | |||
*The Planon app can already find available workspaces to study or work at. But you need to reserve it (ours can also be used if you just want to find an available spot somewhere in, for example, the library). But they are still trying to improve it (not really specified on how they’re improving it iirc). | |||
*Apparently, there is not a shortage of study places/workplaces in general, but a shortage in study/workplaces in Metaforum specifically. This is likely because a lot people just prefer to study in that specific building (could be due to the building being relatively silent and there are comfortable to study at). | |||
*They focused more on the tables themselves instead of the chairs. Sometimes a chair might be somewhere where there is no workplace and you also don’t know to which place the chair belongs to. But if there is an area with a lot of occupied chairs and an area with almost no occupied chairs on the map, you can probably assume that the latter has some free study/workplaces somewhere there. | |||
*Some people claim more than one chair by putting their possessions on them. We can try to figure something out for that. | |||
*Currently, there are no real consequences if you don’t follow the social norms. Also, having a lot of consequences for people who don’t show up often (or who violate any of the rules) makes it more difficult to implement it. | |||
*We could add more information to the building/environment/study place on the map/interface (for example, if the study place has electricity sockets or if it’s silent environment). | |||
*Available study/workplaces (the ones with a QR code) can only be reserved for 2 hours (ARBO law). | |||
*We could make it harder for people to not show up by making them invite other people. So, one person can reserve a room for up to 2 hours but if they invite other people, they can get 1,5 hours extra for each additional person for example. | |||
*Notify someone about our end presentation and wiki with an email. | |||
*We could use the system for finding spaces in the canteen | |||
==Week 5== | |||
{| border=1, style="border-style: solid; border-width: 1px;" cellpadding="3" | |||
!style="text-align:left;"| Name | |||
!style="text-align:left"| Activities (hours) | |||
!style="text-align:left;"| Total time spent | |||
|- | |||
| Boris || Meeting (0.5), Group meeting (3), App Creation (9), Update Wiki (0.5) || 13 | |||
|- | |- | ||
| Horea || | | Horea || Group meeting (3) , Studying Machine Learning for optimization(6), Optimizing the code where able(6)|| 15 | ||
|- | |- | ||
| Jelle || Meeting (0.5), Group | | Jelle || Meeting (0.5), Group meeting (3), Test Plan (4), adjust requirements (2) || 9.5 | ||
|- | |- | ||
| Roy || Meeting (0.5), | | Roy || Meeting (0.5), Group meeting (3), Struggling with PC* (4) || 7.5 | ||
|- | |- | ||
| Winston || Group | | Winston || Meeting (0.5), Group meeting (3), Test Plan (4), adjust requirements (2)|| 9.5 | ||
|} | |} | ||
* Due to a problem while installing linux on a external hard disk I had to partially reset my pc so had to reinstall some programs to get back up and running for the project | |||
==Week 6== | |||
{| border=1, style="border-style: solid; border-width: 1px;" cellpadding="3" | |||
!style="text-align:left;"| Name | |||
!style="text-align:left"| Activities (hours) | |||
!style="text-align:left;"| Total time spent | |||
|- | |||
| Boris || Coordinate transformation (5), Update Wiki (1), App creation (2), Group discussion (2), Interface requirements and testing (2) || 12 | |||
|- | |||
| Horea || Group discussion (2), Repairing the RaspberyPy(10), Configuring the RaspberyPy(10) || 22 | |||
|- | |||
| Jelle || questionnaire distribution (1.5), User requirements and test plan (3.5), Group discussion (2) || 7 | |||
|- | |||
| Roy || Mockup creation (4), Group discussion (2), Rewriting / Finalizing Design Choices (4), Updating Wiki (1) || 11 | |||
|- | |||
| Winston || Revised wiki (mainly privacy policy) (2), asked people to fill in the questionnaire (1), adjusting test plan (3), Group discussion (2) || 8 | |||
|} | |||
==Week 7== | |||
{| border=1, style="border-style: solid; border-width: 1px;" cellpadding="3" | |||
!style="text-align:left;"| Name | |||
!style="text-align:left"| Activities (hours) | |||
!style="text-align:left;"| Total time spent | |||
|- | |||
| Boris || Meeting with Tijn (0.5), Group Meeting (1.5), Further Group Discussion (0.5), App Testing (2), App Creation (1), Make Testing Videos (1), Overall Wiki Check (1), PowerPoint Presentation (2) || 9.5 | |||
|- | |||
| Horea || Meeting with Tijn (0.5), Group Meeting (1.5), Further Group Discussion (0.5), Algorithm Testing(2), Make Testing Videos(2), Presentation Record + Video Edited(4)|| 10.5 | |||
|- | |||
| Jelle || Meeting with Tijn (0.5), Group Meeting (1.5), Further Group Discussion (0.5), Survey analysis (4), Rewriting wiki (2), Requirements (1,5) Survey distribution (1) || 11 | |||
|- | |||
| Roy || Meeting with Tijn (0.5), Group Meeting (1.5), Further Group Discussion (0.5), System Design choices (4), Recommended system (4) || 10.5 | |||
|- | |||
| Winston || Meeting with Tijn (0.5), Group Meeting (1.5), Further Group Discussion (0.5), Asking for more respondents (1), Work out results (4), Wiki writing (1), start PowerPoint (1) || 9.5 | |||
|} | |||
==Week 8== | |||
{| border=1, style="border-style: solid; border-width: 1px;" cellpadding="3" | |||
!style="text-align:left;"| Name | |||
!style="text-align:left"| Activities (hours) | |||
!style="text-align:left;"| Total time spent | |||
|- | |||
| Boris || Tutor meeting (0.5), Groupmeeting (2) || 2.5 | |||
|- | |||
| Horea || Tutor meeting (0.5), Groupmeeting (2) || 2.5 | |||
|- | |||
| Jelle || Tutor meeting (0.5), Groupmeeting (2), Final wiki check (1), Rewriting USE (2), Requirements (2) || 7.5 | |||
|- | |||
| Roy || Tutor meeting (0.5), Wiki editing (1), Rooms rewrite (2), Groupmeeting (2), Rewriting + Wiki editing (0.5) || 6 | |||
|- | |||
| Winston || Tutor meeting (0.5), Groupmeeting (2), Wiki editing (1), Test results (1), Questionnaire text (1) || 5.5 | |||
|} | |||
== Peer Review== | |||
For the peer review we have decided that the group members will all get the same mark. Some people might have written less than others but invested their time and effort in other things. Others might have done a bit more but had more problems on delivering it on time or communicating. So, in total with everything that happened we have decided that everyone will get the same mark. | |||
=References= | =References= | ||
<references /> | <references /> |
Latest revision as of 17:27, 7 April 2020
Group Members
Name | ID | Major | |
---|---|---|---|
Deliverables
- Presentation: https://docs.google.com/presentation/d/1iAvQ0Z0fLYO_gdYZlJpNcMgUN7GqepjbUoVi02OU4tI/edit?usp=sharing
- Video presentation: https://www.youtube.com/watch?v=wjVsYjUPT3s Sorry for the watermark, this was an oversight on our part and we were unable to remove it and we were not able to re-record the video
- Demonstration: https://youtu.be/lkvP9rBYgNc
Subject
A real-time camera-based recognition device using capable of identifying vacant seats in areas with dynamic workplaces. These include areas like workspaces at Metaforum for studying, seats at a library or empty desks at flexible workplaces at a company. This information can be communicated to the users which will minimize the time and effort it takes to find a place to work.
Problem Statement
During examination weeks many student want to work and study at the workplaces in the MetaForum. However, during the day it often very busy and it might take a while to find a place to sit, costing effort and precious study time. If students knew the locations of vacant seats it would significantly reduce the amount of time it takes to find them and will probably also reduce the distance that needs to be walked, decreasing the noise for the people already studying. This same issue could arrive at various other places such as public libraries or flexible workspaces. An automatic method to determine the vacant workplaces would be ideal to deal with situations like this.
Objectives
- Libraries and other flexible workplaces
The system should be able to tell the user whether there are vacant seats available and if so, in what area.
- Room reservation
It should be able to detect whether there are people in a room and if that's not the case for a certain amount of time, it should set the room to available for reservation.
Approach
Here a number of possible approaches are described with their advantages and disadvantages. Our goal is to use the "camera-based recognition software approach", but if that fails, we have some other possible methods to achieve our goal.
Camera-based recognition software: The system uses a camera to detect empty workplaces. It can tell whether there is a person sitting at the workplace or if it’s free for other people. The camera will be installed in higher places to decrease the chance of other objects obstructing the view of the camera.
Advantages:
- Not only can it tell whether a person is sitting in a certain workplace or not, it can also tell whether a person is only taking a break or leaving the workplace for someone else to take it (by looking if the person has also taken his/her stuff with him/her)
- (Relatively) easy to install
- Limited amount is needed, since one camera (if placed right) can cover a big area, also reducing the overall costs
Disadvantages:
- Visual data of people will get captured, this means that people might feel that their privacy is violated.
- Developing an algorithm that can accurately conclude everything might become difficult
Echo location-based:
The system is based on the reflection of sound waves emitted by a sound source. The reflected sound will be different based on whether a person is sitting on the chair or not. The distance the sound has to travel is shorter if there is a person (taller than the chair) sitting on the chair.
Advantages:
- It does not capture any visual data which people might feel their privacy violated by.
- It can have quite a lot of range for one sensor, since it measures the differences between signals over time and always have something to compare.
Disadvantages:
- Other objects can deteriorate the signal if they’re close to the chair or person, making the measuring of the sound waves less accurate.
- It can only detect if there is someone in the chair, it cannot tell if the person leaves stuff on the desk indicating he or she is coming back or not.
Movement-based:
Movement based cameras can work on multiple premises, passive infrared (PIR), microwave, ultrasonic, tomographic motion detector, video camera software, gesture detector. Many of the current movement-based sensors have a combination of the two but they use the different methods to detect a movement. In general a movement based sensor can also be divided into zones which detect the movement in that zones separately.
Advantages:
- A person studying will generally move while writing, typing etc so it is easy to detect a person sitting in a chair or at a location. Which is good to detect quiet spaces.
- It can not capture any visual data which people might feel their privacy violated by depending on which detection is use.
Disadvantages:
- It can only detect movement, so if there is no movement in a certain zone it does not know if there is an actual chair at that place and it can only see there is no movement.
- A movement based sensor must have a lot of different zones for movement detection, if it is one big zone then any movement in that zone will render it as busy which makes it hard to detect empty chairs.
- Since chairs are not fixed in one location they can sit in between two zones which could render two zones as busy while 1 chair in one of those zones might still be empty which cannot be seen.
Thermographic-based / Infrared:
Thermographic-based detection focuses on the premise of the different temperatures between objects to distinguish them. Since humans, chairs, tables and floor have different temperatures a thermographic visual should be able to distinguish them based upon their temperatures.
Advantages:
- A thermographic based camera detects heat, so when a person is sitting on a chair it will detect a higher temperature which indicates that the chair is occupied, while a colder object is more likely to be a chair.
- Heat lingers when someone leaves a chair, the chair will have a higher temperature than normal since a person just sat on it and transferred heat onto it. This could be used as a sort of buffer to make sure that the chair is empty for a while before stating it as empty.
- While visual data is collected, a thermographic image will make it hard to actually identify a person which will decrease the violation of privacy people might feel.
Disadvantages:
- There probably will be a difference in the base temperature of the chair due to the difference in the weather over the year and even in a single day. A chair next to a window where the sun is shining on will probably have a higher temperature than a chair in the shadow. In the summer, unless the *temperature is really well regulated, the area in the view of the camera will have a general higher temperature than in the winter, which could make it harder to detect differences. So a lot of factors have to be incorporated into the design to even the effect
- Normal consumer thermographic cameras have a small viewing angle, and work precisely relatively close. If you want to detect objects further away the preciseness of the camera goes down so it means you must install more cameras on lower ceilings to have it accurate and it can become quite expensive.
Users, Society and Enterprise
The primary users this project will be focused on are students of our own university. After the technology has been developed for our university it could be used in other places as well. Besides the similar possibilities like other universities or public libraries, there are also different settings that our technology could be applied to. If businesses can be convinced of the usefulness of our product the software could be sold to them. This would primarily target large businesses with flexible work spaces, since it is mainly in such environments that our product could provide a substantial increase in the efficiency of the use of work spaces. However, our product will only be attractive to businesses if it is already a polished product. Because of this a corporate application would only be of concern after the university has served as a training ground and the product has been thoroughly tested and refined. If eventually our technology were to become widely adopted by companies and public institutions alike, there might also be implications for society regarding privacy. Even if the recorded footage from the cameras isn’t saved or viewed by any humans, the widespread installation of cameras might still make people feel uneasy. This could contribute to the trend of rising societal concerns about privacy. For this reason, among other things, we have decided to inquire about the requirements and concerns of our users through a survey.
User Requirements Survey
In order to develop a sound engineering product it is important to not become out of touch with the actual requirements and needs that our targeted users have. Although we, as students, are for a large part also users ourselves, we can still get misdirected in our assumptions of what the user requirements and needs are by the anecdotal problems that we personally face. For this reason we have made a survey with the purpose of determining the stances on some aspects of our project. We have chosen to focus on multiple choice questions over open questions in our survey. The main reason for this is that open questions are a lot harder to properly analyze, since the answers can’t be easily quantified into different categories. However, open questions do have the advantage of removing some of the subjectivity of the creators of the survey from the answers. Although there will remain some subjectivity due to how the creators of the survey choose and formulated the questions, there is only subjectivity to how people will respond if the answers are pre-formulated as well. For this reason we have added a open question at the end that inquires about any miscellaneous thoughts or concerns that the students might have. This is important, since there might be aspects to our project that we have not yet considered and have therefore also not implemented into the multiple choice questions of the survey. The most prominent of these concerns, if there are any, should show up in questionnaire this way. There might also be correlations between answers to the different questions that could tell us more about our users
In order to paint a clear picture of the application of our idea we have selected the library of Metaforum as an example setting for the survey, as it is the busiest and most popular of the open study spaces on the university. The following aspects are inquired about in the survey:
- How often do you approximately study in Metaforum? This is asked in order to ensure the creditability of the other answers.
- How often do you have trouble finding a place to study in Metaforum? This is asked to gauge how much need there is for a solution to our problem statement.
- Would you appreciate and use an app that allows you to see a map of available open study spaces? This is asked to determine if our users agree that our idea is conceptually a suitable solution to the problem statement.
- If you answered "No" to the question above, what is your main reason for doing so? (open question). By asking this open question we try to detect any unnoticed reasons that might obstruct the usage of our application among our users.
- Would you have any concerns regarding privacy if the app made use of a network of cameras at these study places to determine where free places are available? This is asked to gauge of much our users are bothered by the privacy implications of the camera network that is necessary for our application.
- How would you answer the last question if it would be ensured that the footage from the cameras is exclusively used by software for determining where free chairs are located and therefore cannot be viewed by anyone? This is asked to determine the effect of our largest privacy measure, which is keeping the camera measurements in a closed system.
- When you are studying in Metaforum, what percentage of the time do you estimate you have your laptop before you? This is asked to check our assumption that laptops can generally be used to predict the status of a seat as being occupied.
- Do you have any miscellaneous thoughts or concerns about our proposed solution? Finally, we ask another open question to ensure we haven’t missed any aspects of our application.
The final survey can be found here: https://forms.gle/LnnYxHqzP3n6338g8
Survey Analysis
After roughly three weeks we have gathered 19 responses. This is less than we originally anticipated. There seem to be two main reasons for this. Firstly, using the large group chats of students of each major to spread the survey turned out to be fairly ineffective. Although each group chat often contains well upward of a hundred people, very little people seemed to have followed through on filling in the survey. Secondly, after this setback became apparent, there were only a limited amount of options left to distribute the survey due to the Covid-19 pandemic. We did however manage to increase the amount of participants by approaching individual students or small group chats of students. This might have introduced some bias to our results, especially since the students we approached were generally friends or other people that we knew. We have chosen to do this anyway since the otherwise extremely low sample size would have definitely been more detrimental to the accurate exploration of our user’s requirements.
1. How often do you approximately study in Metaforum?
All respondents answered that they studied in Metaforum. This confirms that our survey has reached our target users and therefore allows us to analyze the rest of the questions of this survey.
2. How often do you have trouble finding a place to study in Metaforum?
The answers to this question were fairly evenly split between “often”, “occasionally” and “rarely”. Although this does show that our problem statement is far from shared by all students, it also equally shows that there is definitely a need for a solution to our problem statement.
3. Would you appreciate and use an app that allows you to see a map of available open study spaces?
Except for a single answer everyone responded that they would at least somewhat appreciate our application and would at least use it occasionally.
4. If you answered "No" to the question above, what is your main reason for doing so?
The single person that responded with “no” to question 3 answered here that finding a study place would be faster without using the app. This probably has to do with this person also answering “rarely” to question 2.
5 & 6. Would you have any concerns regarding privacy if the app made use of a network of cameras at these study places to determine where free places are available?
How would you answer the last question if it would be ensured that the footage from the cameras is exclusively used by software for determining where free chairs are located and therefore cannot be viewed by anyone?
First, before the respondents knew that the footage is used exclusively by the software, roughly one-third of them (36,8%) did not like the idea of using cameras due to privacy concerns. After knowing that the footage is exclusively used by software, the amount of people, who initially said that using a camera was unacceptable, has decreased to roughly one-sixth (15,8%). So, more than half of them changed their minds after knowing that. The total amount of people who find it acceptable (or at least tolerable) to use cameras for finding vacant seats, after knowing the footage cannot be accessed by people, seems to be 84,2%.
7. When you are studying in Metaforum, what percentage of the time do you estimate you have your laptop before you?
This question was answered surprisingly unanimously, all respondents reported having their laptops in front of them at least 80% of the time, for an average of 94,7%.
8. Do you have any miscellaneous thoughts or concerns about our proposed solution?
About a third of the participants answered this open question. Two commented that they thought the application wasn’t necessary, another two commented that they had privacy concerns, one of which suggested using sensors rather than cameras. Lastly, one respondent replied that they would like to see an implementation with the planapp rather than the development of a new app.
Conclusion
Our participants can be roughly divided into two groups, a larger group that occasionally or often has trouble finding a study place in Metaforum and would appreciate our app, and a smaller group that only rarely or occasionally has trouble finding a study place and that doesn’t see much benefit in our application. This doesn’t matter that much for the development of our technology, since unlike room reservations the use of our application is voluntary. While it obviously would be better if even more participants answered that they would like to use our app, the part of the students that isn’t interested in using the application doesn’t experience any negative consequences. Additionally, the fact that there is still a majority that would like to use our application confirms that there is definitely a need for the technology that we are developing. What does potentially pose a problem are the responses to the questions about privacy. Although most participants didn’t have any privacy issues, especially if the footage isn’t saved or viewed, there is still roughly 15% that do. Unlike the previously described situation, the people that are worried about privacy issues are still affected by those issues, regardless of them using the app or not. This means that we will need to further think about possible changes that we could make to our application that could resolve these issues.
State-of-the-art
Neural Networks
What is a neural network
Neural networks are a set of algorithms, modeled loosely after the human brain, that are designed to recognize patterns. They interpret sensory data through a kind of machine perception, labeling or clustering raw input. The patterns they recognize are numerical, contained in vectors, into which all real-world data, be it images, sound, text or time series, must be translated. Neural networks help us cluster and classify. You can think of them as a clustering and classification layer on top of the data you store and manage. They help to group unlabeled data according to similarities among the example inputs, and they classify data when they have a labeled dataset to train on. (Neural networks can also extract features that are fed to other algorithms for clustering and classification; so you can think of deep neural networks as components of larger machine-learning applications involving algorithms for reinforcement learning, classification and regression.) The most important applications, in our case are:
Classification
All classification tasks depend upon labeled datasets; that is, humans must transfer their knowledge to the dataset in order for a neural network to learn the correlation between labels and data. This is known as supervised learning. Detect faces, identify people in images, recognize facial expressions (angry, joyful) Identify objects in images (stop signs, pedestrians, lane markers…) Recognize gestures in video Detect voices, identify speakers, transcribe speech to text, recognize sentiment in voices Classify text as spam (in emails), or fraudulent (in insurance claims); recognize sentiment in text (customer feedback) Any labels that humans can generate, any outcomes that you care about and which correlate to data, can be used to train a neural network.
Clustering
Clustering or grouping is the detection of similarities. Deep learning does not require labels to detect similarities. Learning without labels is called unsupervised learning. Unlabeled data is the majority of data in the world. One law of machine learning is: the more data an algorithm can train on, the more accurate it will be. Therefore, unsupervised learning has the potential to produce highly accurate models. Search: Comparing documents, images or sounds to surface similar items. Anomaly detection: The flipside of detecting similarities is detecting anomalies, or unusual behavior. In many cases, unusual behavior correlates highly with things you want to detect and prevent, such as fraud.
Model:
Here’s a diagram of what one node might look like.
A node layer is a row of those neuron-like switches that turn on or off as the input is fed through the net. Each layer’s output is simultaneously the subsequent layer’s input, starting from an initial input layer receiving your data.
Convolutional Neural Network
For computer vision and image recognition, the most used type of Neural Network is a Convolutional Neural Network A Convolutional Neural Network (ConvNet/CNN) is a Deep Learning algorithm which can take in an input image, assign importance (learnable weights and biases) to various aspects/objects in the image and be able to differentiate one from the other. The pre-processing required in a ConvNet is much lower as compared to other classification algorithms. While in primitive methods filters are hand-engineered, with enough training, ConvNets have the ability to learn these filters/characteristics.
Model:
Current Knowledge
Neural Networks
The current state of the art library for AI and machine learning is OpenCv. OpenCV (Open Source Computer Vision Library) is an open source computer vision and machine learning software library. OpenCV was built to provide a common infrastructure for computer vision applications and to accelerate the use of machine perception in the commercial products. Being a BSD-licensed product, OpenCV makes it easy for businesses to utilize and modify the code.
The library has more than 2500 optimized algorithms, which includes a comprehensive set of both classic and state-of-the-art computer vision and machine learning algorithms. These algorithms can be used to detect and recognize faces, identify objects, classify human actions in videos, track camera movements, track moving objects, extract 3D models of objects, produce 3D point clouds from stereo cameras, stitch images together to produce a high resolution image of an entire scene, find similar images from an image database, remove red eyes from images taken using flash, follow eye movements, recognize scenery and establish markers to overlay it with augmented reality, etc. OpenCV has more than 47 thousand people of user community and estimated number of downloads exceeding 18 million. The library is used extensively in companies, research groups and by governmental bodies.
From those the current state of the heart in terms of object detections is an algorithm called Cascade Mask R-CNN. A multi-stage object detection architecture, the Cascade R-CNN, is proposed to address these problems. It consists of a sequence of detectors trained with increasing IoU thresholds, to be sequentially more selective against close false positives. Comparing it to the last year state of art algorithm , Cascade Mask R-CNN has an overall 15% increase in performance, and a 25% performance increase regarding the state of art of 2016.
This method/apporach can be found in the following papers:
Hybrid Task Cascade for Instance Segmentation[1]
CBNet: A Novel Composite Backbone Network Architecture for Object Detection. [2]
Cascade R-CNN: High Quality Object Detection And Instance Segmentation. [3]
This is a paper which describes the workings, differences and origin of multiple InfraRed cameras and techniques. [4]
Parking Space Vacancy Detection
Similar systems have already been implemented in real-life situation for parking spaces for cars.[5] Many parking environments have implemented ways to identify vacant parking spaces in an area using various methods: Counter-based systems, which only provide information on the number of vacant spaces, sensor-based systems, which requires ultrasound, infrared light or magnetic-based sensors to be installed on each parking spot, and image or camera-based systems. These camera systems are the most cost-efficient method as it only requires a few cameras in order to function and many areas already have cameras installed. This system is however rarely implemented as it doesn't work too well in outdoor situations.
Researchers from the University of Melbourne have created a parking occupancy detection framework using a deep convolutional neural network (CNN) to detect outdoor parking spaces from images with an accuracy of up to 99.7%.[6] This shows the potential that image based systems using CNN's have in these types of tasks. A major difference that our project has from this research however, is the movement of the spaces. Parking spaces of vehicles always stay on the same position. A CNN is therefore able to focus on a specific part of the camera and focus on one parking space. In our situation the chairs can move around and aren't in a constant position. The neural network will therefore first have to find and identify all the chairs in its vision before it can detect whether it is vacant or not, an additional challenge we need to overcome.
Another research group have performed a similar research using deep learning in combination with a video system for real-time parking measurement.[7] Their method combines information across multiple image frames in a video sequence to remove noise and achieves higher accuracy than pure image-based methods.
Seat or Workspace Occupancy Detection
A group of students from the Singapore Management University have tried to tackle a similar problem.[8] In their research they proposed a method using capacitance and infrared sensors to solve the problem of seat hogging. Using this they can accurately determine whether a seat is empty, occupied by a human, or the table is occupied by items. This method does require a sensor to be placed underneath each table and since in our situation the chairs move around, this method can't be used everywhere.
A seat occupancy method using capacitive sensing has also been proposed.[9] The research focused on car seats and can also detect the position of the seated person. A prototype has shown that it is feasible in real-time situations.
The Institute of Photogrammetry has also done research into an intelligent airbag system, only this time using camera footage.[10] They were also able to detect if the passenger seat was occupied or not and what the positions of the people were.
A method using cameras is described in the research by the National Laboratory of Pattern Recognition in China for people in seats counting.[11] They propose a coarse-to-fine framework to detect the amount of people in a meeting using a surveillance camera with an accuracy of 99.88%.
Autodesk research also proposed a method for detecting seat occupancy, only this time for a cubicle or an entire room.[12] They used decision trees in combination with several types of sensors to determine what sensor is the most effective. The individual feature which best distinguished presence from absence was the root-mean-square of a passive infrared motion sensor. It had an accuracy of 98.4% but using multiple sensors only made the result worse, probably due to overfitting. This method could be implemented for rooms around the university but not for individual chairs.
A similar idea was envisioned a few years ago with the creation of an app called RoomFinder which allowed students at Bryant University to find empty rooms around campus to study in.[13] This system, created by one of the students, taps into the sensors used by the automatic lighting system in these rooms, to detect whether a room is currently being used and sends that information to the app. As that system was already implemented around campus, it didn't require any capital investment.
Other Image Detection Research
Aerial and satellite images can also be used for object detection.[14] An automatic content-based analysis of aerial imagery is proposed to mark object or regions with an accuracy of 98.6%.
Planning
Milestones
For our project we have decided upon the following milestones each week:
- Week 1: Decide on a subject, make a planning and do research on existing similar products and technologies.
- Week 2: Finish preparation research on USE aspects and subject and have a clear idea of the possibilities for our projects.
- Week 3: Start writing code for our device and finish the design of our prototype.
- Week 4: Create the dataset of training images and buy the required items to build our device.
- Week 5: Have a working neural network and train it using our dataset.
- Week 6: Test our prototype in a staged setting and gather results and possible improvements.
- Week 7: Finish our prototype based on the test results and do one more final test.
- Week 8: Completely finish the Wiki page and the presentation on our project.
Deliverables
This project plans to provide the following deliverables:
- A Wiki page containing all our research and summaries of our project.
- A prototype of our proposed device.
- A presentation showing the results of our project.
Schedule
Our current planning can be seen in the table below
Rooms
Besides the system to detect free workplaces, it should also be noted that the system to reserve rooms at the TU/e has some flaws. At first, there is currently no system in place to detect if the room is actually used. There have only been some pilots, plus there are no punishments for those who take advantage of the system. In this section there will only be a focus on suggestions and recommendations to "upgrade" the system.
State of the art at the TU/e
The current system which is used at the Technical University of Eindhoven is based upon Planon. This system manages the reservations for the rooms and the workplaces in auditorium and some others around the campus. Those workplaces are able to be recognised by the stickers and the QR-codes on the tables.
The TU/e has also expended upon it by using BookMySpace in combination with Planon, reservations made by BookMySpace will be fed into Planon. This results in that BookMySpace is still limited by the possibilities by Planon. For example Planon can not handle that a reservation is shared between multiple people. Currently BookMySpace sends invites via outlook to create the meeting, but the actual reservation can only be made by one person.
The system has also expanded upon by Pilots of BookMySpace. In the building Metaforum they implemented sensors in some room to detect no-showers, people who do not show up in time, and early leavers, people who leave earlier than expected. After 15 minutes of no movement the sensor could consider the room empty and cancel the current reservation. However there were some noticed problems with this system. While the system could detect no-showers correctly it had some problems with early-leavers. Since the detection of the system was based upon movement sensors it could happen that if a person was making a test or sits too still for 15 minute the system does not detect any movement and detects it as early-left. This could give the room free for other students to use while someone was in a test. That resulted into that the observer or examinee had to move or wave their hand every 15 minutes which was quite inconvenient.
Also from sources from BookMySpace there probably will be another pilot in the upcoming future in the building Atlas at the TU/e campus. This system will probably use some form of detection systems in the lamps. One difference with this pilot in comparison to the pilot in Metaforum is that this detection will be based upon heat. This will result that the detection system can detect if people are in the room, and even how many there are in the room. This will probably reduce the chance of a wrong detection of early leavers in comparison to the old system. Which could result into a wide implementation of a no-shower and early-leaver system into Atlas. Since those lamps are at this moment only compatible with the building Atlas.
Besides the pilots above there is also another system in place at the University in Flux. Those rooms are only reserverable by students of the faculties located in the building, however to access the rooms the reserving person has to enter the room with his or her student card so it can be noted who and when the room is entered.
Regulations
In comparison to the system with the chairs which will be explained below, it is possible to pursue people who do not follow the rules and regulations with the rooms system at the TU/e. People need to reserve rooms through their account, making it possible to make them responsible for what happens to the room as long as they have reserved it (name, picture of account holder, student number, etc. are all known once a person has reserved a room through his/her account).
Following it is able to pursue people who do not follow the regulations, regulations can be determined and set up for the students including “punishments”. However also here there are some social norms which people must follow to make sure the system works efficiently.
Some of the social norms to make the system more efficient could be:
- A person can only make use of a room when he or she has reserved it. So, the room does not register that people are in the room and the room can be given as “free” in the system so it can be reserved in the system again. Plus, the system then always knows who has been in the room the latest.
- A person only reserves the room for the time he is in the room, so during a planned lunch break the room can be used by other students or staff.
- In case there is something wrong in the room it will be notified immediately to the university. If this is done the last person entering the room could be held accountable.
There are of course also regulations for reserving the room in the system:
- Rooms can only be reserved up to 7 days in advance by students and teachers for normal meetings. Exceptions are made for meetings for courses which can be reserved for a longer period.
- Reservations can only be made when they are not already in conflict with another reservation.
- A person cannot reserve more than one room in the same time period. This to prevent reserved empty rooms and that the reserving person is in the room.
Next up are the regulations which are punishable, however between those most of them are hard to check if social norms are not followed so it is unknown who did it.
- No vandalism or anything else of the sort. This one is difficult to punish as there could be a variety of people throughout the day in the room which could have vandalized the room and the last person reserving it is not always responsible.
- The room should be left the same way it was found. If chairs and/or tables have been moved in the room, they need to be put back in their original positions before leaving the room. Other items that did not originally belong in the room should be taken away or thrown in the bin.
- Every day, all items left behind found in the rooms will be stored safely and can be picked up at the help desk of the same building as the room where the object was left behind.
- Rooms are only used for meetings in groups and not for single students to work in.
Followed by the regulations which are could be punished if a system was in place to detect the presence of people in the room like at the pilots of the TU/e:
- If no one is in the room after 15 minutes during the reservation, the reservation is cancelled and will be labelled as a no-show.
- If the room is empty during a reservation for a period longer than 15 minutes the reservation is cancelled as well and will be labelled as an early-left.
Now the regulations are in place it is possible to put up the punishments for those who violate the rules of the system. One thing to note is that there will be no punishment for an early-leaver, as this person or group are finished. There should be no punishment for people who are done earlier than expected and let the system detect the room as free.
For the actual punishments those will be based upon the severity of the violation and the previous violations. For example, vandalism of the room can be considered as a higher severity than not showing up. Those violations will then be added up and when certain thresholds are reached limitations will be put upon the user. The reasoning a threshold is used it that someone is a no-show due to strange odds he or she will not be punished. After the passing of time and not violating any rules of the system the violations will disappear and if it is below the threshold less or no limitations are present anymore for the user. This system punishes the abusers harder while a rare no-show will not be punished to keep the system fair for everyone.
It is recommended by bookmyspace to use as little thresholds and punishments as possible. Since the more thresholds and punishments are present within the system the harder it will get for the system to accommodate reservations for everyone and make the system work optimally. So only three thresholds will be suggested.
The first threshold will only a simple limitation of that a person is only able to hold reservations with a total maximum time of 8 hours. This makes sure that person can reserve rooms for a day if needed or multiple smaller meetings during the week. But must think more clearly at what times he or she will be needing the rooms as there is a restriction.
The next threshold will impose another extra rule on top of that which instead of reserving rooms 7 days in advance it is only possible to reserve rooms 3 days in advance. This will give users who do not abuse the system the first choice of rooms while the people who are violating the system have the “second choice” of rooms. It still should give the user enough time to find an empty room in the system though.
The final threshold will reduce the maximum time from 8 to 4 hours of maximum time of reservations. It will it still make it able to reserve rooms and have meetings, as that should not be limited completely since he still is a student or employee of the university and the university provides those services.
Chairs
Besides the problem with the room there is also the occasional problem that a student is not able to find an empty workplace in a reasonable amount of time. This is especially true during exam weeks. To solve this problem a system will be designed and proposed as a possible solution to this problem.
State of art at the TU/e
The current system which is used at the Technical University of Eindhoven is based upon Planon. This system manages the reservations for the rooms and the workplaces in auditorium and some others around the campus. Those workplaces are able to be recognised by the stickers and the QR-codes on the tables. These currently can be found in the buildings Auditorium, Vertigo, Flux and Cascade. These tables can be reserved using either Planon or BookMySpace
Currently the system works by reserving the workplace, mostly looking at the table. This is another approach to our suggested system which will be explained further below where we look at the chairs instead of the table. Another distinction is that this system works by reserving the workplace in advance, you can look in BookMySpace or Planon to find an unreserved workplace and you could make a reservation for yourself. However it is concluded currently do not use this system much since in general there is enough place at the places this system is used. One advantage of this system that you could kick out people if you have reserved a chair, while this could lead to some inconveniences and arguments with students which might not want to leave. Which is in turn another distinction with our proposed system which mainly looks at the current empty chairs in an area where you cannot reserve a chair.
Regulations
In order to run the system as optimally as possible, it is highly recommended that people follow the proposed rules and regulations. The reason why these are "highly recommended" and not mandatory, is because it is not possible to persue people who do not follow these rules and regulations. Currently, the system is not able to tell who a person exactly is when they are detected by the program. It treats everything as different "objects" and therefore it cannot distinguish different people from each other. Furthermore, even if the system was able to tell who person is, distinguishing people from each other can also lead to some ethical problems. For instance, some people do not want the system to recognise who they are, which means that implementing this feature will induce some privacy issues. Therefore it is better to leave the system in such a state where it only detects people, but nothing more than that.
This results that the rules and regulations should be considered more like "social norms" which people have to follow to make the system work optimally and more effecient. Which results into the following social norms:
- A person cannot stay at away of the workplace for a longer period of time while holding the workplace. People who are leaving the chair for a minute to go to the toilet or strech their legs is not a problem. However, sometimes people tend to walk away from their spot for an hour while they still claim the spot with their stuff as a jacket or bag. This claimed spot then cannot be used for other people who might want to sit at that place to study while the other is gone.
- A person can only claim one workplace for themselves. If people are claiming chairs for other people to mark them as occupied for the system and people people will not be able to sit there while the spot is still technically free. As no person is currently working at the workplace.
- Chairs should not be removed from the table or workplace they belong to. This one depends more on the situation and the area, for smaller areas it is probably better to not move the chairs as much since non-occupied chairs also indicate a workplace which is empty. For bigger areas like the metaforum at the TU/e this is less of an issue as there are long table with lots of empty spots.
System Design
Design Choices
How the information is conveyed to the people is the next question. There are multiple options to collect and convey the information to the system users. In this part we will discuss some options that are available and could be used in a practical environment.
How should the information be collected?
Which kind of system?
As described in the approach, there are multiple ways to collect the data needed for the system. For detecting a chair and checking if it is occupied or not, a camera-based system or the thermographic-based system would probably be the best option. However, the camera-based system has one big advantage over a thermographic-based system, which are the costs. The cost of a thermographic camera is quite high when compared to a basic camera. A “cheap” small camera, which can be connected to something like an Arduino, will already cost 65 euros [15] for a 32x24 pixel view of an angle of 56 degrees. While for 15 euros [16] it is also possible to get a 5MP camera with an angle of 170 degrees. A higher pixel count leads to more accurate data to analyse for the algorithm, which determines whether a chair is empty or not, which in turn gives a more accurate representation. In bigger buildings or campuses this could greatly reduce the costs, since less and cheaper cameras are needed for the system while also being more accurate.
Implementation
How the system will be implemented also depends on which building it will be implemented. Preferably, the cameras will be mounted to the ceiling to get a wide coverage of the area, which reduces the number of cameras needed for the system. It is possible to hang them directly above the tables. This lowers the chance of a chair obstructing the view of a camera, since it looks at them from a “bird eye” view. If the camera is in a corner of the ceiling, it will probably have a wider coverage of the area, but the view of an object can more easily be obstructed by other objects, or even other chairs.
The actual system implementation will mostly depend on a couple of factors. Costs, space, and accuracy. At first you have the space available; the ceiling height can change the location of the camera. If the area has a lower ceiling, the “bird's-eye view” will rapidly reduce in visibility the lower the ceiling is ,while a camera in the corner has less problems with that. However, with a lower ceiling it could also be said that since there is more a linear view, there are more possible obstructions for the system. So here, the costs and accurateness of the system come into play. When an accurate system is needed and costs are less of an issue, you could opt to use more cameras in a bird's-eye view for a lower chance of obstruction. The other way around is of course also more possible.
Another reason why the bird eye view can be made more accurate is that in bigger areas, where one camera cannot convey the whole room, it is easier to define boundaries of bird's-eye view cameras since they only must look in a certain “box”. The camera in a corner also has depth to consider, so it is harder to not have duplications in the system. This would also probably mean that the calibration of the cameras will take less time which could in turn also reduce the costs a bit due to less hours needed to implement the system.
Another factor is how the cameras will be connected into the systems. You could opt for separate stations which process the data locally and then send them to the server. The other option is to collect the video tape at location and then send them to a central processing unit where every data is gathered. This will mostly depend on how much processing power you need and how many data you collect. For smaller systems a central processing unit would suffice since it does not handle that much data which makes it possible to queue up the data more easily. Also, a central processing unit is in general more powerful than a small station which also reduces the time needed to detect empty chairs. For bigger buildings with a lot of areas to be governed by the system multiple separate stations would probably be the better options. It will cost a bit more time to compute but it will have less data to process which as well should even it out. It also has the advantage that if one station goes down the system still partially functions while if the central unit goes down the whole system stops.
Data handling
Of course, the privacy of the users, and not users who are in the area is also something to consider. The data must be handled in such a way to make sure the system can be used, is privacy law compliant and is accepted by the people working there. Preferably the videos in the system should only be used to detect the chairs and for nothing else. This gives the highest probability that the people and the law are compliant with it, also in the future. To assure this the best option would be a “black box” model where the video tape goes directly into the system, and then the location of the chairs come out of it which will be send to the server.
If the video tape cannot be accessed it results in that people cannot use the video to spy on the people working in the area, also the video tape should not be stored, or only stored locally for a small amount of time and should be deleted when the system is done processing the information, this also reduces the chance of someone accessing the video footage. One focus of the system also should be that it cannot recognise individuals but only a “human”. In case the system information is accessed the only things visible are object, human, empty chair, occupied chair etc.
Preferably most of the communication of the system would be done via wired connections, since that could reduce the risk of that the system is hacked and information falls into the wrong hands. With a wired system the hacker must have access to the system locally and physically while a wireless system could be hacked remotely. This also includes a database which is located on their own system, so that third-parties are not able to access that data.
What functions should the application have?
Accessibility
At first the system should be easily accessible for the users. If the system is easily accessible it should have a higher likelihood of being used by the intended users. This means that for example a system which only uses some screens in the building is not preferable since that could lead up to a queue to use the system and with that people ignoring it. Preferably it would be a web application or an app for mobile phones. This gives everyone access when they want to use the system. Also, almost, everyone has a smartphone on hand which they could use to access the said web application or app. Plus as an advantage it is also mobile which could help people traverse through the environment.
Favourite system
Another feature to increase the accessibility and usability of the application is to have a favourite feature. This could save the favourite area of the user and put that into a list. This will make it easier for the user to access the areas the user prefers and go to that area directly within a few clicks. Preferably it is not only possible to save a specific areas into the list but also a building, or floor of a building to increase the convivence of the favourite system.
Connectivity
We also must look at the connectivity of the system. How will it be connected to the outside world, or will it be a completely closed system with no direct access to the internet. At first is a closed system with no internet access probably the most privacy secure option. Since people need to be hooked up directly into the system would they be able to break into the data. However, that means that the system can also not be used with mobile phones that well since there is no internet connection. That should result in a less accessible system which might be less used by the intended users. A further dive into the privacy will be done later. So, for it to be widely accessible it should have a connection to the internet so it can clearly and easily communicate with the people.
In case an internet connection is used the system should update the information regularly into a database so the web application or mobile app can have accurate and reliable data. Otherwise users of the system could walk to already occupied chairs for a certain amount of time without being notified of it. This would lead to that preferably the system would be updated real time, however this can put a real strain on the server and system since they must analyse everything at every moment of time. To reduce the load on the system it would only have to update every 10 seconds or so. This gives the system move time to check for empty chairs which reduces the computational power needed for the system. Also, it reduces the load on the server since less data is send to the server.
For the web application or mobile app, the same argument can be made. They could update in real time based upon the information they have gotten from the server, which is about every 10 seconds, or have a refresh function which must be activated manually. While a real time update gives the most accurate information it also increases the load of the system. If people accidentally keep the application option while not looking at it, it still asks requests of the server. If a lot of people are doing it, it might cause some unnecessary problem for the people who want to use the system, as it can reduce to slower loading times due to the higher strain on the server. So, the best option would probably be a refresh function, the moment the app is moment it asks the most accurate data of the server, then the people can press a button to refresh the data with the latest data of the server. To make sure it is not spammed it could be made that it can only be pressed every 5 seconds or so for those who want to play with the button.
Login- / Access system
Another debate can be what chairs should be made visible to who. At first the building might have restricted access area only accessible to a certain number of employees. Preferably those are not visible for those who should not be able to access that area. For example, at the TU/e in the Atlas building there are areas which are reserved for innovation sciences students. A mechanical engineering should preferably not be able to see the visible chairs at the location. This can be solved using a login- / access system, people can get different rights for certain areas to only see the areas which are accessible for them. This however can reduce the usability and accessibility of people since not everyone can access the system. This could lead to a problem where the system is not used in possibly busy public areas like a busy library since not everyone wants to do the hassle to make an account. To tackle this problem, it is an option to make certain areas publicly available without an account, while other areas are locked behind an account, in the same manner a mechanical engineer cannot see the area of innovation sciences.
A bonus of using a login- / access system would be that users could be able to mark an area as a favourite area for them on their account. These could then be displayed in a separate list with is accessible with a single button press. As some users like to sit in the same area if they must be present at the location.
Reserving a chair
It can be argued that a possible function for the system is to the possibility to reserve a chair which the user might want to sit on. This makes sure that the user can sit at the location he or she wants you would think. However, this is difficult to implement into the system as this thought is based upon either of the following premises. The first premise might be that everyone uses the app, then everyone can see which chairs are empty and which are free to pick. The second premise is that the chair might be able to indicate that the chair is reserved but currently not occupied. Both these premises, if true, should both make it able to implement a system which the chair could be reserved as it is indicated while a chair is reserved or not. Sadly, the first one can be hindered by people who are not using the system and will then claim an already reserved chair while the person who reserved it will be left with no chair. The second one can be hindered by the costs of the system as every chair must have an indication that the chair is reserved to make the system work, plus that people do not claim an already reserved chair.
Privacy
The system also must take privacy into account while showing the information. The more data is stored in the application the more chance it must be less privacy compliant to laws or public reception. It should preferable only store the necessary data from the users to make it also future proof if laws might get changed later.
For this system to work there is not that much necessary data which should be collected from within the application. The most prominent data collection from the user is the login- or access system. If it is opted to use such a system, it should store the user’s data to make sure he or she stays logged in to the system. Also, extra data from the user might be asked, like the role in the company for the system to know which area’s it can have access to. However, other personal data, as the name of the user, is not important for the
Other commonly frequently asked permissions from an application should not be necessary. Agenda, camera, contacts, microphone, SMS and phone access should not be used within the app. One debatable access might be the use of location. If it is chosen to also incorporate a navigation to the chosen area or the chosen chair the person wants to sit on location access is needed. Storage access however might be needed, since this could store the login information or preferences from the user so he or she does not have to login every time he or she wants to use the application.
How should the information be conveyed?
All chairs vs only non-occupied chairs
At first there is the option to change the display of all the chairs, the occupied and non-occupied chairs. Both have their own advantages and disadvantages. At first if occupied chairs are shown the system has an additional functionality. Since all chairs are visible by the system the user should be able to see empty spots at the tables. If there is a distance between two (non)-occupied chairs you can consider that area empty. While if only non-occupied chairs are visible the user is not able to know if there is an occupied chair there or not. While this functionality for a single user doesn’t matter that much, for a group of users this could matter since it is easier to find places to sit.
If occupied chairs are shown it can also lead to a small ethical problem. Since it can be argued that it is easier to track a person’s movement if occupied chairs are visible. If the occupier moves the chair it is visible, and the movement of the person can be tracked more easily in comparison to if the occupied chairs are not visible. Since movement of occupied chairs will then not be shown.
Mobile application vs web application
As discussed by accessibility the application should be accessible, preferably via phone. If this is done there are two options, a mobile application or a web application which both have their own advantages and disadvantages. As the "gathering" system is a very closed one and sends data to a database it has to be chosen how that data from the database is conveyed to the application user.
A web-based application has one major advantage and that is that only one application must be designed which should be able to work on any mobile phone. As browsers and their applications can be accessed from Android, iOS, Windows and other systems with access to browsers. This decreases the development time of the application since it does not have to be ported to another OS, although it only must be working at Android and iOS to have 99% market share. [17]Another advantage is that it can also work for laptops and computers, this results into that people at one place could look at their laptop to find a new one in case they have to move since the group size is increased for example.
This could be compared to the major downside and that a browser tends to “forget” the login quite a lot more often. Since a mobile application can store the credentials and login information locally while a browser cannot. So, if a browser is closed the cookies and cache are lost and the user must sign in again which can lead to a small hassle for the users. This could lead to a decrease of accessibility and for that possible use of the system.
Interface
Next up is the actual interface of the application, as the information should work optimally to convey the information in a clear manner. At first there is the option for bigger campuses which use multiple buildings to have a list of the buildings with the number of non-occupied chairs or a map with all the buildings and the number of non-occupied chairs. The first option might be better suited for users who are already familiar with the campus since they know where each building is located. Plus, the information can be seen a bit clearer and faster since you do not have to scroll or zoom to the correct building. The second option is better suited for newer users who are not familiar with the campus yet. These users can then have an overview where the building is located with an immediate number for the number of empty chairs.
Besides the number of chairs, it should be clear which facilities the building has to offer. For example, at the TU/e some buildings offer silent areas where it is expected of the students that they work in concentration silently without noise. Also, there are labs for students located all around the campus as well. Some areas also facilitate power outlets for the students or a possibility for a wired internet connection. This could help users of the system decide to which building they want to go in case they have specific needs. This is not only true for the buildings, but this information should also be visible at the selection of the floors and specific areas.
Next up is the floor selection. The floor selection of a building can be kept quite simple as a simple list, with the possibility to look at the facilities of each floor of course. If a floor is selected there are a couple of options which can be chosen to display the next information.
At first you have the possibility to show the entire floor map with all the (non)-occupied chairs visible. However, this has two downsides which must be considered. As all the chairs are loaded it asks the location of all the chairs, and their status from the server. This could add unnecessary load and strain on the server since more things must be asked individually. The same could be said for the app as well since more things have to be loaded by the application individually using that data. Next up is that it can also be confusing since a mobile phone screen can only show that much information at the same time at the relatively small screen. A person will probably have to zoom in the map at first to see the location of the chairs which decreases its ease of use.
Another possibility is to divide the floor into different areas as well. It has the advantages of that less information is needed, since only the empty number of chairs is needed. Which in turn decrease the load and strain on the server and application. A bonus is that also more specific information of the area can be displayed to the user. As some areas will have a certain table height while another area has a different table height. It also can make it easier to differentiate areas to see if certain areas are only meant to be accessible by a certain people or the area is a laboratory. However, it only shows the number of chairs instead of the location of the chairs as well.
The best option between the above would probably be to have the latter as a selection which then pulls up the map of the area with the (non)-occupied chairs. This has the best of both options as areas are easily differentiated by each other and reducing stress and strain on the application and server while it is also possible to see all the chairs at their location.
Recommended systems
As seen in the above, there are a lot of debates and possibilities to incorporate into the design. The most important about it is that it can differ between different system-users what functionalities are chosen to incorporate into the design.
Universal recommendations
At first there are the more universal options which should be recommended into every system. At first it is suggested to use normal cameras instead of the thermal cameras. Due to the higher accuracy of the camera it should be easier for the system to detect chairs. Plus, less cameras are needed which reduces costs and make it easier to incorporate it seamlessly into the environment. The cameras should be located at the ceiling, preferably directly above the area. As this will make it easier to create zones and know every location is checked for empty chairs. In case this is not possible it can be opted for a camera at the wall. Preferably the camera is located at 2 meters or more to have less chance of obstruction. In general, for system implementation it is recommended to have small processing units which only are connected to a couple of cameras or areas depending on the size of the area and the building. Those units process the data locally and then send it to the database. This should result in better reliability of the system as if one unit goes down the rest of the system continues working in comparison to one central computing system. Also, if maintenance must be done to the units only one unit has to be put offline and temporarily disabled. The latter is however only true if it is a system update to the units and not to the database.
Next up is the data handling which should be as careful with the privacy as possible. This reduces the chance of it not being privacy compliant. That should result into that preferable the video tape should not be stored and not be accessible for people. However, this could lead to a problem in case something goes wrong. Since no one can access the system it can be difficult to locate the problem and fix it. A better suggestion might be that system administrators could access the live feed directly. In this system it is still only possible for the system to see a person as a human and not personally identify it. It increases the privacy problems a bit, but the system also should be able to be maintained to be useable. Also, as little as possible of information about the application user should be stored onto the system, which results in only the preferences, login information and access which should be stored.
Another universal recommendation is to make the application very accessible by it being accessible via a mobile phone. This will also result into that the system is connected via the internet to the application user with updates of about 10 seconds to keep the data up to date and relevant while also reducing stress on the server and application. Also incorporate the favourite system into the application for ease of use, but not the reserving feature as this will possibility greatly increase the cost.
The interface of the application should be easy and clear while reducing stress of the application and server. So, it is recommended to have, in case there are multiple buildings, first the option to select a building from a list or a map. Followed by a floor selection, area selection and then chairs will be visible. All with an option to see the facilities of the building, floor or area and the number of empty chairs in that building, floor or area.
Specific recommendations
Besides the universal recommendations there are also more specific recommendations which might be true for one but not for another implementation. Here there will be a look at libraries, universities and enterprises with a lot of flexible workspaces as possible system implementation targets and the specific recommendations for these will suggested.
Library
Libraries are publicly accessible buildings; everyone can enter freely, and a lot of different people tend to enter the library. The employees of the libraries do not tend to work in the library itself but at their own offices. In this case a login system would not be very helpful as there are not a lot of specific areas only accessible for certain amount of people. To increase the usability even further it is recommended to use a web-based application instead of a mobile application. This since a website is easier accessed as the user does not have to download a mobile application beforehand. This will create the problem that favourite areas cannot be saved easily since no login is used and it is difficult for a browser to save data directly to the mobile phone or computer which can be accessed later. This should not be a problem for smaller libraries; however, this could be annoying for users in bigger libraries. In bigger libraries it can be decided to use a login system or an application to have the favourite feature as a possibility of the system. As libraries are commonly interconnected and share a lot of system the best solution would probably to have an optional login system for the libraries, small and big ones, where the favourite area could be stored. Users who don’t mind their preferences or favourite area could then use the application without any problem. As everyone can access the building and the system it is recommended to display only the non-occupied chairs to guarantee the privacy as much as possible.
Enterprises
First, since enterprises are, mostly, private buildings they are not accessible for everyone. This also leads to a recommendation of using a login for even using the system. So other people are not able to “spy” into the company’s work floor. As a login system is recommend it also would be preferable to use a mobile application-based system to convey the information. As this makes it easier to store the login information of the user and increase the application’s usability. Also, it is recommended that the system only shows the non-occupied chairs. A boss will then not be able to monitor the activity of the employees that easily, as some workplaces might not have a chair and chairs can be moved to other places.
University
The university is officially a publicly accessible building, which should suggest that an open system is recommended without any login. However, this is not always the case, areas in a university might be designated for only a certain type of student. This is mostly tied to the faculties; another problem is that at the university you have employees and students working in the same buildings. Some flexible workspaces might be specifically designated to staff while other are meant for students. A login system will be recommended for universities. This login system will put the specifically designated areas behind a login, while other areas which are open for all are not behind a login.
Since a university campus can be quite large a system to store the favourite areas and preferences should be incorporated. This could either be done locally or to the account. To make sure that it is still very and easily accessible for everyone this would be recommended to do locally. As then everyone can still add their favourite spots without having to sign in. To save the data the system should be based upon a mobile application. As this will make it possible to store said data and login information more easily than a web-based application.
It is recommended that the occupied chairs are also visible at universities. Universities tend to have large study rooms with a lot of big tables and a great number of chairs. By being able to look at the location of all the chairs, the occupied and empty ones, a student can also find a free spot at one of the tables. As non-occupied chairs might be located at places where there is not much room on the table to work at.
To extend upon this it is specifically asked to people from bookmyspace of the TU/e how they thought about it. At first, they want to make all study places available for every student or staff but practically that is not the case at the campus. So, they agreed with the plan to have an access tool where everyone can see easily where they can and cannot sit integrated into the app. Further they also prefer that the study- / workplaces are only available for the TU/e students or personnel. Thus, bookmyspace would prefer that every area is behind a login and not only certain areas so other people are not able to tempted to sit at the university.
Visualisation of system
So how will the information be conveyed to the people? At first the layout of the information does not change much if a web-based application is used or a mobile application. It must be considered that if it is a web-based application it could be used at laptops and computers which have bigger screens. Further is it still meant for both to be used on a mobile phone which makes it still very similar. For an example of visualisation of the system the campus of the TU/e will be used, as this campus covers multiple buildings with different facilities and flexible workspaces for students and staff. This example will cover almost all use-cases since a visualisation of a campus can be skipped in case it is only one building. As discussed above with a campus you have the option to see the campus on a map with the ability to look at the building with flexible workspaces available and what facilities they have. To be extra clear for people do buildings without flexible workplaces have a different colour than those who have flexible workspaces in their building. In the building who do have flexible workspaces a number will be shown which shows the number of free chairs in said building. Plus, it is also possible to click on the building to see the facilities which the building can provide for the student or employee. Those facilities could include laboratories, general workplaces or workplaces for concentration.
As seen at the above in the example, the building on the campus without any workplace are displayed in red. In case a building does have flexible workplaces but are all occupied the burning does not turn red, but instead the number 0 will be shown. This to make it clear that building still has workplace which might become non-occupied at the time of arriving. For the other buildings they have the number within them to make it clear how many non-occupied workspaces are available in the building.
A map like this would be favourable for those who the campus is still unknown and do not know all the locations. A nice overview is shown, and they could also use it to navigate around the campus with it. For those who are already familiar with the campus can a map be inconvenient. A map can be zoomed out to much which could prevent finding the building with the highest number of chairs available or checking the building which he or she wants to sit at. As discussed before as well a list with the building would be more favourable for those. When a building is selected, via the map or list, a list of all the floors in the building should pop up. This list includes, as the building list also should, the facilities each floor can provide and the number of available workplaces at that floor.
Following this a map of the floor will be given. Here the map is divided into separate areas with each their facilities and number of chairs available to sit at. In case a login system is used some areas might be greyed out for the user since he or she is not allowed to sit there. Using the example of the TU/e campus, a bachelor student from mechanical engineering is not able to see the flexible workplaces which are meant for employees of the university or for master students from other faculties.
Subsequently if an area is pressed it will bring up a specific map of the area. This area will finally show all the occupied and non-occupied chairs available in that area. It can also be opted to only show the non-occupied chairs which will then in turn only show the available chairs and not the occupied ones.
App Creation
The App for the prototype is made in Unity. This is a program that can create various types of software on many platforms including Android an iOS apps.
App Design
The design of the app consists of 4 screen levels.
The first screen has a map of the campus with all the buildings that have free seats in beige and the buildings without available seats in red. It also shows the name and the number of currently available seats on the screen. There is a refresh button in the top right of the screen that can be used to refresh the data on the number of available seats. The user can click on a building to go to the screen of that specific building. Also each building has a info button with information about the seating in that building.
This second screen a list of buttons is shown with the floors and other areas of the building. Here it again shows the number of available seats on each floor and there is again a refresh button to refresh this data. There is also a back button in the top left to go back to the previous screen. Every area also has a info button that when clicked will show a bar with information about the seats in that area. The user can click on a floor to go to the screen for that specific floor.
On this screen it shows a map of the entire floor with the tables that have free seats in beige. This map will be divided in various areas with each showing the number of available seats. Again the screen has a refresh and back button. The user can click on one of the areas to go to the final screen. Also each area has a info button with information about the seating in that area.
On this final screen a map of the selected area will be shown with red and green dots on it, with a legend explaining this. These green dots represent available seats at their position and the red dots represent seats that are taken. Again the screen also has a refresh and back button.
On the screens with the dots it currently takes the number of available and taken seats from the firebase database. As we don't know the positions of the chairs in our current prototype, this information is assigned to random chairs in random positions around the tables to show that different chair positions can be shown.
At the bottom of the screen there will also be an image of the seating area to give the user an impression of what it is like. Unfortunately we weren’t able to take these pictures due to the coronavirus.
Chair coordinate transformation
One issue that pops up when trying to show the positions of the chairs in the app is that the coordinates of the chairs on the camera feed don't align with the coordinates they should be at on top view used in the app. This is of course the case because the perspective of the camera is different. Therefore the coordinates determined by the neural network first need to be converted to a different plane. This can be done using perspective transformation.
To illustrate this we can take one example image we made using our prototype:
In this image the neural network has detected several chairs and knows their position on the camera feed. For this example we will only take the upper table and the surrounding chairs. To make the example clearer a simple drawing is made with only the outline of the table and the positions of the chairs.
Next we make a drawing of the same table but in the view we want it in the app:
To find the transformation matrix of this transformation we need four coordinates, in this case the coordinates of the four corners of the table. These coordinates from both views can be used to define a transformation matrix. For this example we used the openCV module in python to get this matrix and transform the camera perspective image to the top view perspective image:
Here the table has been converted to the right view and the chairs have been moved with them. We also added a clearer view of what the output will look like. These converted coordinates can than be used for the positions of the dots in the app.
Obviously this transformation matrix is not the same for every room or area. Therefore this matrix will need to be calculated and hard-coded in the app or neural network for every room or area. The time it takes to do this is however very little as you only need to input the corner coordinates once during setup and, if we assume the cameras never move, this won't need to be changed afterwards. Perspective transformation is therefore a solid solution to this problem.
Requirements of the user interface
Id | Description | MoSCoW |
---|---|---|
A1 | The app can retrieve the number of empty chairs for each area from the database. | Must have |
A2 | The app has a refresh button that can retrieve the newest information on command. | Must have |
A3 | The app can display the information of the number of free chairs on the relevant pages. | Must have |
A4 | The app can display the information of the positions of free chairs and occupied chairs on the relevant pages. | Must have |
A5 | The app can display the extra information about the chairs in an area if the user desires this. | Must have |
A6 | The user can find their way through the pages to the intended area of the app without needing any outside guidance. | Must have |
A7 | The user can understand the information about the number of chairs shown on the first 3 levels of the app. | Must have |
A8 | The user can understand the information about the positions of free chairs and occupied chairs on the relevant pages of the app. | Must have |
A9 | The app must be readily available to all TU/e users without much effort with installation. | Must have |
A10 | The android app is accessible to everyone with a TU/e login and not to anyone else. | Could have |
A11 | The app has all areas with available chairs on campus in the database. | Could have |
Requirement Testing
A1
- Testing plan: Open the app and navigate to a screen which shows the number of available chairs in an area. Check if the number shown in the app is the same as the number that's currently in the database.
- Results: The number shown in the app is the same as the number in the database.
A2
- Testing plan: Open the app and navigate to a screen which shows the number of available chairs in an area. Manually change the number in the database and then press the refresh button in the app. Check if the number shown in the app updates accordingly.
- Results: The number shown in the app changed to the new number in the database.
A3
- Testing plan: Open the app and navigate to a screen which shows the number of available chairs in a room. Check if the number shown in the app is the same as the number that's currently in the database. Then go a level back and check the number of rooms in an entire area and an entire building. Check whether the number are added up correctly.
- Results: The number shown in the app is the same as the number in the database. It also adds the numbers up correctly.
A4
- Testing plan: Open the app and navigate to a screen which shows the vacant and occupied chairs in a room. Check if the number of vacant and occupied chairs shown are the same as the numbers in the database. Also check whether the positions of the dots are in the right position on the screen.
- Results: The numbers of vacant and occupied chairs shown in the app are the same as the numbers in the database. The positions of the dots are however at the moment randomly decided. As the prototype can currently not yet detect the positions of the chairs, the dots are placed at random positions around the tables. The positions are realistic but not accurate. It does however show that the system is capable of placing the dots at the right positions if this information were given.
A5
- Testing plan: Open the app and navigate to a screen which has a information button. Click on the information button and check whether a information panel pops up with the right information.
- Results: An information panel pops up when the information button is pressed. The information shown in the panel corresponds to the right area.
A6
- Testing plan: Let test users try the app and see whether they understand how to navigate through the app to the right screen.
- Results: All test users understood that on the first screen, the different building were buttons and could be pressed to navigate to that building. The screens with buttons showing different rooms and levels were also clear for all test users. Finally, all test users noticed the back button in the top left corner and understood its purpose.
A7
- Testing plan: Let test users try the app and see whether they understand that the numbers shown on the different levels correspond to the number of vacant chairs in that area.
- Results: As the test users knew the purpose of the app, it was clear to them that the numbers showed the available chairs.
A8
- Testing plan: Let test users try the app and see whether they understand that the red and green dots correspond to vacant and occupied chairs at their positions.
- Results: All test users realized that the positions of the dots around the tables corresponded to the positions of the chairs. They also realized that the green dots were vacant chairs. However, not all test user understood that the red dots were occupied chairs and were wondering what they meant. Maybe some sort of legend should be added to these screens to clear that up.
A9
- This can not be tested at the moment, but it should be clear that if this app were uploaded to a public app store for free, every member would have access to it.
A10
- This is also something that has not been implemented in the current prototype.
A11
- Also not the case in the current prototype, but this could easily be implemented without issues.
Neural Network
Using the Yolo Algorithm
The first thing that we thought of when the discussion of detecting objects came, was a Neural Network. In order to detect an object you need powerful type of algorithms that can classify that object, attributing it a label, which in our case is the name of "chair" and its states "empty" or "occupied". The chosen programming language was Python due to its vast Neural Network community and due to is clear and easier to read syntax.
Building a Neural Network can be done in 2 ways:
- Either create your own model, with your own functions and mathematic formulas behind
- Either use an existing model and update in such a way to make it useful for your desired task.
Due to lack of time to create our own Neural Network model, we chose the second option. In recent years, deep learning techniques are achieving state-of-the-art results for object detection, such as on standard benchmark datasets and in computer vision competitions. Notable is the “You Only Look Once,” or YOLO, family of Convolutional Neural Networks that achieve near state-of-the-art results with a single end-to-end model that can perform object detection in real-time. YOLO is a clever convolutional neural network (CNN) for doing object detection in real-time. The algorithm applies a single neural network to the full image, and then divides the image into regions and predicts bounding boxes and probabilities for each region. These bounding boxes are weighted by the predicted probabilities.
YOLO is popular because it achieves high accuracy while also being able to run in real-time. The algorithm “only looks once” at the image in the sense that it requires only one forward propagation pass through the neural network to make predictions. After non-max suppression (which makes sure the object detection algorithm only detects each object once), it then outputs recognized objects together with the bounding boxes.
With YOLO, a single CNN simultaneously predicts multiple bounding boxes and class probabilities for those boxes. YOLO trains on full images and directly optimizes detection performance.
In this project we are using Yolo in order to identify the empty chairs of a classroom. The classification is done as follows:
The chairs can be:
- Empty
- Occupied
These two tags are attributed to the chairs after the following criteria:
* If the chair is clean (it does not have anything in front of it or on it) then the chair is empty * If the chair is empty and someone puts an object in front of it, or sits on the chair, then the chair became occupied
There also exists a small problem, which is that the algorithm does not know at its first look if where is a person there is also a chair. It has to see a chair first in order to give its tag.
Requirements of the model
The model requires multiple objects to be identified accurately in order to function properly. Therefore, we have defined “accurately” in the requirements below as at least 80% percent for our project, where a proof of concept is the most important goal. For the theoretical application of our product a higher accuracy will be necessary. As an example, the Metaforum library has 950 study seats in total. In order to accurately inform users through the app that all these seats are occupied, an accuracy of over 99,9% would need to be achieved. It is true that such an accuracy would be more than enough for each individual chair, as it would be acceptable if only one in a thousand times a user is misled to a supposedly vacant chair that turns out to be occupied. However, when we consider all of the seats in the library together, a false-positive rate of just one in a thousand would still mean that there will on average be one chair available at all times when in reality each chair is occupied. Therefore the accuracy of the model should either be improved considerably or different measures need to be taken to improve the false-positive rate. A possible solution for this would be to let the model analyze multiple frames before determining the status of the chair and sending it to the database. This way a false-positive for a single frame won't immediately lead to a wrong chair count. In order to make this work the algorithm needs to remember chairs across multiple frames and link them as the same entity, which is beyond the scope of this project.
We used the MoSCoW method for assessing the importance of every requirement. In the following table, "must have" means that the requirement in question is a mandatory requirement. Without it, the product does not work. "Should have" means that the product will run more efficiently or more smoothly with that requirement, but the product still works without it. "Could have" means that the requirement in question was possible to have without various constraints preventing it (time, computational power, etc.). Having the requirement in question will make the product more refined, but it works fine without it. "Won't have" means that the product will not work with the requirement in question.
Id | Description | MoSCoW |
---|---|---|
M1 | The model accurately identifies empty chairs, taken chairs, people and laptops | Must have |
M2 | The model accurately identifies miscellaneous objects that indicate a taken chairs, such as jackets, books or notebooks | Could have |
M3 | The model accurately flags chairs with and without a person on it respectively as taken and available (if there are no other objects) | Must have |
M4 | The model accurately flags chairs with and without laptops in front of it respectively as taken and available | Must have |
M5 | The model runs in a loop and processes new images from the camera feed | Must have |
M6 | The model processes at least 1 frame every 10 seconds from the camera feed | Should have |
M7 | The model saves the number of empty chairs found for each area in a database in the cloud. | Must have |
M8 | The model updates the database with this information at least once every 10 seconds | Should have |
M9 | The model keeps track of objects that have been recognized as people. | Won't have |
M10 | The model recognizes people's faces. | Won't have |
Test Plan
(This was our original plan before the Covid-19 outbreak made it impossible to fully perform. We will therefore only be able to perform a restriced version of the test plan that focusses more on validating the individual requirements)
In order to confirm whether we have met our algorithm and user interface requirements the following test plan has been made. We have decided to use one of the OGO rooms in gemini north to test our application. In these rooms one of our laptops can easily be mounted in one of the corners of the room, close to the roof. This laptop will have its camera pointed towards the table below and will have the algorithm running on the images from the camera feed. We plan to make 10 short videos of 30 seconds with all five of us using the room in a variety of scenarios:
- Sitting on chair with laptop
- Sitting on chair without laptop
- Sitting on chair with notebooks
- Different sitting positions (straight/sloppy)
- Walking out of the room
- Walking into the room
- Walking/standing still around the chairs
- Repositioning the chairs
Since our accuracy requirement was 80%, 8 out of 10 chairs need to be correctly identified as occupied or empty. The frames that were analyzed during the testing videos are also saved, so that we can later check how accurate the algorithm was. Additionally, it is also required that the amount of chairs available in the room also needs to be correctly calculated 80% of the time. Since there are multiple chairs, this requirement will most probably be harder to meet, which is necessary, as the amount of free chairs in an area is what is ultimately communicated to the user in our application and this should therefore be the main measure of accuracy. The app will be used to check the amount of free chairs calculated, thereby also validating the correct functioning of the database, where the information is stored and the app that displays the information and can be used to refresh it.
Test Results
Unfortunately, due to the Covid-19 pandemic, we were not able to carry out our original test plan. The amount of footage we had to test our model requirements was limited to the "test" footage we shot before the pandemic. This footage consists of one video and some pictures. The video is about us sitting on chairs at tables with laptops in front of us and also walking around the room for a little bit to switch places. The pictures mainly consist of empty chairs at the table. This was shot in a OGO meeting room in Gemini-South. However, luckily enough the footage was good enough to confirm that every model requirement that was categorised as "Must have" has been met. This means that the model of the prototype was successful, according to our model requirements. If the pandemic did not take place, we would have wanted to shoot more appropriate videos in the same room to test everything else as well, but this unfortunately was not possible.
Detection Steps
In order to manage to complete our final goal I decided to take the following approach in the code: First I had to be sure that the algorithm was able to detect 3 class in our frames: persons, chairs, and laptops because in a optimal environment, I concluded that these 3 classes can provide you a good model of occupied/unoccupied chairs. This will be discussed in the "Future Improvements"' subsection.
In order to detect these specific classes, the Neural Network was trained in the cloud to get the optimal values of its weights and global parameters. After this an own model was created, using the Yolo method in order to find and display the results.
Regarding the Yolo method, it has the following traits:
- It take only one run of a frame in order to give a result. This implies that:
- It trades quality of the result for performance or vice-versa. This means that if you change the input image of the algorithm form 416x416 pixels to 608x608 then the result will be better(a bigger image means a higher quantity of pixels from which you extract the features) but the performance will be lowered.
This can be seen here in the first photo. Input image resolution was 416x416
After the Neural Network was traded and the classes were identified, a start on the Classification problem has been made, which stated "How does the algorithm knows that a chair is occupied or not?" For this, the approach was a follows:
- When computing the classes, we also save the number of items found of that specific class
- When computing the coordinates of the framing boxes also compute and store coordinates of the centers of the objects
- When the framing boxes are drawn also draw the center of the centers
This me approach gave me the possibility to see each frame box ore clear and prepared the data to be classified.
The classification was done as follows:
- For each of the laptops detected
- For each of the chairs detected
- Compute the score between the the laptop and each of the chairs
- Take only store the coordinates of the center of the chair that has the minimum score
- Draw the line between the laptop and the chair
- If the selected chair is already take by a laptop then take the chair that has the next minimum score
- For each of the chairs detected
The first iteration of the score formula was as follows:
- Score = ceil((chair[0] - laptop[0])^2 + (chair[1] - laptop[1])^2)
Where the chair and laptop a list of 2 elements:
- First element [0]: the x coordinate of the chair's/laptop's center
- Second element [1]: the y coordinate of the chair's/laptop's center
The progress can be see in the following 3 images, where the last one has its input image resolution increased to 608x608 pixels in order to get much more information processed
Regarding the third variable in our process, the class of persons increases the difficulty of the object identification and classification.
This can be seen in the following image that has a input image resolution of 608x608.
The problem appears when a person is sitting on a chair but this we be debated in the subsection Future Improvements and in Problems encountered , solutions and workarounds
Data Classification
The classes that our model can detect are as follows:
person bench, backpack, umbrella handbag, suitcase, bottle, cup, fork, knife, spoon, banana, apple, sandwich, orange, chair, dining table, laptop, mouse, keyboard, cell phone, book, clock, scissors,
The main 3 classes on which we are focusing, in order to prove our concept, are: chair, person and laptop We chose these 3 classes, because in an optimal environment to prove our concept, a student is coming to the classroom only with his/her laptop and either places the laptop on the table in order to take seat for himself for later or he sits on the chair and places the laptop on the table.
Furthermore, a student can only sit on a chair thus occupying it. These are our 2 optimal case on which we focus to prove our proof of concept.
Problems encountered , solutions and workarounds
Third class problem
During the development of the algorithm, the following problems were encountered. The first problem was the presence of the persons:
- A person can either sit on a chair
- A person can stay near the table
The problem was that if a person would sit on a chair, then that chair would be obstructed by the person and it would not be recognized by the algorithm. The solution of this problem was as follows.
First, our algorithm assumes 2 things:
- The number of the initial chairs from a classroom is known
- Then number of chairs is fixed so no one can bring a chair with him from another classroom
Secondly, whenever there are persons in the room, we estimate the total number of the empty chairs as follows:
- Let n be the number of total chairs present in the classroom from the beginning.
- Then after the algorithm complete the classification of the objects, the total number of occupied chairs is as follows:
average_h_l = math.ceil((len(center_of_persons) + len(center_of_laptops))/2)
estimated_value_of_occupied_chairs = math.ceil((len(chairsVisited) + average_h_l) / 2)
After finding the estimated_value_of_occupied_chairs we can compute the estimated number of empty chairs
emptyChairs = total_number_of_chairs - estimated_value_of_occupied_chairs
These values estimate the real world behavior of a normal meeting group. Most of the assumptions will be checked via the questionnaire.
Playback problem
Another problem that we have encountered is the playback rate of the algorithm running on a video.
The video can either be a live feed, either a video format file (.mp4, .vmw, etc)
The solution for this has been discussed and stated as follows:
- In order to check the state of the room(the state meaning how is everyone sited and where are the objects placed) we are checking one the 50th frame from a video thus from a video of 30 seconds recorded in 60fps(thus 1800 frames) we check only 36 frames distributed evenly, thus gaining some performance.
Future Improvements
Future improvements can be done regarding 4 things:
- Managing to find a accurate way in order to determine the solution for the Third class problem
- Updating the classification problem with ore than 3 classes such as: books, pens, pencils, notebooks etc.
- Finding a good way to save the real position of the chairs
- Moving from notebook to cloud computing
Regarding the Third class problem one improvement can be as follows:
- Starting the algorithm before the students are present in the room and string the position of the chairs
- Running a separate Neural Network that focuses only on persons and can identify if a person is either standing either is sit
- If a person is sit on a chair then the result of these 2 Neural Networks will conclude that the person sits on that chair.
Regarding the Classification problem an improvement can be done as follows
- Taking into account more than 3 classes.
- Adding more classes can increase the accuracy of the model
- This technique increases the complexity of the model because then your cases will increase exponentially.
- A better algorithm must be developed in order to link multiple object between them that will result in a occupied chair
Regarding the third improvement a solution can be:
- Using a TOF sensor, in order to measure the real world distances between the chairs and between the chairs and the tables and so on.
- With this you could make an accurate map in the app and show exactly which chiar is placed where and which chair is occupied.
Regarding the 4th and final improvement the solution is as it states. Moving our algorithm from our stationary pc(in our case my laptop) to the cloud will give us much more computational power. Thus moving from 0.5 fps playback on a random .mp4 file to more than real time detection.
IoT appliance
What is IoT ?
The Internet of things (IoT) is a system of interrelated computing devices, mechanical and digital machines provided with unique identifiers (UIDs) and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction.
The definition of the Internet of things has evolved due to the convergence of multiple technologies, real-time analytics, machine learning, commodity sensors, and embedded systems. Traditional fields of embedded systems, wireless sensor networks, control systems, automation (including home and building automation), and others all contribute to enabling the Internet of things. In the consumer market, IoT technology is most synonymous with products pertaining to the concept of the "smart home", covering devices and appliances (such as lighting fixtures, thermostats, home security systems and cameras, and other home appliances) that support one or more common ecosystems, and can be controlled via devices associated with that ecosystem, such as smartphones and smart speakers.
Where is our system situated
The requirements of our systems are a room or an open space area and the infrastructure of video surveillance. Our system sis an algorithm that runs on a set of cameras(at least 1) and by using machine learning techniques, it can determine whether or not there are unoccupied chairs in the current room.
Model and design
Regarding the design and the model of our system, our system uses the following design and model:
Design
- A Raspberry Pie that is powered by an external power bank .
- A camera connected to the Raspberry Pi
- The classification algorithm that is running on the Raspberry Pi
- The connection of the Raspberry with the Firebase Database Instance.
- The connection of the Firebase Database Instance with the Android App.
- The Android App.
Model's functionality
In this subchapter will be discussing the base functionalities that each component of the system has to be able to complete.
- The camera functionality:
- It's main purpose is to take the live feed as frames and sent to the main processing unit on Raspberry every 60th frame in order to be processed.
- The Raspberry functionalities:
- It represents the main computational power of the entire system.
- It's functionality is to be a bridge between the camera, the result of the classification algorithm and the firebase database.
- The Classification algorithm functionalities:
- Correctly determine the total number of the occupied chairs.
- Correctly determine the objects present in the room in order to make the classification as unbiased as possible.
- The Database functionality:
- It's main role is to store the data in an understandable manner and provide an instant refresh capability.
- The Android app's functionality:
- It's main role is to retrieve the data from the database and present it to the user in such a way that he/she will be able to determine if a room has or hasn't an empty chair for him.
How the system works
The camera is taking a constant feed of the room in which the system is placed. Every 60th frame of the live feed, is computed by the classification algorithm. The algorithm will find the following 3 classes in the frame: chair, person and laptop. (We considered that this was the necessary number of classes in order to prove our concept)
After it identifies the classes present in the scene, the algorithm will start the process of constructing the occupied chairs by using the formulas stated in the Neural Network chapter.
Furthermore, the algorithm will sent the following values to the database: number of occupied chairs, number of free chairs, and the rest of the chair data. If there will be some values already present in the database, the the algorithm will just update them. This process will be done once every 5 seconds.
When the app is started, it will check if there was somethin changed in the database then it will pull the data and display to the user.
Privacy Policy
The Seat Finder app is built as a free app. This app is provided by us at no cost and is intended for use as is.
This section is used to inform visitors regarding our policies with the collection, use, and disclosure of personal information if anyone decides to use the Seat Finder app.
If you choose to use the Seat Finder app, then you agree to the collection and use of information in relation to this policy. The personal information that we collect is used for providing and improving the service. We will not use or share your information with anyone except as described in this Privacy Policy.
1. Information Collection and Use
For a better experience, while using our Service, we may require you to provide us with certain personally identifiable information. The information that we request will be retained on your device and is not collected by us in any way. The app may use third party services that may collect information used to identify you.
2. Log Data
We want to inform you that whenever you use the Seat Finder app, in a case of an error in the app, we collect data and information on your phone called Log Data. This Log Data may include information such as your device Internet Protocol (“IP”) address, device name, operating system version, the configuration of the app when utilising the Seat Finder app, the time and date of your use of the Seat Finder app, and other statistics.
3. Cookies
We use cookies and similar tracking technologies to track the activity on our Service and we hold certain information. Cookies are files with a small amount of data which may include an anonymous unique identifier. Cookies are sent to your browser from a website and stored on your device. Other tracking technologies are also used such as beacons, tags and scripts to collect and track information and to improve and analyse our service. You can instruct your browser to refuse all cookies or to indicate when a cookie is being sent. However, if you do not accept cookies, you may not be able to use some portions of our Service.
Examples of Cookies we use:
- Session Cookies: We use Session Cookies to operate our Service.
- Preference Cookies: We use Preference Cookies to remember your preferences and various settings.
- Security Cookies: We use Security Cookies for security purposes.
4. Service Providers
We may employ third-party companies and individuals due to the following reasons:
- To facilitate our the Seat Finder app;
- To provide the Seat Finder app on our behalf;
- To perform the Seat Finder app-related services;
- To assist us in analyzing how the Seat Finder app is used; or
- With your consent in any other cases;
We want to inform users of this Service that these third parties have access to your Personal Information. The reason is to perform the tasks assigned to them on our behalf. However, they are obligated not to disclose or use the information for any other purpose.
5. Security
We value your trust in providing us your Personal Information, thus we are striving to use commercially acceptable means of protecting it. But remember that no method of transmission over the internet, or method of electronic storage is 100% secure and reliable, and we cannot guarantee its absolute security.
6. Children’s Privacy
These services do not address anyone under the age of 13. We do not knowingly collect personally identifiable information from children under 13. In the case we discover that a child under 13 has provided me with personal information, we will immediately delete this from our servers. If you are a parent or guardian and you are aware that your child has provided us with personal information, please contact us so that we will be able to do necessary actions.
7. Changes to This Privacy Policy
We may update our Privacy Policy from time to time. Thus, you are advised to review this page periodically for any changes. We will notify you of any changes by posting the new Privacy Policy on this page. These changes are effective immediately after they are posted on this page.
8. In the Event of Sale or Bankruptcy
The ownership of the Site may change at some point in the future. Should that occur, we want this site to be able to maintain a relationship with you. In the event of an (actual or potential) sale, merger, public offering, bankruptcy, acquisition of any part of our business, or other change in control of the Seat App, your user information may be shared with the person or business that owns or controls (or potentially will own or control) the app, provided that we inform the buyer (or prospective buyer) that it must use your user information only for the purposes disclosed in this Privacy Policy.
9. Your right to information, correction, deletion and disclosure of your data
In accordance with legal provisions, you have the right to correct, delete, and block your personal data. Additionally, you have the right to obtain the following information from us at any time:
- Which of your personal data we store
- What our purpose for storing this data is
- Requesting the origin and recipient, or recipient category of this data.
If you wish to perform any of the aforementioned actions with your data, please contact us with the contact information provided in section 9.
10. Contact Us
If you have any questions, requests and/or suggestions about our Privacy Policy, do not hesitate to contact us at [Group 12 contact information].
Logbook
Week 1
Name | Activities (hours) | Total time spent |
---|---|---|
Boris | Brainstorming (1), Research Papers (3), Write Planning (2.5), Write State-of-the-art (4), Write Subject and Problem Statement (0.5), Other Wiki Writing (2) | 13 |
Winston | Brainstorming (1), Look for relevant papers (2), Write subject, objectives, and approach (3),Clean up state of the art (1), clean up the references (1), Wiki writing (2), Rules and Regulations (2) | 12 |
Jelle | Brainstorming (1), Writing users, society and enterprise (4), exploring relevant papers (2), adding to approach (2), Other wiki writing (1) | 10 |
Roy | Brainstorming (1), Exploring relevant papers (2), Write Approach (2) | 5 |
Horea | Brainstorming (1), Look for papers (2), Object detection and neural network (4), State-of-the-art (2), Wiki writing (2) | 11 |
Week 2
Name | Activities (hours) | Total time spent |
---|---|---|
Boris | Meeting (0.5), Update planning (0.5), Clean up state-of-the-art (0.5), Group Discussion (2), App Creation (8) | 11.5 |
Horea | Meeting (0.5), Group Discussion (2), Neural Network Creation (6), Learning to create the Neural Network(4) | 12.5 |
Jelle | Meeting (0.5), User Requirements and questionnaire creation (4), Group Discussion (2) | 6.5 |
Roy | Meeting (0.5), Keep in Contact with Peter Engels (0.5), Group Discussion (2), Design interface (7) | 10 |
Winston | Group Discussion (2), write rules and regulations, mostly the chairs part (4) | 6 |
Week 3
Name | Activities (hours) | Total time spent |
---|---|---|
Boris | Meeting (0.5), Group Discussion (0.5), Contact Engels (0.5), App Creation (10) | 11.5 |
Horea | Meeting (0.5), Group Discussion (0.5), Implementing Yolo object detection on live feed (5) | 6.5 |
Jelle | Meeting (0.5), Group Discussion (0.5), Survey development (5) Contact Engels (0.5) | 6.5 |
Roy | Meeting (0.5), Group Discussion (0.5), Design interface (5), Creating Mockups (2) | 8 |
Winston | Meeting (0.5), Group Discussion (0.5), Contact Engels (0.5), adjust rules and regulations, mostly rooms (5) | 6.5 |
Name | Activities (hours) | Total time spent |
---|---|---|
Boris | App Creation (3), Update Wiki (1), Discussing mockups with Roy (0.5) | 4.5 |
Horea | Creating the database(3), Linking the database to the Neural Network(3), Finalizing the Frameowork (6), Update Wiki(1) | 13 |
Jelle | Asking student outside our group for survey improvement (1), Survey development and layout (3), Researching survey analysis (3) Update wiki (1) | 8 |
Roy | Searching for floor plans (0.5), Discussing mockups with Boris (0.5), Making disregarded mockups(4), Writing Wiki (1) | 6 |
Winston | Adjusted Rules and Regulations (rooms), mostly punishment part (3.5) ; Asked people from other universities what rules and conditions apply (room reservations) and some online searching (3), research on privacy policy (2) | 8.5 |
Week 4
Name | Activities (hours) | Total time spent |
---|---|---|
Boris | Meeting (0.5), Meeting BookMySpace (1), Group Meeting (1.5), App Development (11), Update Wiki (1) | 15 |
Horea | Group Meeting (1.5), Updating the Model (5), Creating the Occupied Chair Classification (5), Linking the Final Model to the database (1), Polishing the code (6) | 18,5 |
Jelle | User interface and model requirements for testing (6), Survey development (1), Survey testing (2), Survey analysis research (1.5), Group Meeting (1.5) | 12 |
Roy | Meeting (0.5), Meeting BookMySpace (1), Writing SoA Planon (2), Adding Design Interface (0.5), Making Floor Plan MF 0 (9), Writing Wiki (0.5) | 12.5 |
Winston | Meeting (0.5), Meeting BookMySpace and finishing the notes (2), Group Meeting (1.5), reviewed the wiki (1.5), continuing Privacy Policy (6) | 11.5 |
Notes Meeting BookMySpace
- Pilots have been done in Meta (for about half a year) to prevent empty rooms from being on reserved. They wanted to test if 15 minutes of no movement in a room was a good way decide if a room should be set to available or not (they used movement detectors). It worked alright but there were some drawbacks (examples: some people don’t move a lot during studying or if someone wants to grab something to eat or drink it would also set the room to available after 15 min).
- At the moment they are also looking at a new sensor from Philips. They have a sensor that can measure body heat and some other things (to prevent various problems of the motion sensor). The problem with this, is that it costs a lot of money, which is also why they didn’t couldn’t implement sensors for each reservable study/workplace.
- Maybe it is possible to combine Planon with our project (but this is more for later if possible, probably not since we only have about 4 weeks left).
- The Planon app can already find available workspaces to study or work at. But you need to reserve it (ours can also be used if you just want to find an available spot somewhere in, for example, the library). But they are still trying to improve it (not really specified on how they’re improving it iirc).
- Apparently, there is not a shortage of study places/workplaces in general, but a shortage in study/workplaces in Metaforum specifically. This is likely because a lot people just prefer to study in that specific building (could be due to the building being relatively silent and there are comfortable to study at).
- They focused more on the tables themselves instead of the chairs. Sometimes a chair might be somewhere where there is no workplace and you also don’t know to which place the chair belongs to. But if there is an area with a lot of occupied chairs and an area with almost no occupied chairs on the map, you can probably assume that the latter has some free study/workplaces somewhere there.
- Some people claim more than one chair by putting their possessions on them. We can try to figure something out for that.
- Currently, there are no real consequences if you don’t follow the social norms. Also, having a lot of consequences for people who don’t show up often (or who violate any of the rules) makes it more difficult to implement it.
- We could add more information to the building/environment/study place on the map/interface (for example, if the study place has electricity sockets or if it’s silent environment).
- Available study/workplaces (the ones with a QR code) can only be reserved for 2 hours (ARBO law).
- We could make it harder for people to not show up by making them invite other people. So, one person can reserve a room for up to 2 hours but if they invite other people, they can get 1,5 hours extra for each additional person for example.
- Notify someone about our end presentation and wiki with an email.
- We could use the system for finding spaces in the canteen
Week 5
Name | Activities (hours) | Total time spent |
---|---|---|
Boris | Meeting (0.5), Group meeting (3), App Creation (9), Update Wiki (0.5) | 13 |
Horea | Group meeting (3) , Studying Machine Learning for optimization(6), Optimizing the code where able(6) | 15 |
Jelle | Meeting (0.5), Group meeting (3), Test Plan (4), adjust requirements (2) | 9.5 |
Roy | Meeting (0.5), Group meeting (3), Struggling with PC* (4) | 7.5 |
Winston | Meeting (0.5), Group meeting (3), Test Plan (4), adjust requirements (2) | 9.5 |
- Due to a problem while installing linux on a external hard disk I had to partially reset my pc so had to reinstall some programs to get back up and running for the project
Week 6
Name | Activities (hours) | Total time spent |
---|---|---|
Boris | Coordinate transformation (5), Update Wiki (1), App creation (2), Group discussion (2), Interface requirements and testing (2) | 12 |
Horea | Group discussion (2), Repairing the RaspberyPy(10), Configuring the RaspberyPy(10) | 22 |
Jelle | questionnaire distribution (1.5), User requirements and test plan (3.5), Group discussion (2) | 7 |
Roy | Mockup creation (4), Group discussion (2), Rewriting / Finalizing Design Choices (4), Updating Wiki (1) | 11 |
Winston | Revised wiki (mainly privacy policy) (2), asked people to fill in the questionnaire (1), adjusting test plan (3), Group discussion (2) | 8 |
Week 7
Name | Activities (hours) | Total time spent |
---|---|---|
Boris | Meeting with Tijn (0.5), Group Meeting (1.5), Further Group Discussion (0.5), App Testing (2), App Creation (1), Make Testing Videos (1), Overall Wiki Check (1), PowerPoint Presentation (2) | 9.5 |
Horea | Meeting with Tijn (0.5), Group Meeting (1.5), Further Group Discussion (0.5), Algorithm Testing(2), Make Testing Videos(2), Presentation Record + Video Edited(4) | 10.5 |
Jelle | Meeting with Tijn (0.5), Group Meeting (1.5), Further Group Discussion (0.5), Survey analysis (4), Rewriting wiki (2), Requirements (1,5) Survey distribution (1) | 11 |
Roy | Meeting with Tijn (0.5), Group Meeting (1.5), Further Group Discussion (0.5), System Design choices (4), Recommended system (4) | 10.5 |
Winston | Meeting with Tijn (0.5), Group Meeting (1.5), Further Group Discussion (0.5), Asking for more respondents (1), Work out results (4), Wiki writing (1), start PowerPoint (1) | 9.5 |
Week 8
Name | Activities (hours) | Total time spent |
---|---|---|
Boris | Tutor meeting (0.5), Groupmeeting (2) | 2.5 |
Horea | Tutor meeting (0.5), Groupmeeting (2) | 2.5 |
Jelle | Tutor meeting (0.5), Groupmeeting (2), Final wiki check (1), Rewriting USE (2), Requirements (2) | 7.5 |
Roy | Tutor meeting (0.5), Wiki editing (1), Rooms rewrite (2), Groupmeeting (2), Rewriting + Wiki editing (0.5) | 6 |
Winston | Tutor meeting (0.5), Groupmeeting (2), Wiki editing (1), Test results (1), Questionnaire text (1) | 5.5 |
Peer Review
For the peer review we have decided that the group members will all get the same mark. Some people might have written less than others but invested their time and effort in other things. Others might have done a bit more but had more problems on delivering it on time or communicating. So, in total with everything that happened we have decided that everyone will get the same mark.
References
- ↑ Kai Chen et al.,"Hybrid Task Cascade for Instance Segmentation"
- ↑ Yudong Liu et al., "CBNet: A Novel Composite Backbone Network Architecture for Object Detection", Sep 2019
- ↑ Zhaowei Cai, Nuno Vasconcelos, "Cascade R-CNN: High Quality Object Detection and Instance Segmentation", Jun 2019
- ↑ Carlo Corsi, "History highlights and future trends of infrared sensors", pages 1663-1686, April 2010
- ↑ Bong, D.B.L., "Integrated Approach in the Design of Car Park Occupancy Information System (COINS)", IAENG International Journal of Computer Science, 2008
- ↑ Acharya, Debaditya, "Real-time image-based parking occupancy detection using deep learning", CEUR Workshop Proceedings, 2018
- ↑ Cai, Bill Yang, "Deep Learning Based Video System for Accurate and Real-Time Parking Measurement", IEEE Internet of Things Journal, 2019
- ↑ Nguyen, Huy Hoang, "Real-time Detection of Seat Occupancy and Hogging", IoT-App, 2015
- ↑ George, Boby, "Seat Occupancy Detection Based on Capacitive Sensing", IEEE Transactions on Instrumentation and Measurement, 2009
- ↑ Faber, Petko, "Image-based Passenger Detection and Localization inside Vehicles", International Archives of Photogrammetry and Remote Sensing, 2000
- ↑ Liang, Hongyu, "People in Seats Counting via Seat Detection for Meeting Surveillance", Communications in Computer and Information Science, 2012
- ↑ Hailemariam, Ebenezer, "Real-Time Occupancy Detection using Decision Trees with Multiple Sensor Types", Autodesk Research, 2011
- ↑ Chrisni, "App helps students find empty study space", University Business, 2014
- ↑ Sevo, Igor, "Convolutional Neural Network Based Automatic Object Detection on Aerial Images", IEEE Geoscience and Remote Sensing Letters, 2016
- ↑ https://www.kiwi-electronics.nl/pim-366?gclid=Cj0KCQjwmdzzBRC7ARIsANdqRRkUsg-t0mHJsYqvDHnaXh2_9f-iEM5mh6Zx6nlUSVyonYZm-ykyR7gaAgL2EALw_wcB
- ↑ https://www.reichelt.nl/raspberry-pi-nul-camera-voor-raspberry-pi-nul-5mp-170-ov56-rpiz-cam-5mp-170-p242690.html?PROVID=2788&gclid=Cj0KCQjwmdzzBRC7ARIsANdqRRlsTczvVNw71UAnh9ichnF7q0_zseop_JK1u6pCXN6F1NoSeUuBMEIaAkxMEALw_wcB&&r=1
- ↑ https://gs.statcounter.com/os-market-share/mobile/worldwide