RE: [Flightgear-devel] Re: Wing motion
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
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
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
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
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
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?
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?
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?
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?
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
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
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
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?
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
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
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?
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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] CVS and file moves
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!
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
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
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
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
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
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
-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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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!
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
Re: [Flightgear-devel] Socket communication
On Tue, 29 Jun 2004 17:37:00 +0200 (CEST) Roberto Manca [EMAIL PROTECTED] wrote: Hi all, I'd like to send some flight data (like altitude, speed, position...) from a machine that runs FlightGear to a slave machine (which will elaborate Hi, Roberto: It is my understanding that FlightGear has a pretty versatile socket system set up. I don't know anything about it, though. That's probably what you'll want to use. However, until that time when someone pipes in to tell you how to use that, I thought I'd pass along something that might be helpful to you. If you are using a JSBSim aircraft model, you can specify an OUTPUT setion in the aircraft file. See some of the JSBSim aircraft config files for more information on that, or if you are interested and are having problems making it work, as me. The overview is this: if you add these lines into your JSBSim aircraft config file: OUTPUT NAME=localhost TYPE=SOCKET PORT=5678 RATE_IN_HZ 10 /OUTPUT you will get flight data output to the localhost on port 5678. The format of the output is text format, with the first set of data being shipped over being the labels for the data. You can look at the FGOutput.cpp and FGOutput.h files in the JSBSim directory for more information. I've tested this out using the netcat program, nc in my CygWin environment. Open a new console window and try this: nc -l -p 5678 This sets up a listening socket on port 5678. If you run FlightGear with the JSBSim aircraft that has the OUTPUT section in the aircraft config file, you _should_ be able to see the data coming across. I haven't tried this from within FlightGear yet. Good luck. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
