Indoor Navigation System for the Blind and Vision Impaired: Using Kinect-Style Sensor and

Real-Time Appearance Based MappingJ. Eisele and D. Mendoza, Student Members IEEE

Abstract- Indoor navigation can be challenging because the Global Positioning System does not function reliably, if at all, indoors. The purpose of this project was to design a prototype of an indoor navigation system that could be used by members of the blind and vision impaired community, demonstrate proof-of-concept, and make a recommendation regarding future research. As part of this project, we evaluated a simultaneous localization and mapping application called "RTAB-Map" for its ability to generate a map of an indoor environment and then perform accurate, real-time localization within the map as required for navigation. RTAB-Map is a graph-based simultaneous localization and mapping approach that uses both image and depth information. The scope of the project was constrained to navigation of an indoor environment that we had previously mapped and existed on a single “floor”. A Microsoft Kinect was used to provide the image and depth information that was required for mapping and navigation.

I. INTRODUCTION

As of 2013, the World Health Organization reported that there are an estimated 285 million people worldwide

who are considered blind or vision impaired (BVI) [1]. Large, public buildings typically contain directories, signage,

and door numbers to help those who are not vision impaired navigate from the building entrance to their destination.

Some buildings contain signage that displays information in braille, but many do not. More importantly, only about

2% of the people in the BVI community are able to read braille [2]. Given this fact, there exists a need for an indoor

navigation system that would help to enable people who are BVI to autonomously navigate large indoor

environments.

Reliable indoor navigation is a challenging problem largely because GPS does not function well, if at all, inside of

most buildings [3]. The ability to reliably navigate without the aid of GPS is an important goal in the field of

robotics and methods have been developed to this end. Simultaneous localization and mapping (SLAM) is one such

method that enables a robot to track its position within an unknown environment while simultaneously creating a

map of the environment. Though movement can be tracked with wheel encoders, IMU’s, or visual odometry –

tracking position with just the use of these sensors (dead reckoning) eventually results in position drift [4]. Real-

Time Appearance-Based Mapping (RTAB-Map) is a graph-based RGB-D SLAM approach that combines global

loop closure with memory management techniques [5]. RGB-D is an acronym for Red-Green-Blue-Depth. RGB-D

SLAM is a type of SLAM algorithm where the input is a series of color images each of which includes depth

information for each pixel. Loop closure allows the SLAM algorithm to “recognize” locations that have been seen

previously and then adjust both the map and odometry as necessary. Since RTAB-Map employs memory

management and global loop closure, the application has the ability to create large maps over multiple sessions and

still run in real-time [5]. Additionally, it has an advantage over dead reckoning in that it corrects for drift during loop

closure. Minimizing position drift is especially important when tracking position over large distances.

The purpose of this project was to design a prototype navigation system that could be used by members of the

blind and vision impaired (BVI) community to navigate previously mapped indoor environments. Additionally, we

demonstrated proof-of-concept using RTAB-Map and provided a recommendation regarding continued research.

A. Basic Introduction to SLAM

Figure 1 below shows a graphical model of the online SLAM problem. Online SLAM differs from full

SLAM in that online SLAM seeks to find the current pose of the camera, whereas full SLAM seeks to find all

of the camera poses over the entire path that has been traveled [6]. A SLAM algorithm is able to determine the

pose of a camera, or robot, while generating a map of the environment. What follows is a very general overview

of SLAM.

Figure 1: Graphical Model of Online Slam [6].

The equation at the bottom of figure 1 depicts the general problem that is being solved during SLAM. The user

seeks to find the probability of their current state at time “xt” and determine a map “m” of their environment

given all previous measurements “z1:t” that have been taken of the environment and all previous control actions

“u1:t”. A control action could be a robot executing a command to move, or if the user is a person instead of a

robot, a control action could be walking or other movement. This problem is generally solved iteratively and

probabilistically with some type of Kalman Filter or Particle Filter. RTAB-Map is the SLAM algorithm that is

used in our prototype and it is a form of graph-based SLAM. For more information on graph-based SLAM, see

[7].

B. Previous Work

The need for an indoor navigation system to aid people who are BVI has been previously recognized, and a

variety of systems have been proposed. In [2], Gallagher, Wise, et al., examined the (then) current state of

