Indoor Positioning Using a Modern Smartphone

Transcription

1 Indoor Positioning Using a Modern Smartphone Project Members: Carick Wienke Project Advisor: Dr. Nicholas Kirsch Finish Date: May 2011 May 20, 2011

2 Contents 1 Problem Description 3 2 Overview of Possible Solutions 3 3 Implemented Solution 3 4 Method WiFi Trilateration Adding Movement and Previous Guess Comparing with Floorplan System Acquiring Data Building Map Access Points Accelerometers Implementation IndoorLocalization BuildingMap DirectionSensor WifiService WifiDataProcessor Implementation Issues Evaluation Results Improvements List of Figures 1 Likely Position Area Display output using only WiFi Display output using previous location and movement vector Display output using predicted directions of movement Sample measurements to determine path loss parameters Sample measurement of accelerometers Flow diagram showing class communication Finished project locating a user

3 1 Problem Description Indoor localization is an important tool for a wide range of applications. These range from safety scenarios such as finding somebody inside a building or helping firefighters navigate through a burning building, to business men trying to find a room in a complex building, to a sports fan finding the restrooms, a concession stand, or his/her seat inside an arena. The most common localization system currently deployed is the Global Position System (GPS). However, due to signal attenuation and noise, GPS devices cannot provide accurate and precise positioning information inside of buildings. A different system needs to be created to solve this problem. 2 Overview of Possible Solutions Proposed solutions to precise indoor localization can be categorized into three categories based on the infrastructure required to implement the design: none, previously/already installed, and new infrastructure. They each provide their own benefits and drawbacks. By requiring no infrastructure, the algorithm could be applied to any building. However, these systems rely on how the position is changing over time, from a known start point, often measuring steps. With these methods, error increases with over time, until the location is recalibrated, which may be done by scanning room numbers or special bar codes. This process is called dead reckoning. [4, 5] The other end of the spectrum requires installing new infrastructure, from RF and ultrasonic transmitters [3] to infrared sensors [1]. These systems have the benefit of dedicated hardware that can be intelligently installed to provide better localization data. However, they are limited to buildings with the infrastructure installed, and it may be very costly to set up such systems, especially in large buildings. The system described in [3] costs US$150 for a 10 m 10 m room. This leads to using infrastructure that is commonly found inside buildings, wireless networks. If the location of the WiFi access points are know, measuring the strength of signals at a point will give an approximation of the distance between each access point and the device. Trilateration then can be used to approximate the location of the receiver. However, the accuracy of WLAN trilateration is limited by the dynamic range of the received signal strength (RSS). Depending on the layout of the building and possible interferences, the RSS can vary at a signal location. [2] 3 Implemented Solution In order to have better location detection, we propose the following modifications to WLAN positioning. The implemented solution compliments WLAN trilateration by using information from the accelerometer and compass of the Dell Streak handheld computer. The accelerometer data shows the direction of movement relative to the device and the compass data can be used to convert this to a vector relative to the building. On every update, the position is first estimated by WLAN trilateration. By comparing the direction of movement with the geometry of the building, this area can potentially reduced, giving a better approximation. This project is an application written in Java for the Android 2.2 operating system. Figure 1(a) shows a possible location heat map due to two WLAN access points. The gray triangles represent the access points and the shaded area represents the area that most likely contains the position of the device. Using only this information does not provide enough information to make an accurate guess [2]. However, when this is combined with the information that the device is moving towards the right of the image, the approximation can be reduced 3

4 to the yellow area shown in Figure 1(b). It is reasonable to assume the person is not walking towards the wall, but instead the hallway to the right of the reduced heat map. (a) Using only WLAN Trilateration (b) Using Trilateration and Movement Figure 1: Likely Position Area The display on the device will track the user as he/she moves throughout the building. At each update time, a specific point will be calculated and output to the display, drawing a line from the previous point. Options will allow the user to display more information, such as the WLAN trilateration heat map, WLAN plus movement heat map, and the direction of movement. Because this system only relies on wireless LAN networks and for the user to carry a smart phone with WLAN connectivity, accelerometers, and a compass, this system can potentially be used by many people in various buildings. 4 Method The following sections detail the method WiFi signals and other sensors are used to determine position. These steps are getting the initial guess using WiFi, comparing this guess to the previous location, and finally comparing the direction of movement to the movement areas. 4.1 WiFi Trilateration An approximate guess is determined using only the WLAN signals. Because the wireless signals attenuate as they travel from the transmitter to the receiver, the RSS is a function of the distance between the two ends of communication. This can be modeled using the log-distance path loss model: P rx (db) = P d0 (db) + 10n log 10 ( d d 0 ) (1) where P rx (db) is the power received in decibels, P d0 (db) is the received power at reference distance d 0, and n is the path loss exponent, and d is the distance from the access point. The 4

