date:20060614

On Wed, 14 Jun 2006 11:57:39 +0200, Georg wrote in message 
[EMAIL PROTECTED]:

 Melchior FRANZ schrieb:
  * Georg Vollnhals -- Wednesday 14 June 2006 03:02:
  Take the BO105 and goo for a straight and level flight with 100-120
   knts. Then push the collective down. [...]
  Try it with the BO105 - see what happens?
  You are not only able to hold height with pulling the stick back
 but to   climb with up to 1500 ft/min until speed is low.
  
  That's translational lift. You know, the thing people are claiming
  isn't implemented. :-}  It's not realistic (as Maik himself says),
 No. Translational list is an additional lift component related to 
 helicopter speed against the air and will start at about 12 to 20 knts
  (depending on type of helo). This is a real big addition lift
  component 
together with (an unwished) roll and yaw component.
  but I'm not sure about the dropping like a stone thing. Normally,
  people compare a fully loaded real helicopter (because they are
  sitting in them as passengers together with several other people)
  with an unloaded sim helicopter. Put more weight into the bo, and it
  sinks faster, as one would expect in RL.
  
  m.
 falling like a stone might be the wrong expression but was told me
 by  a RL pilot and demonstrated afterwards in a hot autorotation for
 a  short time from 2000 to 1000 ft. It is pretty impressive and the 
 vertical speed naturally depends on the type and configuration (ie 
 weight) of the helo that you fly, our BK117 should come up to more
 than  2000 ft/min, a BO105 will be have some other numbers but
 generally  comparable.
 You understand what one is doing when reducing collective? You reduce 
 the common blade-pitch angle to (nearly) zero (depending on the type
 of  helo you are flying). Of course, going into a heavy flare will
 give you  some lift for a short time until your horizontal kinetic
 energy (speed)  is reduced. But when I asked one of our experienced RL
 pilots 

..define experienced.  We need somebody experienced in autorotation,
and these guys are rare and expensive.

 about this scenario and what would happen, he told me that he could
 (if ever) hold  altitude for a *very* short time by pitching back but
 could not make the  bird ascend remarkably (what our FG helo does).
 
 OK, after all I want to say once again that I am not the real expert
 for  this, we should have an *experienced RL helo pilot* who is also 
 interested in flightsims to tell us what he thinks in general and
 detail about our FDM.
 But as I was very keen to learn all about helicopter flight behaviour 
 and technics and comparing different helo sim flightmodels by checking
  the opinion of RL helo pilots I *just want to share* all I know with 
 you. People simply should be advised that there are very diffent views
  regarding the actual helo FDM.
 
 I would feel pretty bad if we announce our helo FDM as realistic as
 we  have some nice fixed wing aircraft with real life pilots and a/c 
 owners approved flightdynamics, this would be bad for FG in common.
 
 Just my 2c, this discussion will probably never end :-)



-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] UAV Heli and Matlab

2006-06-14 Thread GWMobile

Unless you get REALLY small the accuracy should be the same as full 
scale.

But close to the ground the ground effect makes a big difference. It 
happens when aplane flies at an altitude less than half its wingspan. 
Basically the air underneath can't get out and creates tremendous 
additional lift.


On Wed, 14 Jun 2006 6:59 am, Correu PelDavid wrote:
 The discussion seems to be getting hot..

 Regarding the heli model: Could it represent an R/C helicopter model 
 fine enough to synthonize an autopilot to be ported afterwards to real 
 (R/C UAV) life?
 Would it work for slow velocities and near to ground flights?
 Would it work for higher (not much) altitude and agressive manoeuvres?

 Thanks,

 David

 2006/6/14, Melchior FRANZ [EMAIL PROTECTED]:

 * Georg Vollnhals -- Wednesday 14 June 2006 11:57:
  Melchior FRANZ schrieb:
   * Georg Vollnhals -- Wednesday 14 June 2006 03:02:
   Take the BO105 and goo for a straight and level flight with 100-120
   knts. Then push the collective down. [...]  ^^^

   That's translational lift.

  No. Translational list is an additional lift component related to
  helicopter speed against the air and will start at about 12 to 20 knts

 Pardon? You spoke about 100-120 knots. I said it's translational lift.
 You disgree because translational lift starts with 12 to 20 knots?!?
 Doesn't make the least sense.

 m.

 ___



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] VMAP1 in Landcover-DB

2006-06-14 Thread Martin Spott

Hello,
the VMAP1 dataset makes a nice difference for the Bay Area. Go to:

  http://mapserver.flightgear.org/

enter ICAO KPAO, and then replace several layers in the selection:

rivers_stream - rivers_vmap1
rivers_intermittentstream - intermittentrivers_vmap1
roads_road - roads_vmap1
cities_urban - cities_vmap1

  add freeway_vmap1 if you like, Refresh and enjoy.
I find it very interesting that the VMAP1 city areas match the GSHHS
shoreline _much_ better than the VMAP0 cities do, like in SFO downtown
or Treasure Island. It's a pity that the available VMAP1 covers only so
little of the Earth (yes, I know why),

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] UAV Heli and Matlab

Melchior FRANZ wrote:
* Georg Vollnhals -- Wednesday 14 June 2006 11:57:
Melchior FRANZ schrieb:
* Georg Vollnhals -- Wednesday 14 June 2006 03:02:
Take the BO105 and goo for a straight and level flight with 100-120
knts. Then push the collective down. [...] ^^^

That's translational lift.

No. Translational list is an additional lift component related to
helicopter speed against the air and will start at about 12 to 20 knts

Pardon? You spoke about 100-120 knots. I said it's translational lift.
You disgree because translational lift starts with 12 to 20 knots?!?
Doesn't make the least sense.

___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

I think the 100-120 kts figure is irrelevant, he was talking about
autorotation there, which has pretty much nothing to do with what we are
talking about now.

We are mixing two effects here, ETL and transverse flow effect. In my
original post I was talking about ETL, and failed to mention transverse
flow, as well as LTE, both of which should have been on that list. These
two effects are also related to dissymmetry of lift, retreating blade
stall and delta-3 blade hinges. Here are some excellent descriptions of
the difference between the two. Point was, there are a lot of important
effects missing from the simulation or not realistically implemented.