development of indoor navigation systems for the BVI community and set forth criteria that such a system

would ideally meet. Based upon their criteria, a system should be accurate within 2 meters and should not

interfere with the user’s sense of hearing or touch, or affect their ability to use a primary navigational aid – such

as a long cane or guide dog. Additionally, the system should be portable, and provide multiple modes for

outputting information; preferably, options would include tactile output and audio tones. Finally, it is important

that the system require only minimal support from a building’s infrastructure. These criteria are considered

especially relevant given that Gallagher, Wise, et al. conducted human trials as part of their research. They also

proposed a navigation system named “SIMO” that used a building’s WIFI fingerprints and the Nearest

Neighbor algorithm to navigate the building’s map [2].

In [8], Tian, Yang, Yi, and Arditi developed a computer vision based wayfinding device that incorporated

object, door, and text recognition with a text to speech algorithm for the purpose of wayfinding via a building’s

signage and landmarks. The system would enable a BVI user to learn about their environment by deciphering

signage in their direct vicinity. However, the system does not include an actual navigation system that could be

used to directly guide the user to their destination. Additionally, the system runs on a laptop computer and

would be somewhat cumbersome to transport [8]. Benefits of the system include its ability to help the user

navigate environments that have not yet been mapped.

In [3], Bash developed a system called NAAB for the BVI that uses active radio-frequency identification and

quick-response (QR) codes to perform indoor positioning. The system also performs indoor navigation and uses

a Kinect to perform obstacle avoidance. NAAB is very accurate with and has an error of less than 1 meter.

However, in order for the system to function, both active RFID tags and QR code labels need to installed in the

environment beforehand [3]. In addition to installing these devices, they will also need to be maintained to

ensure continued operation.

II. Design Methodology

The deliverables for this project are our prototype indoor navigation system and a recommendation as to whether

or not our design merits further research. Our client is our project advisor Dr. Kupilik from the Electrical

Engineering department at the University of Alaska Anchorage. Dr. Kupilik had the following project requirements:

1. Implement either a visual odometry algorithm or a SLAM algorithm on a laptop computer.

2. Implement a path planning algorithm that interfaces with the program from requirement (1) in order to

demonstrate proof-of-concept for our prototype navigation system design.

3. Test the prototype and determine its accuracy and ability to function in large indoor environments.

4. Write a detailed project report and present our findings.

Additionally, it is important to consider if the results from testing our prototype indicate that it would be worthwhile

to continue this research. This decision will be primarily based upon the test results showing that the design goals

were met and whether or not our design has benefits over alternate designs that already exist.

The first step in the design process came from recognizing that there was an apparent need for an indoor

navigation system that could be used by the BVI community. Additionally, we knew that we were primarily

interested in computer-vision based solutions. This was followed by a literature review to ascertain which

techniques had been employed by others and which features were necessary so that the system was likely to meet the

needs of the BVI community. Upon completing the literature review, and evaluating our resources, we defined

specific design goals and chose the hardware and software that we would use for the project.

C. Design Goals

The design goals that follow are based largely upon the criteria set forth in [2].

1) Accuracy within two meters: at a minimum, the navigation system should be able to determine the user’s

position within two meters. To maximize accuracy, we decided to implement a SLAM based approach

instead of using visual odometry which is more subject to drift. Additionally, a map of the indoor

environment would be generated in advance and post-processed to maximize opportunities for accurate loop-

closures. The user would then localize within the previously generated map.

2) Robustness: the error of the system must well-defined and there must be safeguards in place to deal with

system errors. The system’s scalability and ability to localize the user must be known.

3) Not effected by human gait: According to [9], depth information is necessary to overcome the effects of

human gait. To this end, either stereo cameras or an RGB-D camera, e.g. the Microsoft Kinect, should be

used.

D. Evaluate Resources and Choose Development Environment

Ideally, we would develop and implement our design on a state-of-the-art device like Google’s Yellowstone

tablet from Project Tango. However, the Project Tango Development Kit cost $512 and would require us to

become familiar with mobile application development [10]. Since we had a very limited budget and only one

semester to complete the project, we made the decision to design our prototype to run on a laptop that we were

