Develop Reference

Detect pattern of motion on an Android device

I want to detect a specific pattern of motion on an Android mobile phone, e.g. if I do five sit-stands.
[Note: I am currently detecting the motion but the motion in all direction is the same.]
What I need is:
I need to differentiate the motion downward, upward, forward and backward.
I need to find the height of the mobile phone from ground level (and the height of the person holding it).
Is there any sample project which has pattern motion detection implemented?

This isn't impossible, but it may not be extremely accurate, given that the accuracy of the accelerometer and gyroscopes in phones have improved a lot.
What your app will doing is taking sensor data, and doing a regression analysis.
1) You will need to build a model of data that you classify as five sit and stands. This could be done by asking the user to do five sit and stands, or by loading the app with a more fine-tuned model from data that you've collected beforehand. There may be tricks you could do, such as loading several models of people with different heights, and asking the user to submit their own height in the app, to use the best model.
2) When run, your app will be trying to fit the data from the sensors (Android has great libraries for this), to the model that you've made. Hopefully, when the user performs five sit-stands, he will generate a set of motion data similar enough to your definition of five sit-stands that your algorithm accepts it as such.
A lot of the work here is assembling and classifying your model, and playing with it until you get an acceptable accuracy. Focus on what makes a stand-sit unique to other up and down motions - For instance, there might be a telltale sign of extending the legs in the data, followed by a different shape for straightening up fully. Or, if you expect the phone to be in the pocket, you may not have a lot of rotational motion, so you can reject test sets that registered lots of change from the gyroscope.

It is impossible. You can recognize downward and upward comparing acceleration with main gravity force but how do you know is your phone is in the back pocket when you rise or just in your waving hand when you say hello? Was if 5 stand ups or 5 hellos?
Forward and backward are even more unpredictable. What is forward for upside-down phone? What if forward at all from phone point of view?
And ground level as well as height are completely out of measurement. Phone will move and produce accelerations in exact way for dwarf or giant - it more depends on person behavior or motionless then on height.

It's a topic of research and probably I'm way too late to post it here, but I'm foraging the literature anyway, so what?
All kind of machine learning approaches have been set on the issue, I'll mention some on the way. Andy Ng's MOOC on machine learning gives you an entry point to the field and into Matlab/Octave that you instantly can put to practice, it demystifies the monsters too ("Support vector machine").
I'd like to detect if somebody is drunk from phone acceleration and maybe angle, therefore I'm flirting with neuronal networks for the issue (they're good for every issue basically, if you can afford the hardware), since I don't want to assume pre-defined patterns to look for.
Your task could be approached pattern based it seems, an approach applied to classify golf play motions, dancing, behavioural every day walking patterns, and two times drunk driving detection where one addresses the issue of finding a base line for what actually is longitudinal motion as opposed to every other direction, which maybe could contribute to find the baselines you need, like what is the ground level.
It is a dense shrub of aspects and approaches, below just some more.
Lim e.a. 2009: Real-time End Point Detection Specialized for Acceleration Signal
He & Yin 2009: Activity Recognition from acceleration data Based on
Discrete Consine Transform and SVM
Dhoble e.a. 2012: Online Spatio-Temporal Pattern Recognition with Evolving Spiking Neural Networks utilising Address Event Representation, Rank Order, and Temporal Spike Learning
Panagiotakis e.a.: Temporal segmentation and seamless stitching of motion patterns for synthesizing novel animations of periodic dances
This one uses visual data, but walks you through a matlab implementation of a neuronal network classifier:
Symeonidis 2000: Hand Gesture Recognition Using Neural Networks

I do not necessarily agree with Alex's response. This is possible (although maybe not as accurate as you would like) using accelerometer, device rotation and ALOT of trial/error and data mining.
The way I see that this can work is by defining a specific way that the user holds the device (or the device is locked and positioned on the users' body). As they go through the motions the orientation combined with acceleration and time will determine what sort of motion is being performed. You will need to use class objects like OrientationEventListener, SensorEventListener, SensorManager, Sensor and various timers e.g. Runnables or TimerTasks.
From there, you need to gather a lot of data. Observe, record and study what the numbers are for doing specific actions, and then come up with a range of values that define each movement and sub-movements. What I mean by sub-movements is, maybe a situp has five parts:
1) Rest position where phone orientation is x-value at time x
2) Situp started where phone orientation is range of y-values at time y (greater than x)
3) Situp is at final position where phone orientation is range of z-values at time z (greater than y)
4) Situp is in rebound (the user is falling back down to the floor) where phone orientation is range of y-values at time v (greater than z)
5) Situp is back at rest position where phone orientation is x-value at time n (greatest and final time)
Add acceleration to this as well, because there are certain circumstances where acceleration can be assumed. For example, my hypothesis is that people perform the actual situp (steps 1-3 in my above breakdown) at a faster acceleration than when they are falling back. In general, most people fall slower because they cannot see what's behind them. That can also be used as an additional condition to determine the direction of the user. This is probably not true for all cases, however, which is why your data mining is necessary. Because I can also hypothesize that if someone has done many situps, that final situp is very slow and then they just collapse back down to rest position due to exhaustion. In this case the acceleration will be opposite of my initial hypothesis.
Lastly, check out Motion Sensors: http://developer.android.com/guide/topics/sensors/sensors_motion.html
All in all, it is really a numbers game combined with your own "guestimation". But you might be surprised at how well it works. Perhaps (hopefully) good enough for your purposes.
Good luck!

