Implementing VNAV support in FlightGear: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 116: Line 116:
'''What is required to apply this method?'''
'''What is required to apply this method?'''


* data analysis to determine the scope of fields, and the domain of values for the gathered data (weight & balance, fuel, weather, temperatures, aircraft configurations)
* data analysis to determine the scope of fields, and the domain of values for the gathered data (weight & balance, fuel, weather, temperatures, aircraft configurations. *)
* an agreed standard of tests applied to all airplanes (climb/descend profiles with different configurations)
* an agreed standard of tests applied to all airplanes (climb/descend profiles with different configurations)
* an agreed format(data file structure) in which this data is formated, or using an improved database approach and provide mapping via a DBMS for a changing file structure
* an agreed format(data file structure) in which this data is formated, or using an improved database approach and provide mapping via a DBMS for a changing file structure

Revision as of 04:01, 2 December 2013

This article is a stub. You can help the wiki by expanding it.


Problem

In comparison with other flight simulators, FlightGear has been lacking support for simulating VNAV features found on many modern aircraft since day one.

So far, the general consensus has been that it simply isn't yet possible in FlightGear to properly implement VNAV because VNAV depends on having access to a performance database to provide the proper pitch/thrust changes to make certain altitude/speed constraints, which boils down to a lack of support by the FDMs (JSBsim/YaSim) actually.

As an open source project, we do not have access to the corresponding flight data or such a performance database, and even if we did, we probably couldn't easily use said data due to its proprietary nature.

In addition, a real performance database would probably not serve us too well, because our FDM configurations are custom, too - i.e. the performance database would need to match the performance of the simulated aircraft.

Thus, a performance DB would ideally be provided by the FDM itself. Either in a pre-created fashion, i.e. compiled during an offline "test fligth", or preferably at runtime by running a simulation of the FDM inside the actual FDM.

It is one of those "holy grails" in FlightGear, I am not aware of any aircraft that currently support a proper FMC/CDU "progress" page - creating the page is trivial, but making it functional requires some more work - look for threads with the keywords "performance database", and you'll see that this has been talked about for over half a decade meanwhile. (computing remaining fuel vs. fuel consumption per hour is fairly trivial, but once you want to compute range, you need to be fully aware of the flight plan (speeds, altitudes) and weather/configuration (and aircraft/engine performance in particular) to make a reasonable guess at remaining range).

So, we currently do not have any aircraft with a properly working FMS and performance database support.

Overall, airliners like the 777 in FlightGear remain among the most developed aircraft/airliners in FG, especially in comparison to hundreds of other aircraft. But compared to airliners supported by FSX or X-Plane, we are still lacking in that department and do not provide a complete solution (yet).

And it is also not foreseeable when that will change, because it will require changes in the FDMs we're using or use of some 3rd party/proprietary performance database. Otherwise, it is not currently feasible to come up with VNAV/LNAV modes that properly work for different aircraft. The 3rd party approach is being used for TPPs data, but in the case of FDMs, we would need 100% accurate FDMs, too - so it would be better to directly use the FDM for computing a performance DB. Supporting VNAV/LNAV still is tricky for other reasons, and currently not on anybody's agenda - it's not just something that can/should be tackled by a single aircraft developer, it requires lower-level changes in FlightGear's architecture and the way FDMs are used.

Objective

ticket #640

Determine how to implement the building blocks required for supporting VNAV (vertical navigation) in FlightGear:

In real aircraft, the purpose of the so called "performance database" is to reduce the need for the pilot to refer to a performance manual during flight and to provide the FMC (flight management computer) with data required to transmit pitch and thrust commands to the FCC (flight control computer. The performance database is also used by the FMC to provide detailed predictions along the entire aircraft trajectory. The data stored in the database includes accurate aircraft drag and engine model data, optimal speed data, maximum altitudes, and maximum and minimum speeds. The FMS onboard the aircraft also performs fuel consumption predictions based on a reference model: the FMS performance database. The PERF FACTOR entered in the M/CDU helps to the FMS predictions. Implementing aircraft performance monitoring aims to determine the monitored fuel factor.

The main FMS aircraft performance predictions deal with:

  • fuel consumption, time,
  • climb and descent path,
  • recommended maximum altitude, and
  • optimization of speeds and cruise altitude taking into account economic criteria

defined by the airline Cost Index.

The PDB is derived from the IFP aircraft databases. Slight simplifications were taken into account because of the limited size of the FMS memory. For example, only one air conditioning setting is available (LO/ECON as appropriate). Per design, the aircraft performance databases are stored in the FMS Perf Data Base (PDB). There is only a single PDB per family of aircraft.

Background

Cquote1.png Altitude constraints are a mess - in the short term, they are best avoided. Keep in mind the GPS code doesn't really do proper vertical navigation - it computes some data like the altitude change and climb/ descent rate for a leg, but I'm not sure if any real aircraft is driving the VNAV mode of an autopilot from it.

It's definitely something I will look at, but it's tied up with some other features. At some point I want to support GPS precision approaches and then obviously all the VNAV logic will need to be properly cleaned up - right now it's been copied mostly unchanged from the original gps code.

As always, user stories are good - what do you expect the behaviour to be from the route-manager? Just to track valid altitudes? For the autopilot VNAV to follow the altitude profile exactly? Something in between?

This is also tied up with accurate enroute time calculations and calculating top-of-climb / top-of-descent information, it's quite a mess to unpick.[1]
— James Turner
Cquote2.png
Cquote1.png VNAV doesn't really make sense right now - it's not really implemented.[2]
— ThorstenB
Cquote2.png
Cquote1.png I don't think any aircraft AP supports vertical route navigation yet - and the route-manage itself only has partial support for editing waypoint altitude. There's no real obstacle - waypoints store an altitude (and speed), and the AP can read it, but nobody spent time making it work yet. Vertical modes (VNAV) also tend to depend more on fuel/load and engine performance data from the FMS, which is an area that's been lacking in FlightGear, so hard to model the climb and descent profiles meaningfully. [3]
— Zakalawe
Cquote2.png


Cquote1.png What you need is a simplified performance model of the aircraft or, rather, a set of simplified performance models as function of your relevant variables which in your case may only be c.g. position. Once you have such a model, predicting flight paths is not difficult. The problem is getting such a model. The only way I've ever done it was totake a full-envelope aerodynamic model, a full-envelope thrust model, trim the aircraft at lots of Mach-altitude points, and derive a simple model at each point. Generally, what you want is lift-coefficient as a function of angle of attack, a drag polar model, and some simple moment coefficients so you can predict rotational effects (such as turning and turn rate). Building a program to beat the crap out of a standard model is the only sane way to approach the issue of generating performance models. Good luck.[4]
— Lee Duke
Cquote2.png
Cquote1.png I've seen the use of simple simulation within a simulation, where performance data is being calculated. It was not within JSBSim, however. This is an interesting prospect. Nobody has ever done this, up to now. My initial reaction was pessimistic. However, the flight control components within JSBSim are fairly capable, and you are permitted to define arbitrary functions. So, my guess at this time is, yes, you should be able to set up JSBSim to calculate *some* performance data. It may be a lot of work, but it should be possible. [5]
— Jon S. Berndt
Cquote2.png


Cquote1.png Without being very familiar with the FG source code, the usual way to do this is to call the FDM. Isn't that sort of thing exactly what JSBSim is for? The distinction between a flight planner and a flight simulator is the bounds on the integrations. A simulator will integrate over a frame; a flight planner much longer.[6]
— MAKG
Cquote2.png


Cquote1.png Yes, this is an interesting problem. I worked on the Shuttle Abort Flight Management project several years ago. At each second during the shuttle ascent, several simulations were run quickly to determine viable abort locations at that instant and given the vehicle configuration. It has occurred to me that a JSBSim control <system> could be created that would use a simplified approach to predicting where the aircraft would be in ten, twenty, and thirty seconds into the future, based on current velocities, rates, and accelerations. I think it's possible. It would be a good exercise for someone![7]
— Jon S. Berndt
Cquote2.png


  1. James Turner (Thu, 08 Oct 2009 15:17:18 -0700). New route manager?.
  2. ThorstenB (Sun Sep 25, 2011 9:53 am). B777-200ER VNAV.
  3. Zakalawe (Thu Oct 13, 2011 6:03 am). Getting started with Route Manager.
  4. Lee Duke (2007-03-19 17:35:10). JSBSim Issue#29: performance database/prediction.
  5. Jon S. Berndt (2008-01-07). JSBSim Issue#29: performance database/prediction.
  6. MAKG (Thu Nov 05, 2009 11:55 am). flight path trace in autopilot mode.
  7. Jon S. Berndt (Wed Nov 11, 2009 8:48 pm). flight path trace in autopilot mode.

VNAV for the 777

First part of VNAV is the control of vertical movement of the aircraft. Second and more important part of that is "to predict and optimize the vertical path. Guidance includes control of the pitch axis and control of the throttle." and the other fancy stuff it can do today to optimize the flight - but only in combination with a FMS/FMC.

The 777 and the Citation X don't even use VNAV in their simplest way, i.e. by just targeting the altitude or using FLC-mode. (We don't even have a correct FLC-Mode implemented yet!!) Even if we have a realistic FMS- it would be useless without a correct Autopilot.

