From: Tim Wescott on
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
[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
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
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
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