http://helicopterflight.net/translational_lift.htm
http://www.dynamicflight.com/aerodynamics/transverse_flow_eff/
http://www.dynamicflight.com/aerodynamics/translational_lift/
http://64.233.161.104/search?q=cache:Sy8Mi3NkuKAJ:www.baseops.net/ft_rucker/HELO_Aerodynamics.ppt+translational+lifthl=engl=usct=clnkcd=6client=firefox

Josh

___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Preclipped or overlapping layouts for apt.dat

2006-06-14 Thread bsupnik

Hi Y'all,

One of the things that's come up in the apt.dat discussions is whether 
the taxiway layouts should be pre-clipped (meaning there are no 
overlapping polygons) or overlapped (meaning polygons can overlap and 
there is a well-defined draw order that makes one appear on top of another).

(I think we have to pick one - having overlapping polygons with random 
draw order doesn't help authors make layouts.)

I'm looking for pros and cons of each technique...here's some thoughts 
I've had:

- I'm not sure about FG's scenery distro model, but pre-clipped polygons 
means that more work has been done to a layout before it becomes an 
apt.dat file, which would make on-the-fly loading of add-on scenery faster.

- Any app will have to do clipping or draw order control - clipping can 
happen before or during app run.  So a clipping model gives us a chance 
to keep work out of sim-run-time, but an overlapped model allows us to 
do work in the sim (e.g. avoid the need for preprocessing).  I think FG 
is pretty strongly in the preprocessing camp right now.

- Pre-clipping puts more burdon on content creation tools (by requiring 
them to have robust clipping to save the data) whereas not requiring 
pre-clipping puts more work on data consumers.

- Personally I like pre-clipping because I've always found overlapping 
runway data to be...messy.  I always wonder if there isn't some 
polygon buried under another one, totally invisible to the user.  So I 
tend to think pre-clipping makes a better editing environment.  But this 
last point is probably not appropos to the discussion.

Thoughts?
Ben


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Autopilot Bug/Feature

Hi,

In the course of developing the KC135, I noticed that parts of the autopilot
function do not work in that model, copied from the B737 - the bits
described as vor/loc and app. Investigation showed that the cause was simple
- in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading
Indicator - no Heading Indicator - no vor/loc etc.  So quick as a flash I
rustled up an electrically driven one. Simple solution? Wrong: when I tried
to implement a dedicated instrument.xml configuration for the KC135, using
the new Heading Indicator, the old one was still present (and still
inoperative). This is caused by xmlauto.cxx initiating before
instrumentmgr.xml, and creating the unnecessary nodes which it needs. So I
changed the initiation order. But by this time I realised that the simple
Heading Indicator we have is not what would be fitted to a KC135, or indeed
any jet ac since the '50s onward. We need what I would call a flux gate
compass (you might know a more modern term). This is more or less just the
property orientation/heading-magnetic-deg, but I thought that, for
completeness a proper flux gate instrument electrically driven etc, would be
nice. So I coded up one, and amended xmlauto.cxx so that it uses whichever
sort is configured and does not generate spurious ones.

Now, I might have got hold of the wrong end of the stick here, and someone
may well know better. I intend to arrange the upload of these pretty trivial
changes at the weekend unless otherwise directed, or as I would have said in
a former existence UNODIR.

Regards

Vivian 



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Preclipped or overlapping layouts for apt.dat

2006-06-14 Thread Paul Surgeon

On Wednesday 14 June 2006 16:14, bsupnik wrote:
 - Pre-clipping puts more burdon on content creation tools (by requiring
 them to have robust clipping to save the data) whereas not requiring
 pre-clipping puts more work on data consumers.

Where are you thinking of saving the clipped data?
Back into apt.dat (heaven forbid!) or straight to a scenery format?
If we had to store the clipped data to apt.dat file the file will become 
massive and the editor tools would have to be very complex to handle the 
data. In essense TaxiDraw would become a 3D modeler for airports.

Saving overlapping layouts is going to be a lot cleaner. I'd rather see the 
clipping done at scenery build time or simulator run time much like the way 
it's handled at the moment.
If you're worried about layers becoming lost under others in the editor tools 
it wouldn't be hard to flag them for removal. Just check if any layer is 
totally covered by others and notify the user of the problem.

Paul


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Autopilot Bug/Feature

I think the simple solution here is to modify the autopilot config so 
the input is not from a vacuum driven heading indicator since you don't 
have one, but from a different property that you do have.

The autopilot is designed to be very configurable in this respect and 
even though it can be complex, you can create a custom config for each 
aircraft that matches it's real world capabilities and design quite closely.

Curt.


Vivian Meazza wrote:
 In the course of developing the KC135, I noticed that parts of the autopilot
 function do not work in that model, copied from the B737 - the bits
 described as vor/loc and app. Investigation showed that the cause was simple
 - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading
 Indicator - no Heading Indicator - no vor/loc etc.  So quick as a flash I
 rustled up an electrically driven one. Simple solution? Wrong: when I tried
 to implement a dedicated instrument.xml configuration for the KC135, using
 the new Heading Indicator, the old one was still present (and still
 inoperative). This is caused by xmlauto.cxx initiating before
 instrumentmgr.xml, and creating the unnecessary nodes which it needs. So I
 changed the initiation order. But by this time I realised that the simple
 Heading Indicator we have is not what would be fitted to a KC135, or indeed
 any jet ac since the '50s onward. We need what I would call a flux gate
 compass (you might know a more modern term). This is more or less just the
 property orientation/heading-magnetic-deg, but I thought that, for
 completeness a proper flux gate instrument electrically driven etc, would be
 nice. So I coded up one, and amended xmlauto.cxx so that it uses whichever
 sort is configured and does not generate spurious ones.

 Now, I might have got hold of the wrong end of the stick here, and someone
 may well know better. I intend to arrange the upload of these pretty trivial
 changes at the weekend unless otherwise directed, or as I would have said in
 a former existence UNODIR.

 Regards

 Vivian 



 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


-- 
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Autopilot Bug/Feature

2006-06-14 Thread Berndt, Jon S

 In the course of developing the KC135, I noticed that parts 
 of the autopilot function do not work in that model, copied 
 from the B737 - the bits described as vor/loc and app. 
 Investigation showed that the cause was simple
 - in JSBSim a jet ac does not have vacuum system. No vacuum - 
 no Heading Indicator - no Heading Indicator - no vor/loc etc. 
 
 Vivian

I don't understand this. Is it that JSBSim code is missing some internal
capability, or that most JSBSim aircraft models (the XML files) do not
seem to have defined a vacuum system? Is this a code or a definition
problem?

Jon


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Preclipped or overlapping layouts for apt.dat

2006-06-14 Thread bsupnik

Hi Paul,

For what it's worth, I'm leaning more and more toward overlapping, both 
because of your arguments, stuff Curt's said, and just tossing the ideas 
around...so this is a bit of a devil's advocate argument...

Paul Surgeon wrote:
 Where are you thinking of saving the clipped data?
 Back into apt.dat (heaven forbid!) or straight to a scenery format?

Yes - back into the apt.dat format.

 If we had to store the clipped data to apt.dat file the file will become 
 massive and the editor tools would have to be very complex to handle the 
 data. In essense TaxiDraw would become a 3D modeler for airports.

Yes.

 Saving overlapping layouts is going to be a lot cleaner. I'd rather see the 
 clipping done at scenery build time or simulator run time much like the way 
 it's handled at the moment.

I'm not sure I would say overlapping is 'cleaner'...it's definitely 
simpler from a data format and validation standpoint, simpler for an 
editor, but perhaps more complex for a viewer.  Whether it's a truer 
representation I think depends on the intent of the author.

In my original RFC I described the apt.dat format as a distribution 
format because the output of editors like Taxidraw goes into the 
database for distribution.  But this isn't really tool, because we'd 
like to be able to put the layouts back into TaxiDraw (or another 
editor) and work on them more.  Also apt.dat's roll as a high-level 
format shared between two sims implies it shouldn't be gunked up with 
distribution-level optimizatinos.  So both these things have been moving 
me back toward overlapping and away from clipping.

*cheers*
ben

-- 
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://xplanescenery.blogspot.com/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
Scenery mailing list: [EMAIL PROTECTED]
Developer mailing list: [EMAIL PROTECTED]


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Aerobatics using flight gear and JSBSim

2006-06-14 Thread flying.toaster


Using derivations very similar to those described by Jon in his latest paper, I 
have managed having my Su-26 alpha model do most of these figures :

http://aerobatics.ws/acro_figures.html

The ones that still are a little dirty for me are the tailslide and sided 
loops (the former because I always seem to have some sideslip even with engine 
shut, the latter because I am plain bad as a pilot ;o) ). Cuban eigths on the 
other hand instance are piece of cake. Inverted spins require a lot of aileron 
work whereas normal spins are pretty easy.

 All this to say that it looks very good.

 Now for a few questions : 
