opengc-devel — Developer's discussion list

[Opengc-devel] 0.54 corrupted windows release

[Damion S. <be...@cs...>]

It was pointed out to me that the Windows exe version of OpenGC 0.54 
had a corrupt zip file. This is hopefully now fixed. Although the new 
release has the same version number as the corrupt version, it adds an 
additional feature, the ability to turn the frame rate test on or off 
via an addition to the render window declaration line in the opengc.ini.

This therefore requires that you update your opengc.ini - I've updated 
the install pdf file to more thoroughly explain configuration issues. 
If there are any questions or problems feel free to ask.

-Damion-

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

[Opengc-devel] OpenGC updates

[Damion S. <be...@cs...>]

Hi everyone,

It's been a while since I've posted any update announcements so I 
figured one is due. A summary of recent activity:

1) Release 0.54 is available in both Windows .exe and source versions 
(the source is a mirror of the CVS and has been build tested on both 
Windows and MacOS X). The main component which has been updated is...

2) New POSIX compliant EGyro data source; the previous data source 
worked only on Windows. The code is IFDEF'd so that it should build 
correctly on whichever platform is used. I can vouch for the 
performance of the Keyspan serial/USB adapter (see 
http://www.keyspan.com/products/usb/USA19W/ ). If you have a laptop 
without a serial port - a Powerbook for instance - you might want to 
give this a try.

3) The new X-Plane nav data format is compatible with the current nav 
system in OpenGC. The changes made do not affect the ability of OpenGC 
to parse the file.

4) The .ini file format has changed slightly. You can now specify a COM 
port name for the EGyro data source (ver. 0.54), and can control the 
"frame rate test" feature via a fifth parameter in the render window 
declaration (CVS only). A few more comment lines have been added as 
well. Note that the .ini format differs between 0.54 and the CVS.

5) OpenGC is _probably not_ FS2004 compatible, since that requires the 
newest FSUIPC. Since FSUIPC is now payware (though freeware use is 
permitted with restrictions) the build procedure will be a bit more 
complicated. I'm still ironing out the build process, I'll let you know 
when it's working.

Cheers,
-Damion-

---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

Re: [Opengc-devel] nav display?

[Wendell T. <we...@ad...>]

On Fri, Aug 29, 2003 at 04:05:57PM -0400, Damion Shelton wrote:
> > What is the name of the nav display (HSI) shown on the home web
> > page?  I get blank screens when I load Boeing737NAV.
> 
> Sorry for the confusion... the name of the gauge is: NavTestGauge (note 
> case sensitivity).

Thank you, that one looks nice.

> I'm working on a new map projection system but it's not
> finished yet.

This one is fine.

> > What files should be in the 'NAV DATABASE PATH'?  Should this
> > point to the directory with the apt.dat, etc. files?  Or one
> > above it?
> 
> It should point to the .dat files - I should clarify this in the 
> documentation.

Oops, the 'NAV DATABASE PATH' must end in a '/'.  My mistake.

> If there is no nav data to read, I believe this results in OpenGC 
> aborting (I haven't tried that error case in a while).

It just reports 'The navaid list contains 0 items' and
continues.

> Hope this helps, any other questions please let me know.

Yes, and thank you for your hard work.

Wendell

Re: [Opengc-devel] nav display?

[John W. <ca...@mm...>]

If you go to the website, you'll see some screenshots. the latest show the
generic display, go down (back) a few pages and you'll see some earlier
(circa Feb 02) shots of the PFD/ND and PFD/EICAS.

Sorry, I don't have the latest CVS (I've been quite busy this year and not
kept up with the development) but perhaps that code is still there and you
might have to edit the make files to compile. As I recall, an entry in
opengc.ini not supported by the code is simply ignored which might account
for the blank screen

Hope this helps.

Regards
JW
----- Original Message -----
From: "Wendell Turner" <we...@ad...>
To: <ope...@li...>
Sent: Friday, August 29, 2003 11:56 AM
Subject: Re: [Opengc-devel] nav display?


