1. Tried to use event.timestamp instead of System.currentTime Still the same result: device skips some measurements. Many times, this is detrimental to being able to produce an accurate drawing of the phone motion. Some important acceleration "peaks" are missed. One way to combat this problem may be having the user repeat the motion several times or have him initially draw what they think the motion is on the screen. This could be used to supplement some missing data.
2. Subtracting G from different axes based on the phone's orientation may not be a good idea. The reason is that the orientation measurements also fluctuate somewhat wildly when the phone is moved in XY plane. On some measurements fluctuation reached 30-45 degrees. Makes me wonder if the measurements of acceleration and orientation are done by 1 sensor unit. see here http://forum.xda-developers.com/showthread.php?t=503055 At any rate, this G subtraction would introduce an additional significant error, I think. Also, I have been filtering G with an additional orientation sensor as getOrientation is not working. I used the following formulae to calculate adjustments due to G: double adjX = GRAVITY_EARTH * Math.sin(roll); double adjY = GRAVITY_EARTH * Math.sin(-pitch); double adjZ = GRAVITY_EARTH * Math.cos(roll) * Math.cos(pitch); Where GRAVITY_EARTH was obtained through calibration. 3. I have been plotting Accel X,Y against t and displacement plot XY with Gnu Plot. That is a very nice tool! Allows to plot in 3D too. We limited motion to the table top plane in 2D till other issues can be resolved. 4. We had some luck with drawing circular motion. One thought was that the sensor has centripetal acceleration in addition to the normal phone accel. The phone is applied centripetal force, not the measuring sensor part inside. Unfortunately, the results for other gestures were more mixed. For example, drawing letter M somehow produced an M like plot moving in right to left direction versus it was drawn right to left. Anyone has better luck, please let us know :) D On Jul 10, 3:04 am, keyboardr <[email protected]> wrote: > I'm not 100% familiar with this aspect of the G1, but I know Nintendo > had a similar problem with their Wiimotes. That's why they have the > sensor bar set up: they couldn't get their accelerometers to be > accurate enough to track position. > > On Jul 9, 2:23 pm, dilit <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
