RE: [Flightgear-devel] Re: Wing motion

2005-12-20 Thread Jon S. Berndt
  Unfortunately, so far it only works with solid (unsmoothed) objects.
  Looks like a plib bug to me, but I have yet to find the exact reason.

 Ahh, that would be a shame. I'm very much looking forward to see this in
 action (or better yet, see it in FlightGear).

 Erik

For wing flex (at least at first) I'm thinking that rotating the wing about
it's joint with the fuselage would be the easiest.

Jon


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


RE: [Flightgear-devel] C310 Update

2005-12-20 Thread Jon S. Berndt
 Hi Stuart,
 Thanks!
 How do you feel is the front-wheel steering (low speed, low rpm)?
 If I look from outside the wheel points to one direction but the action
 of the aircraft is very slow.
 At a little bit higher speed the a/c is sliding forward despite the
 wheel direction.
 Just a hint, nothing more.
 I also wish you and your family a peaceful and happy Christmas time.
 Georg EDDW

FYI, the coming version of JSBSim will be having very much improved ground
handling. Almost there ...

Jon


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


[Flightgear-devel] Sim Reset

2005-12-19 Thread Jon S. Berndt
When a sim reset is selected from the menu, what is the calling sequence to
the FDMs that follows? That is, which FGInterface functions are called (and
from where)? I thought that might be done from main.cxx, but I can't find it
at the moment.

Jon


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


RE: [Flightgear-devel] Re: Sim Reset

2005-12-19 Thread Jon S. Berndt
 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
 237 {
 
 (gdb) where
 #0  0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
 #1  0x0812a812 in ~FGFDMExec (this=0xbd3d3e8) at FGFDMExec.cpp:173
 #2  0x08113095 in ~FGJSBsim (this=0xb4b39e0) at JSBSim.cxx:308

What on earth is logstream?

Jon


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


[Flightgear-devel] Wing motion

2005-12-18 Thread Jon S. Berndt
Here's one I'm throwing out simply for discussion, and because it's occurred
to me several times in the past:

Would it be possible to change the visual appearance of wing flex during
flight? I thought it might be interesting to give the wing an amount of flex
dependent on load factor and wing stiffness, etc.  I've got some simple
equations in my old aeroelasticity textbook that might provide a simple
enough algorithm.

Just a thought...

Jon


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


RE: [Flightgear-devel] C310 Update

2005-12-18 Thread Jon S. Berndt
 Move the CG forward a bit, at least a 10--15. (the correct CG location
 should be taken from the type certificate, which I haven't been able to
 find on a quick google) The plane flies a lot better then. (better
 stability and cruise alpha, when it's not flying on the stabiliser) This
 also puts a little more weight on the nose gear, so it steers better while
 taxiing. As it is now, the CG is actually aft of the lift.
 (AC_CGLOC is, if
 I understand it correctly, the CG location without the
 AC_POINTMASSes, i.e.
 empty plane?) A blind guess on the CG limits would be something around
 15--35% of MGC perhaps?

Good suggestion, Joacim:

[Make sure link appears on one line]

http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/
F7F7762D8AD84F2A86257013005A9A68/$FILE/3A10.pdf

The TCDS suggests the CG should be in the range, 37-42 inches (assuming our
datum is the same).

Jon


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


[Flightgear-devel] STL errors?

2005-12-13 Thread Jon S. Berndt
In trying to rebuild FlightGear under Cygwin, I'm getting all sorts of
errors now when I get to compiling the older JSBSim code, beginning with
FGDeadband.cpp. There errors are these:

stl_deque.h:446: error: expected unqualified-id before '(' token
deque.tcc:699: error: expected unqualified-id before '(' token
streambuf.tcc:54: error: expected unqualified-id before '(' token
locale_facets.tcc:514:57: macro min requires 2 arguments, but only 1 given
istream.tcc:147: error: ISO C++ forbids comparison between pointer and
integer
...

Strange. Anyone else see things like this?

Jon



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


RE: [Flightgear-devel] STL errors?

2005-12-13 Thread Jon S. Berndt
 Do you have NOMINMAX defined and

 #ifdef HAVE_CONFIG_H
 #include config.h
 #endif

 at the beginning of every .cpp/.cxx file ?

 -Fred

Not as far as I know. But this is straight from an unaltered current CVS
distribution of FlightGear. I've got the very latest compilers/tools from
Cygwin, so I thought maybe something had changed with g++.

Note that new JSBSim compiles fine on my machine (same files). Maybe I'll
dispense with the old JSBSim code in FlightGear immediately. I just wanted
to get the basic distribution compiled as-is.

Jon


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


Re: [Flightgear-devel] Re: JSBSim broken?

2005-12-11 Thread Jon S Berndt

On Sun, 11 Dec 2005 15:02:13 +0100
 Melchior FRANZ [EMAIL PROTECTED] wrote:

* Dave Culp -- Sunday 11 December 2005 05:05:
The reverser method has changed.  You set the reverser now by 
adjusting the 
/fdm/jsbsim/propulsion/engine[x]/reverser-angle [...]

The property /engines/engine[x]/Reverser  doesn't work any more.


It's the job of the glue code (JSBSim.cxx) to map internal values
to standard fgfs properties. This internal /fdm/jsbsim/foo thingy
will hardly ever be supported by the keyboard/joystick bindings.

m.


I'm not sure I agree. There are standard items that all aircraft 
share, and those are supported in the FGInterface instance. However, 
there will be special switches and items that don't belong in the 
FGInterface instance, but are set directly from an instrment panel 
definition to the property functionality in the FDM. The L410 is like 
that very much. To map the superset of all aircraft switches and 
controls in the interface is not workable.


Maybe I'm not understanding your meaning, though ...

Jon

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


RE: [Flightgear-devel] Re: JSBSim broken?

2005-12-11 Thread Jon S. Berndt
 I'm convinced Melchior aimed at pointing out that FDM-specific names
 for non-FDM-specific properties don't belong into FlightGear.

 FlightGear supports more
 than just one FDM. There are conventions for where to find properties.
 Engine stuff is in /engines/. There are setups relying on information
 being available in the same places, no matter which FDM is used.

Yes, this I agree with.

Jon


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


[Flightgear-devel] OpenGL and new video drivers

2005-12-01 Thread Jon S Berndt
I just installed a new video card (eVGA GeForce 6800) on my Windows 
2000 box and after installing the drivers I find that OpenGL 
applications crash. I've uninstalled (in safe mode) and reinstalled 
(in safe mode) earlier versions of the drivers, but no luck, so far. I 
am trying to find the solution through the manufacturer's web site and 
support mechanism, but any suggestions given here would be much 
appreciated, as well - I know many of you may have gone through the 
same thing.


Jon

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


Re: [Flightgear-devel] b1900d FDM

2005-01-18 Thread Jon S Berndt
On Tue, 18 Jan 2005 16:47:04 +
 Dave Martin [EMAIL PROTECTED] wrote:
Is anyone currently working on the b1900d FDM?
The reason I ask is that while the model is gorgeous, the FDM is 
relatively broken.
I know there is a YASim model, and I've wanted to work on a JSBSim 
model for some time, but as the coordinator for JSBSim, editor for the 
Houston AIAA chapter newsletter, trying to get somewhere on the 1st 
quarter JSBSim newsletter, being in the middle of a job transition, 
and being a father of four ... it's a near miracle that I've almost 
completed the code transition to support JSBSim config file v2.0. :-)

If you are interested in doing a JSBSim version of the B1900, I can 
probably put together a data packet to support that work.

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


[Flightgear-devel] OT: Huygens

2005-01-14 Thread Jon S Berndt
This is a bit off-topic for FlightGear-devel, but I thought it might 
be worth mentioning that the first pictures from the Huygens probe 
have returned from Saturn's moon Titan via Cassini relay. You can see 
them here:

www.spaceflightnow.com
-and-
http://www.esa.int/esaCP/index.html
The overall first impression of the images (one from 16 km and one 
from the surface) seems not inconsistent with some kind of flow. IMHO, 
the rocks look like river rocks. The images are fascinating, and 
there's much more to come. Nice job ESA!

Jon

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


Re: [Flightgear-devel] Is this usefull for flightgear/jsbsim?

2005-01-12 Thread Jon S Berndt
On Wed, 12 Jan 2005 22:10:47 +0100
 [EMAIL PROTECTED] (Wolfram Kuss) wrote:
Erik wrote:
This still might be useful if you can get all the moments and 
coefficients from it. Then you would be able to create a JSBSim 
configuration file from the model geometry.
The idea of using the gfx model you need to do anyone (or one of the
thousands or ten thousands you find on the internet) and 
automatically
get the config file. It would not matter if it takes over night or
even if it takes a week.

However, CFD programs need a watertight geometry. I would guess 
that
far in excess of 90% of models are not. For example, each edge needs
to have two neighbour faces.
There's always DATCOM+:
www.holycows.net/datcom
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Flightgear in AIAA's, Aerospace America

2005-01-11 Thread Jon S Berndt
In this month's AIAA monthly publication, Aerospace America, 
FlightGear receives a mention in the Systems and Software column. 
Here is a link to that article:

www.aiaa.org/aerospace/images/articleimages/pdf/systemsjanuary05.pdf
This is the URL for Aerospace America:
http://www.aiaa.org/aerospace/TableOfContents.cfm
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Happy New Year

2005-01-05 Thread Jon S Berndt
On Wed, 05 Jan 2005 10:17:53 -0600
 Curtis L. Olson [EMAIL PROTECTED] wrote:
It's the start of a new year, so I thought it might be fun to look 
back on 2004 and recall some interesting FlightGear facts and events, 
and then look forward a bit to the upcoming year.
Heh. I have been meaning to post a similar review for JSBSim. One 
thing that I'll mention is that December 2004 was our heaviest month 
yet (given the four year history we have on SourceForge) for web site 
traffic (averaging 100 hits/day for the month), and our development 
mailing list is pushing around 90 subscriptions - also a high.

I'll write more on the sub list and in the upcoming newsletter.
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] EasyXML problem?

2004-12-28 Thread Jon S Berndt
I've encountered an unexpected problem with the class I have derived 
from EasyXML. In one of the configuration files I have, the following 
lines are present:

function NAME=aero/coefficient/Cndr
descriptionYaw moment due to rudder/description
product
propertyaero/qbar-psf/property
propertymetrics/Sw-sqft/property
propertymetrics/bw-ft/property
propertyfcs/rudder-pos-rad/property
value-0.043/value
/product
/function
When I parse this construct I find that the last tagged property does 
not get parsed correctly. What happens as the program is actually run 
shows this:

DATA LINE: ***=fcs/rudde=***
  Parsing property name: fcs/rudde
FGPropertyManager::GetNode() No node found for fcs/rudde
You can see that the fcs/rudder-pos-rad property name is only 
partially read. If I go back and look at the overridden data() 
function in my XMLVisitor-derived class, I see that I did this:

void FGXMLParse::data (const char * s, int length)
{
  const char *local_string = s;
  data_string = local_string;
  data_string.resize(length);
  if (data_string.find_first_of(VALID_CHARS) != string::npos)
current_element-AddData(data_string);
}
I know it's not pretty and certainly better approaches are solicited 
from readers. Reading the documentation in the props.hxx file I see 
this:

   * Note that character data may be chunked arbitrarily: the
   * character data content of an element may be returned in one
   * large chunk or several consecutive smaller chunks.
So, I guess I've been lucky so far that the data I have gotten - 
except in this particular case - has been chunked together. I'm a 
little stumped as to how I can make sure that I get all the data for 
an element and store it as an STL string for later reading.

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


Re: [Flightgear-devel] control surface normalization

2004-12-17 Thread Jon S Berndt
On Fri, 17 Dec 2004 15:26:26 +0100
 Gordan Sikic [EMAIL PROTECTED] wrote:
Hi Jon,
Once more, do not make general statements, based on a few examples. 
Jon wrote:
One hundred percent of the control law diagrams ...
emphasisI have seen/emphasis
that include pilot inputs use force.

There are _many_ FCS's out there, not using input you just described. 
Fore examples, take a look at the Flight control and simulation, 
the book with examples that are completely based on F16 dynamics.
Steven's and Lewis? F-16? I don't know what Steven's and Lewis are 
saying (I'll take a look later today), but I *am* referring to the 
F-16 as _one_ example, and I was referring to the manufacturer's 
(General Dynamics) FCS diagrams, not a textbook interpretation. The 
manufacturer's diagrams show stick force as input.

I don't mean to say that this is necessarily a standard, or that it is 
always this way, or even usually this way, but it makes sense and is 
easy to work with. Can you give an example of an alternative approach? 
I am curious.

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


Re: [Flightgear-devel] control surface normalization

2004-12-17 Thread Jon S Berndt
On Fri, 17 Dec 2004 10:07:47 -0600
 Curtis L. Olson [EMAIL PROTECTED] wrote:
Jon, the problem is:  how does the interface know how to normalize 
the control surface positions?  Where does it read the maximum limits 
from?  The FDM is really the only piece that is going to know this 
information.
This is **exactly** one of the big concerns I have. But, it cuts both 
ways. Using normalized position, NIETHER the FDM NOR the animation 
system knows where to place the elevator, for instance, unless two 
pieces of information are present. This is what I've been trying to 
illustrate for some time. For aerosurfaces, an absolute measurement 
makes sense (such as degrees or radians) for most aerosurfaces because 
it uniquely determines orientation. It is true that the FDM usually 
knows what the phyisical limits are for an aerosurface, but if we 
normalize the elevator or rudder setting we cannot simply pass the 
normalized value, we have to pass the limit as well. And I'm not 
prepared to continue to do this in the FDM proper. The presence of all 
the special purpose normalization routines is really confusing. 
Whatever is done will have to be done in the interface.

Additionally, what on earth are the animators using to turn normalized 
values into degrees, now? JSBSim is certainly not now passing in limit 
information. I suppose JSBSim defines one set of limits and - 
hopefully - the 3D modelers are using the same value. But, what if the 
limits are changed in the flight model?

One thing we could do is to simply define a NORMAL_FACTOR that 
corresponds to a constant, say 30 degrees. Then always normalize in 
the interface w.r.t. that.

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


Re: [Flightgear-devel] control surface normalization

2004-12-17 Thread Jon S Berndt
On Fri, 17 Dec 2004 10:05:04 -0600
 Curtis L. Olson [EMAIL PROTECTED] wrote:
The FDM may choose to carry along with that abstraction (which makes 
sense) because you are concerned with getting the right performance 
when the lever is in the 30 degree position.  It all works out in the 
end, but saying the flaps are at 30 degrees is an extreme over 
simplification.
Yes, this is true. You're right, too, that we don't care about the 
_visual_ position of the flaps, but what the flaps have been commanded 
to and what aerodynamic properties result from that setting. But at 
least we have that. Saying we are at 30 degrees flaps in a range from 
0 to 60 may not be concrete, but it beats simply saying that the flap 
setting is 0.5.

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


Re: [Flightgear-devel] CVS Error?

2004-12-17 Thread Jon S Berndt
On Fri, 17 Dec 2004 11:35:24 -0800
 John Wojnaroski [EMAIL PROTECTED] wrote:
That was it.
The other modules explicitly call out the include directive and 
ifdef, but they appear to be excluded in the JSBSim files ?

seems like something is missing/mis-set on my system , if others are 
not having this problem. At any rate, adding it in for the 
complaining files will work for the interim

Thanks
John W.
Thanks for pointing this out, and thanks to Norman for pointing out 
the fix. It looks like this was inadvertently removed at some point - 
probably by me. We need to work on eliminating the need for the 
snprintf function if it's not portable.

Thanks,
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] control surface normalization

2004-12-17 Thread Jon S Berndt
On Fri, 17 Dec 2004 21:51:56 -
 Vivian Meazza [EMAIL PROTECTED] wrote:
How do FDMs handle Fowler flaps? i.e. the first part of the action 
extends the flap rearwards without any rotation, acting only to 
increase wing area, then for the rest of the action rotate downwards?

Easy enough to 3d model with a normalized input: translation then 
rotation.
Now that's a good example. I'd have to think about it a bit. I don't 
have an answer on that one.

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


Re: [Flightgear-devel] control surface normalization

2004-12-17 Thread Jon S Berndt
On Fri, 17 Dec 2004 22:59:35 -
 Vivian Meazza [EMAIL PROTECTED] wrote:
Lee Elliott wrote
  [snip...]

 How do FDMs handle Fowler flaps? i.e. the first part of the
 action extends the flap rearwards without any rotation, acting
 only to increase wing area, then for the rest of the action
 rotate downwards?

 Easy enough to 3d model with a normalized input: translation
 then rotation.

 Just curious

 Vivian
That's exactly one of the problems I'm trying to work out wioth
the B-52.  The flaps have only two settings - fully extended or
fully retracted, and it took 60 sec for full traversal.  IIRC,
the first 60%, or so, just increases the wing area, with the
remainder changing the downwash.  I've no idea what YASim is
doing, as far as numbers go, but it seems to be behaving close
according to anecdotal evidence.
Probably what we'd do for JSBSim if we were going to model this is to 
figure out the aero coefficient increments due to flap extension to 
specified points (perhaps pseudo degrees or in a range from 0 to 1). 
We might do this using DATCOM+, or using standard equations. Then we'd 
use a kinematic component to introduce the effects at runtime. For the 
next version of JSBSim we might even introduce the effects using 
equations, specified in the config file.

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


Re: [Flightgear-devel] control surface normalization

2004-12-16 Thread Jon S Berndt
On Thu, 16 Dec 2004 11:15:52 -0800
 Richard Harke [EMAIL PROTECTED] wrote:
A rotation whether in degrees or radians only makes sense if the 
axis of rotation is specified. This would have to be on a per aircraft 
basis. Also I'm sure that many if not most control surfaces do not
simply rotate about a single axis but involve sliding motion and
rotation of multiple parts and often, rotation while sliding.
No, this is only really relevant for the 3D model. But even 
complicated multi-segment flaps are indexed by degrees with respect to 
aero coefficients. Further, the flight control system still outputs 
degrees - not normalized units. Once you get to a certain level of 
detail of course the signal to an actuator might be in volts. How do 
you normalize that? For any normalized aerosurface command, you still 
need two pieces of data to make an absolute: the normalized value and 
the travel range. Plus, as I've mentioned before, if you output in 
degrees (or radians) you are outputting an absolute, which is also 
eeffectively what is require for the rendering system directly. When I 
did IRIX GL programming ten years ago the API call used degrees to 
rotate. Converting to a normalized value, then back again is a waste.

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


Re: [Flightgear-devel] control surface normalization

2004-12-16 Thread Jon S Berndt
On Thu, 16 Dec 2004 18:21:24 +0100
 Gordan Sikic [EMAIL PROTECTED] wrote:
I have seen (and I've seen more than few) control law diagrams 
taking some generalized input (0-1 range), taking target speed, or 
attitude, or something,... but havent seen any, taking as a input
force that pilot has to produce. Could you pls give some pointers? I'd
like to take a look; it's never to late to learn something new :)

As far as the force in the stick is of concern, I've seen exactly
oposite situation: one has position of the stick, speed of the 
stick, dynamic properties of the linkage, and all data from FDM. Using 
those as input, force to be produced on the stick is calculated, and 
generated.
Look here at the X-15 data and FCS diagram: 
http://jsbsim.sourceforge.net/X-15Aero.html

The USAF F-16 (Block 40) FCS diagram is the same way: stick force is 
the input. Same with Space Shuttle control Law diagrams.

The JSBSim X-15 model simulates the X-15 control laws as shown in the 
link above. We take the -1 to +1 joystick input from FlightGear and 
turn it into a stick force, mapping to the force range described in 
Etkin's book as a sort of standard.

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


Re: [Flightgear-devel] control surface normalization

2004-12-16 Thread Jon S Berndt
On Thu, 16 Dec 2004 20:47:03 -
 Jim Wilson [EMAIL PROTECTED] wrote:
Jon's concern is quite valid, but there are problems.   As I work 
through
these concepts in my mind,  I can see that although the current 
method sounds
more complicated for the 3D animator,  having to deal with the real 
values
could be a lot worse (at least with the current architecture).
For simple aerosurface movements I fail to see how it could be 
anything but easier. For more difficult cases, whether you are scaling 
an angle or a normalized value, it should be similar.

It might be useful for someone to work through the values as that 
would be
report for the various stages of deployment on a 747 flap system. 
As Richard
message suggests here the detail required by the 3D modeler is 
sometimes quite
a bit more than what is required by the FDM.
Also, ask yourself the question, does the normalized value of, say, 
0.5 really correspond to 30 degrees of flaps when the total range is 0 
to 60?

Also, to have some objects reported normalized and other objects 
reported
actual would be too confusing...even if the distinctions and reasons 
were
logically sensible.  In the long run we'll benefit the most from 
consistency
even if it means more work at the FDM interface.
Not sure I agree here. It should not be a big deal to have two 
subclasses, one to handle normalized and one to handle not normalized.

It's not such a big deal to me except in that I don't want the FDM to 
be dealing with things it does not need to be dealing with - I want to 
work towards reducing excess baggage from JSBSim proper. I'd be 
content with moving normalization into the interface class.

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


Re: [Flightgear-devel] control surface normalization

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 12:01:23 -0500
 Norman Vine [EMAIL PROTECTED] wrote:
It is realy quite simple 

you either have 

1) an abstract class with 'Normalized units'
class Control
   or 
2) a bunch of specalized classes
class Angle_Controller
class Toggle_Controller
class Percentage_Controller
etc .

Both schemes have advantages
Quick question 
Do valves take 1 or 2 full rotations of the handle to fully open ?
Yes, I agree that there are output (from the FDM perspective) 
parameters that operate on a 0 to 1 basis. Even in our aero 
coefficient specification, landing gear effects, for example, are 
based on a 0 to 1 range. Aerosurfaces are different, though. Plain 
flap deployment is referenced via angle. Even complex flap 
arrangements are referenced by angular measurement in degrees - I have 
not personally seen nor heard of flaps being referenced via a 0 to 1 
normalized range. Spoilers also are referenced in degrees, from what I 
have seen (maybe Dave Culp can chime in here, and Tony). I think there 
is a use for both types of actuators, both linear and angular. I'd 
much rather see them referenced via native (or more native) 
variables.

Also, again your (valve) example is for an input control, not an 
output control that is fully defined by a subsystem (FDM). We (FDM) 
take normalized joystick inputs (0 to 1) because there are many 
joystick types and it makes sense to accept a zero or 1 and turn that 
into the value we need. We have control over that. We don't need to 
add special code for that. But our output for aerosurfaces is (like I 
said before) in the lowest common denominator value when we can ship 
it out - in degrees.

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


Re: [Flightgear-devel] control surface normalization

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 12:30:25 -0500
 Norman Vine [EMAIL PROTECTED] wrote:
Curtis L. Olson writes:
I think we are limiting the discussion here to only flying control 
surface positions, i.e.
As you point out those are only a small subset of the 
Control class abstaction.

So specialize these if esired but 
IMO the 'slippery slope principal' is in play here
It's a matter of not trying to fit a square peg into a round hole. 
Consideration of a subclass here is warranted.

BTW  It is peculiar how one of the argument for using degrees
because it cuts down on 'conversion code'  in SimGear is not 
applied to using for Geocentric Coordinates internally as SimGear 
and the FDMs go to great pains to pass everything  as lat lons 
which requires duplicate conversions on both ends of the pipe :-)
?? Not sure I can parse this sentence. Can you rephrase?
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] control surface normalization

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 11:16:32 -0800
 John Wojnaroski [EMAIL PROTECTED] wrote:

And then there are slats that deploy as a function of airspeed/AOA; 
e.g; Sabreliners
This is irrelevant, also - at least for JSBSim. In this case, the 
slats would be automatically deployed as directed by the flight 
control system control laws, and the actual position would be 
referenced by degrees.

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


[Flightgear-devel] Re: FCS normalization

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 14:51:07 -0500
 Norman Vine [EMAIL PROTECTED] wrote:
Jon S Berndt writes:
This is irrelevant, also - at least for JSBSim. 
That is an excellent observation
FGFS is more then JSBSim though :-)
Norman
Absolutely. And JSBSim is used by more than FlightGear - which leads 
to part of the concern I have. FlightGear should not require the FDM 
to massage values that it should be massaging itself.

Abstraction in object-oriented design has been referred to as the the 
elimination of the irrelevant and the amplification of the essential. 
All FDMs I have worked with or am aware of (except, perhaps YASim) 
output control surface deflections in degrees, and for good reason: 
it's natural, it's physical. From the point of view of JSBSim, 
normalized aerosurface deflections are unnatural and irrelevant. The 
overhead and baggage code causes confusion and obfuscates the 
operation of flight control code. It clutters the code. I have no 
problem with FlightGear doing whatever it wants to with the values we 
send, but I remain skeptical about using normalized values as a 
common transport device for the actual physical value.

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


[Flightgear-devel] Re: FCS normalization

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 14:51:07 -0500
 Norman Vine [EMAIL PROTECTED] wrote:
Jon S Berndt writes:
This is irrelevant, also - at least for JSBSim. 
That is an excellent observation
FGFS is more then JSBSim though :-)
Norman
Absolutely. And JSBSim is used by more than FlightGear - which leads 
to part of the concern I have. FlightGear should not require the FDM 
to massage values that it should be massaging itself.

Abstraction in object-oriented design has been referred to as the the 
elimination of the irrelevant and the amplification of the essential. 
All FDMs I have worked with or am aware of (except, perhaps YASim) 
output control surface deflections in degrees, and for good reason: 
it's natural, it's physical. From the point of view of JSBSim, 
normalized aerosurface deflections are unnatural and irrelevant. The 
overhead and baggage code causes confusion and obfuscates the 
operation of flight control code. It clutters the code. I have no 
problem with FlightGear doing whatever it wants to with the values we 
send, but I remain skeptical about using normalized values as a 
common transport device for the actual physical value.

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


Re: [Flightgear-devel] control surface normalization

2004-12-15 Thread Jon S Berndt
Curt wrote:
But Jon, this statement seems to run counter to your overall 
argument.  Slats at least on many of the aircraft I've seen deploy 
linearly.   In other words they are on some sort of rail mechanism 
and slide out away from the leading edge of the wing in a linear 
motion.  They aren't attached with a hinge, there's no rotation at
all.  So in this case representing linear motion with some arbitrary
angle seems a lot worse than representing angles with normalized 
values.
You're right - I had in my mind that we were discussing spoilers - not 
slats. Slats could be similar to landing gear, working in a 0 to 1 
range.

In the case of YAsim, you may need to dig in and get a better 
understanding of it, but essentially, the way it works, it does not
need to know deflection angles.
Yes, I'm sure it's a pretty good approximation, but IMHO this is 
sloppy. In flight simulation you want to know deflection angles for 
any of a number of reasons. And, again, in some flight control systems 
you might have hardware or software limits placed on the aerosurface 
excursions. Does YASim arbitrarily choose the limits? Which limits? 
Where does the rendering system get the limits so it knows what the 
maximum travel means? The point is: if you take angular deflections 
from the FDM, you have all you need right there; angular measurements 
are used to do the drawing. If YASim specifies some range of travel 
that represents full deflection, then it can also easily pass you 
degrees deflection for an elevator, for instance.

As you pointed out earlier, elevator, rudder, aileron, flaps - those 
items are always or almost entirely always referenced in angular units 
- exactly the units needed for drawing, and native units that the FDM 
outputs. It seems to me that it would be polluting the property tree 
to provide these in normalized coordinates.

I think what I'd like to do for now is to put the normalization for 
these parameters outside of JSBSim and into the FGJSBSim interface 
code. But, I'll look at that some more before doing so.

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


Re: [Flightgear-devel] Real Piper Data

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 09:10:03 -0500
 David Megginson [EMAIL PROTECTED] wrote:
A Piper owner trying to have is PA-28-201 (Arrow) repaired managed 
to get this concrete information from Piper:

Dear Sir:
There is not an off-set of the vertical fin or the stabilator on the
PA28R-201. The fin is should be vertical to center line and the 
stablilator
should be horizontal to the ground when the aircraft is straight and 
level.
The only off-set would be the wing twist and the engine is off set 
by
approximately 3 degrees to the right of center and approximately 4 
degrees
down.
Excellent stuff. This is quite easy to adjust in JSBSim.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] control surface normalization

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 10:41:27 -0500
 Norman Vine [EMAIL PROTECTED] wrote:
Jim Wilson writes:

And the Simgear 3D animation code is all about taking those 
normalized values
and translating them to a representation of degrees movement.  On 
the surface,
this doesn't make sense to me either.
I can think of no other generalized expression of a 'control's 
state' 
whether it be rotation, fluid pressure, amps what ever :-)

Once you start specializing there is no end and IMO using the
Normalized Values makes perfect sense for the abstract Control 
Module.

Simple translators from Normallized to Actual value are all that is 
needed
and are already instantiated on the FGFS side.  Client applications 
such
a JSBSim can easily implement wrappers when talking to FGFS
Your example is irrelevant. Fluid pressure cannot be seen. Amps cannot 
be seen. Neither Amps nor fluid pressure are reported on a zero to one 
scale. Aerosurfaces can be drawn and seen, and that's not done on a 
zero to one basis either. Like I said, there are some things that can 
be done on a zero to one basis, such as landing gear deployment. But, 
aerosurfaces are reported in degrees, regardless of whatever aircraft 
it is, it's already generalized to its lowest common denominator. 
Why it should be further reduced and then reassembled to the exact 
same value (one hopes) later on when rendered via SimGear - that's 
defies description, IMHO.

It is true that we can pollute our code (a.k.a. implement wrappers) 
to satisfy FlightGear, but why? We know what the control surface 
limits are. So, what do we do? Pass a normalized value AND the 
aerosurface limits so they can be reconstructed later? Why not just 
pass the raw value and be done with it?

Code that massages physical parameters to make up for shortcomings in 
the rendering/animation system doesn't belong in the FDM. If it 
doesn't belong in SimGear or on the FlightGear side, it belongs in the 
FGInterface class - but I don't think it even belongs there.

I know this sounds forceful, and I don't mean to step on any toes 
here, I just feel strongly about this.

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


Re: [Flightgear-devel] control surface normalization

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 17:21:13 -
 Vivian Meazza [EMAIL PROTECTED] wrote:
A quick search revealed that most, if not all, the 3d models in the 
current inventory use normalized values for animating the control
surfaces. 
See, this further raises a red flag for me. How does the 3D model know 
how far to move the aerosurface? What does the normalized value 
represent? This requires (like the VRP) more communication between the 
flight modeler and the 3D modeler. Are they both using the same values 
for the maximum angular range for an aerosruface - that is, the value 
that 1 represents? There are software limits. There are hardware 
limits. Which one is being used by the 3D modeler? It seems to me that 
the sensible thing to do is to simply use the angular value provided 
by the FDM - the one that is being used to determine the forces and 
moments. To do otherwise invites errors and confusion, IMHO.

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


Re: [Flightgear-devel] control surface normalization

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 18:22:30 -
 Vivian Meazza [EMAIL PROTECTED] wrote:
There are several points here. 

1. The fact is that most 3d (I think all, but I haven't checked) 
rightly or wrongly already use normalized values. It would be a
significant task to change.
Agreed. This is a consideration. If the FDMs can divest themselves of 
the need to provide normalized values, I don't care what is done on 
the other side of FGInterface.

2. I don't think we tell YASim the correct angles to use. Therefore 
the normalized output, factored to produce the correct visual angles,
is the way to do it right now.
How does YASim know how far an aileron can deflect? How does 
FlightGear know how far to deflect the aileron? The FDM needs to know 
and use control surface deflection in degrees (or radians) - 
normalized values won't cut it for flight modeling. Since the FDM 
knows truth, it can be the one-stop supplier for this angle - rather 
than normalizing it (based on what?) and shipping that to 
FlightGear/SimGear where it must be told how to de-normalize the 
normalized value for display.

3. For consistency, and remember that some 3d models are used with 
both YASim and other FDMs, we need normalized values.
This is just plain wrong. If an aircraft can deflect the elevator +/- 
30 degrees that's the way it is. Regardless of FDM. We are talking 
about absolutes, here, not some arbitrary limit decided upon by the 
FDM. Even if the FDMs use different values for elevator deflection 
limits, the aircraft would fly based on the deflection actually made, 
and the 3D model will show what the FDM says it is flying to. Item #3 
here is a non-issue.
 
4. It doesn't matter where the conversion is done. If FG is the only 
user of normalized values, it makes sense to do it there. 
Yes, and that's my point. But there is a little more to it than that - 
it's about accuracy. If the FDMs abandon the provision of normalized 
values, what will FlightGear do with what is provided? If JSBSim sends 
FlightGear a 20 degree elevator deflection, what does it normalize 
that value based on? FlightGear will need to be provided with the 
maximum travel for aerosurfaces. Since teh FDM will also work with 
these maximums, this could introduce another point of failure.

I have no doubt that this point was vigorously debated at some point 
in the past, and for good reasons we are where we are. We need to
revisit those discussions and revalidate the decisions before making
any change.
I would think we would have discussed this in the past, but I don't 
remember having done so. Normalized values were introduced in JSBSim 
about 2 years and 9 months ago, according to our CVS logs.

Best regards,
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] control surface normalization

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 14:51:07 -0500
 Norman Vine [EMAIL PROTECTED] wrote:
Jon S Berndt writes:
This is irrelevant, also - at least for JSBSim. 
That is an excellent observation
FGFS is more then JSBSim though :-)
Norman
Absolutely. And JSBSim is used by more than FlightGear - which leads 
to part of the concern I have. FlightGear should not require the FDM 
to massage values that it should be massaging itself.

Object-oriented design has been referred to as the the elimination of 
the irrelevant and the amplification of the essential. All FDMs I 
have worked with or am aware of (except, perhaps YASim) output control 
surface deflections in degrees, and for good reason: it's natural, 
it's physical. From the point of view of JSBSim, normalized 
aerosurface deflections are unnatural and irrelevant. The overhead and 
baggage code causes confusion and obfuscates the operation of flight 
control code. It clutters the code. I have no problem with FlightGear 
doing whatever it wants to with the values we send, but I remain 
skeptical about using normalized values as a common transport 
device for the actual physical value.

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


Re: [Flightgear-devel] control surface normalization

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 14:51:07 -0500
 Norman Vine [EMAIL PROTECTED] wrote:
Jon S Berndt writes:
This is irrelevant, also - at least for JSBSim. 
That is an excellent observation
FGFS is more then JSBSim though :-)
Norman
Absolutely. And JSBSim is used by more than FlightGear - which leads 
to part of the concern I have. FlightGear should not require the FDM 
to massage values that it should be massaging itself.

Object-oriented design has been referred to as the the elimination of 
the irrelevant and the amplification of the essential. All FDMs I 
have worked with or am aware of (except, perhaps YASim) output control 
surface deflections in degrees, and for good reason: it's natural, 
it's physical. From the point of view of JSBSim, normalized 
aerosurface deflections are unnatural and irrelevant. The overhead and 
baggage code causes confusion and obfuscates the operation of flight 
control code. It clutters the code. I have no problem with FlightGear 
doing whatever it wants to with the values we send, but I remain 
skeptical about using normalized values as a common transport 
device for the actual physical value.

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


Re: [Flightgear-devel] control surface normalization

2004-12-15 Thread Jon S Berndt
On Wed, 15 Dec 2004 14:51:07 -0500
 Norman Vine [EMAIL PROTECTED] wrote:
Jon S Berndt writes:
This is irrelevant, also - at least for JSBSim. 
That is an excellent observation
FGFS is more then JSBSim though :-)
Norman
Absolutely. And JSBSim is used by more than FlightGear - which leads 
to part of the concern I have. FlightGear should not require the FDM 
to massage values that it should be massaging itself.

Object-oriented design has been referred to as the the elimination of 
the irrelevant and the amplification of the essential. All FDMs I 
have worked with or am aware of (except, perhaps YASim) output control 
surface deflections in degrees, and for good reason: it's natural, 
it's physical. From the point of view of JSBSim, normalized 
aerosurface deflections are unnatural and irrelevant. The overhead and 
baggage code causes confusion and obfuscates the operation of flight 
control code. It clutters the code. I have no problem with FlightGear 
doing whatever it wants to with the values we send, but I remain 
skeptical about using normalized values as a common transport 
device for the actual physical value.

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


[Flightgear-devel] Tracking camera

2004-12-14 Thread Jon S Berndt
Does FlightGear have a tracking camera view at this time? What I am 
getting at is this: say I have a vehicle that I want to fly in a 
scripted manner. Can I select a camera that will automatically track 
the vehicle as it flies?

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


[Flightgear-devel] CVS and file moves

2004-12-08 Thread Jon S Berndt
Is there a clean way to move files in a CVS repository from one 
directory to another for a reorganization?

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


Re: [Flightgear-devel] Solaris/GPU recommendations sought!

2004-12-03 Thread Jon S Berndt
On Fri, 3 Dec 2004 16:03:13 +0100
 [EMAIL PROTECTED] (Gerhard Wesp) wrote:
Primary objective is to run FlightGear rock solidly (need it as a
front end/testing environment) for my own FDM).
Why your own FDM? Don't get me wrong - I think there are a lot of 
reasons why someone would want to write their own FDM. One reason is 
because it's fun (OK, I'm wierd :-)  But, if your being driven to 
write your own because one of the others is lacking something or there 
is some other cause, I'd be interested to hear it, for the purpose of 
possibly making improvements.

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


Re: [Flightgear-devel] Aircraft directory structure

2004-11-22 Thread Jon S Berndt
On Mon, 22 Nov 2004 15:02:09 -0600
 Curtis L. Olson [EMAIL PROTECTED] wrote:
How hard would it be to allow aircraft to live in an arbitrary 
structure underneath data/Aircraft?
From a JSBSim FDM point of view, I've been giving this some thought 
with respect to standalone JSBSim, as well. There ought to be more 
flexibility in this system. We have aircraft, engines, control 
systems, etc. files. Some of them we might tend to want to be 
interchangeable - that is, allow use of an engine with several 
aircraft. The idea is to preclude the need to have an engine defined 
in each aircraft subdirectory and just have one engine corral (sorry 
- remember, I'm from Texas ;-)  However, I am beginning to warm to the 
idea of having one location where an aircraft could be found, and 
under that - or even inside that directory - the engine itself could 
be found, as well as other required files. The engine files 
specifically are small enough so they could be duplicated with hardly 
a storage impact at all.

Ideally, the controlling program (either the JSBSim.cpp wrapper for 
standalone operation, the Flightgear FDM interface class in the case 
of integrated operation, etc...) would pass along or specify the 
directory to search and the aircraft file name. We really don't care 
where we get the aircraft file name from - we just need the file name 
(and path). Right now, I think we are trying to be too rigid in 
specifying where files are to be found.

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


Re: [Flightgear-devel] Aircraft directory structure

2004-11-22 Thread Jon S Berndt
On Mon, 22 Nov 2004 15:29:36 -0600
 Curtis L. Olson [EMAIL PROTECTED] wrote:
Jon S Berndt wrote:
I don't think we need to kill ourselves trying to be overly 
flexible.  I think it's worth having a central repository of commonly 
used items (engines, instruments, etc.)  An aircraft could refer to a 
standard item, or could refer to a specific item in it's own 
directory.  I don't think we would need to go overboard on recursive 
directory searches to hunt for stuff.
I agree - I sure wasn't suggesting that. My point was that the 
controlling application can have all the smarts as far as directory 
searches are concerned. It ought not to matter to the FDM where the 
files are stored - right now, JSBSim cares, at least for standalone 
operation. It is sort of a forced directory structure. I don't like 
that any more.

I'm calling for someone to take on the task of making aircraft more 
relocatable.  If someone wants to make a family of aircraft varients 
and share parts ... I think it's ok to make them all live as siblings 
to a single parent directory, but right now everything is hardwired 
so every aircraft must be a child of the Aircraft subdirectory.  We 
can't make up organization aircraft directories (i.e. Single-Engine, 
WWII, Boeing, Cargo, Biz-jet, etc.)
This makes a lot of sense. Dave Culp prodded us to support placing the 
engine directory under the specific aircraft directory as a first step 
for JSBSim. I'd like to see that changed so we (JSBSim) can simply 
accept a directory path and name for the aircraft being modeled.

That does raise some issues for us, though. Within the aircraft config 
file, we specify various filenames for engine, thruster, and perhaps 
control system, etc.  By default now there is a series of directories 
taht are searched for engines (the engine filename only is given in 
the main aircraft config file - not the entire path). So, there is 
really a series of acceptable paths. I don't like that. I'd like there 
to be a single way to do this - such as specifying that all 
FDM-relevant config files (aircraft, engine, controls, etc.) should 
all be in the same directory. The path to said FDM directory ought to 
be passed in by the controlling program and then we're all set. I'd 
actually prefer (now) to NOT have separate directories for engines and 
aircraft.

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


[Flightgear-devel] [OT] Keyhole

2004-11-18 Thread Jon S Berndt
The Ultimate Interface to the Planet:
http://www.keyhole.com/
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] JSBSim Scripts in FlightGear

2004-11-08 Thread Jon S Berndt
I got a request to implement something I've been considering 
implementing for some time, anyhow. JSBSim has the ability to run 
scripted flights. Scripts are composed in an XML-format command file. 
This works quite well for JSBSim in a standalone mode. I have yet to 
try to implement this in JSBSim.cxx - the interface. However, I 
suspect it is merely a matter of not taking input from FlightGear, but 
instead taking input from our script class.

The problem I need to know how to solve is in taking a command line 
option from FlightGear. We still need to specify the name of the 
script file to use. The script file designates which aircraft to load, 
as well as the initial conditions file to use. So, what I'd like to do 
is to implement a command line option in Flightgear that is mutually 
exclusive with setting initial conditions and aircraft name. Possible?

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


Re: [Flightgear-devel] JSBSim Scripts in FlightGear

2004-11-08 Thread Jon S Berndt
I would go the other way around, implement FlightGear's FDM socket 
communication protocol for JSBSim and run it as a stand-alone FDM 
that feeds FlightGear with it's data.

Erik
I like this idea a lot - but I'm not quite sure how to proceed on 
this. Do you have any ideas to throw out on how this might work? Mind 
you, I have had no exposure to the FDM scp.

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


Re: [Flightgear-devel] Plea for help: geometry/trigonometry problem

2004-11-04 Thread Jon S Berndt
-atan2(-phi,theta)
This looks *very* strange.  An arc tangent of a quotient of angles??
Although it works out dimension-wise, I've never seen a quotient of
angles in any formula.
Cheers
-Gerhard
Think of them as distances, really. It was meant to be the X and Y 
component of the rotated Z axis projected along the XY plane. Think of 
the angles in radians and project the unit vector components. Maybe 
it's not correct, I did it very quick, but qualitatively it seemed to 
work, and quantitatively it seemed correct for the few angles I 
checked.

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


Re: [Flightgear-devel] Re: Plea for help: geometry/trigonometry problem

2004-11-03 Thread Jon S Berndt
On Wed, 3 Nov 2004 14:05:59 -0500
 David Megginson [EMAIL PROTECTED] wrote:
I've thought of a simpler way to approach this problem.  Let's say
that I have a plane and the three Euler angles of rotation, phi,
theta, and psi (roll, pitch, and yaw).  Given those three angles, I'd
like to determine which direction around the z axis is most directly
uphill and how steep the hill is.
For JSBSim, the order of rotation is z, y, x (heading, pitch, roll). 
Given that, note that pitch and roll don't affect heading. I assume 
you are talking about the aircraft z axis in your last sentence. Also, 
I assume that you mean, which angle about the z axis is most vertical 
with respect to the local horizontal? I _think_ this answer might have 
something to do with constructing an omega rotation vector using the 
Euler angles, transforming it to the local frame, and taking a dot 
product, but I'd have to think about this one for a little bit. This 
is kind of a cool problem. Probably someone else will have figured 
this out by the time I post this email ... :-)

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


Re: [Flightgear-devel] Re: Plea for help: geometry/trigonometry problem

2004-11-03 Thread Jon S Berndt
On Wed, 03 Nov 2004 15:28:26 -0600
 Curtis L. Olson [EMAIL PROTECTED] wrote:
I think you're on the right track. I think you want to determine the 
orientation of the aircraft body Z axis w.r.t. the local vertical 
axis. That can tell you both the magnitude and direction of the most 
vertical ascent about the local vertical axis.

Geez ... yes, it has been a long time ...
:-)
Jon

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


Re: [Flightgear-devel] Plea for help: geometry/trigonometry problem

2004-11-03 Thread Jon S Berndt
On Wed, 3 Nov 2004 16:47:37 -0500
 David Megginson [EMAIL PROTECTED] wrote:
What does arctan(-phi/theta) give you?
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Plea for help: geometry/trigonometry problem

2004-11-03 Thread Jon S Berndt
On Wed, 3 Nov 2004 16:47:37 -0500
 David Megginson [EMAIL PROTECTED] wrote:
After having scribbled for a LITTLE WHILE on the back of an envelope
;-) I am thinking that what you want is this:
-atan2(-phi,theta)
but I'll have to play a little bit more. I think this would give you 
the angle about the local vertical from the aircraft X axis to the 
most vertical ascent angle given the plane located by the aircraft X 
and Y axes.

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


Re: [Flightgear-devel] Plea for help: geometry/trigonometry problem

2004-11-03 Thread Jon S Berndt
On Wed, 03 Nov 2004 16:02:19 -0600
 Jon S Berndt [EMAIL PROTECTED] wrote:
On Wed, 3 Nov 2004 16:47:37 -0500
 David Megginson [EMAIL PROTECTED] wrote:
After having scribbled for a LITTLE WHILE on the back of an envelope
;-) I am thinking that what you want is this:
-atan2(-phi,theta)
Maybe I am missing what you are trying to do, but I just tried this in 
Excel:

-atan2(theta,phi)
which gives this:
theta   phi angle (from forward, positive clockwise)
45  0   0
45  -45 45
0   -45 90
-45 -45 135
-45 0   -180
-45 45  -135
0   45  -90
45  45  -45
0   0   BAD!
10  0   0
10  80  -82.87498365
80  10  -7.125016349
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Plea for help: geometry/trigonometry problem

2004-11-03 Thread Jon S Berndt
More:
 theta  phi   heading  magnitude
 45.00   0.000.0045.00
 45.00 -45.00   45.0075.00
  0.00 -45.00   90.0045.00
-45.00 -45.00  135.0075.00
-45.00   0.00 -180.0045.00
-45.00  45.00 -135.0075.00
  0.00  45.00  -90.0045.00
 45.00  45.00  -45.0075.00
 45.00   0.000.0045.00
Not sure if this is really true, cause I have not yet figured out by 
longhand the ascent angle at 45/45 degrees, but it looks close if not 
right.  The heading (as stated before) is:

-ATAN2(theta,phi)
The ascent angle magnitude is (where theta and phi are supplied in 
radians):

1.57 - ACOS(COS(theta)*(SIN(ABS(phi + ABS(theta)
This might be able to be cleaned up considerably.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Multiheaded video cards?

2004-11-02 Thread Jon S Berndt
On Tue, 02 Nov 2004 12:37:40 -0600
 Curtis L. Olson [EMAIL PROTECTED] wrote:
Has anyone played around with any of these options who can report 
success or failure or something in between?  What kind of performance 
are you getting?
I recall a couple years ago I was running two 17 monitors off of a 
dual head nVidia GeForce MX400 card. When I ran FlightGear, the window 
took up the entire width (two screens) as if the two monitors were one 
wide screen.

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


[Flightgear-devel] Command line debugger

2004-11-01 Thread Jon S Berndt
Is anyone aware of a command line C++ code debugger? Particularly one 
that runs under IRIX?

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


Re: [Flightgear-devel] Command line debugger

2004-11-01 Thread Jon S Berndt
On Mon, 01 Nov 2004 21:09:39 +0100
 Erik Hofman [EMAIL PROTECTED] wrote:
Jon S Berndt wrote:
Is anyone aware of a command line C++ code debugger? Particularly 
one that runs under IRIX?
If you mean something like gdb for Linux: xdb
Erik
Has anyone used ddd? Does KDevelop compile under IRIX? Can it be 
forced to do so?

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


Re: [Flightgear-devel] AI carrier

2004-10-27 Thread Jon S Berndt
On Wed, 27 Oct 2004 15:18:46 -0500
 David Culp [EMAIL PROTECTED] wrote:
Some notes on making an AI carrier.

The FDM will have to be changed to allow the aircraft to sit on a 
deck without 
the deck sailing away from under it.  The difference between the 
aircraft's 
and carrier's velocity vectors will be applied to the ground 
reactions to 
accelerate the aircraft.

That's the first two steps anyway, AFAICT.
Yep. I guess this means that the ground position and velocity 
vectors will need to be passed in to the FDMs. I'd also recommend 
against passing in orientation and rotational velocity vectors at the 
moment - first do the steady level case.

Or ... I remember at one time that there was a suggestion to allow the 
Flightgear side to query for gear location, so the specific ground 
state could be given back to the FDM per-gear. Is that a correct 
recollection?

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


[Flightgear-devel] [OT] Simulation and Air Disasters

2004-10-26 Thread Jon S Berndt
Interesting story about the Airbus crash in a New York suburb in 
November of 2001:

http://www.cnn.com/2004/US/10/26/ntsb.flight587.ap/index.html
Benzon also said that investigators found that American Airlines 
improperly trained its pilots to use the aircraft's rudder while 
recovering from upsets and said the problem could have been 
exacerbated by the airline's simulator training.

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


[Flightgear-devel] Trim quotes

2004-10-21 Thread Jon S Berndt
Would it be grumpy of me to suggest that we try a little harder to 
trim quotes when replying with quotes? I've noticed that there are 
several emails today with 100 to 200 lines of quoted material, 
followed by anywhere from a few lines to ten or so. Over time, this 
stuff builds up...

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


Re: [Flightgear-devel] how to interface with flightgear

2004-10-20 Thread Jon S Berndt
On Thu, 21 Oct 2004 01:26:54 +0800
  [EMAIL PROTECTED] wrote:
I am working on a autopilot project and we need a flight simulator 
to prove 
our control method before use it on a real aircraft. Is there any 
interface to
get the attitude of aircraft from and send control data to 
flightgear.  I mean get
the altitude, rate, accelerate and so on from it and send rudder, 
elevator,
aileron and throttle data to flightgear to control a aircraft. 
Thanks
Out of curiousity, have you seen the facilities that JSBSim has to 
offer in the way of control systems (including autopilot)? Are you 
using Matlab?

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


[Flightgear-devel] Validating XML parser

2004-09-30 Thread Jon S Berndt
I've been wondering about easyXML, if it can be modified to support 
validation against a DTD? Since it is built on top of eXpat - and I 
believe eXpat _can_ be compiled to provide validation - is this just a 
matter of proper compilation of the eXpat library?

I ask because it is becoming clear to me that, as I compose the new 
parsing logic for JSBSim config files - as well as the new config file 
format itself - I may need to provide error checking / validation 
functions as the data is read in. There are just too many 
opportunities to mess up the config file. Ideally, this kind of thing 
would be done by a config file editor, but since there is no config 
file editor on the horizon, validation of a config file against a DTD 
becomes quite attractive. IMHO, it simplifies parsing logic in the end 
application (in this case, JSBSim).

Now, this raises another question: do general purpose (or 
configurable) XML application editors (open source or free, preferred) 
exist that could be used to author a JSBSim config file?

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


[Flightgear-devel] 737 autoflight modeling

2004-09-24 Thread Jon S Berndt
Regarding a 737 autopilot, I thought I'd write some comments, here.
Having discussed with Dave C. recently some of the autoflight and/or 
flight management features of the 737NG airliner, I have investigated 
using the JSBSim components to model some aspects of these systems. I 
found that these systems can be modeled with the suite of components 
offered as part of the JSBSim flight control system model. However, 
while attempting to model a small part of the flight management 
capabilities dealing with flight level changes, I found that the logic 
for the system can get pretty complicated, quickly. Modeling the 
actual published procedure is not really that difficult. However, 
modeling the effects of inappropriate command sequences is, frankly, a 
total WAG. Having done actual flight software modeling, I can say with 
confidence that writing a simulated flight management system for the 
737 would likely approach the amount of work required to write a 
thesis! :-)  First of all, due to the unavailability of the actual 
flight management software, a guess would have to be made using 
reference material such as a flight manual. A quick search of the web 
indicates that flight manuals for currently in-service airliners are 
not simply given out. Security concerns have limited availability to 
those with a valid reason. Given that, I also wonder about how smart 
it would be to model such aspects of airliner operation too closely.

In any case, I intend to work with Dave C. to model at least parts of 
the flight management system as an exercise.

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


Re: [Flightgear-devel] 737 autoflight modeling

2004-09-24 Thread Jon S Berndt
On Fri, 24 Sep 2004 19:55:54 +0200
 Boris Koenig [EMAIL PROTECTED] wrote:
Also, regarding the whole terrorist issue that you mentioned:
terrorists usually have the funding available to really use
*professional tools*, so the 9/11 terrorists did not only fool
around with a version of Micro$oft's flight simulator, but also 
attended REAL flight training, they even used fixed base sims...

FlightGear is not going to become interesting for that group of 
people!
Yeah (it sounds like you've considered these questions before ;-)  I 
agree with your logic. But, it can make one a little queasy, 
nonetheless: I believe I recall that MSFS was used by some of the 9/11 
perpetrators.

I do think it's a good idea to reiterate that, as always, we should 
make sure that whatever information is used in this endeavor is based 
on genuinely publicly available material.

I would suggest to  coordinate your efforts then with Harald Johnsen,
who's  working on the visual/logical implementation of the CDU/FMC:
http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26056.html
http://www.chez.com/tipunch/flightgear/index.html
Maybe you guys can save some of the work by combining your efforts 
:-)
Sounds like a good idea.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: Simgear::EasyXML - minimum file set

2004-09-01 Thread Jon S Berndt
On Wed, 01 Sep 2004 11:54:08 -0700
 Alex Romosan [EMAIL PROTECTED] wrote:
you need to have the expat library installed (+ the header files) but
then you can use just easyxml.cxx from simgear with the following
patch applied:
--- easyxml.cxx 29 Jul 2004 08:30:10 -  1.4
+++ easyxml.cxx 1 Sep 2004 18:49:57 -
@@ -5,7 +5,7 @@
 #include string.h// strcmp()
 
 #include easyxml.hxx
-#include xmlparse.h
+#include expat.h
 
 #include STL_FSTREAM
 #include STL_IOSTREAM

i've been running simgear like this forever (the rest of the files in
simgear/xml are a rather old version of the expat library).
Thanks. I was able to compile three xml***.c files early today (in the 
lib/ directory of the eXpat dist). I don't know if that is the eXtent 
of what is required to compile EasyXML or not, yet. Also, somehow I 
have to figure out how to get JSBSim to compile with a new class 
(FGXMLParse) that uses easyxml (which in turn uses eXpat) for the 
standalone version of JSBSim, and also compiles and links within 
FlightGear. That shouldn't be too big of a deal, but it could be 
tricky.

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


[Flightgear-devel] Re: [Jsbsim-devel] Re: Simplot compilation fails

2004-08-20 Thread Jon S Berndt
On Fri, 20 Aug 2004 15:58:29 +0200
 Steven Beeckman [EMAIL PROTECTED] wrote:
I've checked the latest CVS snapshot from SimGear.org, and even there 
I find 2 readXML-methods in easyxml.hxx, so that won't be the 
problem. I've commented out the readXML-method with 3 arguments in 
easyxml.hxx, which seemed to solve the overloading problem.

So in main.cpp the code looks like this:
ifstream inputfile(argv[2]);
if (!inputfile) {
 cerr  Could not open autoplot file   argv[2]  endl  endl;
 exit(-1);
}
plotXMLVisitor myVisitor;
readXML (inputfile, myVisitor);|
Unfortunately, compiling gives this:
|[EMAIL PROTECTED]:~/JSBSim/JSBSim/utilities$ g++ *.cpp 
-I/usr/local/include/ -L/usr/local/dislin/ -ldislnc -o simplot
   main.cpp: In function `int main(int, char**)':
   main.cpp:69: could not convert `inputfile' to `const std::string'
   /usr/local/include/simgear/xml/easyxml.hxx:377: in passing argument 
  1of `void readXML(const std::string, XMLVisitor)'
|
Calling readXML with argv[2] instead of inputfile gives (again) an 
undefined reference about the readXML-method (still commented out the 
one with 3 arguments). Any ideas how to solve this problem?
Yes, calling readXML() with a char* would not be good - wrong type. 
However, I am using this form in two applications, and compiling under 
CygWin, with no problem (this is from a different application that 
simplot):

  ifstream inputfile(argv[1]);
  if (!inputfile) {
cerr  Could not open XML file   argv[1]  endl  endl;
exit(-1);
  }
  FGXMLParse myXMLFile;
  readXML (inputfile, myXMLFile);
It seems as if your compiler is choking on the first argument of 
readXML() not being a const reference to a string. I'm not sure how to 
solve this. I'll cross-post to flightgear-devel - someone there may 
have a clue.

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


Re: [Flightgear-devel] Re: [Jsbsim-devel] Re: Simplot compilation fails

2004-08-20 Thread Jon S Berndt
On Fri, 20 Aug 2004 09:37:29 -0500
 Jon S Berndt [EMAIL PROTECTED] wrote:
to solve this. I'll cross-post to flightgear-devel - someone there 
may have a clue.

Jon

Disregard this - I goofed.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Loading an XML file using EasyXML

2004-08-20 Thread Jon S Berndt
Can someone tell me what the process is once a file has been opened 
and is being parsed by EasyXML? What do the callbacks do ... what is 
the standard procedure for reading in the attibutes and elements and 
data?

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


Re: [Flightgear-devel] Loading an XML file using EasyXML

2004-08-20 Thread Jon S Berndt
On Fri, 20 Aug 2004 20:55:18 +0200
 Mathias Fröhlich [EMAIL PROTECTED] wrote:
On Freitag, 20. August 2004 18:48, Jon S Berndt wrote:
Can someone tell me what the process is once a file has been opened
and is being parsed by EasyXML? What do the callbacks do ... what is
the standard procedure for reading in the attibutes and elements and
data?
See:
http://www.simgear.org/doxygen/easyxml_8hxx.html
It is a quite neat implementation.
And I think that using integrating this provides is a good chance to 
seperate configuration data from state data.
Yes, I've seen that page. I've written (now) two applications that use 
the EasyXML class, and it is a very nice (and Easy) class to use. With 
the plotting application, it was not too difficult to use it (even if 
I did so incorrectly). There was one class that was subclassed from 
XMLVisitor, and it included all the plotting parameters I needed.

However, in the case of JSBSim, there are now several classes that 
read in data from the configuration file (FGFDMExec does the initial 
read, and hands off the config file handle to other classes to let 
them read in their own data). The Aerodynamics, MassBalance, Aircraft, 
Output, etc. classes currently all read in their own data from the 
configuration file.

Today, I have written a class that parses JSBSim format config files. 
Within the callbacks I simply echo the information read from the 
files. Currently, FGXMLParser (the name of the potential new class to 
replace FGConfigFile) can parse the config file, but then the question 
is: what do I do, now. Remember, currently in JSBSim each file reads 
in its own data as the config file class encounters the relevant 
sections in the config file. With FGXMLParser we have callbacks - this 
is philosophically different from FGConfig File.

So, my question is: What is the philosophy behind loading various 
classes with their own data from the config file using EasyXML 
callbacks?

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


Re: [Flightgear-devel] Loading an XML file using EasyXML

2004-08-20 Thread Jon S Berndt
On Fri, 20 Aug 2004 21:40:28 +0200
 Mathias Fröhlich [EMAIL PROTECTED] wrote:
On Freitag, 20. August 2004 21:10, Jon S Berndt wrote:

But also an aircraft is built like such a tree. The top node is the 
Some aircraft are even built OUT OF trees. ;-)
aircraft itself. This one has a flightcontrolsystem, some object 
containing the aerodynamic properties of the aircraft, a list of engines,
a list of undercarriage elements and so on.
Erik's approach might work. I will have to play with the parsing to 
see different approaches, and how they might work.

Thanks,
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Loading an XML file using EasyXML

2004-08-20 Thread Jon S Berndt
On Fri, 20 Aug 2004 22:01:43 +0200
 Frederic Bouvier [EMAIL PROTECTED] wrote:
I think Jon wants to preserve the current JSBsim syntax and not use
the property syntax.
-Fred
Well, perhaps. The thing is, certain items that would be parsed from 
the configuration file, such as landing gear, aero coefficients, 
engines, and flight control components, are _instantiated_ when they 
are read from the config file. The parsing process does not simply 
read property values and assign them. The configuration of the 
specific simulation is formed. Also, the interest is in allowing each 
class to extract its own values from the config file. That makes it a 
little trickier.

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


Re: [Flightgear-devel] Re: yasim + bo105 + vrp + @#%$#@ == argh!

2004-08-04 Thread Jon S Berndt
On Wed, 4 Aug 2004 23:04:16 +0200
 Melchior FRANZ [EMAIL PROTECTED] wrote:
Good idea. I'll try that. Thanks.
Get some sleep, first !!
:-)
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Data source battle?

2004-08-02 Thread Jon S Berndt
Jim Wilson wrote:
If it wasn't for the great work on JSBsim and YASim we'd have very 
few aircraft.  But I think those config files, along with the source 
code that ends up interpreting and processing them, both make up the
FDMs.

There is considerable skill and effort involved in producing accurate
flight models for new aircraft isn't there?
This is absolutely true. It's almost an art form in itself. But, the 
aircraft definition is a complete, static, specification file for a 
specific aircraft. The flight dynamics model (I'm referring to JSBSim, 
YASim, or UIUC-LaRCsim source code compiled into FlightGear) 
_implements_ the flight dynamics guided by the specific aircraft 
flight model.

Just my $0.03.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Properties and speed of lookup

2004-07-30 Thread Jon S Berndt
Properties = text strings bound to variables or access methods.
Property manager maintains a list of these.
How is the lookup done when a property value is retrieved (assuming 
the desired property to be looked up is referenced by the text 
string)?

I wondered if an STL map is used?
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-29 Thread Jon S Berndt
On Thu, 29 Jul 2004 15:01:28 -
 Jim Wilson [EMAIL PROTECTED] wrote:
Jon Berndt wrote:
 One more thing: think of a baseball or better yet a lightweight 
 ball. How do those things curve?

Well Jim's make it up as you go along Physics manual says that there is
greater pressure against the air molecules in front of the moving ball.  
... etc.
Strike 1.
Hint: If the curve ball is spinning about a vertical axis, what does 
this say about the flow of air on the left and right sides of the 
ball?

Here's the windup ... and the pitch ...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-29 Thread Jon S Berndt
On Thu, 29 Jul 2004 10:34:16 -0500
 Curtis L. Olson [EMAIL PROTECTED] wrote:
Ok, then how do you explain a frisbee that can curve either way, even 
though it's always thrown with the same direction of spin.  And 
please include the coriolis effect in your explanation (now that it 
is implimented in JSBSim.)

Thank you. :-)
Gyroscopic stabilization and tilt.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-29 Thread Jon S Berndt
On Thu, 29 Jul 2004 19:37:08 +0200
 Boris Koenig [EMAIL PROTECTED] wrote:
I like it when people share their valuable experiences ... :-)
So, the next time I'm there I'll be careful !
Why? You won't hit anything! :-)
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-29 Thread Jon S Berndt
On Thu, 29 Jul 2004 19:38:44 +0200
 Erik Hofman [EMAIL PROTECTED] wrote:
(Now I start to wonder why we always smash our probes on the surface 
of Mars).
NASA does it by design.
(Well ... except for the Mars Polar Lander.)
:-)
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-28 Thread Jon S Berndt
On Wed, 28 Jul 2004 17:25:31 -
 Jim Wilson [EMAIL PROTECTED] wrote:
Richard Bytheway said:

Well as a physicist (but with no formal aeronautical education), I 
always
think of it as the wing is pushing air down, which causes an equal 
and
opposite force (to quote Newton) of the air pushing the wing up. 
Hence
acrobatic aircraft with symmettrical wings can still fly. The key to 
wing
shape design is to keep the air flow attached to both the upper and 
lower
surface so that you can change the direction of airflow. Once the 
flow
detaches (a stall), you are not pushing the air down any more, so it 
isn't
pushing you up.

This suggests that both bernoulli and the pushing (gravity) are at 
play,
depending on the airfoil.  My (uneducated) guess is the pushing is 
almost all
of it and that the bernoulli effect only augments:
http://observe.arc.nasa.gov/nasa/exhibits/planes/planes_1c.html
The pushing comes into play in Newtonian flow, such as at hypersonic 
speeds. In that case, the momentum transfer of many impacts with air 
molecules and the resulting exhange of momentum might be seen as 
pushing the wing upward.

Also, past stall a wing will see a decrease in lift, but then an 
increase again - perhaps to an even higher degree than it had prior to 
stall - at about 45 degrees, like a flat plate. In that case, the 
airflow on the back side of the wing is obviously going to be 
detached, but there is lift, nonetheless. It seems to me that this 
could be seens as the airflow pushing the wing up, and the airflow 
being deflected downward. Not sure how that fits in with Bernoulli, if 
at all.

However, at normal angles of attack below stall, the Bernoulli 
principle is, I believe, the explanation for lift. The 
_resulting_effect_ of the lower pressure on the top surface of the 
wing than on the bottom, gives a net lift - which *results*in* airflow 
being deflected (i.e. pushed downward). It could be a matter of 
point-of-view: the direct cause of the lift is the pressure 
differential, the effect is that airflow is deflected downwards. It's 
not the other way around - that is, the air that is pushed downward 
does not cause the pressure differential over the wing surfaces.

That's my further explanation, in any case.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-28 Thread Jon S Berndt
On Tue, 28 Jun 2005 19:20:17 +0100
 SGMINFO [EMAIL PROTECTED] wrote:
David Megginson wrote:
  I'm getting seriously out of my depth here, since I didn't even 
take high
  school physics...

Just a lurker at present until I can find a way to contribute more 
usefully but try this...

http://www.av8n.com/how/
Yes, this seems liek an excellent piece. See section 3.14 and 3.15 for 
pertinent discussion.

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


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-28 Thread Jon S Berndt
On Wed, 28 Jul 2004 14:15:04 -0400
 Norman Vine [EMAIL PROTECTED] wrote:
This is a 100 year old argument :-)
http://hyperphysics.phy-astr.gsu.edu/hbase/fluids/airfoil.html
If you really want to know read everything you can wriiten by
Koukowskii and Prandtl
Is light a wave or a particle?
:-)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-28 Thread Jon S Berndt
On Wed, 28 Jul 2004 14:52:24 -0400
 David Megginson [EMAIL PROTECTED] wrote:
The important thing to note is that the airflow *above* the wing also 
curves down, not just the airflow below it.  That is why, even with 
the same incidence angle, the hstab sees a different angle of attack 
in the wings' downwash even if it is level with or slightly above the 
wings themselves.

David
So, from the point of view of the horizontal stabilizor, that pesky 
downwash happens because wings really suck. ;-)

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


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-28 Thread Jon S Berndt
On Wed, 28 Jul 2004 22:56:59 +0200
 Erik Hofman [EMAIL PROTECTED] wrote:
This is exactly the reason why pressure is build up underneath the 
wing (pushing the airfoil up on air molecules == force).
No, not really. See: 

http://www.av8n.com/how/htm/airfoils.html#sec-consistent
Excerpt:
Of course, if there were no atmospheric pressure below the wing, 
there would be no way to have reduced pressure above the wing. 
Fundamentally, atmospheric pressure below the wing is responsible for 
supporting the weight of the airplane. The point is that pressure 
changes above the wing are more pronounced than the pressure changes 
below the wing.

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


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-28 Thread Jon S Berndt
On Wed, 28 Jul 2004 23:28:55 +0200
 Erik Hofman [EMAIL PROTECTED] wrote:
Jon S Berndt wrote:

No, not really. See:
http://www.av8n.com/how/htm/airfoils.html#sec-consistent
Try this for a start:
An airflow over the wing is causing the downwash at the end of the 
airfoil. The airflow below the wing is now kind of captured between 
the airfoil and the layer(s) of air underneath itself.

In this situation it can go in just two directions, up or down, The 
majority of the flow will go down, bu a tiny fraction of the 
molecules has to go up. If the number of molecules that go up is high 
enough it will lift the airfoil up with it.

This is really what DaVinci already had discovered back in 
1530-something.
Which is why he never flew. See the argument about bullets in the 
link provided, above.

In the case of the airflow below the wing, it's not really trapped. 
It gets out of the way, below. Also, consider the wing of a B-52. I 
believe it is entirely possible that a wing such as that on the B-52 
can have a lower surface that is parallel to the airflow, but still 
provides lift. That's because it's _mostly_ (or entirely) the 
sucking action above the wing that contributes the most to lift.

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


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-28 Thread Jon S Berndt
On Wed, 28 Jul 2004 23:55:09 +0200
 Erik Hofman [EMAIL PROTECTED] wrote:
Jon S Berndt wrote:

That's because it's _mostly_ (or entirely) the sucking action above 
the wing that contributes the most to lift.
No, that is the *result* of lift, not the *cause*.
Erik
No, you're mixing up cause and effect.
From Fundamentals of Aerodynamics (John Anderson) is this 
succinctly put explanation: No matter how complex the body shape may 
be, the aerodynamic forces and moents on the body are due entirely to 
the above two basic sources.  The two sources were listed as, 
Pressure distribution over the body surface, and shear stress 
distribution over the body surface. If you integrate the pressure 
distribution over the body (a wing, for instance), you get lift (and 
drag, if you componentize them in a coordinate system aligned with the 
velocity vector).

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


Re: [Flightgear-devel] Taildragger takeoff and landing

2004-07-28 Thread Jon S Berndt
On Wed, 28 Jul 2004 23:16:05 +0100
 Lee Elliott [EMAIL PROTECTED] wrote:
Although it might not be accurate in my model, the B-52 wing is set 
at six deg 
incidence, and while it does fly a little nose-down in some 
circumstances, 
six deg worth would be worrying;)   Heh - not that I haven't seen 
some of my 
FDMs for it do exactly that:)
Take a look at the NACA wing section lift curves. The ones with a 
camber have a positive lift coefficient at zero degrees alpha.

The lift is due to the net pressure difference across the wing 
surfaces. The same action (pressure difference) that causes the lift, 
also causes the downwash. You can't have one without the other.

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


Re: [Flightgear-devel] Success

2004-07-23 Thread Jon S Berndt
On Fri, 23 Jul 2004 16:05:13 +0100
 Al West [EMAIL PROTECTED] wrote:
On Friday 23 July 2004 15:21, Jon Berndt wrote:
I'll stop whining, now. ;-)
I was able to build simgear and flightgear with the OpenAL libs.
 
I've built it fine too - acutally being able to run it is a different 
matter. 

Is it running for you?  I've tried all sorts of openalrc files with 
or without 
--disable-sound but stil get complaints about openal settings on 
startup.  
I only had time to try the default aircraft before coming into work. I 
simply typed:

fgfs
and it ran. I even flew it.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Visual Reference Point scheme works

2004-07-23 Thread Jon S Berndt
On Fri, 23 Jul 2004 16:07:17 -
 Jim Wilson [EMAIL PROTECTED] wrote:
It has been a while since this feature was added,  but I thought Jon 
might
like to know that using his VRP feature I've succeeded in positioning 
the
Cessna 310  (U-3A) visual model identically under both JSBSim and 
YASim flight
dynamics models.  The YASim config for the c310 has the origin placed 
at the nose.  The changes are in CVS now.
Good, thanks. Even though I think the VRP is a good idea, it still 
requires some work from the FDM guys - that is, we'll have to set the 
VRP to the correct value in all JSBSim aircraft files. Right now it's 
set at the CG for many aircraft, I think - which is not correct.

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


Re: [Flightgear-devel] Prerelease 2 and traffic manger

2004-07-22 Thread Jon S Berndt
On Thu, 22 Jul 2004 20:17:34 +0200
 Durk Talsma [EMAIL PROTECTED] wrote:
What kind of problems did you see? I've sent a lot of changes to Erik 
about 
two weeks ago. That update fixed a lot of stuff, including the 
autopilot, 
which makes it a lot easier to fly. The CVS version is a little heavy 
during 
take-off. I.e. doesn't start pitching up until at about 200 kts, but 
we're 
working on that. Please let me know what problems you had, and I can 
see what 
I can fix.

Also, note that including the MD-11 at this stage is not my first 
preference: 
that would be including the new traffic manager and AIFlightplan 
code, and 
use *only* the 737 traffic. 

On the other hand: The MD-11  *is* the first aircraft that has multi 
livery 
support, which is a kinda neat feature. :-)

Cheers,
Durk
On Thursday 22 July 2004 19:51, Curtis L. Olson wrote:
Durk Talsma wrote:
I just started building FlightGear-0.9.5-pre2. SimGear compiled and 
built
fine, and FlightGear is compiling as I type.

One thing I noticed is that the Traffic Manager issue still isn't 
resolved
yet. fgfs-base-0.9.5 doesn't contain the MD-11, but the current 
traffic
 files require this aircraft to be present.

I've sent Erik a patch that would allow us to use alternative 
traffic
 patterns instead. Erik, would you mind adding this to cvs, or does
 everybody feel this is a new feature and should not be added to 
until the
 next version? If the former then I can go ahead and modify the 
traffic
 list.

Hmmm, I hadn't included the MD11 because when I looked at it (maybe 
two
weeks ago) it still seemed very much under development.  And there 
are
big problems with the flight dynamics making it virtually unflyable. 
I
could include it in the base, but it would be really great if 
someone
could work on the flight dynamics enough so that it is at least
plausibly flyable.
Is the MD-11 a JSBSim aircraft? I thought it was, but I don't recall 
it being in our CVS ... is the AI aircraft its own FDM?

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


Re: [Flightgear-devel] Latest OpenAL for new build?

2004-07-22 Thread Jon S Berndt
On Thu, 22 Jul 2004 12:36:40 -0700
 John Wojnaroski [EMAIL PROTECTED] wrote:
Curtis L. Olson wrote:
John Wojnaroski wrote:
Trying a build of the latest pre-0.9.5 release...
SimGear compile fails on sample_openal implicit declaration of 
alGetsourcei(...) and alutLoadWAVFile()

Searched the include files for AL and there is an alGetsourceiv() and 
alGetSourcefv() but the above functions are missing.

Running the stable version of debian  (woody) and libopenal-dev 2.3 
package from stable release. Searched thru the other testing and 
unstable directories with zero results...

Does SimGear/FG require the latest versions from their OpenAL 
website?

Probably yes, try grabbing the latest version from CVS.  I was 
surprised 
to find that OpenAL has no official version number releases.  You 
have 
to get the source via CVS if you get it from their site.  And, they 
seem 
to be ok with making some API changes over time.  And even stranger, 
they have a different API variant for MacOS.  These are the 
annoyances 
we have to deal with when using OpenAL.

Curt.

Grabbed the latest CVS download from the OpenAl website and did a 
build and install. Things look okay.. Back to simgear
There is no process like this for CygWin users, right? We have to 
use the pre-packaged tar file that exists somewhere on the net (I 
can't recall where it is). Have any CygWin users besides me, some 
months ago) tried to check out the latest OpenAL from CVS and 
compiling? Any time SimGear/FlightGear take advantage of new features 
added to OpenAL, CygWin users are going to have a problem, until 
OpenAL supports CygWin out of the box.

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


Re: [Flightgear-devel] Difficulty with building under Cygwin

2004-07-19 Thread Jon S Berndt
On Mon, 19 Jul 2004 18:07:43 +0100
 Vivian Meazza [EMAIL PROTECTED] wrote:
I've just downloaded the current cvs version of SimGear and 
FlightGear. They both compile under Cygwin straight out of the box.

I would suppose that you have a problem with your path.
Possibly, but I am using the same approach I've used for years. The 
simgear and plib libraries both built as expected, and were installed 
as expected. I've updated via CVS all of the parts. So, it seems that 
something has changed that I am not aware of.

I will check the config.log as Curt suggested, when I get home this 
evening.

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


Re: [Flightgear-devel] status of aircraft carrier

2004-07-08 Thread Jon S Berndt
On Thu, 8 Jul 2004 14:03:14 +0100
 Vivian Meazza [EMAIL PROTECTED] wrote:

Jon Berndt wrote
Sent: 08 July 2004 13:29
To: FlightGear developers discussions
Subject: RE: [Flightgear-devel] status of aircraft carrier
 In my day they consisted of a pulley system forcing hydraulic 
fluid 
 through orifices. These orifices were adjusted to provide the 
right 
 decelerating force for each aircraft type.

 I seem to recall that a disk brake system was proposed. I 
don't think 
 that this was implemented in Royal Navy carriers, but may have 
been 
 for modern US carriers.

An aircraft, upon landing on a carrier, does not appear to 
slip backwards at all under the force of the arresting wire. 
It seems like a one-way spring.
A one way spring - a new concept in physics :-). Perhaps more like a 
one way damper on a car suspension.

Seriously - did you mean a linear spring where the force that stretches the
spring is in direct proportion to the amount of stretch? That would 
not be
quite correct - the arresting force was constant in the first part of 
the
pull-out, and I think, but can't quite remember, that the orifices 
closed
towards the end of the pull-out to provide a soft stop. 
I thought about using a damper, too, but qualitatively that didn't 
seem right, either. A spring/damper could probably be made to feel 
close enough.

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


Re: [Flightgear-devel] Re: Concorde

2004-07-07 Thread Jon S Berndt
copy direct.xml from some other engine directory to
Aircraft/Concorde/Engines. it worked for me.

On Wed, 7 Jul 2004 13:15:42 -
 Jim Wilson [EMAIL PROTECTED] wrote:
Just in case someone, in the future, searches the archives for a 
solution to this particular error...   This is NOT a good thing to do.
A few weeks ago there was a change made to the propulsion system code 
such that engines could be stored - not only in the engine/ directory 
- but in the same directory that the aircraft config file is in. This 
might cause some problems that were unforeseen because the thruster is 
probably searched for in the same directory as the aircraft, too. If 
that has not ALSO been moved over (the thruster file, that is; in this 
case direct.xml), then the load will fail.

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


Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3

2004-07-07 Thread Jon S Berndt
On Wed, 7 Jul 2004 15:30:14 -
 Jim Wilson [EMAIL PROTECTED] wrote:
There doesn't seem to be support for the std::numeric_limits 
references added
in the June update.  Can we work around this?

e.g.:
In file included from FGFCSComponent.h:46,
 from FGDeadBand.h:40,
 from FGDeadBand.cpp:40:
./FGJSBBase.h:41:18: limits: No such file or directory
From FGJSBBase.h:
#include limits
Looks like Mathias added this. It looks like it compiles under CygWin. 
It's present under IRIX, and it's also present under whatever Linux 
Mathias is using. Strange. In any case, the #include limits 
statement needs to be put in the correct #ifdef block, similar to the 
rest of the c++ headers.

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


Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3

2004-07-07 Thread Jon S Berndt
On Wed, 7 Jul 2004 17:35:31 -
 Jim Wilson [EMAIL PROTECTED] wrote:
Mathias Fröhlich said:
On Mittwoch, 7. Juli 2004 17:30, Jim Wilson wrote:
 There doesn't seem to be support for the std::numeric_limits 
references
 added in the June update.  Can we work around this?
Done in JSBSim's cvs.

Please check out a new version.
I don't see anything in JSBSim CVS that addresses this problem.  Did 
you read the later posts?
Jim:
If you are browsing CVS, there is a lag between what is committed and 
what is presented, I think. If you downloaded from CVS and there is 
still a problem, that would be surprising - CVS is immediate. Are 
you still seeing the offending code?

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


Re: [Flightgear-devel] status of aircraft carrier

2004-07-07 Thread Jon S Berndt
On Wed, 7 Jul 2004 19:12:11 +0200
 Mathias Fröhlich [EMAIL PROTECTED] wrote:
On Mittwoch, 7. Juli 2004 18:59, Andy Ross wrote:
The only special hardware on the carrier are the arresting wires 
and
catapults.  It would be easier to just model these and let generic
intersection code handle the deck intersection stuff.
Yes, this is what I meant.
What I thought of is a kind of 'wire surface' which covers the area 
bewteen 
the first and the last wire. If the hook intersects this surface we 
cought a 
wire.
That is not the whole trueth, but may be a sufficient approximation.

Off the top of my head (and I'm in a real hurry at this second), I 
think it would be nice to make it possible to supply the FDMs with a 
force vector and point of application - perhaps even a moment vector. 
Is that what you are proposing?

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


Re: [Flightgear-devel] status of aircraft carrier

2004-07-07 Thread Jon S Berndt
On Wed, 07 Jul 2004 15:12:05 -0400
 David Megginson [EMAIL PROTECTED] wrote:
Once we support ground reactions with a moving surface (like the deck 
of a ship), why not just model the catapult as a faster moving 
surface?
That would supply only a sliding friction force to the tires, which 
would be way too low, if the surface was horizontal. If you are 
referring to a vertical surface, that would then be dependent on some 
kind of spring damper associated with the gear. That's no good, 
either. In reality, the catapult imparts a force on the aircraft, and 
that's how it should be modeled.

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


Re: [Flightgear-devel] status of aircraft carrier

2004-07-07 Thread Jon S Berndt
On Wed, 7 Jul 2004 22:50:40 +0100
 Vivian Meazza [EMAIL PROTECTED] wrote:
Hmm, bolted? Don't forget that the cat force is adjusted for the 
aircraft type and launch weight.

It would have to be modelled as a spring 
force acting on the nose gear to be correct.  Even that's not 
quite good enough, since on real cat shots the gear is 
artificially compressed to keep the nose from tipping 
backwards during the shot. 
I thought initially that a spring was not the way to go, but I think 
you are picturing a spring that (figuratively) goes from the bow of 
the ship to the nose gear, no? This sounds plausible, but it depends 
on how the catapult works. Does it maintain pressure along the entire 
throw length of the catapult? In this case, a spring is wrong.


And arrestor wires have their own complexities.  They need to 
be tuned to the landing aircraft weight to produce the 
right amount of deceleration.  This is a manual process on a 
real carrier, but we'd have to fake it somehow.

Do we need to model that? We know the mass of the aircraft, just apply a
suitable decelerating force at the hook attachment point if the hook 
engages a wire.
Yep.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] L1011-500

2004-07-06 Thread Jon S Berndt
On Tue, 6 Jul 2004 20:09:38 +0200
 Durk Talsma [EMAIL PROTECTED] wrote:
Just a few comments below, since I also ran into similar issues 
creating and updating the MD-11 aero file. 

I also had problems using the FG_TURBINE and switched to
FG_SIMTURBINE, is this a good idea?
Yes, this reflects a recent change in JSBSim, which hasn't traversed 
it's way 
back into aeromatic yet. 
Actually, I did make the change - it should be implemented in 
Aeromatic. I can't test it right now.

The file generated by aeromatic had the AC_THRUSTER inside the
AC_ENGINE tags and it didn't work until i separated them, 
aero-matic bug?
Not really a bug: This how JSBSim expected things to be, until a 
couple of weeks ago. It took me a while to figure this one out. ;-)
I thought I had made a big announcement. If I did not, my apologies.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] L1011-500

2004-07-02 Thread Jon S Berndt
On Fri,  2 Jul 2004 22:46:14 +0100
 [EMAIL PROTECTED] wrote:
The L1011-500 uses the Rolls-Royce RB211-524B
take a look here for details:
http://www.aircraftenginedesign.com/TableB3.html
I have committed to JSBSim CVS an RR RB211-524 engine.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


  1   2   3   4   5   6   >