Re: [Flightgear-devel] Turn ball fix & JSB notes

[Andy R. <an...@ne...>]

My responses are out of order, mostly because I wanted to quote the
debug code first.

Jon S. Berndt wrote:
> Andy Ross wrote:
> > I'm (fairly) certain that this behavior is endemic to the vUVWdot
> > calculation.
> 
> I'd really like to know more about how you saw this "feature" ;-)
> I'd like to reproduce it and try to distill what's going wrong. Your
> continued input is solicited and appreciated.

Here's the debug code I was using.  This simply prints the current
pilot acceleration out everytime the cockpit gauges are updates.  This
seems to happen once a frame, which make for a nice scrolling update,
neither too fast nor too slow.  I happen to have it here because I
started out debugging the turn coordinator, which is updated here.
(And yes, I'm sure I should be using the C++ standard library.  But I
have printf format strings in my head, and I'd have to look up how to
limit field width with iostreams).

// In FlightGear/src/Cockpit/steam.cxx
void FGSteam::_CatchUp()
{
        // Lots of real code...  Somewhere in the middle:

        FGInterface* fdm = current_aircraft.fdm_state;
        printf("Pilot Accel: %7.3f %7.3f %7.3f\n",
               fdm->get_A_X_pilot(),
               fdm->get_A_Y_pilot(),
               fdm->get_A_Z_pilot());

        // More real code...
}

> In any case, I believe the accelerations the pilot feels should be the
> acceleration of the center of the vehicle (total acceleration in local
> coords including gravity)
> [...]

Ack, no.  That's the bug!  Think about it: what's the total
acceleration in local (!) coordinates of an F15 in a 9G turn?  Well,
this second, the air is flowing directly at me at 260 knots.  It was
doing that last second too, and the next second will be the same.  So
the acceleration is zero.  Bzzt.  The acceleration is 9G, but you
can't see that in the plane's (accelerated) reference frame.  You can
ONLY see that acceleration with reference to the ground (or another
unaccelerated) reference frame.

This is not a theoretical issue, you can see it in the simulator.  Put
the debugging code in as above.  Run fgfs using the cessna.  Take off.
Pull the plane into a nice tight turn and look at the Z acceleration.
It will spike up as the plane enters the turn, and then TREND TOWARDS
ZERO.  No matter how hard you pull, you can't push the pilot into his
seat for more than a few tenths of a second.

But the rest of your point was valid:

> [...]
> *plus* w X (w X r) (acceleration due to aircraft rotation). That's off
> the top of my head, though.

Yes, the rotation term about the aircraft C.G. was already present in
the code.  I didn't move it.  This is required (at least for the cases
of big aircraft where the pilot is far from the center of gravity),
but this is not the right correction for the accelerated reference
frame.  As a gedanken experiment: what if you've JUST begun your turn
and are not yet rotating about any axis at all.  You should still be
accelerating, otherwise how would you enter the turn?  Again, it's
more easily easily demonstrated in the simulator; try it.

> Also, I am not sure what you are referring to by "ficticious force".

It's a term used in my high school physics textbook, and I've seen it
used in other contexts.  The basic idea is that Newtonian/Galileian
mechanics has a simple form*, and that's a good thing.  The problem
is, they have a simple form ONLY if the reference frame you're using
is moving with some constant velocity relative to the objects you're
modeling.

 [* F=ma, P=mv, momentum is conserved, energy is conserved -- those two
    definitions and two laws comprise ALL of Newtonian mechanics.  You
    can add "angular momentum is conserved" too, though Newton didn't
    grok that, and it's required only in the presence of quantum
    mechanics.]

If the reference frame is accelerating (like, for example, a turning
airplane), then the laws of motion become rather more complicated.
You end up having to introduce position- or velocity-dependant
accelerations to make things balanace.  These are "fictitious" forces,
since they don't obey laws like conservation of momentum.

In a software engineering sense, they also tend to break well founded
assumptions. Breaking assumptions like "the time derivative of
velocity is acceleration" (usually this is how acceleration is
defined) or "the pilot feels a force opposite the acceleration"
(i.e. Newton's third law) causes bugs.  Both those assumptions can't
be true in the plane's reference frame.

Andy

-- 
Andrew J. Ross                NextBus Information Systems
Senior Software Engineer      Emeryville, CA
an...@ne...              http://www.nextbus.com
(510)420-3126                 Why Wait?