able to borrow from the university. Additionally, we chose the Microsoft Kinect as our sensor since we had free

access to one and it provided the necessary depth information. To obtain access to a large suite of open-source

computer vision and navigation applications, we chose the Robot Operating System (ROS) as our development

framework. ROS is an open-source software package that incorporates a variety of software applications and

libraries that are useful for developing robotic systems [11]. Important to our project, was the fact that ROS

contains several SLAM algorithms, some of which support the Microsoft Kinect. We chose Ubuntu 14.04, a

Linux based operating system (OS), for our project laptop’s OS since it is open-source and fully supports ROS.

E. Design and System Overview

The current design implements an ROS version of RTAB-Map on a laptop computer. A Kinect sensor is used

to collect image and depth information about the environment. To simplify the design of the prototype, position

and navigation information is output to the console – this is just for the purpose of testing by sighted users . The

system begins by determining the user’s location and setting the local coordinate system appropriately in

RTAB-Map. The user is then prompted to provide their destination. This information is used by the path

planning program to generate a list of intermediate destination waypoints that are used to direct the user to their

final destination. When the system detects that the user has reached the next waypoint, the system updates the

current waypoint and the next destination waypoint. The system is robust to deviations from the intended path

because it re-calculates the user’s path whenever it detects that the user has deviated from the pre-determined

path. The logic diagram for the system is shown below in figure 2. The system components are defined as

follows:

1) ROS (Robot Operating System): ROS works as a framework

where individual programs (commonly referred to as nodes)

communicate with each other by way of topics. Each program

can publish or subscribe to any number of topics, each of which

contain their own pieces of data. One example of this is

odometry data; odometry data can be published by a node

(program) that reads a sensor or a node that interpolates the

odometry between a “before and after” image frame. Regardless

of the method, the data gets published and the position and

direction from the odometry could be used in a path planning

node. This allows users to create programs that depend on

information from other nodes without having advanced

knowledge of the node’s implementation. ROS was chosen as

the development framework because it contains packages that

are relatively easy to use and are capable of acquiring data from

the Kinect and using it to generate 3D point clouds and perform

SLAM. Figure 3 below visually describes the flow of data

through the ROS nodes used in the system. The path planning,

user interface, and Odom Listener nodes are depicted as

separate nodes for easier understanding of the information flow,

but on the system they are implemented as a single node.

Figure 2: Path Planning Logic Diagram

2) RTAB-Map (Real-Time Appearance-Based Mapping): an RGB-D SLAM approach that employs a memory

management technique and uses a global loop closure detector. When a newly acquired image is detected as a

previously seen location, a new constraint is added to the map to minimize errors in the map. RTAB-Map

processes the RGB-D data sent to it from the Kinect and creates a 3D point cloud map of features. This map is

continuously processed and when a loop is detected, the map is adjusted to incorporate the loop closure thereby

increasing the accuracy of the map. An image of RTAB-Map in operation can be seen below. The large image

on the right in figure 4 below is a view of the 3D generated

map that RTAB-Map creates from processing the RGB-D

data with SLAM. Figure 5, below on the left, is an image of

just the 3D point cloud map generated from RTAB-Map.

Figure 6, below on the right, is a 2D projection of the 3D

point cloud shown in figure 5.

Figure 5: Sample 3D point cloud generated by RTAB-Map

Figure 3:System Overview Node Graph

Figure 4: Screenshot of RTAB-Map in operation.

3) Kinect: a widely available RGB-D camera that can be purchased off-the-shelf. In ROS, the Kinect is easily

interfaced with RTAB-Map by using a prebuilt package that initializes the Kinect and publishes the RGB-D

data for other ROS nodes to use.

4) Path planning: after a map is generated, a list of waypoints that define a small circular area, each with their own

unique position and identification number, are used to subdivide the generated map. The waypoints were

generated by subdividing the floor into a grid. Each grid line was spaced 5ft apart, and the waypoints were

centered at the grid intersection points. This allows the system to correlate the user’s current position and final

destination to specific waypoints. The path planner takes the user’s current location and final destination as

inputs and generates a sequence of waypoints for the user to travel through in order to reach their destination.

As soon as the user leaves what was considered their current waypoint, the system updates the user’s current