How to/Should I implement a Kalman filter to get accurate Accelerometer data?

I want to get as accurate data from the built in accelerometer in an Android phone as possible. I want to track two dimensional movement in x and y axis and even the small movements must be registered.
When I look at the data from the accelerometer / linear acceleration when the phone is flat on a table it changes a lot when i should be zero.
I have looked at Kalman filters, it seems like a good approach but I am having problems setting up a model.
1. Is a Kalman filter the way to go to get as accurate data as possible from an accelerometer?
2. Will a Kalman filter work? Maybe i have misunderstood but it seems like the acceleration or the velocity must be constant?
3. How do I set up the model for using Kalman filter? I'm having trouble understanding (among other things) what the process noise is?

A Kalman filter applies when all measurements (of acceleration in this case) are equal to the true value plus a measurement error. The measurement error is the process noise. For for the original Kalman filter to apply the noise must be normally distributed, i.e. sometimes the error will be positive, sometimes negative, and on average zero.
If you jerk your android phone quickly back and forth, there'll be large accelerations. I'd suggest recording the accelerometer readings in that kind of action, and reviewing by eye to see whether it looks like there's the readings are indeed subject to some kind of normally distributed process noise. My guess is that the answer will be "No", i.e. I expect they readings when plotted on a graph will be smooth-ish. But if they're not smooth, a Kalman filter could be useful.
If you're trying to use accelerometer readings to work out location, I think your project is doomed to failure. Acceleration is the 2nd derivative of position with respect to time, and I've never heard of anyone being able to integrate the readings with sufficient accuracy to be at all useful.
I have applied a Kalman filter successfully to GPS readings on an Android phone to improve the location estimate. See Smooth GPS data for code that implements a Kalman filter for that. I subsequently wondered whether velocity and perhaps acceleration data could be used to improve the location estimate. Although I never followed up on that idea, see https://dsp.stackexchange.com/questions/8860/more-on-kalman-filter-for-position-and-velocity for the maths that I was considering using.
The optimal way of using all the sensor inputs (GPS, accelerometer, gyroscope, etc) to get a good estimate of location is a very hard (and interesting) problem. To find out more, the key phrase to search for is "Sensor fusion". On this subject, there's an old youtube video at http://www.youtube.com/watch?v=C7JQ7Rpwn2k .

You might find this thread useful. I came across the same issues
We think the variance when lying flat might be an issue with Gimbal lock confusing the calculations but thats just a theory right now. We've also noticed the covariance in each axis alters depending on the orientation of the device, which might be gimbal lock interference too, but again just a theory
Implement a Kalman filter to smooth data from deviceOrientation API

Tracking linear movement on mobile devices [duplicate]

