gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about decoding subframe messages (ublox F9P)


From: Curtis Olson
Subject: Re: Questions about decoding subframe messages (ublox F9P)
Date: Wed, 27 May 2020 22:50:00 -0500

On Wed, May 27, 2020 at 10:13 PM Gary E. Miller <gem@rellim.com> wrote:
ORGN does similar.  No one knows how it works.  Not even well enough
to document the required protocol.  No doc, no gpsd support.

I would like some doc on that "send GGA" protocol.  ORGN wants the
same thing, but has no idea what to send or how.

I'll try to dig something up for you, I remember it making sense when I did it, but I think I was looking at a working example at the time.
 
> For our lab's purposes, one of our core strengths (ours, not
> necessarily mine) is a 15-state EKF (kalman filter) that estimates
> attitude and location using gyro, accelerometer, and gps.

What?  No magnetometer?  9-axis works a lot better than 6-axis.
Until you fly by a magnetic source...

This a fun discussion, but probably outside the scope of gpsd, but let me say a couple thoughts.  With only gyro, accels, and gps pos/vel, (INS + GNSS) you can actually estimate your true heading (and roll and pitch.)  You can't do it from a single instantaneous measurement, but over time if you have enough change in velocity (aka acceleration) from the perspective of the gps velocity vector, you can converge.  It's kind of abstract, but imagine I power up and guess that I'm pointed north (but I'm really pointed east).  I start moving forward so my filter estimates north velocity and change in position latitude based on integrating accels and gyros.  When the next gps reading comes in, I'm not where I predicted, and my velocity vector is wrong.  So I could ask myself, what starting heading would have placed me in the actual spot I ended up?  If you wrap all that up into a kalman filter (I'm being extremely hand wavey) and iterate over time as you fly, magic starts happening.

The cool thing is that without mags, this system converges accurately to true heading, but it can take a few seconds or minute or two (depending on how bad the initial guess was) and it requires acceleration (change in direction also works because that is a change in the velocity vector, aka acceleration.)  Also, any gps errors (including latency) can pull the solution away from truth.  So for us flying fixed wing aircraft, it's actually really great.  Magnetometers are never perfectly calibrated, so adding those to the system is really just adding another thing that pulls your solution away from the truth.  But they can help you start out with a better initial guess ... so it s a love/hate relationship.

We do have a version of our EKF with mags incorporated into the measurement update (we can compare the sensed mag vector against the estimated ideal mag vector from the WMM.)  This works pretty well when the mags are well calibrated, but if the calibration is not great, then it's a constant source of error driving the system away from truth.

Lately I've been working hard on mag calibration, that's another long story, but if I trust my filter has converged (close) to truth and I can use the WMM to compute the ideal mag vector.  Then I can collect data from the actual sensor vs. the estimated truth, and do an affine transformation fit ... over the range of attitudes the vehicle flies or drives, I can get a pretty nice calibration.

Anyway, love and hate the mags ... nothing is perfect, but sometimes with vs. without works a little better than the other for a particular purpose.  My side shelter in place project is an autonomous boat, so I need an EKF that performs well in a low dynamic situation and for that I need mags.

Attitude?  RTK does not fix your attitude, unless you have two on the same rover.

Sorry, yes, see above.  INS + GNSS = magic.  INS + RTK GNSS = better magic?  INS + GNSS + MAGS = other different magic.
 
Looks nice, I've never flown HITS.  I'd have the next waypoint, course, distance and time to next waypoint, plus baro altitude.

I've created the videos in post-process as a way to intuitively see what the flight controller is doing, plus it's kind of cool.  Over and over again when I look at something new, I see a new problem, and then I spend a year working on fixing it.  That stupid HUD visualization has caused me a ton of work!
 
Is your alt MSL or HAE?  No ball?

This is MSL (basically GPS altitude after the EKF has smoothed it.)  The ekf altitude still chases gps error, but I get a lot of the more subtle variations out of the INS and it's not as noisy as the baro.  On any given day it's a toss up for if the baro or the gps will drift more over the course of the flight (and most of the baro drift is the sensor, not the weather.)  I actually do have a ball on the ground station display, but it's not been useful for anything since I have my eyes on the plane itself when I manually fly it (like an RC airplane.)  It's tuned for a full size airplane since I got the math out of FlightGear, so it's *really* jumpy when I drive it from mems accels on a small UAV with far less inertia.  Oh, shoot, I just lied, I yanked that gauge out a few weeks ago and replaced it with a prioritized caution/warning alert system ... that has been more useful and can hopefully start to give some early indications if something important is going south.

Sorry for all the typos, it's late here (for me). :-)

Thanks,

Curt.
--
Curtis Olson
University of Minnesota, Aerospace Engineering and Mechanics, UAS Lab

reply via email to

[Prev in Thread] Current Thread [Next in Thread]