jsbsim-devel

[Jsbsim-devel] Multi-body modeling

[Jon S. B. <jon...@co...>]

As you may know, 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.

Thoughts?

Jon

Re: [Jsbsim-devel] Multi-body modeling

[Bertrand C. <bco...@gm...>]

2011/1/5 Jon S. Berndt <jon...@co...>:
> As you may know, 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.
>
> Thoughts?
>

I guess that, as long as the bodies are not interacting, the safer and
simpler way to proceed is to use multiple instances of JSBSim.

But for the J246 example, there are alternate solutions where, instead
of a monolithic rocket, you use a set of boosters which are connected
together. These connections can be modelled by constraints between the
DOFs of each bodies. Of course, it is more complicated but more
versatile. For instance, you can use a constraint to cap the maximum
distance between 2 bodies to model a glider that is towed by an
aircraft.

Moreover there exist algorithms that can optimize the amount of
calculations for sets of bodies that are constrained together. This
would require to adapt a significant portion of JSBSim code and would
therefore be considered more like a long term goal while your
suggestion seems more likely to be applicable in the short term.

Cheers,

Bertrand.

Re: [Jsbsim-devel] Multi-body modeling

[Andreas G. <a....@we...>]

Hello everybody,

Am 05.01.2011 14:24, schrieb Jon S. Berndt:
> [...] where a state could be passed from the "core" instance, to other
> instances. 
if you mention a core instance, I can't help but think about a single
property tree maintained by the core, where each child instance keeps
its own subtree instead of having its own separate one. By allowing
access (probably read-only) to the other instance's realms, one could
eliminate the need for passing states between the instances.

Code-wise, this might possibly be realized by calling the child
instances as shared objects from the core instance, as a kind of plugin.

Having a common database available seems to be a big issue in today's
simulation industry, I remember the subject popping up various times, e.g.
http://www.aviationweek.com/aw/generic/story.jsp?id=news/awst/2010/11/29/AW_11_29_2010_p40-271623.xml&channel=defense
The standard for the CDB mentioned in the article is available here:
http://www.presagis.com/files/standards/CDB-Specification-v31.zip
(42 MB).
If JSBSim needs to support such complexity is of course something that
needs to be discussed, and CDB is quite an overshoot on the subject of
multi-body modeling. However, a common property tree sounds quite appealing.

Just talking a bit at large,

	Andreas

Re: [Jsbsim-devel] Multi-body modeling

[David C. <dav...@co...>]

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.

Dave