How to access navigation data in FlightGear ?

[JabX]

Hello there,

I'm currently trying to develop some external applications to display a PFD and a ND in separate windows. I am coding in Python if you ask but that's not the point of my question.
I managed to get a working PFD with use of the generic protocol and access to the Property Tree, but i am wondering how I could access the FG navigation database to display airports, waypoints, VORs, etc. nearby the aircraft. I searched the forum and the wiki to no avail, and looking into MFD/ND XML files of existing aircrafts didn't help me too.

Thanks a lot for your incoming answers

[Hooray]

Hi & welcome,

FlightGear has built-in scripting language that also supports modern functional/OOP paradigms, to learn more see: http://wiki.flightgear.org/Nasal

The native FlightGear scripting language also has bindings to internal FlightGear data structures and subsystems, including access to the navigation database, for details see: http://wiki.flightgear.org/List_of_Nasa ... ct_Queries

To do this in python, you would either have to expose the C++ code to Python, or reuse code from python-based FG side projects (such as python GUI launchers for FG).

Finally, all the nav data is just plain text - encompressed as tgz file, see $FG_ROOT/Navaids - so you can directly access everything from Python and manually parse the data there - I would however suggest to either look at existing Python code doing similar stuff, or simply use FG scripting directly.

The NavDB is implemented as a dedicated subsystem in FG, which is accessible to other C++ system at runtime - which is how the scripting bindings work.

In FlightGear things are a little more sophisticated and efficient meanwhile, because we are using a SQLite-based navdata cache for all the plain text data that supports spatial queries. By using FlightGear scripting via Nasal, you'll get all that "for free".

Also, note that there are a bunch of people interested in also supporting scripting via Python, ideally using HLA: http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture)

For scripting PFD/NDs or _ANY_ other other modern avionics, there's also a dedicated subsystem in FlightGear, called the Canvas: http://wiki.flightgear.org/Canvas

This is a fully scriptable, 100% hardware-accelerated offscreen rendering target to implement arbitrary stuff (instruments, avionics, HUDs, widgets, GUIs etc). Here's an EICAS demo implemented using just FlightGear scripting + the canvas system:

And here's a CDU implemented using Nasal and the Canvas:

Personally, I'd suggest to use our built-in Canvas system in combination with Nasal scripting, we already have a standalone "FGPanel" client that renders instruments in a separate program, for distributed multi-machine master/slave setups: http://wiki.flightgear.org/FGPanel

By using a Nasal/Canvas-based framework, you can also easily reuse existing instruments/textures available in FlightGear (ADF, RMI, HSI etc), including various 2D instruments - it's just a matter of some scripting.

And there's already been talk about eventually also supporting this for canvas-based avionics: http://wiki.flightgear.org/FGCanvas

Note that FGPanel is fairly limited feature-wise, it doesn't support any of the hard-coded displays (TCAS, AGRADAR, WXRADAR, NavDisplay) or other owner-drawn gauges, it's stricly for static textures animated through properties.

If you should be interested in pursuing the "native" canvas/scripting route, I'd suggest to check out this related discussion:

viewtopic.php?f=71&t=20401
viewtopic.php?f=71&t=20402#p186882
viewtopic.php?f=71&t=20402#p186886

[JabX]

Wow, thank you for such a quick and detailed reply !

Well, I really thought about what I should use to develop my apps, and the fact that FGCanvas isn't out yet and the existence of very nice APIs for Python (like Kivy) made me choose the latter. But definitely you've done an amazing job on Canvas.

So maybe I could do some scripting directly in FG with Nasal to get the data from the navdata cache, and then sending it over to my external program over the network interface ? Is there somewhere some tutorial which explains how to make those spacial queries ? I guess the wiki explains how to do the rest.

[Hooray]

definitely you've done an amazing job on Canvas.

Agreed: TheTom is the single/primary developer behind the Canvas system, thanks Tom!

the fact that FGCanvas isn't out yet

Once you check out the FGCanvas wiki article, you'll see that FGCanvas basically is already out, because it is going to be just FlightGear, i.e. FlightGear in a different startup mode, to disable unneeded subsystems and features. FGPanel is great, but it's a separate code base, and as such needs to be maintained separately, it also isn't as flexible - and cannot be scripted or used for glass avionics, or any of the existing hardcoded displays.