- Are both half wings treated separately in JSBSim ? That can be important for 
snap rolls, even though I do them day in day out now
- Has anybody given thought to have wing flex in 3D models ? That would be 
interesting effect for aerobatics in a sailplane, some undercarriages (like 
humm, say humm, the su-26) and modern airliners for which wings are quite 
flexible (look at a picture of any of them taking off)

When I release the Su as beta, I would like some feedback of people who have 
flown aerobatics (so that I can tweak some more)

Cheers




___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Autopilot Bug/Feature

Vivian Meazza wrote:
 Hi,
 
 In the course of developing the KC135, I noticed that parts of the autopilot
 function do not work in that model, copied from the B737 - the bits
 described as vor/loc and app. Investigation showed that the cause was simple
 - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading
 Indicator - no Heading Indicator - no vor/loc etc.  So quick as a flash I
 rustled up an electrically driven one. Simple solution? Wrong: when I tried
 to implement a dedicated instrument.xml configuration for the KC135, using
 the new Heading Indicator, the old one was still present (and still
 inoperative). This is caused by xmlauto.cxx initiating before
 instrumentmgr.xml, and creating the unnecessary nodes which it needs. So I
 changed the initiation order. But by this time I realised that the simple
 Heading Indicator we have is not what would be fitted to a KC135, or indeed
 any jet ac since the '50s onward. We need what I would call a flux gate
 compass (you might know a more modern term). This is more or less just the
 property orientation/heading-magnetic-deg, but I thought that, for
 completeness a proper flux gate instrument electrically driven etc, would be
 nice. So I coded up one, and amended xmlauto.cxx so that it uses whichever
 sort is configured and does not generate spurious ones.
 

Can't you just supply whatever property regarding the vacuum system that
the instrument is looking for?

Josh


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Autopilot Bug/Feature

2006-06-14 Thread AJ MacLeod

On Wednesday 14 June 2006 21:51, Josh Babcock wrote:
 Can't you just supply whatever property regarding the vacuum system that
 the instrument is looking for?

He could (which ISTR I had to do for the Lightning) but I think it would be 
nice to have the correct system available too.  Some aircraft have multiple 
types of the same instrument to provide emergency backups and providing for 
this is where the hacks start to get a bit messy I think.

Cheers,

AJ


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

2006-06-14 Thread Theo Hankers

Hey toaster :-),