I was looking into implementing an Inertial Navigation System for an Android phone, which I realise is hard given the accelerometer accuracy, and constant fluctuation of readings.
To start with, I set the phone on a flat surface and sampled 1000 accelerometer readings in the X and Y directions (parallel to the table, so no gravity acting in these directions). I then averaged these readings and used this value to calibrate the phone (subtracting this value from each subsequent reading).
I then tested the system by again placing it on the table and sampling 5000 accelerometer readings in the X and Y directions. I would expect, given the calibration, that these accelerations should add up to 0 (roughly) in each direction. However, this is not the case, and the total acceleration over 5000 iterations is nowhere near 0 (averaging around 10 on each axis).
I realise without seeing my code this might be difficult to answer but in a more general sense...
Is this simply an example of how inaccurate the accelerometer readings are on a mobile phone (HTC Desire S), or is it more likely that I've made some errors in my coding?

You get position by integrating the linear acceleration twice but the error is horrible. It is useless in practice.
Here is an explanation why (Google Tech Talk) at 23:20. I highly recommend this video.
It is not the accelerometer noise that causes the problem but the gyro white noise, see subsection 6.2.3 Propagation of Errors. (By the way, you will need the gyroscopes too.)
As for indoor positioning, I have found these useful:
RSSI-Based Indoor Localization and Tracking Using Sigma-Point Kalman Smoothers
Pedestrian Tracking with Shoe-Mounted Inertial Sensors
Enhancing the Performance of Pedometers Using a Single Accelerometer
I have no idea how these methods would perform in real-life applications or how to turn them into a nice Android app.
A similar question is this.
UPDATE:
Apparently there is a newer version than the above Oliver J. Woodman, "An introduction to inertial navigation", his PhD thesis:
Pedestrian Localisation for Indoor Environments

I am just thinking out loud, and I haven't played with an android accelerometer API yet, so bear with me.
First of all, traditionally, to get navigation from accelerometers you would need a 6-axis accelerometer. You need accelerations in X, Y, and Z, but also rotations Xr, Yr, and Zr. Without the rotation data, you don't have enough data to establish a vector unless you assume the device never changes it's attitude, which would be pretty limiting. No one reads the TOS anyway.
Oh, and you know that INS drifts with the rotation of the earth, right? So there's that too. One hour later and you're mysteriously climbing on a 15° slope into space. That's assuming you had an INS capable of maintaining location that long, which a phone can't do yet.
A better way to utilize accelerometers -even with a 3-axis accelerometer- for navigation would be to tie into GPS to calibrate the INS whenever possible. Where GPS falls short, INS compliments nicely. GPS can suddenly shoot you off 3 blocks away because you got too close to a tree. INS isn't great, but at least it knows you weren't hit by a meteor.
What you could do is log the phones accelerometer data, and a lot of it. Like weeks worth. Compare it with good (I mean really good) GPS data and use datamining to establish correlation of trends between accelerometer data and known GPS data. (Pro tip: You'll want to check the GPS almanac for days with good geometry and a lot of satellites. Some days you may only have 4 satellites and that's not enough) What you might be able to do is find that when a person is walking with their phone in their pocket, the accelerometer data logs a very specific pattern. Based on the datamining, you establish a profile for that device, with that user, and what sort of velocity that pattern represents when it had GPS data to go along with it. You should be able to detect turns, climbing stairs, sitting down (calibration to 0 velocity time!) and various other tasks. How the phone is being held would need to be treated as separate data inputs entirely. I smell a neural network being used to do the data mining. Something blind to what the inputs mean, in other words. The algorithm would only look for trends in the patterns, and not really paying attention to the actual measurements of the INS. All it would know is historically, when this pattern occurs, the device is traveling and 2.72 m/s X, 0.17m/s Y, 0.01m/s Z, so the device must be doing that now. And it would move the piece forward accordingly. It's important that it's completely blind, because just putting a phone in your pocket might be oriented in one of 4 different orientations, and 8 if you switch pockets. And there's many ways to hold your phone, as well. We're talking a lot of data here.
You'll obviously still have a lot of drift, but I think you'd have better luck this way because the device will know when you stopped walking, and the positional drift will not be a perpetuating. It knows that you're standing still based on historical data. Traditional INS systems don't have this feature. The drift perpetuates to all future measurements and compounds exponentially. Ungodly accuracy, or having a secondary navigation to check with at regular intervals, is absolutely vital with traditional INS.
Each device, and each person would have to have their own profile. It's a lot of data and a lot of calculations. Everyone walks different speeds, with different steps, and puts their phones in different pockets, etc. Surely to implement this in the real world would require number-crunching to be handled server-side.
If you did use GPS for the initial baseline, part of the problem there is GPS tends to have it's own migrations over time, but they are non-perpetuating errors. Sit a receiver in one location and log the data. If there's no WAAS corrections, you can easily get location fixes drifting in random directions 100 feet around you. With WAAS, maybe down to 6 feet. You might actually have better luck with a sub-meter RTK system on a backpack to at least get the ANN's algorithm down.
You will still have angular drift with the INS using my method. This is a problem. But, if you went so far to build an ANN to pour over weeks worth of GPS and INS data among n users, and actually got it working to this point, you obviously don't mind big data so far. Keep going down that path and use more data to help resolve the angular drift: People are creatures of habit. We pretty much do the same things like walk on sidewalks, through doors, up stairs, and don't do crazy things like walk across freeways, through walls, or off balconies.
So let's say you are taking a page from Big Brother and start storing data on where people are going. You can start mapping where people would be expected to walk. It's a pretty sure bet that if the user starts walking up stairs, she's at the same base of stairs that the person before her walked up. After 1000 iterations and some least-squares adjustments, your database pretty much knows where those stairs are with great accuracy. Now you can correct angular drift and location as the person starts walking. When she hits those stairs, or turns down that hall, or travels down a sidewalk, any drift can be corrected. Your database would contain sectors that are weighted by the likelihood that a person would walk there, or that this user has walked there in the past. Spatial databases are optimized for this using divide and conquer to only allocate sectors that are meaningful. It would be sort of like those MIT projects where the laser-equipped robot starts off with a black image, and paints the maze in memory by taking every turn, illuminating where all the walls are.
Areas of high traffic would get higher weights, and areas where no one has ever been get 0 weight. Higher traffic areas are have higher resolution. You would essentially end up with a map of everywhere anyone has been and use it as a prediction model.
I wouldn't be surprised if you could determine what seat a person took in a theater using this method. Given enough users going to the theater, and enough resolution, you would have data mapping each row of the theater, and how wide each row is. The more people visit a location, the higher fidelity with which you could predict that that person is located.
Also, I highly recommend you get a (free) subscription to GPS World magazine if you're interested in the current research into this sort of stuff. Every month I geek out with it.