> On Fri, Aug 29, 2003 at 11:39:21AM -0700, John Wojnaroski wrote:
> > I've not kept up with the latest CVS version, so I'm not sure which
version
> > you are running.
>
> The cvs version.  As I'm on a Linux platform, I only have access
> to CVS; there don't seem to be older tar files around.
>
> > Again, I've not looked at the latest CVS source, but I think Damion was
> > creating a generic nav display whereas the earlier version was specific.
>
> I don't really care which version, just any nav/hsi display
> would be nice.
>
> > The earlier version should work (i.e., load and display irrespective of
nav
> > data since there were default values for LAX). But data or a connection
is
> > NOT required to bring up the display (at least not in the earlier
version)
>
> Ok, thanks for that piece of information.
>
> > If you are running flightgear, I might note there has not been an update
to
> > the FG/OpenGC interface in some time
>
> The other displays (pfd) seem to work fine, so I have no reason
> to doubt that interface.
>
> Wendell
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opengc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengc-devel

Re: [Opengc-devel] nav display?

[Damion S. <be...@cs...>]

> What is the name of the nav display (HSI) shown on the home web
> page?  I get blank screens when I load Boeing737NAV.

Sorry for the confusion... the name of the gauge is: NavTestGauge (note 
case sensitivity). The current incarnation of this gauge only loads 
airports and some classes of VOR's, and is best used in latitudes below 
60 degrees n/s because of the Mercator projection. I'm working on a new 
map projection system but it's not finished yet.

Boeing737NAV used a bunch of code that was incomplete (the original 
developers disappeared) so I should remove any references to it from 
the .ini file.

> What files should be in the 'NAV DATABASE PATH'?  Should this
> point to the directory with the apt.dat, etc. files?  Or one
> above it?

It should point to the .dat files - I should clarify this in the 
documentation.

> If there is no nav data to read, or no connection to flightgear,
> will that result in a blank screen for the nav display?  That
> is, does the nav display need a valid position from the flight
> sim?

