FPGA Central

Hi, I'm working on location sensing by using 1 accelerometer and
magnetometer only (so called "dead reckoning") but now I realize that whe
I move my device, it is always possible to tilt the device a little bit
such that the gravity is decomposed onto 3 axes, which causes that the rea
motion acceleration and the gravity cannot be told apart. Thus, if
perform integration(dead reckoning) on the acceleration directly given b
the accelerometer, the result is largely inaccurate.

So I have to offset G first to get the real motion acceleration. Is thi
possible to be done by only using the accelerometer and one mor
magnetometer (since my device has it built in too)?

I read an old thread on this web
http://www.dsprelated.com/showmessage/39145/1.php

It talks about using Kalman filter to filter out G and sort o
things...but I couldn't really see any straight answers related to my cas
here.
So do Kalman filter help? Thank you very much!

PS. just for your info. Initially I wanted to figure out the orientatio
(yaw, pitch and roll) first , so that based on the 3 angles I coul
decompose G, and therefore offset G on each of the 3 axes. And th
orientation can actually be calculated by rotation matrix on acceleratio
and magnetic field. But the orientation obtained in this way cannot b
really used for decomposing G during the acceleration motion, because th
orientation is calculated from the acceleration and thus affected by th
acceleration change, meaning during the acceleration motion the orientatio
calculated is not the real orientation of the device.

>Hi, I'm working on location sensing by using 1 accelerometer and 1
>magnetometer only (so called "dead reckoning") but now I realize tha
when
>I move my device, it is always possible to tilt the device a little bit,
>such that the gravity is decomposed onto 3 axes, which causes that the
>real
>motion acceleration and the gravity cannot be told apart. Thus, if I
>perform integration(dead reckoning) on the acceleration directly give
by
>the accelerometer, the result is largely inaccurate.

It seems doubtful. Why would you only have 1 accelerometer? (If I had t
guess, you're on some sort of wheeled ground vehicle that's only "supposed
to move in 1 local direction? If so, consider odometry instead, or i
addition.) If you've got any significant angular velocity and you
accelerometers are not at the center of mass, you will have othe
components you need to remove, too, not quite as significant as gravity
but potentially swamping platform acceleration.

