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.
> 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.
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.
On Oct 1, 12:07 pm, DD <daviddiaofri...@gmail.com> wrote:
> 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.
I would say, g is already decomposed by BMA 150 (as it got 3 distinct
sensors, aligned with chip
axes), and AK8973 has no part in it.
