Re: [Flightgear-devel] JSBSim and airports

[Curtis L. O. <cu...@fl...>]

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 ...

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.
-- 
Curtis Olson   Human Factors Research Lab       FlightGear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org