If there is no nav data to read, I believe this results in OpenGC 
aborting (I haven't tried that error case in a while). If it does not 
receive a network comm from flightgear or another sim, the gauge will 
display but remain static.

Hope this helps, any other questions please let me know.

Cheers,
-Damion-

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
412.268.6436 (fax)
http://www.cs.cmu.edu/~beowulf
---------
We tend to scoff at the beliefs of the ancients. But we can't scoff at 
them personally, to their faces, and this is what annoys me.

Re: [Opengc-devel] nav display?

[Wendell T. <we...@ad...>]

On Fri, Aug 29, 2003 at 11:39:21AM -0700, John Wojnaroski wrote:
> I've not kept up with the latest CVS version, so I'm not sure which version
> you are running.

The cvs version.  As I'm on a Linux platform, I only have access
to CVS; there don't seem to be older tar files around.

> Again, I've not looked at the latest CVS source, but I think Damion was
> creating a generic nav display whereas the earlier version was specific.

I don't really care which version, just any nav/hsi display
would be nice.

> The earlier version should work (i.e., load and display irrespective of nav
> data since there were default values for LAX). But data or a connection is
> NOT required to bring up the display (at least not in the earlier version)

Ok, thanks for that piece of information.

> If you are running flightgear, I might note there has not been an update to
> the FG/OpenGC interface in some time

The other displays (pfd) seem to work fine, so I have no reason
to doubt that interface.

Wendell

Re: [Opengc-devel] nav display?

[John W. <ca...@mm...>]

Hi,

I've not kept up with the latest CVS version, so I'm not sure which version
you are running. If you are running an "older" version perhaps I could help,
if you'r running the latest then Damion...

Again, I've not looked at the latest CVS source, but I think Damion was
creating a generic nav display whereas the earlier version was specific.

The earlier version should work (i.e., load and display irrespective of nav
data since there were default values for LAX). But data or a connection is
NOT required to bring up the display (at least not in the earlier version)

If you are running flightgear, I might note there has not been an update to
the FG/OpenGC interface in some time

Regards
JW

----- Original Message -----
From: "Wendell Turner" <we...@ad...>
To: <ope...@li...>
Sent: Friday, August 29, 2003 10:10 AM
Subject: [Opengc-devel] nav display?


> What is the name of the nav display (HSI) shown on the home web
> page?  I get blank screens when I load Boeing737NAV.
>
> What files should be in the 'NAV DATABASE PATH'?  Should this
> point to the directory with the apt.dat, etc. files?  Or one
> above it?
>
> If there is no nav data to read, or no connection to flightgear,
> will that result in a blank screen for the nav display?  That
> is, does the nav display need a valid position from the flight
> sim?
>
> Wendell
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opengc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengc-devel

[Opengc-devel] nav display?

[Wendell T. <we...@ad...>]

What is the name of the nav display (HSI) shown on the home web
page?  I get blank screens when I load Boeing737NAV.

What files should be in the 'NAV DATABASE PATH'?  Should this
point to the directory with the apt.dat, etc. files?  Or one
above it?

If there is no nav data to read, or no connection to flightgear,
will that result in a blank screen for the nav display?  That
is, does the nav display need a valid position from the flight
sim?

Wendell

[Opengc-devel] Re: [Opengc-announce] like to use instruments for my own simulation - where do i start?

[Damion S. <be...@cs...>]

Hi,

> My question to you developer guys is which components do I need from 
> the source code to simply draw a glass cockpit, that is driven with my 
> simulation data ?

This depends on whether you want to have the rendering occur within 
your code or in a separate program. Either way will work, but the 
approach would be different:

Common to either approach - classes derived from ogcDataSource are 
responsible for handling the acquisition of data from the simulator. 
You will need to write a data source that can interface with your 
computer vision code; exactly how this will be done depends on your 
system. I would strongly suggest using network communications (probably 
UDP format) as this will result in the most portable system - any 
computer that can hook up to your vision machine with an ethernet cable 
will be able to read data. Look at the X-Plane data source for an 
example of how UDP programming is done with the Plib library used by 
OpenGC.

Within your code - you need to perform OpenGL window management in a 
way similar to that done in ogcRenderWindow. The gauges are, for the 
most part, coded in pure OpenGL and therefore don't actually care about 
the specifics of window management. Keep in mind that you will need to 
preserve the overall framework of OpenGC. For instance the AppObject 
class allows event messages to be passed between objects, so your code 
would need to replicate this behavior.

Separate program - this is by the far the simplest approach. Write your 
data source in OpenGC to accept UDP network packets that are broadcast 
from you vision machine and translate them to the internal DataSource 
format. This is quite similar to how the existing data sources work. In 
this scheme, OpenGC can be run on any networked machine connected to 
the sim, or even on the sim machine itself with the network configured 
in "loopback" mode.

To summarize: I suggest keeping OpenGC as a separate program, adding 
UDP broadcast to your vision system, and writing a new data source 
(using X-Plane as an example). Keep in mind that the X-Plane data 
source is an example only; it does some slightly strange variable 
casting to deal with the floating point format so don't follow it 
exactly!

If you have any more questions feel free to ask (though I'd suggest 
using the devel instead of announce list).

Cheers,
-Damion-
---------
Damion Shelton
The Open Source Glass Cockpit Project (OpenGC)
Carnegie Mellon University, Robotics Institute
http://www.opengc.org
da...@op...

[Opengc-devel] Re: your OpenGC screen shots

[John W. <ca...@mm...>]

Hi Damion,

Good to hear from you...
>
> Wow! A few quick questions about the screen shots you sent the link
> for... are you planning on contributing that code back to the main
> repository? It looks fantastic! Am I interpreting things correctly in
> that you have a working FMC? It would be great if all of this code
> could be made to work cross-platform.
>
> Anyways, let me know what your plans are. As I said, those are some
> fantastic shots.
>
Yes, that is a working  FMC, but it's NOT state-of-the-art control theory
stuff. However it will fly a coupled ILS with autothrottle/autoflare/rollout
and do a few other things like stability aug stuff and attitude hold

I've not kept up with the changes you make to the baseline and a bunch of
the stuff is specific to my setup and requirements. The fg/opengc interface
is highly customized and requires a minimum of three network machines and
graphic cards with dual head capabilities. A lot of machine talk across the
network as well. It might take some effort to get things back in sync, but
first things first....

Regards
John W.

[Opengc-devel] Linux builds

[John W. <ca...@mm...>]

Hi Wendell,

I've been away for a LONG while but slowly getting back into the swing =
of things

Yes, opengc will run with fg under linux but it will need some work to =
get all things back in sync

check out www.first-day.org/jpgs/ for a series of screen shots (opengc =
and fg) of an ILS approach into KSFO

Unfortunately, this version will NOT run with windows, but than can be =
worked..

Also the version is designed to run over a network of two or more =
machines. Trying to run opengc and fg on the same host just kills the =
frame rate. If you have two or more machines on a network.  the problem =
with Linux/Windows networking is how the various compilers aligned data =
types in memory. So a mix of data types like booleans, int, and double =
don't always line up on bit boundaries. there are ways to handle that

Regards
JW

[Opengc-devel] Need a hand?

[Chris A. <chr...@mi...>]

Hi there!

I think you have a great system here, and I LOVE it!!!!

I've just finished testing it in my homebuilt cockpit, and it fits the bill
better than other offerings - including Magenta.

If you need a hand, I'd like to contribute.  I'm not a programmer, but I am
what I consider an advanced user.  By day, a mild mannered MIS manager, by
night, a swashbuckling flight-sim enthusiast.

I'll be happy to help anywhere I fit.

Let me know how I can help.

Thanks again,

Chris

Re: [Opengc-devel] Linux as host?

[Damion S. <be...@cs...>]

> Ok, I suppose it uses the regular cmds:
>   aclocal
>   automake
>   autoconf
>   ./configure

No, it uses CMake, available from http://www.cmake.org

You can find a brief rundown of the build process at:

http://www.opengc.org/developers/build.html

The version listed for FTGL on that page is incorrect - you need FTGL 
2.0. You also no longer need zlib.

-Damion-

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
http://www.cs.cmu.edu/~beowulf
---------
Here's a good thing to do if you go to a party and you don't know 
anybody: First take out the garbage. Then go around and collect any 
extra garbage that people might have, like a crumpled napkin, and take 
that out too. Pretty soon people will want to meet the busy garbage guy.

Re: [Opengc-devel] Linux as host?

[Wendell T. <we...@ad...>]

> > Does OpenGC still run on Linux?

> So, you shouldn't have to do anything special to run under Linux, other 
> than build OpenGC.

Ok, I suppose it uses the regular cmds:
  aclocal
  automake
  autoconf
  ./configure

however, aclocal complains about missing files:

  aclocal: `configure.ac' or `configure.in' is required

Does the configure.* files get generated, or are they from some 
other cvs location?

Wendell

Re: [Opengc-devel] Linux as host?

[Damion S. <be...@cs...>]

> Does OpenGC still run on Linux?  There is a file in
> the Documentation directory that alludes to that, but
> the file is marked as old.  How old is the Linux
> configuration?

As far as I know, yes, it still runs under Linux. I develop under Mac 
OSX about 75% of the time, and its library setup is virtually identical 
to Linux. I marked that file as old because I rewrote the Flightgear 
interface some time ago it no longer supports the command line options 
described in that document.

> Also, the documentation states that FlightGear should
> run on a Windows machine also.  It states something
> about packet sizes is incorrect when Linux is used.
> Why is that?  What would it take to run both FlightGear
> and OpenGC to operate on a Linux host?  (Have I just
> volunteered for something?)

That issue has to do with how Linux and Windows serialize classes when 
they're passed over a network. As I understand it, they pad the object 
slightly differently, resulting in packet sizes that differ between the 
OS's. If you're running an all-Linux network or an all-Windows network 
this shouldn't be problem. I unfortunately don't have enough machines 
to test all of the different permutations.

So, you shouldn't have to do anything special to run under Linux, other 
than build OpenGC.

Cheers,
-Damion-

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
http://www.cs.cmu.edu/~beowulf
---------
Here's a good thing to do if you go to a party and you don't know 
anybody: First take out the garbage. Then go around and collect any 
extra garbage that people might have, like a crumpled napkin, and take 
that out too. Pretty soon people will want to meet the busy garbage guy.

[Opengc-devel] Linux as host?

[Wendell T. <we...@ad...>]

Does OpenGC still run on Linux?  There is a file in
the Documentation directory that alludes to that, but
the file is marked as old.  How old is the Linux
configuration?

Also, the documentation states that FlightGear should
run on a Windows machine also.  It states something
about packet sizes is incorrect when Linux is used.
Why is that?  What would it take to run both FlightGear
and OpenGC to operate on a Linux host?  (Have I just
volunteered for something?)

Wendell

[Opengc-devel] Re: no text

[Damion S. <be...@cs...>]

Hmmm, thanks for figuring that out. I could have sworn I put the right 
one in the CVS - I should change that to avoid messing anyone else up. 
I don't know if I mentioned it elsewhere, but the nav data can be 
obtained from:

http://www.x-plane.org/users/robinp/

You'll need to reorganize the directory structure a bit; the 
subdirectories specified in the archive are not needed, and all of the 
files should just be at the same level (e.g. /mystuff/navdata )

-Damion-

On Wednesday, May 21, 2003, at 04:12 PM, Daniel Nawrocki wrote:

> Fixed it - your hint on not needing that change is the key.  The 
> version of FTGL that is distributed in the CVS is not up-to-date, and 
> after downloading the latest version, everything worked fine.  Thanks 
> for your help!
>
> Dan Nawrocki

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
http://www.cs.cmu.edu/~beowulf
---------
If you drop your keys into a river of molten lava, let 'em go, because, 
man, they're gone.

[Opengc-devel] Re: Compiling openGC from respos

[Damion S. <be...@cs...>]

Ok, I'll make sure to tag more often. I'm seeing a similar error upon 
exiting OpenGC; I'm 95% sure its a bad pointer operation that occurs 
when the nav information is deleted, but I'm still tracking it down.

-Damion-

On Wednesday, May 21, 2003, at 03:34 PM, Robert Oaks wrote:

> Damion,
>
> Tagging the repository would be very helpful!!
>
> Yes, I have been able to get it to build. I am have one
> problem when exiting the program with a
> "The instruction at 0xdddddddd. The memory could not be read."
> Which is minor at thsi point.
>
> Thanks
> Robert Oaks

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
http://www.cs.cmu.edu/~beowulf
---------
If you drop your keys into a river of molten lava, let 'em go, because, 
man, they're gone.

[Opengc-devel] Re: help....looking for a glass cockpit

[Damion S. <be...@cs...>]

Hi, sounds like an interesting project...

> I have an experimental airplane and me and a friend have developed a 
> solid
> state gyro system.  What we are in need of is panels that will work 
> with it.

So, one thing I should say right off is that the OpenGC license 
specifically states that it should not be used in real aircraft, and 
that if you choose to do this you understand that it was not designed 
with airworthiness in mind. Now, that said, OpenGC is released under 
the GPL license so you are pretty much free to do what you want with 
it...

> The idea stemmed from looking at the project magenta website which is 
> where
> i got your name.  What we need to figure out is out to "feed" your 
> panels or
> Enrico's panels with our gyro information instead of it getting "fed" 
> from
> microsoft flight sim.

Ok,	based on the information you provided this would be pretty trivial. 
You just need to write a subclass of ogcDataSource that handles the 
serial communications and converts the data to the correct format; 
shouldn't be a big deal.

> The gyro we have outputs it information in roll, pitch and yaw via a 
> serial
> cable.  a gps can be hooked up and the roll, pitch and yaw string is 
> then
> alternated with the standard GPS NMEA string.  We also have a 
> magnetometer
> and airdata interface that we add to the end of the RPY string.

So this would give you: roll, pitch, yaw, lat/lon, barometric altitude, 
airspeed, and climb/descent?

What you are talking about sounds feasible, probably a weekend or two 
of work. A few considerations to keep in mind:

1) You would need a lightweight computer in your aircraft (a laptop 
would work, but couldn't be panel mounted). You could probably put 
together a mini-ATX system with a 15" flat panel monitor that would 
weigh about 10-15 pounds and could be easily mounted in the cockpit.

2) I don't know how/if FAA regulations cover experimental 
instrumentation. I would need to see documentation that this is legal 
before I'm willing to help.

