Re: [Flightgear-devel] JSBSim and airports

[Tony P. <ap...@ea...>]

On Thursday 14 June 2001 15:35, you wrote:
> js...@ha... writes:
> > Unfortunately - and as David mentions - this is likely an
> > initialization problem. Tony deals with initialization, but he is
> > very busy at the moment and I don't want to bother him with this for
> > a little while. OTOH, I really need to dig into this a bit more and
> > understand it - and to some extent I have.
> > However, the code on the FlightGear side that sets up the FDM initially
> > and sets in motion the initializations (note the plural) is something I
> > have not understood, yet. I have a hunch that JSBSim gets initialized
> > properly at some point, but then is once again re-initialized
> > superfluously and
> > ambiguously and that's when things go screwy. The initialization is
> > not optimal nor is it intuitive (to me). Any help or explanation in
> > this matter would go a long ways in helping us.
>
> Tony can probably speak more clearly to this matter.  Originally the
> FDM was initialized once and only once.
>
> However, as I understand it, Tony redid the way FDM initialization
> worked in FlightGear.  Again, as I understand it, any time you force a
> value used by the FDM to change externally, flightgear re-init's the
> FDM.
>
> I believe the idea is to give the FDM a chance to do something
> meaningful if a position changes radically.
>
> For instance.  Let's say you 'instantaneously' reposition the aircraft
> 7.45 meters in the forward direction.  The FDM could assume that the
> plane just moved 7.45 meters in the last iteration 1/60th of a second
> for example.  This is equivalent to moving 1000 mph.
>
> Now what should the FDM do?  Should it proceed as if some external
> force just moved the plane @ 1000 mph and continue on with those force
> and velocity values (probably destroying the plane).  Or should it
> leave everything as is and run with the new position value.
>
> Depending on the FDM implimentation, the later might not be possible.
> In fact, jerking the FDM values around externally could cause
> undefined behavior in an FDM that doesn't expect this.
>
> So, the what Tony set up was that any time you change one of the
> externally changable FDM values (position, orientation, velocity) then
> the re-init function is called.
>
> So, to say the fdm is re-init'd superflously, is not entirely true,
> but it appears that JSBSim is not robust to being reinited with
> changed values.  That's not meant as a knock on the JSBSim code.  It
> just means that not all the pieces are playing happily together.
>
> ===================================================================
>
> Thoughts:
>
> 1. The original intent of the FlightGear interface to the FDM's was to
> allow FlightGear to interface with any arbitrary FDM code.
>
>
> 2. Perhaps what we need to do is change the interface so you have:
>
> An init() routine that is only called once with the FDM is
> instantiated.
>
> A re-init() routine that is called when we want the FDM to reset to
> some initial condition (i.e. stationary on the ground at a new
> location.)
>
> We already have a mechanism which Tony set up to externally change a
> value in a way that the FDM interface glue can do the right thing for
> the underlying FDM.  We have set_Lon() set_Lat() set_Vel() etc.
> routines which can be overridden for each FDM interface.
>
> 3. I really don't feel qualified to go in and start doing things that
> could affect the FDM's.  I can bluff my way through LaRCsim, but
> JSBSim is a different story.
>
> 4. Perhaps JSBSim should be designed so that you can:
>
>    a) instantiate it (already done)
>    b) define up some initial state (position, velocity, orientation,
>       trimmmed/not trimmed) (I think mostly already done)
>    c) reset to this new initial state. (This needs to be worked on?)
>
> 5. I see that by my reading of the code there is some odd
> confusion/confounding going on.
>
> The specific FDM interface init() routine calls the generic
> FGInterface::init() routine.  The FGInterface::init() calls the set_*
> routines would could trigger iterations of the flight model.  This
> happens though before the FDM interface init() is allowed to finish
> it's initializing.  I could see where that could cause problems.
>
> I think you are right in saying this is a mess ...

For JSBSim, most of the important init now happens in the FDM specific 
constructor, not its init method.  There was one call in FGJSBSim::init() 
that happened after the call to FGInterface::init() that really should have 
been before but all it does is set a value to its default ( effectively no 
change, it was originally put there as a place holder ), so shouldn't have 
been an issue. I've committed a change to JSBSim.cxx which moves it to the 
constructor, anyway.  The remainder of the code is all console output.

In the case of LaRCsim, the call to FGInterface::init() should probably be 
moved farther down towards the bottom of FGLaRCsim::init() as it is called 
before even the time step is set and the engine is set-up.

I think FGInterface::init() serves a purpose as the work it does serves to 
show potential new FDM developers the minimum expected from the FDM at init 
time and avoids a lot of duplication of code.  Maybe a name change is in 
order?

The other possibility, and one I find more appealling, is to simply say that 
once the FDM specific constructor completes flightgear will expect that the 
FDM is fully ready to accept a completely arbitrary (but valid) set of 
initial conditions.   This would force some code in the FDM specific init() 
upstream into its constructor (though it would really only change LaRCsim, 
JSBSim is already set-up this way.)



>
> Jon, Tony, I encourage you to step through the program logic
> carefully, I managed to do it right now.  It didn't give me warm
> fuzzies.  I think we should take a closer look at what's going on here
> and see if we can straighten things out a bit so they make more sense.
>
> Regards,
>
> Curt.

-- 
Tony Peden
ap...@ea...
We all know Linux is great ... it does infinite loops in 5 seconds. 
-- attributed to Linus Torvalds