Hi there, I guess I'm doing the pretty much same project as you r. Actually I've no idea about how to answer your question...but just wanna ask you how you filter G out?
You mentioned " I creates a threshold of ±1 m/s^2 for every output of accelerometer to filter out which sample is gravity (9.807f). " May I know more specifically how you did this? Cuz I'm also facing the problem that G is out there which causes the real moving acceleration can't be told apart... What I'm current doing first of all is, since the phone actually decomposes G onto x,y,z automatically when the phone is tilted, I just manually decompose G using pitch and roll and then reversely compensate x,y,z accelerations, which theoretically is supposed be cancel out G. However, the thing is, SensorListener() only reports me either acceleration or orientation one at a time; I can't get the both at the same time. Therefore, G is decomposed based on the values of pitch and roll that are always "out of date"; they are not corresponding to the new acclerations. This is where the error comes out. So I doubt if I can really use this approach. May I know how you did this in order to get the moving acceleration? Thanks a lot! DD On Sep 27, 6:22 pm, LVMH <lvmh...@gmail.com> wrote: > Does anyone work with sensors on Android have any go around to solve > this problem? > > On Sep 25, 5:15 pm, LVMH <lvmh...@gmail.com> wrote: > > > > > Hello, > > > I am trying to develop an indoor inertial navigation system on the HTC > > hero with the built-in accelerometer and digital compass. > > > As far as I know about hardware, the accelerometer chip is the Bosch > > Sensortec's 3-axis BMA150 and the digital compass is Asahi Kasei's > > AK8973 (similar to iPhone). I am not sure about the accuracy of each > > sensor but the digital compass seems to function fairly well in the > > iPhone. > > > What I am doing is getting accelerometer samples and magnetic field > > samples at the SENSOR_DELAY_FASTEST (seems to me around 10 - 20 ms per > > sample) > > > Then I creates a threshold of ±1 m/s^2 for every output of > > accelerometer to filter out which sample is gravity (9.807f). The same > > is applied for output from the digital compass (with threshold of ± 5 > > microtesla). I intended to use this filter to provide the correct > > gravity and geomagnetic field for the SensorManager.getRotationMatrix > > to work correctly (I am not sure if this method would actual provide > > better result). > > > From the rotation matrix created above, I simply use getOrientation to > > get the heading (north) and convert the output from the accelerometer > > from the device coordination system to the Earth's coordination system > > by multiplying to the rotation matrix. > > > ****** My question ****** > > The result I am getting is completely not usable. It seems that the > > heading is very inaccurate thus making the rotation matrix > > inaccurate. > > Even when I applied kalman filter, the result is still far from being > > usable. > > I wonder if anyone has approached this problem before and if there is > > some better way to do it. > > > Thanks, > > lvmh- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