5 Figure 2: Display output using only WiFi variables P d0 (db) and n are parameters of the building and access point that can be determined by sampling the received power at known distances ( 5.1.2). Once an approximate distance from each access point is calculated, trilateration is used to determine the best guess location. Since the position is overdetermined, a least squares method of approximation is used. The best guess, p, is found by minimizing the sum of the of the squares of the error, S(p). Because this is nonlinear, solving requires an iterative approach that samples the function. S(p) = k (distance(p, p i ) d i ) 2 (2) i=0 where k is the number of access points in range of the device, p i is the location of the i th access point, and d i is the approximate distance from the i th access point. The output due to this stage is shown in Figure 2. The orange triangles represent the access points that are within range, the red circles represent the best guess radii from each of the access points, and the teal circle is the guess using least-squares estimation. 4.2 Adding Movement and Previous Guess While the scan to get the RSS of the access points is in progress, the direction the user is moving is updated. The availability of accelerometer data can be used along with the compass to calculate this. When a user is walking, the vertical acceleration changes over time, Figure 6. Movement is detected by checking if there is significant change between sequential vertical acceleration readings. Once it is determined that the user is moving ( 5.1.3), the direction is based on the orientation of the phone. It can be assumed that the user will be walking along the major axis of the device, which is found using the device s compass. The compass gives the orientation relative to the Earth. With this information and the known orientation of the building relative to the Earth, the orientation of the phone relative to the building is calculated. The guess from the previous scan is shifted by the accumulated movement between scans. It is expected that the user will be within both circles. The new guess is calculated by determining the circle that is centered equidistant from both circles and contains the whole intersection of the two circles. This is the circle that will be shifted during the next iteration. Figure 3 shows the output of this stage. This produces the guess represented by the shaded blue circle. It is the intersection of the current WLAN trilateration guess (teal circle) and the 5

6 Figure 3: Display output using previous location and movement vector shifted previous guess (purple circle). The faint purple circle is the previous guess before being shifted. 4.3 Comparing with Floorplan This guess achieved from the previous sections, can be narrowed down further by using the direction of movement again. Indoors, it is typical for people to walk along a similar pattern, e.g. along the hall or through a doorway. With the building broken into sections based on the typical direction of movement, the position of the user can be snapped to a location where the direction of motion most closely follows predicted movement patterns. This final output is shown in Figure 4. The shaded blue circle, the area of interest, is the same from the previous stage, but the predicted movement areas are now shown. The darker areas represent the areas that more closely match the direction of movement and, therefore, are more likely to contain the device. The position from the previous guess is snapped to the most likely area. Figure 4: Display output using predicted directions of movement 6

7 5 System This section describes the work that was required to implement the solution. Information about the building, access points, and device was learned through different means. This was followed by writing the code to perform the localization. 5.1 Acquiring Data The algorithm relies on knowing the building map, predicted movement patterns, path loss parameters for the APs, and how to use the device sensors to detect motion. This section describes the methods used to determine this information Building Map The building map consists of two parts: an image of the floorplan and a set of rectangular areas with predicted movement patterns. The image was from a PDF file of Kingsbury, with a high resolution ( ). Through measuring long distances of 20 to 35 meters and comparing to the pixel count, the ratio of pixels to meters was determined to be To eliminate overlap due to rounding errors, the movement areas were defined in pixels instead of meters Access Points Both the location and the path loss parameters of the access points needed to be found. After writing a WLAN Scanner to scan for a specific MAC address and record the distance and signal strength, a plot of RSS versus logarithmic distance was created and shown in Figure 5. A regression line was calculated based on the mean RSS at each distance. The y-intercept of the plot is P d0 (db), the RSS at d 0 and the slope is n, the path loss exponent (1). These parameters are used to calculate the distance in meters, which is converted to meters using the ratio determined in Section This was repeated for different model routers and APs located on different floors because they do not all share the same parameters. Figure 5: Sample measurements to determine path loss parameters The same scanner was used to locate all the access points in the target area. The RSS of each MAC address was watched as the device was moved through the target region. Once the minimum RSS was found, the device was physically located and marked on the map. These coordinates are stored in pixels. 7

