What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

Velocity vector algorithm, need help!

Brantel

Brantel

Well Known Member
Can one of you math geniuses or people with experience developing velocity vector algorithms tell me if it is possible to calculate a velocity vector to be projected onto a x,y grid based on the following GPS information being available:

East/west velocity direction
East/west velocity magnitude
North/south velocity direction
North/south velocity magnitude
Vertical velocity direction
Vertical velocity magnitude
 
Brantel said:
Can one of you math geniuses or people with experience developing velocity vector algorithms tell me if it is possible to calculate a velocity vector to be projected onto a x,y grid based on the following GPS information being available:

East/west velocity direction
East/west velocity magnitude
North/south velocity direction
North/south velocity magnitude
Vertical velocity direction
Vertical velocity magnitude
Click to expand...

Pure GPS information is position only, unless there is an embedded IRS. GPS only knows where it is, it calculates any motion. What that means in pure GPS derived velocity info is calculated from what you DID, not what you are doing. It is always lagging, unless you are absolutely steady state.

A velocity vector has to come from IRS derived data. GPS will always be lagging.
 
svyolo said:
Pure GPS information is position only, unless there is an embedded IRS. GPS only knows where it is, it calculates any motion. What that means in pure GPS derived velocity info is calculated from what you DID, not what you are doing. It is always lagging, unless you are absolutely steady state.

A velocity vector has to come from IRS derived data. GPS will always be lagging.
Click to expand...

Well I also have ADAHRS info available as well...pitch, roll, heading, airspeed, rate of turn, lateral accel, vertical accel, vertical speed, etc. available as well.

I get what you are saying but since past trends can sort of predict where you are going in the future since we can't change vectors super fast in these planes. Seems like deriving a velocity vector from GPS data might be good enough for this application but if it can be improved with ADAHRS data, I would try to incorporate it.
 
Velocity vector

If you are attempting to resolve the velocity vector in three dimensions, there is a bit more math.

That being said, if you have that calculation complete, it is not a big step to predict where you will be at a given time, lets say 30 seconds out. Obviously, the prediction would be based on no changes in the vector, i.e. no turns, and unaccelerated flight. It can be a neat feature to have, as long as you understand the limits of the prediction...
 
rocketman1988 said:
If you are attempting to resolve the velocity vector in three dimensions, there is a bit more math.

That being said, if you have that calculation complete, it is not a big step to predict where you will be at a given time, lets say 30 seconds out. Obviously, the prediction would be based on no changes in the vector, i.e. no turns, and unaccelerated flight. It can be a neat feature to have, as long as you understand the limits of the prediction...
Click to expand...

My energy around this is for open source HUD development. Given the small screen space of the affordable HUD options available, there are already limits to the range this velocity vector display needs to be able to present. More or less it just needs to show the trend/vector up/down or left/right.
 
BillL said:
What happened to replies to this thread from yesterday?
Click to expand...
Yeah. I was sure I posted an answer, but it's not here today. (Cue Twilight Zone music)

OIC, there are TWO threads. I posted on the other one.
 
Last edited:
Brian,

I think you need the magnetic heading for the calculation.

You then take the difference of the ground track and MH along with the speed GS and TAS to calculate the wind velocity vector.
 
N941WR said:
Brian,

I think you need the magnetic heading for the calculation.

You then take the difference of the ground track and MH along with the speed GS and TAS to calculate the wind velocity vector.
Click to expand...

That's a related display that I am working on as well but the one I am focused on in this thread is what some people call a flight path vector.

Most EFIS's have this included in their PFD displays these days. Most of them are overlaid on top of a 3D projection or similar to represent synthetic vision. For the open source HUD project I am helping with, I am not planning anything that sophisticated. More like the simple version similar to what I have seen on a F18 HUD.

My goal is a simple HUD with a clean display that adds value to the pilot while keeping his head up and eyes outside. Ultimately the display options may be user selectable so I am working on the algorithms to drive those display options by using what information is provided by the EFIS on its streaming data output. One EFIS maker outputs some data types that are ready to go out of the box but most do not... instead they provide the building blocks in their stream that someone can use in an algorithm to produce the same results.
 
Last edited:
svyolo said:
Pure GPS information is position only, unless there is an embedded IRS. GPS only knows where it is, it calculates any motion. What that means in pure GPS derived velocity info is calculated from what you DID, not what you are doing. It is always lagging, unless you are absolutely steady state.

