NavApp: A Mobile App as a Master’s Thesis

Gianmario Motta , Iman Abu Hashish, Antonella Longo

Abstract: This paper illustrates a project work made by graduate students in computer engineering at University of Pavia. The project concerns a mobile indoor navigation application, called NavApp,for the mobility of pedestrians inside a building. NavApp has been deployed in a real environment,namely the library of the University of Pavia. It supports the staff in picking, storing, moving and inventory operations. Indoor navigation relies on a cloud service that fuses data of magnetic fields,Wi-Fi and beacons, called Indoor Atlas. NavApp has a sufficient positioning precision (2 meters)with the relevant advance of being able of working without any pre-deployed infrastructure, a key point in an ancient library with many million books.

Key words: indoor navigation; location based services; mobile application; indoor positioning

1 Introduction

We here illustrate a project work made by graduate students in computer engineering at University of Pavia. The project concerns a mobile indoor navigation application, called NavApp, for the mobility of pedestrians inside a building. The project involves various aspects: analysis of techniques and technologies for pedestrian indoor mobility, analysis of user’s needs, design and deployment of an App. Of course, we have not thrown impromptu such project;conversely, pedestrian indoor mobility had been a subject of numerous papers authored by our lab staff[1-4],of Doctoral and Master theses[5], of joint research on mobility of Visually Impaired People[6-7].

This remaining of paper includes three parts, each on a specific subject. Part 2 is on the issue of indoor pedestrian mobility, and sketches the background of the case study. Part 3 is on the case study and includes a series of sections, which, respectively, illustrate the analysis of users’ needs, the architecture of NavApp,the implementation and test of NavApp, and the posttest refactoring. Finally, conclusion considers the educational and business value of NavApp.

2 Indoor Pedestrian Mobility

NavApp is a mobile app that supports pedestrian indoor navigation phases inside a building. Such phases are shown in fig.1, while table1 lists those technologies that are used in NavApp (available technologies are many more). The first off-line phase acquires the indoor map and adds way points and POIs (Points Of Interest),thus storing the master data for navigation; to acquire data, as you see from table 1, NavApp relies on the technology of magnetic fingerprints. In the subsequent on-line phases, positioning is based on matching finger prints with the current position of the mobile phone; in turn, path planning uses Dijkstra’s Algorithm; finally,real-time assistance displays the position of the mobile on the map and adds appropriate routing instructions.As a final management phase, analysis considers the flows, by time and path, of app users.

Fig. 1 Phases of indoor navigation [2].

Table 1 Technologies for indoor navigation.

3 The NavApp Project Work

NavApp has been assigned to graduate students of computer engineering as a thesis, with the purpose of designing a usable system for indoor navigation that could work without pre-deployed infrastructure and fulfilled as much as possible ideal functional requirements. Let us shortly comment them (see Table 2).

· The independence requirement implies that a portable navigation device can work without relying on an infrastructure that has been previously deployed in the building. This is a key requirement in our case study. Indeed, with the very large size of the library and the consequent cost of deploying active sensors, our App should work without any specific infrastructure.

· Map positioning in a building requires that the navigation App locates the user in the right room. For a person who can see and walk accordingly, a 2-meter precision is enough; proximity sensing is not necessary,thanks to the human space perception.

· Vertical positioning let you know at which flor you are. Again, this is challenging for a robot, not for a person, who can perceive it.

· Safe path implies that the system selects specific itineraries/path for impaired people,e.g. wheel chair or visually impeded. This can be obtained by storing the safe paths on the building map accessed by the navigation device and/or by proximity sensing that identifies obstacles and triggers an alternative path.

· Finally, en-route assistance shows the user the location where he/she is, and displays instructions to the next destination; this requirement, typical to outdoor navigators, is critical also indoor.

NavApp supports requirements of Independence, Map Position, Safe Path, En-Route Assistance, and Precision,not Vertical Position and Mass Sensing. In short, such support is good enough for the purpose NavApp is conceived for.

Table 2 Ideal requirements for indoor navigation.

To get a usable application within the limits of a master thesis, we have decided to use existing technologies, and concentrate creativity on the solution.Such approach has led us to:

(1) make students familiar with existing techniques and technologies by a systematic literature review based on recent surveys[8-9];

(2) let students spend several days in the library to get familiar with user’s needs and model a real work flow;

(3) build a server to store and retrieve library-specific data;

(4) release a simplified edition 1 to test magnetic fields positioning, and, based on this experience,develop an enhanced edition 2;

(5) re-engineer the edition 2 app into a micro service paradigm as an assignment of a course on the Design of Service Systems.

3.1 Analysis of user's activities

Our use case study concerns the Library of Pavia University, which stores millions of books that range from medieval manuscripts to contemporary texts.The library features a general catalogue, called Open Web[10], which provides the topographic code of every book, i.e. a code that indicates the position of an individual book. NavApp has the purpose of guiding the library staff to the location of the book by displaying on the smartphone the position of the librarian, the positions of the books to be sought, and,of course, the itinerary to be followed for searching the books.

Students and tutors discussed with library staff how the mobile App should work, and modeled the user scenarios with the activities to be introduced or removed. In these meetings we defined also a protocol for an operations log, which records search evidence,i.e. a picture of the ledge where the book was or was supposed to be. This activity lasted months, and included simulations and a complete documentation of the analysis, based on BPMN and standard UML.

3.2 Design of system architecture

After the analysis, we realized that a server was necessary for supporting the App and provided data to the entries server, and we proceeded to its design.Indeed, NavApp should orchestrate various systems, as we show in Fig. 2.

Fig. 2 Architecture of NavApp (adapted from[2]).

A national catalogue, based on the classic OPAC technology, stores book information to which a local system, namely Open Web[10], adds book location.IndoorAtlas[11], a cloud-based service, provides indoor position data by fusing magnetic fields, Wi-Fi, and Beacons. NavApp receives from Open Web the list of books to pick or store and their respective shelves through a URL. Then, it retrieves geomagnetic fingerprints, locates users accordingly, computes the shortest paths by Dijkstra’s algorithm, and guides users in reaching their destinations.

NavApp architecture includes a front-end(NavPhone) and a back-end (NavServer). NavServer features a database where waypoints (obtained by fingerprints) are associated to library shelves;hence, each logical position (shelf) is associated to a physical map position (waypoint). The database contains also some operational information as the log of operations and paths. NavPhone, on a smart phone, runs the navigation program. Specifically, it uses the Model-View-Controller (MVC) architectural pattern. Model classes map the tables of our database. Controller classes manage the shortest path algorithm and access the server. Finally, the view classes correspond to the screens of the application.We included external libraries, i.e. IndoorAtlas SDK, Google Maps service[12]，Retrofit 2[13], and Hipster[14]for computing the shortest path through the classic Dijkstra algorithm[15].

3.3 Implementation and test

The software includes off-line and on-line phases(Section 2, Fig. 1). The off-line phase creates the map on IndoorAtlas in various steps:

(1) Set location: building, longitude and latitude.

(2) Add the floor plan (PNG map).

(3) Position the floor plan: the map is adjusted to the longitude and latitude of the location.

(4) Add waypoints: waypoints (with their respective longitude and latitude) are added to each floor. Each waypoint is related to a POI (Point Of Interest).

(5) Collect magnetic fields: this task is performed by an IndoorAtlas application, namely MapCreator[16],which spots magnetic fields and records magnetic fingerprints.

(6) Generate the final map by IndoorAtlas server.

The on-line phase includes the navigation of the use(Fig. 1). In the first step, the user selects the shelves to be reached. Subsequently, the user is guided to each destination. At any moment, the user can see his/her position relatively to the next destination. After having reached the first destination, NavApp will plot the subsequent destination. The system relies on waypoints that are associated with each library shelf.Those waypoints are gathered to a preparation session and stored in the NavApp database. In turn, the realtime position of the user is given by IndoorAtlas as an external service.

The objective of the NavApp (i.e., a usable system for pedestrian indoor navigation) requires a complete field test. Our test has considered a wide range of variables for a total of over 30 cases.

· Various Android smartphone models: Samsung Galaxy versus Xiaomi Redmi Note 4.

