Ask.GSR, SMU next-gen FBS.
Authors: Ho Jing Yi, Ho Xin Yi, Tay Jing Wen, Foo Chuan Geng, Soh Ze Yu, Lu Zhimao
We’re a team of undergraduate students majoring in Smart City Management and Technology (SMT) at Singapore Management University (SMU). Currently, our team is taking a module called “Smart City Systems and Management” and one of the key milestones for this module is to create a viable product for smart city applications within our campus. It is inevitable that students in SMU face certain issues and through several observations, interviews, feedback, and surveys, we have found a list of problems that students face. Out of the top problems, we have narrowed it down to Group Study Rooms (GSR) where it suits the context of our project. Therefore, we have decided to embark on this project to identify the root cause of students’ frustrations with the GSRs as well as come up with smart solutions that help to alleviate the problems.
Problem Statement
Given a relatively large number of GSRs for students to use for academic purposes, our survey results have found out that a majority of the student population still find it difficult to secure a GSR.
Through much analysis, we have found that the current facility booking system (FBS) is flawed by its technical aspects and user’s misuse such as failure to turn up for their bookings.
“ This has resulted in inefficient use of the GSRs set out to maximize the student’s learning environment. “
With the influx of technology, it is no doubt that smartphones play a significant part in our everyday lives and are in many ways empowering. They have the capabilities of replacing the functions in which computers are providing especially in terms of convenience. Hence, we have decided to take advantage of the smartphone technology and formulate a solution revolving around the use of smartphones which would ultimately bring utmost convenience to the student population.
With that, we shall first dissect the functions of the current FBS.
The current FBS does not support the usage of smartphones to book GSR. Hence, it can be quite cumbersome to book due to an incompatible user-interface. As seen from Figures 1 & 2, the FBS when portrayed on smartphones is not user-friendly. Also, beyond what is shown on the screenshots provided, the selection of booking time slots for the respective GSRs proves to be more of a hassle for users.
Survey Results
From our survey with 91 respondents from SMU, 71% of the students are not satisfied with the current FBS system. Upon further elaboration, the survey results in Figure 3 show the reasons for student dissatisfaction with the current FBS system. The main cause was the difficulty to use FBS on mobile devices as well as the tedious process of booking a GSR. Many also expressed difficulty in finding available rooms.
Furthermore, there is an apparent hogging culture in SMU where students book a GSR, use it to store belongings and leave the room underutilized for a significant duration as evidenced from Figures 4 & 5.
As we can see from the pictures taken, our team observed this behaviour where many GSRs were booked and left unutilized. This can be credited to the endless supply of booking credits and the lack of disincentive to use the rooms in a more considerate way. As such, all of these factors culminate in the situation whereby it is hard to find a space to study in SMU.
From the same survey, we found out that it is almost impossible to find a room if one were to try and book a GSR on the day itself, and most people tend to reserve spaces in advance, without cancelling even if they do not plan on using it.
Significance of Solving Current FBS Issues
As a campus located in the city, SMU has significantly limited spaces as compared to other tertiary education institutes like NTU and NUS. Space constraint is a problem that students have been facing, especially when it comes to looking for space to study. The GSR is one such space that plays an important role in the student’s learning journey in SMU. Hence, our solution aims to solve the existing technical issues of the FBS while alleviating the behaviour of hogging GSRs among SMU students.
Proposed Solution — Ask.GSR
After numerous hours ideating, developing and creating a solution from ground up designed for users’ convenience, we are proud to present to you the future of SMU’s facility booking system, Ask.GSR.
With Ask.GSR, booking of GSR will be done solely through a live telegram chatbot, this means that Ask.GSR can be easily accessed by users through either using their mobile devices or computers as long as they have the telegram application installed. Apart from this, Ask.GSR system is also integrated with Internet of Things (IoT) — ultrasonic sensors with Raspberry Pi in order to prevent the hogging of GSRs or to reduce the no-show rate. The exchange of information between the database, Ask.GSR chatbot and IoT are done by the APIs so that the information can be shared interconnectedly, making our system dynamic. Before we dive into the key feature of our Ask.GSR, a picture of the newly created GSR Booking System (ASK.GSR) process flow will provide you with a bigger picture of our system.
For simplicity, below is the user journey for students when they are using Ask.GSR:
Some further explanation of each key feature that Ask.GSR provides are as follow:
1. Ask.GSR Telegram Bot
Ask.GSR Telegram Bot (@askgsr_smu_203_bot) is the main tool that the user will use to make the GSR booking and it allows users to check their details, view current available GSRs, book a GSR or simply to cancel their GSR booking. We designed this telegram bot with the goal to improve the user’s overall facility booking experiences as compared to the current FBS system. With this goal in mind, we ensure that our Ask.GSR telegram bot booking process is user friendly and straightforward.
Below are the main command handlers that Ask.GSR Telegram Bot offers:
/userdetails
After pressing/typing this command handler, users will be able to view their current GSR bookings, credits*, as well as their information such as the number of penalty** and account status.
*Credits: Credits students will use to book GSR. 1 credit = 1 hour of booking
** Number of penalty: When a user does not show up for his/her booking, their booking will be cancelled and they will be given a penalty. When a user has 3 penalties, their account status will be changed to ‘Inactive’ and they will be banned from making any booking.
/availgsr
After pressing/typing this command handler, users will be able to view current available bookings based on the desired faculty and date chosen by the users.
/createbooking
After pressing/typing this command handler, users will be able to book a GSR by selecting the desired faculty, date, gsr_no, and time slots available of the chosen GSR.
/cancelbooking
After pressing/typing this command handler, users will be able to cancel their existing GSR booking if any by selecting the booking reference.
Additional useful command handlers:
- /start — After pressing/typing this command handler, users will be brought to the main menu, where they can view and select the above command handlers.
- /cancel — After pressing/typing this command handler, users will be able to cancel any existing process that they are undergoing.
For more information on the source code of the bot, please visit: https://github.com/noluvdeepweb209/askgsr_bot
2. Internet of Things (IoT)
Our project also makes use of IoT devices to tackle the hoarding of GSRs as one of the reasons for the difficulties in finding available GSRs is the misuse of FBS to hoard GSRs. Students have no incentive to cancel bookings if they no longer plan to show up and there is no monitoring system in place to ensure proper utilization of the room. As such, GSRs are often empty but booked, or booked for students to dump belongings. In both cases, there is inactivity in the GSRs which is our approach for tackling these problems.
Functions of IoT in Ask.GSR
We decided to install IoT sensors in GSRs to monitor the activity of the GSRs. This will allow us to check if students show up for their bookings or if they abuse the booking and leave the room unattended for extended periods of time. With the data of inactivity, we can release the GSRs that were booked with no students showing up, or students misusing it to store belongings. A sensor will be installed in each GSR and the information within each room will be processed before sending only the status of the rooms to the database that we’ve created. We will send information using API calls, both for updating the database for room status as well as cancelling the room.
IoT System and the reason behind our choice of sensor
We chose to install ultrasonic sensors as the prototype phase due to its accuracy and sensitivity to movement. When investigating the difference between a motion sensor and an ultrasonic sensor, we found out that there were several key considerations that made the ultrasonic sensor stand out as a better choice for our project. All computation and processes were handled by a Raspberry Pi which also sends the data through the internet connection, meaning the whole system can be wireless aside from the power supply.
With regards to configuration, the ultrasonic sensor can be configured via software whereas the motion sensor required manual hardware configurations which we lack the expertise in. The start-up time of the motion sensor is also slower as compared to ultrasonic. Finally, due to the nature of having low speed, the motion sensor is significantly less sensitive to movements as compared to the ultrasonic sensor. We didn’t want to risk any detection error whereby the motion sensor fails to detect any activity and releases the wrong status to the database and cancels a user’s booking wrongfully. In fact, some of us have experienced being in a room and the lights switch off due to motion sensors detecting inactivity. In consideration of future implementation purposes, the complexity of motion sensors is way higher than the ultrasonic variation.
How we make use of IoT to detect activity in a GSR
As the ultrasonic sensor has a narrow sensing cone, we devised a way to accurately calculate the user’s movements in the GSR. Firstly, we had to mount the sensor above the chair level, so that it will detect users rather than any other obstacle in a typical GSR set-up.
We decided on a waist-level height so that users that are standing or sitting will be detected. Also, we aligned it to cover across the areas of the room where users are most likely to sit. Currently, at the prototype stage, the coverage is limited to a cone-shaped area in front of the sensor. For implementation purposes, we will have at least 2 to 3 sensors for fool-proof detection.
The ultrasonic sensor detects obstacles in front of the device and measures the distance between itself and the obstacle. As such, we used this feature to compute if there was any activity in the room. Every 5 minutes, the Raspberry Pi activates the ultrasonic sensor to take the average of a burst of 3 readings. It then stores the values until the 30th minute. By doing a simple calculation of range between the minimum and maximum distance recorded, we can determine that there was activity in the room. The data is sent to the database and the list is then cleared for the next 30 minute’s data.
How we integrate our IoT system to our database
The Raspberry Pi uses API calls to update the GSR’s room status. Checking the room status every 30 minutes will ensure that users show up for their booking. In the event that users did not show up for their booking, their booking will be automatically cancelled. Incorporating an IoT system in Ask.GSR helps to minimize the no-show rate and the automatic cancellation of booking opens up more GSRs for users that really need it.
For detailed information on the IoT system, click here
3. System Monitoring
Having an effective monitoring system is crucial for Ask.GSR as any down-time of the system will lead to many inconveniences, especially for the user. In order to minimize the downtime of our system, Ask.GSR is equipped with two system monitoring tools. One monitoring system will be used to monitor the APIs of the main Ask.GSR flask app and another system will be used to ensure that our IoT sensors are working properly.
Monitoring of Main Flask App
In order to ensure that the APIs of our main flask app is always up and running, we used Freshping by Freshworks, an open-source website monitoring software to monitor our APIs.
Why use Freshping?
Freshping is a reliable website monitoring system that is equipped with simple and user-friendly interfaces. It provides us with many useful features such as a dashboard for APIs monitoring, instant downtime alerts via email, weekly APIs performance reports.
Freshping Dashboard
Freshping dashboard allows the team at Ask.GSR to check all the status of our APIs, the downtime (in minutes) as well as the average response time of our APIs. With this dashboard, the team at Ask.GSR will be able to check all the status easily and also get to pick out on which APIs needed further improvement based on the response time.
Instant Downtime Alerts
Instantaneous email alerts to notify the team at Ask.GSR, when an API is down, will allow the team to solve the issue as soon as possible to minimize the disruption to Ask.GSR facility booking services.
Weekly Reports
With a weekly report for each API, the team at Ask.GSR will be able to better understand the reason behind each downtime incident. Through this, the team will be able to do improvement of the Ask.GSR system based on the reason surfaced and reduce the downtimes of the system in the future.
Monitoring of IoT Sensors
Apart from monitoring Ask.GSR main flask app APIs, we also implemented a telegram bot system alert to notify the team via telegram in the event that an ultrasonic sensor is down due to technical issues. This alert will enable the team to solve the technical problems as soon as possible to minimize the disruption of services.
4. Future Analysis
Although data by itself is just facts and figures, the team at Ask.GSR understands that the data we collected can become an important asset to us if we did a useful analysis of it. The two main data we are collecting to conduct exploratory analysis on would be the room status of all GSRs every 30 minutes interval (during operating hours) and GSR bookings that got cancelled due to inactivity/no-show.
The following example we are going to show you will be done on Jupyter Notebook with various python libraries. However, data analysis of the data collected can definitely be done on other platforms as and when needed. Using Jupyter notebook, one example of what we can do with the data collected would be visualizing the room occupancy of a specific GSR in a week.
With the visualization of room occupancy done above, we will be able to analyze whether there is an underutilization of a specific GSR. In the event that a GSR has a low occupancy rate when all the other GSRs have a high occupancy rate, it can be an indication that the GSR with a low occupancy rate has issues such as dull lighting, wifi connections problem, etc. These issues may defer students from booking it which results in the low occupancy rate. With this in mind, the team at Ask.GSR will be able to investigate what is the reason behind the low occupancy rate and seek ways to improve the occupancy rate to ensure that all GSRs are fully utilized.
Apart from this, the visualization of room occupancy of all GSRs in one bar chart is also possible. By doing this visualization, the team at Ask.GSR will be able to know whether the GSRs are underutilized or if there is a need for additional study facilities.
The type of analysis we can do with the data collected is not limited to the examples given above and the results of the analysis at different points in time can vary. Integrating a data analysis component in Ask.GSR is important as it helps us identify underlying problems that we may not have been aware of and also allow us to explore data in meaningful ways. This is the reason why we decided to ensure that we incorporate a feature in our system to store data that is useful for future analysis.
So why Ask.GSR?
Brings convenient to students
Once students switch over from the old FBS booking system to Ask.GSR, they can expect to enjoy the convenience that Ask.GSR brings. Ask.GSR saves students the hassle of finding a space to whip out their laptops just to book a GSR as our telegram bot is both mobile and computer friendly.
Improved UX
Gone are the days with the laggy booking interface. Ask.GSR uses Telegram as our main and only booking interface that the students will interact with. Detailed instructions are given throughout the whole booking process with each telegram message thus, students can book with ease. Not only that, due to our school culture, most of the SMU students also have Telegram installed on their mobile devices and laptop, which makes adopting this UX not a challenge at all.
More GSR available to students
With the help of IoT devices and blacklist systems, it will minimize the hogging of GSRs in SMU and thus, allow more GSR to be available to students who need it.
Assumption and Limitations
Assumptions
During the process of developing the ideas, we made a few assumptions. These assumptions are as follows:
All the information of the GSR and Students details including their telegram ChatId will be given by school through a CSV file
Since students need not register for an account with Ask.GSR, our authentication measure over here is the student’s telegram chat id. Thus, we need to assume that all students have installed telegram and have given their telegram chat id to the school. In addition, Ask.GSR is not an independent application by SMU, we assume that the changes in terms and conditions of Telegram will not affect our Ask.GSR telegram bot.
SMU have enough fundings for installation and maintenance of IoT devices for GSRs
Since there are many GSRs in SMU, we assume that SMU has adequate fundings to install IoT devices to the GSRs. Additional funds will also need to be set aside for the maintenance of IoT devices.
Limitations
Below are some limitations of our project:
Absence of some facilities in SMU
Due to time constraints, our project only covers the booking of GSR and not other facilities that are under our current FBS booking systems such as seminar rooms and meeting lounge. More time will be needed to incorporate the other facilities.
Absence of other faculties in the selection
As it is in a prototype stage, we chose to only focus on the School of Information System (SIS) due to time constraints. More faculties will be added in the future.
Ask.GSR system is not independent
Solely relying on telegram bot as our main booking interface for students might not be reliable as it is a third-party source. In the event that the third-party telegram system is down, we do not have the guarantee when it will be up and this will hinder the students from booking any GSR. In the future, the application could be moved to an independent mobile application to ensure that the system is foolproof. This way, even if the system is down, we will be in control and get the system back up as soon as possible to minimize the impact it may make on our students.
Conclusion
Overall, this project gave us a fulfilling experience in development. We learned how to develop and manage a smart booking system. The challenges and difficulties we faced when designing, implementing and managing our smart booking system make us understand that every single component in the system is important and we need to take into account even the smallest things to ensure that our system will work properly. To design, implement and manage a smart city system is definitely not an easy task so we would especially like to thank Prof. Tan Hwee Xian for her insightful feedback and for guiding us through our whole project.
Additional Code Resources:
Ask.GSR website: https://hjy1998x.wixsite.com/smt203
Telegram Bot: https://github.com/noluvdeepweb209/askgsr_bot
IoT System: https://github.com/sohzeyu/ASK.GSR-IoT-System
APIs of Ask.GSR main flask app and analysis flask app: https://github.com/Jingyiho98/smt203-databasesnothers
