On 06/19/2011 06:46 AM, Jon S. Berndt wrote:

> Maybe I've gone wrong somewhere here, but something similar might work.
> Also, in situations like a flat spin or tail slide this probably falls
> apart!

Let's postpone discussion of exotic flight conditions such as flat
spins and tail slides.  There are much more prosaic situations that
need to be addressed.  Let's start by getting the aircraft to behave 
properly when 
   a) _taxiing_ with a crosswind and/or tailwind, and
   b) _landing_ and _taking off_ with a crosswind and/or tailwind,

These seem like basic and fundamental features.

As far as I can tell, none of the existing FG aircraft that use the 
JSBSim FDM behave properly under these conditions.  (FWIW the Pitts
and the Comanche use YASim).

The value of these features can hardly be exaggerated.  For example, 
according to page 4-3 of the POH the "maximum demonstrated crosswind" 
for a C-172 is 15 knots.  It is important for pilots to know what 
happens if they use soft-field takeoff procedure with a 15-knot 
crosswind.  We do not want them to discover this the hard way, in a 
real airplane.  It would be extremely valuable to have a simulator 
that faithfully models the real behavior.

Et cetera.  For more perspective and motivation, see appendix below.

Returning to the technical issues:  AFAICT the most fundamental issues
are not "JSBSim" issues strictly speaking, but rather aeromatic issues.
The aeromatic output I have seen is 100% predicated on the assumption 
of small alpha and small beta.  The entire strategy of the aeromatic-
based aircraft.xml file is predicated on this.  For example:
 -- The idea that there would be "lift due to alpha" and then some
  "delta lift due to flap extension" is absurd.  Near the stall,
  extending the flaps (at constant pitch attitude, and constant
  direction of flight) will make a /negative/ contribution to the
  lift in the real airplane.  
 -- Forsooth, the whole idea of "lift due to alpha" is absurd, since the 
  lift of the real airplane depends in a nonlinear way on alpha _and beta_.  
  Specifically, for an unswept wing we expect the lift of the wing to go 
  to zero when beta is 90 degrees.  Few if any of the existing FG aircraft
  model this beta-dependence.  A faithful model of this would require 
  a major reorganization of the aircraft.xml file AFAICT.  Small changes
  will not suffice.

That leads to an other rather fundamental issue:  Let's talk about lift.

Lift is a vector.  It is defined to be perpendicular to the wind, and
perpendicular to the Y axis.  Axes are defined here:
  http://www.av8n.com/how/htm/motion.html#fig-axes

Specifically, if W is the relative wind velocity (directed toward the 
airplane, not toward the wind-source) then lift is in the direction 
W × Y.  The component of lift along the W × Y direction is positive,
for not-too-large positive alpha.
  -- Minor point:  This can be confusing to non-experts there is a 
   tailwind, since W × Y is downward in that case.
  -- This is undefined when there is a direct crosswind, since in 
   that case W × Y is zero and does not define a direction.  For an
   unswept wing it doesn't matter, since the magnitude of the lift
   of the wing is zero ... but for a swept wing this is an utterly
   nontrivial issue.

Remark:  Here is an item that is *not* on the list of fundamental issues.
I mention it just for perspective.   The last time I checked, in all
the aeromatic aircraft, the lookup tables for coefficient-of-lift versus 
alpha were defined over a severely limited domain of alpha values.  This 
is not a fundamental issue, because it is so straightforward to fix.  It
will of course need to be fixed, but it will be nowhere near sufficient.

Constructive suggestion:  According to the JSBSim manual, the "wind
axis system" (LIFT, DRAG, and SIDElift) is not the only choice; the
body axis system (X, Y, and Z) is also supported.  Alas, the last
time I checked, precisely none of the FG aircraft used the XYZ axis
system in their JSBSim configuration (aircraft.xml).

I suggest that the first step toward getting an aircraft to behave
properly during crosswind taxiing would be to convert to the XYZ
axis system.

  I am quite aware that this conversion requires a large investment
  per aircraft.  However, AFAICT the investment will pay for itself
  very soon.  I for one am not interested in re-arranging the deck
  chairs on the Titanic, and I am not interested in making minor
  tweaks on an aircraft.xml file that is mathematically unsound.