But even with a 3-axis magnetometer, as you mention later, you only get
single vector (magnitude and direction) in 3-space. Magnetometers ar
fraught with all sorts of issues, regarding disturbances, both platform an
environmental. Ignoring those (a potentially serious source of error), i
your magnetometer outputs something of the same magnitude (to oversimplif
again) as your local magnetic model, but rotated, you're generally stil
short of knowing how it was rotated. Now if you can stop your platfor
completely, and your accelerometer is not mounted in an unfortunat
orientation, then *maybe* you can get something. But, even if that works
that doesn't really help with "separating gravity": that's just using wha
is known to be gravity (barring all sorts of accelerometer nonidealities
to compute static orientation. I suspect it's a waste of your time t
try.

You'd really be MUCH better off getting 3 accelerometers and 3 gyros, o
re-thinking the strategy altogether. You're really just making thing
difficult on yourself, and if your precision requirements are such that
few cheap sensors won't do, then I think you're headed for seriou
problems.


>So I have to offset G first to get the real motion acceleration. Is this
>possible to be done by only using the accelerometer and one more
>magnetometer (since my device has it built in too)?
>
>I read an old thread on this web,
>http://www.dsprelated.com/showmessage/39145/1.php
>
>It talks about using Kalman filter to filter out G and sort of
>things...but I couldn't really see any straight answers related to m
case
>here.
>So do Kalman filter help? Thank you very much!

If your platform model is accurate enough (is it? do you even have one?)
it should help, relative to nothing at all (after all, it should be bette
than open-loop dead-reckoning based on actuator commands, and a good enoug
model can make it better than just looking at the sensors at each tim
instant). But it may or may not be ENOUGH to do what you want.

>>Hi, I'm working on location sensing by using 1 accelerometer and 1
>>magnetometer only (so called "dead reckoning") but now I realize that
>when
>>I move my device, it is always possible to tilt the device a littl
bit,
>>such that the gravity is decomposed onto 3 axes, which causes that the
>>real
>>motion acceleration and the gravity cannot be told apart. Thus, if I
>>perform integration(dead reckoning) on the acceleration directly given
>by
>>the accelerometer, the result is largely inaccurate.
>
>It seems doubtful. Why would you only have 1 accelerometer? (If I ha
to
>guess, you're on some sort of wheeled ground vehicle that's onl
"supposed"
>to move in 1 local direction? If so, consider odometry instead, or in
>addition.) If you've got any significant angular velocity and your
>accelerometers are not at the center of mass, you will have other
>components you need to remove, too, not quite as significant as gravity,
>but potentially swamping platform acceleration.
>

Hey, Thank you very much for your answer! Actually, I'm not dealing with
wheeled vehicle...I'm working on a cellphone(Android phone, to be specific
that has 1 accelerometer and 1 magnetometer built in (also 1 temerapur
sensor which I dont think it helps in any way here). I just read abou
"odometry" on wiki, and figured it seemed only applicable to a wheele
device, so it isnt really suitable for my case here, am I correct?

>But even with a 3-axis magnetometer, as you mention later, you only ge
a
>single vector (magnitude and direction) in 3-space. Magnetometers are
>fraught with all sorts of issues, regarding disturbances, both platfor
and
>environmental.

Yeah...I'm already aware of this...the magnetometer is used in th
cellphone together with the accelerometer to determine/calculate th
orientation.

Ignoring those (a potentially serious source of error), if
>your magnetometer outputs something of the same magnitude (t
oversimplify
>again) as your local magnetic model, but rotated, you're generally still
>short of knowing how it was rotated. Now if you can stop your platform
>completely, and your accelerometer is not mounted in an unfortunate
>orientation, then *maybe* you can get something. But, even if tha
works,
>that doesn't really help with "separating gravity": that's just usin
what
>is known to be gravity (barring all sorts of acceleromete
nonidealities)
>to compute static orientation. I suspect it's a waste of your time to
>try.
>
>You'd really be MUCH better off getting 3 accelerometers and 3 gyros, or
>re-thinking the strategy altogether. You're really just making things
>difficult on yourself, and if your precision requirements are such tha
a
>few cheap sensors won't do, then I think you're headed for serious
>problems.

Thanks for your advice. Then if I had 3 accelerometers and 3 gyros, ho
would I solve my problem, getting the orientation or offsetting G? Coul
you roughly let me know the approach? I'm quite new to this field. Actuall
I've been thinking of the similar problem: how the aircraft determines it
orientation...

>
>
>>So I have to offset G first to get the real motion acceleration. I
this
>>possible to be done by only using the accelerometer and one more
>>magnetometer (since my device has it built in too)?
>>
>>I read an old thread on this web,
>>http://www.dsprelated.com/showmessage/39145/1.php
>>
>>It talks about using Kalman filter to filter out G and sort of
>>things...but I couldn't really see any straight answers related to my
>case
>>here.
>>So do Kalman filter help? Thank you very much!
>
>If your platform model is accurate enough (is it? do you even hav
one?),
>it should help, relative to nothing at all (after all, it should b
better
>than open-loop dead-reckoning based on actuator commands, and a goo
enough
>model can make it better than just looking at the sensors at each time
>instant). But it may or may not be ENOUGH to do what you want.

Well...what do you mean by "platform model"? Is it possible you sugges
any? and I will do the further reading on them. I only heard Kalman filter
got something to do with the model...yeah, would appreciate your
suggestions!
>
>
>

>>>Hi, I'm working on location sensing by using 1 accelerometer and 1
>>>magnetometer only (so called "dead reckoning") but now I realize that
>>when
>>>I move my device, it is always possible to tilt the device a little
>bit,
>>>such that the gravity is decomposed onto 3 axes, which causes that the
>>>real
>>>motion acceleration and the gravity cannot be told apart. Thus, if I
>>>perform integration(dead reckoning) on the acceleration directly given
>>by
>>>the accelerometer, the result is largely inaccurate.
>>
>>It seems doubtful. Why would you only have 1 accelerometer? (If I had
>to
>>guess, you're on some sort of wheeled ground vehicle that's only
>"supposed"
>>to move in 1 local direction? If so, consider odometry instead, or in
>>addition.) If you've got any significant angular velocity and your
>>accelerometers are not at the center of mass, you will have other
>>components you need to remove, too, not quite as significant a
gravity,
>>but potentially swamping platform acceleration.
>>
>
>Hey, Thank you very much for your answer! Actually, I'm not dealing wit
a
>wheeled vehicle...I'm working on a cellphone(Android phone, to be
>specific)
>that has 1 accelerometer and 1 magnetometer built in (also 1 temerapure
>sensor which I dont think it helps in any way here). I just read about
>"odometry" on wiki, and figured it seemed only applicable to a wheeled
>device, so it isnt really suitable for my case here, am I correct?