A velocity vector has to come from IRS derived data. GPS will always be lagging.
Click to expand...

Ummm... I would tend to dispute this information. Most GPS receivers do the mathematical integration that results in the production of 3-axis velocity data, totally independent of any AHARS. In fact it is this velocity information which often is used to aid the attitude solution in EFIS equipment should they loose access to pitot info (Dynon in particular does this).

Also note the ADSB data output by approved GPS position sources and provided to either 1090ES or UAT devices contains velocity data.
 
Last edited:
In the absence of any other information, yes, GPS can compute velocity as a simple difference equation, to provide PVT data (position, velocity, time).

If you really want a much better solution to where you are and where you're going, then you probably want to incorporate additional data such as rate info from gyros, and use a Kalman filter.
 
Canadian_JOY said:
Most GPS receivers to the mathematical integration that results in the production of 3-axis velocity data
Click to expand...

Not integration...differentiation (or the related difference equations). Numerical differentiation is ill-posed, but given relatively long intervals (1 Hz to 10 Hz or so), for the distances covered, it's close enough.
 
Brantel said:
Can one of you math geniuses or people with experience developing velocity vector algorithms tell me if it is possible to calculate a velocity vector to be projected onto a x,y grid based on the following GPS information being available:

East/west velocity direction
East/west velocity magnitude
North/south velocity direction
North/south velocity magnitude
Vertical velocity direction
Vertical velocity magnitude
Click to expand...

BTW, I don't get why you're asking to "project onto an XY grid" this data. You say you have East or West direction, and the same for North and South...am I correct in assuming that means it's either E (90) or W(270), N(0) or S(180)? If so, you have all the data you need to "project" onto a 2-dimensional Cartesian coordinate system...the X and Y magnitudes, which you say are given.

Why don't you give us an example of the actual data you have, please.

In any case, they're all simple coordinate system transformations...Cartesian to Polar or cylindrical, or Spherical, or vice-versa. Easy to derive, even easier to look up.
 
RV7A Flyer said:
BTW, I don't get why you're asking to "project onto an XY grid" this data. You say you have East or West direction, and the same for North and South...am I correct in assuming that means it's either E (90) or W(270), N(0) or S(180)? If so, you have all the data you need to "project" onto a 2-dimensional Cartesian coordinate system...the X and Y magnitudes, which you say are given.

Why don't you give us an example of the actual data you have, please.

In any case, they're all simple coordinate system transformations...Cartesian to Polar or cylindrical, or Spherical, or vice-versa. Easy to derive, even easier to look up.
Click to expand...

Yes, the GPS data made available in the data stream provides:

Your either going E(90) or W(240) at X velocity
and
Your either going N(0) or S(180) at Y velocity
and
Your either going U or D at Z velocity

Velocity is in meters/sec

The data sentences look like this:

@190126152214N3614868W08322052D003+01615E0568N0736D0805
@190126152215N3614908W08322015D003+01609E0549N0752D0702
@190126152216N3614949W08321979D003+01604E0536N0764D0572
@190126152217N3614991W08321944D003+01601E0526N0771D0423
@190126152218N3615033W08321909D003+01600E0518N0775D0274

Updated at about 2x per second.

Here is the serial protocol decoder ring
 
Brantel said:
Velocity is in meters/sec

The data sentences look like this:

@190126152214N3614868W08322052D003+01615E0568N0736D0805
@190126152215N3614908W08322015D003+01609E0549N0752D0702
@190126152216N3614949W08321979D003+01604E0536N0764D0572
@190126152217N3614991W08321944D003+01601E0526N0771D0423
@190126152218N3615033W08321909D003+01600E0518N0775D0274

Updated at about 2x per second.

Here is the serial protocol decoder ring
Click to expand...

Velocity is given in 0.1m/s

@190126152218N3615033W08321909D003+01600E0518N0775D0274

It's been a while since I've done vector math but I think those three values highlighted are going to give you your vector.

[E @ 51.8 m/s, N @ 77.5 m/s, D @ 27.4 m/s]

You now have a Euclidean vector. Your speed will be the magnitude.

Your true air speed in this case is: sqrt(51.8^2 + 77.5^2 + 27.4^2) or 97.1m/s or 188.8 knots.

If you want groundspeed, I believe you can ignore the U/D component and effectively project your speed in two dimensions: [51.8, 77.5] and take the magnitude of that: sqrt(51.8^2 + 77.5^2) = 93.2 m/s or 181.2 knots.
 