8 5.1.3 Accelerometers Similar to the WLAN Scanner, an application was written to record accelerometer data and timestamps. It was used in different scenarios such as walking at varied speed holding the phone in multiple orientations. The accelerometer values were plotted against time and there was not a simple correlation between a x and a y values and the direction of movement relative to the device; a z was used to detect walking. When the change between successive values of a z is greater than a threshold of 0.35 m/s 2, it is assumed the user is moving. Figure 6 shows the accelerometer values while walking slowly along a major axis of the device. It can be seen that the average value of both a x and a y have magnitude, even though one should average out to zero. Figure 6: Sample measurement of accelerometers 5.2 Implementation This section describes the design of the system from the code level, separating each class and describing its responsibilities and implementation. It discusses the communication between classes and describes in detail the purpose of the important classes. A chart describing these classes and interactions is shown in Figure 7. IndoorLocalization is the main application that maintains control over the other aspects. DirectionSensor and WifiService are the services that acquire data from the sensors and send it to the main application. WifiDataProcessor is a worker class that is used to calculate the best guess using an iterative approach to least squares approximation. Finally, BuildingMap is the View that is used for drawing, which handles showing the location given by the main application. The classes that are not shown, AccessPoint and MovementArea simply hold data about a single AP or movement area and provide methods for accessing information and the state of the objects IndoorLocalization This class is the main Activity that runs. Therefore, it handles the menu input, manages the services, and performs the synthesis of WLAN and movement data calculations. This should be done in a separate thread, but since they are reasonably fast it does not create an issue. This class stores sets of AccessPoint and MovementArea that are used in multiple places. For example the APs are needed to both calculated location and draw to the device. 8

9 Figure 7: Flow diagram showing class communication This class uses a BroadcastReceiver for each of services it starts, DirectionSensor and WifiService. When the services finish, the information is broadcast to other classes. This class accepts the information and processes it. When there is new accelerometer data, the movement, if present, is added to a cumulative vector. When there is new WiFi position information, the class performs the calculation from the stages of the algorithm described in Sections 4.2 and 4.3. This information is then sent to the BuildingMap to update the display, after clearing the state, such as AccessPoint RSS levels and the movement vector BuildingMap This class is the View that is used as the display for the application. It loads the floorplan image from the resources and draws it to the screen. The BuildingMap has a public interface for updating the location and orientation information, and has access to the APs and movement areas for drawing but otherwise only requires the information passed when there is new data available. Drawing is done by scaling and translating the canvas so that calculations are done in map pixel coordinates. The image is then drawn followed by a series of calls to Canvas.draw...() methods to overlay the proper information. This class also handles the multitouch gesture input. By implementing the OnGestureListener and OnScaleGesureListener, the BuildingMap is able to listen for scale and scroll events that are converted to zoom and translate the map and information. 9

10 5.2.3 DirectionSensor The DirectionSensor Service uses the SensorListener to receive notification when accelerometer and geomagnetic sensor values change. When either changes, many times a second, the orientation is updated using the SensorManager.getOrientation() method and the orientation as well as the accelerometer values and timestamp are sent using Context.sendBroadcast(). Since there is little processing time, another thread is not needed WifiService The WifiService uses a BroadcastReceiver to listen for complete WiFi scans. When there is a completed scan, the Service creates a new WifiDataProcessor to process and calculate the new information. Each scan completes in about a second. The Service then waits until the processing is done, and is notified using a message Handler. When this occurs, a new scan is initiated and a message is broadcast if enough scans have occurred. Multiple scans occur before a position guess because it is useful both to reduce the error due to outliers in RSS as well as give the user an ability to calibrate position using WLAN WifiDataProcessor Because this processing could take a few seconds to calculate, it is performed in a new thread that is created when the class is created. After adding the appropriate RSS to each AccessPoint, the code checks if enough scans have occurred. If not, it returns and asks for more another scan before sending a guess. Once enough scans have completed, the RSSs for each AP are averaged, and the approximate distance is returned using interfaces built into the AccessPoint class. This is then followed by an iterative approach to solve the least square estimation (Section 4.2). The result of this is then returned to the Handler, the WifiService. 5.3 Implementation Issues During implementation, there were a couple of roadblocks. First, the algorithm does not work well inside of rooms. This is because direction of movement is mostly random and cannot be predicted well. Therefore, there is no easy way to snap the user to a particular place in the room. To simplify the algorithm, rooms were left out and the target area was reduced to the hallways. This is reasonable because most uses of localization indoors is navigation through the halls. A second issue was calculating the direction of movement. Initially it was planned to use all three accelerometers in the device to calculate direction of movement. The horizontal accelerometers were going to be used to determine how the user is moving relative to the device; for example, it would know if the user was moving diagonally. When the accelerometer data was collected, there was not a clear correlation between the horizontal accelerations and direction of movement relative to the device. This is most likely due to the slight shaking horizontal shaking due to user s arm moving during walking. 6 Evaluation The following is an evaluation of the success of the project. It discusses the completion of the project relative to the design goals, as well as improvements to the project that were discussed but not implemented due to time constraints and/or complexity. 10

