Re: [Flightgear-devel] Frames of Reference in jsbsim
Dave Culp wrote: But it doesn't. Seems like an oversight to me. I'm trying to model a 'plane with almost no dihedral AFAICS and I'm not sure what to twiddle in the .xml file to get that effect. My advice is don't worry about it. Is there something about the way the Colditz Glider is flying that doesn't seem right? Yeah - it flies too well! It's got almost no dihedral, so I'd expect it to be pretty unstable in roll. Having said that, and though I've never flown anything other than a hang-glider for real, I find the c172 to be rather *too* unstable in roll for my liking. It's not obvious to me (yet) how the effects of dihedral are handled in jsbsim, so it's not easy to experiment with changes in those values. Steve.
Re: [Flightgear-devel] Frames of Reference in jsbsim
The textbook solution for straight wings is that 1 degree of positive dihedral adds approximately .0002 to Cl, the rolling moment coefficient . This would be added to the Clb coefficient in the input file, since it is sideslip that generates the effect. I use an old copy of Perkins and Hage, Airplane Stability and Control to look these things up, when I need to. Rex Steve Hosgood wrote: Dave Culp wrote: But it doesn't. Seems like an oversight to me. I'm trying to model a 'plane with almost no dihedral AFAICS and I'm not sure what to twiddle in the .xml file to get that effect. My advice is don't worry about it. Is there something about the way the Colditz Glider is flying that doesn't seem right? Yeah - it flies too well! It's got almost no dihedral, so I'd expect it to be pretty unstable in roll. Having said that, and though I've never flown anything other than a hang-glider for real, I find the c172 to be rather *too* unstable in roll for my liking. It's not obvious to me (yet) how the effects of dihedral are handled in jsbsim, so it's not easy to experiment with changes in those values. Steve.
Re: [Flightgear-devel] Frames of Reference in jsbsim
Dave Culp wrote: On Thursday 11 May 2006 11:08 am, Steve Hosgood wrote: Deriving the parameters like "yaw moment due to beta" and other such magic numbers from physical parameters is going to be pretty non-trivial. You can use "common numbers" from some hard to find sources. To get fancy you can use DATCOM+ to calculate them. Hence the existance of Aeromatic I presume. Yes, that takes the pain out of getting a good first cut at a config file. You can tweak stuff afterwards. Tell you what: a "tweaker's guide" would be a useful document! For instance, how do you tweak the output of Aeromatic to model the fact that your aircraft (Colditz Glider in my case) has almost no dihedral on the main wing. Look at it this way. The process of getting an FDM to model a particular aircraft can be broken down into 3 steps: 1) define the airplane parts 2) define the effects of the airplane parts 3) render the airplane state during simulation Using YASim you do step 1, and YASim does steps 2 and 3. Using JSBSim you do steps 1 and 2, and JSBSim does step 3. The two methods each have their own advantages. Now that you've pointed it out, I can see the relative merits of both routes. I have no argument with jsbsim's methodology, just a slight misunderstanding to do with just how much the physical model is "missing" from jsbsim's .xml files! However, it doesn't seem possible to specify the things I was griping about to Aeromatic (wing incidence, dihedral, vertical dispacement of rudder w.r.t centerline etc). You don't specify the measurements, you specify the effects. (Except wing incidence). What I meant was, regardless that most of the physical measurements are missing from jsbsim's .xml files, **Aeromatic** should have a way of specifying them so that it can produce the right "magic" coefficients. Yet it doesn't. Aeromatic is good at what it does, but would be nice it it handled some of the other possible physical parameters of a basic aircraft. Dihedral and wing incidence would seem obvious ones. Steve. Steve.
RE: [Flightgear-devel] Frames of Reference in jsbsim
I'm working on a thorough document now, but I still only hav e alittle psare time in which to write it. :-( Jon -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Steve HosgoodSent: Friday, May 12, 2006 8:22 AMTo: flightgear-devel@lists.sourceforge.netSubject: Re: [Flightgear-devel] Frames of Reference in jsbsimDave Culp wrote: On Thursday 11 May 2006 11:08 am, Steve Hosgood wrote: Deriving the parameters like "yaw moment due to beta" and other such magic numbers from physical parameters is going to be pretty non-trivial. You can use "common numbers" from some hard to find sources. To get fancy you can use DATCOM+ to calculate them. Hence the existance of Aeromatic I presume. Yes, that takes the pain out of getting a good first cut at a config file. You can tweak stuff afterwards. Tell you what: a "tweaker's guide" would be a useful document! For instance, how do you tweak the output of Aeromatic to model the fact that your aircraft (Colditz Glider in my case) has almost no dihedral on the main wing. Look at it this way. The process of getting an FDM to model a particular aircraft can be broken down into 3 steps: 1) define the airplane parts 2) define the effects of the airplane parts 3) render the airplane state during simulation Using YASim you do step 1, and YASim does steps 2 and 3. Using JSBSim you do steps 1 and 2, and JSBSim does step 3. The two methods each have their own advantages. Now that you've pointed it out, I can see the relative merits of both routes. I have no argument with jsbsim's methodology, just a slight misunderstanding to do with just how much the physical model is "missing" from jsbsim's .xml files! However, it doesn't seem possible to specify the things I was griping about to Aeromatic (wing incidence, dihedral, vertical dispacement of rudder w.r.t centerline etc). You don't specify the measurements, you specify the effects. (Except wing incidence). What I meant was, regardless that most of the physical measurements are missing from jsbsim's .xml files, **Aeromatic** should have a way of specifying them so that it can produce the right "magic" coefficients.Yet it doesn't. Aeromatic is good at what it does, but would be nice it it handled some of the other possible physical parameters of a basic aircraft. Dihedral and wing incidence would seem obvious ones.Steve.Steve.
Re: [Flightgear-devel] Frames of Reference in jsbsim
On Friday 12 May 2006 08:21 am, Steve Hosgood wrote: What I meant was, regardless that most of the physical measurements are missing from jsbsim's .xml files, **Aeromatic** should have a way of specifying them so that it can produce the right magic coefficients. Yet it doesn't. Aeromatic is good at what it does, but would be nice it it handled some of the other possible physical parameters of a basic aircraft. Dihedral and wing incidence would seem obvious ones. Well, wing incidence *is* one of the configuration items that can go into a JSBSim configuration file. As for dihedral, I think you're still not getting the methodology of JSBSim. In JSBSim you don't specify the dihedral, you specify the *effect* of dihedral. Dave --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frames of Reference in jsbsim
On Tuesday 16 May 2006 11:40 am, Steve Hosgood wrote: Trouble is, most aircraft modellers would struggle to work out what those effects are. So we might expect that Aeromatic (which is the compiler if you like) actually takes in a value for dihedral and works out the magic numbers for the .xml file. One of my main goals when I wrote Aeromatic was to keep the interface as simple as possible. It is meant to spit out a plausible config for a particular type of airplane. Just because you have a number in your possession doesn't mean that Aeromatic should want to use it. But it doesn't. Seems like an oversight to me. I'm trying to model a 'plane with almost no dihedral AFAICS and I'm not sure what to twiddle in the .xml file to get that effect. My advice is don't worry about it. Is there something about the way the Colditz Glider is flying that doesn't seem right? As for wing incidence, true that does go in the .xml file. But by your arguments, surely it shouldn't? The *effect* of wing incidence should go into the .xml file, and (by my arguments) it should be a parameter specified to Aeromatic. Ah, but the incidence angle's effect is a mere angle, so in this case the datum and the effect of the datum are the same. Please don't take any of this as a criticism of jsbsim. No problem. JSBSim is what it is, and it works well actually. Dave --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frames of Reference in jsbsim
Jon S. Berndt wrote: I just *know* I'm going to get totally flamed for this, but can someone please tell me how the CG, Eyepoint, AERORP and VRP are interconnected? Yeah, I know - RTFM. I'd say that, but there really isn't much of one, yet! :-( You won't get flamed. It's not the easiest concept to figure out. Before I say anything, I'd like to commend you Jon, along with Dave Culp and Erik Hofman for your three replies to my original question. *None* of you flamed me or anyone else, and answered pretty much all my questions really neatly. As you say, Jon, there isn't much of a manual (yet) and discussions like this in the archives are often the next best thing. Maybe you (as prime author of jsbsim) and the other guys could clear up one or two associated questions for me please? Issue 1, Vol1 of the Quarterly Newsletter states that the sim tracks an aircraft by its CG. >From the replies I've read so far then it would appear that Issue 1, Vol 1 meant to say "jsbsim tracks the stated CG of the empty airframe". That makes a lot more sense as the article then goes on to say that the actual flying CG of a plane isn't a useful reference because it moves. Do you confirm that the "AERORP" is the point from which the "tail arm" and "rudder arm" are referenced? Since it doesn't seem possible to specify a "wing arm", do I assume that the "AERORP" must be sited at the 0.25 chord point of the main wing? Since it is largely the relative positions of various points on the aircraft which matter most, it's somewhat arbitrary how the "base" coordinate system is defined. The XYZ points in the JSBSim config file are specified relative to a coordinate system that has its X axis pointing backwards, the Y axis pointing out the right side of the aircraft, and the Z axis pointing upwards. The origin of the coordinate frame could be anywhere, but it is usually out ahead of the aircraft, and often the X axis is coincident with the aircraft centerline. This is the "structural frame" as defined by some aircraft manufacturers. It is fixed in the aircraft for all time. OK. One thing I've noticed about the aircraft.xml file (both the new version and the old) is that the "metrics" section (describing the physical layout of the plane) is rather "lightweight" compared with the vast other parts of the file that can provide lift and drag and stall characteristics of the airfoil. However (and you're probably going to prove me wrong pretty quick here) it seems that the metrics section merely lists the span and width (or area) of the main wing and the same things for the horizontal stabilizer on the tail, along with the "tail arm" length. Also the rudder dimensions and "rudder arm". There doesn't seem to be any way to specify dihedral (of the wing or of the horizontal stabilizer), or that the horizontal stabilizer airfoil isn't necessarily the same as the main wing airfoil. There doesn't seem to be any way to specify the angle of the wing chord w.r.t the aircraft centerline, or the angle of the horizontal stabilizer chord w.r.t the aircraft centerline. This comes back to my original question about orientation of the X axis. I know it runs "nose to tail" but without a way so specify the wing chord you could end up with a plane that flies rather nose up or nose down. Similarly, there doesn't seem to be a way to specify where the centre of lift of the rudder is placed vertically off the aircraft centerline. Most planes have the rudder above the centerline, and surely that generates a rolling moment on the plane when the rudder is moved? You'd seem to need some concept of "rudder vertical arm" to deal with that, but if there is one then I (for one) don't know about it. Don't feel bad about "interrogating". If you have questions, please feel free to ask either here or in the JSBSim list. Let us know if the above does not answer your question. Best regards, Jon Jsbsim is a fine bit of work, Jon. Just trying to make up for a slight lack of definitive manuals, that's all! Steve.
Re: [Flightgear-devel] Frames of Reference in jsbsim
Steve Hosgood wrote: Before I say anything, I'd like to commend you Jon, along with Dave Culp and Erik Hofman for your three replies to my original question. *None* of you flamed me or anyone else, and answered pretty much all my questions really neatly. You're not subscribed to [EMAIL PROTECTED] Josh --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] Frames of Reference in jsbsim
Steve Hosgood wrote: Before I say anything, I'd like to commend you Jon, along with Dave Culp and Erik Hofman for your three replies to my original question. *None* of you flamed me or anyone else, and answered pretty much all my questions really neatly. You're not subscribed to [EMAIL PROTECTED] Josh Ha! :-D This community is pretty well-behaved and well-mannered. You should see the usenet groups alt.space.shuttle and alt.space.policy! Jon --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frames of Reference in jsbsim
From: Erik Hofman Steve Hosgood wrote: I just *know* I'm going to get totally flamed for this, but can someone please tell me how the CG, Eyepoint, AERORP and VRP are interconnected? Yeah, I know - RTFM. It basically comes down to this, *you* decide where (0,0,0) is referenced and you will have to define all other locations relative to (0,0,0) Also there have been discussions historically about situations when, if the nose tip, single engine prop cone tip or whatever forward most centered point on the aircraft can be identified that would it be 0,0,0 as a convention. This just a convenience for syncing FDM designers and 3D Model authors, especially noticable when you have multiple FDM's for a single 3D model or multiple 3D Models for a single FDM model. Technically, what Erik is saying is correct. Also related to eyepoint, the location being reported now (AFAIK) by the FDM's (as lon,lat,alt) is always considered the origin by the viewer. This means that when you are following a plane in an Look At view (e.g. chase view, tower view) the point being followed is this origin (0,0,0). For various reasons that have been explained here before (involving how 3D graphics work) the aircraft will appear to pitch about the nose if the nose is the origin. Several aircraft including the P51D have an offset defined as trarget-z-offset-m that moves the point that the 3D camera is pointing to back to where the wing is thus making aircraft movements appear more natural. Best, Jim -- Jim Wilson Kelco Industries PO Box 160 Milbridge, ME 04658 207-546-7989 --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frames of Reference in jsbsim
On Thursday 11 May 2006 04:56 am, Steve Hosgood wrote: Do you confirm that the AERORP is the point from which the tail arm and rudder arm are referenced? Since it doesn't seem possible to specify a wing arm, do I assume that the AERORP must be sited at the 0.25 chord point of the main wing? You decide where to put it, and it's best to put it near the CG. OK. One thing I've noticed about the aircraft.xml file (both the new version and the old) is that the metrics section (describing the physical layout of the plane) is rather lightweight compared with the vast other parts of the file that can provide lift and drag and stall characteristics of the airfoil. I think you're looking at JSBSim from a YASim-like point of view. It's a completely different animal. In JSBSim we use the build-up method to define the aerodynamic characteristics of an object. The build-up is done in the aerodynamics section of the config file. The important thing to know here is that if you don't put anything in the aerodynamics section, then your object has no aerodynamic characteristics at all. There are no inferred characteristics from the metrics section. You are right in that the aerodynamics section is the heart of the config file. It is only here that we define how the object reacts to the air. Fortunately, the ways in which airplanes react to air are pretty well known, so we only need about twenty or so entries in the aerodynamics section to get our object to behave like an airplane. Specifically, the tail arms are not used (except by the turbulence code?). The effects of having a tail go in the aerodynamics section. Horizontal tail aerodynamics goes in the lift and pitch sub-sections, and vertical tail effects go in the yaw and roll sub-sections. Again, the parts of your airplane have no aerodynamic effects at all unless these effects (the effects, *not* the metrics) are defined, and this is only done in the aerodynamics section. Dave --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frames of Reference in jsbsim
On Thursday 11 May 2006 11:08 am, Steve Hosgood wrote: Things are becoming a bit more transparent. Trouble is, an aircraft modeller usually starts by knowing just physical parameters (location of wings and things, location of tail, rudder etc along with amount of dihedral, angle of incidence of wing). Deriving the parameters like yaw moment due to beta and other such magic numbers from physical parameters is going to be pretty non-trivial. You can use common numbers from some hard to find sources. To get fancy you can use DATCOM+ to calculate them. Hence the existance of Aeromatic I presume. Yes, that takes the pain out of getting a good first cut at a config file. You can tweak stuff afterwards. And that's fair enough, having a compiler that takes high level language (a description of the physical layout of a plane) and compiles it down to assembly languuage (the 20 or so entries in the aerodynamics section). Look at it this way. The process of getting an FDM to model a particular aircraft can be broken down into 3 steps: 1) define the airplane parts 2) define the effects of the airplane parts 3) render the airplane state during simulation Using YASim you do step 1, and YASim does steps 2 and 3. Using JSBSim you do steps 1 and 2, and JSBSim does step 3. The two methods each have their own advantages. However, it doesn't seem possible to specify the things I was griping about to Aeromatic (wing incidence, dihedral, vertical dispacement of rudder w.r.t centerline etc). You don't specify the measurements, you specify the effects. (Except wing incidence). Dave --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Frames of Reference in jsbsim
I just *know* I'm going to get totally flamed for this, but can someone please tell me how the CG, Eyepoint, AERORP and VRP are interconnected? Yeah, I know - RTFM. Trouble is, I think I did R the FM (there was an article by Jon S. Berndt himself in Issue 1, Vol1 of the Quarterly Newsletter) but it didn't seem to answer the following questions. For that matter ISTR that this same issue came up here a while back, but I can't find it in the mailiing-list archives. Here goes. Issue 1, Vol1 of the Quarterly Newsletter states that the sim tracks an aircraft by its CG. However, it then goes on to state that CG isn't a useful datum for a frame of reference because it can move (as, for instance, when fuel is used up). Indeed, CG gets specified in the aircraft .xml file as having an [X,Y,Z] location, and evidently this [X,Y,Z] is using some other point on the aircraft as datum. Where is this other point? Just some arbitrary convenient point? Presumably not the aerodynamic reference point, since it looks like that also gets specified with an [X,Y,Z] coordinate in the setting of AERORP. Is the AERORP the point about which the tail arm is referenced? Where should the AERORP be placed w.r.t the wing? Is there a concept of wing arm to match the concept of tail arm? I think I know what the eyepoint is :-). It is specified with an [X,Y,Z] too, but in what coordinate frame? Likewise the VRP. This is the location of the reference point of the 3D model isn't it? Again, from what point is the VRP's [X,Y,Z] measured from? Then there's the semi-unrelated question of the X axis. Increasing aftwards it says, but along what axis of aftwards are we speaking? Is it parallel (say) to the chord of the main wing or what? Finally, back to CG again. Do I assume the the CG that is specified with an [X,Y,Z] coordinate refers just to the CG of the airframe itself? Issue 1, Vol1 of the Quarterly Newsletter states (quite rightly) that the actual CG of a plane moves during flight duration as the fuel is used up, but I assume that this is why you can specify tank locations and fuel weights and rates of fuel usage. So the actual flying CG of a plane isn't where you set CG? Sorry about the interrogation, but I've realised that I seriously don't know what I'm doing in the .xml file department here! Thanks in advance for any insights. Steve. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Frames of Reference in jsbsim
On Wednesday 10 May 2006 11:43 am, Steve Hosgood wrote: Where is this other point? Just some arbitrary convenient point? yes I think I know what the eyepoint is :-). It is specified with an [X,Y,Z] too, but in what coordinate frame? same as above Likewise the VRP. This is the location of the reference point of the 3D model isn't it? Again, from what point is the VRP's [X,Y,Z] measured from? same as above Then there's the semi-unrelated question of the X axis. Increasing aftwards it says, but along what axis of aftwards are we speaking? Is it parallel (say) to the chord of the main wing or what? nose to tail Finally, back to CG again. Do I assume the the CG that is specified with an [X,Y,Z] coordinate refers just to the CG of the airframe itself? yes, CG of the empty airplane Issue 1, Vol1 of the Quarterly Newsletter states (quite rightly) that the actual CG of a plane moves during flight duration as the fuel is used up, but I assume that this is why you can specify tank locations and fuel weights and rates of fuel usage. So the actual flying CG of a plane isn't where you set CG? correct Dave --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
RE: [Flightgear-devel] Frames of Reference in jsbsim
I just *know* I'm going to get totally flamed for this, but can someone please tell me how the CG, Eyepoint, AERORP and VRP are interconnected? Yeah, I know - RTFM. I'd say that, but there really isn't much of one, yet! :-( You won't get flamed. It's not the easiest concept to figure out. Issue 1, Vol1 of the Quarterly Newsletter states that the sim tracks an aircraft by its CG. However, it then goes on to state that CG isn't a useful datum for a frame of reference because it can move (as, for instance, when fuel is used up). Indeed, CG gets specified in the aircraft .xml file as having an [X,Y,Z] location, and evidently this [X,Y,Z] is using some other point on the aircraft as datum. Since it is largely the relative positions of various points on the aircraft which matter most, it's somewhat arbitrary how the base coordinate system is defined. The XYZ points in the JSBSim config file are specified relative to a coordinate system that has its X axis pointing backwards, the Y axis pointing out the right side of the aircraft, and the Z axis pointing upwards. The origin of the coordinate frame could be anywhere, but it is usually out ahead of the aircraft, and often the X axis is coincident with the aircraft centerline. This is the structural frame as defined by some aircraft manufacturers. It is fixed in the aircraft for all time. I think I know what the eyepoint is :-). It is specified with an [X,Y,Z] too, but in what coordinate frame? Likewise the VRP. This is the location of the reference point of the 3D model isn't it? Again, from what point is the VRP's [X,Y,Z] measured from? Then there's the semi-unrelated question of the X axis. Increasing aftwards it says, but along what axis of aftwards are we speaking? Is it parallel (say) to the chord of the main wing or what? The VRP, landing gear, CG, aero ref pt, eyepoint, engine locations, etc. are all in structural frame. Finally, back to CG again. Do I assume the the CG that is specified with an [X,Y,Z] coordinate refers just to the CG of the airframe itself? Issue 1, Vol1 of the Quarterly Newsletter states (quite rightly) that the actual CG of a plane moves during flight duration as the fuel is used up, but I assume that this is why you can specify tank locations and fuel weights and rates of fuel usage. So the actual flying CG of a plane isn't where you set CG? Correct. The CG moves. The empty weight CG is what is specified in the metrics section of the config file. Don't feel bad about interrogating. If you have questions, please feel free to ask either here or in the JSBSim list. Let us know if the above does not answer your question. Best regards, Jon --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
