This is something that I intended to post already weeks ago - it's likely to exceed the mysterious 1024 byte limit, though ;-)
Curtis Olson wrote:
A lot of people asked about GPS modeling which we (and FlightGear) really don't do a good job of yet.
There are few flight simulators that really fully resemble a GPS unit well ... most of them (have to) make understandable compromises ...
Compromises that FlightGear would probably also have to make, so as long as there is no 1:1 solution, it would probably mainly appeal to the gaming audience and not so much to the professional users.
I know that Roy has started to work on some gps internals, but it would be cool someday to be able to mimic in flightgear the sorts of gps units people are putting in airplanes these days ... such as the garmin 430/530.
...and then Garmin's GNS series is probably the most advanced stuff !?
Anyway, inspired by this, I contacted Garmin and talked to Bill Stone from Garmin's sales departement about different possibilities to support such an effort:
Specifically, I was having their Garmin GNS 430/530 *simulator* units in mind, which are freely available on their webpage, i.e. at:
http://www.garmin.com/software/simulators/TRAIN530.EXE
(does also work fine under Wine - what a rhmye !) :-)
Simulators like this one resemble pretty much most (if not all !) of the functionality that the real units have.
They are meant to introduce and familiarize with the GUI and usage of the actual hardware units.
The emphasis is put on the GPS units themselves of course and not so much on the flight simulator part, so there's only a very simple frontend that allows you to change things like speed, altitude etc. - not much more !
Everything else is mainly about the GPS unit itself...
...probably you're by now thinking exactly what I thought:
I figured: if they make the applications ("unit simulators") themselves
*freely available*, why not ask them what they think about making the
sources for that simulator available - in order to let projects such as
FlightGear modify them so that they can be used as simulated GPS units
WITHIN the simulator, or rather also externally, using data that's
provided by a flight simulator such as FlightGear....still with me ? :-)
However, while I was told that Garmin would *LOVE* to support such efforts, I was also told that this would currently not be an option, mainly because of two reasons:
1) "Garmin can only afford to provide resources to projects that
provide/create a direct revenue for Garmin"and
2) "the source code that is used for said simulated GNS units
has to remain *closed source*, as it shares MAJOR parts of the
source code with the original unit's software - which is also
the reason for the high fidelity of the simulated units."
I could understand these points and asked Mr. Stone to think about what would be involved in separating the current simulator's structure into two parts: the GUI frontend itself and the underlying software routines, provided by a separate binary library.
My line of thought was:
One would then be able to use a binary library based on the GNS simulators in order to resemble much of the original unit's functionality - the library would provide a generic interface that could be used by _any_ simulator.
Taking into account the enormous level of fidelity of the original GNS simulators, that one would hardly ever be able to achieve by trying to *manually* resemble such an anvanced avionic device, I thought that being able to interface with such a library would still be a real advantage - regardless of the closed source nature of the actual software...
However, I was again told that this would not be a feasible option:
...even if they were willing to provide access to the sources, because of the fact that the source code for the unit simulators is currently mainly 16-Bit and seems to run exclusively under WinDooze.
So a cross-platform port of such a library doesn't seem likely.
Personally, I would still consider it an enormous advantage if there was the possibility to use such a library - no matter, whether windows- specific, or not ...
Anyway, since I anticipated already the most likely "No" I had also directly asked them for their permission to use Garmin photographs, screenshots and extracts from the (VERY extensive) manual(s) - you can take a look into the fine manuals at:
http://www.garmin.com/products/manual.jsp?product=010-00182-11
....this for the case where FlightGear users/developers would have to try to _manually_ re-create a basic working model of the unit.
This is also where the manuals as well as the GNS 530 simulator would come in VERY handy:
Simpy because this would create a situation where not only extensive (> 200 pgs) (and illustrated) documenation is available, but also a simulator provided by the manufacturer of the actual hardware unit to familiarize potential customers with the unit's functionality and features.
So, there would definitely be plenty of resources available to actually "model" a unit for FlightGear use.
While I did mention that it would be preferable for FlightGear to get access to GPL'ed artwork, photographs etc. from Garmin - there was no response in regards to the GPL link that I provided in that eMail.
However, concering the requirement to use their graphics, they did state the following:
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
Permission to utilize photographs of Garmin's products and/or
other Garmin copyrighted material: We hereby grant permission to use those materials
provided that your materials,whether in electronic or
print form, state that Garmin Ltd. or its affiliates
owns the copyright in the material and that it is
reproduced by permission.8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
Additionally, they also asked us to include the following statement:
"Inclusion of Garmin copyrighted material in this presentation does not imply any endorsement by Garmin Ltd or its affiliates of the flight training material provided by FlightGear."
8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
...the latter probably mainly meant as a disclaimer, though.
So, while it is not the kind of success that I would have personally liked to see, it is insofar a success, as it means that anybody who would like to start such a GNS530 project for FlightGear would be allowed to use Garmin's graphics for that purpose - following the above guidelines.
(I did also explicitly ask for the permission to use screenshots of the simulated unit, as well as extracting graphics from said simulator and the manuals - they were fine with that, too !)
Garmin also maintains a media archive with high resolution graphics at:
http://www.garmin.com/pressroom/mediaGallery
With this newly obtained "freedom" ;-) I decided to give it a shot and thought about what would be involved:
My impression is/was that FlightGear's current way of implementing panels/instruments by using XML-based PropertyLists would simply not be powerful enough in order to model such an advanced instrument, (rather "device")
I think one would probably need to either add SOME [more] (programming) functionality to the XML-interface or alternatively simply use C++ directly for that purpose.
This would probably also be recommended in terms of performance !?
I am really not sure how performant FlightGear remains if there's an instrument displayed that's basically defined by using dozens and dozens of conditional layers...
Maybe someone can comment on that ?
Anyway, while I would personally prefer an external solution (i.e. non-FG-dependent) for such a device - simply also because it's too complex to be easily (AND conveniently) used/displayed on a normal cockpit panel (provided there's only one screen in use), I thought that trying out what's already possible couldn't harm at all:
Very first basic attempts using the provided graphics from Garmin showed that I would easily wound up with a instrument definition (XML) file with more than 100 kbyte in size very soon - at least while using the manual approach ... So after having played around with that for a while I decided that it would not be feasible to do everything manually.
Some things would obviously minimally need to be modified for this to work, so I looked into David's (Megginson) sources under $FG_SRC/Cockpit and modified a couple of things.
Mainly these changes were about:
- allowing layers to have their width, height and dimensions
to be dynamically retrieved through the property tree - allowing actions to be dynamically defined by using
property nodes instead of fixed values- allowing actions/hotspots to be changed at runtime
Basically, these changes allowed me to dynamically create the PropertyList for the instrument using Nasal - including the possibility to dynamically modify such values.
Additionally, the following stuff would probably come in very handy for such an undertaking:
- dynamic color specification
- basic support for shapes like circles, rectangles and lines
- additional fonts
- more advanced transformations, e.g. zoomingWhile using the XML-encoded PropertyList files is initially a bit more inconvenient (compared with the C++ approach) it would ulitmaltey also be more dynamic and could be used for other more advanced instruments - like a weather radar or Sandel's EHSI.
I remember that Harald Johnsen mentioned some time ago an idea to add basic OpenGL bindings to Nasal, so that it could be used to dynamically animate panels/instruments - I assume that such an idea would probably depend on Nasal being able to use multiple contexts or at least more advanced callbacks, my estimation is that something like this isn't going to happen anytime soon.
Hence, I would personally prefer to continue extending the current interface in the mentioned directions.
Another thing that a *lot* of people asked about was glass cockpits. John W. has done some really good work on this front for his 747 project, but it is kind of isolated and specific to his system. So this is another area where there is a lot of interest, but FG is a bit weak.
There are at least half a dozen of other glass cockpit projects, so it would probably be a good idea to collect the different projects on a list and write down what's needed to make them interface with FG.
Talking about FlightGear "todos" in general I noticed several of such things on this mailing list, mainly hidden very well in various topics.
I think as long as there is no bugZilla-pendant installed on flightgear.org it would be a good idea to either try to collect such ideas on the "contribute" page on flightgear.org or preferably even add corresponding files to FlightGear/data/Docs - something like:
README.todo
or
README.contributing
sounds reasonable to me.
A mailing list is simply not a suitable means to store such things.
The file could also contain different sections, possibly even depending on the urgency/priority of a task.
And every time someone encounters something that should be fixed or sounds like a good thing to add/revamp it should be put into said file.
That way potential contributors could also take a quick look into the file and see quickly what's needed.
In that regard a
README.bugs
would probably also be a good idea ?
---------- Boris
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