RV7A Flyer said:
Not integration...differentiation (or the related difference equations). Numerical differentiation is ill-posed, but given relatively long intervals (1 Hz to 10 Hz or so), for the distances covered, it's close enough.
Click to expand...
Yes, indeed, you're correct. That's what happens when one is writing a post here while doing other, more productive things. Simple minds truly are incapable of doing two things at once. Or at least doing them correctly!
 
Brantel said:
Yes, the GPS data made available in the data stream provides:

Your either going E(90) or W(240) at X velocity
and
Your either going N(0) or S(180) at Y velocity
and
Your either going U or D at Z velocity

Velocity is in meters/sec

The data sentences look like this:

@190126152214N3614868W08322052D003+01615E0568N0736D0805
@190126152215N3614908W08322015D003+01609E0549N0752D0702
@190126152216N3614949W08321979D003+01604E0536N0764D0572
@190126152217N3614991W08321944D003+01601E0526N0771D0423
@190126152218N3615033W08321909D003+01600E0518N0775D0274

Updated at about 2x per second.

Here is the serial protocol decoder ring
Click to expand...

Well, as noted by others, this data IS your velocity vector in Cartesian (XYZ) coordinates. What are you trying to find? Rho and theta?
 
RV7A Flyer said:
Well, as noted by others, this data IS your velocity vector in Cartesian (XYZ) coordinates. What are you trying to find? Rho and theta?
Click to expand...

I want to project that on a 2D HUD in front of the pilot and have it generally be interpreted as a flight path marker.

Basically I need an X and a Y to tell my little circle where to go on the HUD screen.

The hints in this thread have me pointed in the right direction.
 
Last edited:
He wants to project the GPS velocity vector onto a HUD display. The HUD display is fixed to the aircraft. The GPS velocity vector is fixed to an earth coordinate system.

In order to do this, he needs to know not only where is the aircraft going, he needs to know where the fuselage is pointed.

Low and slow in a strong crosswind, you could be crabbing 25 degrees to the flight path, and you presumably want the HUD to recognize that.

This is why you need AHRS data, and magnetic compass info. Presumably, it's rate gyros can give you orientation of the aircraft relative to zero pitch, zero yaw and zero roll. But I believe you still need what direction you are pointed relative to magnetic north, because your GPS data is in that coordinate system. (Alternatively, it could be relative to polar north, not sure.)

So, suppose the GPS velocity vector is (Ve, Vn, Vu), for east, north and up.

Also suppose the aircraft pointing angles are (Ap, Ay, Ar), for pitch, yaw and roll. And suppose the aircraft is oriented at magnetic heading angle Ah. You need to resolve the velocity vectors of the GPS into the aircraft's coordinate system, then display that vector on the HUD, accounting for pitch, yaw and roll angles. Note that you have to account for what happens in sine and cosine functions when angles go past 90 degrees, etc.

If the GPS data is not magnetic north, then additionally you have to adjust polar north to magnetic north via a table of deviations.

If you want to pay me to work out the page of code you will need to do this, I should be able to help.

-Paragon
Cincinnati, OH
 
Yeah, pretty much what you said.

I do have the other required variables available.

Sorry, nobody getting paid for this....all volunteers. :)
 
Paragon said:
He wants to project the GPS velocity vector onto a HUD display. The HUD display is fixed to the aircraft. The GPS velocity vector is fixed to an earth coordinate system.

In order to do this, he needs to know not only where is the aircraft going, he needs to know where the fuselage is pointed.

Low and slow in a strong crosswind, you could be crabbing 25 degrees to the flight path, and you presumably want the HUD to recognize that.

This is why you need AHRS data, and magnetic compass info. Presumably, it's rate gyros can give you orientation of the aircraft relative to zero pitch, zero yaw and zero roll. But I believe you still need what direction you are pointed relative to magnetic north, because your GPS data is in that coordinate system. (Alternatively, it could be relative to polar north, not sure.)

So, suppose the GPS velocity vector is (Ve, Vn, Vu), for east, north and up.

Also suppose the aircraft pointing angles are (Ap, Ay, Ar), for pitch, yaw and roll. And suppose the aircraft is oriented at magnetic heading angle Ah. You need to resolve the velocity vectors of the GPS into the aircraft's coordinate system, then display that vector on the HUD, accounting for pitch, yaw and roll angles. Note that you have to account for what happens in sine and cosine functions when angles go past 90 degrees, etc.