location and the waypoint that is next in the sequence. The path planning program uses Dijkstra’s Algorithm,

but another path planning algorithm could have been used. Figures 7 and 8 below depict the waypoint gird

overlaid on top of the architectural floor plan that was used in the path planning program.

Figure 7: Waypoint Grid

Figure 8: Close-up view of Waypoint Grid

III. Test Procedures

To determine how well RTAB-Map and our path planning program met our design goals, we conducted the

following series of tests.

1) Accuracy within two meters: two accuracy metrics were considered – map accuracy, and localization accuracy.

a) Map Accuracy was examined qualitatively by visually comparing an architectural drawing to a map

generated by RTAB-Map.

b)Localization accuracy was measured quantitatively by comparing an actual change in position with the

change in position reported by the navigation system. The error was desired to be less than 2 meters.

i. Accuracy test #1 was conducted in the lobby of the EIB building on our university’s campus.

ii. Accuracy test #2 was conducted in the hall of the EIB building on our university’s campus.

2) Robustness: system robustness was examined with respect to scalability and loss of localization.

a) To determine scalability, the peer-reviewed literature relating to RTAB-Map was referenced [5].

b) The causes of lost localization were determined by taking note of what actions caused the system to lose

localization during testing.

3) Path Planning: The path planner was tested in two ways.

a) By providing the path planning program with a final position from a known start location, and then

following the generated path to confirm that the path planning program was working.

b) By measuring the current position and corresponding waypoint and then moving a short distance and

confirming that the program accurately determined the new waypoint correctly.

IV. Results and Discussion

The results from the test procedures that were outlined in the previous section are as follows:

A. Map Accuracy

In figure 9 below, the differences between the actual building layout and the map generated by RTAB-Map can

be seen. The top image is from the building’s architectural drawings and the bottom image was generated by

RTAB-Map.

Figure 9: Map of EIB, Architectural (top), RTAB-Map (bottom)

As can be seen from the comparison in figure 9, there is significant variation between the two images. Most of

the distortion in the bottom image is believed to be the result of walls with poor features in the hallway, this

occurs just to the left of the image’s horizontal center.

B. Localization Accuracy

Accuracy test #1 consisted of following the green path shown below in figure 10 – being sure to start and stop

at the same location – and then comparing our actual change in position (0 meters) with the change in position

according to RTAB-Map. The magnitude of the change in position reported by RTAB-Map was the error.

Figure 10: Accuracy Test #1 – 1st floor EIB Lobby.

The test area was approximately 19 meters long by 9 meters wide. The test consisted of three trials. We then

found the mean and standard deviation of the localization error (see Appendix I for the raw test data). The

mean error (µ) and standard deviation (σ) are as follows: µ = 0.65 meters, σ = 0.37 meters. Since the mean

error was less than 2 meters, the system successfully passed this test.

Accuracy test #2 consisted of following the green path shown below in figure 11 – being sure to start and stop

at the same location – and then comparing the actual change in position of 0 meters with the change in position

according to RTAB-Map. The magnitude of the change in position reported by RTAB-Map was the error.

Figure 11: Accuracy Test #1 – 1st floor EIB Hall.

The test area was approximately 73 meters long by 3 meters wide. The test consisted of three trials. We then

found the mean and standard deviation of the localization error (see Appendix I for the raw test data). The

mean error (µ) and standard deviation (σ) are as follows: µ = 10.7 meters, σ = 1.7 meters. Since the mean error

exceeded the maximum allowable error of 2 meters, the system did not successfully pass this test.

Based upon the results from accuracy test #2, the navigation system does not meet the design goal of being

accurate within 2 meters. Since the system passed accuracy test #1 but failed test #2, we compared the tests to

each other to determine why this had occurred. Test #1 was conducted in an area that was 19 meters by 9

meters and test #2 took place in an area that was 73 meters by 3 meters. Based upon these observations, one

might conclude that the larger error associated with test #2 was the result of the longer distance traveled during

test #2. To determine if the system’s error was primarily a result of distance traveled, the mean error per

distance traveled was calculated for both tests; the distance traveled was taken to be the perimeter of the test

area. The mean error per meter associated with test #1 was equal to 0.0116. The mean error per meter

