Prev: Practical differences between BCH and Reed-Solomon codes?
Next: Looking for an FEC coding scheme with variable coding bits
From: DDfyp on 12 Nov 2009 01:54
>>>>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 as
>gravity,
>>>but potentially swamping platform acceleration.
>>>
>>
>>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)
>>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 on
two
>things: 1) how closely is the sensor mounted to the accelerometer and
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 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 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 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 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
First  |  Prev  | 
Pages: 1 2
Prev: Practical differences between BCH and Reed-Solomon codes?
Next: Looking for an FEC coding scheme with variable coding bits