· Users at different proficiency levels: experienced,intermediate, beginner.

· Environment changes: unchanged versus modified room layout (i.e. with modified position of metal furniture).

· Positioning: vertical versus horizontal positioning(the library includes both floor and mezzanine shelves).

· Lighting: lighting on and off.

The precision and usability of NavApp has reached its best on Xiaomi, with an expert or intermediate user,in an unchanged environment, in horizontal positioning with controlled lighting. In such situation, the precision is 1 to 2 meters. Positioning errors are caused mainly by alterations of magnetic fields that reflect position changes of metal objects or interferences of neon lighting. At the time of the test, Vertical positioning was not possible with Indoor Atlas. Results vary among the various smartphones, because they reflect their different sensor filtering (magnetometer, gyroscope) and related data fusion.

3.4 Edition 2 and refactoring

The first NavApp edition allowed, for the sake of simplicity, only one operation for each navigation[17].To overcome that limit, the edition 2, developed by a second student, enables an unlimited number of operations (pick, store, check)[18]. Such edition 2 was in turn reengineered in a microservice paradigm[19]that was developed as a team assignment in the graduate course “Design of Service Systems”, with the steps listed in Fig. 3.

Fig. 3 Design steps for NavApp refactoring.

4 Conclusion

In this paper, we have reported the case study of NavApp, a mobile application for pedestrian indoor navigation. Specifically, the application objective is guiding library staff in storing, picking, checking books, without relying on pre-deployed infrastructures as Wi-Fi, beacons. etc. Technologically, the solution has resulted usable, i.e., enough user-friendly, robust, and accurate. NavApp, although not an absolute innovation,demonstrates a feasible integration of existing services for a scalable and infrastructure-free indoor positioning.

NavApp has been a project work for graduate students; it has included① a thesis on design and implementation of the basic edition, focused on the issue of indoor positioning by magnetic fields 1;②a thesis on an enhanced and more scalable edition 2 with unlimited number of operations;③a course project work, aimed at refactoring of the code in the microservice paradigm. Let us conclude with some remarks on educational and business value of the NavApp project work as a champion of a complex, real-world project.

4.1 Educational value

In our view, NavApp has a high educational value.Such thesis project work is a “l(fā)ab internship”, where students develop a real App for 6～9 months. Such internship is effective: among our fifteen students who graduated with a lab internship in recent years, ten are working in multi-national companies, as Alibaba,IBM, and Atos, and four are successfully working in academic career[20].

In fact, lab internship has some unique advantages.Students acquire a structured command on both application and technology domains, and cover the whole project lifecycle, from user’s needs to implementation and test. Given the research-like project, they are pushed to search solutions and research studies, acquiring intellectual self-confidence. Additionally, university can test ideas and keep control of the developed knowledge.However, internship is not a universal solution. Not only supervision costs are high (10% of PhD student and 5%of professor for every internship)[20], but also a projectlike organization is needed, with plans, progress review and walkthroughs, and, finally, the project work requires students of class A.

Complex project work may be less effective in a regular course. In our experience with NavApp refactoring, the shorter time (less than one academic semester) prevented students to acquire a structured command of both application domain and technology.In this case, a more limited scope, either on analysis or implementation, seems preferable.

4.2 Business value

The business value of NavApp stems from a stateof-art system integration, that aims at the fusion of a wide range of positioning techniques and technologies,of cloud-oriented architecture, and the conceptual framework on mobility phases. Such fusion has several development perspectives with edge computing and future IOT.

For instance, assistive technologies for visually impaired people[7]include a range of wearable devices,as smart glasses, smart canes etc., which work as active and passive sensors to communicate to the user’s position, both outdoor and indoor. NavApp can provide the ground for the backend module, i.e. the“brain” which supports all mobility phases we have illustrated at the beginning of this paper and complies with the ideal requirements we have listed in Table 2. Specifically, the “brain” fuses data gathered by wearable sensors, thus relying on the combination of multiple positioning technologies, as Magnetic Fields,Vision, and Dead Reckoning.

Too, this fusion is coordination which implies some osmotic computing[21]that shall use available resources which time to time may be local (wearable) and/or remote (cloud).