At the moment, there are a handful systems/features in FG that need to be disabled manually, and others that cannot be disabled at all. Which is why you'll either need a fairly powerful computer, or use a workaround, such as the one described at: http://wiki.flightgear.org/FGCanvas#Workarounds

That will give you a second FlightGear instance which has most features disabled, while only showing a single canvas main window, which can in turn be used to show existing 2D instruments or custom avionics.

Setting up master/slave setups by using multiple instances is well-documented, see: http://wiki.flightgear.org/Property_Tre ... ol_Slaving
You would then use the XML-configurable generic protocol to exchange relevant properties and sync them.

So maybe I could do some scripting directly in FG with Nasal to get the data from the navdata cache, and then sending it over to my external program over the network interface ? Is there somewhere some tutorial which explains how to make those spacial queries ? I guess the wiki explains how to do the rest.

We do not currently have a dedicated interface for exchanging internal data structures like the navdb, terrain data or images/video streams. However, something like that would be generally useful for a whole number of purposes and projects, so please feel free to leave a feature request at the tracker:
http://flightgear-bugs.googlecode.com/

In the meantime, there are several options:

• build a custom binary that exposes fgcommands to access such data through the telnet/props interface or simply add new telnet commands (C++/rebuild required)
• Nasal/XML: you could also just set up a Nasal script that register a listener to implement a simple command interface on to of the property tree and then use the generic protocol to talk to FG, where a listener would be invoked that handles your python request and returns the data to the script - this could be also done in combination with the telnet system.
• Python only: simply read the navcache directly via Python's SQLite bindings

Overall, I'd still suggest to use a conventional fgfs instance, manually set up for "FGCanvas" mode, and then use the Nasal/Canvas framework.

I am saying that, because we've seen about 6 different side projects implementing custom external glass cockpits for FlightGear, including OpenGC, fggc etc - so tons of projects were started over time, and reached varying degrees of maturity - but we could NEVER reuse anything, and they ALWAYS ended up being abandoned after a while. Which is exactly the reason why the native Nasal/Canvas is superior: stuff will be specifically written FOR FG, and it can be reused and maintained by others, too - in fact, you could even clone fgdata and develop your custom standalone PFD there, as a Nasal submodule that simply renders a fullscreen canvas in fgfs.

[Stiglr]

Just thinking out loud here, but...

Hooray: y'think maybe the fact it took so much verbiage to explain all these different programs, subsystems, routines etc. just for this cockpit concept points up one of FlightGear's biggest PROBLEMS: the fact that it's overly complicated, lacks a single design or even feature set, defies any semblance of cohesion, daunts and confuses would-be contributors with equal severity, and thus produces a wide range of results quality from "embarassing" to "ready-for-commercial-release"?

[Hooray]

Actually, the OP mentioned that he is a programmer (python), thus my response was definitely not for the layman - it was intended to be full of technical information and facts that people without a programming background would not understand. The OP will agree that the amount/density of information was more than he expected - but that isn't a problem at all, it's a good thing for people looking for this type of knowledge/expertise.

Usually, people would not receive any responses at all, or very little information included - sort of a like challenge to do lots of research, I decided to provide lots of pointers to present the options, as I see them.
Most developers familiar with the mailing list will agree that not even the devel list will provide this degree and density of information.

I don't see there's anything wrong with FG providing options - many of the features/options we have came into existence at different times, with different needs and requirements in mind. It is often only by accident that they start overlapping, sort of like various FDMs, scripting solutions, interfacing options or weather simulations.

Admittedly, it's far from cohesive, but there's really nothing that we can do about it: It would require a coordinated effort, not just people telling others what to do, but others willing to listen.
The T4T/combat support situation isn't any different: we have flug's bombable addon as the most sophisticated option available in FG, and then we have various more or less "competitive" approaches, including T4T - yet most folks are not actively seeking collaboration, and doing very little to unify different concepts and approaches. Instead, the focus is often on differences rather than shared needs and common goals.

Which is part of the reason why we have so many "unfinished" aircraft in comparison to other simulators. But like I said, there's really nothing that we, as a project, can do about it - short of adopting a commercial development model and a corresponding hierarchy.