Cheers,
-Damion-

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
http://www.cs.cmu.edu/~beowulf
---------
During the Middle Ages, probably one of the biggest mistakes was not 
putting on your armor because you were "just going down to the corner."

[Opengc-devel] help.....looking for glass cockpit

[Ray J. C. 3. E. <jef...@au...>]

Dear Sir,

I am located in the united states and i have been looking all over the net
for people that might be able to help me with a project that i have going
on.

I have an experimental airplane and me and a friend have developed a solid
state gyro system.  What we are in need of is panels that will work with it.

The idea stemmed from looking at the project magenta website which is where
i got your name.  What we need to figure out is out to "feed" your panels or
Enrico's panels with our gyro information instead of it getting "fed" from
microsoft flight sim.

The gyro we have outputs it information in roll, pitch and yaw via a serial
cable.  a gps can be hooked up and the roll, pitch and yaw string is then
alternated with the standard GPS NMEA string.  We also have a magnetometer
and airdata interface that we add to the end of the RPY string.

IF you have ANY information regarding this or can point us in the right
direction, we would appreciate it very much...

we are at a stopping point for simple fact that we cant find anyone to help
us make this project a reality.

Obviously we are not looking for a handout.  we are prepared to hire/retain
people for help..

Thanks again!!

Jeff Ray

