FGRadar

From FlightGear wiki
Revision as of 21:19, 20 October 2012 by Hooray (talk | contribs) (→‎Design)
Jump to navigation Jump to search
FGRadar
FGRadar icon.png
Developed by Fernando García (Icecode GL)
Written in C++
OS Cross platform
Development status Active (as of 10/2012)
Development progress 20}% completed
License GNU General Public License v3
Website

FGRadar is a free, open-source, multi-platform and stand-alone air traffic control (ATC) client for FlightGear currently under development (10/2012). It makes use of the SimGear library and the Nasal scripting language.

On the scripting side, it uses the GTK+ and Cairo wrappers for Nasal in order to perform GUI rendering and drawing operations, respectively.

Status (10/2012)

Under development as of October 2012 (no public release yet):

FGRadar builds and starts up, running an SGSubsystemMgr-based main loop, the property tree and a fully working Nasal subsystem that is able to run Nasal scripts and extension functions - including the added gtk/cairo bindings.

In other words, FGRadar can already be easily augmented or implemented in scripting space using Nasal, including GTK-based GUI rendering and CAIRO-based 2D drawing. FGRadar also connects to mpserver01.flightgear.org:5001 and dumps a list of active clients to the console, at a configurable update rate.

Changes coming soon

  • Networking Support via Nasal-space SGSocket wrappers

Planned Features

  • multiplayer support by sending/recieving packages from the MP servers
  • reading shapefiles in order to create terrain maps (OpenRadar style)
  • FGCom protocol support
  • Flight Planning support (might include support in fgms too)
  • Nasal command line to execute extension functions easily without scripts

Roadmap

Milestone 1 Done Done 17.10.2012

  • Establish a multi-platform code base using CMake as the build system Done Done
  • Establish an SGSubsystem-based architecture Done Done
  • Implement Nasal Scripting support Done Done

Milestone 2 Done Done 19.10.2012

  • Implement an SGApplication framework for CLI/GLUT Done Done
  • Add a networking layer (subsystem) to get a list of fgms clients (aircraft) (ETA: 1 coding day) Done Done
  • Add a --data= parameter to specify the location of the data folder (Nasal scripts etc) Done Done

Milestone 3 Done Done 20.10.2012

  • fix the Nasal timer implementation after merge into master Done Done
  • use the --data= parameter in master
  • SGApplication: make program name configurable Done Done
  • SGApplication: make --data directory parameter configurable Done Done
  • SGApplication: make version file name configurable Done Done
  • SGApplication: add checkVersion() method Done Done


Milestone 4

  • finish the merge of the scripting branch into master 80}% completed
  • finish the SGApplication template and move stuff from FGRadarApplication/FGPanel 70}% completed
  • re-add the original FGMS/Telnet code from FGRadar for testing purposes Pending Pending

Milestone x

  • Parse the fgms response and convert it into internal data structures (callsign, lat,lon,alt etc) Pending Pending
  • Copy the fgms response to the property tree, for use by Nasal Pending Pending
  • Add FlightGear's navaid DB subsystems, so that airports, navaids, fixes etc can be accessed Pending Pending (ETA: 2 coding days)
  • Add scripting hooks (NasalPositioned) Pending Pending (ETA: 1 coding days)

Milestone x

  • Add an SG_OSGApplication framework for OSG-viewer based apps
  • Add support for the Canvas subsystem (once it's been moved to SimGear) (ETA: 1 coding week)

Contributing

Contributors are welcome to join the project. C++ Developers should ideally have some experience with:

  • C++
  • GIT
  • CMAKE
  • MULTI-PLATFORM development

In addition, a little familarity with the SimGear/FlightGear code bases is a definite plus, because FGRadar re-uses some code from those.

Note: As of 11/2012, it will also be possible for non-C++ developers to contribute to the project via Nasal scripting, because FGRadar re-uses FlightGear's scripting subsystem. So anybody familiar with Nasal scripting in FlightGear, should feel quite at home in FGRadar. In addition to many of the extension functions found in FlightGear (such as setprop/getprop etc), FGRadar also adds GTK/CAIRO bindings for powerful GUI/2D drawing support.

If someone wants to join the project, give ideas, requests or opinions, feel free to do so. The repository is here: https://gitorious.org/fgradar

To get commit privileges, please get in touch with Icecode GL via the forum or directly via gitorious.

Design

FGRadar uses a framework-centric design where the main architecture is based on a conventional SGSubsystemMgr loop that passes control to the Nasal scripting system early on.

  • Written in C++
  • Uses Doxygen for developer documentation
  • Multi-Platform support
  • Uses cmake as the build system
  • Uses Nasal based unit tests
  • favors the use of smart pointers for memory management to reduce the danger of memory leaks
  • uses the SimGear library
  • uses GTK 2.0
  • uses CAIRO
  • scripting support via Nasal
  • Implements an SGSubsystem-based main loop, to re-use existing SG/FG code
  • Uses the FlightGear/SimGear Property Tree as its internal main data structure
  • Uses the FlightGear/FGMS networking stack (based on SGSocket)

Changelog / Completed

  • cmake support Done Done
  • main loop cleanup to prepare scripting support Done Done
  • the CMAKE build system should probably be re-structured such that each source directory gets its own CMakeList? Done Done
  • implement an SGSubsystem-based main loop Done Done
  • absorb useful stuff (gtk/cairo bindings) from "Nasal standalone" into scripting module, and use SimGear's Nasal Done Done
  • implement an SGApplication framework for SGSubsystem-based CLI/GUI apps Done Done
  • start using the property-tree Done Done
  • start using the SimGear-based logging facilities (SG_LOG) Done Done
  • add a new SGSubsystem that connects to fgms and gets a list of aircraft, i.e. via http://mpserver01.flightgear.org:5001/ and SimGear's HTTPRequest Done Done
  • add a "data" folder for scripts etc (fg-root), needs to be installed via CMake Done Done
  • use simgear::ResourceManager::instance()->addBasePath(fg_root, simgear::ResourceManager::PRIORITY_DEFAULT) for data folder access Done Done


TODO (Nobody working on any of these)

  • We need to recieve chat messages too, not provided by fgms telnet.
  • refactor and generalize the scripting implementation and move it to SGScriptableApplication ?
  • apt.dat version 850 parsing (currently only 810 is supported)
  • more map projections (only the Mercator projection is available right now)
  • Improve the GTK bindings such that they can be used in multi-threaded apps, which boils down to wrapping certain gtk functions in between gdk_threads_enter() and gdk_threads_leave() calls - also glib's threads_init() will need to be called in the gtk init() function in gtklib.c [1] [2]
  • document the available gtk/cairo bindings so that contributors can get started more easily
  • support the FG performance monitor
  • add a dedicated memory management subsystem that tracks RAM usage per subsystem
  • support dynamic subsystem initialization (see FG [3] )

Known Issues

Regressions while merging the scripting branch

  • data folder support using the simgear::resourceManager (used by Nasal) Done Done
  • global property tree handle Done Done
  • use FGPanel's sleep() implementation to fix the busy loop
  • command line parsing 60}% completed