You're right, which is why I said "if so". I couldn't imagine anothe
situation where anyone could *think* (rightly or wrongly) they could ge
away with just one. I have to think the cellphone manufacturer ha
something other than dead-reckoning in mind (maybe games, similar to
Wii-mote). Whether or not the temperature sensor is useful depends on tw
things: 1) how closely is the sensor mounted to the accelerometer and 2
do you have a calibration oven (unlikely, but maybe the manufacture
provides tables in the ROM, since it's device-dependent?). Even then, it'
be a pain to use it without the other axes. I've not looked into th
hardware on phones (other than mine, which does not have any such devices)
so I'm speaking in general.


>>But even with a 3-axis magnetometer, as you mention later, you only get
>a
>>single vector (magnitude and direction) in 3-space. Magnetometers are
>>fraught with all sorts of issues, regarding disturbances, both platform
>and
>>environmental.
>
>Yeah...I'm already aware of this...the magnetometer is used in the
>cellphone together with the accelerometer to determine/calculate the
>orientation.
>
>Ignoring those (a potentially serious source of error), if
>>your magnetometer outputs something of the same magnitude (to
>oversimplify
>>again) as your local magnetic model, but rotated, you're generall
still
>>short of knowing how it was rotated. Now if you can stop your platform
>>completely, and your accelerometer is not mounted in an unfortunate
>>orientation, then *maybe* you can get something. But, even if that
>works,
>>that doesn't really help with "separating gravity": that's just using
>what
>>is known to be gravity (barring all sorts of accelerometer
>nonidealities)
>>to compute static orientation. I suspect it's a waste of your time to
>>try.
>>
>>You'd really be MUCH better off getting 3 accelerometers and 3 gyros
or
>>re-thinking the strategy altogether. You're really just making things
>>difficult on yourself, and if your precision requirements are such that
>a
>>few cheap sensors won't do, then I think you're headed for serious
>>problems.
>
>Thanks for your advice. Then if I had 3 accelerometers and 3 gyros, how
>would I solve my problem, getting the orientation or offsetting G? Could
>you roughly let me know the approach? I'm quite new to this field
>Actually
>I've been thinking of the similar problem: how the aircraft determine
its
>orientation...

Well, aircraft undoubtedly have units of much higher precision than wha
can fit in a phone (certainly budget-wise). I couldn't really provide muc
detail here on aircraft, in particular; there's a lot that goes into that.
Your units probably cannot sense earth's rotation; my understanding is that
the ones in planes are sensitive enough, though I've never worked with
aircraft (only done some reading). If you're curious about higher-quality
specs, I saved this link:

http://www.dsprelated.com/showmessage/75736/3.php

In any case, what I would do with 6 axes is figure out orientation first.
Accelerometers can be used to determine gravity's direction at low
frequency, and gyros at higher frequency (search "complementary filter").
This can be done with varying degrees of sophistication. Your heading will
drift; the magnetometer can correct that (another complementary filter),
but only long-term. Your linear velocity and position will drift, but your
phone probably has GPS (?), and, if so, that can keep position/velocity
errors in check. If it doesn't, you can at least keep velocity errors
bounded by asking the phone user to hold the phone still every once in
awhile and hit a key, then calculate the accelerometer bias retroactively
needed in order to force the final velocity to zero. Of course, he won't
be perfectly still when he hits the button, even if he thinks he is (if
you're familiar with trigger jerk... ).

As mentioned in the other thread, you really won't be able to easily tell
the difference between gravity and body acceleration. There are two things
you can do there: A) assume body acceleration is small (the user is not
waving the phone around really fast, jumping off bridges, etc.) B) have a
motion model. Neither of these is very good, but they're better than
nothing. You, however, have an additional problem: the center of your
angular rotations is not fixed with respect to the phone: the user can
bend their elbows, shoulders, waist, etc., so you're SOL on removing
certain pseudoforces from the accelerometers, as far as I can tell.



