Re: [Flightgear-devel] JSBSIm, aeromatic, crosswind taxiiing, et cetera
> From: John Denker [mailto: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. John, I agree, but the comment I made was more of a disclaimer than anything. > 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. I agree, again. One problem with having a tool such as Aeromatic is that some people use it to generate the template and then don't modify it. Ideally, Aeromatic would be modified to produce better output in these circumstances. I might look into that at some point, but I'll need to find a 26 hour day lying around somewhere... ;-) > 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. There is soon going to be a donation of JSBSim code mods that *may* be useful in implementing this approach. Stay tuned. > I would be happy to discuss the details with anybody who wants to > contribute in this area. If you do a writeup for this, it would be helpful. Jon -- 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
Re: [Flightgear-devel] Nasal updating properties in the menu
On Sunday 19 June 2011 17:55:25 Hal V. Engel wrote:
> On Sunday, June 19, 2011 02:15:54 PM Ron Jensen wrote:
> > http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg302
> >08 .html gui.menuBind("radio", "dialogs.Radio.open()");
>
> Thanks I knew I saw something about this on the list but I coundn't find
> the emails that covered it. When I try to use it it fails when I click on
> the menu item.
>
> Here is my code:
>
> var radio = gui.Dialog.new("sim/gui/dialogs/SCR-522C/dialog",
>
> "Aircraft/Instruments-3d/SCR-522C/Dialogs/radios.xml");
> gui.menuBind("radio", "dialogs.radio.open()");
>
> When I select Equipment --> Radios I get the following error message in the
> console:
>
> Nasal runtime error: undefined symbol: dialogs at
> /sim/bindings/menu/bindings[35], line 1
>
> I must be doing something wrong but I don't see what it is. Can anyone
> here spot my error?
>
> Hal
In the example case you are running in the namespace "dialogs" so, in the
setfile you would have:
mynasal.nas
If you have something different, you need something different...
Assuming you load the nasal in this block:
Aircraft/p51d/Nasal/over-ride-flaps.nas
Aircraft/p51d/Nasal/stores.nas
Aircraft/p51d/Nasal/limits.nas
Aircraft/p51d/Nasal/engine-start.nas
Aircraft/p51d/Nasal/sputter.nas
Aircraft/p51d/Nasal/climbrate.nas
Aircraft/p51d/Nasal/gear-doors.nas
Aircraft/p51d/Nasal/gear-lever.nas
gui.menuBind("radio", "p51d.radio.open()");
Ron
--
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
Re: [Flightgear-devel] Nasal updating properties in the menu
On Sunday, June 19, 2011 02:15:54 PM Ron Jensen wrote:
> On Sunday 19 June 2011 15:04:11 Hal V. Engel wrote:
> > I need to over ride one of the default menu items so that I can use a
> > custom menu. After some effort I have figured out what needs to be
> > changed
> >
> > in the property tree. The code looks like this:
> > # Disable the menu item "Equipment > radio" so we use our own gui.
> >
> > gui.menuEnable("radio",0);
> >
> > # override default radio menu
> > setprop("sim/bindings/menu/binding[35]/dialog-name", "SCR-522C-radio");
> > setprop("sim/menubar/default/menu[5]/item[3]/binding/dialog-name",
> >
> > "SCR-522C-radio");
> >
> > setprop("sim/menubar/default/menu[5]/item[3"]/name", "SCR-522C-radio");
> >
> > gui.menuEnable("SCR-522C-radio",1);
> >
> > And this is working. But I am concerned that if the menus should be
> > changed (IE. items added or removed) that this would no longer be correct
> > and the code will start failing. Is that true? If so ithere a better
> > way to do this sort of thing?
> >
> > Hal
>
> http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30208
> .html gui.menuBind("radio", "dialogs.Radio.open()");
Thanks I knew I saw something about this on the list but I coundn't find the
emails that covered it. When I try to use it it fails when I click on the
menu item.
Here is my code:
var radio = gui.Dialog.new("sim/gui/dialogs/SCR-522C/dialog",
"Aircraft/Instruments-3d/SCR-522C/Dialogs/radios.xml");
gui.menuBind("radio", "dialogs.radio.open()");
When I select Equipment --> Radios I get the following error message in the
console:
Nasal runtime error: undefined sysbol: dialogs at
/sim/bindings/menu/bindings[35], line 1
I must be doing something wrong but I don't see what it is. Can anyone here
spot my error?
Hal
>
> ---
> --- 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
--
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
Re: [Flightgear-devel] Nasal updating properties in the menu
On Sun, 19 Jun 2011, Hal V. Engel wrote:
> I need to over ride one of the default menu items so that I can use a custom
> menu. After some effort I have figured out what needs to be changed in the
> property tree. The code looks like this:
>
> # Disable the menu item "Equipment > radio" so we use our own gui.
> gui.menuEnable("radio",0);
>
> # override default radio menu
> setprop("sim/bindings/menu/binding[35]/dialog-name", "SCR-522C-radio");
> setprop("sim/menubar/default/menu[5]/item[3]/binding/dialog-name",
> "SCR-522C-radio");
> setprop("sim/menubar/default/menu[5]/item[3"]/name", "SCR-522C-radio");
>
> gui.menuEnable("SCR-522C-radio",1);
>
> And this is working. But I am concerned that if the menus should be changed
> (IE. items added or removed) that this would no longer be correct and the code
> will start failing. Is that true? If so ithere a better way to do this sort
> of thing?
>
I would REALLY suggest the use of named constants instead of hard-coded
values.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
Political correctness is a doctrine, fostered by a delusional, illogical
minority, and rabidly promoted by an unscrupulous mainstream media, which
holds forth the proposition that it is entirely possible to pick up a turd
by the clean end.
--
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
Re: [Flightgear-devel] Nasal updating properties in the menu
On Sunday 19 June 2011 15:04:11 Hal V. Engel wrote:
> I need to over ride one of the default menu items so that I can use a
> custom menu. After some effort I have figured out what needs to be changed
> in the property tree. The code looks like this:
>
> # Disable the menu item "Equipment > radio" so we use our own gui.
> gui.menuEnable("radio",0);
>
> # override default radio menu
> setprop("sim/bindings/menu/binding[35]/dialog-name", "SCR-522C-radio");
> setprop("sim/menubar/default/menu[5]/item[3]/binding/dialog-name",
> "SCR-522C-radio");
> setprop("sim/menubar/default/menu[5]/item[3"]/name", "SCR-522C-radio");
>
> gui.menuEnable("SCR-522C-radio",1);
>
> And this is working. But I am concerned that if the menus should be
> changed (IE. items added or removed) that this would no longer be correct
> and the code will start failing. Is that true? If so ithere a better way
> to do this sort of thing?
>
> Hal
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30208.html
gui.menuBind("radio", "dialogs.Radio.open()");
--
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
[Flightgear-devel] Nasal updating properties in the menu
I need to over ride one of the default menu items so that I can use a custom
menu. After some effort I have figured out what needs to be changed in the
property tree. The code looks like this:
# Disable the menu item "Equipment > radio" so we use our own gui.
gui.menuEnable("radio",0);
# override default radio menu
setprop("sim/bindings/menu/binding[35]/dialog-name", "SCR-522C-radio");
setprop("sim/menubar/default/menu[5]/item[3]/binding/dialog-name",
"SCR-522C-radio");
setprop("sim/menubar/default/menu[5]/item[3"]/name", "SCR-522C-radio");
gui.menuEnable("SCR-522C-radio",1);
And this is working. But I am concerned that if the menus should be changed
(IE. items added or removed) that this would no longer be correct and the code
will start failing. Is that true? If so ithere a better way to do this sort
of thing?
Hal
--
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
Re: [Flightgear-devel] FlightGear development entered state "feature-freeze" until July, 17th 2011
Torsten Dreyer skrev 2011-06-17 21.47: > Anticipating the release 2.4.0, we reached our first milestone today. > The development streams for flightgear, simgear and fgdata on gitorious > are now declared "frozen". The above states quite clearly that testing is expected to be against the source repositories for fg source/data and simgear. There are many other 3rd party software dependencies whereof the most prominent are plib and osg. Which version of these packages should be used for 2.4.0 testing? Cheers, Jari -- 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
[Flightgear-devel] RUNNING MULTIPLE VERSIONS ON WIN32
Hi for the past few years myself and others on Windows XP have not had the convenience of running more than one version of flight-gear without a lot o jiggery pokery such as backing up configuration files swapping settings around and in many cases ended up breaking something, that's why I spent the last week writing this new batch file and it works! If someone wants to make it work on windows 7 good luck as I do not have Win7, not that I am saying it will not work it might just need a bit of extra fiddling around? It might look fairly complex but most of the batch is designed around checking to make sure the users files are not lost so first thing it does is make a backup, but it is a good idea to backup anyway just in case. In my archive I have made several version the latest one's have extra files included inside an exe file these are to aid in the smooth running of my batch file, I am currently using it myself and have made many improvements so far, and in fact not sure If I can make it much better other than SHORT HAND some of the commands but for now I need to be able to remember what each part does so have left a fair amount of clues in the variables about what does what. ftp://UNITYALLIANCE:aer010242017nama...@ortorea.dnsalias.org/FTP-Programs/flightgear-choice.zip Regards Aerotro __ This email has been scanned by Netintelligence http://www.netintelligence.com/email -- 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
Re: [Flightgear-devel] JSBSIm, aeromatic, crosswind taxiiing, et cetera
2011/6/19 John Denker : > 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
[Flightgear-devel] JSBSIm, aeromatic, crosswind taxiiing, et cetera
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
Re: [Flightgear-devel] JSBSim Functions for Propwash and Downwash [was: Clarification on YASim input]
2011/6/19 Ron Jensen : > On Saturday 18 June 2011 21:00:41 Jon S. Berndt wrote: >> 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 >> section of the config file - but outside of any >> element - is this definition of qbar due to propwash: >> >> [Note: is shorthand for "value", and is shorthand for "property".] >> >> >> >> 0.5 >> atmosphere/rho-slugs_ft3 >> >> >> velocities/u-aero-fps >> >> propulsion/engine/prop-induced-velocity_fps >> 2.0 >> >> >> 2.0 >> >> >> > > I recently added this function to the A6M2 Zero. I placed it on CYdr (rudder > yaw) and dCLdf (flap lift delta) as well as CMde. It makes the plane fly > much, much better during the initial takeoff roll. It probably should be used > with CMdf (pitch due to flaps) as well. > > But why are you multiplying propulsion/engine/prop-induced-velocity_fps by 2? > The total velocity of the air flow in the far slipstream is V+2*w where V is the velocity of the airplane and w is the induced velocity as computed by the momentum theory. See the following discussion in the JSBSim mailing list : http://sourceforge.net/mailarchive/forum.php?thread_name=201004181833.32417.ghmalau%40gmail.com&forum_name=jsbsim-devel 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
[Flightgear-devel] JSBSim Functions for Propwash and Downwash [was: Clarification on YASim input]
On Saturday 18 June 2011 21:00:41 Jon S. Berndt wrote: > 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 > section of the config file - but outside of any > element - is this definition of qbar due to propwash: > > [Note: is shorthand for "value", and is shorthand for "property".] > > > > 0.5 > atmosphere/rho-slugs_ft3 > > > velocities/u-aero-fps > >propulsion/engine/prop-induced-velocity_fps >2.0 > > >2.0 > > > I recently added this function to the A6M2 Zero. I placed it on CYdr (rudder yaw) and dCLdf (flap lift delta) as well as CMde. It makes the plane fly much, much better during the initial takeoff roll. It probably should be used with CMdf (pitch due to flaps) as well. But why are you multiplying propulsion/engine/prop-induced-velocity_fps by 2? > [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.] I prefer to read this as "The reconstituted coefficient" or "The formula containing the coefficient" :) Seriously, I was never confused by the function naming. It helped me along when I was first learning JSBSim, because those are the terms all the textbooks use. Look at FDMs like the c182rg that have had everything renamed to the marginally pendantically correct "FLDe" instead of "CLDe" and "MmDe" instead of "CmDe". I find it ugly and potentially confusing to new users. Thanks, Ron -- 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
Re: [Flightgear-devel] Clarification on YASIM input (actionpt)
Didn't mean to branch the topic , was just curious .And thanks for the replies Jon and Hal. Ron Jensen has patiently tried coaching me with jsbsim , but I'm a slow learner ;) My apologies xsaint , hope you got the answer you were looking for. Cheers -- 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
Re: [Flightgear-devel] JSBSim Functions for Propwash and Downwash [was: Clarification on YASim input]
2011/6/19 Jon S. Berndt : > Hal, > > Oops! Sorry I attributed code to you that came from somewhere else. :-) I > now seem to recall experimenting with your model at that time - actually > replacing the older one in JSBSim cvs with yours, then adding the estimated > propwash effects. > > Hal wrote: > > 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: > > > Pitch_moment_due_to_elevator > > aero/qbar-psf > metrics/Sw-sqft > metrics/cbarw-ft > fcs/elevator-pos-rad > > velocities/mach > > 0. -0.9 > 0.66 -0.6 > 0.74 -0.4 > 1. -0.05 > > > > > > 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 Jon's function since it is > non-linear. > > Yes, the above mach effects table looks better. I can't remember where that > came from. > > ... > > 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? > > Yes - in fact, in the version I have in JSBSim cvs, the modified qbar is > used for: CLde, Cldr, Cmde, and Cndr. I haven't tested any of these for > validity, though. > > And Jon do you have any ideas on how to go about writing a > function to implement downwash pitch moment affects? > > Yes, that's another thing that could be done. I've thought about that > sometimes, too. When the wing is generating lift, the airflow is being > deflected downward behind the wing, and so the alpha that the tail sees is > affected, since the normal airflow has been given an additional component in > the body Z direction (downward from the pilot perspective). Also, if there > is an appreciable pitch rate, the alpha at the tail is affected. Finally, if > the propeller is producing thrust, then there is that affect, too. So, how > do we calculate the alpha at the horizontal tail? > > I'm making this up right here as we go, but here are my thoughts. First, > calculate the wind velocity that the H. tail sees: > > U_adjusted = U + U_prop > > Next, the Z axis velocity that the H. tail sees: > > W_adjusted = W + q*ht_arm - i_wing > > Where W is the aircraft Z axis wind velocity at the CG, q is the pitch rate, > ht_arm is the distance from the CG to the horizontal tail, and i_wing is the > induced velocity produced by the wing. At zero lift i_wing would be zero, > and at lift=weight (such as at cruise) the i_wing value would be some value > - and it might not be trivial to calculate what that would be, though you > might be able to estimate it to produce a plausible qualitative effect. > There is a NASA paper that might be helpful in calculating this: "The > Calculation of the Induced Velocity Field of a Wing". It is the translation > of a technical paper by Klaus Gersten. It is NASA Technical Translation TT > F-12, 436, and you can download it at this URL: > http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19690023298_1969023298. > pdf. > > Anyhow, then, of course, the calculation is just this: > > alpha_tail = atan2(W_adjusted, U_adjusted) > > 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! > To improve our bibliography I suggest to add this paper "Prediction of the effects of propeller operation on the static longitudinal stability of single-engine tractor monoplanes with flaps retracted" - J. Weil, W. C. Sleeman - NACA Report 941 available at this URL: http://hdl.handle.net/2060/19930092006 Figures 12 and 13 are of particular interest : you can see the influence of propwash on CL and Cm. On figure 12, the slopes of CL and Cm for a tail incidence of 0 deg are roughly increased by 30% and 60% respectively. 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 Flightgea
[Flightgear-devel] JSBSim Functions for Propwash and Downwash [was: Clarification on YASim input]
Hal, Oops! Sorry I attributed code to you that came from somewhere else. :-) I now seem to recall experimenting with your model at that time - actually replacing the older one in JSBSim cvs with yours, then adding the estimated propwash effects. Hal wrote: 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: Pitch_moment_due_to_elevator aero/qbar-psf metrics/Sw-sqft metrics/cbarw-ft fcs/elevator-pos-rad velocities/mach 0. -0.9 0.66-0.6 0.74-0.4 1. -0.05 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 Jon's function since it is non-linear. Yes, the above mach effects table looks better. I can't remember where that came from. ... 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? Yes - in fact, in the version I have in JSBSim cvs, the modified qbar is used for: CLde, Cldr, Cmde, and Cndr. I haven't tested any of these for validity, though. And Jon do you have any ideas on how to go about writing a function to implement downwash pitch moment affects? Yes, that's another thing that could be done. I've thought about that sometimes, too. When the wing is generating lift, the airflow is being deflected downward behind the wing, and so the alpha that the tail sees is affected, since the normal airflow has been given an additional component in the body Z direction (downward from the pilot perspective). Also, if there is an appreciable pitch rate, the alpha at the tail is affected. Finally, if the propeller is producing thrust, then there is that affect, too. So, how do we calculate the alpha at the horizontal tail? I'm making this up right here as we go, but here are my thoughts. First, calculate the wind velocity that the H. tail sees: U_adjusted = U + U_prop Next, the Z axis velocity that the H. tail sees: W_adjusted = W + q*ht_arm - i_wing Where W is the aircraft Z axis wind velocity at the CG, q is the pitch rate, ht_arm is the distance from the CG to the horizontal tail, and i_wing is the induced velocity produced by the wing. At zero lift i_wing would be zero, and at lift=weight (such as at cruise) the i_wing value would be some value - and it might not be trivial to calculate what that would be, though you might be able to estimate it to produce a plausible qualitative effect. There is a NASA paper that might be helpful in calculating this: "The Calculation of the Induced Velocity Field of a Wing". It is the translation of a technical paper by Klaus Gersten. It is NASA Technical Translation TT F-12, 436, and you can download it at this URL: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19690023298_1969023298. pdf. Anyhow, then, of course, the calculation is just this: alpha_tail = atan2(W_adjusted, U_adjusted) 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! Jon <>-- 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
Re: [Flightgear-devel] Clarification on YASIM input (actionpt)
2011/6/19 Hal V. Engel : > 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 > >> section of the config file - but outside of any > >> element - is this definition of qbar due to propwash: > >> > >> [Note: is shorthand for "value", and is shorthand for "property".] > >> > >> > >> > >> 0.5 > >> atmosphere/rho-slugs_ft3 > >> > >> > >> velocities/u-aero-fps > >> > >> propulsion/engine/prop-induced-velocity_fps > >> 2.0 > >> > >> > >> 2.0 > >> > >> > >> > >> > >> Later, within the pitch axis definition, is this definition: > >> > >> > >> Pitch_moment_due_to_elevator > >> > >> aero/thrust-qbar_psf > >> metrics/Sw-sqft > >> metrics/cbarw-ft > >> fcs/elevator-pos-rad > >> > >> velocities/mach > >> > >> 0. -0.8 > >> 2. -0.200 > >> > >> > >> > >> > > 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: > > > > Pitch_moment_due_to_elevator > > > > aero/qbar-psf > > metrics/Sw-sqft > > metrics/cbarw-ft > > fcs/elevator-pos-rad > > > > velocities/mach > > > > 0. -0.9 > > 0.66 -0.6 > > 0.74 -0.4 > > 1. -0.05 > > > > > > > > > > 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 "coeffic
