14 replies to this topic

[TerryAC4]

Hi All,

A newby question, the OP GPS is configured to output at a 10 Hz rate, has no Z velocity output.  The AHRS currently sets vel[2] (z) to 0.  Can someone comment on what kind of impact, good or bad, of using a different GPS that does output a Z velocity would have on the filter?  Say something like the u-blox 6, with both a 10 Hz output, and a NED velocity output message.

Thanks!

[peabody124]

The effect would be good.  IIRC the variance on that vel[z] = 0 is very high, so it's not detrimental to say that.  The filter then uses the z position and accels to work out the z velocity as well as possible.  However, obviously having more information will always improve things.

[Kenn Sebesta]

I would tend to think that trying to fuse the two z_dot measurements is somewhat perilous. If the GPS noise isn't gaussian (and it almost certainly isn't), then you should have biases that might be very difficult to account for. Moreover, I suspect that the GPS z_dot will have a significant lag, due to the nature of its internal filters. Not saying that it won't work, just that my instinct says that you shouldn't expect much, if any, improved performance vs. a decent barometer. This kind of technology has been used in aircraft for 50 years, so I'm betting that it's pretty mature.

If you suppose that the variance is very high, then, yeah, you'll certainly have no adverse reactions. But then what is there to be gained?

Lastly, just for my personal edification, if OP receives an D_dot message-- or a D_dot component in a NED_dot message-- will it parse it or will it otherwise just ignore it?

[peabody124]

Kenn Sebesta, on 03 March 2011 - 11:26 AM, said:

I would tend to think that trying to fuse the two z_dot measurements is somewhat perilous. If the GPS noise isn't gaussian (and it almost certainly isn't), then you should have biases that might be very difficult to account for. Moreover, I suspect that the GPS z_dot will have a significant lag, due to the nature of its internal filters. Not saying that it won't work, just that my instinct says that you shouldn't expect much, if any, improved performance vs. a decent barometer. This kind of technology has been used in aircraft for 50 years, so I'm betting that it's pretty mature.

If you suppose that the variance is very high, then, yeah, you'll certainly have no adverse reactions. But then what is there to be gained?

You might be right and this is something we've been playing around with (comparing the best velocity versus position variance on the GPS data) but we don't have a firm conclusion yet.  I need to fix my quad and get some solid logging data for offline analysis.  However we have essentially four pieces of information: gps z position, (theoretically gps z velocity), baro z position, and acceleration in z.  There _is_ an optimal way to fuse them, you just might be right that giving the z vel substantially less weight is the best way.  To me this is an empirical question.

Quote

Lastly, just for my personal edification, if OP receives an D_dot message-- or a D_dot component in a NED_dot message-- will it parse it or will it otherwise just ignore it?

No, that's largely a debugging message.  We have a handful of UAVObjects that might even be disabled when DEBUG = NO that are mostly for us to scope the internals.  For example NEDaccel is used entirely within guidance and helps with vertical position hold.

[Kenn Sebesta]

peabody124, on 03 March 2011 - 03:41 PM, said:

You might be right and this is something we've been playing around with (comparing the best velocity versus position variance on the GPS data) but we don't have a firm conclusion yet.  I need to fix my quad and get some solid logging data for offline analysis.  However we have essentially four pieces of information: gps z position, (theoretically gps z velocity), baro z position, and acceleration in z.  There _is_ an optimal way to fuse them, you just might be right that giving the z vel substantially less weight is the best way.  To me this is an empirical question.

You're certainly right that there's an optimal way to fuse them, I'm just not sure you gain much. The barometric sensor is so good for this kind of thing, and coupled with the z-axis acceleration you already have everything necessary for a really nice state estimation.

If you wanted to do the GPS optimally with a Kalman filter, first you'd need to characterize the noise. If you can do that, then you can subtract the colored noise and then filter the remaining Gaussian noise. I have no idea how to do this, and a couple years ago made a cursory bibliography on the matter. We didn't find anything that helped us create a parametric model of noise, not even a simple one, so we just shelved it.

[peabody124]

Well one thing you gain using the gps z position over baro is insentivity to the slower time scale drifts that affect baros pretty badly.  Also just from eye balling the traces the noise is comparable on both, so I'm pretty sure if/when we break it down gps improves things.  For example the temporal correlations you can cheapily almost avoid by simply increasing the variance over the empirical one to the original while noise.  Anyway, experiments will answer this

