From: Tim Wescott on 26 May 2010 11:18 On 05/26/2010 01:23 AM, claudegps wrote: > On 26 Mag, 09:00, "andreivig"<vig.andrei(a)n_o_s_p_a_m.gmail.com> > wrote: >> On an iPhone I have a GPS and 3 axis accelerometer. I can also get the >> heading. I use the GPS data for my navigation, but as I said this is >> sometimes really bad. Sometimes I receive a position with an error within >> 100 to 400 meters. >> >> Is there any algorithm that I could use to optimize/smoothen this data? > > 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) > Any halfway decent GPS receiver will already do that. And GPS receivers are _terrible_ at figuring out their DOP from multipath effects -- they can easily get confused by reflections and have you teleporting over 100 meters sideways, up, or down. Without an independent measurement of some sort there's just not information there to filter out. (Note that a surveyor's GPS _does_ get independent information -- you set it down, and you push a button that basically tells the GPS that it isn't moving. Then, because it _knows_ it isn't moving, it makes a more-accurate estimate of position). -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: claudegps on 26 May 2010 11:43 [cut] > > 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) > > Any halfway decent GPS receiver will already do that. And GPS receivers > are _terrible_ at figuring out their DOP from multipath effects -- they > can easily get confused by reflections and have you teleporting over 100 > meters sideways, up, or down. It depends: the receiver can easily determine it's status (DOPs, CN0, residuals ecc...) and decide to invalidate the solution. But... it maybe just working in way that is "just give out what you have, whatever it is", without discarding any fix even if it's very bad. This approach is often used in mobile phones where you privilege the location avalability instead of the general accuracy. > Without an independent measurement of some sort there's just not > information there to filter out. You could filter bad fixes and take into account only the fixes you define as good (Max DOP, Min CN0, min N of sats used in solution ecc...). Of course, the price is that you have less availability of the navigation solution. The accelerometer could be used in some ways to give an independent measurement of the dynamics, but should be done in "thigly coupled" way. Not just using GPS solution as Lat/lot/alt information (PVT solution...)
From: Tim Wescott on 26 May 2010 13:19 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. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: Clay on 27 May 2010 10:36 On May 25, 10:28 am, "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? First thing is to use a gps with WAAS. This helps substantually. Also use one with good sensitivity such as one based on a SIRF chipset. My handheld unit almost always has me to within 10 meters. And it is quite often better than 5 meters. Clay
From: Rune Allnor on 27 May 2010 11:29
On 27 Mai, 16:36, Clay <c...(a)claysturner.com> wrote: > My > handheld unit almost always has me to within 10 meters. And it is > quite often better than 5 meters. Eh... how would you know? What do you use for reference? Rune |