associated with test #2 was equal to 0.0704. Given these results, we concluded that the error was not primarily

a function of distance traveled. Most likely, the relatively large error from test #2 resulted from the hallway

walls having poor features. Additionally, the map that was being used for localization was distorted the most

severely in the hallway. The map distortion was also believed to be primarily due to the poor features in a

section of the hallway.

To overcome both the map distortion and the localization inaccuracy, a laser rangefinder and/or an inertial

measurement unit (IMU) should be incorporated into the prototype design. Satisfactory results could potentially

be obtained by using a device with a laser rangefinder during the mapping phase, and then using a different

device for localization. If an accurate map of the environment had already been created, then accurate

localization results might be achievable with a light-weight device that incorporated an IMU, but did not have a

laser rangefinder. This is an issue that will need to be addressed in future work.

C. Robustness

Based upon the peer-reviewed journal article [5], RTAB-Map employs a memory management technique that

allows the system to maintain real-time operation regardless of the size of the environment. There are, of

course, some caveats to this. Clearly, the map file will need to be stored somewhere and this will require some

quantity of memory. Our 3D map file of the hall and lobby, 2D projection of which is depicted at the bottom of

figure 9, was approximately 350 megabytes. The physical dimensions of the area that was mapped was

approximately 100 meters in length by 6 meters in width. Therefore, the size of the map file would impose

some limitation on how large a particular map could be.

While testing the navigation system, we found that there were several actions that resulted in a loss of

localization. The actions that resulted in a loss of localization are as follows:

Encountering sections of wall that were approximately 3 meters or more in length and had poor

features.

Whenever a majority of the Kinect’s field of view was blocked.

If the user underwent rapid movement – especially in areas that had poor features.

Though loss of localization was manageable during our testing of the prototype, this issue would need to be

resolved in future work.

D. Path Planning

The pathing ability of the path planner was confirmed by testing it along several paths. The path planner was

able to consistently direct the user to the next waypoint in the path thereby performing as needed. The system

was also consistent at reporting the user’s waypoint corresponding to the user’s current position.

E. Future Work

To our knowledge, a commercial product that enables the BVI community to autonomously navigate indoor

environments does not currently exist. However, based upon projects like Google’s Project Tango, I believe

that such devices will exist in the not too distant future. Indoor navigation devices have the potential to make a

significant difference in the lives of those who are blind or vision impaired. Instead of needing to have a

companion aid them in navigating an unfamiliar indoor environment – someone who was blind or vision

impaired could use a smartphone application to get step-by-step directions from the building entrance to their

destination. Hopefully, the autonomy provided by such a device would enable those in the BVI community to

live more independent, fuller lives. Before this can happen though, the ability to reliably track position through

an indoor environment needs to be accomplished. Additionally, it must be accomplished without burdening the

building owner with the need to install additional equipment or conduct additional maintenance. That is the

purpose of generating a digital map that contains the layout of the building and allows the user to perform

localization and navigation tasks. Once the map is generated, it can be stored in the cloud – thus eliminating the

need for the building owner to store the map on their hardware. This method minimizes costs to the building

owner; hopefully, making widespread adoption of such a system more likely.

A future implementation would likely consist of two pieces of equipment. One device would be similar to

our current prototype but would include a laser rangefinder and IMU to improve the accuracy of map

generation. The second device would then be used to accurately localize the user inside of the previously

generated map and would consist of the “Yellowstone” tablet that is part of Google’s Project Tango Tablet

Development Kit [10]. The Yellowstone is a lightweight platform that contains a 4 megapixel RGB-IR sensor,

IR projector, with 3D depth sensing, speakers, Wi-Fi, accelerometer, GPS, gyroscope, and a 4.96 amp-hour

battery; all in a 120x197x16 mm package that runs on Google’s Android [10]. This platform would replace

both the laptop and Kinect camera and is small enough to not encumber the user. RTAB-Map already runs on

the Yellowstone and could be extended in a similar fashion as the current design. Better path planning methods

could be used and reporting to the user could be done through text-to-speech. Text-to-speech and speech-to-text

capabilities are included in the Android software development kit.

There are privacy and security issues that would need to be addressed in future work. The building owners