>>
>>
>>>So I have to offset G first to get the real motion acceleration. Is
>this
>>>possible to be done by only using the accelerometer and one more
>>>magnetometer (since my device has it built in too)?
>>>
>>>I read an old thread on this web,
>>>http://www.dsprelated.com/showmessage/39145/1.php
>>>
>>>It talks about using Kalman filter to filter out G and sort of
>>>things...but I couldn't really see any straight answers related to my
>>case
>>>here.
>>>So do Kalman filter help? Thank you very much!
>>
>>If your platform model is accurate enough (is it? do you even have
>one?),
>>it should help, relative to nothing at all (after all, it should be
>better
>>than open-loop dead-reckoning based on actuator commands, and a good
>enough
>>model can make it better than just looking at the sensors at each time
>>instant). But it may or may not be ENOUGH to do what you want.
>
>Well...what do you mean by "platform model"? Is it possible you suggest
>any? and I will do the further reading on them. I only heard Kalman
filter
>got something to do with the model...yeah, would appreciate your
>suggestions!
>>
>>
>>
>

Doesn't sound good. How well can you predict what a person (one of those
reliable end-users, no less) is going to do? If they're just keeping it in
their pocket and walking, and you do have 6 axes (which it sounds like you
don't), you have some hope. There are actually state estimators out there
in the literature where they have developed models for walking. But my
guess is you want it to work while it's in their hand, too, which I have to
think will be more difficult.

Oh, and even if you find the right equations for what you're looking for,
expect your position estimate to get really far off, really fast. Possibly
on the order of seconds. For comparison, I have a very consistently-moving
rigid body I work with that moves very slowly/smoothly, but I would
hesitate to try to use my temperature-calibrated MEMS IMU to estimate
position, at least without external aiding.

If you're interested in this in general, rather than just for this
application (which honestly looks hopeless), there's a lot of reading to
do. For the inertial sensors you're likely to encounter, Titterton and
Weston is it. For Kalman Filtering, you're probably going to have to read
a few books (or a really good one several times) before it clicks. I know
several people here recommend Dan Simon's book for the latter task, and
it's a good book (just finished it...the derivations are a bit verbose for
my taste, but that's the only remotely negative thing I have to say, and
some would not even consider that negative), but the one that made me
actually understand first was an older book by Gelb. Either way, I
couldn't stop with just one or two books, so I'm not sure it matters.
There are many. You can spend a real lot of time on this; are you sure you
want to?

> Hey, Thank you very much for your answer! Actually, I'm not dealing with a
> wheeled vehicle...I'm working on a cellphone(Android phone, to be specific)
> ......


Motorola lays off 1000's of engineers and now comes to Usenet for
help?


Mark

>
>> Hey, Thank you very much for your answer! Actually, I'm not dealing
with a
>> wheeled vehicle...I'm working on a cellphone(Android phone, to be
specific)
>> ......
>
>
>Motorola lays off 1000's of engineers and now comes to Usenet for
>help?
>
>
>Mark

Interesting, that hadn't occurred to me. I thought this was just a
hobbyist trying to extend an existing phone.

