kalman filter to improve the gps data received from an iPhone
in [DSP]
|
From: claudegps on 28 May 2010 03:30 On 28 Mag, 02:19, Manny <mlou...(a)hotmail.com> wrote: > On May 26, 6:19 pm, Tim Wescott <t...(a)seemywebsite.now> wrote: > > > > > On 05/25/2010 07:28 AM, andreivig 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? > > > I just realized that I left out my intuitive explanation of why a > > coupled IMU/GPS solution works, and why a Kalman filter helps. > > > A GPS receiver generally does a really good job of delivering a position > > solution that is correct _on average_. In other words, if you have a > > reasonably clear sky, and you set the receiver down in one spot where it > > won't move, you can average a bunch of position estimates from the > > receiver and get down to millimeter accuracy. This is far more reliable > > if you have clear sky in all directions, but you can still do pretty > > well if there aren't too many confounding reflections. (obviously it > > won't work at all if you're in deep forest or underground or some other > > situation where you can't receive satellite data). > > > But a GPS receiver is fairly poor at telling you where you are from > > moment to moment. The position estimate jumps around, and for most GPS > > receivers it does so more when it is being moved. > > > A six-axis IMU, i.e. three accelerometers and three gyros, does a really > > good job of telling you what's happening _this instant_ -- it measures > > acceleration and rotation, after all, which are second and first > > derivatives, respectively, of physical and angular position. > > Theoretically, if you start with a perfect IMU and a perfect model of > > the earth's gravity and motion, you can navigate all over the world, > > endlessly, with just IMU data. > > > In practice, the IMU has its own noise and bias and drifts, so it > > doesn't work so well. But for any given IMU you can always _start_ at a > > known position, velocity and orientation, and for some amount of time > > that varies depending on how good the IMU is, you can keep track of your > > position, velocity, and orientation. The problem is that the worse (and > > less expensive) that the IMU is, the sooner you completely lose track. > > > So the GPS is really good with slow position measurements, and the IMU > > is really good with fast position measurements. > > > What a Kalman filter lets you do is to take the "GPS is good at slow" > > and "IMU is good at fast" and put them together. It merges the data, > > smooths out the bumps, and gives you an overall system that's better > > (perhaps far better) than the GPS for instantaneous positions, and > > that's always far better than the IMU for long-term positions. So > > there's no magic involved -- the Kalman filter is just letting > > already-existing capabilities work together. > > > Conversely, in the case of the iPhone you only have a three-axis IMU, > > and insufficient compass resources to tell which way vertical lies. > > Without knowing the orientation of an accelerometer you have no way of > > knowing your own acceleration in any absolute sense. As an example, if > > the accelerometer reads 9.8m/s^2 in a particular direction, you don't > > know if that means that you're standing still or if you're accelerating > > downward at 19.6m/s^2, or some combination of forward and downward > > acceleration. Similarly, if the accelerometer says that you're > > accelerating at 10.45m/s^2, you don't know if you're staying level and > > accelerating at 7.35m/s^2 horizontally, or if you're accelerating upward > > at 2.45m/s^2, or what. > > > So that three-axis IMU is _completely useless_ by itself for inertial > > navigation. Even if it were perfect -- which it is not -- it is still > > delivering totally insufficient information for navigation. Given that, > > there is no filter in the world that will rescue you with just the > > information from a GPS. Add a good three-axis gyro and you've > > essentially got a 6-axis IMU. Add a heading and vertical reference, and > > you're all set -- but all reasonable vertical references that work when > > you're moving need accelerometers. > > > Much as I hate to say it, there is no software solution to this hardware > > problem. You just can't get there from here, at least without adding > > more hardware to the solution than is to be found inside of an iPhone. > > What if you had say 2 friends with you with iphones too in the same > moving car (total of three iphones). There are technicalities to do > with achievable level of synchronization say over wifi or 3g between > the three, but let's talk theoretically here: would this increased > dimensionality of sensor data help at all? And if so, what is the > required level of synchronization? Mmmm... both iPhone going around togheter? They would suffer by the same errors in satellite reception. Hypotethically: (1)you could try to check if one of the two have a slightly better reception (i.e. if for example they are in different sides of the car, they may see different satellites) and use the best position. (2) a bit more complex: merge the measurements from both iPhones (always in the hypothesys the receive different signals... that is not much likely to hapòpen, but sometimes maybe...) and use both to compute the fix. Not an easy scenario, as as far as I know, you don't have access to raw measurements. (3) let's do something different: one iphone static and the other one going around. There you can try to do Differential GPS (google for it.. :) ) Any other idea? :)
From: Richard Owlett on 28 May 2010 07:12 Manny wrote: > On May 26, 6:19 pm, Tim Wescott <t...(a)seemywebsite.now> wrote: >> On 05/25/2010 07:28 AM, andreivig 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? >> I just realized that I left out my intuitive explanation of why a >> coupled IMU/GPS solution works, and why a Kalman filter helps. >> >> A GPS receiver generally does a really good job of delivering a position >> solution that is correct _on average_. In other words, if you have a >> reasonably clear sky, and you set the receiver down in one spot where it >> won't move, you can average a bunch of position estimates from the >> receiver and get down to millimeter accuracy. This is far more reliable >> if you have clear sky in all directions, but you can still do pretty >> well if there aren't too many confounding reflections. (obviously it >> won't work at all if you're in deep forest or underground or some other >> situation where you can't receive satellite data). >> >> But a GPS receiver is fairly poor at telling you where you are from >> moment to moment. The position estimate jumps around, and for most GPS >> receivers it does so more when it is being moved. >> >> A six-axis IMU, i.e. three accelerometers and three gyros, does a really >> good job of telling you what's happening _this instant_ -- it measures >> acceleration and rotation, after all, which are second and first >> derivatives, respectively, of physical and angular position. >> Theoretically, if you start with a perfect IMU and a perfect model of >> the earth's gravity and motion, you can navigate all over the world, >> endlessly, with just IMU data. >> >> In practice, the IMU has its own noise and bias and drifts, so it >> doesn't work so well. But for any given IMU you can always _start_ at a >> known position, velocity and orientation, and for some amount of time >> that varies depending on how good the IMU is, you can keep track of your >> position, velocity, and orientation. The problem is that the worse (and >> less expensive) that the IMU is, the sooner you completely lose track. >> >> So the GPS is really good with slow position measurements, and the IMU >> is really good with fast position measurements. >> >> What a Kalman filter lets you do is to take the "GPS is good at slow" >> and "IMU is good at fast" and put them together. It merges the data, >> smooths out the bumps, and gives you an overall system that's better >> (perhaps far better) than the GPS for instantaneous positions, and >> that's always far better than the IMU for long-term positions. So >> there's no magic involved -- the Kalman filter is just letting >> already-existing capabilities work together. >> >> Conversely, in the case of the iPhone you only have a three-axis IMU, >> and insufficient compass resources to tell which way vertical lies. >> Without knowing the orientation of an accelerometer you have no way of >> knowing your own acceleration in any absolute sense. As an example, if >> the accelerometer reads 9.8m/s^2 in a particular direction, you don't >> know if that means that you're standing still or if you're accelerating >> downward at 19.6m/s^2, or some combination of forward and downward >> acceleration. Similarly, if the accelerometer says that you're >> accelerating at 10.45m/s^2, you don't know if you're staying level and >> accelerating at 7.35m/s^2 horizontally, or if you're accelerating upward >> at 2.45m/s^2, or what. >> >> So that three-axis IMU is _completely useless_ by itself for inertial >> navigation. Even if it were perfect -- which it is not -- it is still >> delivering totally insufficient information for navigation. Given that, >> there is no filter in the world that will rescue you with just the >> information from a GPS. Add a good three-axis gyro and you've >> essentially got a 6-axis IMU. Add a heading and vertical reference, and >> you're all set -- but all reasonable vertical references that work when >> you're moving need accelerometers. >> >> Much as I hate to say it, there is no software solution to this hardware >> problem. You just can't get there from here, at least without adding >> more hardware to the solution than is to be found inside of an iPhone. > > What if you had say 2 friends with you with iphones too in the same > moving car (total of three iphones). There are technicalities to do > with achievable level of synchronization say over wifi or 3g between > the three, but let's talk theoretically here: would this increased > dimensionality of sensor data help at all? And if so, what is the > required level of synchronization? > > -Momo Improvement unlikely. See http://gpsinformation.net/main/poordgps.htm http://www.google.com/search?q=poor+man%27s+dgps gives hits on several discussions of the issue.
From: ajjc on 28 May 2010 12:24 On May 26, 1:39 am, "andreivig" <vig.andrei(a)n_o_s_p_a_m.gmail.com> wrote: > >Maybe that you can just try to filter out the "bad" fixes by looking > >at the solution status. > >If you can have access to GPS data like N. of satellites used in the > >solution, their CN0 and DOPs you can determine which fixes have a good > >probability to be accurate and which ones have a really poor accuracy > >(few satellites, low CN0s, high DOPs) > > The data that I receive from the GPS is : > - coordinates : x, y; > - altitude > - horizontal accuracy > - vertical accuracy > - speed > - course > - heading(optional) > > I don't have access to number of satellites and so on. > > Which algorithm is best suited to improve coordinates data based on the > other inputs I have? I take it that you are referring to the iPhone API document http://bit.ly/axEDxc From what I can tell, Apple doesn't tell you how they get these parameters. -They could come from the sensors in the phone itself (GPS, etc.) -They could come from External information sources(Cell Phone Towers, WiFi connections, other phones in your local area). So, I guess that the point is...can I improve on the accuracy of the endpoint geolocation that Apple sends through this API, without knowing how they do it, or what information sources they are using...and that they may change the alogrithm or information sources in the next release! Using some kind of machine learning or adaptive filtering seems reasonable, but I guess that you'd have to analyze a bunch of actual data streams to know where to start, or you'd have to postulate a meta model under which some known techniques would work. alan or from what information sources they are using
From: illywhacker on 4 Jun 2010 06:07 On May 25, 4:28 pm, "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. > TheGPSdata 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? This rather depends on what kind of errors you want to correct, and on what kind of use you foresee (car, handheld, etc.). If the problem is that every now and again there is an isolated GPS reading that makes you jump 500m away and back in a time incompatible with your speed, then you can certainly try to improve these using something like a Kalman filter. However even if the readings look nice and smooth, and coherent with your true positions and motion, they still might be in error, but there will not be anyway to correct this without extra information. illywhacker;
From: claudegps on 8 Jun 2010 04:19
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 :) |