Absent that, we'll have to continue embracing the "Darwinian's development philosophy", where everybody is free to contribute in whatever form they see fit, and it will be up to time to decide which features are going to stay, and which are going to be ripped out eventually.

All of us have real life obligations, and very few of us are willing to accept additional duties/deadlines, no matter if it's aircraft development, core development, texturing, scenery work, wiki administration, forum administration or other "duties" - still, all this needs to be done by someone.

Thus, it's those who roll up their own sleeves and spend their time contributing who get to influence the way FG development is heading, no matter if others agree or not - the only "hard currency" that counts in this project is time, i.e. the amount of time you have to contribute to the project

Which is also the reason why we are seeing some really skilled and experienced contributors (with very little time on their hands...) being increasingly fed up with the way FG development is going recently, simply because there are quite a number of guys who may not be as experienced or skilled (i.e. not holding multiple CS degrees), but who may be able to spend more time contributing to the project in a different form, which -at least in part- also explains the sheer rate of growth of Nasal scripting in FlightGear, especially in comparison to relatively little new C++ code being committed to the core repository (the canvas system being the obvious exception here, but ironically the Canvas system additionally fosters scripting adoption even further, because base package developers can suddenly contribute in areas that were previously reserved for C++ developers only, such as the GUI, avionics and other fancy stuff).

Honestly, we do have various accomplished core developers who do not particularly like the way Nasal is increasingly used, or the way the Canvas system is becoming a viable alternative over some hardcoded solutions - likewise, the weather system being 95% scripted is another annoyance to some - but at the end of the day, it's really just software evolution taking place: We have a decreasing number of experienced C++ developers, more and more becoming increasingly inactive - which is why the base package has been seeing so much development in comparison, and under these circumstances it is only natural for some core developers to recognize these issues and focus on providing building blocks and infrastructure to empower base package developers.

It's not that your assessment is totally off, but we cannot really deal with it, unless we are telling people what to do - and as you may have witnessed before, that doesn't work out too well usually (remember the various T4T discussions). Thus, we need to accept what's brought to the table, no matter how inconsistent it is, and "absorb" it until something better comes along - even though that may mean that we'll end up with various different approaches in the meantime.

Overall, the current situation isn't as bad as it used to be once

Stiglr: I suggest to briefly take a look at the following posting to see what I am referring to: viewtopic.php?f=42&t=15267

PS: My original response to the OP may have been sizable, but it was also biased, as you may have noticed: I was specifically trying to convince the OP that he should drop his current approach and reconsider the options that I have presented, in other words: I was trying to get him on the "right" track (which I reason IS Nasal scripting and the Canvas system), to increase consistency and code reuse - but as you can see, people are usually pretty set on having their own ideas followed through, regardless of the approach - which is also why we've had so many different "standalone cockpit" programs over time - people will not listen (and, I also wouldn't listen right away probably, but I'd at least argue that I am informed, and willing to make my case)

[JabX]

Python only: simply read the navcache directly via Python's SQLite bindings

That's basically what i am looking for, but i can't find any information about how to perform these bindings and what queries I should write. Do you know where to look ?

And if I were only developing for FG I would have chosen the Canvas method, but I am part of a bigger project that isn't just about FG and I have some external constrains that are driving me out the native development.

Just thinking out loud here, but...

Hooray: y'think maybe the fact it took so much verbiage to explain all these different programs, subsystems, routines etc. just for this cockpit concept points up one of FlightGear's biggest PROBLEMS: the fact that it's overly complicated, lacks a single design or even feature set, defies any semblance of cohesion, daunts and confuses would-be contributors with equal severity, and thus produces a wide range of results quality from "embarassing" to "ready-for-commercial-release"?

Actually there is today one good solution to do cockpit instruments and panels : Canvas, as he described it to me. I knew right about it and I wouldn't have asked here if that were the solution to my particular problem. The wiki is fairly enthusiast about Canvas too

What is really needed IMO is a clean-up of the wiki, or at least proper indexing. There's plenty of solutuons to do everything in FlightGear but most of the time only one of them (or two maybe) is (are) the one to go, and it's not that apparent because it is lost in the middle of all solutions described in the wiki. I took a hell of a long time to understand that generic protocol was the way to go for my needs of interfacing for instance.