>>>>Hi, I'm working on location sensing by using 1 accelerometer and 1
>>>>magnetometer only (so called "dead reckoning") but now I realize that
>>>when
>>>>I move my device, it is always possible to tilt the device a little
>>bit,
>>>>such that the gravity is decomposed onto 3 axes, which causes tha
the
>>>>real
>>>>motion acceleration and the gravity cannot be told apart. Thus, if I
>>>>perform integration(dead reckoning) on the acceleration directl
given
>>>by
>>>>the accelerometer, the result is largely inaccurate.
>>>
>>>It seems doubtful. Why would you only have 1 accelerometer? (If
had
>>to
>>>guess, you're on some sort of wheeled ground vehicle that's only
>>"supposed"
>>>to move in 1 local direction? If so, consider odometry instead, or in
>>>addition.) If you've got any significant angular velocity and your
>>>accelerometers are not at the center of mass, you will have other
>>>components you need to remove, too, not quite as significant as
>gravity,
>>>but potentially swamping platform acceleration.
>>>
>>
>>Hey, Thank you very much for your answer! Actually, I'm not dealin
with
>a
>>wheeled vehicle...I'm working on a cellphone(Android phone, to be
>>specific)
>>that has 1 accelerometer and 1 magnetometer built in (also 1 temerapure
>>sensor which I dont think it helps in any way here). I just read about
>>"odometry" on wiki, and figured it seemed only applicable to a wheeled
>>device, so it isnt really suitable for my case here, am I correct?
>
>You're right, which is why I said "if so". I couldn't imagine another
>situation where anyone could *think* (rightly or wrongly) they could get
>away with just one. I have to think the cellphone manufacturer had
>something other than dead-reckoning in mind (maybe games, similar to a
>Wii-mote). Whether or not the temperature sensor is useful depends o
two
>things: 1) how closely is the sensor mounted to the accelerometer an
2)
>do you have a calibration oven (unlikely, but maybe the manufacturer
>provides tables in the ROM, since it's device-dependent?). Even then
it'd
>be a pain to use it without the other axes. I've not looked into the
>hardware on phones (other than mine, which does not have any suc
devices),
>so I'm speaking in general.
>
>
>>>But even with a 3-axis magnetometer, as you mention later, you onl
get
>>a
>>>single vector (magnitude and direction) in 3-space. Magnetometers are
>>>fraught with all sorts of issues, regarding disturbances, bot
platform
>>and
>>>environmental.
>>
>>Yeah...I'm already aware of this...the magnetometer is used in the
>>cellphone together with the accelerometer to determine/calculate the
>>orientation.
>>
>>Ignoring those (a potentially serious source of error), if
>>>your magnetometer outputs something of the same magnitude (to
>>oversimplify
>>>again) as your local magnetic model, but rotated, you're generally
>still
>>>short of knowing how it was rotated. Now if you can stop you
platform
>>>completely, and your accelerometer is not mounted in an unfortunate
>>>orientation, then *maybe* you can get something. But, even if that
>>works,
>>>that doesn't really help with "separating gravity": that's just using
>>what
>>>is known to be gravity (barring all sorts of accelerometer
>>nonidealities)
>>>to compute static orientation. I suspect it's a waste of your time to
>>>try.
>>>
>>>You'd really be MUCH better off getting 3 accelerometers and 3 gyros,
>or
>>>re-thinking the strategy altogether. You're really just making things
>>>difficult on yourself, and if your precision requirements are suc
that
>>a
>>>few cheap sensors won't do, then I think you're headed for serious
>>>problems.
>>
>>Thanks for your advice. Then if I had 3 accelerometers and 3 gyros, how
>>would I solve my problem, getting the orientation or offsetting G
Could
>>you roughly let me know the approach? I'm quite new to this field.
>>Actually
>>I've been thinking of the similar problem: how the aircraft determines
>its
>>orientation...
>
>Well, aircraft undoubtedly have units of much higher precision than what
>can fit in a phone (certainly budget-wise). I couldn't really provide
much
>detail here on aircraft, in particular; there's a lot that goes into
that.
>Your units probably cannot sense earth's rotation; my understanding is
that
>the ones in planes are sensitive enough, though I've never worked with
>aircraft (only done some reading). If you're curious about
higher-quality
>specs, I saved this link:
>
>http://www.dsprelated.com/showmessage/75736/3.php
>
>In any case, what I would do with 6 axes is figure out orientation first.

>Accelerometers can be used to determine gravity's direction at low
>frequency, and gyros at higher frequency (search "complementary filter").

>This can be done with varying degrees of sophistication. Your heading
will
>drift; the magnetometer can correct that (another complementary filter),
>but only long-term. Your linear velocity and position will drift, but
your
>phone probably has GPS (?), and, if so, that can keep position/velocity
>errors in check. If it doesn't, you can at least keep velocity errors
>bounded by asking the phone user to hold the phone still every once in
>awhile and hit a key, then calculate the accelerometer bias
retroactively
>needed in order to force the final velocity to zero. Of course, he
won't
>be perfectly still when he hits the button, even if he thinks he is (if
>you're familiar with trigger jerk... ).
>
>As mentioned in the other thread, you really won't be able to easily
tell
>the difference between gravity and body acceleration. There are two
things
>you can do there: A) assume body acceleration is small (the user is not
>waving the phone around really fast, jumping off bridges, etc.) B) have
a
>motion model. Neither of these is very good, but they're better than
>nothing. You, however, have an additional problem: the center of your
>angular rotations is not fixed with respect to the phone: the user can
>bend their elbows, shoulders, waist, etc., so you're SOL on removing
>certain pseudoforces from the accelerometers, as far as I can tell.
>
>
>
>>>
>>>
>>>>So I have to offset G first to get the real motion acceleration. Is
>>this
>>>>possible to be done by only using the accelerometer and one more
>>>>magnetometer (since my device has it built in too)?
>>>>
>>>>I read an old thread on this web,
>>>>http://www.dsprelated.com/showmessage/39145/1.php
>>>>
>>>>It talks about using Kalman filter to filter out G and sort of
>>>>things...but I couldn't really see any straight answers related to my
>>>case
>>>>here.
>>>>So do Kalman filter help? Thank you very much!
>>>
>>>If your platform model is accurate enough (is it? do you even have
>>one?),
>>>it should help, relative to nothing at all (after all, it should be
>>better
>>>than open-loop dead-reckoning based on actuator commands, and a good
>>enough
>>>model can make it better than just looking at the sensors at each time
>>>instant). But it may or may not be ENOUGH to do what you want.
>>
>>Well...what do you mean by "platform model"? Is it possible you suggest
>>any? and I will do the further reading on them. I only heard Kalman
>filter
>>got something to do with the model...yeah, would appreciate your
>>suggestions!
>>>
>>>
>>>
>>
>
>Doesn't sound good. How well can you predict what a person (one of
those
>reliable end-users, no less) is going to do? If they're just keeping it
in
>their pocket and walking, and you do have 6 axes (which it sounds like
you
>don't), you have some hope. There are actually state estimators out
there
>in the literature where they have developed models for walking. But my
>guess is you want it to work while it's in their hand, too, which I have
to
>think will be more difficult.
>
>Oh, and even if you find the right equations for what you're looking
for,
>expect your position estimate to get really far off, really fast.
Possibly
>on the order of seconds. For comparison, I have a very
consistently-moving
>rigid body I work with that moves very slowly/smoothly, but I would
>hesitate to try to use my temperature-calibrated MEMS IMU to estimate
>position, at least without external aiding.
>
>If you're interested in this in general, rather than just for this
>application (which honestly looks hopeless), there's a lot of reading to
>do. For the inertial sensors you're likely to encounter, Titterton and
>Weston is it. For Kalman Filtering, you're probably going to have to
read
>a few books (or a really good one several times) before it clicks. I
know
>several people here recommend Dan Simon's book for the latter task, and
>it's a good book (just finished it...the derivations are a bit verbose
for
>my taste, but that's the only remotely negative thing I have to say, and
>some would not even consider that negative), but the one that made me
>actually understand first was an older book by Gelb. Either way, I
>couldn't stop with just one or two books, so I'm not sure it matters.
>There are many. You can spend a real lot of time on this; are you sure
you
>want to?
>
>


Thanks alot, Michael. I think that would be too much reading for
me...haha. Actually this is my final year project of my Bachelor degree,
and I have to finish it by next May when I graduate. So don't really think
I will have time for those books. Right now I'm only given an HTC Magic
phone with those sensors(accelerometer,magnetometer,temperature sensor, and
orientation sensor which unfortunately doesn't detect orientation
independently but gets orientation by calculating the accelerometer and
magnetometer data), and try to manipulate them to perform dead reckoning
and location tracking. Em...I've also realized the difficulty in here, but
I can't just get another gyro and mount it on the phone anyway...>_<''
Yeah, Thank you very much for allyour answers