I love your idea of trying to simulate aerobatics correctly and I'd want 
to try to help you once you're able to release the first version. I'm 
not too familiar with flightgear (I'm only using it as a flight data 
display) so far (especially not JSBSim, can't help you with that), but 
I've been flying aerobatics for quite a while (I'd rather have other 
people judge my skill than myself :-) and I'm quite familiar with the 
flight dynamics of different aerobatic maneuvres.
In my opinion simulating the wings seperately would be the key feature 
for simulating aerobatics. No simulator I know of has this ability so 
far, but accurate (inverted) snaps and spins won't work without it. 
You'll also have to include the torque effect since in modern aerobatics 
many figures rely on engine torque influence, and vice versa many 
figures simply won't work with or without it.
In the end, I don't believe we even have an aerobatic plane for 
Flightgear yet (I'm loading MS Flight Simulator MDL-models).
I don't know if I can help you out, but I'll try!

Good luck on your design,

TH

flying.toaster wrote:
 Using derivations very similar to those described by Jon in his latest paper, 
 I have managed having my Su-26 alpha model do most of these figures :

 http://aerobatics.ws/acro_figures.html

 The ones that still are a little dirty for me are the tailslide and sided 
 loops (the former because I always seem to have some sideslip even with 
 engine shut, the latter because I am plain bad as a pilot ;o) ). Cuban eigths 
 on the other hand instance are piece of cake. Inverted spins require a lot of 
 aileron work whereas normal spins are pretty easy.

  All this to say that it looks very good.

  Now for a few questions : 
 - Are both half wings treated separately in JSBSim ? That can be important 
 for snap rolls, even though I do them day in day out now
 - Has anybody given thought to have wing flex in 3D models ? That would be 
 interesting effect for aerobatics in a sailplane, some undercarriages (like 
 humm, say humm, the su-26) and modern airliners for which wings are quite 
 flexible (look at a picture of any of them taking off)

 When I release the Su as beta, I would like some feedback of people who have 
 flown aerobatics (so that I can tweak some more)

 Cheers




 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel


   



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Autopilot Bug/Feature

Curt wrote

 
 I think the simple solution here is to modify the autopilot config so
 the input is not from a vacuum driven heading indicator since you don't
 have one, but from a different property that you do have.

There is one - nearly - as I said orientation/heading-magnetic-deg. But it's
not derived from an instrument, and therefore has no supply, neither can it
fail, not does it have any error. Further, use of such a property will not
stop, AFAIKS, the generation of spurious and unnecessary instruments, caused
by incorrect initiation, and a hack to get around this. This looks
unprofessional.
 
 The autopilot is designed to be very configurable in this respect and
 even though it can be complex, you can create a custom config for each
 aircraft that matches it's real world capabilities and design quite
 closely.

So it is. Except the existing Heading Indicator is quite inappropriate for
even halfway recent military or civil aircraft.

 
 Vivian Meazza wrote:
  In the course of developing the KC135, I noticed that parts of the
 autopilot
  function do not work in that model, copied from the B737 - the bits
  described as vor/loc and app. Investigation showed that the cause was
 simple
  - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading
  Indicator - no Heading Indicator - no vor/loc etc.  So quick as a flash
 I
  rustled up an electrically driven one. Simple solution? Wrong: when I
 tried
  to implement a dedicated instrument.xml configuration for the KC135,
 using
  the new Heading Indicator, the old one was still present (and still
  inoperative). This is caused by xmlauto.cxx initiating before
  instrumentmgr.xml, and creating the unnecessary nodes which it needs. So
 I
  changed the initiation order. But by this time I realised that the
 simple
  Heading Indicator we have is not what would be fitted to a KC135, or
 indeed
  any jet ac since the '50s onward. We need what I would call a flux gate
  compass (you might know a more modern term). This is more or less just
 the
  property orientation/heading-magnetic-deg, but I thought that, for
  completeness a proper flux gate instrument electrically driven etc,
 would be
  nice. So I coded up one, and amended xmlauto.cxx so that it uses
 whichever
  sort is configured and does not generate spurious ones.
 
  Now, I might have got hold of the wrong end of the stick here, and
 someone
  may well know better. I intend to arrange the upload of these pretty
 trivial
  changes at the weekend unless otherwise directed, or as I would have
 said in
  a former existence UNODIR.
 
  Regards
 
  Vivian
 
 
 
  ___
  Flightgear-devel mailing list
  Flightgear-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/flightgear-devel
 
 
 
 --
 Curtis Olsonhttp://www.flightgear.org/~curt
 HumanFIRST Program  http://www.humanfirst.umn.edu/
 FlightGear Project  http://www.flightgear.org
 Unique text:2f585eeea02e2c79d7b1d8c4963bae2d
 
 
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Autopilot Bug/Feature

Jon

 
  In the course of developing the KC135, I noticed that parts
  of the autopilot function do not work in that model, copied
  from the B737 - the bits described as vor/loc and app.
  Investigation showed that the cause was simple
  - in JSBSim a jet ac does not have vacuum system. No vacuum -
  no Heading Indicator - no Heading Indicator - no vor/loc etc.
 
  Vivian
 
 I don't understand this. Is it that JSBSim code is missing some internal
 capability, or that most JSBSim aircraft models (the XML files) do not
 seem to have defined a vacuum system? Is this a code or a definition
 problem?
 

Well, unless you can show me that modern jet aircraft have a vacuum system
that is gear driven from the engine or bled from it somewhere - the existing
code is just fine and totally realistic.

The problem is that the existing Heading Indicator is not the correct
instrument, vacuum or electrically driven, and there is some programming
that could be improved a little, but not in JSBSim.

Vivian  





___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Autopilot Bug/Feature

AJ wrote

 On Wednesday 14 June 2006 21:51, Josh Babcock wrote:
  Can't you just supply whatever property regarding the vacuum system that
  the instrument is looking for?
 
 He could (which ISTR I had to do for the Lightning) but I think it would
 be
 nice to have the correct system available too.  Some aircraft have
 multiple
 types of the same instrument to provide emergency backups and providing
 for
 this is where the hacks start to get a bit messy I think.
 

We really don't need to hack this one. Sure we could paper over this one
with a few lines of Nasal, but that won't solve the underlying problem
(minor but below the high standards we set ourselves, or I thought we did)

Vivian 



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Autopilot Bug/Feature