(I know that these questions are crucial and interesting, especially for FG core devs, but let's not forget my inital question please )

[zakalawe]

I would strong prefer you don't read the navcache directly, it is not a supported or published API. It could, and has, changed between versions as it's still relatively new code. Also to query it efficiently needs code on the C++ side.

Of course I can't stop you reading the file, I just don't want to deal with complaints in six months time when I change the schema

[JabX]

I'm not specially keen on hardcoding some queries directly on the file (like you said), but couldn't I undirectedly get it via some Nasal script ? And then handle the communication with my external app with any network protocol ?

[Hooray]

you could, see my previous response: Basically, you'll add a command interface by using a Nasal script that watches a property that you make up - such as /navdb/request, and then you'll send commands to FG by setting that property, such as "GET VORS IN RANGE 50" (or something similar, but less verbose) - your Nasal script would pick up the request, parse it, and then use the internal NasalPositioned APIs to get all VORs in 50 nm range - and then populate the property tree accordingly, subsequently you would be able to to read out the results through the property tree - for example, by using the telnet/props method that I linked to earlier. This particular method should be more robust, and more high-level, than directly accessing the navcache SQLite DB.

[JabX]

Is the NasalPositioned API documented somewhere ? I searched the wiki but didn't find anything else than a mention.
But that's exactly what I wanted, thank you very much for your time !

[Hooray]

Is the NasalPositioned API documented somewhere ? I searched the wiki but didn't find anything else than a mention.
But that's exactly what I wanted, thank you very much for your time !

Well, you must have been really overwhelmed by the sheer size of my response ....
See my first response, and in fact the 3 first lines:

Hi & welcome,

FlightGear has built-in scripting language that also supports modern functional/OOP paradigms, to learn more see: http://wiki.flightgear.org/Nasal

The native FlightGear scripting language also has bindings to internal FlightGear data structures and subsystems, including access to the navigation database, for details see: http://wiki.flightgear.org/List_of_Nasa ... ct_Queries

We don't have a dedicated interface for creating fully custom protocols from Nasal, so you probably will want to use the telnet interface.

Note that I'd suggest to support versioning in your wrappers, and to use a Nasal submodule to implement the whole thing: http://wiki.flightgear.org/Creating_new ... ub_modules - the requested version of your APIs ("command interface") should be part of every request, something like VER:1 REQUEST:VOR RANGE:50" - that's easy to parse using just split() and substr(), but it can be eaily extended, and maintained, once you modify your interface or support more stuff - and it will allow other people to use your APIs reliably.

Also, I'd suggest to look at fgcommands/Nasal code doing similar stuff, such as the "load_xml" fgcommand (which populate a property tree branch by reading an XML file) or the xmlhttprequest fgcommand which populates a property tree branch asynchronously and sets a signal property once the process is finished, so that you can register a "finish" handler that gets called automatically (no polling needed).

[JabX]

Wow, how did I just missed that ?

Well, I guess you've helped me more than reason, I'm on my own now, thank you again.

[Hooray]

shouldn't be too difficult, use something like this as a stub to get started and fill in the various stubs with code

Code: Select all

##
# navprops submodule for $FG_ROOT/Nasal/navprops/navprop.nas
#

var request_property = '/navdb/request';

var copyNavaidToTree = func(navaid) {
  print("FIXME: need to implement copy function:", navaid.id);
}

var QUERY = {};

QUERY.NAVAIDS = func (range=50, dest) {
  var result = findNavaidsWithinRange();
  foreach(var r; results) {
   copyNavaidToTree(r);
  }
}

var VERSION = {};

VERSION['VER=1'] = {
 REQUEST: func (what, range) {
 
 },

};

##
# parse the request
#

var request_parser = func(request) {
 print("parsing request...");
 
} # end of request_parser

##
# initialize
#

var init = func() {
 var l = setlistener(request_property, request_parser);
 
} # end of init function


##
# register a submodule listener, so that the init
# callback is invoked once all files in navprops
# have been laoded

_setlistener('/nasal/navprops/loaded, init);




[Hooray]

just for the sake of completeness: a much simpler option would have been to tell the OP to simply use the new addcommand() Nasal API to register a custom fgcommand, which is implicitly available to telnet and expose the required FGPositioned data structures that way ...