[Kenn Sebesta]

peabody124, on 03 March 2011 - 04:08 PM, said:

Well one thing you gain using the gps z position over baro is insentivity to the slower time scale drifts that affect baros pretty badly.  Also just from eye balling the traces the noise is comparable on both, so I'm pretty sure if/when we break it down gps improves things.  For example the temporal correlations you can cheapily almost avoid by simply increasing the variance over the empirical one to the original while noise.  Anyway, experiments will answer this

Well... I'm guessing that that gps z_dot output is radically different from the z_dot baro output. I'd be curious to know whether you'd be anywhere close to 'z' reality if you integrated the z_dot output from the GPS. If you are, then I guess you've got a pretty solid answer for signal noise relevance over short periods of time.

Edited by Kenn Sebesta, 03 March 2011 - 04:25 PM.

[peabody124]

Our baro doesn't put out a position derivative as far as i know.

[Kenn Sebesta]

peabody124, on 03 March 2011 - 05:23 PM, said:

Our baro doesn't put out a position derivative as far as i know.

Yeah, that's a good point. I was thinking in terms of variometers, without having actually realized that I don't think I've ever seen a MEMS variometer. Not even sure such a thing exists.

TerryAC4, I don't have any data here so I can't integrate them myself, but I'd try integrating your GPS z_dot vs. acc_dot_dot and comparing it with the actual Z values, preferably measured by some reference. (Imagine flying up the side of a building to some known height.) I would think that if you find that the integrated values for GPS z_dot are good, then you know noise is low. I would also check if there is GPS signal delay. If the results seem pretty good, then you are completely justified in fusing in the new measurement data.

Actually, don't do it near a building, you'll get noised GPS readings. Maybe a flagpole in the middle of a wide space?

[Corvus Corax]

I am working on a module for fixed wing that is supposed to work without GPS and uses the barometric sensor for both Z and Z_dot measurement (the latter indirectly with a very simple smoothing filter over a delta Z )

I will soon make some flight tests. With a bit of luck the telemetry logs of both GPS and barometer readings might shed some light on which sensor is good for what. Once I have them I'll post them here.

[Corvus Corax]

http://cybertrench.c...aro_logs.tar.gz

These include high freq PositionActual and  BaroAltitude logs (250ms period) of a couple of fixed wing flights. The GPSPosition period is longer, I think 500 ms or 1000 ms.

[Canova]

I can imagine that a similar situation will exist with the speed estimate on a fixed wing for correction of the accelerometer outputs during a turn for example. Would the GPS alone provide a good enough estimate for speed or will a separate airspeed measurement be required?

[TheOtherCliff]

peabody124, on 03 March 2011 - 03:41 PM, said:

...
we have essentially four pieces of information: gps z position, (theoretically gps z velocity), baro z position, and acceleration in z.  There _is_ an optimal way to fuse them
...

I'm going to go out on a limb and assume that ultrasonic (etc.) range finder altitude for altitudes (AGL) of say 2m or less may eventually be used for soft landings and sources like this should be considered a possible additional source of altitude information.

This implies a rough topographical map (or at least a fixed altitude at the landing site) for fusing with the ultrasonic sensor so we can have an absolute altitude to compare with the other sensors.

Cliff

[TheOtherCliff]

peabody124, on 03 March 2011 - 04:08 PM, said:

Well one thing you gain using the gps z position over baro is insentivity to the slower time scale drifts that affect baros pretty badly.  Also just from eye balling the traces the noise is comparable on both, so I'm pretty sure if/when we break it down gps improves things.  For example the temporal correlations you can cheapily almost avoid by simply increasing the variance over the empirical one to the original while noise.  Anyway, experiments will answer this

Z accuracy is probably only critical for low AGL flight like landings?

GPS drifts too with satellites being added or removed.  If GPS "selective availability" ever comes back or the EU version of GPS (sorry, forget the name) implements SA the drift will be even worse.

My point with the ultrasonic range finder for landings is that it's variance is really low.  When it is within range, you should rely on it.  You know the ground is 1.5m away and should be doing something about it (flare).  It comes into range just in time for landing.  What do you think?

Cliff

[peabody124]

I agree US is good for quads landing.  I'd be curious about getting it working well for planes - you might find you have to make it slightly forward facing and how well it works is dependent on speed.  Sambas has already written an US range finding module for OP.

Another good alternative is laser range triangulation although it takes a bit more computation.