FGPlot
| This article or section contains out-of-date information
Please help improve this article by updating it. There may be additional information on the talk page. |
| Tip The now mature Oscilloscope addon available from the FGAddon repository since January 2018 can be considered to be the replacement for FGPlot. |
Note Contributors wanting to use FGPlot, need to check out the topics/canvas-radar fgdata branch, using these 3 steps:
This will give you a local branch named 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 |
 | |
| 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 | https://forum.flightgear.org/viewforum.php?f=71 |
FGPlot was meant to become a built-in plotting tool to help with autopilot/FDM tuning, and other efforts that profit from native plotting capabilities.
It was being developed as a conventional XML dialog, for the time being with a <canvas> section for 2D rendering. Once PUI will be phased out, it was intended that it would be ported to use a native Canvas window instead.
To FlightGear, fgplot is just an XML file with embedded Nasal code.
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 [1]
- Fullscreen mode, see Howto:Creating fullscreen Canvas applications
- Provide support for zooming/panning
- Consider using a Nasal submodule for fgplot ?
Done (in FGPlot2) - Consider adding a time marker [2] Done
- New support for saving/loading plotting profiles with property sets Done
- Fullscreen mode, see Howto:Creating fullscreen Canvas applications
- 06/2013: kuijfe09 has finished porting his original C code to use Nasal scripting and the Canvas system Done
Feature Requests & Ideas
- Add tooltip support
Not done - Try to use widgets provided by the canvas system Not done
- Consider making min/max axis dimensions configurable based on properties (alt, speed, vs) Not done
- Consider adding support for property-profiles (name, list of properties - e.g. "FDM", "AP", "Approach (altitude vs. terrain)") Not done
- Consider supporting additional plotting modes, e.g. altitude for FDM developers Not done
- Consider generalizing the code, so that a "graph widget" can be created for all sorts of property-driven graphs 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 [3] Not done
- C++: expose cppbind hooks to access flight recorder/replay data [4] Not done
Background
|
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
|
|
|
|
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
|
|
|
|
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
|
|
|
|
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
|
|
References
- ↑ Curtis Olson (Fri, 08 Mar 2002 07:43:35 -0800). idea ... (?).
- ↑ Curtis Olson (Fri, 08 Mar 2002 07:43:35 -0800). idea ... (?).
- ↑ Curtis Olson (Fri, 08 Mar 2002 07:43:35 -0800). idea ... (?).
- ↑ Curtis Olson (Fri, 08 Mar 2002 07:43:35 -0800). idea ... (?).