would need to grant permission to have their building mapped. Due to security concerns, certain buildings

would probably not be able to be mapped. To limit privacy issues, the buildings would preferably be mapped

when they were empty. It would be important to consult an attorney during future work in order to address

security and privacy issues.

V. Conclusion

The primary objective of this project was to design, build, and test a prototype of a navigation system that

could be used to aid members of the blind and vision impaired community in autonomously navigating indoor

environments. With the results from the literature review that was conducted, we specified the design goals. Per

these goals, the system was to be accurate within two meters and robust. Achieving robustness required knowledge

of the system’s scalability and knowledge of which actions resulted in loss of localization.

We were successful in our primary objective. Our prototype hardware consisted of a laptop computer and an

RGB-D camera – specifically, a Microsoft Kinect. The Robot Operating System (ROS) was used as our software

development framework. The navigation system made use of two software packages, an open-source simultaneous

localization and mapping (SLAM) package known as RTAB-Map and a path planning algorithm that was custom

built for this project. Our system used a two-step process. First, a map of the environment was created using RTAB-

Map in SLAM mode and the Kinect sensor. Second, the user would navigate the environment using RTAB-Map in

localization mode (which required the previously generated map), the path planning algorithm, and the Kinect

sensor.

Upon testing the system, we discovered that it was difficult to generate large maps with only the Kinect sensor.

We created a map that was approximately 100 meters in length by 6 meters in width and consisted of a hallway and

a lobby. The map was most distorted in a section of the hallway, about 5 meters in length, where the walls had very

few features. When we tested the accuracy of the system’s localization ability, we found that the system met the

design goal for accuracy in the lobby, but not in the hallway. The mean localization error in the lobby was 0.65

meters, while the mean localization error in the hallway was 10.7 meters. Since the localization error in the hallway

exceeded 2 meters, the system did not meet the design goal for accuracy. We believe that the excessive error in the

hallway can be attributed to the walls having poor features and the fact that the map used for localization was

distorted in the hallway. It is believed that adding a laser rangefinder and/or an inertial measurement unit (IMU) to

the system would solve both the issue of map inaccuracy and localization inaccuracy. Pertaining to robustness, we

believe that the system is highly scalable as it employs a memory-management technique that is designed to ensure

real-time operation regardless of map size. However, there would be some upper limit to map size based upon the

fact that the size of the map file increases with the size of the map. Our map file was approximately 350 megabytes.

We found that the system lost localization whenever the user encountered “featureless” walls in excess of about 3

meters, or underwent rapid movement – especially in areas where the walls had poor features. Additionally, if the

Kinect’s field of view was blocked, the system lost localization. Before the system could be considered robust, a

method for maintaining localization would need to be found. We hope to resolve the accuracy and robustness issues

in future work.

VI. Recommendation

Given the success that we had with accurately localizing the user in Accuracy Test #1, and that the cause of the

inaccuracy of Accuracy Test #2 was likely determined, we believe that a revised system could meet our design goal

for accuracy. Creating an accurate system would likely require a laser rangefinder and/or an IMU. A device similar

to our prototype, but with a laser rangefinder would likely be able to generate accurate maps. This device could also

be used to test the accuracy of RTAB-Map’s localization abilities and the path planning portion of the prototype.

However, it does not seem practical to have a laser rangefinder in the BVI user’s navigation device since they are

expensive, have moving parts, and are cumbersome. Though some additional testing could be performed by adding a

laser rangefinder to our current prototype, continued development would soon require implementation on a mobile

device like Google’s Yellowstone tablet.

We believe that continued research towards designing an indoor navigation system for the BVI community is

warranted and recommend continuing the research that was started in this project. Before purchasing additional

equipment, it would be wise to determine if the Yellowstone tablet is capable of working with the maps that are

being generated by RTAB-Map with the current prototype. This information would help guide the decision as to

whether the next step would be to improve the existing prototype with a laser rangefinder or to begin development

on the Yellowstone tablet immediately.

References

[1] Who, “Visual impairment and blindness,” World Health Organization. p. 1, 2013.

[2] E. Wise, B. Li, T. Gallagher, A. G. Dempster, C. Rizos, E. Ramsey-Stewart, and D. Woo, “Indoor

