kalman filter to improve the gps data received from an iPhone
in [DSP]
|
From: Tim Wescott on 8 Jun 2010 12:53 On 06/08/2010 09:40 AM, claudegps wrote: > On 8 Giu, 15:48, Tim Wescott<t...(a)seemywebsite.now> wrote: >> On 06/08/2010 06:40 AM, Jerry Avins wrote: >> >> >> >>> On 6/8/2010 4:19 AM, claudegps wrote: >>>> On 25 Mag, 16:28, "andreivig"<vig.andrei(a)n_o_s_p_a_m.gmail.com> >>>> wrote: >>>>> Hi, >> >>>>> I am currently working on an navigation application for an iPhone >>>>> device. >>>>> The GPS data that I receive is not very accurate and I want to use a >>>>> kalman >>>>> filter. The problem is that I don't really know how to build the kalman >>>>> equations for x and y coordinates. What kind of model should I use? >> >>>> Now iPhone4 has also the gyro! >>>> 3 Axis accelerometer + 3 axis gyro and you have your IMU :) >> >>> What is the drift rate? >> >> No doubt it's high -- but at least with a gyro you have a chance! >> >> The pernicious thing about this GPS/Kalman application is that there is >> no threshold for how good the IMU must be unless you also specify the >> motion profile. If the motion is rich enough in accelerations (if, for >> instance, someone is holding the iPhone in their hand while walking) >> then the IMU doesn't have to be as good as it would if the assembly is >> bolted down to a car (where the IMU would have to be good enough to >> carry measurements while you're seeing accelerations no more severe than >> bumps in the road, or at least normal corners). > > Interesting. > But shouldn't the car be an easier environment? > In the car you have motion constrains (you can't turn fast, > acceleration are always lees than 1g, ecc) and every movement can be > easily related with GPS data. > That should make calibration of the IMU much easier... isn't it? > > While walking, the user may turn around, move hands, rotate the > device, put it into its pocket ecc... the user can do many many > movement that can not be easily related to the GPS data. Moreover you > can't fix any constrain in the motion model (or better: you really > have lees constrains you can rely on) > > What I'm missing? The Kalman filter for combining IMU and GPS data works by correlating motion sensed by the IMU with motion measured by the GPS. The less motion there is in relation to the IMU's own internal errors the less the Kalman filter can tell the difference between IMU noise and actual motion. So having a rich motion trajectory helps a lot. Because the motion of a car is much smoother than the motion of a person's hand while walking, there is less useful data there. Given that the GPS antenna and the IMU are all in one little package, any motion of the phone is easily related to the GPS data. This assumes that the GPS data is reported with sufficient precision, and fast enough -- you really want GPS data reported with enough precision that the quantization noise is a small part of the overall noise, and if the GPS engine can be made to report faster than the traditional once/second that'd be a really big help. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: claudegps on 9 Jun 2010 12:17 On 8 Giu, 18:53, Tim Wescott <t...(a)seemywebsite.now> wrote: > On 06/08/2010 09:40 AM, claudegps wrote: > > > > > On 8 Giu, 15:48, Tim Wescott<t...(a)seemywebsite.now> wrote: > >> On 06/08/2010 06:40 AM, Jerry Avins wrote: > > >>> On 6/8/2010 4:19 AM, claudegps wrote: > >>>> On 25 Mag, 16:28, "andreivig"<vig.andrei(a)n_o_s_p_a_m.gmail.com> > >>>> wrote: > >>>>> Hi, > > >>>>> I am currently working on an navigation application for an iPhone > >>>>> device. > >>>>> The GPS data that I receive is not very accurate and I want to use a > >>>>> kalman > >>>>> filter. The problem is that I don't really know how to build the kalman > >>>>> equations for x and y coordinates. What kind of model should I use? > > >>>> Now iPhone4 has also the gyro! > >>>> 3 Axis accelerometer + 3 axis gyro and you have your IMU :) > > >>> What is the drift rate? > > >> No doubt it's high -- but at least with a gyro you have a chance! > > >> The pernicious thing about this GPS/Kalman application is that there is > >> no threshold for how good the IMU must be unless you also specify the > >> motion profile. If the motion is rich enough in accelerations (if, for > >> instance, someone is holding the iPhone in their hand while walking) > >> then the IMU doesn't have to be as good as it would if the assembly is > >> bolted down to a car (where the IMU would have to be good enough to > >> carry measurements while you're seeing accelerations no more severe than > >> bumps in the road, or at least normal corners). > > > Interesting. > > But shouldn't the car be an easier environment? > > In the car you have motion constrains (you can't turn fast, > > acceleration are always lees than 1g, ecc) and every movement can be > > easily related with GPS data. > > That should make calibration of the IMU much easier... isn't it? > > > While walking, the user may turn around, move hands, rotate the > > device, put it into its pocket ecc... the user can do many many > > movement that can not be easily related to the GPS data. Moreover you > > can't fix any constrain in the motion model (or better: you really > > have lees constrains you can rely on) > > > What I'm missing? > > The Kalman filter for combining IMU and GPS data works by correlating > motion sensed by the IMU with motion measured by the GPS. The less > motion there is in relation to the IMU's own internal errors the less > the Kalman filter can tell the difference between IMU noise and actual > motion. > > So having a rich motion trajectory helps a lot. So far, I'm with you :) > Because the motion of a car is much smoother than the motion of a > person's hand while walking, there is less useful data there. Less useful, but much more easy to correlate the movements and have a relaible motion model of the system... I think > Given that the GPS antenna and the IMU are all in one little package, > any motion of the phone is easily related to the GPS data. This assumes > that the GPS data is reported with sufficient precision, and fast enough Mmmm... here is what I don't understand. A motion of the phone when walking cannot be easily related to GPS data. Think to a person turnig around: the GPS data gives no info on the simple rotation... unless you move fast enough (there is no absolute direction). Other movements like a single step cannot be deternimed the GPS that has not sufficient precision to detect movement in the order of tents of centimeter. You need meters of movement to have reliable data from the GPS. During pedestrian navigation, the receiver may experience drifts of some meters.. And about the altitude, it's even bad... you have 5-10 meters of uncertainty there (when lucky). So it's difficult for me to think that the rich movements done keeping the phone in your hands (and maybe moving you arm) can be related to GPS data that has a resultion of meters. > -- you really want GPS data reported with enough precision that the > quantization noise is a small part of the overall noise, and if the GPS > engine can be made to report faster than the traditional once/second > that'd be a really big help. The GPS engine can report data with 5 or 10Hz (instead of the traditional 1Hz speed) but the precision... we have meters of uncertainty.
From: Tim Wescott on 9 Jun 2010 12:27 On 06/09/2010 09:17 AM, claudegps wrote: > On 8 Giu, 18:53, Tim Wescott<t...(a)seemywebsite.now> wrote: >> On 06/08/2010 09:40 AM, claudegps wrote: >> >> >> >>> On 8 Giu, 15:48, Tim Wescott<t...(a)seemywebsite.now> wrote: >>>> On 06/08/2010 06:40 AM, Jerry Avins wrote: >> >>>>> On 6/8/2010 4:19 AM, claudegps wrote: >>>>>> On 25 Mag, 16:28, "andreivig"<vig.andrei(a)n_o_s_p_a_m.gmail.com> >>>>>> wrote: >>>>>>> Hi, >> >>>>>>> I am currently working on an navigation application for an iPhone >>>>>>> device. >>>>>>> The GPS data that I receive is not very accurate and I want to use a >>>>>>> kalman >>>>>>> filter. The problem is that I don't really know how to build the kalman >>>>>>> equations for x and y coordinates. What kind of model should I use? >> >>>>>> Now iPhone4 has also the gyro! >>>>>> 3 Axis accelerometer + 3 axis gyro and you have your IMU :) >> >>>>> What is the drift rate? >> >>>> No doubt it's high -- but at least with a gyro you have a chance! >> >>>> The pernicious thing about this GPS/Kalman application is that there is >>>> no threshold for how good the IMU must be unless you also specify the >>>> motion profile. If the motion is rich enough in accelerations (if, for >>>> instance, someone is holding the iPhone in their hand while walking) >>>> then the IMU doesn't have to be as good as it would if the assembly is >>>> bolted down to a car (where the IMU would have to be good enough to >>>> carry measurements while you're seeing accelerations no more severe than >>>> bumps in the road, or at least normal corners). >> >>> Interesting. >>> But shouldn't the car be an easier environment? >>> In the car you have motion constrains (you can't turn fast, >>> acceleration are always lees than 1g, ecc) and every movement can be >>> easily related with GPS data. >>> That should make calibration of the IMU much easier... isn't it? >> >>> While walking, the user may turn around, move hands, rotate the >>> device, put it into its pocket ecc... the user can do many many >>> movement that can not be easily related to the GPS data. Moreover you >>> can't fix any constrain in the motion model (or better: you really >>> have lees constrains you can rely on) >> >>> What I'm missing? >> >> The Kalman filter for combining IMU and GPS data works by correlating >> motion sensed by the IMU with motion measured by the GPS. The less >> motion there is in relation to the IMU's own internal errors the less >> the Kalman filter can tell the difference between IMU noise and actual >> motion. >> >> So having a rich motion trajectory helps a lot. > > So far, I'm with you :) > >> Because the motion of a car is much smoother than the motion of a >> person's hand while walking, there is less useful data there. > > Less useful, but much more easy to correlate the movements and have a > relaible motion model of the system... I think > >> Given that the GPS antenna and the IMU are all in one little package, >> any motion of the phone is easily related to the GPS data. This assumes >> that the GPS data is reported with sufficient precision, and fast enough > > Mmmm... here is what I don't understand. A motion of the phone when > walking cannot be easily related to GPS data. > Think to a person turnig around: the GPS data gives no info on the > simple rotation... unless you move fast enough (there is no absolute > direction). > Other movements like a single step cannot be deternimed the GPS that > has not sufficient precision to detect movement in the order of tents > of centimeter. You need meters of movement to have reliable data from > the GPS. > During pedestrian navigation, the receiver may experience drifts of > some meters.. And about the altitude, it's even bad... you have 5-10 > meters of uncertainty there (when lucky). > So it's difficult for me to think that the rich movements done keeping > the phone in your hands (and maybe moving you arm) can be related to > GPS data that has a resultion of meters. > >> -- you really want GPS data reported with enough precision that the >> quantization noise is a small part of the overall noise, and if the GPS >> engine can be made to report faster than the traditional once/second >> that'd be a really big help. > > The GPS engine can report data with 5 or 10Hz (instead of the > traditional 1Hz speed) but the precision... we have meters of > uncertainty. In my experience the GPS errors are correlated in time over a few tenths of a second. Even if this weren't so, as long as the GPS errors are strictly additive (and sometimes they aren't, but let's pretend) then you can dig the signal out of the noise with enough repetitions. That's why I was saying _resolution_, not _precision_. If the errors (loss of precision) are additive, and the GPS engine reports down to the centimeter (high resolution), then you'll get a combination of error and signal. If the GPS engine truncates too much, then your signal will get chopped off, and you're out of luck. Note, though, that I don't think that the IMU in a iPhone is going to turn out to be good enough, even if you tie it to a six-foot string and whirl it around your head. But I can guarantee you that it won't be good enough in a car -- for that you need an IMU that's about ten times the volume of an iPhone, and about 100 times the price. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: m26k9 on 11 Jun 2010 00:27 Can you really do this with a Kalman filter? In the basic sense the Kalman filter will estimate the signal which is embedded in Gaussian noise. And the signal is modeled as a Gauss-Markov or AR model. Can you model the incoming signal without knowing the transision value for the AR and also the driving noise? I only have experience in using the 'conventional' Kalman filter so interested in knowing how to use Kalman filter in the case of GPS. Because the data you get is not corrupted in a known noise, is it really possible to do this? I mean the task of the 'filter' is to filter out the noise right?
From: Tim Wescott on 11 Jun 2010 00:44
On 06/10/2010 09:27 PM, m26k9 wrote: (Begin restored context -- this is USENET!!) In my experience the GPS errors are correlated in time over a few tenths of a second. Even if this weren't so, as long as the GPS errors are strictly additive (and sometimes they aren't, but let's pretend) then you can dig the signal out of the noise with enough repetitions. That's why I was saying _resolution_, not _precision_. If the errors (loss of precision) are additive, and the GPS engine reports down to the centimeter (high resolution), then you'll get a combination of error and signal. If the GPS engine truncates too much, then your signal will get chopped off, and you're out of luck. Note, though, that I don't think that the IMU in a iPhone is going to turn out to be good enough, even if you tie it to a six-foot string and whirl it around your head. But I can guarantee you that it won't be good enough in a car -- for that you need an IMU that's about ten times the volume of an iPhone, and about 100 times the price. (end restored context) > Can you really do this with a Kalman filter? > In the basic sense the Kalman filter will estimate the signal which is > embedded in Gaussian noise. And the signal is modeled as a Gauss-Markov or > AR model. Can you model the incoming signal without knowing the transision > value for the AR and also the driving noise? > > I only have experience in using the 'conventional' Kalman filter so > interested in knowing how to use Kalman filter in the case of GPS. Because > the data you get is not corrupted in a known noise, is it really possible > to do this? I mean the task of the 'filter' is to filter out the noise > right? I'm not sure where your problem is, frankly. So I'll just give a short summary of how it's done: The way you use a Kalman filter with an IMU and GPS is you model a system with a known rotation rate and acceleration plus rotation and acceleration noise, being measured in position and maybe velocity with noise corrupting the measurements. Then you use the IMU outputs as your "known" rotation rate and acceleration to input to the Kalman, and the GPS as your measured position for feedback. If the object is being accelerated strongly enough compared to the IMU noise then you can figure out which direction it's pointing, and once you know what direction it's pointing you can do a pretty good job with smoothing it's position and velocity estimates. There's a lot to it, but it's doable. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com |