Re: [Opengc-devel] nav display status

[Damion S. <be...@cs...>]

Hi,

> What I seem to remember is that the best projection was the one most
> frequently used for aviation maps.

I emailed my uncle, who is an A320 pilot for US Airways, and he is not 
sure what projection is used on the Airbus ND. He did say that the 
largest range scale on the ND is 320 NM, and that at that scale, both 
great circles and lines of constant heading appear as straight lines. 
He's sending me a photocopy of the operations manual that deals with 
the ND, so maybe I'll get the question answered from the real thing...

> BTW: for conversion routines, there's the PROJ project. This might help
> you in OpenGC

Yeah, I ran across that too. Unfortunately, the code isn't really in a 
useful form (it's heavily macro'd), so I'd have to link against yet 
another library. The gnomonic projection looks like it should be pretty 
straightforward to code.

> Some time back I looked at OpenGC and what kind of
> transformation/projection you used... this seemed to be a special local
> projection from the Netherlands, if I remember correctly. I was
> wondering why you choose that one.

I didn't, actually. A while back, two guys were working on adding ND 
code, and that was their choice. I lost contact with them and decided 
to rewrite things completely so that I understood how it worked.

> My project (X11GC) can be found at:
> http://cockpit.varxec.de/software/x11gc.html
> along with my flightgear-based cockpit contruction project:
> http://cockpit.varxec.de