Coding

  • The current SGApplication implementation uses a "busy waiting"-loop, needs to use the FGRadarApplication/FGPanel implementation Pending Pending
  • Determine if we need to find a better solution for GTK's blocking main loop than jusing doing gtk_main_iteration_do() (threading? )Pending Pending

Build System

  • PKGLIBDIR is not being set properly via cmake yet (see FGRadarApplication.cxx)
  • The NasalSys.cxx file uses gettimeofday(), which may not be available on Windows - we need to add CMake magic to detect availability of it (already done by FG!) Pending Pending
  • The build system has only been tested on Linux so far

Data

  • we should really be using import() from driver.nas

Work in Progress

  • expose SimGear's SGSocket to Nasal via a separate Nasal ghost, so that Nasal can use sockets (Hooray) 10}% completed
  • improved cross-platform support, so that FGRadar also works on Windows 50}% completed
  • Nasal scripting support (Hooray) 80}% completed
  • re-add and port submodule support for scripting, so that multiple files can be loaded into the same namespace (Hooray) Pending Pending
  • add a SG_OSGApplication inherited from SGApplication which provides an osgviewer-based window (see $FG_SRC/utils/fgviewer/fgviewer.cxx) to support Canvas 20}% completed
  • improved Nasal GTK wrapper (port from GTK 2.0 to 3.x) Pending Pending
  • An XML configurable GUI using Gtk (glade) Pending Pending
  • merge Nasal progress from initial-scripting-support branch into master (Icecode) 70}% completed

SGApplication

  • port the FG/FGPanel Sleep() method to SGApplication, so that frame/CPU throttling can be implemented
  • enforce use of smart pointers
  • clean up subsystems properly, delete all pointers (proper ordering!)
  • use real singletons to manage resource access
  • start working on SGScriptableApplication
  • support environment variables
  • start working on config file support (~/.fgfsrc)
  • fix all compiler warnings
  • add DoxyGen comments

Canvas Integration

We may also want to take a look at osggtk and http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/examples/osgviewerGTK .

The Canvas subsystem will need something:

  • to attach its cameras to (osg::Group).
  • also, there has to be a property tree which will be used to control the canvas and also by the canvas itself to parse informations back.
  • For user interaction, and displaying windows there will be needed an osgViewer and a GUI camera (camera with orthogonal projection whose output goes to the application window/screen.
  • For initializing the Nasal support it would be good to have support for the same kind of initialization as it's currently used in the fg/Scripting files.
  • the map layers (airports, towers, runways, taxiways etc) need full navdb access, i.e. the NasalPositioned bindings

The Scripting System

The scripting system in FGRadar is largely based on FlightGear's FGNasalSys implementation, unneeded methods and extension functions are removed however - this affects mostly the scenery related features, various loading hooks (models, XML dialogs) and a handful of FlightGear-specific extension functions that depend on FlightGear systems that are not available in FGRadar (i.e. geodinfo, which requires the tile manager).

However, most general-purpose functions are also available in FGRadar, such as for example:

  • print()
  • rand(), srand(), abort()
  • cmdarg()
  • systime()
  • setprop()/getprop()
  • setlistener()/removelistener()

In the future, we'll probably also support the NasalPositioned extension functions from $FG_SRC/Scripting to also access navdb related information from Nasal within FGRadar. In addition, all core-language features and library functions of the Nasal language itself are obviously also supported in FGRadar (i.e. sort(), append(), contains() etc).

As of 10/2012, the Nasal scripts are loaded from a directory in $FG_RADAR/data/Nasal. The folder contains two sub directories:

  • lib - for libraries, i.e. code that doesn't run
  • app - for scripts that implement applications

Each script in any of these two folders is loaded into a namespace based on the file name - which is identical to FlightGear. However, the lib folder is processed prior to the app folder obviously.

Note that support for Nasal sub modules (where all Nasal files in a single folder are loaded into the same namespace) hasn't yet been implemented, but will soon be added to make it easier to support the Canvas scripting layer. That will probably mean another folder in data/Nasal (loaded prior to app, but after lib), namely:

  • modules

Related content