If the GPS data is not magnetic north, then additionally you have to adjust polar north to magnetic north via a table of deviations.

If you want to pay me to work out the page of code you will need to do this, I should be able to help.

-Paragon
Cincinnati, OH
Click to expand...

You can do all of this one of two ways. The first is to figure out what all of the transformations are from one coordinate system (that is, the velocity vector in [E, N, Z] coordinates in either true or magnetic north) to the aircraft's coordinate system, or you can put everything into a common reference system in inertial space, do the computations there, and then transform them back into display space.

Either way works, but the second is usually preferred, particularly if you are building a more extensible, general software system that can handle additional components and inputs (like, say, traffic position and direction). If you're doing it using modern object-oriented design, then you can define a class hierarchy for coordinate systems (or, I imagine, just buy a library for them), and then you can put any object in any of the defined coordinate systems into any other coordinate system, depending upon what you need. It's probably also easier in the long run, as well as MUCH easier to extend. FWIW, the base class should probably be referenced to earth-centered earth-fixed inertial space, as that's what GPS uses.
 
Brantel said:
I want to project that on a 2D HUD in front of the pilot and have it generally be interpreted as a flight path marker.

Basically I need an X and a Y to tell my little circle where to go on the HUD screen.

The hints in this thread have me pointed in the right direction.
Click to expand...

W is negative. S is negative. (Project your x/y speeds onto a 2d Cartesian plane with 0 speed at the origin.)

trueheading = math.degrees(math.atan2(ew, ns))

E0518 N0775

ew = 51.8
ns = 77.5

trueheading = 033.8 degrees

If you were to flip your N/S so it's negative you'll end up with 146.2

Stay heading south and flip ew to negative to going more westerly and you'll end up with -146.2. Since it's negative, add 360 and get 213.8
 
Thanks for all the help guys.

I now have the code developed and up and running and compared to real flight data logs.

At this point I have been able to either parse or calculate the following data from the G3X serial stream:

Ground Speed (calculated from parsed GPS data)
Ground Track (calculated from parsed GPS data)
Altitude AGL (parsed)
Roll (parsed)
Pitch (parsed)
Indicated Air Speed (parsed)
Pressure Altitude (parsed)
Outside Air Temp (parsed)
Angle of Attack (parsed)
Magnetic Heading (parsed)
Barometer Setting (calculated from parsed data)
Baro Corrected Altitude (calculated from parsed data)
Vertical Speed (parsed)
True Air Speed (calculated from parsed data)
Vertical G (parsed)
Rate of Turn (Parsed)

Now I am working on adding wind speed and direction to my growing list of variables.

Still working on getting my head wrapped around the velocity/flight path vector display.
 
Last edited:
Canadian_JOY said:
Ummm... I would tend to dispute this information. Most GPS receivers do the mathematical integration that results in the production of 3-axis velocity data, totally independent of any AHARS. In fact it is this velocity information which often is used to aid the attitude solution in EFIS equipment should they loose access to pitot info (Dynon in particular does this).

Also note the ADSB data output by approved GPS position sources and provided to either 1090ES or UAT devices contains velocity data.
Click to expand...

GPS calculated position data is where you WERE, a fraction of a second ago. It never knows where you are, if you are moving. When it calculates speed, it is using historical numbers, and will always lag unless you are in steady state motion, i.e. steady speed in one direction.

It doesn't know what your are doing, it only knows what you DID. I have used GPS on foot, motorcycles, cars, and boats. Most types you can call up instantaneous speed and direction. Start a steady turn, and watch. The speed vector is always lagging you in the turn.

The info for a velocity vector needs to come from inertial data. Maybe some newer GPS's might have one embedded in them, and maybe you could use "GPS" data then. But it is inertial based.
 
svyolo said:
It doesn't know what your are doing, it only knows what you DID.
Click to expand...
Exactly correct. There's a one second latency on my Garmin Virb Elite. I take this into account when reviewing my Ground Speed on takeoff or touchdown. (I have to take the wind into account as well.)
 
I am a few weeks from ordering a glass cockpit setup, and I have had to educate myself on the glass we use in GA.

I made a bad assumption that you could use inertial info alone for the VV or FPM. The grade of AHRS used in GA makes that impossible, although GRT and MGL might be a bit better in that regard. GRT makes a claim about this on their website, and MGL sells a more expensive AHRS. They don't make this claim.

