Implementing VNAV support in FlightGear: Difference between revisions

Jump to navigation Jump to search

Implementing VNAV support in FlightGear (view source)

Revision as of 21:16, 4 December 2013

2 bytes added ,  4 December 2013
m
reorder, jsbsim section has become more detailed meanwhile
m (reorder, jsbsim section has become more detailed meanwhile)
Line 168: Line 168:
* 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)
* 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)
* a way of implementing this data into the aircraft's model(usually xml file)
== YaSim ==
{{cquote|VNAV stuff-- An interesting problem.
A large part of what the YASim solver does is pre-calculate an elevator incidence such that the aircraft can fly at "cruise" with neutral elevator and also have sufficient elevator throw to meet the "approach" criteria. Lift/weight and drag/thrust are held in static equilibrium, and the solver plays with stabilizer and elevator settings to meet the constraints. Essentially it's looking to balance pitching moments at both approach and cruise ends of the flight envelope. This is why in a YASim aircraft you do not set the elevator incidence-- the solver sets it in order to guarantee an aircraft that is more-or-less controllable.
Since the solver is essentially validating the aircraft at two predicted flight attitudes (approach/cruise), this suggests that someone could probably create similar routines to specify top-of-descent and bottom-of-descent parameters, feed in some additional constraints for wind vector, time, and desired flight economy profile, and have the revised solver return pitch and thrust requirements. Where the current solver assumes weight/lift at equilibrium, I'm going to guess it would probably iterate to find the appropriate weight/lift ratio that results in the correct altitude change over the time period. Once it finds one it returns the pitch/thrust settings used, else it aborts. It would be a messy little project, but I think it would be doable.
I would not envy anyone trying to do this. The YASim code base is, um, a bit challenging and has very little documentation.
I suspect this wouldn't work well as a run-time flight predictor, the YASim solver has to crunch a lot of numbers, but I'm guessing it could be used to build a database of profiles.
Assuming YASim elements could be hacked/revised to do this, I suspect such solutions would at best be ballpark approximations compared to the same profile flown in the actual simulator. They'd need to be verified with actual flight tests, and if someone is going to bother to properly conduct and log such tests, it makes the point of the solver a little questionable. Maybe I under-rate the possibilities or it could be refined over time, I dunno.
Also, VNAV profile data for any particular YASim aircraft would have to be re-built every time someone made a change to the YASim FDM. Seemingly minor FDM tweaks can have major YASim impacts, particularly if the developer isn't very experienced or knowledgeable with YASim. So VNAV data and the YASim aircraft FDM version would have to be tightly coupled. If someone commits a Git change to the aircraft's FDM, then the VNAV DB for that plane is hosed until it's re-calculated.<ref>{{cite web |url=http://forum.flightgear.org|title=YaSim vs. VNAV (by PM)
|author=Buckaroo |date=Mon Dec 02, 2013 9:38 pm  }}</ref>|Buckaroo}}
{{cquote|There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions.
Obviously this is chicken-and-egg, since no one can become expert enough in the  code to become a maintainer :)
So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too,
if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch.
Suggestions for that means in practice, are most welcome!
Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}
{{cquote|I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer).  Just cc: me if you do, because my
latencies here are measured in weeks.
Bugs can always be fixed.  What YASim needs is a maintainer, not really expertise per se.  The latter comes from the former.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}
<references/>


== JSBSim ==
== JSBSim ==
Line 742: Line 707:
* whether the property tree interface suffices or if some separate command interface should be used for interfacing the solver to FG
* 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 ?
* any better/alternate ideas ?
== YaSim ==
{{cquote|VNAV stuff-- An interesting problem.
A large part of what the YASim solver does is pre-calculate an elevator incidence such that the aircraft can fly at "cruise" with neutral elevator and also have sufficient elevator throw to meet the "approach" criteria. Lift/weight and drag/thrust are held in static equilibrium, and the solver plays with stabilizer and elevator settings to meet the constraints. Essentially it's looking to balance pitching moments at both approach and cruise ends of the flight envelope. This is why in a YASim aircraft you do not set the elevator incidence-- the solver sets it in order to guarantee an aircraft that is more-or-less controllable.
Since the solver is essentially validating the aircraft at two predicted flight attitudes (approach/cruise), this suggests that someone could probably create similar routines to specify top-of-descent and bottom-of-descent parameters, feed in some additional constraints for wind vector, time, and desired flight economy profile, and have the revised solver return pitch and thrust requirements. Where the current solver assumes weight/lift at equilibrium, I'm going to guess it would probably iterate to find the appropriate weight/lift ratio that results in the correct altitude change over the time period. Once it finds one it returns the pitch/thrust settings used, else it aborts. It would be a messy little project, but I think it would be doable.
I would not envy anyone trying to do this. The YASim code base is, um, a bit challenging and has very little documentation.
I suspect this wouldn't work well as a run-time flight predictor, the YASim solver has to crunch a lot of numbers, but I'm guessing it could be used to build a database of profiles.
Assuming YASim elements could be hacked/revised to do this, I suspect such solutions would at best be ballpark approximations compared to the same profile flown in the actual simulator. They'd need to be verified with actual flight tests, and if someone is going to bother to properly conduct and log such tests, it makes the point of the solver a little questionable. Maybe I under-rate the possibilities or it could be refined over time, I dunno.
Also, VNAV profile data for any particular YASim aircraft would have to be re-built every time someone made a change to the YASim FDM. Seemingly minor FDM tweaks can have major YASim impacts, particularly if the developer isn't very experienced or knowledgeable with YASim. So VNAV data and the YASim aircraft FDM version would have to be tightly coupled. If someone commits a Git change to the aircraft's FDM, then the VNAV DB for that plane is hosed until it's re-calculated.<ref>{{cite web |url=http://forum.flightgear.org|title=YaSim vs. VNAV (by PM)
|author=Buckaroo |date=Mon Dec 02, 2013 9:38 pm  }}</ref>|Buckaroo}}
{{cquote|There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions.
Obviously this is chicken-and-egg, since no one can become expert enough in the  code to become a maintainer :)
So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too,
if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch.
Suggestions for that means in practice, are most welcome!
Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=James Turner |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|James Turner}}
{{cquote|I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer).  Just cc: me if you do, because my
latencies here are measured in weeks.
Bugs can always be fixed.  What YASim needs is a maintainer, not really expertise per se.  The latter comes from the former.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23986.html
|title=YASim and documentation
|author=Andy Ross |date= Fri, 05 Oct 2012 03:54:43 -0700}}</ref>|Andy Ross}}
<references/>


== The FlightGear Interface: FGFDM ==
== The FlightGear Interface: FGFDM ==
Line 748: Line 748:


Also see: [[FDM engine feature standardization]].
Also see: [[FDM engine feature standardization]].


== Misc Resources ==
== Misc Resources ==
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/65217"

Navigation menu