20,741
edits
(→JSBSim) |
|||
| Line 485: | Line 485: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
== | == Instancing another FDM == | ||
The whole VNAV effort would be greatly simplified if we could directly run and query the FDM for some future point in time. This isn't directly supported by JSBSim. However, as a workaround, we could run a "simulation inside the simulation" by instantiating the JSBSim FDM recursively: | The whole VNAV effort would be greatly simplified if we could directly run and query the FDM for some future point in time. This isn't directly supported by JSBSim. However, as a workaround, we could run a "simulation inside the simulation" by instantiating the JSBSim FDM recursively: | ||
| Line 498: | Line 498: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
And as it turns out, | === Parent & Child FDMs === | ||
And as it turns out, being able to instantiate child/slave FDMs is another long-standing idea/feature request, i.e. supporting recursion in JSBSim FDMs and having multiple FDM instances per process (single-threaded). So to better understand the design of this feature and its current limitations, let's look at the original design/development discussions: | |||
{{cquote|One feature in JSBSim that I began and have not yet finished (pending other things) is a parent/child capability. You can (for instance) load a Mk82 on | {{cquote|One feature in JSBSim that I began and have not yet finished (pending other things) is a parent/child capability. You can (for instance) load a Mk82 on | ||
| Line 516: | Line 518: | ||
{{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| | {{cquote|That feature has not yet been implemented completely or tested. I started that one a long time ago, but there were aspects of it that I did not have time to explore. I still believe it will be possible to implement, but it will have to wait until after 1.0 is release (at least). | ||
Also, I'm not sure that the capability as designed is what you are looking for. It was initially conceived as a way to have a multi-component vehicle (a staged rocket, for instance, or an aircraft and mounted missiles). | |||
So, it sounds like you want to model multiple aircraft, but only one JSBSim instance? I don't know for sure how to solve your specific problem, but I wonder if JSBSim.cpp could be modified to start up several instances of FGFDMExec and manage those? Would that meet your requirement?<ref>{{cite web |url=http://sourceforge.net/p/jsbsim/mailman/message/19080229/ |title=Re-enabling multiple FDM's |author=Jon S. Berndt |date=2008-04-13 03:38:51 }}</ref>|Jon S. Berndt}} | |||
| Line 549: | Line 547: | ||
The challenge is to make sure that FlightGear is not adversely affected by | The challenge is to make sure that FlightGear is not adversely affected by | ||
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|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}} | |||