The lower grade AHRS's are fine for attitude, but position keeping, and hence velocity, not so much. Somehow they mathematically blend in GPS and or airspeed for some PFD calculations. I am sure they are proprietary algorithms.

Cheaper gps's update at 1 hz, the WAAS ones at 4 or 5. They will be better, but will still lag.

I don't know how the EFIS companies blend the inertial with other speed. But it is a mathematical blend.

That math is over 30 years in my past.
 
svyolo said:
I am a few weeks from ordering a glass cockpit setup, and I have had to educate myself on the glass we use in GA.

I made a bad assumption that you could use inertial info alone for the VV or FPM. The grade of AHRS used in GA makes that impossible, although GRT and MGL might be a bit better in that regard. GRT makes a claim about this on their website, and MGL sells a more expensive AHRS. They don't make this claim.

The lower grade AHRS's are fine for attitude, but position keeping, and hence velocity, not so much. Somehow they mathematically blend in GPS and or airspeed for some PFD calculations. I am sure they are proprietary algorithms.

Cheaper gps's update at 1 hz, the WAAS ones at 4 or 5. They will be better, but will still lag.

I don't know how the EFIS companies blend the inertial with other speed. But it is a mathematical blend.

That math is over 30 years in my past.
Click to expand...

Kalman filter.
 
DOS PC's were only about 4 years old when last I learned about a Kalman Filter. LOL.

I was surprised at the grade of AHRs used in GA EFIS's. I would have assumed they were as good as what I used 25 years ago.

But I guess they are more than good enough for our application.
 
You will produce the best possible state vector estimate by combining the GPS position (not velocity) with the AHRS accelerations and angular velocities in your extended Kalman filter. This will give you a current velocity vector estimate, not a previous observation. Note that GPS positions are normally based on WGS-84, and you need to know whether the data returned is relative to the ellipsoid or to the geoid.

The GPS velocity outputs, where available, are generally derived from an EKF within the GPS, so you don't actually increase the data input to the calculation by including them (but you add uncertainty from someone else's process and measurement noise models).

You can include the air data state vector components in the EKF if you're concerned about performance as well as navigation.
 
dmn056 said:
You will produce the best possible state vector estimate by combining the GPS position (not velocity) with the AHRS accelerations and angular velocities in your extended Kalman filter. This will give you a current velocity vector estimate, not a previous observation. Note that GPS positions are normally based on WGS-84, and you need to know whether the data returned is relative to the ellipsoid or to the geoid.

The GPS velocity outputs, where available, are generally derived from an EKF within the GPS, so you don't actually increase the data input to the calculation by including them (but you add uncertainty from someone else's process and measurement noise models).

You can include the air data state vector components in the EKF if you're concerned about performance as well as navigation.
Click to expand...


I am not sure. I would definitely use some kind of filtered GPS position, and accelerations from the AHRS. I think AHRS velocity might potentially be way off.

I was used to INS's that stayed within a few knots through out the flight. You could definitely use velocity from those, especially because we were flying at much higher speeds. I am not exactly sure how far off the AHRS's that are used in GA EFIS's, but the velocity errors might be 10 times higher.

I believe many are using GPS and/or airspeed for velocity. The magnitude of the GPS velocity is probably close enough, the direction would lag in accelerated flight.

That is a guess. I have been reading the user's manual from all 4 EFIS manufacturer's, and perusing their forums.

Like I said, GRT advertises not using pitot/static in their AHRS. MGL sells what they claim is a "high performance" AHRS. The high performance was not speed based, but better AHRS performance.
 
Comparing INS’s to today’s GA AHRS units? Apples to oranges .... those things weigh a ton, cost more than most GA airplanes, and are huge in comparison to roughly the size of a deck of cards.

I hate to be the bearer of bad news but all affordable GA AHRS units use some sort of aiding to keep the errors in check.

GRT uses aiding as well, they are just using clever marketing to hide it.

In the early years some manufacturers required air data for their aiding and if that went away so did their attitude solution’s accuracy.

Today most if not all can use multiple aiding sources so this is not a problem.

All this talk about what you can do with any of these AHRS unit’s raw data is a mute point since none of the manufacturers make that data available to the end user. There are a few stand alone third party AHRS units out there that do but that’s not Garmin, GRT, Dynon, MGL, or AFS.

If you want raw data, your going to have to get into the components and build one yourself or purchase a pre built board like the Stratux AHRS board which is a hobby grade solution.
 
Last edited:
You must log in or register to reply here.
Back
Top