navigation for the blind and vision impaired: Where are we and where are we going?,” 2012 Int. Conf.

Indoor Position. Indoor Navig. IPIN 2012 - Conf. Proc., no. August 2015, 2012.

[3] E. Bash, “A Context-aware Navigational Autonomy Aid for the Blind,” PhD Propos., vol. 1, 2015.

[4] M. Attia, A. Moussa, and N. El-sheimy, “Map Aided Pedestrian Dead Reckoning Using Buildings

Information for Indoor Navigation Applications,” Positioning, vol. 4, no. 3, pp. 227–239, 2013.

[5] M. Labbe and F. Michaud, “Online global loop closure detection for large-scale multi-session graph-based

SLAM,” IEEE Int. Conf. Intell. Robot. Syst., pp. 2661–2666, 2014.

[6] “Probabilistic Robots,” 2009. [Online]. Available:

https://courses.cs.washington.edu/courses/cse571/07au/slides/09-mapping-slam.pdf. [Accessed: 28-Apr-

2016].

[7] G. Grisetti, K. Rainer, and C. Stachniss, “A Tutorial on Graph-Based SLAM,” pp. 1–11.

[8] Y. Tian, X. Yang, C. Yi, and A. Arditi, “Toward a computer vision-based wayfinding aid for blind persons

to access unfamiliar indoor environments,” Mach. Vis. Appl., vol. 24, no. 3, pp. 521–535, 2013.

[9] D. Zhang, D. J. Lee, and B. Taylor, “Seeing Eye Phone: A smart phone-based indoor localization and

guidance system for the visually impaired,” Mach. Vis. Appl., vol. 25, no. 3, pp. 811–822, 2014.

[10] Google, “Google Project Tango.” [Online]. Available:

https://store.google.com/product/project_tango_tablet_development_kit. [Accessed: 03-Sep-2016].

[11] M. Quigley, K. Conley, B. Gerkey, J. FAust, T. Foote, J. Leibs, E. Berger, R. Wheeler, and A. Mg, “ROS:

an open-source Robot Operating System,” Icra, vol. 3, no. Figure 1, p. 5, 2009.

Appendix I

A. Accuracy Test #1

Accuracy test #1 - trial 1 start (m) finish (m) difference (m) magnitude (x,y) mean mag. (m) std deviationx 0.005 1.08 1.075 1.08 0.65 0.37y 0.01 0.025 0.015z blank blank

Accuracy test #1 - trial 2x 0.162 0.067 0.095 0.39y -0.082 0.299 0.381z 0.122 0.966 0.844

Accuracy test #1 - trial 3x 0.067 -0.111 0.178 0.50y 0.299 0.761 0.462z 0.966 1.619 0.653

Figure 12: Raw Data for Accuracy Test #1

B. Accuracy Test #2

Accuracy test #2 - trial 1 start (m) finish (m) difference (m) magnitude (x,y) mean mag. (m) std deviationx -0.115 2.45 2.565 12.60 10.7 1.72y 0.045 12.38 12.335z

Accuracy test #2 - trial 2x -0.105 4.307 4.412 9.23y -0.161 -8.27 8.109z -0.189 4.622 4.811

Accuracy test #2 - trial 3x -0.117 3.17 3.287 10.31y -0.074 -9.85 9.776z -0.15 6.63 6.78

Figure 13: Raw Data for Accuracy Test #2

Appendix II

Pseudo-code for Dijkstra’s which was used in path-planning algorithm.

1 function Dijkstra(Graph, source): 2 3 create vertex set Q 4 5 for each vertex v in Graph: // Initialization 6 dist[v] ← INFINITY // Unknown distance from source to v 7 prev[v] ← UNDEFINED // Previous node in optimal path from source 8 add v to Q // All nodes initially in Q (unvisited nodes) 910 dist[source] ← 0 // Distance from source to source11 12 while Q is not empty:13 u ← vertex in Q with min dist[u] // Source node will be selected first14 remove u from Q 15 16 for each neighbor v of u: // where v is still in Q.17 alt ← dist[u] + length(u, v)18 if alt < dist[v]: // A shorter path to v has been found19 dist[v] ← alt 20 prev[v] ← u 2122 return dist[], prev[]