Implementing VNAV support in FlightGear: Difference between revisions

Jump to navigation Jump to search

Implementing VNAV support in FlightGear (view source)

Revision as of 07:32, 4 December 2013

2,498 bytes added ,  4 December 2013
m
→‎Parent & Child FDMs
Line 491: Line 491:
As in, run an independent instance of the FDM as part of the FCS, to solve for certain VNAV constraints (altitude, speed, time) via specific pitch/thrust settings.  
As in, run an independent instance of the FDM as part of the FCS, to solve for certain VNAV constraints (altitude, speed, time) via specific pitch/thrust settings.  
Instantiating a JSBSim FDM instance is straightforward, thanks to the FGFDMExec class, which manages a single JSBSim instance:
Instantiating a JSBSim FDM instance is straightforward, thanks to the FGFDMExec class, which manages a single JSBSim instance:
<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
FGFDMExec* fdmex = new FGFDMExec(); // (1) Instantiation
FGFDMExec* fdmex = new FGFDMExec(); // (1) Instantiation
Line 515: Line 516:
{{cquote|One thing I've been playing around with (OK, _played_ around with - about a year ago) in JSBSim was the ability to add "child" objects to the main aircraft. Each child would be a separate instance of a JSBSim FDM. The idea would be to provide a way to model an aircraft with attached stores. Each store would transmit forces and moments to the parent aircraft (for example a Mirage) until it was released, at which time the FDM for that child object (for example a Mk-82 or AIM-9) would start integrating and do its own flyout - the parent aircraft now free of the effects of the store. Additionally, each store would have its own config file - and its own flight control system/autopilot/guidance. In theory, the possibilities are limitless for game playing, where one might <PC> set up a food drop tank to be released from an aircraft and make a mid-air "connection" to another aircraft, mid-flight</PC>, or <PC> a water delivery tank could be guided by homing device to a precision landing extremely close to a hostile anti-aircraft battery or needy family (in some cases these are coincident)</PC>. I've been threatening to complete this for a long time, but one day we'll allwake up and I'll announce that it is finished. <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18114.html |title=Multiplayer Server RFC  |author=Jon S. Berndt |date=Wed, 05 Nov 2003 13:01:44 -0800}}</ref>|Jon S. Berndt}}
{{cquote|One thing I've been playing around with (OK, _played_ around with - about a year ago) in JSBSim was the ability to add "child" objects to the main aircraft. Each child would be a separate instance of a JSBSim FDM. The idea would be to provide a way to model an aircraft with attached stores. Each store would transmit forces and moments to the parent aircraft (for example a Mirage) until it was released, at which time the FDM for that child object (for example a Mk-82 or AIM-9) would start integrating and do its own flyout - the parent aircraft now free of the effects of the store. Additionally, each store would have its own config file - and its own flight control system/autopilot/guidance. In theory, the possibilities are limitless for game playing, where one might <PC> set up a food drop tank to be released from an aircraft and make a mid-air "connection" to another aircraft, mid-flight</PC>, or <PC> a water delivery tank could be guided by homing device to a precision landing extremely close to a hostile anti-aircraft battery or needy family (in some cases these are coincident)</PC>. I've been threatening to complete this for a long time, but one day we'll allwake up and I'll announce that it is finished. <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18114.html |title=Multiplayer Server RFC  |author=Jon S. Berndt |date=Wed, 05 Nov 2003 13:01:44 -0800}}</ref>|Jon S. Berndt}}


{{cquote|It has long been my hope to develop the "child" modeling capability that currently has "stubs" set up in JSBSim. The idea is that a <child> element
within a "master" aircraft config file would cause the instantiation and loading of an FGFDMExec instance that is controlled by the master FGFDMExec
instance. The child vehicle would update its state vector (location, orientation, velocity, attitude rates) based on the master (parent) vehicle.
The child vehicle would be placed at a known location that relates the Vehicle Reference Point (VRP) of the parent and child vehicles. But, there
are a lot of details that would need to be worked out for this to work. I think Dave is proposing something different than the multi-body sim
capability that I am describing.
For all cases, though, there does need to be a way to set the state vector for a given vehicle. That would have to include setting past values, as
well. Then there's the question of how you detach a child vehicle. And lots of other questions.<ref>{{cite web |url=http://sourceforge.net/p/jsbsim/mailman/message/24286794/ |title=Slaved FDM  |author=Jon S. Berndt |date=2010-01-02 05:54:58 }}</ref>|Jon S. Berndt}}
{{cquote|IAny time a multiple FDM would be used, the child FDMs would be "resident" for the entire run that the parent was in existence. Child FDMs will not ever be removed and additional ones added during a run. It is possible that a child FDM may cease integrating, but child FDMs are inherent and inseparable characteristics of a parent/child flight model.<ref>{{cite web |url=http://sourceforge.net/p/jsbsim/mailman/message/22902959/ |title=Multiple property tree problem/soution  |author=Jon S. Berndt |date= 2009-06-27 18:52:11 }}</ref>|Jon S. Berndt}}




Line 524: Line 537:
However, we can look at the corresponding code in order to learn how to instantiate an '''FGFDMExec''' instance as part of '''FCS''' system/channel in order to run an identical FDM instance in look-ahead mode, see $JSBSIM_SRC/FGFDMExec.cpp: '''bool FGFDMExec::ReadChild(Element* el)'''
However, we can look at the corresponding code in order to learn how to instantiate an '''FGFDMExec''' instance as part of '''FCS''' system/channel in order to run an identical FDM instance in look-ahead mode, see $JSBSIM_SRC/FGFDMExec.cpp: '''bool FGFDMExec::ReadChild(Element* el)'''


Instantiating a JSBSim FDM instance is straightforward, thanks to the FGFDMExec class, which manages a single JSBSim instance:
 
<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
bool FGFDMExec::ReadChild(Element* el)
bool FGFDMExec::ReadChild(Element* el)
Line 576: Line 589:
</syntaxhighlight>
</syntaxhighlight>


Now, as can be seen, this method is currently specific to the use-cases discussed originally on the JSBSim/FlightGear-Devel  mailing lists, so it cannot be directly used "as-is" for VNAV purposes, but needs to be slightly modified, or rather, re-implemented with the following requirements in mind:
* add a new FCS component that instantiates a child FDM
* prevent the sub-FDM instance from recursively instantiating additional instances
* use the same FDM, but don't slave it to the parent FDM as an attached object
* instead, allow the child FDM to run independently
* allow input parameters to be specified for typical VNAV constraints
** origin-waypoint (lat, lon, alt, speeds, time)
** target-waypoint (lat, lon, alt, speeds, time)
** only modify pitch/thrust settings to make those constraints
** if successful, return pitch/thrust settings for the specified VNAV leg


=== Open Questions ===
=== Open Questions ===
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/65198"

Navigation menu