2011/6/19 Hal V. Engel <hven...@gmail.com>: > On Saturday, June 18, 2011 08:00:41 PM Jon S. Berndt wrote: > >> > From: syd adams [mailto:adams....@gmail.com] > >> > > >> > Does jsbsim ? I've just begun to look into it , so I don't really know > >> > jsbsim's capabilities. > >> > >> It's not automatic - not a natural effect calculated by JSBSim code >> itself. > >> Like many things in JSBSim, the facilities are present to let the aircraft > >> flight model developer add these kinds of things. The contributions from > >> the tail, (such as moment due to elevator, lift due to elevator) are > >> functions of alpha and qbar. Both alpha and qbar are affected by propwash, > >> since propwash speeds up the airflow immediately behind it if it is > >> producing thrust. When defining lift or moment contributions from the > >> elevator, the alpha and qbar that are parts of that definition can be > >> modified by a function that includes the effects of propwash. So, it's > >> very configurable. You could even include the effects of beta (sideslip) > >> so the effects are blended out if beta is too high. > >> > >> Here's an example from Hal's P-51D Mustang. This is from an old version, >> so > >> it may have changed by now, but it illustrates the approach. In the > >> <aerodynamics> section of the config file - but outside of any <axis> > >> element - is this definition of qbar due to propwash: > >> > >> [Note: <v> is shorthand for "value", and <p> is shorthand for "property".] > >> > >> <function name="aero/thrust-qbar_psf"> > >> <product> > >> <v> 0.5 </v> > >> <p> atmosphere/rho-slugs_ft3 </p> > >> <pow> > >> <sum> > >> <p> velocities/u-aero-fps </p> > >> <product> > >> <p> propulsion/engine/prop-induced-velocity_fps </p> > >> <v> 2.0 </v> > >> </product> > >> </sum> > >> <v> 2.0 </v> > >> </pow> > >> </product> > >> </function> > >> > >> Later, within the pitch axis definition, is this definition: > >> > >> <function name="aero/coefficient/Cmde"> > >> <description>Pitch_moment_due_to_elevator</description> > >> <product> > >> <property>aero/thrust-qbar_psf</property> > >> <property>metrics/Sw-sqft</property> > >> <property>metrics/cbarw-ft</property> > >> <property>fcs/elevator-pos-rad</property> > >> <table> > >> <independentVar>velocities/mach</independentVar> > >> <tableData> > >> 0.0000 -0.80000 > >> 2.0000 -0.200 > >> </tableData> > >> </table> > >> </product> > >> </function> > > These were never in any of the code I worked with and were removed before I > started working on the FDM. My current Cmde function looks like this: > > <function name="aero/coefficient/Cmde"> > > <description>Pitch_moment_due_to_elevator</description> > > <product> > > <property>aero/qbar-psf</property> > > <property>metrics/Sw-sqft</property> > > <property>metrics/cbarw-ft</property> > > <property>fcs/elevator-pos-rad</property> > > <table> > > <independentVar>velocities/mach</independentVar> > > <tableData> > > 0.0000 -0.9 > > 0.66 -0.6 > > 0.74 -0.4 > > 1.0000 -0.05 > > </tableData> > > </table> > > </product> > > </function> > > This is using the qbar-psf which is not influenced by prop wash. The Cmde > function Jon has above has a lookup table that goes from MACH 0 to MACH 2 in > a linear fashion. This looks like something intended for a supersonic > aircraft and is not what I would expect from a subsonic aircraft. The table > I am using goes from MACH 0 to MACH 1 and has a strong inflection at MACH > 0.74 which is unlike the one in Jons function since it is non-linear. > > There are other interesting things in the look up table. MACH 0.66 is were > MACH drag becomes a factor for the P-51 series and MACH 0.74 is the speed at > which compressibility effects start to set in. I have not changed this > function and this is what I grabbed from the JSBSim code repository when I > started working on the P-51D. So someone, perhaps Jon, worked on this at > some point. It looks to me like this is basically correct for the P-51 since > the MACH values used are right from the NACA reports. > > The above should cause a very mild tuck at speeds above MACH 0.66 and the > tuck should get much stronger above MACH 0.74. This is sort of what happens > to the real thing at these speeds but it also porpoises above MACH 0.74. I > have a seperate compressibility function that adds more tuck and also causes > the porpoise affect above MACH 0.74 by changing the pitch moment in a > sinusoidal fashion with the frequency and strength increasing at higher MACH > numbers. All of this is writen in pure JSBSim functions with no need for > Nasal. The airframe will break up at about MACH 0.8 since the G forces from > the porpoising will cause too much negitive G. > > I also agree with Jon that JSBsim is VERY powerful and if you understand how > some force should act on the airframe you are modeling you should be able to > write a function or a set of functions that will provide those forces for > your model. But it can take a lot of effort to put these things together. > One thing that we need is for modelers to start building up example JSBSim > code for things that are not part of the default Aeromatic generated FDM so > that others can leverage that work and apply it to their modeling efforts. > > Jon thanks for the above code. I will look into integrating this into the > current P-51D. Also shouldn't the same sort of thing happen with the rudder? > > And jon do you have any ideas on how to go about wrting a function to > implement downwash pitch moment affects? > >> > >> [Note that while this function definition is named "aero/coefficient/Cmde" > >> it is not really a coefficient, but an actual moment in units of foot > >> pounds. The "coefficient" part of the name is a holdout from years past.] > >> > >> In the second code snippet you can see the "aero/thrust-qbar_psf property > >> used. > >> > >> I hope this helps a bit. >
Thank you for your detailed answers Jon and Hal. Yet my point was not to raise another JSBSim vs YASim thread. If it has interpreted like so then I apologize. My point really was about the relevance of using a second order correction (the bearing offset) when some first order contributors are neglected. By doing so, you are not increasing fidelity even if the 2nd order contributor is correct to 10E-9. This is a general rule which is applicable to YASim, JSBSim, and more generally to any modelling of real world physics. 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
