Re: [Flightgear-devel] JSBSIm, aeromatic, crosswind taxiiing, et cetera

2011-06-19 Thread Jon S. Berndt
> 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

2011-06-19 Thread Ron Jensen
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

2011-06-19 Thread Hal V. Engel
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

2011-06-19 Thread Gene Buckle
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

2011-06-19 Thread Ron Jensen
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

2011-06-19 Thread Hal V. Engel
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

2011-06-19 Thread Jari Häkkinen
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

2011-06-19 Thread Chelley
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-06-19 Thread Bertrand Coconnier
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

2011-06-19 Thread 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 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-06-19 Thread Bertrand Coconnier
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]

2011-06-19 Thread 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?

> [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)

2011-06-19 Thread syd adams
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-06-19 Thread Bertrand Coconnier
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]

2011-06-19 Thread 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!

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-06-19 Thread Bertrand Coconnier
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