PRE2023 1 Group3: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
Tag: 2017 source edit
Tags: Blanking Visual edit
Line 1: Line 1:
<br />
{| class="wikitable"
|+Members
!Name!!Student Number!!Study!!e-mail
|-
|Wilbur van Lierop||1703870||Applied Mathematics||w.p.v.lierop@student.tue.nl
|-
|Quincy Salden||1749900||Applied Mathematics||q.salden@student.tue.nl
|-
|Jerome Bleyendaal||1483870||Electrical Engineering||j.bleyendaal@student.tue.nl
|-
|Jack Grunfeld||2064677||Exchange (software and Robotics engineering)||j.w.v.grunfeld@student.tue.nl
|}
GitLab link: https://gitlab.tue.nl/20233137/projectrobotsg3/-/tree/main (please note git is not currently working for me (Jack) so I have uploaded the import code files for viewing, and the .zip file of the actual program.


=='''Introduction'''==
The TU/e, University of Technology Eindhoven, is a large university where over 10.000 students and 2.000 staff members come together to educate, research, and learn about technological sciences. TU/e shares its location with Fontys, an university with a few thousands students as well. In total, the schools have around 20 buildings that are home to lecture rooms, meeting rooms, study spots, cafeteria’s, and a variety of other facilities.
For newcomers to Eindhoven it will initially feel overwhelming navigating the campus grounds. Buildings of course follow a certain structure when it comes to labelling their rooms, using signs to sent you in the right direction. However, despite this organization it can still feel like walking around in a maze, especially when a certain route is blocked off, or when your destination is not indicated by signs, such as printers and water fountains. Not being able to find your destination is never appreciated, especially if it means arriving late for classes, meetings or exams.
It is for this reason that we wish to find out which problems newcomers to the campus experience, and hopefully provide a way for them to navigate around campus more efficiently. Additionally, we shall not restrict our focus to just guiding newcomers from A to B as quickly as possible, as we will also take into account students and staff that are already a little familiar with the TU/e that struggle finding particular amenities, or that are interested to discover alternative routes that would also guide them from A to B.
Since we put our attention to people that study or work at a technological university, we find it appropriate to find a solution in a digital environment. To be more concrete, we envision making a digital map with a corresponding app as our solution for the problems navigating the campus, as this will be available to all students and staff, and is of course easily accesible to everyone with a smartphone.
=='''Objective | Problem Statement'''==
The aim of this project is to create an interactive mapping solution tailored to the needs of TU/e students and staff, which entails providing the user with essential information about campus facilities, including building locations, lecture rooms, study spots, bicycle parking, and more. The project focusses primarily on guiding around first-year students and newcomers to the Eindhoven campus, and secondly focusses on providing a way for students already a little familiar to the campus alternative routes for navigating themselves around, or providing them information about events and out-of-order amenities.
=='''Target user'''==
'''1. First-year students and newcomers to Eindhoven:'''
*'''Orientation:''' First-year students and newcomers are often completely new to the university campus with its corresponding structure. They may not be familiar with the layout of the campus, the locations of key facilities, or the services available to them.
*'''Needs:''' They require guidance and support to navigate the campus efficiently. They may also seek information about academic resources, extracurricular activities, and student services.
*'''Challenges:''' Finding lecture rooms, study spots, and other essential places can be challenging during the initial days. They may also face difficulties in understanding the campus culture and community.
'''2. TU/e students and staff that are somewhat acquainted with the campus:'''
*'''Orientation:''' Typically they are already familiar to the structure whithin the buildings of the TU/e campus, though they might for example be unaware of all facilities and study spots available to them. Also, they might often take a longer route to get from A to B as a consequence of not knowing alternatives.
*'''Needs:''' They require to be time-efficient most of the times, though sometimes they might wish to deviate from their usual options and try-out new ones, such as finding a study spot in a different building opposed to the building they would usually settle for, or they might wish to take more outside walks when going from one building to another, but only know the indoor route.
*'''Challenges:''' Finding rooms in case their <nowiki>''</nowiki>usual<nowiki>''</nowiki> route is blocked off by constructions, or facilities when the known options are out of order. Further, they require to be time efficient and therefore need up-to-date information about events.
THE FOLLOWING SHOULD EITHER BE INTEGRATED WITHIN ABOVE 2 USER, OR DELETED!!!
'''3. %Diverse Backgrounds:'''
*'''%International Students:''' TUe attracts a diverse student body, including international students. This diversity adds to the complexity of the target audience, as language and cultural differences may %influence their needs and preferences.
*'''%Varied Academic Disciplines:''' TUe offers a range of academic programs, each with its unique requirements and facilities. Understanding these variations is important when tailoring the solution.
=='''User portfolio'''==
Based on our own visions of the needs target users have, we came up with a user portfolio. This portfolio strictly covers common problems first-year students, newcomers, and the other people to which TU/e is their working place, experience at the TU/e. This is useful to us, as this provides a general direction for the project, and helps us establish a user-survey which either hopefully confirms our thoughts on what the user needs and requires, or it will otherwise hopefully give us new insights which will be beneficial for the product design.
Here is the list of problems and difficulties we thought of, with a brief explanation if applicable:
*Underestimating walking times from one building to another; In general it is very stressful being late for your lectures due to not being able to find the right room or underestimating the time required to get from one place to the room. Especially at time of exams, being late can have negative consequences.
*The bicycle parking in front of Atlas is always full, making it difficult to get your bike out of the racks. Many students do not know where to find alternative parkings.
*Finding the stairs and elevators in particular buildings.
*Parking your car at TU/e; Finding a spot at around 11:00 can sometimes take over fifteen minutes.
*Finding a good study spot without reservation can be a pain, especially finding a spot where you can sit with a couple of friends.
*Irregular building opening hours.
*Finding lockers. A relatively high percentage of lockers is usually occupied, and additionally, a high percentage of lockers is often out of order.
*Long lines at cafeteria's like Subway during lunch break and coffee machines in the brakes of lectures.
*Events taking place, e.g. the career expo in Auditorium, with as consequences the Subway being closed and making Auditorium not really pleasant for studying.
*Presence of AED machines, first-aid kits, and fire extinguishers in case of an emergency.
*Finding gender-neutral restrooms.
*Ping-pong equipment for the ping pong tables.
*Parking for people with a disability.
=='''Survey'''==
===='''Survey methodology'''====
We conducted a survey to gather insights from TU/e students, with a focus on first-year students and newcomers to Eindhoven. The survey was distributed to various participants via social media. Participants were informed that their responses would be kept anonymous. The survey was open for a week and yielded 40 respondents.
===='''Survey results'''====
A total of 40 participants contributed to the survey, providing valuable feedback on various aspects of campus navigation.
'''First-Year Status:'''
When asked if this was their first year at TU/e, 15 respondents (37.5%) indicated that they were first-year students, while 25 respondents (62.5%) reported that they were not.
'''Campus Navigation Challenges:'''
A significant number of participants acknowledged facing challenges in finding various campus facilities. Specific issues included locating specific rooms, such as those in Metaforum zaal 11-15 and OGO rooms in Atlas. Participants also mentioned difficulties in navigating between buildings, especially those less commonly visited, such as Fenix. Additionally, finding study spots, rooms, and parking spaces posed challenges for some participants.
'''Usefulness of App Features:'''
Participants were asked to rate the usefulness of potential features for the campus navigation app. The highest-rated features included room finder (average score: 4.18 out of 5), study place finder (average score: 4.1 out of 5), and printer finder (average score: 4.08 out of 5). These results highlight the importance of features that aid in locating specific facilities within the campus.
'''Events Information:'''
A majority of respondents (average score: 4.35 out of 5) expressed interest in a feature that would display information about social and academic events happening on campus, such as open days for sports associations and lunch lectures.
'''Location Tracking:'''
In response to the question of whether they would allow the app to track their location for navigation purposes, 23 participants (62.2%) indicated their willingness, while 14 participants (37.8%) preferred not to. This would allow for the possibility of dynamic features which uses location tracking.
'''Reporting Broken Amenities:'''
A significant proportion of participants (75%) expressed their willingness to actively participate in keeping the interactive map up-to-date by reporting broken amenities through the app.
'''Additional Ideas:'''
Some participants shared additional ideas for the app, including providence of information on building opening and closing times, walkways, food and drinks spots with their menus and operating hours, and the possibility of including humorous comments from teachers and students.
=='''User Scenarios'''==
Based on the survey responses, and our own mindmap, four user scenarios have been established to provide a better vision for the scope of our project.
<u>User scenario 1:</u>
Dylan is a 19 year old boy from the Netherlands, right on the voyage of starting his bachelor time at TU/e. In high school he was pretty chaotic, never able to put structure in his daily routines, causing him to often be late for class, and sometimes even for exams. At university he hopes to make a fresh start and try to get into a daily rhythm that is not as chaotic as in high school.
In order for him to fix his bad habit, he wants to start showing up on time. He would like an interactive map that shows him the fastest route that guides him to the right lecture room. He also likes to have up-to-date information about opening hours of cafeteria’s, and how busy they are, as he often forgets to bring his own lunch. Lastly, he requires some assistance with finding good places to study, as he is pretty chaotic and easily distracted when working in crowded areas with much distraction.
<u>User scenario 2:</u>
Emmi is a 28 year old high school teacher who occasionally tutors at university for specific courses related to teaching. She has been in a wheelchair since the age of ten, and she has just gotten a request to tutor a group of students following a course that prepares them for educating high schoolers in a particular subject.
Her disability is something that costs her a lot of time and effort, since a lot of buildings, especially older ones, tend to be very unclear with showing where wheelchair entries are. Apart from that, it is often a struggle to navigate across the hallways of buildings, since she often encounters obstacles that prevent her from following the shortest route available. She also feels bothered when other people have to make space for her so that she can pass through, so she often goes to her lecturing rooms well before the start of her lecture. Therefore, she likes to have some assistance for navigating across buildings on campus, with in particular information about where she can enter buildings and which hallways are wheelchair-friendly. Additionally, some facilities like coffee machines are not particularly well designed for people in wheelchairs, and because of Emmi’s willingness to be independent, she would really appreciate it if she had a good overview of all coffee machines that allow her to get coffee herself.
<u>User scenario 3:</u>
Max is a 18 year old boy from England, born as a female kid, but Max did not feel at the right place of the spectrum, and underwent a program that altered his gender, making him a transgender. Max had a difficult time at high school due to him not feeling comfortable going to the toilets, as there were no gender-neutral ones, and similarly for locker rooms. Another characteristic of Max is his poor sense for orientation and navigation, and difficulties adapting to new environments. Max also tends to sleep very little usually, so he requires 2-3 coffees per day to keep active. Lastly, he is very smart, and just started with an exchange program at TU/e for software engineering.
Max would really appreciate an app that can help him get to his right location on campus, since he considers the campus really big, and poorly structured. Buildings, lecture rooms, meeting rooms, elevators, and water taps are all considered to be hard to find. In specific, he really struggles with finding gender-neutral restrooms, as this relatively new concept is not yet adapted in most buildings. Besides that, he would find it helpful to always know the closest coffee machines a his disposal. This is because he has to walk pretty far when going to the toilet, so he does not want to spend as much time searching for coffee.
<u>User scenario 4:</u>
Tris is both sporty and very clever when it comes to studying. She likes going for outdoor runs as often as she can, preferably through nature. She is 22 and is enrolled for a masters program at TU/e, after easily completing her bachelor elsewhere. She is a bit of an environmentalist, an art-lover, and likes to explore new places.
Tris would like an app with a map that can help her navigate around her new university, but also makes adaptations to the route when she wants to explore where an interesting path might lead her. She also hates using the elevators, so she prefers to strictly take the stairs if able. And in case the weather is really nice, she would love to take an outdoor walk if she has to go from one building to another, but if it is raining, she rather limits this to just staying indoors.
=='''Project Requirements, Preferences and constraints'''==
In this chapter, we outline the components that will shape the development of the interactive campus map for the TU/e. The RPC-list (Requirements, Preferences and Constraints) serves as a guide for our project, to ensure we work towards an end project which aligns with not just our own vision and goals, but especially those of the users. We recognize that our user's input is very important, if not the most important, and have therefore taken their opinions into account when making this RPC-list.
===='''RPC-List'''====
===='''Requirements'''====
'''Map accuracy and completeness:'''
*The interactive map should accurately represent the TU/e campus layout. (The prototype shall only include a layout of the inside for atlas floor 8.)
*It should include information on important facilities, such as buildings, room numbers, study spots, etc.
*It should have a navigation system allowing users to find rooms or buildings.
*The navigation should be able to determine the fastest route from the entrance of atlas to any room on the 8th floor. (The prototype might be limited to only a few rooms.)
*Navigation system should be able to determine how long a route takes.
*It should be able to find the nearest toilet and determine the fastest route, given a certain starting position.
'''User-friendliness:'''
*The app should be easily accessible and free to all TU/e students and staff.
*It should have a user friendly interface.
*It should have a search function to be able to find specific buildings, rooms or amenities.
*The app should allow the user to scroll over the campus and see lay-outs of all key rooms of all buildings.
*The map should allow the user to easily toggle between different floor of a building.
'''Feedback system:'''
*The app should have a feature allowing users to report broken amenities.
===='''Preferences'''====
'''Integration with campus system:'''
*The mapping system should be integrated within the TU/e app to make it easier for the user. On the other hand, the app should of course also be accesible for outsiders that plan to visit the university and are in need of help traversing the campus.
*This integration should allow users to be able to reserve rooms and study spots through the app.
'''Multilingual support:'''
*The app should have support for multiple languages, as there are many users with various backgrounds.
'''Real-time data:'''
*The map should provide real-time information on disruptions and availability of buildings, rooms or bridges between buildings.
*It should also provide information on how busy certain area's are or if certain study spots are available.
'''Campus social hub:'''
*The app should have a social hub showing events and social activities in the near future.
===='''Constraints'''====
'''Time constraints:'''
*The project should be finished within the span of this course.
'''Data constraints:'''
*Users might not agree to share their location, rendering any dynamic map features less effective.<br />
=='''Vision'''==
In order to develop a dynamic application which allows students to have clear and useful hub for information around campus, the following features are deemed most important and therefore require primary focus:
*easy and accessible navigation
*frequent and reliable updates about on-campus amenities.
*information about Cafes/food/drink locations around campus.
*vital knowledge such as bathroom locations, tire pumps, water dispensers.
*access to social hub networks such as events, clubs and gatherings.
*information about study zones and busy timeframes.
=='''Key Features'''==
*'''Real-Time Updates:''' Implement a dynamic system for real-time updates, including alerts for occupied bicycle parking areas, out-of-order coffee machines, and suggestions for available study spots.
*'''User Engagement:''' Encourage user engagement through features like reviews, ratings, and reporting mechanisms, fostering a sense of community among TUe students.
*'''Mobile Accessibility:''' Ensure that the interactive map is accessible via mobile devices, allowing students to use it conveniently on the go.
*'''Path finding:''' To have the ability to show the best route to locations around TUe. (Using A* search or Dijkstra's algorithm).
=='''State-of-the-art Research'''==
*https://www.mazemap.com/    Mazemap introduce themselves as follows: ''"MazeMap is an innovative digital wayfinding platform, offering solutions for large campuses such as universities, hospitals, offices, hotels, and event venues. In addition to wayfinding, we also offer space booking & visualization tools, indoor positioning, IoT integrations and more."'' One nice feature of Mazemap is the <nowiki>''</nowiki>Find Closest Available<nowiki>''</nowiki> feature, which performs the action described by its name for a few types of facilities. Another particularly unique feature is their heatmap function, which can provide information about places of a building experiencing high traffic. This feature would be helpful in preventing areas on campus becoming way too crowded, which we consider to be a problem worthy of implementing in our campus map. One example where Mazemap is being used is the NTNU (Norwegian University of Science and Technology), where Mazemap became very popular with as two main use-cases the planning of meetings, events, conferences and visits, and navigation around campus by users of the app. It helped students save a lot of time, and optimize their schedules. Mazemap also receives praise for allowing it to implement other services, such as space booking tools, allowing the users to just look in the app where there are unoccupied study spots, and which spots are readily being used.
*
*
*https://maps.syracuse.edu/?id=1275#!ct/48860,43018,42873,34415,34413,34416,38441,38498,38500,38611,38612,38613,38617,53074,53075,57269?s/  [[File:Saraceusa University.png|thumb|Syracuse navigation feature]]Syracuse University has their own interactive campus map. One nice feature of this map is 3D-renderings of the exterior of buildings. Furthermore, it has as sidebar with grouped facilities like parking and dining options. It also provides an outdoor-navigation system, though on the webbrowser it does not really function very user-friendly. The wayfinding feature also works between two places in the same building, though the route is not displayed clearly, as it maintains the outdoor-navigation view. Interesting to note is that this map is only accesible as a website, and therefore not as an app. With well over 100 buildings and 20.000 students enrolled, one might suspect to prefer an app over a website, as apps tend to be easier to access on mobile phones.
*Işıkdağ, Ü., Zlatanova, S., & Underwood, J. (2013). A BIM-Oriented model for supporting indoor navigation requirements. ''Computers, Environment and Urban Systems'', ''41'', 112–123. <nowiki>https://doi.org/10.1016/j.compenvurbsys.2013.05.001</nowiki>
#<nowiki>''</nowiki>A BIM is a digital representation of all the physical and functional characteristics of a building through its entire life cycle.<nowiki>''</nowiki>
#<nowiki>''</nowiki>Semantic information is a clear definition (and naming) of building storeys, elements, spaces, as their usage would support better orientation and guidance.<nowiki>''</nowiki>
#<nowiki>''</nowiki>Primal models include a geometric representation in 3D Euclidean Space and a topology representation for expressing the relationships between building elements. Dual(s) of these models are a network (metric graph) for representing the physical connectivity and a graph (logical graph) for denoting abstract connectivity in a building.<nowiki>''</nowiki>
#<nowiki>''</nowiki>The representations in the primal layer are mainly utilized for information provision, retrieval and visualization purposes. The geometric networks and graphs in the dual layer are usually derived from the primal representations and used to compute the required (i.e. shortest, fastest) navigation path.<nowiki>''</nowiki>
#<nowiki>''</nowiki>BIMs contain advanced geometric and semantic representation of the building elements and they are considered as the most valuable source for representing and managing building information through the lifecycle of a building.<nowiki>''</nowiki>    - <nowiki>''</nowiki>In the development of the new model, IFC was selected a source BIM standard, as it is the mainstream schema standard of Building Information Modeling.<nowiki>''</nowiki>
*Schuldt, C.; Shoushtari, H.; Hellweg, N.; Sternberg, H. L5IN: Overview of an Indoor Navigation Pilot Project. ''Remote Sens.'' 2021, ''13'', 624. <nowiki>https://doi.org/10.3390/rs13040624</nowiki>  This article poses the project Level 5 Indoor Navigation, which has the aim to show how 5G signals can be used for indoor positioning in <nowiki>''</nowiki>navigation systems, which have thus far only been available in the outdoor segment, can now be integrated into existing smartphone systems for indoor navigation.<nowiki>''</nowiki> Here are some key findings of this paper that are in correspondence with our project:
#When it comes to indoor positioning for navigation, the most-used techniques today are Bluetooth and WLAN, but these methods have the downside that a client server has to be held up in order to work.
#This project also uses a university as demonstration location, where building information modelling was used for positioning.
#The paper explains that in theory it should be possible to create a map data set quickly and easily by just using escape and rescue plans, which exist for a lot of universitial buildings.
#The underlying motivation for using BIMs for the L5IN project: <nowiki>''</nowiki>The advantage of working with BIMs is that different information about a building can be collected centrally within a data set. Information that otherwise comes from different sources (such as drawings, tables, presentations, and charts) can be bundled within a BIM. The fact that working with BIMs allows the use of a combination of semantic, geometric, and topological attributes is one reason for their growing usage in different cases.<nowiki>''</nowiki>
#In regard with the aim to create a digital map, the following quote seems worth mentioning here: <nowiki>''</nowiki>Due to the already mentioned role of the model as a single source of information for relevant building information, it makes sense to generate the required maps directly from the model. A distinction must be made whether the modeled 3D geometries of the BIM should be used directly for a navigation application or if they should be abstracted from the 3D geometries and used as a 2D map.<nowiki>''</nowiki>
*Pauwels, P., De Koning, R., Hendrikx, B., & Torta, E. (2023). Live semantic data from building digital twins for robot navigation: Overview of data transfer methods. ''Advanced Engineering Informatics'', ''56'', 101959. <nowiki>https://doi.org/10.1016/j.aei.2023.101959</nowiki>  Note: This paper was recommended to us by E. Torta, after sending her an email with regard to building information modelling. Additionally, we received access to two Gitlab repositiories which          contained the data and instructions used for the research covered in this paper.  This article covers a research in which the use of BIM models for the localization and navigation for autonomous robots is investigated. Useful to note is that a direct connection between a robot and a server with BIM data files can be established and used for real-time data updates. Further, the paper categorizes 5 methods for the data transfer from the BIM-environment to the robot, after which they proceed by mainstreaming three promising transfer methods based on their literature study. These transfer methods are: 1. Traditional IFC-based file transfer 2. Live linked data server 3. JSON-based web services.  The research is conducted at the TU/e. To be more specific, the 8th and 9th floor of the Atlas building. For these stories, BIMs were used for the implementation of two of above-mentioned transfer methods. Our group was granted access to the same BIMs, so a few more details about their contents will be provided here. The key elements in these BIMs are:
*#Space: an empty area that is available for use, and that is bounded by either physical or virtual boundaries
*#Interface: a generic concept to qualify the relationship of two or more things in the world, where at least one is a building element or zone. We limit our interpretation here by considering the interface the relationship between a space and a bounding (virtual or physical) element.
*#Element: a construction entity with a characteristic technical function, form or position.
About the process of transferring the BIM data to data for the robot's navigation, the following is stated: "First, the BIM model is transformed into a JSON dataset. After the JSON content was created, it was transformed into JSON-LD, which can be used to build a 2D vector map for robot navigation (PNG). Finally, robot navigation takes place.<nowiki>''</nowiki>
=='''APP DEV'''==
===Research:===
To gain insights into user needs for app, I employed a comprehensive research approach that combined surveys (see survey section) and conversations with fellow exchange students at TU/e, much like myself. Surveys allowed for structured data collection, enabling us to understand broader preferences and pain points, while one-on-one conversations offered a deeper, qualitative perspective. By engaging with the user community directly, I was able to gather firsthand feedback, uncover specific requirements, and identify nuanced user expectations. This multifaceted approach ensured that the resulting app design was rooted in the real needs and experiences of its intended users, ultimately leading to a more user-centric and effective solution.
<br />
===Features:===
*'''Map View:''' The Map View displays a map of the TU/e campus, allowing users to navigate the campus easily. It includes the user's location and offers a visual guide to find their way around the university.
*'''Service View:''' The Service View provides a search functionality for various services on campus, such as accessibility ramps, lecture theaters, study rooms, and more. Users can quickly find and access these services, making their campus experience more convenient.
*'''Event View:''' The Event View presents a calendar with events organized by TU/e, allowing users to stay informed about upcoming activities, meetings, lectures, and room locations. This helps users plan their schedules and stay updated on university events.
*'''Food and Drink View:''' The Food and Drink View offers information about cafes and food locations on campus. Users can easily locate places to grab a bite or a cup of coffee, enhancing their overall campus experience.
*'''Profile View:''' The Profile View allows users to access and manage their profiles and personal information. This feature offers a personalized experience, enabling users to customize their settings and preferences.
*'''Settings View:''' The Settings View offers users the ability to adjust app preferences and configurations. It gives users control over their app experience, making it more user-centric and adaptable to their needs.
<br />
===Development Process:===
developing app using SWIFT and Xcode, for seamless easy app development, see gitlab for code Updates.
[[File:Mindmap.png|center|thumb|1200x1200px]]
<br />
===Future development:===
*'''Feature Development:''' A deeper understanding of feature development is essential. This means continually improving and expanding features to meet the evolving needs of users.
*'''Map Implementation:''' Enhancing the map features and adding routes for events and amenities would greatly improve navigation and event engagement.
*'''Layout Development:''' Ongoing layout development ensures that the app remains visually appealing and user-friendly, keeping it in line with design trends and user preferences.
*'''Profile and Login Pages:''' Expanding the profile and login system with TU/e branding and background imagery can create a more immersive and personalized user experience.
*'''Proximity Method:''' Adding a proximity feature to show nearby amenities is a valuable addition, as it enhances on-campus navigation and user convenience.
*'''Improved Location Estimation:''' Developing a more precise location estimation method can help users better understand their relative position on campus, aiding in navigation.
*'''Event Information Boxes:''' Implementing information boxes for events and linking them to navigation functions is a user-friendly enhancement. It simplifies event attendance and navigation.
*'''Astar Algorithm Redesign:''' Correctly implementing the Astar algorithm and improving its user interface can make the app more efficient and user-friendly for generating images from Jerome work.
Overall, your focus on simplicity, usability, privacy, and feature enhancements are great practices in app development, and the planned future developments show your commitment to continuously improving the user experience
===Issues:===
Swift is the primary language for iOS app development, so in order to implement the indoor path finding, we approached it with two ways, one to run a python script/file through the swift application. Running the provided algorithm using a Python file within a Swift project on iOS is not straightforward due to the limitations of the Swift PythonKit library, which primarily supports macOS applications. iOS apps have a different runtime environment and system architecture, which is significantly more constrained compared to macOS. This fundamental difference poses a challenge for running Python code within an iOS app, as the necessary Python runtime components are not readily available on iOS devices. We hoped for this method to work as it would be most similar to how the app would function using database queries and dockers, but sadly this method currently isn't a viable approach for us, the alternative method which is the translation of Python code to Swift.
This included attempting to rewrite all the image processing components to use Swift-compatible libraries and developing a custom implementation for graph algorithms like A*. Python and Swift are fundamentally different languages in terms of syntax, structure, and paradigms. this is why we believed it was worth considering other approaches over rewriting it like leveraging interoperability solutions (such as Python's C API, PyO3, or using Python within Swift), as these may have allowed us to use Python code within a Swift project while minimising the need for a complete rewrite.
=='''Indoor positioning'''==
Before talking about navigation, we would first have to tackle the problem of getting the user's location on the map, as we of course require a starting point to guide the user to his or her destination.
===='''GPS'''====
GPS (Global Positioning System) is one of the, if not the, most dominant methods for outdoor navigation worldwide (1).  GPS makes use of satellites that send out signals to earth. The signals are then detected by the ground device. If the ground device, such as a smartphone or laptop, receives three or more signals from distinct satellites, it can use this information to triangulate the device's position. As long as the signals are strong enough, the accuracy of the device's location can be very precise. For outdoor position, the accuracy of a standard smartphone is around 5 to 10 meters (2). Also, GPS can follow a device's location while it is in motion, making it a perfect method for navigation. Hence its popularity. 
Whithin the scope of this project, GPS positioning for outdoor routes seems very reasonable. Though we have to make a small note here. Despite having an accuracy of only a few meters, for some outdoor routes this may still be too much. In traffic, crossroads and buildings are often far enough apart from eachother for the positiong to be sufficient enough. Additionally, the device can take the direction of the vehicle and its velocity into account, allowing for good adaptation of its position. But GPS positioning might be problematic when walking on a narrow path between buildings, since the accuracy might be large enough to <nowiki>''think''</nowiki> the user is located inside one of the buildings. Therefore we must explore other forms of indoor positioning:
===='''Alternate indoor localization methods:'''====     
#'''Wi-Fi-Based Indoor Positioning:'''
#*'''Description:''' This method leverages the existing Wi-Fi      network infrastructure within a building. There’s multiple methods which use Wi-Fi      to determine one’s position. The first one being a '''signal strength      based''' method, in which the user scans for nearby Wi-Fi access points and      measures signal strength. Using a database of      known access point locations, the device can estimate its position based      on the signal strengths and triangulation. A method to do this is called ‘trilateration’. Since      this method is not quite as accurate as one might want it to be, there’s ways      to improve the accuracy, namely '''fingerprinting'''. This is a similar      method to the previous one, except instead of determining location based      on signal strength, it uses a database to determine it’s location. This      database needs to be created first and will contain Wi-Fi fingerprints of      all areas you want to track. Creating this database involves walking      around the area and relating the recorded signal strengths to the known      locations. Once this database is made, it can then be used to determine      one’s location. It does this by comparing the perceived signal strengths      with the signal strengths in the database and finding the best match,      which then results in a location.
#*'''Pros:''' Utilizes existing infrastructure, namely the existing TU/e Wi-Fi network, provides reasonably accurate      positioning, i.e.      within 5-8 meters accuracy. <ref>Are Wi-Fi Positioning Systems Still Worth Implementing in 2023?<nowiki>https://mapsted.com/blog/wifi-positioning-system-explained</nowiki></ref> Or in the case of      fingerprinting: <3m <ref>Kotaru, Manikanta; Joshi, Kiran; Bharadia, Dinesh; Katti, Sachin (2015-01-01). "SpotFi". ''Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication''. SIGCOMM '15. New York, NY, USA: ACM. pp. 269–282.</ref> accuracy, for which room-level accuracy is usually      enough.  (Note that these      accuracies vary based on various factors, such as the variation in signal      strength, density of Wi-Fi points, quality of the fingerprint database      and the dynamic environment. This means that we cannot confidently give a      prediction of the accuracy of this method if it were to be used on the TU/e.)
#*'''Cons:''' Can be affected by changes in Wi-Fi network configurations and      may not provide highly precise results.
#'''Bluetooth-Based Indoor Positioning:'''
#*'''Description:''' Bluetooth-based indoor positioning is similar to the previous      method, but instead of Wi-Fi it relies on Bluetooth Low Energy (BLE) beacons. Mobile devices detect and communicate      with these beacons, enabling them to determine their location. This is, once again similar      to before, done by measuring the strength of the Bluetooth signals      received and then using triangulation to determine position.      Fingerprinting is also possible for Bluetooth-Based indoor positioning      and increases it’s accuracy.
#*'''Pros:''' Precise location information <3m when calibrated correctly, (Once      again this varies depending on many factors and it is not possible to say      how accurate it would be if it would be implemented in our app), low power consumption.
#*'''Cons:''' Requires beacon installation and maintenance, making it costlier      to implement, signal      interference and variations.
#'''Inertial Navigation Systems (INS):'''
#*'''Description:''' INS uses the sensors within a mobile      device, like accelerometers and gyroscopes, to measure changes in      velocity and direction. By tracking these changes over time, the system      estimates the user's position. However, it needs some initial known position. From which it can      then determine the positions the user is in after that by keeping track      of the changes in acceleration and angular velocity. This way of determining      the position is prone to cumulative errors, since any error made is kept      for all positions determined later on. Thus using this as a sole system      seems like a bad idea. However, using this in combination with other      methods would be possible. INS could recognize if an elevator is going up      or the precise direction the user is looking at or going to.
#*'''Pros:''' Provides real-time information and is suitable for short-term      navigation.
#*'''Cons:''' Accumulates errors over time, leading to inaccuracies in      long-distance navigation.
#'''Ultra-Wideband (UWB) Positioning:'''
#*'''Description:''' UWB is similar to Bluetooth-based indoor      position finding, but instead of using BLE’s, it uses UWB beacons which      make use of very short-duration radio pulses to communicate with the user.      The beacon sends a signal, which is then bounced back by the user. This      time is measured and since the radio pulse is of a very short duration, a      fairly accurate estimation of the location of the user can be made. When expanding      this to a multilateral system, using multiple strategically placed beacons,      this system becomes very accurate. This method, using duration of radio      pulses, is called Time-of-flight measurement.
#*'''Pros:''' Exceptional precision, low interference.
#*'''Cons:''' Initial setup and infrastructure costs can be high, especially on a big campus      like TU/e.
#'''Visual-Based Positioning:'''
#*'''Description:''' Visual-based systems use the cameras on      smartphones to analyse visual cues in the environment, such as QR codes      or landmarks. In our case it could recognize room numbers or direction      signs, since they are very common on TU/e and would give an accurate      location. However, to be able to recognize these room numbers or direction      signs, a system would need to be in place to be able to do so. Furthermore      the user would have to ‘look around’ with their camera to recognize these      ‘landmarks’, which is not as user-friendly as we would like it to be.
#*'''Pros:''' Provides an      accurate location.
#*'''Cons:''' Relies on visual markers and may not work well in environments with      limited visual cues,      Not User-friendly, If the user wants an updated location it needs to ‘look      around’ continuously.
#'''Magnetic Field-Based Navigation:'''
#*'''Description:''' Magnetic field-based navigation uses the      Earth's magnetic field to estimate position. Devices detect changes in      magnetic fields within a building to determine location. However, since this      technique is somewhat new and, on top of that, very difficult to      implement, it may be out of our reach currently.
#*'''Pros:''' Can work in environments where other technologies might not      function well,      accurate localization.
#*'''Cons:''' Sensitive to metal objects and magnetic interference, difficult to implement.
#'''Acoustic-Based Indoor Positioning:'''
#*'''Description:''' Acoustic-based systems use sound waves      or ultrasound for positioning. Mobile devices detect and analyse acoustic      signals to estimate their position.
#*'''Pros:''' Can provide accurate results and is suitable for specific      applications.
#*'''Cons:''' Sensitive to ambient noise and may not be suitable for all      environments,      since there is a lot of ambient noise on the TU/e, this makes for a not      very efficient method.
#'''Radio Frequency Identification (RFID):'''
#*'''Description:''' RFID systems use RFID tags to identify      and track objects or people within a building. RFID readers and tags      communicate via radio waves to determine location.
#*'''Pros:''' Effective for asset tracking and inventory management.
#*'''Cons:''' Limited to tagged objects and requires RFID infrastructure.
#'''Dead Reckoning:'''
#*'''Description:''' Dead reckoning estimates a user's      position based on a known starting point and information about their      movement, such as step count, direction, and speed. It continuously      updates the estimated position based on user movement data.
#*'''Pros:''' Suitable for short-term navigation without the need for      additional infrastructure.
#*'''Cons:''' Prone to accumulating errors over time and requires      recalibration.
#'''Infrared Positioning:'''
#*'''Description:''' Infrared positioning uses infrared      sensors or transmitters to detect and locate objects or people within a      building. Devices communicate with infrared sources to determine their      position.
#*'''Pros:''' Suitable for applications like indoor gaming and virtual reality.
#*'''Cons:''' Requires specific infrared infrastructure.
#'''Indoor GPS:'''
#*'''Description:''' Indoor GPS is a concept that combines      various positioning methods like Wi-Fi, Bluetooth, UWB, and sensor data      to mimic outdoor GPS indoors. These systems use hybrid approaches to      improve accuracy.      This method, since it combines multiple other methods, would arguably be      the best. But since it requires multiple methods to have the      corresponding infrastructure and proper software to be able to work together,      it is probably too difficult to implement.
#*'''Pros:''' Can provide more accurate results by combining multiple data      sources.
#*'''Cons:''' Requires integration of multiple technologies and may be complex      to implement.
===='''Determining the best option'''====
*'''Bluetooth-based positioning, UWB positioning, RFID positioning''' and '''infrared positioning''' all seem like good options, which would give accurate results. However, they all come with one major flaw, namely that they all require specific infrastructure. This is of course not realistic within the scope of our project. But even for a project with more time and resources, this still does not seem like a good option, since creating and upkeeping this infrastructure is simply too much work for what you get back from it. (Note that in the case of a project with a lot of resources, these options could be considered.)
*'''Magnetic field based Navigation''' and '''Acoustic based indoor positioning''' both do not seem like they would be accurate enough for room-level accuracy. On top of this these are both very difficult localization methods to implement.
*'''Visual based positioning''' would, in theory, work. However, it would require the user to constantly ‘look around’ with their phone, which is not the user-friendly app we want to create.
*'''Inertial Navigation system''' and '''Dead-reckoning''' both have their use, but when used on their own are simply too prone to cumulative errors. They could be used in combination with other systems. They could assist in localization whenever the other method isn’t able to or they could determine the direction of the user.
*Which leads us to '''Indoor GPS''', combining multiple methods. It would make sense to have INS or Dead-reckoning to determine the direction the user is going, but other than that there isn’t much benefit to it. This is assuming you have a well-functioning, consistent localization method.
*Finally we have '''Wi-Fi-Based localization''', which we believe to be the best option for indoor positioning. Not only does the Wi-Fi infrastructure already exist on the entire campus, it can also, assuming limited interference or errors, reach room-level accuracy.
===='''Implementation of Wi-Fi-Based localization'''====
As mentioned before, there is two ways to implement this, namely the signal strength based approach and the fingerprinting approach. Firstly we will take a look at a signal strength based approach.
===='''Signal strength based approach'''====
*'''Relation between signal strength and distance:'''
The most common relation used in indoor navigation is the following path loss model<ref>Localization Algorithm of Indoor Wi-Fi Access Points Based on Signal Strength Relative Relationship and Region Division Wenyan Liu1 , Xiangyang Luo1, *, Yimin Liu1 , Jianqiang Liu2 , Minghao Liu1 and Yun Q. Shi</ref>:
P_r = P_0 - 10γ*lg(d/d_0) + X_g
Where P_r represents the received signal strength in dBm at distance d (in meters) from the user, P_0 represents the received signal strength at d_0 (which is usually 1m), γ is the path loss exponent and X_g is a gaussian random variable, which is often ignored when dealing with large quantities of data.
*'''Determining location<ref>MOBILE INDOOR POSITIONING USING WI-FI LOCALIZATION Bianca BOBESCU, Marian ALEXANDRU Transilvania University, Brasov, Romania</ref>:'''
Once the n signal strengths have been converted to distances, you end up with a system of equations which looks like this:
d_1 = (x-x_1)^2 + (y-y_1)^2
…
d_n = (x-x_n)^2 + (y-y_n)^2
where d_n represents the estimated distance to an AP (Access point, i.e. Wi-Fi router) with coordinates (x_n,x_y). finally (x,y) represents the coordinates of the user. In a world with no object interference or other kind of errors, this system of equations would give a single solution for (x,y).(figure 1)
Of course, the environment won’t be so ideal, and thus we can’t get a single point out of these equations. However, the solutions to these equations give us intersection points, which consequently give us a localization area, rather than a point. (figure 2) The precise location would then be estimated by taking the center or average of this localization area.
*'''Object interference''':
The issue of '''object interference''' can be solved in the following way according to T. Nakatani et al:<ref>Estimatingthe Physical Distance between Two Locations with Wi-FiReceived Signal Strength Information Using Obstacle-awareApproachTOMOYA NAKATANI, TAKUYA MAEKAWA∗, MASUMI SHIRAKAWA, and TAKAHIRO HARA,Os-aka University, Japan</ref> There is a difference in which object interference affects signal strength in 2.4 GHz and 5 GHz. More specifically, 5 GHz signals weaken much faster than 2.4 GHz signals when dealing with object interference. This can be used to our advantage by devising a neural network which takes both these signals as inputs and estimates the probability of the presence of walls or some other object interference. However, not all walls are equally thick and will of course cause different amounts of interference. This is why the probability found by the neural network is then used as an estimate for the condition of the object interference. i.e. a high probability suggests a lot of object interference, while a low probability suggests little interference. Finally an estimation is made for both the situation of no object interference and the situation where there is object interference. These two results are then fused together, depending on the probability found earlier. Using this method would result in a MAE (mean absolute error) of about 3-4m, which is room-level accurate.
===='''fingerprinting'''====
Since the previous signal strength based method is not a guarantee for an accurate result and could prove difficult to implement in the correct manner, we will take a look at another way to approach this problem, namely fingerprinting. This method, as described before, requires a database of location fingerprints to be created first. Once this is done this database can then be accessed to determine a user’s current location. We’ll explore this in more detail in this section.
*'''Database creation:'''
The first step is to create a database with location fingerprints. During this phase, often referred to as the ‘offline’ phase, fingerprints of RSS (received signal strengths) are collected from multiple known locations. These fingerprints are then stored in a local or cloud based database which has the following structure for n measurements where each fingerprint has m received signal strengths:
(x_1 , y_1): (RSS_11<span> </span>: (x_AP_1 , y_AP_1)) … (RSS_1m<span> </span>: (x_AP_1m , y_AP_1m)
…
(x_n , y_n): (RSS_n1<span> </span>: (x_AP_1 , y_AP_1)) … (RSS_nm<span> </span>: (x_AP_nm,y_AP_nm)
Where (x_n , y_n) represent the actual coordinates, either in longitude/latitude or in a relative coordinate system, depending on which other methods are chosen. RSS_m represents measured signal strength from AP_m with coordinates (x_AP_nm , y_AP_nm).
*'''Determining location:'''
After this first phase is completed, one can now begin with phase two, most commonly referred to as the ‘online’ phase. Firstly the user will need to receive input signals from the AP’s. We define these perceived signal strengths as PSS_m. it then compares these perceived signals to the database and chooses the fingerprint with the smallest Euclidian distance. In a more rigorous way this would look like the following:
Argmin_n {(RSS_n1 – PSS_m)^2 + … + (RSS_nm-PSS_m)^2 | n in |N|}
Where |N| describes the number of fingerprints
References:
(1) Kunhoth, J., Karkar, A., Al-Maadeed, S. ''et al.'' Indoor positioning and wayfinding systems: a survey. ''Hum. Cent. Comput. Inf. Sci.'' 10, 18 (2020). <nowiki>https://doi.org/10.1186/s13673-020-00222-0</nowiki>
(2) Menard T, Miller J, Mowak M, Norris D. Comparing the GPS capabilities of the Samsung Galaxy S, Motorola Droid X, and the Apple iPhone for vehicle tracking using FreeSim_Mobile. 14th International IEEE Conference of Intelligent Transportation Systems. 2011, Oct. Washington, DC.
=='''Navigation'''==
Navigating through multi-floor building and giving expected travel time is significantly more complex than navigation on a single floor. The first reason for this is because the use of elevators and stairs is required in most cases, this not requires an estimate of the expected time it would take to reach the desired floor using the stairs and elevators but also allow the algorithm to select the correct matrix of the new floor, starting and ending positions. The second issue that comes up when navigating on a large and complex area is the required time to compute the optimal path, since the algorithm must consider a lot of possible paths.
====Pathfinding Algorithm Overview====
Our algorithm tackles the complexity of this task by first identifying the user's current building and their desired destination. In the case that the building of the destination is not the same as the building the user is currently in, the algorithm will continue by pinpointing all the exits of the current building and determining the optimal time to reach each exit, taking the time it would take to use the stairs and elevators into account when necessary. The path that results in the shortest time is saved for each exit with the time it would take. From there the algorithm will continue by identifying the possible entrances of the target building and calculating the optimal way to get from the exit of the current building to the entrance of the target building. Finally, the algorithm will compare the time it would take to reach the desired floor for each entrance and save the optimal path for each unique set of elevators and stairs and add the time it takes to reach the destination.
====Enhanching User Experience====
<u> Optimization  </u>
Optimizing the algorithm is crucial to streamline the pathfinding process, especially in situations where computing the entire path without any optimization is computationally intensive. To achieve this, the algorithm employs a strategy of pre-calculating and storing distances in a length matrix, which it can then readily access.
For instance, consider the frequent journey from an entrance to an elevator within a building. Rather than recalculate the optimal path each time a user takes this route, the algorithm can simply refer to the length matrix and instantly retrieve the necessary information.  This optimization technique can be used when pathfinding within a building when moving between floors with a direct entrance and for exterior pathfinding when traveling from one entrance to another.
This approach reduces the computational load of the pathfinding algorithm, resulting in faster route generation which enhances the user’s experience when navigating.
<u> Natural Pathfinding </u>
Certain changes must be made to the movable spaces of the 2D matrix, to ensure that the user receives a path from the navigation algorithm that is both readable and comfortable. The A* algorithm that was used for the 8th floor of atlas tends to navigate too close to the walls of the building. To resolve this issue, a morphological erosion function was performed on the matrix. The shape chosen for the erosion function was a circle with a radius of 4, which is approximately 0.3 m. This shape allows the algorithm to still go through any doors that it might come across and give the user a comfortable buffer from any walls, the result of which can be seen in the image displayed below.
[[file:erosionArray.png|left|thumb|425x220px | Pathfinding Array with Protective Buffer]]
{{clear}}
<u> Customizable Stops </u>
In the current implementation, the algorithm's support for customizable stops is constrained to the 8th floor of Atlas, and it is unable to select the optimal path when the optimal stop is on a different floor or in a different building than that of the destination. The current thought process to solve this problem, is calculating the additional time it would take for a user to reach the destination when visiting an additional stop.
The primary challenge lies in selecting the optimal facility, particularly when it's located on a different floor. A possible solution, should future development occur, is to enhance the algorithm's decision-making process. It could consider various factors, such as user preferences, facility popularity, and time estimates to reach the destination after making additional stops. This more sophisticated approach would aim to provide a more user-centric and efficient experience.
While the feature may have its limitations in the current implementation, there's room for future development to address these challenges.
====Stair and Elevator Estimation====
To give an estimate of the expected travel time, the algorithm needs to make an estimate of how long it would take the user to take the stairs and elevator to the required floor. For the practical implementation only the data on the elevator and stairs of atlas are required.
<u>Taking the stairs in Atlas</u>
Atlas has staircases right behind each set of elevators, so on opposing sides of the building, and additionally, there is also a staircase in the center, but this staircase is more difficult to model, since the staircase upwards on some floors is not directly next to the staircase downwards. Since we cannot model the floors two up until six within the timespan of this course, we shall therefore not model the central staircase, and only model the staircases directly behind the elevators.
The following assumptions were made with regard to modelling these staircases:
#The time it takes to take each staircase is the same for all staircases. The reason for this is that all staircases are all of (nearly) equal steps, and there are two staircases opposing each other at each side of the building so that even if it is a little crowded, this will not significantly increase the time to take a staircase.
#Going up the stairs takes more time than going down the stairs.
#We assume the user to maintain the same walking speed while walking the stairs, regardless of the number of stairs they have already taken.
#The stairs at each side of the building are identical.
We have taken the stairs ten times, two times per day on five different days. Each trial we used a stopwatch to time the time it takes to go from the first to the second floor, which takes two staircases. This resulted in a mean time of 20.2 seconds to go up from the first to the second floor, and a mean time of 13.8 seconds to get down from the second to the first floor. Hence we shall use these numbers for the estimated walking times of the navigation function.
<u>Taking the elevators in Atlas</u>
Atlas has two sets of elevators at opposing sides of the building, with each set consisting of three elevators. The three elevators of one set operate together in the sense that, upon pressing the button, one of the three elevators will make its way to the corresponding floor. The elevators traverse between the floors -1 to 12. We are interested in the expected time T it takes between pressing the elevator button and arriving at the requested story. We will make an estimation of T based on the following assumptions and estimates:
#It will take at most three minutes for an elevator to arrive at the requested story.
#The elevator will take approximately six seconds to go up or down precisely one story.
#The elevator takes five seconds to get up or down one floor
#When people want to get in get out of the elevator, the elevator will take longer to get to the desired floor.
We let c be a variable with range [0,1], which denotes how crowded it is at the elevator. When c is close or equal to zero, there are assumed to be very few to none other people. When c is close to or equal to one, there are assumed to be a lot of other people that want to make use of the elevator. We let D denote the floor difference between ones current floor and the floor they wishes to go to.
For the sake of simplicity we assume that it will take 180*C seconds for an elevator to arrive at the requested floor. Also, with regard to assumption 4, we shall assume it will take the elevator 10*C*D additional seconds to bring one from its current floor to their requested floor.
Hence we arrive at the following formula to estimate T, with T given in seconds:
T<span> </span>:= 180*C + 6*D + 10*C*D.
In order to determine whether or not our estimating formula is reasonable, a few trials were done. For these trials we required to make an estimation for C based on the time of the day and how crowded the elevators are. T.B.C.
{| class="wikitable"
|+
!Run:
!Estimated C:
!Initial floor:
!Requested floor:
!D:
!Time for elevator arrival (in seconds):
!Time for elevator to get to requested floor (in seconds):
!Total time (in seconds):
!Estimated time T (in seconds):
!Difference between total time and estimated time (in seconds):
|-
|1
|0.5
|1
|5
|4
|80
|59
|139
|134
|5
|-
|2
|0.3
|0
|7
|7
|36
|48
|84
|117
|33
|-
|3
|0.7
|1
|8
|7
|132
|93
|222
|217
|8
|-
|4
|0.2
|5
|0
|5
|62
|30
|92
|76
| -16
|-
|5
|0.25
|4
|1
|3
|23
|38
|61
|70.5
|9.5
|}
====Example of Pathfinding====
[[file:examplePath.png|right|185x304px| Example Navigation Output: Atlas West Entrance to 8th Floor Room with Toilet Stop]]
In this illustrative scenario, we'll explore how our navigation system operates. Imagine a user's goal is to navigate from the Atlas West Entrance to a specific room on the 8th floor, located near the south elevator, all while making an additional stop at a nearby restroom. To request this navigation, the user provides the following inputs: the starting location (Atlas West Entrance), the destination (the 8th-floor room), and the coordinates of the restrooms.
The algorithm takes these inputs and performs the following steps:
<u>1. Calculating the Optimal Route: </u>
Starting from the entrance, the algorithm evaluates the available routes to reach the 8th floor. In this case, it determines that the elevators are the quickest option compared to using the stairs.
<u>2. Customizable Stops: </u>
The algorithm computes the path from both elevators to the restrooms and from the restrooms to the desired room.
<u>3. Optimal Path Recommendation:</u>
After processing all the information, the algorithm recommends the optimal route. In this example, it advises the user to take the south elevator, make a restroom stop on the 8th floor (located across  from the south elevator), and then proceed to the destination room. The estimated time for this entire journey is approximately two and a half minutes. The image on the right displays the recommended path on the 8th floor on these inputs.
=='''BIMS'''==
For this project we experimented with the use of BIMs. BIM stands for Building Information Modeling and is defined as “a digital representation of the physical and functional characteristics of a facility. A BIM is a shared knowledge resource for information about a facility forming a reliable basis for decisions during its life-cycle; defined as existing from earliest conception to demolition.<nowiki>''</nowiki> The use of BIMs has been on the rise for the past decade, due to the fact that the traditional way of denoting building information comes with a variety of problems. 
The use of BIMs facilitates one central information point, which leads to clear, efficient and transparent communication among all parties which are involved in the project. It is the process where 3D-models are created and used to design, plan, construct, and maintain build- and infrastructureprojects. These models are more than regular 2D-drawings.
This means all relevant information usually is gathered in just one single 3D-model. To be more precise, a lot of detailed information could be stored, which is useful to make renovations easier, and the end-of-lifecycle more efficient. Examples of information that can be stored in the semantics of a BIM project are room specifications, dimensions, materials, color, and more. This makes BIMs much more convenient in terms of involving all stakeholders. Usually, when one stakeholder needs information from another stakeholder, this requires a lot of time and effort, since the stakeholders have different standards and ways of denoting their information. Therefore the stakeholders have difficulties with proper communication. BIMs in some sense erase these barriers, by sharing the same standards across all stakeholders, and make retrieving information quick and efficient.
Other postive points about making use if building infromation modelling include the following:
- BIMs already provide a good visual representation in the early stages of development. 
- Using BIMs heavily reduces the amount of time required for the building process, as relevant information is easier accesible to all stakeholders.
- Besides time reduction, BIMs also tend to lead to a decrease in costs. This is due to a lower risk of misinterpretation of drawings, as well as a lower chance of making errors in the construction phase.
For our project we would use BIMs that are stored on a server, which could be queried to retrieve the data the user requires, and then the server sends this data to the app. The following figure schematically depicts the way this would work: 
[[File:Image app-server-bim setup.png|center|thumb|Schematic overview BIM-server setup|550x550px]]
The user would like to know how to get from the Southern entrance of Atlas to the Western entrance of Flux as quickly as possible. They will use the app to select the starting location and goal, after which the app will send an action to the server. The server receives the request and will respond by querying the BIM database. The server will receive the required information and compute the fastest route based on the specifiactions given by the database. The server will then send the data back to the user's app, which will show the user the fastest route, completing the process. 
Based on the visions we have for the project, the BIMs will have to be dynamic. Thus a copy shall be made, in order to not interfere with the original files. With the BIMs set up like this, we can make distinctions between routes such as nature-walks and wheelchairfriendly-routes by labelling the paths. Additionally, the database can be updated to let users of the app know when a coffee machine is broken, a toilet is out of order, or to indicate which areas will be blocked off due to an event taking place. 
Hence we can facilitate the BIM models to have up-to-date data available, allowing users for real-time updates.   
=='''Visual Representation'''==
In this section we shall briefly explain the thught process behind the visual representation for the app which we envisioned. Inspiration was taken from state-of-the-art navigation platforms like Google Earth and Maps, and the sources mentioned earlier. The user should be allowed to easily and quickly gain the information they require.
To quickly find all restaurants around campus, ther user should not have to scroll enlessly over the map until they found every option. Hence the incorporation of a tab for all popular amenities such as toilets, coffee machines, and study spots, is a self-evident necessity.
Furthermore, this means that all buildings should be clearly visible. For each building it should be easy to visualize each of its floors, with all its rooms and facilities, so that the user can find a facility in the blink of an eye. This formed the motivation to add a button to toggle between floors after selecting a particular building. Apart from that, following a good structure by means of a color scheme can quickly provide a lot of information to the user. By labelling all toilets with a yellow color on the map the user can see all toilets on one floor, which makes it easier to find one close by.
Lastly, the user needs a way to properly zoom in and out, since smartphones are fairly small for showcasing an entire map. Thus zoom buttons are completely appropriate.
Within the restricted timeframe, it would not make sense to make individual lay-outs for all floors, and since only a BIM model of the 8th floor of Atlas was made available to us, only a visual representation for this specific floor was made. This will give a decent impression as of how the final result for the campus map was envisioned. The image is given below:
[[File:Atlas 8th floor layered on top of Atlas.png|center|thumb|625x625px|Visual representation of the 8th floor of Atlas for the campus app (credits to Google Earth for the background layer)]]
=='''Testing'''==
===Robust testing===
testing algorithm, by picking random locations to test the algorithm.
<nowiki>**</nowiki> more work needed here**
===Procedure for testing the project===
In order to gain insight into how well the prototype of the app satisfies the user’s needs and requirements, it would be necessary to conduct some tests in which users make use of the app. This will also confirm if the prototype is understandable, self-explanatory, and functions like the user wishes it to. For this reason we have set-up a test procedure.
Our prototype is restricted to just the ground floor and the 8<sup>th</sup> floor of the Atlas building, which does really limits us to test the app thoroughly. Regardless, it is still worth executing a test.
We aim for a total of eight participants to test our app. They have to sign a consent form to approve their participation in this test, and for their answers and execution of the experiment to be used in our project. Of the participants, we want four of them to be relatively or completely new to the TU/e campus, and four of the participants to be already familiar with it. The former quadruple will be referred to as test group A, the latter quadruple as test group B. Of each test group, precisely one of the four will perform test procedure A, and similarly test procedures B, C, and D. For each test procedure, the user will be provided with a phone which has the prototype app opened at the home screen. They will have to strictly use the app to navigate and complete the following assignment depending on the procedure:
Test procedure A: The user starts at the West entrance of the Atlas building (on the ground floor), and will have to navigate to room 8.201. They need to take the fastest route available.
Test procedure B: The user starts at room 8.201, and will have to navigate to the West entrance of the Atlas building (on the ground floor). They need to take the fastest route available.
Test procedure C: The user starts at the West entrance of the Atlas building (on the ground floor), and will have to navigate to room 8.201, after successfully having navigated to a coffee machine. They need to take the fastest route available.
Test procedure D:  The user starts at room 8.201, and will have to navigate to the West entrance of the Atlas building (on the ground floor), after successfully having navigated to a coffee machine. They need to take the fastest route available.
Depending on how busy it is, the app will either send the user via the stairs or the elevators. Thus we cannot have a predefining measure to compare the results of each test with. Instead we rather wish for the participants to provide open feedback about the app and address what aspects of the navigation function are experienced as good, and what they miss or want to see improved. Throughout the assignment, one of our group members shall stick with the participants and make notes if applicable.
We did not succeed in conducting the test procedure, since the app was not yet fully working as required.
=='''Future Work'''==
When we got first started working on this idea we envisioned it to be much bigger, but our vision exceeded the scope of what we were able to achieve in this 8 week timeframe. This resulted in a lot of unfinished work and a lot of possibilities to expand or improve on this project. We will explore these possibilities further in this section. Firstly we will describe some basic features the app could have. Secondly we will describe some dynamic features we imagine the app could have. These features will, for example, use live location data of students to determine busy areas or availability of study spots. Furthermore we will explain some possible future work for the app development, use of BIMs and indoor localization.
====Basic features====
*'''Expanded Campus coverage:'''
Currently, the prototype is limited to only a few floors in atlas. Of course, in a fully developed app more, if not all, buildings should be available. On top of this, the app could, if it’s developed fully, be made to be more generally applicable, allowing it to be easily used on other universities campuses also.
*'''Integration of additional amenities:'''
There’s a lot of amenities which are not yet featured on the app. Think of printers, water fountains, lockers, study places, etc. All of these are still to be added.
*'''Social Hub:'''
Another feature we imagined the app to have is a social hub feature. In this hub you could find (leisure) events by student associations, lectures or other student events happening in the near future. More importantly it would show you where, when and for who these events would be available. This would give (new) students an easy way to meet new people or explore new hobby’s next to their regular studies.
*'''Integration with TU/e systems:'''
We have made a whole new app, but why not just integrate it into the already existing TU/e app, which most students already have? Of course this was not possible in this 8 week timeframe, but if this app would become be properly developed, this would be an excellent improvement.
*'''Study spot / meeting room reservations:'''
If you wish to reserve a meeting room, you have to use a an external tool. Instead meeting room reservations could be incorporated within this app, allowing you to easily reserve a meeting room and instantly know where it is. Furthermore, study spots could be visualized on the app and a feature could be added where you can reserve a study spot. (Note that this feature would’ve been good during covid times. However it would currently not be very relevant, instead a feature simply showing where there are likely to be available study spots would be better)
====Dynamic features:====
*'''Heatmap:'''
The first possibility for dynamic features is a heatmap which shows which areas are busy. This would either use live location data from students who have the app, which is possible since a majority of students would be ok with sharing their location, according to our survey, or it would make use of students timetables to determine busy areas. This feature could be used in a number of ways:
1.    Show busy areas on the map
2.    Avoid busy areas during navigation to get faster routes. (After a while, previous data could be used to predict busy areas and get even more accurate route planning.)
3.    Determine availability of study spots
*'''Advanced Navigation:'''
Another more advanced feature would be the possibility to chose between different ‘types’ of routes, namely:
1.    Wheelchair-friendly route
2.    Fastest route
3.    ‘Scenic’ route (Note that this one might be a bit difficult to implement, since what is ‘scenic’ is of course very subjective. But you could turn this into a feature which shows you available study spots or meeting rooms which have a nice view)
====App improvements====
TBD
====BIMs====
*'''Integration of BIMs into the app:'''
As of now, BIMs are not used in the way we initially envisioned using them. Instead they are only used to create an image of the floors of atlas. However, in the future they could still be made to properly integrate within the app. The BIMs would be used to extract useful data, such as the location of rooms or amenities. Using BIMs could initially prove difficult, but once implemented it could be used for other buildings or other campuses and speed up the process when implementing other buildings or implementing the app for other university’s campuses.
*'''Combined database:'''
Another feature one could explore is creating a combined database of the BIMs and live data from the app. This would include things that are not in the BIMs, for example, where coffee machines, water fountains, vending machines, etc. are. This extra database would be kept up to date and could be updated, in the app, (by the user) when amenities like coffee machines or toilets are broken. This would allow for one big central database for this system.
====Indoor localization====
*'''Implementation of Wi-Fi-based localization:'''
As described in previous sections, a new indoor localization method has to be implemented, the most likely candidate being Wi-Fi based localization. The principles of this have been described in the indoor localization section, but to actually implement this, some more work is needed. One would have to figure out where how to access TU/e’s Wi-Fi AP’s. Furthermore, a choice would have to be made between the two different approaches, strength based and fingerprinting, based on both their advantages and disadvantages given TU/e circumstances. Finally, of course, this whole system would have to be properly implemented.
<br />
=='''TIME FRAMES'''==
{| class="wikitable"
|+
!Week
!Scope
!description
!Notes
|-
|1
|gauge Idea
|group brainstorming, find project scope and idea
| - idea found, student helper app for navigation
|-
|2
| -scope of Project
-creating survey for users
-start APP dev
- defining users
| -Understand how and where to start with Project, what is required and how to approach idea
-creating a user survey to send back and get feebback and gauge where the gaps are in the project
- look into app programming and development
| - we each found roles within the group which could work on
- understanding scope and fine tuning to a achievable goal
- Understanding what users might be looking for and developing a survey which to find it
-using Swift and xcode for easy app dev and creating a user friendly application
|-
|3
| - release Survey
- continue app dev for basic features
- understand BIMS
<br />
| - releasing the survey to the users, aiming for mostly first years and Exchange students
- continue work of app dev
- meeting with gijs van den to learn and understand BIMS
| - waiting for survey results, to compute
- see app dev page for app development
- find out how to use BIMS
|-
|4
| - continue app dev
- starting work on path finding algorithms
- computing survey data
- R.P.C list
| - see app dev page
- looking into types of algorithms which would be best for our project
- reviving survey data slowly, and computing the out come
- creating the list, to understand and gauge scope and idea further to create more achievable goals
| - looking into pathing algorithims using python
- waiting longer to receive more responses for survey
|-
|5
|continue app dev
|
|
|-
|6
|
| - wilbur: find accuracy gps mapkit library in swift x-code phone gps
|
|-
|7
| - start preparing final presentation
| - find expected walking times
- (mathematical) time it takes to take the elevator from floor i to floor j
|
|-
|8
| - add code to Wiki
|
|
|}
<br />
==HOURS==
<br />
{| class="wikitable"
|+
!WEEK
!Jack - hours
!Jack - breakdown
!
!Wilbur - hours
!Wilbur - breakdown
!
!Jerome - hours
!Jerome - breakdown
!
!Quincy - hours
!Quincy - breakdown
|-
|1
|0hr
|N/A
|
|13hrs
|Introductory presentation; formation of group; brainstorming ideas for possible projects; researching feasibility and state-of-the-art of two prominent project ideas; extra brainstorming meeting
|
|10 hrs
|Introduction, group formation, idea brainstorming, state of the art research
|
|10hr
|Introductory presentation; idea brainstorming; meeting; state-of-the-art research
|-
|2
|10hrs
|In our initial meeting, we delved into various approaches and discussed the initial steps for commencing the development process. I have initiated the research phase to explore the idea further and outline the necessary steps for app development. For detailed insights, please refer to the 'APP dev' section.
|
|13hrs
|Made a mindmap/overview about all possible ideas that come to mind with regard to navigating the TU/e campus (as newcomer); Look at possible ways to create a digital map with semantics of TU/e; As a group: discuss target user; Come up with 10 questions for survey; send an email to Elena Torta with the ask for advice, and regarding possible BIMs of the Atlas building
|
|8 hrs
|Assist with making a survey, work on pathfinding
|
|10hrs
|Initial meeting to discuss approach; started work on survey
|-
|3
|12hrs
|Continued app development as described in the previous APP dev section. The app now features functional buttons, although currently, only the map button successfully links to the map page. I'm in the process of reconfiguring the profile button from being a bottom tab to being integrated into the button list.
|
|16hrs
|Meeting: discussed the reply of E. Torta; went through one of the two entire gitlab folders that she had shared (the other gitlab folder we got access denied, which contained the BIM files, but we didn't know this, so we wasted a lot of time because we didn't precisely know what to look for); researched what BIMs are and where they are used; send another mail to E. Torta for help to retrieve the BIM data -> she replied by redirecting us to Gijs van den Brandt, who we could schedule a meeting with to ask specific questions; I read the 2/3 articles E. Torta provided in her initial reply
|
|12 hrs
|Reading about BIMS and how to extract required information, survey release
|
|10hrs
|meetings; Finalized survey; created a proper consent form and added this to the survey; survey release;
|-
|4
|10hrs
|Continuing app development, I've been working on new features, but they're not fully functional yet. I'm focusing on the calendar feature, which will help users manage schedules. I'm also creating an environment for pathfinding and looking at Python code conversion for this purpose.
Managing security and accessibility functions for the app has been challenging but necessary. It involves handling permissions and pop-up notifications while ensuring user privacy.
I had a productive meeting with Gijs van den Brandt to discuss integrating Building Information Models (BIMs) into the app. This is a key part of our project.
|
|12hrs
|25/09: Meeting with Gijs van den Brandt about the BIMs; more research of BIMs and reading the final article recommended by E. Torta
|
|15 hrs
|Working on pathfinding on a certain floor using a matrix
|
|8hrs
|Meeting with Gijs van den brandt; some initial BIMs research; meetings
|-
|5
|15hr
|Implementing user location while strictly adhering to user privacy guidelines has proven to be a complex task. This effort has posed a greater challenge than managing Apple's security and accessibility functions to enable pop-ups and permission changes within the application.
|
|14hrs
|GraphDB tutorials; loading and querying of BIM data in GraphDB; looking into the data of the CSV-file which generates the Matrixmap in the Python notebook; finished writing some short scenario's based on the survey results; looked into indoor/outdoor positioning, focussing on GPS - I described this in the Wiki in week 6;
|
|14 hrs
|Expanding on the pathfinding: coordinates to array index, navigate via, added some known (toilets, elevators, room)
|
|8hrs
|Meetings; Written the RPC-list
|-
|6
|14hrs
|I'm currently working on the calendar feature. It's important to note that this feature is still under development and not yet functional. Its purpose is to serve as a demonstration of how some of the other features within the application could be implemented. Additionally, I've begun creating an environment conducive to pathfinding functionality. I'm exploring methods to convert and integrate Python code into the project to enhance the capabilities of the pathfinding feature.
|
|14hrs
|Rewritten introduction and target-user; described what BIMs are and which applications they have + why we can implement it in our project; researched how to setup a server with BIMs for the app
|
|13 hrs
|Work on pathfinding: added time estimate with elevator estimate,  allow to navigate from entrance to floor 8 using shortest time route
|
|8hrs
|Meetings; incorporated survey results in the report; initial research on localization methods
|-
|7
|16hr
|Continuing app development, focusing on algorithm integration, code optimization, and improving existing features. Also, actively researching best practices for informed development decisions.
|
|16hrs
|Ran some trials of taking the stairs and elevators in Atlas; came up with a formula to estimate the time it takes to take the elevators and stairs in Atlas, using a very very simple mathematical approach; preparation for presentation; setting up a testing procedure for testing our app, though we are not yet fully certain if our prototype will be ready in time
|
|19hrs
|Trying to run/convert python script in swift, preparation for presentation with added pictures of pathfinding
|
|17hrs
|Meetings; Presentation preparation; Researched all possible indoor localization methods and described them; Determined best option and researched that further; described implementation of Wi-Fi based localization; added bibliography
|-
|8
|17hr
|Continuing efforts to integrate a Python algorithm into the app, exploring multiple approaches for effective implementation. Simultaneously, actively working on enhancing the project's documentation and knowledge base through the Wiki. and preparing presentation.
|
|16.5hrs
|Extended parts on the Wiki with future vision; final presentation; finished a design for visualization of how we envision the final app to look like, and wrote our motivation in the corresponding section; read the entire Wiki and fixed a few minor grammar mistakes
|
|14 hrs
|Meetings, updating wiki, uploading python script to gitlab
|
|16hr
|Preparation for the presentation; presenting the presentation; Feedback meeting; written future work section; some fixes on previous sections.
|}
=='''Bibliography'''==
<references /><br />
=='''Milestones | Time Frames'''==
===='''10/09/2023 |  Tutorial'''====
- Update wiki with basic info about project
====12/09/2023 | group meeting====
- Understanding Scope of Project, focus on First year students
- TODO:
*Make scope smaller, do research on USER based survey and questions
*Pick a building/ Area to focus on.
*Each member come up with 10 questions before 13th.
====18/09/2023 | '''Tutorial'''====
- Gage how to start without having the user feedback
-get advice from professionals and other lecture figures
- technical issues see first slide.
- email the BIMS lady
- start building a app to find current location and other basic services etc,
-start mapping out the building
'''weekly roles:'''
Jack - initial app set-up and dev. 
Wilbur - BIMS research 
Quincy - BIMS use and dev 
Jerome - Survey release   
===25/09/2023 | Tutorial===
- extrapolate survey result, find scope.
- meeting/understanding BIMS.
- continue App dev, for other services on map
- research indoor map methods and techniques. 
- figure out what our functional scope is?
'''weekly roles:'''
Jack - continue app dev, focus on other features of the app.
- focus of part of app which users identified from survey.
Wilbur - State of the art research 
Quincy - RPC-list
Jerome- gage survey data / Look into the BIMs 
===02/10/2023 | Tutorial===
- Define concrete goals; what do we hope our indoor navigation is capable of? -> Find-nearest function.
- Wilbur shall figure out the way to determine expected times of taking stairs and elevators
- Write out answer to question how we envision the user to define the location where he/she is, when using the indoor navigation. -> Use GPS location, small error indoors, which we don't cosider a problem as it will be small compared to the distance between two different facilities.
- Maybe find 2D maps of Atlas, cause we only require coordinates of the facilities in a building.
- explain why BIMs are better for our project than just 2D maps -> BIMs can have inherited information, and information can easiliy be updated once set-up. Also if BIM works at floor 6, it can work for entire building.
- Write down what we achieved with the navigation part (A* algorithm)
- Wilbur try to figure out how the matrixmap is generated from the CSV file, and what is in the CSV file, using the BIM of Atlas. 
====09/10/2023 | Tutorial====
- continue to create smaller scope
- figure out how precise the location services are.
- develop floors and stairs in map finding.
- lack of infrastructure around UNI to completer all areas of project (keep in mind for later wiki writing) 
- make plan for testing and release.
- look a B.I.Ms for a more extensive understanding of locations, perhaps for views, scenic routes, fitness routes, etc 
- look a chatting to another body of knowledge around using and understanding B.I.Ms

Revision as of 01:12, 31 October 2023

Retrieved from "https://dsdwiki.wtb.tue.nl/index.php?title=PRE2023_1_Group3&oldid=124015"