Client Architecture: Conceptual Overview

The client application is the part of solution which runs on mobile devices. In general Android applications consit of the following elements:

• Foreground Activity (Class with processes wihich run in the foreground and enable user interaction - User Interface)
• Background Service (Class with processes which run in the background and exchange data with foreground activity and other services)
• Intermittent Activity (The processes which can be modified directly by user and run in the background after user's modifications)

In case of solution for motion determination the main client's task is to retrieve the values from acceleration sensor. Optionally, in case we want to enable automatic emergency call with location report, the client has to determine the location by simply reading GPS values or getting the information from available web services which are able to determine the approximate location by base station the phone currently uses. In order to enable storing informations for later motion analysis in case the internet connection is unavailable, we can add the database and the logic for data storing and later retrieval before sending.

The picture represents the client application concept. The red rectangles represent activities and blue are the services. The application consits of three dialogs: main dialog, login and settings. The main dialog displays current activity status, acceleration values and location informations. On application start the user has to sign-in to the server with username and password so at the beginning the login dialog appears. Some options modifications such as enable/disable location report are possible by using Settings dialog.

There are four services running in the background . The Location Service retrieves the location informations and broadcasts the location data which are received at main (GaitLink) activity, Communication Service and optionally at Database Service. The Acceleration Service retrieves the data from accelerometers and also broadcasts the data which are received by the same components. The Database Service listens for the broadcasted messages which can represent the data that have to be stored or the commands for data reading and sending to Communication Service.

Communication Service implements multiple threads. Broadcast Receivers for acceleration and location messages run in separate thread. Every received message is sent to queue. Another thread is periodically retrieving the messages from queues and send the messages to the server. In order to prevent queue congestion the reading frequency has to be higher than queue writing frequency. The main reason for using queues are possible transitory network delays or drops. Without intermediate measurements storing to the queue every value would have to be successfully sent before reading next values from the sensors which is certainly fair too unreliable.

Determining Body Movement with Mobile Phone

Currently I'm trying to develop a solution which would determine the type of movement by measuring accelerations with mobile phone.

By reading acceleration data many things can be discovered. The persons's walk pattern is almost as unique as fingerprint. By reading the walk (movement) patterns early stages of a possible disease could be recognized as well. Another thing that could be implemented is fall/collision detection and automatic emergency call. These are just a few of the possible uses of the solution.

So far the mobile devices haven't been powerful enough to perform all the required processes independently, but luckily the data transmission is cheap and fast enough so the main analysis can be performed on the server.

The accelerometers are cheap so almost every new phone have built-in sensors. Currently I'm using HTC Dream G1 (Android) phone and developing client application in Java. The server-side application has been built in C# .NET.

So far I have established the connection between the phone and server. The phone sends the location data and acceleration measurements to the server which runs the analysis.
I've managed to determine some simple user behaviour patterns such as walk, run and rest by measuring the frequency components of the pattern.

Below there are the charts for collision and walk in time and frequency domain.

These are the acceleration values of simulated collision:



and these are the accelerations of walk:
In both cases The DFT has been performed on 32 sample points at sampling frequency 2.5 Hz.
This is the phone screen (any suggestion about the design is more than welcome). The phone gets the location address by performing reverse geocoding (part of the existing framework) and the activity status by questioning the server.