To develop VNAV support, we should take the 777 as it is in the base package and has currently the best developed AP. ThorstenB has put a lot of time in it, and we have an user here who knows the real one.


References

Methods for implementing VNAV

  1. (virtual flight-testing database):

Instead of doing all this "live" inside the FDM via a reverse solver, another method would be doing virtual test flights and gathering the required flight data to come up with a virtual PerfDB, i.e. actually write test data to some form of database (eg. SQLite) so that this could be queried at runtime in FG.

What is required to apply this method?

  • data analysis to determine the scope of fields, and the domain of values for the gathered data (weight & balance, fuel, weather, temperatures, aircraft configurations. *)
  • an agreed standard of tests applied to all airplanes (climb/descend profiles with different configurations)
  • an agreed format(data file structure) in which this data is formated, or using an improved database approach and provide mapping via a DBMS for a changing file structure
  • an agreed property *list inside flightgear to hold this data (a single property won't suffice)
  • an interface for flightgear to query the data file through the DBMS (FlightGear's scripting language Nasal does have SQLite bindings, another option would be a flat text/XML file)
  • a way of implementing this data into the aircraft's model(usually xml file)

JSBSim - Open Questions

Check the JSBSim docs/website: there's a compact little example called WNS (Waypoint Navigation System), for following/making lateral waypoints. All implemented in JSBSim directly, i.e. can be run/played with standalone. It's in the end of the reference manual, example #5 - just search for "waypoint" or "WNS".

From a standalone prototyping standpoint, JSBSim doesn't seem to currently have a 777 model included, the 737 seems to be more suitable for starters, because the aircraft is available, and various scripts for test flights exist already. Otherwise, the 777 FDM from FG would need to be copied to JSBSim and made to work in standalone mode.

Some of the more interesting questions to discuss with JSBSim experts would be:

  • better prototype this in standalone mode or not ?
  • possibly use a 2nd instance for the computations of the Performance DB, or can we use the same instance ?
  • how to do systems modeling in JSBSim that involves running the same FDM inside the simulation, and parametrizing it for reverse-solving, i.e. given altitude/speed constraints for legs, to get the proper pitch/thrust settings
  • how to save the output in some form of lookup table, either in-memory or to some separate file
  • how to run reverse-solver queries against such a solver to come up with the proper pitch/throttle changes.
  • whether the property tree interface suffices or if some separate command interface should be used for interfacing the solver to FG
  • any better/alternate ideas ?

Misc Resources

Related Discussions