> On Freitag 20 Mai 2005 16:37, Andy Ross wrote:
> > Mathias Fröhlich wrote:
> > > At first I need to know how this local frame is meant.
> > > What I have found from the code is that it is meant to be the *geodetic*
> > > horizontal local frame.
> > > But is is meant to be fixed at the aircraft and thus rotates due to the
> > > aircrafts velocity or is it fixed at the earth and relocated for every
> > > frame to display?
> >
> > For what it's worth, YASim supports this "NED" (north/east/down)
> > coordinate frame for output, but doesn't use it internally.  It's
> > pretty strange IMHO, and of course has a singularity problem at the
> > poles.  If JSBSim is having trouble with it, it might be best to just
> > junk the concept and fix the HUD code to use body coordinates.

> Yep, JSBSim uses *a* horizontal local frame, the geocentric one.
> But not the geodetic horizontal local frame like flightgear seems to expect.

Actually, IIRC, FlightGear did it's own conversions from geocentric to geodetic 
and so
expects to get geocentric locations from the FDM. Over time, perhaps this has 

> I have checked in into JSBSim's cvs a change which will make the inerial
> acceleration in the earth fixed geodetic horizontal local frame available to
> the HUD.
> That patch is attached to this mail. So you could apply that to your local
> tree and use that until flightgears JSBsim is again synced with the original
> tree.

Mike: for the purposes of energy calculations (I assume you are providing some 
kind of
guidance via HUD symbology based on energy) and based on a quick look at your 
there should be virtually no difference between the geocentric accels and the
corresponding geodetic values. Previously in JSBSim we have provided NED accels 
(in the
geocentric local frame), but this capability was lost when the EOM were 

If everyone is happy with this change, I'll make sure it gets into the newer 
version that is finishing up development in another branch.


Flightgear-devel mailing list

Reply via email to