How to compensate gravity if I only have 1 accelerometer and 1 magnetometer(magnetic field sensor)?
in [DSP]
|
Prev: Practical differences between BCH and Reed-Solomon codes?
Next: Looking for an FEC coding scheme with variable coding bits
From: DDfyp on 9 Nov 2009 08:56 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. 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! PS. just for your info. Initially I wanted to figure out the orientation (yaw, pitch and roll) first , so that based on the 3 angles I could decompose G, and therefore offset G on each of the 3 axes. And the orientation can actually be calculated by rotation matrix on acceleration and magnetic field. But the orientation obtained in this way cannot be really used for decomposing G during the acceleration motion, because the orientation is calculated from the acceleration and thus affected by the acceleration change, meaning during the acceleration motion the orientation calculated is not the real orientation of the device.
From: Michael Plante on 9 Nov 2009 10:27 >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. 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. 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. >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.
From: DDfyp on 10 Nov 2009 22:43 >>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? >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... > > >>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! > > >
From: Michael Plante on 11 Nov 2009 11:15 >>>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?
From: Mark on 11 Nov 2009 12:23
> 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 |