Josh

 
 Vivian Meazza wrote:
  Hi,
 
  In the course of developing the KC135, I noticed that parts of the
 autopilot
  function do not work in that model, copied from the B737 - the bits
  described as vor/loc and app. Investigation showed that the cause was
 simple
  - in JSBSim a jet ac does not have vacuum system. No vacuum - no Heading
  Indicator - no Heading Indicator - no vor/loc etc.  So quick as a flash
 I
  rustled up an electrically driven one. Simple solution? Wrong: when I
 tried
  to implement a dedicated instrument.xml configuration for the KC135,
 using
  the new Heading Indicator, the old one was still present (and still
  inoperative). This is caused by xmlauto.cxx initiating before
  instrumentmgr.xml, and creating the unnecessary nodes which it needs. So
 I
  changed the initiation order. But by this time I realised that the
 simple
  Heading Indicator we have is not what would be fitted to a KC135, or
 indeed
  any jet ac since the '50s onward. We need what I would call a flux gate
  compass (you might know a more modern term). This is more or less just
 the
  property orientation/heading-magnetic-deg, but I thought that, for
  completeness a proper flux gate instrument electrically driven etc,
 would be
  nice. So I coded up one, and amended xmlauto.cxx so that it uses
 whichever
  sort is configured and does not generate spurious ones.
 
 
 Can't you just supply whatever property regarding the vacuum system that
 the instrument is looking for?
 

Why would I want to do that when a proper solution is to hand? It's only a
handful of lines of code to fix this, and I've already written them.

Vivian



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

On Wed, 14 Jun 2006 22:12:31 +0200 (CEST), flying.toaster wrote in
message 
[EMAIL PROTECTED]:

  Now for a few questions : 
 - Are both half wings treated separately in JSBSim ? 

..AFAIK, no, yasim yes.

..2 option for JSBSim, cut your Su-26 in 2, Su-26Left and Su-26Right,
or rewrite JSBSim with 2 half wings per full wing.

 That can be important for snap rolls, even though I do them day in day
 out now - Has anybody given thought to have wing flex in 3D models ?

..just a wee bit, short term solution is look-up tables off FEA models,
then hope Microsoft survives long enough to lure box vendors like Dell
and Lenovo into shrinking Hollywood render farms into desktops.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.




___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] VMAP1 in Landcover-DB

On Wed, 14 Jun 2006 12:58:09 + (UTC), Martin wrote in message 
[EMAIL PROTECTED]:

 Hello,
 the VMAP1 dataset makes a nice difference for the Bay Area. Go to:
 
   http://mapserver.flightgear.org/
 
 enter ICAO KPAO, and then replace several layers in the selection:
 
 rivers_stream - rivers_vmap1
 rivers_intermittentstream - intermittentrivers_vmap1
 roads_road - roads_vmap1
 cities_urban - cities_vmap1
 
   add freeway_vmap1 if you like, Refresh and enjoy.
 I find it very interesting that the VMAP1 city areas match the GSHHS
 shoreline _much_ better than the VMAP0 cities do, like in SFO downtown
 or Treasure Island. It's a pity that the available VMAP1 covers only
 so little of the Earth (yes, I know why),

..one way we can go, is use VMAP1 or better where we can find it, 
and VMAP0 elsewhere, and let the market and the electorate 
put the heat on where it belongs, so we can help them patriots show 
off their beautiful home town, instead of that ugly VMAP0 dump.  ;o)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] vatsim

On Wed, 14 Jun 2006 20:36:46 +0100, Lee wrote in message 
[EMAIL PROTECTED]:

 Ultimately though, _all_ software will be designed by AIs and 
 'who' will 'own' it then?  :)

..mmm, after AII; AI Intuition, porcupine aviation etc.  ;o)
 
 ...but until then we have both O/S  C/S s/w and that's the way 
 it _is_, whether anyone thinks that's good or bad.
 
 The issue of getting FG to work with C/S software, such as 
 vatsim, doesn't have to compromise FG's integrity or leave it 
 open to challenges.  

..we certainly better not, and as long as we keep our eyes 'n 
minds open, we should able to remain squeaky clean.

 There's no restriction within the GPL of exchanging data between O/S
 and C/S s/w, and a good job too  because all the firmware in your h/w
 is going to be C/S.

..correct, those restrictions are usually on the C/S side and in their
contracts, and litigators usually allege some complex and spicy form 
of breach of contracts.
 
 The only real issue I see here is who does the work and how they 
 feel about it.

..feelings protects _nothing_.  Action on it is a requirement.  
Ask any woman.  ;o)

 I've top-posted because I guess I'm summarising :)
 
 ...and hey - it's summer :)

..aye.  ;o)

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Preclipped or overlapping layouts for apt.dat

On Wed, 14 Jun 2006 10:14:18 -0400, bsupnik wrote in message 
[EMAIL PROTECTED]:

 Hi Y'all,
 
 One of the things that's come up in the apt.dat discussions is whether
  the taxiway layouts should be pre-clipped (meaning there are no 
 overlapping polygons) or overlapped (meaning polygons can overlap
 and  there is a well-defined draw order that makes one appear on top
 of another).
 
 (I think we have to pick one - having overlapping polygons with random
  draw order doesn't help authors make layouts.)
 
 I'm looking for pros and cons of each technique...here's some thoughts
  I've had:
 
 - I'm not sure about FG's scenery distro model, but pre-clipped
 polygons  means that more work has been done to a layout before it
 becomes an  apt.dat file, which would make on-the-fly loading of
 add-on scenery faster.
 
 - Any app will have to do clipping or draw order control - clipping
 can  happen before or during app run.  So a clipping model gives us a
 chance  to keep work out of sim-run-time, but an overlapped model
 allows us to  do work in the sim (e.g. avoid the need for
 preprocessing).  I think FG  is pretty strongly in the preprocessing
 camp right now.

..strong enough, or too?  ;o)

 - Pre-clipping puts more burdon on content creation tools (by
 requiring  them to have robust clipping to save the data) whereas not
 requiring  pre-clipping puts more work on data consumers.
 
 - Personally I like pre-clipping because I've always found overlapping
 runway data to be...messy.  I always wonder if there isn't some 
 polygon buried under another one, totally invisible to the user.  So I
 tend to think pre-clipping makes a better editing environment.  But
 this last point is probably not appropos to the discussion.
 
 Thoughts?
 Ben