11 6.1 Results The major goal of this project was to improve on basic WLAN RSS trilateration for localization indoors. The algorithm that was implemented complimented this information with direction of movement and information about the building to more precisely locate the device and user. When using only WLAN information, the device is generally accurate to approximately 10 to 15 meters. There are exception, usually when the user is located towards the edges of the map where there are fewer access points. The radius can be reduced by complimenting WiFi trilateration with the movement vector. Depending on the amount of intersection between consecutive guesses, the location can be as accurate as 8 meters, but will be at least as accurate as one of the two approximations. Comparing direction of movement to the floor plan, leads the same area of interest, but the best guess is updated to be in the area where the direction of movement matches predicted movement patterns. This can produce a wrong best guess when the user is close to an intersection and is not moving along a hallway, but this is uncommon. This algorithm was able to more accurately predict locations and also reduced the jumping of locations with just WLAN information. In this scenario, it took many more scans for the position to settle because it could not use previous location as reliably. The algorithm shifts the last guess based on movement, so if movement is not tracked then there are no good ways to use previous location. Figure 8 shows the working system tracking the location of the user. Figure 8: Finished project locating a user 6.2 Improvements Although the algorithm met design goals, it is not without flaws and possible improvements. The most substantial improvement would be allowing the user to calibrate position. Much like how users can read bar codes with the camera of modern smartphones, if the user was able to scan a room number sign, the application would be able to precisely and quickly be able to calibrate the position of the device. Future location guesses will use this information to better approximate location. Secondly, tracking people inside of rooms should be implemented. This would require another algorithm that complements the algorithm already implemented. One possible solution would be a state machine that keeps track of if and, if so, which room the user is in by knowing 11

12 where the entrances to each room are. Once a user is inside of the room, he we stay in the room until he uses one of the exits. Another improvement would be smoother updating of position. The current implementation uses each WLAN scan as a discrete iteration of the algorithm, meaning the position will not update between scans. This has potential issues where if a user moves around a corner, the device will think that the user moved at an angle. This could be solved by updating the location as the user moves and using filtering of the new locations so that they jump less. This system could be updated to allow for path finding and augmented reality. If the localization is precise enough based on the improvements above, the program could route the user from the current location to a specific room. Furthering this, the camera on the device can be used as a heads-up display. The user would be able to hold the camera up, and the device would overlay the calculated path on the image. References [1] G. Borriello, J. Hightower, and R. Want, SpotON: An Indoor 3D Location Sensing Technology Based on RF Signal Strength, UW CSE Technical Report # , University of Washington, Department of Computer Science and Engineering, Feb 200, [2] U. Grossman, M. Schuach, and S. Hakobyan, The Accuracy of Algorithms for WLAN Indoor Positioning and the Standardization of Signal Reception for Different Mobile Devices, International Journal of Computing, Vol. 6, No. 1, 2007 [3] C. Randell, H. Muller, Low Cost Indoor Positioning System, Lecture Notes in Computer Science, Volume 2201, 2002, available at [4] A. Serra, D. Carboni, and V. Marotto, Indoor Pedestrian Navigation System Using a Modern Smartphone, ACM, New York, available at [5] E. Vildjiounaite, E. Malm, J. Kaartinen, and P. Alahuhta, Location Estimation Indoors by Means of Small Computing Power Devices, Accelerometers, Magnetic Sensors, and Map Knowledge, Lecture Notes in Computer Science, Volume 2414/2002, 2002, available at http: // 12