Looks cool... keep in touch about the nav stuff.

Cheers,
-Damion-

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
http://www.cs.cmu.edu/~beowulf
---------
I wish I would have a real tragic love affair and get so bummed out 
that I'd just quit my job and become a bum for a few years, because I 
was thinking about doing that anyway.

Re: [Opengc-devel] nav display status

[Manuel B. <li...@va...>]

On Fri, May 09, 2003 at 08:15:23PM -0400, Damion Shelton wrote:
> Thanks for the reply,
> 
> I've been doing some reading today (I find this an interesting problem) 
> and came up with the following information:
> 
> According to http://mathworld.wolfram.com/topics/MapProjections.html 
> the Lambert conformal conic projection does not display either great 
> circles (orthodromes) or lines of constant heading (loxodromes) as 
> straight lines. Apparently, one of the few projections where 
> orthodromes are straight lines is the gnomonic projection, but it's 
> nonconformal (does not preserve small angular relationships) and 
> results in rather extreme distortion away from the center of the 
> projection.

Hmmm... I thought that lambert did show great circles as straight
lines... but its been several weeks since I looked into this.
I do remember looking at gnomonic projections, maybe I was confusing
those... I just have forgotten what I came up with thru my research.
I must have taken some notes... just have to find'em in my filesystem.

