20,741
edits
Implementing VNAV support in FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Implementing VNAV support in FlightGear (view source)
Revision as of 08:21, 4 December 2013
, 4 December 2013→Parent & Child FDMs
| Line 550: | Line 550: | ||
the inclusion of this capability. I think Ron's suggested fix does that.</nowiki><ref>{{cite web |url=http://sourceforge.net/p/jsbsim/mailman/message/22902969/ |title=Multiple property tree problem/soution |author=Jon S. Berndt |date= 2009-06-28 14:51:29 }}</ref>|Jon S. Berndt}} | the inclusion of this capability. I think Ron's suggested fix does that.</nowiki><ref>{{cite web |url=http://sourceforge.net/p/jsbsim/mailman/message/22902969/ |title=Multiple property tree problem/soution |author=Jon S. Berndt |date= 2009-06-28 14:51:29 }}</ref>|Jon S. Berndt}} | ||
{{cquote|<nowiki> I've been interested in modeling multiple-bodies in JSBSim | |||
for some time. There are references to child model objects in the codebase, | |||
now. I've been wondering, however, if there is a better way to do this. It | |||
occurred to me that perhaps just having multiple instances of JSBSim running | |||
would work, where a state could be passed from the "core" instance, to other | |||
instances. This is not dissimilar to the way I have been considering | |||
implementing the capability, with the difference being in what object is | |||
responsible for managing the various instances of JSBSim. | |||
A reference case for such a capability is for a multistage rocket. We do | |||
have an example case that is being developed, now (the J246). However, once | |||
bodies (such as booster rockets) are dropped off they are not tracked. I | |||
simply zero out the mass of the spent boosters. However, what if instead we | |||
initialized an instance of JSBSim for each booster rocket that is dropped? | |||
The way that might work is to actually create an instance of JSBSim | |||
representing each booster rocket (or each individual piece). The initial | |||
configuration of the rocket would be done as it currently is in the J246 | |||
model, where the monolithic rocket is modeled. However, at staging, if the | |||
mass of the booster rockets is zeroed out, I envision that at that time we | |||
can initialize the "dormant" JSBSim instances that represent each booster | |||
rocket by itself at the current correct location, and let them fly free. | |||
This would, of course, require the application that manages a JSBSim | |||
instance to be set up to handle multiple JSBSim instances. However, I think | |||
this could be made to work.</nowiki><ref>{{cite web |url=http://sourceforge.net/p/jsbsim/mailman/message/26849507/ |title=Multi-body modeling|author=Jon S. Berndt |date= 2011-01-05 13:24:04 }}</ref>|Jon S. Berndt}} | |||
{{cquote|<nowiki>There was a discussion here a few years ago about setting up a "master/slave" capability for JSBSim, wherein an instance of the FDM could be slaved to some external source of position/orientation/velocity (POV). The discussion was started as a possible solution to the problem of how one models the launching of an X-15 from a mothership. | |||
The X-15 FDM, while in slaved mode, would still be iterating in order to keep a propulsion system, atmosphere, etc. running, as well as making sure that all the derived properties of the vehicle state are populated with reasonable numbers. When launched, the X-15 would start providing its own POV, hopefully without any initial transients. | |||
The external source of POV could be anything. Another instance of FGFDMExec, a fixed location for modeling a launch tower/rail, another app (i.e. FlightGear). | |||
The benefit of this over a multi-body solution is that the slaved object and master object aren't communicating over some elastic structure using forces.</nowiki><ref>{{cite web |url=http://sourceforge.net/p/jsbsim/mailman/message/26856309/|title=Multi-body modeling |author=Dave Culp|date= 2011-01-06 18:09:01 }}</ref>|Dave Culp}} | |||