- My account
Example application for accelerometer/gyroscope processing on Android
Fri, 2012-02-10 21:59
In the previous parts we have seen how to simulate the gravity vector with the gyroscope if the accelerometer is not able to measure gravity correctly (because it is subject to motion acceleration too beside the gravity acceleration) and how to update this simulated gravity vector from the accelerometer to prevent the accumulation of measurement errors. At the end of the previous post we had a gravity vector which was normally taken from the accelerometer but our algorithm switched to gyroscope simulation automatically when needed.
We need just one more step to enable cool applications and that step is very evident. If you remember my Droidcon 2011 presentation (slide 24), the acceleration measured by the accelerometer is the sum of gravity and motion acceleration. If both are present, they cannot be separated in the general case without additional sensor input. But now we have the gravity acceleration which is reasonably exact even if the accelerometer is subject to motion acceleration too. This means that we can extract the motion acceleration by subtracting the simulated gravity acceleration from the acceleration measured by the accelerometer.
This opens the way for applications based on dynamic movements much like the Wii games with Motion Plus accessory (which actually do the same as the Motion Plus accessory is really just a 2+1 axis gyroscope).
The example program is attached to this post. You have to be logged in to the Sfonge site to access it.
After all these simulation script, let's see something hands-on. The example program is the implementation of all these ideas we have seen so far. You need an Android phone with gyroscope to test it. The gyroscope processing algorithm is implemented in SamplingService.java. GyroAccelActivity is really doing only visualization, getting callbacks from SamplingService.
When started, the service enters the calibration state. This state is necessary to get a good fix of the initial gravity vector so the device should not be moved when calibrating. The initial gyroscope drift experienced on my Nexus S also ceases during the calibration period.
Then the service enters the measuring state and implements everything we discussed so far. It samples the accelerometer and the gyroscope paralelly, simulates the gravity vector if it finds out that the accelerometer is probably subject to motion acceleration and calls back the activity with the calculated motion acceleration vector. The acceleration is shown as movement of a large white ball (quite ugly, actually). The x and the y components of the motion acceleration move the ball horizontally and vertically while the size of the ball is calculated from the z component of the motion acceleration.
Note that the motion acceleration is expressed in the coordinate system of the device itself, so you may get some unexpected result if the device is not parallel to the floor surface. As we have the gravity vector, rotating the motion acceleration vector to the Earth's coordinate system is simple exercise (took me several days to get it right ;-)). We calculate two rotations (around z and y axes) to rotate the gravity vector into the z axis. At the same time we rotate the motion acceleration vector with the same rotations. This yields a normalized motion acceleration vector that would have been measured if the device were parallel to the surface.
If you are done with playing the ball, you will notice that analyzing these 3D acceleration vectors are not trivial. You can try setting the SamplingService.DEBUG field to true, then the application produces the usual /sdcard/capture.csv file (beware, it can be large) that you can download to your computer and visualize with the attached Sage script.
Sun, 2012-02-12 20:19#1
sensor and gps loging on sqlite
I'm very interested for a project of mine to log sensor data on a sqlite file, but cannot achieve this goal so far i can only write the sensor buffer to file but this method is prone to buffer overflow.
I'm using the android phone as a tool to log sensor and gps data for a long time, let say 2 hour and than get this data for further study.
SQLITE is a good choise because theoretically supports high frequency data feed which is my case.
Please let me know if there is any solution i can use.
Sun, 2012-02-12 21:28#3
Wham i'm trying to say is
Wham i'm trying to say is that the only way i'm able to write the data to the file is through buffer dumps which depending on the frequency of the data, normal, game or fast, cause the buffer to overflow if i want to retrive data for a long period.
So it's obvious to try writing the data to sqlite as they happen, and this is what i cannot achieve.
Thu, 2012-03-22 09:34#5
sampling rate of android acceleromerter
I want sampling frequency 20Hz,ie 20 samples/second.But my phone accelerometer has sampling frequency of only 17Hz.Is there any way to give delay by program to get 20 samples?
Fri, 2012-03-23 06:32#7
I have done FFT in phone by taking the accelerometer reading.But its frequency is changing randomly evenif I placed the phone simply on the table.Is this happening due to any error in sampling?How to correct it?
Mon, 2012-04-09 01:43#9
more information in AR
Because of popular papers related to AR problem, 25Hz on realtime smart phone ( X6, or android OS) is better, and the uncertainty of Hz caused from onSensorChange() android,
From my experiment, NORMAL mode is so bad, we can not extract better features when we apply filtering
From CPU and battery consumption of GAME mode take 40% CPU on Samsung galaxy note ( for only sensor collecting data application)
From your presentations, I would like to supply these things:
- Other advices such as: 25Hz is ok for AR,
- UI is acceptable choice for cost consumption or qualified data demand
normally, on samsung galaxy note 17Hz for UI mode, we can apply linear or cubic spline interpolation to increase to 25Hz. We should apply to all 3-axises at specific time (predefine algorithm to find this time, suggest: compare from variances of axises.
for filtering: smooth filtering is ok, but I refer to use wavelet db 4-5, since it can reconstructs original data more 90% accuracy.
almost each behavior of AR ( walking, running, take 0.8 -1 second)
from above reason, we should use wavelet db4 ( it takes 8 neighbours of each central point)
Mon, 2012-04-09 15:47#11
- Reconstructing: wavelet in my case is only used to filter noise, by reconstruct we can check the accuracy of it.
- Wavelets for filtering: I use daubichies wavelet different from Morlet wavelet in your paper. I haven't applied Morlet yet.
Almost paper use db wavelet in gait authentication. From my experiment, accelerometer data consist many white noise (gaussian). Daubichies seperate our acceleration into 2 components (high pass, low pass).
For example with db8, it will manipulate correllation of ith signal to (i+15)th signal. With Fastest mode in HTC Nexus One ( from my experiment 22Hz), with window size 5 seconds.
We can get 110 samples, with db8 operation, we can maximum downsample 3 times ( level 3).
Regarding to this problem, there still has some papers use daubichies from level 4-8 for hard threshold (high frequency component is set to 0). But this has principal that more kept correlated sample derive accuracy is decrease. When low level is chosen , it will make noise.
Wherefore, db 5-6 is acceptable.
- I only use built-in acceleromter ( BMA 150) for widely popularity on smart phone.
- Interpolation: Linear interpolation is quick and easy but low precision, and new point is like step although it were used in many AR paper.
For smoother, cubic is considered since each interval uses 2 control points and 2 tangents.So, I only use linear and cubic in animation game and AR.
I will implement Whittaker-Shannon to compare.
- In optimization problem: until now, I only focus to simple features with portable trained model but also guarantee acceptable accuracy and resolving personalize model from known model and velocity problem with only accelerometer.
Thank you for your materials, it can be my further studies.