..I don't like either way.  My preference is let those home town
patriots decide whether they wanna live with their ugly-as-sin
VMAP0/apt.dat toxin dumps, or volonteer slick brlcad type 3d solid
models to tweak in TaxiDraw, and generate apt.dat data from those.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

 Using derivations very similar to those described by Jon in his
 latest paper, I have managed having my Su-26 alpha model do most
 of these figures :

 http://aerobatics.ws/acro_figures.html

 The ones that still are a little dirty for me are the tailslide
 and sided loops (the former because I always seem to have some
 sideslip even with engine shut, the latter because I am plain bad
 as a pilot ;o) ). Cuban eigths on the other hand instance are
 piece of cake. Inverted spins require a lot of aileron work
 whereas normal spins are pretty easy.

This is fascinating to me - I'll be interested to try it out.

  All this to say that it looks very good.

  Now for a few questions :
 - Are both half wings treated separately in JSBSim ? That can be
 important for snap rolls, even though I do them day in day out now

Yes, I know. The aerodynamics of a snap roll are ... interesting. We have
talked about splitting up various surfaces on and off for years. I think
David Megginson first suggested that approach. It's definitely a
possibility. I suppose that ideally the wing would be split up into four or
five parts on each side. Alpha would be calculated for each section given
the rotational and translational state of the aircraft.

But, I'm also wondering if there is a way to obtain the same effect with a
three-dimensional table. Can someone give a detailed describption of a snap
roll?

Jon



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] VMAP1 in Landcover-DB



I say we issue everyone a GPS unit and start taking out own data :)

Josh


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

Jon S. Berndt wrote:
 But, I'm also wondering if there is a way to obtain the same effect with a
 three-dimensional table. Can someone give a detailed describption of a snap
 roll?
   

My understanding of a snap roll is that at some speed (probably well 
above traditional stall speed) you command a large nose up elevator 
deflection -- if you have enough elevator authority you can quickly 
force the wing to a high alpha so that the wing stalls (at a much higher 
than normal speed.)  What happens next is very similar to a spin: one 
wing stalls before the other leading to a rapid roll.  But in this case 
you have so much forward momentum that the result looks more like a 
traditional aileron roll.

I can do this in many of my R/C planes.  Just pull back the elevator to 
full deflection and the plane rolls almost instantly.  Let go of the 
elevator and the plane stops rolling and recovers.  From the ground it 
looks *very* similar to a more traditional aileron roll.

I have an aerobatic sea plane with the engine mounted on a pylon above 
the wing.  There's one move that's fun and freaky to fly it through.  
First I accelerate to full speed and pull the aircraft into a vertical 
climb, then I induce a snap roll as I'm going straight up by pulling the 
elevator back to maximum deflection.  The result is that I'm in a snap 
roll/spin but heading straight *UP*.  If I do this at full throttle and 
then feed in some extreme aileron/rudder deflection, the airplane will 
continue to spin upwards until it runs out of momentum and then continue 
tumbling very strangely in mid air before it begins to drop and the 
maneuver transitions into a more traditional spin.  It's very freaky to 
watch because the engine is on a pylon above the wing so you have a 
strange off axis thrust line that makes the plane tumble more strangely.

http://www.flightgear.org/~curt/Models/Current/Mariner40/

I should point out that I'm an average R/C pilot at best so there are a 
*lot* of guys that can do a lot fancier and wilder stuff than I know how 
to do.

Curt.

-- 
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] AI Flightplan Animations

2006-06-14 Thread dene maxwell

Hi
I'm writing xml animation files for AI aircraft. I have the propeller 
animation tied into the air-speed as an AI aircraft doesn't have an engine 
speed.

I tied the flap and gear animations into;

/ai/models/aircraft/surface-positions/flap-pos-norm

and

/ai/models/aircraft/controls/gear/gear-down

respectively

I can test the flap animation using the internal property browser and it 
works.
The gear-down property seems to be read only though (when I try to change it 
from true to false it reverts back to true).

The other issue is that neither of these properties seem to be tied into the 
flightplan gear-down and flaps-down properties.

The on-ground flightplan property doesn't seem to do anything in the 
property tree.

I'm using 098a.

Can some-one please point me in the direction of what I'm doing wrong?

I would post the xml samples but they don't post too well either in mail or 
on a web-site.

Regards
Dene

_
Check out the latest video  @  http://xtra.co.nz/streaming



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

 Jon S. Berndt wrote:
  But, I'm also wondering if there is a way to obtain the same 
 effect with a
  three-dimensional table. Can someone give a detailed 
 describption of a snap
  roll?

 
 My understanding of a snap roll is that at some speed (probably well 
 above traditional stall speed) you command a large nose up elevator 
 deflection -- if you have enough elevator authority you can quickly 
 force the wing to a high alpha so that the wing stalls (at a much higher 
 than normal speed.)  What happens next is very similar to a spin: one 
 wing stalls before the other leading to a rapid roll.  But in this case 
 you have so much forward momentum that the result looks more like a 
 traditional aileron roll.
 
 Curt.

Partially right:

http://www.av8n.com/how/htm/snaps.html

Rudder is involved.

Jon



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

Snap roll:

This is indeed the recipe for a snap roll: starting from a speed slightly
above the stall, apply a sudden yaw with the rudder, apply opposite aileron,
and pull back on the yoke. SNAP! --- One wing stalls and the plane rolls
over.

[I liked the clever use of the word, recipe with the phrase snap *roll*]

This would be hard to model using lookup tables, but it might be possible
using JSBSim functions and a table or tables, together. Could be fun. I need
to think about this one. The first idea that comes to mind is that if the
aircraft speed minus the yaw rate times some characteristic lateral length
(span/2?) falls below the stall speed, then a rolling moment would be
generated - maybe a yawing moment, too.

Jon



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

2006-06-14 Thread Hugo Vincent

