2011/6/19 John Denker <j...@av8n.com>: > 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. >
John, This is funny because I was posting a comment to FlightGear bug #250 http://code.google.com/p/flightgear-bugs/issues/detail?id=250 I think it has been reported by yourself ? Anyway after some testing on FG, I commented the bug report and explained that the behaviour you observed was actually due to the P-factor calculations. Now, after having read your e-mail and Dave's bug report http://sourceforge.net/tracker/?func=detail&aid=3171743&group_id=19399&atid=119399 I decided to dive into JSBSim code and found that: src/models/propulsion/FGPropeller.cpp 227: if (P_Factor > 0.0001) { 228: alpha = fdmex->GetAuxiliary()->Getalpha(); 229: beta = fdmex->GetAuxiliary()->Getbeta(); 230: SetActingLocationY( GetLocationY() + P_Factor*alpha*Sense); 231: SetActingLocationZ( GetLocationZ() + P_Factor*beta*Sense); 232: } I came to the conclusion that this code indeed needs some improvement to be capable of handling high alpha and beta angles which, as you rightly mentioned, can occur when taxiing on ground. I also encourage everyone to read FlightGear bug #250 (link above) and to actually run the test as described in the bug report. It is very instructing. Can somebody make suggestions to modify this code and make it capable of handling tailwind on ground ? Bertrand. ------------------------------------------------------------------------------ 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