I'm not sure how great your offset is, because you forgot to include units. ("Around 10 on each axis" doesn't say much. :P) That said, it's still likely due to inaccuracy in the hardware.
The accelerometer is fine for things like determining the phone's orientation relative to gravity, or detecting gestures (shaking or bumping the phone, etc.)
However, trying to do dead reckoning using the accelerometer is going to subject you to a lot of compound error. The accelerometer would need to be insanely accurate otherwise, and this isn't a common use case, so I doubt hardware manufacturers are optimizing for it.

Android accelerometer is digital, it samples acceleration using the same number of "buckets", lets say there are 256 buckets and the accelerometer is capable of sensing from -2g to +2g. This means that your output would be quantized in terms of these "buckets" and would be jumping around some set of values.
To calibrate an android accelerometer, you need to sample a lot more than 1000 points and find the "mode" around which the accelerometer is fluctuating. Then find the number of digital points by how much the output fluctuates and use that for your filtering.
I recommend Kalman filtering once you get the mode and +/- fluctuation.

I realise this is quite old, but the issue at hand is not addressed in ANY of the answers given.
What you are seeing is the linear acceleration of the device including the effect of gravity. If you lay the phone on a flat surface the sensor will report the acceleration due to gravity which is approximately 9.80665 m/s2, hence giving the 10 you are seeing. The sensors are inaccurate, but they are not THAT inaccurate! See here for some useful links and information about the sensor you may be after.

You are making the assumption that the accelerometer readings in the X and Y directions, which in this case is entirely hardware noise, would form a normal distribution around your average. Apparently that is not the case.
One thing you can try is to plot these values on a graph and see whether any pattern emerges. If not then the noise is statistically random and cannot be calibrated against--at least for your particular phone hardware.

