Location Aware Programming Framework

Transcription

1 Location Aware Programming Framework CSE237B Course Project, Fall 2004 by Apurva Sharma Introduction Time as a variable has been integrated into programming for quite some time. Most languages provide support for Time either as a language feature or through run-time libraries. The same is not true for Location. Anyone wishing to develop an application that takes into account the current position of the device on which it is running is required to develop the necessary framework himself. This hasn t traditionally been that much of an issue because mobile devices weren t that common, and location sensors like GPS weren t available on mobile devices thus making accurate location discover hard. This situation is to change soon. There are an increasing number of mobile devices shipping across the world with build in GPS receivers and it is also easy to attach a small external GPS receiver which is readily available, through USB/Serial/Bluetooth interface. Being interested in developing an application for mobile devices using Bluetooth interface I was motivated into this project to develop a generic framework that provides support for using Location as a variable in any application without being concerned about what interface is used to obtain the Location data, how to program that interface etc. Motivating applications Navigation system is probably the most common example that revolves around Location and it holds good for mobile devices too. Another application is associating the current Location information with snapshots taken with a mobile device s built-in digital camera for integration into Weblogs. Some other useful applications are Location based device customization (e.g. switch to silent mode in meeting rooms/hospitals/movie theatres); Location based alerts; Location based communities (e.g. I want to chat with all Superman fans in my current Location) etc. Project Goals The framework that we develop should have the following characteristics: Ability to connect to a GPS device and read GPS data from it. Although we are implementing for a Bluetooth GPS interface, the framework should be extensible such that it can be used with any other interface so if in the future we need to run the framework on a device with built-in GPS support we don t need to modify the framework or our application extensively. Ability to associate user-friendly names (e.g. House, Hospital, Office etc.) to Location objects and to access Location objects by their assigned names as well as geographical coordinates. Provide operations on Location objects such as computing distance, testing whether two Location definitions overlap etc.

2 Ability to associate application defined listener to Location events. Allow the application to control the rate at which location is updated. This might be important for application that wishes to conserve power for example. Related Work Upon researching for similar work I found similar packages for Java mobile platform (J2ME). JSR82 specifies an extension to J2ME that standardizes how J2ME applications can communicate using Bluetooth interface and JSR179 defines a framework for Location aware programming in Java. If we have both of these then our work is done and I don t need to do anything for this project. The challenge here is both JSR82 and JSR179 are extensions and not part of standard J2ME and thus not supported for most mobile devices. Since I had already committed myself to this project I decided to implement a framework for once such device Microsoft Windows Smartphone 2003 powered mobile phone. Even though my device had a Bluetooth interface and J2ME support it did not support J2ME extensions for Location or Bluetooth. Even the.net Compact framework that comes with the phone doesn t have API to access the Bluetooth interface. The final option left was to program natively using embedded Visual C++ and develop my own framework to access the Bluetooth interface, get GPS data and provide for Location aware programming. Hardware and Software Summary I tested my software using a Microsoft Windows Smartphone 2003 powered mobile phone and a Belkin F82951 Bluetooth GPS Receiver. Programming was done in Microsoft embedded Visual C sp4 The application reads GPS data in National Marine Electronics Association s NMEA-0183 interface standard that is commonly supported by GPS devices. GPS NMEA Sentences The National Marine Electronics Association (NMEA) has developed a specification that defines the interface between various pieces of marine electronic equipment. The standard permits marine electronics to send information to computers and to other marine equipment. GPS receiver communication is defined within this specification. Most computer programs that provide real time position information understand and expect data to be in NMEA format. This data includes the complete PVT (position, velocity, time) solution computed by the GPS receiver. The idea of NMEA is to send a line of data called a sentence that is totally self contained and independent from other sentences. There are standard sentences for each device category and there is also the ability to define proprietary sentences for use by the individual company. The most important NMEA sentences include the GGA which provides the current Fix data, the RMC which provides the minimum GPS sentences information, and the GSA which provides the Satellite status data. For the framework I only use RMC and GGA sentences which are discussed below:

3 $GPRMC Sentence (Position and time) Example (signal not acquired): $GPRMC, ,V, ,N, ,E,,,041299,,*1D Example (signal acquired): $GPRMC, ,A, ,S, ,E,0.00,89.68,211200,,*25 Field Example Comments Sentence ID UTC Time $GPRMC hhmmss.sss Status A A = Valid, V = Invalid Latitude ddmm.mmmm N/S Indicator S N = North, S = South Longitude dddmm.mmmm E/W Indicator E E = East, W = West Speed over ground 0.00 Course over ground 0.00 Knots Degrees UTC Date DDMMYY Magnetic variation Magnetic variation Checksum *25 Terminator CR/LF Degrees E = East, W = West $GPGGA Sentence (Fix data) Example (signal not acquired): $GPGGA, , ,N, ,E,0,00,0.0,0.0,M,,,,0000*00 Example (signal acquired): $GPGGA, , ,S, ,E,1,04,24.4,19.7,M,,,,0000*1F Field Example Comments Sentence ID UTC Time Latitude $GPGGA hhmmss.sss ddmm.mmmm N/S Indicator S N = North, S = South Longitude dddmm.mmmm E/W Indicator E E = East, W = West Position Fix 1 0 = Invalid, 1 = Valid SPS, 2 = Valid DGPS, 3 = Valid PPS Satellites Used 04 Satellites being used (0-12)

4 HDOP 24.4 Horizontal dilution of precision Altitude 19.7 Altitude in meters according to WGS-84 ellipsoid Altitude Units M M = Meters Geoid Separation Separation Units DGPS Age DGPS Station ID 0000 Checksum *1F Terminator CR/LF Geoid separation in meters according to WGS-84 ellipsoid M = Meters Age of DGPS data in seconds Framework Design Figure 1 Figure1 shows a typical application using the framework. The application is required to provide a concrete implementation of the interface LocationListener which is drawn as MyLocationListener above. The framework interface IOConnector describes a generic connector and the concrete class BTConnector included with the framework implements the facilities of connecting and communicating with a Bluetooth device. NMEAParser is a library used by the framework to parse NMEA sentences read from the GPS receiver. The class Location in the framework stores all Location specific information coordinates, name, type (placeholder for pointer application specific data structure) etc. and its only purpose is as a aggregating the Location specific data. All operations over the Location objects are performed through the LocationProvider class which is the center of the framework. During the course of the design I made the following design decisions to make the framework generic and useful across a wide range of applications:

5 Use of interfaces IOConnector and LocationListener to abstract out the connection and Location Event Listener parts from the framework which are either dependent on the connection type or are specific to the application. Since the application might have its own requirements on when and how frequently should the location be updated (e.g. to conserve power), assuming a fixed interval of update, or even assuming a periodic update might have been limiting. So LocationProvider provides a single function RefreshLocation that the application is expected to call when an update is desired. Defining what constitutes a Location was the most challenging decision. I looked at the kind of scenarios where I would be using the framework. I might want to define a room as a location, or a building or a campus. From this I concluded that maybe cuboids would best represent a Location (region). But then the problem was what default size to choose. Should the application assume a default size and let the user correct whenever it makes a bad guess. But then the Location object would keep changing which might not be desirable. Also the overhead required for this generic model both in terms of computational complexity, storage required as well as user interaction was too high. I thus formed a simpler model. I decided to represent a location as cylinder whose base is specified by a center (latitude, longitude, altitude) and radius (horizontal tolerance) and height (vertical tolerance). I also decided to get user input for all parameters at Location creation, thus avoiding runtime complexity. This model also simplifies the implementation of operations for Location objects. Overlapping locations: It is possible for a user to define two locations that share a region of space. It could be the user s intention or this could be the result of overestimating one of the tolerance parameters. I decided to permit the creation of such objects while providing a function to determine if two location objects overlap. If the application decides to disallow such objects all it need to do is use the check overlap function at construction time. Description of classes constituting the framework: Location: Provides storage for location specific information (name, coordinates, horizontal tolerance, vertical tolerance etc.). Also permits a type parameter which can be used to store application-specific information. LocationProvider: Provides all kinds of operations for Location, maintains the current location information and is responsible for invoking the listener callback functions when location events happen. IOConnector: Interface for a generic connector. Has a method for Read/Write, checking the connection status. BTConnector: An implementation of IOConnector interface for Bluetooth. Provides extra methods for device discovery. LocationListener: Interface for a generic listener. Has event callback for LocationEntry, LocationExit, and LocationUpdate. NMEAParser: Provides parsing for GPS NMEA sentences and is used by LocationProvider.

