From FlightGear wiki
Jump to: navigation, search
Started in 05/2013
Description Provide plotting support inside FlightGear using the Canvas
Contributor(s) kuifje09 (since 05/2013),
Status Under active development as of 05/2013
Topic branches:
fgdata canvas-hackers team clone (topics/fgplot)
Subforum http://forum.flightgear.org/viewforum.php?f=71
Note  Contributors wanting to use FGPlot, need to check out the topics/canvas-radar fgdata branch, using these 3 steps:
  1. git remote add canvas-hackers https://gitorious.org/fg/canvas-hackers-fgdata.git
  2. git fetch canvas-hackers
  3. git checkout --track -b fgplot canvas-hackers/topics/fgplot

This will give you a local branch named fgplot (tracking topics/fgplot), so that you can easily pull/push changes. When pulling, it makes sense to pull with --rebase. The fgplot dialog can be found in the Equipment menu. Note: The code is currently being revamped, so if you're interested in working with it, it would be better to use the latest version [1].


Provide a built-in plotting tool to help with autopilot/FDM tuning, and other efforts that profit from native plotting capabilities.

Status / Changelog

kuifje09 is now working on an updated version of FGPlot, called "FGPlot 2" which will be implemented using just Nasal scripting and the canvas subsystem, as a Nasal submodule. After 3.2, FGPlot should benefit from being turned into a Canvas Widget, so that it can be easily reused in other dialogs.

  • 07/2013: consider creating dialogs/windows dynamically [2] 50}% completed
    • fullscreen mode, see Howto:Creating fullscreen Canvas applications 50}% completed
    • provide support for zooming/panning 40}% completed
    • consider using a Nasal submodule for fgplot ? Done Done (in FGPlot2)
    • consider adding a time marker [3] Done Done
    • New support for saving/loading plotting profiles with property sets Done Done
  • 06/2013: kuijfe09 has finished porting his original C code to use Nasal scripting and the Canvas system Done Done


Feature Requests & Ideas

  • add tooltip support Not done Not done
  • try to use widgets provided by the canvas system Not done Not done
  • consider making min/max axis dimensions configurable based on properties (alt, speed, vs) Not done Not done
  • consider adding support for property-profiles (name, list of properties - e.g. "FDM", "AP", "Approach (altitude vs. terrain)") Not done Not done
  • consider supporting additional plotting modes, e.g. altitude for FDM developers Not done Not done
  • consider generalizing the code, so that a "graph widget" can be created for all sorts of property-driven graphs Not done Not done
  • C++: provide a new Nasal API to serialize a canvas texture (or better a group) to an osg::Image in $FG_HOME, so that graphs can be easily saved and shared/posted online without users having to take full screen shots and then having to manually extract the graph [4] Not done Not done
  • C++: expose cppbind hooks to access flight recorder/replay data [5] Not done Not done


FGPlot is being developed as a conventional XML dialog, for the time being with a <canvas> section for 2D rendering. Once PUI will be phased out, this will be ported to use a native canvas window instead.

To FlightGear, fgplot is just an XML file with embedded Nasal code.



Cquote1.png I was just thinking today that it might be cool to have a built in grapher for simple / quick graphing needs.

With the property system it would be trivial to pick an arbitrary property from the property tree and graph it over time -- superimposed on top of everything else.

Things get a bit trickier if you want to control scaling, how much time history get's graphed, multiple values, etc., but even graphing a single value (or maybe just two values) over time could be of some use.

I thought I'd toss this out there in case someone thought it was worth while enough to tackle.[1]
— Curtis Olson
Cquote1.png Yes, this would be no substitute for data logging and post processing, but if you know what you are looking for, I do think it could be

useful. The immediate thing that comes to my mind is this:

As a side project I'm working on integrating a 'commercial' fdm with FlightGear via a network interface. One of the things this code supports is control loading. The hardware guys are chomping on the bit wanting to know what range of values the software is going to kick out.

Something like a quick and dirty embedded graphing program would be pretty nifty.

"cout" probably works just as well, but it's not as pretty. :-) And once you had the basic graphing mechanism in place, it would be trivial to let the user specify which property(ies) to graph.

Maybe we could even hook up the GUI prop-picker to specify which values we want rather than forcing the user to type them all in.

FWIW, I think it's important for the FDM guys to frequenty fly their code in real time. In real time with visuals attached, various incorrect effects and behaviors can really jump out at you ... stuff that you'd never notice when looking through tabular data, or even a graph. Sometimes the trend is correct, but the scale or the sign is way off.

I would think that being able to fly in real time, and see some key graphical data output would be an immensly useful debugging tool.[2]
— Curtis Olson
Cquote1.png we can spend all day pointing out situations where realtime graphing wouldn't be helpful, but if there are some situations where it would be helpful, and in fact preferable to post processing, then doesn't that make it worth doing?[3]
— Curtis Olson
Cquote1.png Sure, you could use it to graph the value of any flight gear property over time ... not just FDM values. This could be useful for all sorts of stuff ... debugging panel actions, 3d model animations, environment modeling, etc.[4]
— Curtis Olson
  1. Curtis Olson (Fri, 08 Mar 2002 07:43:35 -0800). idea ... (?).
  2. Curtis Olson (Fri, 08 Mar 2002 07:43:35 -0800). idea ... (?).
  3. Curtis Olson (Fri, 08 Mar 2002 07:43:35 -0800). idea ... (?).
  4. Curtis Olson (Fri, 08 Mar 2002 07:43:35 -0800). idea ... (?).