Count Steps using accelometer in android [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to Count the Number of Steps Using the Accelerometer
Are there any well known algorithms to count steps based on the accelerometer?
Hi i have developed android application. In one module I have to create a pedometer. Now at this stage I have to count the steps user walked by using accelormeter. I have search on internet and found different methods but none of that working. I have tried this
Does anyone have an idea how to achieve my goal? Any help is appreciated.

The simplest solution would be to have a time-window and a number of thresholds. The signal gets a form of a double wave, and you can split a step into several parts. You may need to have several windows and corresponding threshold values to recognise one step. But keep in mind that this signal will change if someone is walking upstairs/downstairs or running or just walking with different pace. You will get great variability if you actually going to try it with several participants.
Threshold values will differ greatly between devices. Frequency of measurements will also have an impact. Standard frequency that allows one to detect walking with normal pace is about 10Hz, some devices use 20Hz, if you go over this you will get lots of data and little information. Manufacturers do use different versions of accelerometers, so if your software works on one phone, there is no guarantee it will work on the other device even of the same model.
I would start from plotting your signal first. Also don't forget that the phone can be in different positions in a pocket (unless you fix it somehow) so the threshold values will float. All clinical pedometers are usually affixed to the leg in a certain position.
Consider using mono-axial accelerometry instead of 3-axial, the signal analysis gets much more easier to begin with. Also take a look at the Fourier transformations and wavelet analyses.
See the image below to get a basic idea of how walking looks with a 3-axial accelerometer. I made it when was doing similar task (walking is the noisy bit).
And this is how walking looks with a mono-axial accelerometer (again noisy bits)

This seems to be pretty reasonable and accurate:
Enhancing the Performance of Pedometers Using a Single Accelerometer
Anyhow, I am also interested in finding a good algorithm.

Need to read android sensors really fast

Issue:-
I am developing a application which
needs a new acceleration datum every 5
millisecond.
My Approach:-
I have created a remote service
which only reads the acceleration
data from SensorManager.
I had also set the read rate to
"DELAY FASTEST" while initialize the
SensorManager.
Then i use IPC to communicate too my
main application to get these
reading.
Problem:-
If i put a log inside
onSensorChange() event i receive a
new sensor data every 20 ms time. But i need data every 5 ms.
Question ?
Is there any better method to read
the senor data faster.
Is there any way i can poll the
senor data rather that waiting for
the event handler to trigger the
event?
Please help me to find a better solution to read the data in 5 ms time or poll the acceleration data.

As I understand it, the accelerometer is very noisy and not suitable for fast operations. See the GoogleTech talk on sensor fusion at http://www.youtube.com/watch?v=C7JQ7Rpwn2k for a more authorative explanation and what you can do about it. Short explanation: Use the gyro for high speed events and the acceleromenter to correct the drift.

For people referencing this post today, while I think #robinr has a good point and is very true, that is not an answer, however stackoverflow wont let me comment on it directly.
For answers to the first question reference Native Activity. And. Android does not guarantee data rate, it only makes sure that you get the minimum (or maximum if you requesting too much).
The accelerometer is Not noisy, at least not today. Its just way too good at picking up EVERYTHING. So you need to use some filtering if you want a good accelerometer algorithm. If you have excellent filters, accelerometer is actually preferable to all else because it is usually a lower power sensor, has the highest supported frequency, and is most likely to be available when the screen is off(compared to other sensors).
The caveat to a forceful method of using native and extracting the highest frequency is that your device support will be limited. This is why Android doesn't support direct frequency settings.
In response to question 2; your going to have to throttle your sensor events manually by monitoring the timestamp.

Regarding the speed of the Android SensorManager, I would be more inclined to suspect the speed of the Android file I/O that is generating your log. You might try a benchmark of your sensor read code without writing to the log. Something like logging the current time in milliseconds, then doing 1,000,000 sensor reads, then logging the current time again. You might still have to use the C version to get the data, but at least you'll know definitively where the bottleneck lies.

There are a few issues I can see with this. The first is that you are most likely going to bog down the whole rest of the system if you try to force polling of sensor data that fast. If all you are doing is polling sensors that may be ok, but if you want any kind of user interaction, I am not sure that's going to work. Also, why do you need data that fast? If you're interacting with people there is no way there going to notice a lag of even 100ms.

have you resolved your problem?
i have a similar project, to get sample at least every 10 ms (about 100 Hz), here. But, nothing change in samples that i got, even when i set setEventRate = 10 milisec.
So i think there is any hardware limitation since i've read BMA220 datasheet (my sensor hardware) only provides 62,5 Hz for Orientation Sub-mode.