Sorry about that, prematurely hit send. Here is the link:http://forums.x-plane.org/index.php?showtopic=13050st=0Might be interesting, or maybe even relevant to modelling things like snap rolls in JSBSim.
Regards,Hugo Vincent.On 6/15/06, Hugo Vincent [EMAIL PROTECTED] wrote:
I came across this discussion about adding a new open source FDM toX-Plane, using CFD methods to get really really high fidelity models.On Wed, 2006-06-14 at 20:32 -0500, Jon S. Berndt wrote: Snap roll:
 This is indeed the recipe for a snap roll: starting from a speed slightly above the stall, apply a sudden yaw with the rudder, apply opposite aileron, and pull back on the yoke. SNAP! --- One wing stalls and the plane rolls
 over. [I liked the clever use of the word, recipe with the phrase snap *roll*] This would be hard to model using lookup tables, but it might be possible
 using JSBSim functions and a table or tables, together. Could be fun. I need to think about this one. The first idea that comes to mind is that if the aircraft speed minus the yaw rate times some characteristic lateral length
 (span/2?) falls below the stall speed, then a rolling moment would be generated - maybe a yawing moment, too. Jon ___
 Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

 This would be hard to model using lookup tables, but it might be possible
 using JSBSim functions and a table or tables, together. Could be
 fun. I need
 to think about this one. The first idea that comes to mind is that if the
 aircraft speed minus the yaw rate times some characteristic lateral length
 (span/2?) falls below the stall speed, then a rolling moment would be
 generated - maybe a yawing moment, too.

 Jon

We might also calculate alpha at a few points along the wing and key off of
that (partially) for roll and yaw moment deltas...

Jon



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

On Wed, 14 Jun 2006 20:22:05 -0500, Jon wrote in message 
[EMAIL PROTECTED]:

  Jon S. Berndt wrote:
   But, I'm also wondering if there is a way to obtain the same
   effect with a three-dimensional table. Can someone give a detailed
   describption of a snap roll?
  
  My understanding of a snap roll is that at some speed (probably well
  above traditional stall speed) you command a large nose up
  elevator  deflection -- if you have enough elevator authority you
  can quickly  force the wing to a high alpha so that the wing stalls
  (at a much higher  than normal speed.)  What happens next is very
  similar to a spin: one  wing stalls before the other leading to a
  rapid roll.  But in this case  you have so much forward momentum
  that the result looks more like a  traditional aileron roll.
 
 Partially right:
 
 http://www.av8n.com/how/htm/snaps.html
 
 Rudder is involved.

..rudder _may_ be involved, any assymmetry will do the job.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.




___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

2006-06-14 Thread Hugo Vincent

I came across this discussion about adding a new open source FDM to
X-Plane, using CFD methods to get really really high fidelity models.


On Wed, 2006-06-14 at 20:32 -0500, Jon S. Berndt wrote:
 Snap roll:
 
 This is indeed the recipe for a snap roll: starting from a speed slightly
 above the stall, apply a sudden yaw with the rudder, apply opposite aileron,
 and pull back on the yoke. SNAP! --- One wing stalls and the plane rolls
 over.
 
 [I liked the clever use of the word, recipe with the phrase snap *roll*]
 
 This would be hard to model using lookup tables, but it might be possible
 using JSBSim functions and a table or tables, together. Could be fun. I need
 to think about this one. The first idea that comes to mind is that if the
 aircraft speed minus the yaw rate times some characteristic lateral length
 (span/2?) falls below the stall speed, then a rolling moment would be
 generated - maybe a yawing moment, too.
 
 Jon
 
 
 
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

   My understanding of a snap roll is that at some speed (probably well
   above traditional stall speed) you command a large nose up
   elevator  deflection -- if you have enough elevator authority you
   can quickly  force the wing to a high alpha so that the wing stalls
   (at a much higher  than normal speed.)  What happens next is very
   similar to a spin: one  wing stalls before the other leading to a
   rapid roll.  But in this case  you have so much forward momentum
   that the result looks more like a  traditional aileron roll.
 
  Partially right:
 
  http://www.av8n.com/how/htm/snaps.html
 
  Rudder is involved.

 ..rudder _may_ be involved, any assymmetry will do the job.

Sounds like it. I've now read several accounts. There are at least two ways
to enter it. See this, for instance:

https://cnatra.navaltx.navy.mil/cnatra/folder5/T45/P-1287.PDF

Jon



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

Jon S. Berndt wrote:
 Partially right:

 http://www.av8n.com/how/htm/snaps.html

 Rudder is involved.
   

The link you quote describes a situation where you get into a snap 
roll/spin when you don't want to.  I had something similar happen when I 
was looping my R/C cub and tried to tighten up the bottom side of the 
loop a little too much.

But as far as I know, rudder isn't required.  It's just that rudder (or 
the lack of it (or compensating for change in rudder with aileron 
deflection)) can get you into trouble a lot quicker than you might realize.

Also note that if your left wing is dropping due to being on the edge of 
a stall and you try to compensate with right aileron, that will cause 
the left side aileron to deflect down.  This effectively increases the 
angle of attack a bit and can hasten the arrival of your spin.  But if 
you don't want to spin, you might consider correcting with rudder next 
time when you are at these low speeds. :-)

Curt.

-- 
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

2006-06-14 Thread Major A


Curt,

 I can do this in many of my R/C planes.  Just pull back the elevator to 

Ah, how come I haven't until now realized that you're into model
aircraft...? What a great collection of models you have, too.

 First I accelerate to full speed and pull the aircraft into a vertical 
 climb, then I induce a snap roll as I'm going straight up by pulling the 
 elevator back to maximum deflection.  The result is that I'm in a snap 
 roll/spin but heading straight *UP*.  If I do this at full throttle and 

That's often called a Lomcevak, I think, or at least one of the
millions of variations thereof.

 I should point out that I'm an average R/C pilot at best so there are a 
 *lot* of guys that can do a lot fancier and wilder stuff than I know how 
 to do.

