D, I'm having many of the same issues, though my app is a little different in nature ... i don't know that this will help much, but here's my thoughts so far:
- when determining the sample time rate use event.timestamp in your sensor listener callback. you'll see more or less the same results, but more accurate all the same. - i found the same with subtracting G from the three acceleration components, that is, you can't rely on SensorManager.GRAVITY_EARTH, you're better off having your app calibrate a local G on each handset. - note that when filtering out G you need orientation data as well. this posed a problem for me though: SensorManager has a method, getOrientation, however I couldn't get it working. So instead I set 2 listeners, one for accelerometer and one for orientation ... meaning when I filter G, i don't really know that I'm using the right orientation data to calculate the different components of G because the two callbacks are called independantly, so I can only make a best- guess based on event.timestamp. How are you filtering out G? - there's a simple free app on the market called "Accelerometer xyz values" or something like that, just search for "Accelerometer" ... gives a simple line chart of all three accelerometer axiis over time. - from what i found around the net, this is a common issue with accelerometers, even the more sophisticated ones used in robotics, tho i couldn't actly find specs on the accelerometer used in G1. but don't be too mad at HTC, i'd imagine iPhone has similar issues :) - as for noise filtering, up to now i've tried a simple High Pass filter. In this case, I set the device down flat and allow my app to measure the range of noise coming from the sensors to create a threshold. Then I only admit values with a higher absolute value than the the threshold. I just built this app this week and so far have had mixed results tho. Now for Kalman filtering. I do have a little experience with Kalman filtering and here's some issues to consider: 1) *performance*, Kalman is efficient, however we're dealing with a managed runtime and limited hardware. even if we get a Kalman filter running, it's hard to say now that it would perform well enough without moving to the Android NDK (native development kit) 2) Kalman assumes noise is normally distributed (like a bell curve), however I've seen evidence that the noise is biased somehow. you even noted that motion seemed to change the noise characteristics of the sensor, tho i didn't see the same thing. but i *have* seen that playing any audio will *definitely* change the noise characteristics of the sensor (although technically it's not inherent noise, it's the sensor reacting the EM field of the speaker's driver). 3) Kalman is efficient because it is "hard-coded" with a sense of what you expect your data to look like. So say you always want to track a circular motion: you'd tell your Kalman filter "i'm expecting something vaguely circular, now do your stuff and de-emphasize the data that makes this look like something that's not a circle (the noise)". So in your case, if I can assume you want to track arbitrary motion, i'm not sure Kalman is useful. However, one possibility: if you restricted your application to a handful of basic gestures you could have a two-stage filter in which 1st you determine if the gesture is even close to something you handle, then apply an appropriate Kalman filter to it to remove noise. Then, this handful of basic gestures could be composited together to allow more sophisticated gestures like: arc -> sharp angel -> inward sprial, etc 4) Unless you're experienced with the math used in Kalman, you could spend a few weeks getting it right ... it's not the simplest thing in the world i'm afraid :) anyway, i feel your pain. at the moment i have a decent app built up for analyzing the characteristics of the acceleromater ... if you're interested let me know and we mite post it to the market sometime soon. hth, chris On Jul 9, 5:23 pm, dilit <dmit.lit...@gmail.com> wrote: > Sounds like some signal processing/filter math is in > order.http://www.cs.unc.edu/~welch/kalman/ > > Anyone with experience? > D > > On Jul 9, 1:18 pm, dilit <dmit.lit...@gmail.com> wrote: > > > > > Just in case, > > > We did calibrate our phones. > > E.g. My phone's Gravity value is more like 8.7 vs 9.81. > > While static, the phone's accel values were acceptable. > > As soon as the phone was in motion, the acceleration (position) > > data went out to lunch. > > > FYI, marketing = lying 99% of the time. IMO > > > On Jul 9, 1:05 pm, dilit <dmit.lit...@gmail.com> wrote: > > > > We are writing an application that uses acceleration sensor data to > > > plot phone's movement in 3D. > > > We are finding gross inconsistencies in the actual data output by the > > > sensor. Also, sampling rates > > > vary greatly from 8 to 200 millis. (using System.currentTimeMillis()) > > > > Specifically, when we try to draw a circle with G1 flat on the table > > > all the time (filtering out gravity accel 9.8), > > > most of the time we would get a plot of phone's position that is not a > > > circle at all. Lots of times, it would be close to a straight line. > > > Sometimes, it would start drawing an arc, but would not close the > > > circle shooting off in a random direction. > > > > We tried to eliminate the time variable, by substituting a constant > > > time sampling rate (10 millis) to calculate phones position, but the > > > result was > > > very close to what we had before (shapewise). Also, the acceleration > > > in Z direction when the phone is displaced lying flat on a table (XY > > > plane) varies too > > > by +/- 2 units which is a lot. > > > > I do not think it is an error in our code, as we have checked it many > > > times. If there were an error indeed and the > > > accelerometer worked properly, we would see a consistently wrong > > > depiction of the phone's movement. Unfortunately, repeating the same > > > movement > > > (circle) would produce sometimes wildly differently shaped plots. > > > > It all comes down to us wanting to know if that is indeed the case > > > that the G1 accelerometer is very unreliable and inconsistent device > > > when used for more or less precise > > > measurements? Is there some documentation/facts paper that would tell > > > us just how reliable accelerometer is? > > > > Thanks for you help! > > > Dmitriy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