Another constructive suggestion:  While we are reorganizing the
aircraft.xml file, we should get rid of the notion of "lift due to 
alpha" et cetera.  I suggest a more faithful model would work with 
things like "force due to wing" and "force due to elevator".  As a 
first step, compatible with the existing approach, we can treat the 
wing as a whole.  Then, later, as a second step we can model the 
wing in four parts:  port outboard (with aileron), port inboard (with
flap), starboard inboard (with flap), and starboard outboard (with
aileron).  This is AFAICT the only reasonable way to model the effect
of flaps near the stall, the effect of flaps in inverted flight, the 
loss of aileron authority near the stall, et cetera.  It is also the
only reasonable way AFAICT to model swept wings.

  I remark that these two suggestions play nicely together.  The
  cost of doing them together is much less than 2x the cost of
  either one separately.

************************

I have already gone a fair ways down this road with the C172 and C182
models.  The results are already waaay better than the "stock" FG models.
You can taxi in a crosswind.  You can land and take off in a crosswind.
You can roll inverted and fly with some semblance of realism.

I would be happy to discuss the details with anybody who wants to
contribute in this area.

========================================================
Appendix : Additional perspective and motivation
========

In addition to the basic goals (a) and (b) mentioned above, we might also
consider some additional goals, including:

   c) _engine out_ (asymmetric thrust) in a twin,
         and for extra credit maybe
   d) simple _inverted flight_ ... not an inverted flat spin, just
    plain old inverted flight, such as people routinely do in a
    Cessna 150 Aerobat.
   e) The effect of propwash on trim and on elevator authority.
    This is a big deal in some aircraft, including the 152/172/182
    family.

These seem like modest goals, nowhere near as advanced as flat spins
or tail slides.


Note that when an engine fails in a twin at an inopportune moment
and the pilot uses not-quite-perfect technique, there are a lot of 
"interesting" things that can happen.  We would prefer to have the
pilots learn about this in a simulator.  It would be extremely valuable 
to have a simulator that faithfully models the real behavior.

Also:  I have experienced inverted flight in a C-172, when students
pilots performed an inadvertent snap roll (during slow-flight lessons).
The topics of inverted flight and how best to recover to upright flight
are *not* part of ordinary pilot training ... not for private pilots,
commercial pilots, or even flight instructors.  I had taken a few
aerobatics lessons, so suddenly becoming inverted was no big deal for
me ... but it could have been a much bigger deal for someone else.
Again:  It would be reeeeally valuable to be able to practice such
things in a simulator ... a simulator that provided a faithful model
of such conditions.

  Some perspective:  On a recent checkride I flew a simulator in the
  "middle" price range (purchase price = six figures).  It had truly
  terrible flight dynamics.  Even the most basic stuff was wrong, 
  such as the stability of the airspeed/pitch/AoA system during normal 
  flight.  It was much worse than anything I have ever seen from 
  FlightGear.  It was based on MS Flight Simulator plus some "value 
  added" stuff.  We had to reboot the machine four times to get it 
  properly started.  The checkride was extremely stressful, like 2
  hours of flying partial panel, only worse.  Being unable to trust
  the FDM is worse than having some unusable instruments.

  I mention this for perspective, and also because I was tempted to
  recommend that the operator replace the sim with something based 
  on FG.  Alas I am unable to make that recommendation at this time,
  because for most of the FG aircraft, the FDM is not enough better.
  FG is definitely better, but not enough.

  It would be really nice to improve FG to the point where it can
  compete in this space.  I would really like to be able to recommend
  FG for such uses.

I am quite aware that gamers outnumber pilots by a wide margin.  We
need to make some decisions:  Do we want FG to appeal to gamers only,
or do we want it to be useful to pilots also?

The small-angle approximation is epidemic in the aeromatic aircraft.
(I suspect the same goes for datcom, but I know less about that.)
The small-angle approximation is good enough for gamers, but it is
not good enough for pilots ... even in prosaic situations such as
crosswind takeoff, landing, and taxiing.

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to