What I seem to remember is that the best projection was the one most
frequently used for aviation maps.

Once I get to the ND part of my glass cockpit software, I'll have to
come back looking at the projections.

BTW: for conversion routines, there's the PROJ project. This might help
you in OpenGC

Some time back I looked at OpenGC and what kind of
transformation/projection you used... this seemed to be a special local
projection from the Netherlands, if I remember correctly. I was
wondering why you choose that one.



My project (X11GC) can be found at:
http://cockpit.varxec.de/software/x11gc.html
along with my flightgear-based cockpit contruction project:
http://cockpit.varxec.de


Regards,
Manuel

Re: [Opengc-devel] nav display status

[Damion S. <be...@cs...>]

Thanks for the reply,

I've been doing some reading today (I find this an interesting problem) 
and came up with the following information:

According to http://mathworld.wolfram.com/topics/MapProjections.html 
the Lambert conformal conic projection does not display either great 
circles (orthodromes) or lines of constant heading (loxodromes) as 
straight lines. Apparently, one of the few projections where 
orthodromes are straight lines is the gnomonic projection, but it's 
nonconformal (does not preserve small angular relationships) and 
results in rather extreme distortion away from the center of the 
projection.

The Mercator projection plots loxodromes as straight lines. One web 
site on navigation ( 
http://www.psych.usyd.edu.au/vbb/woronora/maritime/Navigation.html ) 
indicates that a common trick is to break great circle routes into 
segments of loxodromes to make executing the route easier (to avoid 
having to steer a continuously variable heading). This trick also 
applies to navigation using airways, since they generally (always, 
perhaps? I'm not familiar enough to say) connect two nav beacons or 
intersections with a line of constant heading.

So, it seems that a consequence of displaying great circles/orthodromes 
as straight lines is an inability to plot loxodromes as straight lines. 
This would result in a route planned using airways to appear curved 
despite the lines being of constant heading. Is this the case on an 
actual ND? As I understand it, additional constraints such as ETOPS 
certification, weather, and so on often preclude the use of 
great-circle routes in any case.

Whew. I think I'm about done with math for today... this is not exactly 
light reading. Any corrections or comments are encouraged.

Cheers,
-Damion-

On Friday, May 9, 2003, at 11:09 AM, Manuel Bessler wrote:

> On Wed, May 07, 2003 at 02:38:06PM -0400, Damion Shelton wrote:
>> In any case, do any of you know how this is handled in the real world?
>> There are of course other projections available, some of which I have
>> the math for and some which I don't. On the scale that navigation
>> occurs (as distinct from flight planning) it's mostly safe to assume
>> that the world is flat, but I'd like to have a reasonably correct
>> implementation.
>
> Having done some research for my own project earlier this year,
> I believe that the projection used on current Nav Displays is a Lambert
> conformal conic projection. This also seems to be the most common
> projection used for aviation paper maps.
>
> I talked to a real world Airbus Pilot about that, and although he could
> not tell me which projection is used, he confirmed my thoughts. (eg.
> great circles are straigt lines on the ND, except some older Airbusses)
> This pointed my to believe that the above mentioned projection is what
> he stares at in his "office".
>
>
> Regards,
> Manuel

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
http://www.cs.cmu.edu/~beowulf
---------
Here's a good thing to do if you go to a party and you don't know 
anybody: First take out the garbage. Then go around and collect any 
extra garbage that people might have, like a crumpled napkin, and take 
that out too. Pretty soon people will want to meet the busy garbage guy.

Re: [Opengc-devel] nav display status

[Manuel B. <li...@va...>]

On Wed, May 07, 2003 at 02:38:06PM -0400, Damion Shelton wrote:
> In any case, do any of you know how this is handled in the real world? 
> There are of course other projections available, some of which I have 
> the math for and some which I don't. On the scale that navigation 
> occurs (as distinct from flight planning) it's mostly safe to assume 
> that the world is flat, but I'd like to have a reasonably correct 
> implementation.

Having done some research for my own project earlier this year,
I believe that the projection used on current Nav Displays is a Lambert
conformal conic projection. This also seems to be the most common
projection used for aviation paper maps.

I talked to a real world Airbus Pilot about that, and although he could
not tell me which projection is used, he confirmed my thoughts. (eg.
great circles are straigt lines on the ND, except some older Airbusses) 
This pointed my to believe that the above mentioned projection is what 
he stares at in his "office".


Regards,
Manuel

[Opengc-devel] nav display status

[Damion S. <be...@cs...>]

Hi,

A quick update as to where things are with the nav display (which has 
been a thorn in my side for quite some time)...

It works! (sort of) I made a simple test gauge that only displays VORs, 
but it is in principle fairly simple to go ahead and write readers for 
the other types of objects displayed in ND. It will likely be some time 
before a feature complete ND is available, but full "moving map" 
functionality should be approximately 2-3 weeks away. I have designed 
the framework to hopefully be relatively generic, so making a 
type-specific ND will not involve rewriting any of the fundamental nav 
code.

A few specifics:

1) I decided to go with Robin Peel's nav database, which is used by 
X-Plane and Flightgear (specifically, the X-Plane version of this 
database). It includes airports, radio nav beacons, airways, and 
intersections. He follows the DAFIF cycle, making it easy to get 
up-to-date information with minimal effort.

2) Please handle the CVS repository with care - I have been making 
fairly substantial changes, and not everything is stable just yet. As 
of last night it builds on both Mac and Windows, but you will have to 
manually edit ogcNavDatabase.cpp to point it at the right nav path - it 
will be updated to respect the nav path specified in opengc.ini in the 
near future, but there is a technical problem related to file parsing 
that needs to be sorted out. There is a bug (probably pointer related) 
that causes a segfault upon exiting OpenGC, which I still have to sort 
out.