This is a video I've just come across and it displays some of the best
flying I've ever seen, it's great fun to watch. Warning: you might
want to get one for yourself after seeing this (especially since the
kind of plane shown here isn't very expensive):

  http://www.rcgroups.com/forums/showatt.php?attachmentid=831005

:)

  Andras (building a 74 EDGE 540, perfect for snap rolls etc.)


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

 Also note that if your left wing is dropping due to being on the edge of
 a stall and you try to compensate with right aileron,

Right aileron as in trying to roll to the right?

 that will cause the left side aileron to deflect down.

Left aileron TED follows from right aileron TEU. The pilot causes the left
aileron TED movement. I'm not sure what you mean.

 This effectively increases the angle of attack a bit

Why? I'm trying to picture the mechanics of that and can't quite. Seems to
me like deflecting the left aileron down would cause the airflow to deflect
down and reduce the angle of attack - all other things remaining constant.
The hinge moment might also tend to reduce the angle of incidence of the
outer length of the wing, thus reducing alpha.

Jon



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

2006-06-14 Thread Major A


 This would be hard to model using lookup tables, but it might be possible
 using JSBSim functions and a table or tables, together. Could be fun. I need
 to think about this one. The first idea that comes to mind is that if the
 aircraft speed minus the yaw rate times some characteristic lateral length
 (span/2?) falls below the stall speed, then a rolling moment would be
 generated - maybe a yawing moment, too.

There are two simulators out there that model all kinds of weird
flight situations remarkably well -- Reflex XTR and Aerofly Pro
Deluxe. Unfortunately, both are payware, but they both have a
reputation among R/C modellers that they are as realistic as it
gets. I'm not sure what kind of physics they use, but maybe we can
learn something from them in one way or another. Just a thought.

  Andras


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

Disclaimer: my degree is in computer science, I only walk through the 
aerospace engineering department on they way to my driving simulator 
lab. :-)

Jon S. Berndt wrote:
 Also note that if your left wing is dropping due to being on the edge of
 a stall and you try to compensate with right aileron,
 

 Right aileron as in trying to roll to the right?
   

Yes, that's what I meant.

 Left aileron TED follows from right aileron TEU. The pilot causes the left
 aileron TED movement. I'm not sure what you mean.
   

TED = trailing edge down?

By right aileron I mean turning the wheel to the right and commanding 
the aircraft to roll right.

 This effectively increases the angle of attack a bit
 

 Why? I'm trying to picture the mechanics of that and can't quite. Seems to
 me like deflecting the left aileron down would cause the airflow to deflect
 down and reduce the angle of attack - all other things remaining constant.
 The hinge moment might also tend to reduce the angle of incidence of the
 outer length of the wing, thus reducing alpha.
   

I'm probably mixing up my terms here.  Imagine some cross section of the 
wing (ie. airfoil.)  This could be some complex shape, especially if it 
includes the aileron in a deflected state.  To compute wing incidence at 
that cross section, you need to come up with some sort of average zero 
incidence line fit through the airfoil shape.  There's probably a name 
for that and an official way to determine this zero incidence line.

If you look at the cross section of the wing (through a point that 
includes the aileron) when you deflect the aileron down (TED), you are 
increasing the angle of that average zero incidence line relative to 
the wind stream.  If you deflect the aileron up (TEU) you are reducing 
the average incidence of that section of the wing.

So now, take an airplane that is flying at a high angle of attack where 
the wing is struggling to stay ahead of a stall.   Now deflect one 
aileron down (TED).  You have just slightly (or perhaps more than 
slightly) increased the incidence of the wing across the area covered by 
the aileron.  All other things remaining equal which it will be in the 
short term, you have just increased the aoa on a portion of your wing, 
and if you are riding the edge already, it might be just enough to push 
you over into a snap roll.

Maybe said a different way, imagine your wing is riding on the edge of 
the amount of air it can push down without stalling.  Now you deflect 
the aileron down and try to push the air down even more.

For what it's worth, I experienced this first hand in my Piper Cub (R/C) 
model (so I was safely on the ground.)

I was attempting to do a loop, but in retrospect I started too low and 
too slow.  I got really slow over the top and due to my low altitude, I 
tried to tighten up the backside of the loop on the way down by feeding 
in some additional elevator. But the cub snapped hard on me. I released 
the elevator and got some speed and then pulled back again to avoid the 
ground and she started to snap again. But I somehow managed to find some 
sort of middle ground with the elevator to keep pulling out of the dive 
while maintaining just enough aileron authority to somehow save it. Both 
wing tips were literally inches from the ground at various points in the 
manuever and I was still flying right on the ragged edge of the stall. I 
was one tremble short of another full snap roll. The spectators claimed 
that ground effect saved me. :-) Somehow in the end I was back flying 
with no vegetation in the gear or wing tips. WHEW!

BUT!  Had I known then what I know now and steered with the rudder 
rather than the ailerons, it probably wouldn't have been nearly such a 
close call.

Curt.

-- 
Curtis Olsonhttp://www.flightgear.org/~curt
HumanFIRST Program  http://www.humanfirst.umn.edu/
FlightGear Project  http://www.flightgear.org
Unique text:2f585eeea02e2c79d7b1d8c4963bae2d



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

2006-06-14 Thread Major A


 BUT!  Had I known then what I know now and steered with the rudder 
 rather than the ailerons, it probably wouldn't have been nearly such a 
 close call.

There are a few very spectacular inadvertent stalls and spins and
suchlike in this video as well. It's actually quite funny to watch:

  http://www.rusjet.ru/video/krach.wmv

#2 is very much what happened to you, I think, with a slightly
different outcome.

  Andras


___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim

 Maybe said a different way, imagine your wing is riding on the edge of
 the amount of air it can push down without stalling.  Now you deflect
 the aileron down and try to push the air down even more.

Stupid me. I forgot something. OK, deflecting an aileron is like deflecting
a flap. If you look at a lift curve from a wing section you can see that
deflecting a flap (aileron) increases the lift coefficient, but you also
reduce your stall angle. That would be enough to do it for that portion of
the airfoil.

Jon



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim