[Flightgear-devel] Transfer function elevator/climb for root locusanalyse for JSBSIM

2005-09-30 Thread Rex
I am assuming that you want to avoid paying for MatLab, but they now 
have a full
flight simulator available from which you could derive the root-locus 
diagrams. 
(cost about US$1300 plus MatLab and Simulink.)


I am not sure what you mean by climb, but the effect of the elevator 
depends on
about four variables, at least, including the elevator angle, alpha, 
pitch angle, Qbar, etc. The
elevator affects the pitch-up, which in turn affects the climb rate. 

a text, such as Flight Stability and Automatic Control by Robert C. 
Nelson, has

what you want pretty well laid out.  If you can find a copy where you are.

I have had pretty good luck with some problems by simply looking in 
Google.  A lot

of engineering departments have analyses on line that would help you.

Good luck.

Rex du Pont


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Problem with HUD

2005-09-29 Thread Rex
I am having a problem porting a hud display that I wrote for use in 
FG8.0 up to 9.8.

It hangs at the instruction in drawHUD() :

for_each(HUD_deque.being(), HUD_deque.end(), HUDdraw());

with a segfault.  The problems seems to be that there are 18 labels in 
hudlabel.xml, all 18 of which pass the instruction, but the program 
carries HUD_deque.size() as 20!  Looks like it is looking for 
superfluous information.  Where does it set the deque size, and how 
could it be going wrong?


Thank you,

Rex du Pont
[EMAIL PROTECTED]

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] problem making FGFS/JSBSim

2003-01-24 Thread Rex
I just updated my RedHat to 8.0 from 7.3 and tried to recompile
a somewhat modified version of the JSBSim, and I am getting a mystery
message:  

make[2]: Entering directory `/home/Rex/J2/FlightGear-0.7.10/src/Cockpit'
Making all in built_in
make[3]: Entering directory 
`/home/Rex/J2/FlightGear-0.7.10/src/Cockpit/built_in'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory 
`/home/Rex/J2/FlightGear-0.7.10/src/Cockpit/built_in'
make[3]: Entering directory `/home/Rex/J2/FlightGear-0.7.10/src/Cockpit'
source='panel_io.cxx' object='panel_io.o' libtool=no \
depfile='.deps/panel_io.Po' tmpdepfile='.deps/panel_io.TPo' \
depmode=gcc3 /bin/sh ../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src  
-I/usr/local/include -I/usr/X11R6/include  -g -O2 -c -o panel_io.o `test 
-f 'panel_io.cxx' || echo './'`panel_io.cxx
cc1plus: warning: changing search order for system directory 
/usr/local/include
cc1plus: warning:   as it has already been specified as a non-system 
directory
panel_io.cxx: In function `FGPanelAction* readAction(const SGPropertyNode*,
  float, float)':
panel_io.cxx:186: conversion from `std::vectorSGPropertyNode_ptr,
  std::allocatorSGPropertyNode_ptr ' to non-scalar type 
`std::vectorconst
  SGPropertyNode*, std::allocatorconst SGPropertyNode* ' requested
make[3]: *** [panel_io.o] Error 1
make[3]: Leaving directory `/home/Rex/J2/FlightGear-0.7.10/src/Cockpit'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/Rex/J2/FlightGear-0.7.10/src/Cockpit'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Rex/J2/FlightGear-0.7.10/src'
make: *** [all-recursive] Error 1

It used to work, and now I get this.

Does anybody have any idea what is going on?

Thank you,

Rex du Pont
[EMAIL PROTECTED]


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] 3D model origin proposal

2002-12-16 Thread Rex



Rex du Pont wrote:

I've been watching this discussion for about a week. I am using the JSBSim
model on a 
real airplane development project, to give you some background.

Seems to me that the question is about how to make a 3D model look right
from outside, 
probably from a distance of several wingspans away. In that case, you do
not have to be precise
about the congruence of the point of rotation and the cg, so long as you
are not using the 
rotation point for any of the physics. I would guess that the cg is near
the 25% chord point, and 
within a foot or so of the center of the wing vertically, so that if you
know where that is relative to 
the nose, or other origin point, you can make it look right in flight. I'd
vote for 25% chord point 
on the wing center line for rotation. If the model uses the nose as a reference,
you would just 
have to know the correct offsets, or estimate them from a side view.

You could have a problem at or near the ground for the reasons discussed
before. On the ground you
rotate about the gear, not the cg. You could either accept having the wheels
sink into the runway 
(or float above it) or incorporate an "gear offset" when there is any WOW.
I suppose this could jerk the
plane onto the ground if the point of rotation is set low, but, on the whole
it would give you a pretty realistic flight. I suppose you could resolve
this by empirically setting the vertical CG position so that the 
gear looks right at rest, from outside, by cut and try. 

The FDM model must know where the CG is. The 3D view must know where the
wings are in relation
to the nose, etc. Where the MAC is on a swept wing is a matter of educated
guesswork, unless someone
tells you, but you could come pretty close visually.  I would suggest that
you try something like rotating in the air around something simple like the
25% chord guesstimate, on the centerline, and then adjust vertically to have
the gear just touch the ground at rest. How does the 3D deal with gear
extension? H. Try what looks right on the ground, then watch it take
off and see what further adjustments you need. 

Rex du Pont




Tony Peden wrote:

  --- Erik Hofman [EMAIL PROTECTED] wrote:
  
Jon Berndt wrote:

  
Well, to rotate the aircraft realistically the refference point


should 

  
be known by the 3D modellers, but that aside.

The rigid body rotates about the CG, not the aero ref. pt.

Even when in motion?

In the FDM's (all of them, AFAIK), yes. Always.In reality, the aircraft will rotate about the cg in air and some otherpoint if any of the gear are touching the ground.  During takeoffrotation and landing de-rotation, for example, the aircraft will rotateabout the main gear.

  It seems to me there would otherwise be no need for a refferencepoint.
  
  It's still needed.In order to calculate the moment coefficients from measured moments,one needs to set a point on the aircraft to take the moment arms from. This has traditionally been chosen as the point 25% of the way aftalong the mean aerodynamic chord.  The reasoning for this is that forlow speed aircraft, it is a reasonable estimate of the wing's center ofpressure (i.e. where you'd place the lift vector both chord- andspan-wise).  In truth, this location varies with (at least) the airfoilsection, wing planform, and Mach number, so when using it as a constantreference point we have to call it something different.  I chose tocall it the aero reference point.  And since someone might reducemeasured data using something other than the 1/4 chord of the MAC, thisnumber needs to be configurable.
  
Erik___Flightgear-devel mailing list[EMAIL PROTECTED]http://mail.flightgear.org/mailman/listinfo/flightgear-devel

__Do you Yahoo!?Yahoo! Mail Plus - Powerful. Affordable. Sign up now.http://mailplus.yahoo.com___Flightgear-devel mailing list[EMAIL PROTECTED]http://mail.flightgear.org/mailman/listinfo/flightgear-devel