6 Sample Application This being my first experience working the Smartphone platform I wanted to choose an application that was simple enough to implement within the time frame of the project, yet would demonstrate how to use the framework and its features. The application that I developed allows creating Location objects, and provides support for setting up warnings (simulated by vibrating the device for 0.5 sec for each warning) for both location entry and location exit events. It also provides a display with the current location name, and positioning and time information obtained from GPRMC sentence. The implementation is divided into a main program (ProjectL.cpp) that performs all initialization, implements the UI and invokes the LocationProvider to update the location information through a Timer and MyLocationProvider.cpp which provides a LocationListener specific to this application making the phone vibrate in response to entry/exit events and updating an edit control in response to update event with current location data. The user is allowed to choose a GPS device from a list of discovered Bluetooth devices and specify a time interval for polling the GPS device. I wasn t able to obtain valid values for Altitude during my testing (probably something to do with what it receives from the satellite and not a bug since the GGA spec says that altitude might be wrong) and hence this application ignores the vertical tolerance fields. My GPS device always returns incorrect value for the Date field, but I have verified that Time, Latitude and Longitude fields are correct. The following images demonstrate the application interface (going from left to right and top to bottom): 1. Initial Display 2. First Step Configure Connection

7 3. Select Bluetooth GPS device and polling interval. 5. Creating a new Location 4. Displays the current location information. If the Location is not assigned a name, Unknown is displayed in place of name. 6. The New Location Dialog

8 7. Example New Location entry 8. Updated display with the new location Windows Smartphone 2003 platform The following software was required for development: Microsoft embedded Visual C sp4 Microsoft Windows Smartphone 2003 SDK Microsoft ActiveSync All software is available for free download from Microsoft. The sample code for Bluetooth was available only through Windows CE.NET 4.2 evaluation kit. This platform also has issues with deployment. If the vendor wishes he can configure the device to only allow deployment of signed applications. For that one needs to purchase a license for signing application and submit his application to get them signed. Fortunately the device I tested with permitted installing unsigned applications. My application produces only one executable so deployment is straightforward, but when several files are part of the application the deployment can be done through a CAB file. Unfortunately the default settings in embedded Visual C++ are for Pocket PC platform CAB file and the process for Smartphone platform is manual. A reference is included for this. Conclusions I have successfully implemented a Location aware programming framework for the target platform and demonstrated its use using a sample application location based reminder service. The framework is generic enough to allow extension for different interfaces and support applications with diverse requirements.

9 Future Work One feature that I see missing from my current implementation is the ability to save created locations to permanent store and load it at subsequent application invocations. This could further be extended to allow synchronization of locations with another device as is available for Contacts, Notes and Mails already. The other direction I see is building a more complex and useful application using the framework. Reference: for a description of common NMEA sentences for a free C++ GPS NMEA parser used by my implementation. Microsoft website for reference information about developing for Microsoft OS powered mobile devices. Software and downloads for windows mobile An application for Nokia Smartphone that uses network cell id to provide location aware services. An article about using GPS Bluetooth to get Location data on a mobile device to link with photos to store on a Weblog. Smartphone application deployment guide. Microsoft Windows Smartphone 2003 SDK.