PoliInfo Reader
- Details Hits: 6431
PoliInfo is an augmented reality application, aimed to provide location and identity based content to the user in a friendly manner.
Goals and overview of the design:
The system is based on the client-server architecture. The client is represented by the user of the actual Android application and should be given a user/password pair for authentication with the server. Each user name is associated with a group of roles (e.g. John Doe may be associated with the following roles: student, teacher and guest). Access to content items is role-based (students don't have access to the content intended for teachers only). In the same time, a single user can be assigned any number roles and a single content item may be intended any number of roles. In this way identity based content is delivered to the client. in order to address the second concern, location based content, the server has to be able to get the current location of the client. We decided to use QR barcodes for this task because they offer the desired level of accuracy (when the user sees a barcode and scans it a request is sent to the server which now knows that the user is a couple of feet away from the barcode) and they represent a solid tool for augmented reality applications. The other alternatives were GPS or GSM based, but neither provided the accuracy and reliability of the previously mentioned solution. Using the identification system and knowing the location of the user, the server is able to offer information that is addressed to a specific user and that is relevant to that specific location. For instance, a student located in the "EG hallway" area is probably interested in knowing how to get to EC 004 lecture room, not AN 030 (location based) or a person from the maintenance department may consider guidance related info irrelevant since he or she already knows that place like the back of his/her hand but that person may be interested in knowing what kind of maintenance operations were conducted in that area (identity based).
Usage:
Now that the basic idea is clear (hopefully), we can delve into details about the way the system should be used. We will examine two use cases: basic user (content destination) and system administrator.
The basic user should download and install the application on his device and provide the user name and the password. The application uses permanently the internet connection in order to communicate with the server. Once the authentication is done, the user has to point the camera to the desired barcode. The info comprised by the barcode represents the identification info based on which the server understands what information is relevant to that barcode. The client sends a request that contains the id. When the response is received, an augmented reality layer is displayed based on the info received (currently a jpg image is used). If the user wants more information the server generates a new feed of information and sends it piece by piece to the user in a request-response fashion.
The system administrator is able to create/modify/delete users, roles, content items and/or barcodes. These actions are carried out using simple HTML forms after the authentication is done.
Development tools or technologies:
Client side:
- Barcode recognition : ZXing library and the facilities offered by Android API for camera control
- org.apache.http – for issuing requests and getting responses from the server
- Android SDK
Server side:
- hosting : Google App Engine
- Web application : J2EE Servlet API
- Persistence: Google Data Store. Objectify framework (for easier data manipulation)
Other:
- Eclipse Helios with ADT and Google Plugins
- Subclipse for SVN project management
Problems encountered during development:
- Performance and power consumption constraints on the client side. The application logic involves continuously capturing sample frames, extracting the barcode position, decoding the barcode itself and then rendering the augmented reality layer on top of the camera layer. Our aim was to find a balance between “looks” and practicality. Thus we decided to keep the graphics in the augmented reality layer quite simple so as to limit the limit the footprint of the rendering process and keep the application robust and responsive. In the near future due to the advent of high performance tablets we might release a version of the app designed for tablets that may incorporate 3D shapes in the augmented reality layer.
- Because wireless networks sometimes suffer from reliability problems we employed certain caching techniques at the client side (in case of the sticker graphics and feed items) and avoid creating useless request-response cycles.
Knowledge or experience gained during development:
- Image processing
- Using the tools provided by the Android SDK for camera control
- Extended knowledge regarding the application lifecycle, lifecycles of the activities, Android multi-threaded environment
- Using the com.apache.http packet for sending HTTP request and receiving HTTP responses during the communication with the server
- Experience in project management using SVN
- Google App Engine API for Java
Route map for future releases:
- Extensive testing for ensuring the reliability of the application before any extensive usage
- Extend the content types that can be delivered to the clients
- Improve on the image processing algorithms and perform code refactoring for getting better performance while keeping the feature list at least the same
- Improve the admin dashboard used for content and user management
- Create other application based on the framework offered by the current one