3) The problem of mapping a spherical/ellipsoidal earth onto a flat 
plane is not trivial. The current implementation does a Mercator 
projection of the lat/lon coordinates of each geographic object and 
uses these cached values along with a real-time projection of the 
aircraft lat/lon to produce a rectangular map. This works surprisingly 
well, and is quite fast since it becomes easy to apply a visibility 
constraint during rendering and only render the objects actually 
visible on the map.

I tried flying around my home airport (KPIT) at approximately 40 
degrees north, and the Mercator distortion was minimal. The main 
advantage of a Mercator projection is of course the preservation of 
absolute heading relative to true north, but the coordinate conversion 
process renders it useless as you approach the poles. I've toyed with 
the idea of doing a local real-time mercator projection (i.e. centered 
around the current aircraft location rather than the intersection of 
the equator and prime meridian) but it's not clear to me what the 
performance hit would be versus the cached implementation currently in 
use.

In any case, do any of you know how this is handled in the real world? 
There are of course other projections available, some of which I have 
the math for and some which I don't. On the scale that navigation 
occurs (as distinct from flight planning) it's mostly safe to assume 
that the world is flat, but I'd like to have a reasonably correct 
implementation.

Cheers,
-Damion-

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
http://www.cs.cmu.edu/~beowulf
---------
If you ever crawl inside an old hollow log and go to sleep, and while 
you're in there some guys come and seal up both ends and then put it on 
a truck and take it to another city, boy, I don't know what to tell 
you.