Those are complex issues about disengaging autopilot. Your
helped me to understand why the FG aircraft sometimes does gyrations when
the VOR NAV setting Ctrl-N. I'll try setting the controls to neutral
before hitting Ctrl-N
----- Original Message -----
Sent: Saturday, June 30, 2007 12:15
Subject: Re: [Flightgear-devel] [off
list] patch forcontrol lockingbyautopilot
On 06/30/2007 09:52 AM, firstname.lastname@example.org
> An airliner some years ago crashed into the Everglades in
> because the autopilot
> was unknowingly disengaged by
accidental knee pressure on the Yoke as
> the pilot
> was getting
out of his seat. Specs showed that the minimum 45 pounds
pressure required was faulty.
> The aircraft had been in
a holding pattern pending confirmation that the
> gear was down, since
> indicator lamp was burned out and the spare broke upon attempted
> from its recessed
> location. Unknowingly the
aircraft was slowly descending and the last
> thing on the
> recorder ws the co-pilot "Hey, there's something wrong with the
> instruments" when he
> noticed the altimeter showed just above
> If I understand the FG issue correctly,
then I would think that a sudden
> movement of
> the Yoke could
be used to disengage the autopilot.
This is a tricky issue.
case that has to be considered is what happens when you
are /engaging/ the
autopilot. In particular, suppose you
are in a long-winged glider in
a steep turn, holding
tons of outside aileron to compensate for the
tendency. You engage the autopilot, desiring that
will maintain the turn. Then
-- in the real aircraft,
you let go of the yoke and
it stays where it is. No
-- in FG, you let go of the yoke and it springs
to the center. That's a problem.
other side of the same coin, suppose you want to
disengage the autopilot
while the ailerons are deflected.
You really ought to deflect the joystick
so that it matches
what the autopilot is doing with the yoke, before
the autopilot disengage button.
Similar considerations apply
to the pitch axis and yaw axis.
Keep in mind the pilot who inadvertently
snap-rolled a 747,
seriously injuring a couple of passengers, by
autopilot without noticing that the autopilot was holding
of the rudder pedals to the floor.
and references therein.
Note that there are four stages of
sophistication among FG users:
a) Using the keyboard for primary
b) Using the mouse for primary flight
c) Using a plain old joystick for primary flight control;
d) Using a joystick with force-feedback (or position
for primary flight control.
It is slightly
peculiar that the problem is only serious in
stage (c). It does not
arise in stage (b) because we can warp
the mouse to the desired
position; we let the user deal with
the side effects of such
Arguably the theoretically-ideal solution would be for
to skip stage (c) and go directly to fully
joysticks ... but that is not likely to happen anytime
so for now we are still facing nontrivial problems at stage
Note that the problems are compounded by the fact that the
user does not know what to expect ... and indeed doesn't
understand what he's seeing when a war breaks out between
autopilot and the joystick. It just looks like something
broken. Disabling the joystick when the autopilot is
ends the war, but doesn't really solve the user's problem;
just sees it as a different kind of brokenness.
idea I've been toying with involves animating a
/hand/ which is normally
gripping the yoke. The joystick moves
the hand. When the
autopilot is engaged, the joystick still moves
the hand, but the hand is
not gripping the yoke. I'm not sure
how hard this would be to
implement. In any case, it has some
conceptual value, providing a way
to visualize the nature of the
problem, to some extent.
This is an
important topic to be discussing. Some of the recent
commendable steps in the right direction, but I
reckon we are still one
breakthrough removed from a complete
solution to the
SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE
version of DB2 express and take
control of your XML. No limits. Just data.
Click to get it now.