Re: [Flightgear-devel] Taildragger takeoff and landing
On Wed, 2004-07-28 at 14:28, Erik Hofman wrote: Jon S Berndt wrote: 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 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. I hope you guys realize that this is an ages old debate that still goes on in the relevant academic circles. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Stabilizer Trim
On Tue, 2004-07-27 at 18:36, Innis Cunningham wrote: Thanks Guys I guess the answer is there is no stabilizer trim property. Andy Ross writes Innis Cunningham wrote: As far as I can tell there is no property to simulate a stabilizer trim system in flightgear. If this is not the case then maybe some kind soul could point me to the said property. What's wrong with /controls/flight/elevator-trim? Because stab trim and elevator trim are not the same. It is like saying a piston engine and a jet engine are the same. They are in the fact that they both provide thrust to the aircraft.It is how they do it that is different. No they are not, but they accomplish the same thing *and* the great majority of aircraft have one or the other but not both. So having one property to represent the function is fine. Maybe name it pitch-trim? Stabilizer trim is an FDM implementation detail. The *control* which you modify in the property system isn't any different on a 747-400 than it is on a PA28-161. FWIW: You can map controls to the incidence value of an htsab object in YASim to make this work, although all the current aircraft simply add the elevator trim to the tail's flap deflection. The results are indistinguishable. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d _ Protect your inbox from harmful viruses with new ninemsn Premium. Go to http://ninemsn.com.au/premium/landing.asp?banner=emailtagreferrer=hotmail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Rebuild
If you change an oft-included header in simgear, this is pretty normal. On Tue, 2004-06-29 at 20:02, Richard Harke wrote: I have found a bug in libGLcore.so from Nvidia for ia64. I think I have a work-around that involves a small change (temporary) in simgear. after making the changes, I deleted the .o and corresponding .a and ran make. Seemed to work fine and just re-compiled the one file and did the one link. Then I deleted fgfs and ran make on flightgear and it seems to be recompiling the whole world. I didn't change any flightgear files so I am rather puzzled. Is this normal bahavior for flightgear make? Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: JSBSim Cessna 172p stability patch
On Thu, 2004-05-20 at 05:17, David Megginson wrote: Jon Berndt wrote: Thanks, David. There are a couple of things I can think of to do, here. One is that I sure wish I had time to make a DATCOM model of the C-172 that could give me some aero data for comparison. But with my schedule now I can't make any promises, but I will get to this someday! The second comment is that it ought to be possible to get some real numbers for you pretty quickly from comparable aircraft. I think I can do that tonight or tomorrow. Third, there are some equations that ought to shed some light on things. Fourth, it will be interesting to see if pilot perceptions suggest altering all/most coefficients in the same direction for all aircraft in order to give the perception of proper flight characteristics. That is a tricky issue, because using spring-loaded controllers gives a significantly different feel than fully-loaded aircraft controls, and there is always a danger of altering the flight characteristics to compensate for the control differences. To try to avoid that problem this time, I tried to concentrate on rates (how fast the plane could bank, pitch, and yaw), coupling (how much adverse yaw a particular bank causes and how much bank a particular yaw causes), and recovery (how the plane recovers from a yaw or pitch disturbance). I deliberately ignored control feel. The model I posted seems a lot closer to what I remember of the 172 and what I observe in my PA-28, but unfortunately, I do not currently have measurements to test it against. Another good way to take the controls out of it are with the Dutch roll and phugoid characteristics. Once the initial rudder and elevator inputs, respectively, are complete the aircraft response should be about the same. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT, article] Memphis Belle pilot passes away
On Sun, 2004-05-16 at 15:39, Jon Berndt wrote: Only because it's from fox news. Don't bother wasting time on a reply, just eat shit Tex. Jeez, shouldn't there be a minimum age for posting to this list? Yes, I'm puzzled. A very late Saturday night? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11 Good News
On Tue, 2004-05-11 at 23:16, Durk Talsma wrote: On Tuesday 11 May 2004 08:31, Innis Cunningham wrote: Well Ampere the good news is that FG is quite happy to animate using the 3DS file. Another piece of good news is that the ground trimming problems have been solved by Mathias Frolich. His proposed solution is currently under investigation by Tony Peden and will hopefully traverse it's way from JSBSim cvs to FlightGear cvs wthin the next few days/weeks. It's in JSBSim CVS now, just needs to get into FG. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Questions about flight model
--- Andy Ross [EMAIL PROTECTED] wrote: Luca Masera wrote: about YASim: in which units is measured the oil pressure? In JSBSim the value is holded by oil-pressure-psi and it's measured in psi; in YASim is holded by epr but the units are missing. Er, that's an Engine Pressure Ratio , which is a thrust metric used in early jets in lieu of N1 RPM. FWIW, PW still prefers EPR over N1. YASim doesn't model oil pressure right now, because I'm not aware of a good basis on which to do so. If you have numbers you want to match for this particular aircraft, I could write you up some Nasal in just a few minutes which would do the job. But the idea behind YASim is to produce plausible results for all possible engines; oil pressure is one of those values that is (AFAIK) just too engine-specific. The units are missing, btw, because there aren't any. It's a ratio. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
--- Erik Hofman [EMAIL PROTECTED] wrote: Erik Hofman wrote: Jon S Berndt wrote: They are not now expected to be in any particular order, nor are they given specific names. The layout is somewhat free form. A questions is, how do you set up the gear model to support animation when you may want to model things as varied as a 747, a C-172, a P-51D, a Harrier, etc.? Maybe we should do the same as we did for the braking group, define a left (most), right (most) and nose gear compression and let the animation derive any values from that? Thinking about it again I think the solutions (for JSBSim) is quite simple, use the name of the entry (in lower letters) to define the gear: AC_GEAR NOSE -6.8 .0 -20.0 1800 600 .5 .8 .02 STEERABLE NONE 10 FIXED AC_GEAR L_MAIN 58.2 -43.0 -17.9 5400 1600 .5 .8 .02 CASTERED LEFT 0 FIXED AC_GEAR R_MAIN 58.2 43.0 -17.9 5400 1600 .5 .8 .02 CASTERED RIGHT 0 FIXED AC_GEAR TAIL_SKID 188.0 .0 8.0 2 1000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR LEFT_TIP 43.2 -214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR RIGHT_TIP 43.2 214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED /gear/nose /gear/l_main /gear/r_main /gear/tail_skid /gear/left_top /gear/right_tip The only change might be that YASim should allow for defining named gear locations. It seems like this would break down pretty quick when faced with all the variations e.g. a glider, a 172, 747, B-52, DC-10, etc. etc. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CG Location
On Tue, 2004-04-06 at 14:21, Jon S Berndt wrote: On Tue, 6 Apr 2004 16:59:55 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: I thought I read somewhere, that in Flight Gear, the CG of your aircraft isn't specific to the aircraft itself, but rather related to some sort of reference. Is this true? Or did I misinterpret something? It also mentioned that you could put the coordinates of (0,0,0) for CG location. sonny For a JSBSim flight model, there are a few reference frames of interest. I just published a newsletter for JSBSim that describes within it some of the various coordinate frames. Go to www.jsbsim.org, and click on the newsletter announcement at the top of the main page. All points that are specified in the config file are referenced to a coordinate frame that has the X axis increasing aft, the Y axis increasing right, and the Z axis increasing up. The origin technically could be anywhere, but is usually at or near the nose of the aircraft - although, technically, it *could* be placed coincident with the CG - even though the CG moves during flight. or put another way, it could be put at one location of the cg, the origin of the structural frame does not move with the cg. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] More on JSBSim ground trimming issue
--- Jon Berndt [EMAIL PROTECTED] wrote: I may be a little slow (monday morning here), but that does not tell me anything. We are talking about agl not the center of gravity. Is that the confusion? I'm not sure, but let me jump in here with a somewhat related comment. Like I've said before, the FDM naturally solves the rigid body equations of motion using the CG of the aircraft as a point of importance. At least for JSBSim we always will know where the CG location is in lat/long/alt. The FDM can _derive_ where any other point is located. This is important since the CG moves, and it can cause small problems when trying to link up the FDM and the visual model (hence the VRP solution). When it comes to AGL (Above Ground Level) we can report the AGL of the CG above the local ground elevation. We can (and any FDM can) report the AGL of any point on the aircraft, for that matter. So, the hard part is deciding where the point of importance is on the aircraft. Apparently, YASim uses the landing gear point of contact (?) -- arguably a point of importance at landing. We (JSBSim) use the CG -- arguably a point of importance for the FDM (since we measure gear contact points) from the CG, and depending on whether the gear are retracted or extended. For trimming on-ground the AGL value needs to be iterated on until the lowest point of the aircraft has a positive AGL value. Not really. Trimming iterates on altitude and theta until the landing gear are deflected just the right amount to hold the aircraft up. I'd have to think about this whole thing a bit more to figure out a logical potential solution, and I won't have time to do that for the moment, but I'll throw in my $0.02 to this discussion as it progresses. It would be nice to simplify things a bit. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
--- Mathias Fröhlich [EMAIL PROTECTED] wrote: On Montag, 5. April 2004 14:12, Jim Wilson wrote: This sounds like it might be excessive. We should continue to model instrumentation in flightgear. Fine. Nothing more on this is needed from the FDM (we should only be translating to sensor points _if_ the particular aircraft models the instrument). That translation could easily occur in a Instrumentation/ subclasses. It would then be standardized across FDM's, which is why it is not advisable to increase the complexity of the FDM interface. We're having enough trouble keeping what we have standard. Yep, I think this too. FGInterface is way too heavy. And too little standardized. And it is too little documented :) This seperation between hard and soft values are thought to make things a bit leaner and cleaner. But I am not shure if I can reach this goal with that. What I can tell is that I think FGInterface needs to be cleaned out to some degree. Ok, back to the original subject: I am interrested if JSBSim should rely on the /preset/sim/onground property to be set correct or if we should think of some heuristic to find out how we should trim? The trimming routine is not the problem. Jim W. said it himself, the behavior changes when - is set as the altitude. Well, the only place such logic exists is in src/Main, not src/FDM. I think eyeballs need to be directed that way. Furthermore, nothing regarding the trimming routine has changed for at least three weeks. I really am at a loss to explain why we have to go through this blame the trimming routine routine every time it fails. The trimming routine does not do magic, it's just a 6-dof zero finder, something every engineer learns how to code in school. It is not a mysterious black box. As such, it is no different than any other piece of code: GIGO. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
--- Mathias Fröhlich [EMAIL PROTECTED] wrote: On Montag, 5. April 2004 16:02, Tony Peden wrote: The trimming routine is not the problem. Hey, it is not. The problem is that JSBSim relys on a property which is set in a different way on start than on reset time. This property changes the 'trimming type' which is used for trimming. So we need to know if we could rely on this property or if we should find out ourselfes if we should do tGround or tLongitudinal trimming ... Been there, done that. No less grief. I really am at a loss to explain why we have to go through this blame the trimming routine routine every time it fails. The trimming routine does not do magic, it's just a 6-dof zero finder, something every engineer learns how to code in school. :) It is not a mysterious black box. As such, it is no different than any other piece of code: GIGO. Just for curiosity: What is GIGO? Garbage in, Garbage out. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
--- Jim Wilson [EMAIL PROTECTED] wrote:
Tony Peden said:
The trimming routine is not the problem.
Jim W. said it himself, the behavior changes when - is set as
the
altitude. Well, the only place such logic exists is in src/Main,
not
src/FDM. I think eyeballs need to be directed that way.
Furthermore,
nothing regarding the trimming routine has changed for at least
three
weeks.
They have been. The problem has been there unnoticed for several
weeks. And
yes it can be fixed there. This is a problem that has been there
before,
and seems to be unique to JSBSim.
I really am at a loss to explain why we have to go through this
blame
the trimming routine routine every time it fails. The trimming
routine does not do magic, it's just a 6-dof zero finder, something
every engineer learns how to code in school. It is not a mysterious
black box. As such, it is no different than any other piece of
code:
GIGO.
My question and I think Mathias' question is do we need this test in
JSBsim.cxx?
if ( fgGetBool(/sim/presets/onground) )
{
fgic-SetVcalibratedKtsIC(0.0);
fgtrim = new FGTrim(fdmex,tGround);
} else {
fgtrim = new FGTrim(fdmex,tLongitudinal);
}
What JSBSim does that YASim does not is if the aircraft is a little
too close
to the ground at initialization JSBSim hurls the thing up in the air.
Why is
it that only JSBSim reacts by flipping over the Cessna?
Exactly. GIGO.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
__
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
--- Jim Wilson [EMAIL PROTECTED] wrote: Andy Ross said: Jim Wilson wrote: What JSBSim does that YASim does not is if the aircraft is a little too close to the ground at initialization JSBSim hurls the thing up in the air. Why is it that only JSBSim reacts by flipping over the Cessna? YASim does something similar though: it doesn't have a trimming routine per se. Instead, if it detect the aircraft near the ground, it sets the altitude such that the lowest (extended) gear is at exactly ground level and drops it. No fancy trimming code needed. :) But will we ever know why JSBSim needs to do flip over the 172? :-) Bad data. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_GLUT_H
On Mon, 2004-04-05 at 15:08, David Luff wrote: Tony Peden writes: On Sun, 2004-04-04 at 18:14, Andy Ross wrote: Tony Peden wrote: I'm running RH9 and have found the need to add #include FG_GLUT_H to src/ATC/ATCdisplay.cxx src/Cockpit/cockpit.cxx src/Cockpit/panel.cxx It sounds like you're missing something from the recent glut changes. The glut.h header should not be included from *anywhere* in the general source code anymore. Can you be sure to do a complete cvs update and post the errors you get? Well, I did a cvs up -dP. Is that not enough? I guess you could try cvs up -dPA. I've been well and truely bitten by forgotten sticky tags in the past. My apologies if assuming that everyone is capable of my levels of incompetence doesn't apply in this case ;-) Oh, it probably does ... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] More on JSBSim ground trimming issue
On Mon, 2004-04-05 at 07:01, Jon Berndt wrote: Jon wrote: For trimming on-ground the AGL value needs to be iterated on until the lowest point of the aircraft has a positive AGL value. Tony replied: Not really. Trimming iterates on altitude and theta until the landing gear are deflected just the right amount to hold the aircraft up. I shouldn't have said trimming. I was thinking that a good initial value for altitude of the vehicle would be found as I described. Then, trimming could take place. OK, how do I do that without trimming? You know, I don't know that the trimming routine isn't the problem, I just know that that's where problems always show up, so it always gets the blame, deserved or not. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Mon, 2004-04-05 at 16:04, Jim Wilson wrote: Jon S Berndt said: On Mon, 5 Apr 2004 23:15:42 +0200 Mathias Fröhlich [EMAIL PROTECTED] wrote: The onground property is now ok. You can reset now JSBSim aircraft. Thanks for the fix! ?? Was it bad data? All that was bad was a flag caused the trim routine to be called or not called with a tGround parameter...whatever that is, which was discussed in this thread yesterday. Questions are still unanswered, so I'm sure that sometime down the road the trim routine will rear it's ugly head again. The trimming routine has several modes, one of which is tGround. That tells it to iterate on altitude and pitch attitude until the gear forces balance the weight. tLongitudinal tells it to trim in-air with angle of attack for lift, elevator for pitch, and thrust for speed. tFull tells it to trim all six axes, those above plus adjust the controls, bank angle, and sideslip to trim yaw, roll, and side force. tTurn sets up the body axis rates to perform a tFull trim in a steady state turn. If I knew of a way to make the trimming routine less sensitive to bad data (such as a bad terrain altitude) or divine how it's supposed to set itself up, I'd do it. I can think of things that could be done but they all involve either a sacrifice in capability or attempting to make the trimming routine smarter than it should be. David's explanation is relevant but not entirely, because this issue was showing up doing a full reset. I think, that maybe this could be resolved by doing as Andy described earlier. In other words know where the gear is and get it above the pavement (ground elevation) before the simulation starts. Then and only then drop the sucker, start the simulation, and let it settle. Sorry for the simplistic explanation and my apologies for suggesting that JSBSim could do something about bad data instead of just crashing random aircraft. Thank you. As it is now we need to test every single JSBSim aircraft every time a modification is made to flightgear because the trim routine is lacks robustness. It does demand alot of both the calling program and the aircraft configs. As much as I'd hate to see it stop getting used, maybe the right thing is too just stop using it altogether. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Mon, 2004-04-05 at 14:30, David Culp wrote: Bad data. On the part of ... ? I'll attempt an explanation. If I'm wrong maybe Tony can add two words. OK, one and a half. 1) A JSBSim airplane can only be placed on the ground after going through an iterative routine to lower it and adjust it's body angle to balance-out the forces at the gear. 2) If the airplane could be removed and placed back at the exact trimmed position and orientation immediately, it should be able to stay still because nothing has changed. 3) If the airplane burns fuel, then its CG and weight changes, therefore if you try to return it to the former trimmed position, which was based on a heavier weight and different CG, then there will be too much, and an unbalanced amount of, spring tension. 4) Therefore, to reset the airplane at the runway, a JSBSim airplane must be allowed to run through the same trimming routine it does at start-up. No shortcuts are allowed. Yep. See, just one. ;-) Dave -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Mon, 2004-04-05 at 07:32, Mathias Fröhlich wrote: On Montag, 5. April 2004 16:26, Tony Peden wrote: --- Mathias Fröhlich [EMAIL PROTECTED] wrote: On Montag, 5. April 2004 16:02, Tony Peden wrote: The trimming routine is not the problem. Hey, it is not. The problem is that JSBSim relys on a property which is set in a different way on start than on reset time. This property changes the 'trimming type' which is used for trimming. So we need to know if we could rely on this property or if we should find out ourselfes if we should do tGround or tLongitudinal trimming ... Been there, done that. No less grief. So what do you think: should we tell the flightgear maintainers that this property needs to be set correct or should we think of a heuristic to make this decision ourselves? If you can come up with a reliable one, I'm all for it. All my experience with it ends up making me feel like I do when Word fixes what it takes to be an error on my part. Greetings Mathias -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Mon, 2004-04-05 at 01:23, Mathias Fröhlich wrote: On Montag, 5. April 2004 03:02, Andy Ross wrote: I'm happy to dumb down the existing AGL property, but we should pick a new name for the gear altitude property, which is IMHO a much more interesting value. To me there arises the question which gear do you take for this? The nose gear for example will have a different agl then any other gear depending on the orientation of the aircraft. We should also pick a coordinate origin to report it relative to. If JSBSim is using the (moving) c.g., then we're both bugged. :) Yep you are right, on my list of improvements to JSBSim there is a 'sensor location' config option. Not really thought about this in deep and not started to ask for the others' opinions. This would solve this problem too. Just define a sensor for the altitude. And define a reference point where this radar altitude sensor will compute its reference height to (I don't know how these radar sensors realy work ...). We already have such a point, the VRP, why not just use it? From FG's point of view this would probably seem more consistent. I think one needs to distinguish between values which define the /hard/ position of the aircraft (lat/lon/radius is sufficient or may be lat/lon/altitude). These hard values can be read and set from flightgear. And /soft/ values, only required for instruments/autopilot ... The soft values are read only to flightgear. They are just the result of the aircraft configuration when the aircraft's position is set to the hard ones. The soft ones do not need to be consistent with any other values without knowledge of aircraft internals (FG should not expect that sensor_agl+groundlevel==altitude+sea_level). Note that I only suggested a nonredundant set of values for the hard values: no agl here. So here the consistency question does not arise. This would also mean that flightgear cannot just set the agl of an aircraft in the FDM. If flightgear wants to do that, it has to compute the altitude and set that instead. greetings Mathias -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_GLUT_H
On Mon, 2004-04-05 at 17:53, Tony Peden wrote: On Mon, 2004-04-05 at 15:08, David Luff wrote: Tony Peden writes: On Sun, 2004-04-04 at 18:14, Andy Ross wrote: Tony Peden wrote: I'm running RH9 and have found the need to add #include FG_GLUT_H to src/ATC/ATCdisplay.cxx src/Cockpit/cockpit.cxx src/Cockpit/panel.cxx It sounds like you're missing something from the recent glut changes. The glut.h header should not be included from *anywhere* in the general source code anymore. Can you be sure to do a complete cvs update and post the errors you get? Well, I did a cvs up -dP. Is that not enough? I guess you could try cvs up -dPA. I've been well and truely bitten by forgotten sticky tags in the past. My apologies if assuming that everyone is capable of my levels of incompetence doesn't apply in this case ;-) Oh, it probably does ... Several files got patched, but not the ones I changed. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_GLUT_H
On Sun, 2004-04-04 at 18:14, Andy Ross wrote: Tony Peden wrote: I'm running RH9 and have found the need to add #include FG_GLUT_H to src/ATC/ATCdisplay.cxx src/Cockpit/cockpit.cxx src/Cockpit/panel.cxx It sounds like you're missing something from the recent glut changes. The glut.h header should not be included from *anywhere* in the general source code anymore. Can you be sure to do a complete cvs update and post the errors you get? OK, I did the cvs up -dPA and made sure my patched files were out of the way. I still get: source='ATCdisplay.cxx' object='ATCdisplay.o' libtool=no \ depfile='.deps/ATCdisplay.Po' tmpdepfile='.deps/ATCdisplay.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o ATCdisplay.o `test -f 'ATCdisplay.cxx' || echo './'`ATCdisplay.cxx ATCdisplay.cxx: In member function `virtual void FGATCDisplay::update(double)': ATCdisplay.cxx:75: `gluOrtho2D' undeclared (first use this function) ATCdisplay.cxx:75: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [ATCdisplay.o] Error 1 I presume the files in src/Cockpit will do the same thing. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_GLUT_H
On Mon, 2004-04-05 at 19:32, Andy Ross wrote: Tony Peden wrote: ATCdisplay.cxx:75: `gluOrtho2D' undeclared This is a GLU function, not a glut one, so the appropriate header to include should be GL/glu.h. Including glut.h works presumably because it pulls in GL.h and GLU.h on its own. src/ATCdisplay.cxx src/cockpit.cxx src/hud.cxx src/panel.cxx I'm honestly not sure why you're seeing compilation errors, though. What are the other files you're having trouble with? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FG_GLUT_H
I'm running RH9 and have found the need to add #include FG_GLUT_H to src/ATC/ATCdisplay.cxx src/Cockpit/cockpit.cxx src/Cockpit/panel.cxx Is there something peculiar about RH9 or my install? I ask because I find it hard to believe that I'm the first to run across this if it affects everyone since I haven't attempted to build FG in several months. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] flight path heading
--- Jim Wilson [EMAIL PROTECTED] wrote: Does anyone have a formula handy for calculating the flight path of an aircraft in true degrees (direction of travel as opposed to the airframe heading)? My guess is that it'd be a matter of doing something with the lon/lat from the previous frame. Maybe there's something simpler with the current FDM output in FlightGear? JSBSim calculates the heading of your ground track, that sounds like the same thing. I don't know if it's currently available in the FG property tree, however. Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Fri, 2004-02-13 at 10:23, Russell Suter wrote: Jon Berndt wrote: So, instead of defining some arbitrary frame, _we_use_an_industry_standard_, which is the structural frame that the manufacturer defines, when available. It is always (in my experience) X positive aft, Y positive right, with the origin being seemingly arbitrary. I wouldn't go so far as to say this is an industry standard. FG is the first sim I've seen that uses this coordinate system. The one I've seen the most is X positive forward, Y positive right and Z positive down. Someone once told me this was named the Boeing system. On the sim I'm working on now, it's positive Y forward, positive X to the right and positive Z up. I'll admit that most of the sims I've worked on are relatively old in FORTRAN and C. There really are no industry standards here. Body axis, earth local, and earth fixed are commonly used in simulation. A system like our structural system is commonly used by manufacturing, ground ops, and flight ops folks. But even then, the origins vary from airplane to airplane. Don't get me wrong, I'm not saying this is a bad system, I'm just not sure I agree it is an industry standard... -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerodynamic centre and 3D models
On Thu, 2004-02-12 at 12:53, Jon S Berndt wrote: On Thu, 12 Feb 2004 15:35:59 -0500 David Megginson [EMAIL PROTECTED] wrote: Jon S Berndt wrote: I'm not sure I see how this helps -- the model code still doesn't know where the CG is, so it still doesn't know where the centre of rotation for the model should be. This is precisely *why* the nose is used as a reference point. If the scene graph (is that the right term/subsystem?) places the aircraft at the spot reported by JSBSim -- that is, where JSBSim says the nose of the aircraft is -- the perceived CG of the 3D aircraft as viewed in the scene will fall exactly in the spot that the FDM says it should be at. Look at it this way: the FDM tracks the motion of the CG, and the rotation of the aircraft about the CG. The FDM knows teh location of the CG at any point in time, as well as the euler angles of the aircraft at that point in time. If we were to report the location of this CG to FlightGear, and IF the origin of the 3D model was allowed to shift (by some magic) and always be coincident with the virtual CG in the 3D model, then we'd all always be happy and everything would match up fine. The problem is, the CG shifts and the 3D model coordinate system can't. Since the FDM knows (or can calculate) where the nose is at all times, we simply report the nose location to FlightGear, and by convention FlightGear places the 3D model's nose at the point reported by JSBSim - the CG falls into place as needed IFF the 3D model is defined (or scaled/rotated/translated in the scene graph) correctly as described previously. And said nose location *includes* any translation the nose experiences due to the aircraft rotating about the cg. In other words, if you could move the aircraft such that only the pitch angle changes (not terribly real, but humor me) and that pitch angle change results in the nose rising 10 feet, then the FDM reports the nose location as the CG altitude + 10 feet. So now, if the 3D model code positions the nose of the aircraft at that location and pitches it to the corresponding angle, the CG will not have moved at all but the nose will. And that means that the model will appear to rotate around the CG, just like it should (in free air, at least. On the ground is a different thing) Takeoffs and landings would look fine, etc. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Commercial Ticket..
On Wed, 2004-02-04 at 19:54, Curtis L. Olson wrote: Andy Ross wrote: Curtis L. Olson wrote: The real fun comes from practicing with only one engine running [...] There are some real world effects that are important for training which I don't think we model well on existing twins. The main one that comes to mind is that with an engine out there is a minimum speed you must maintain That's no doubt true, but hopefully it's more a lack of tuning than it is a fundamental flaw. For the specific case of YASim: the asymmetric thrust effects should be more or less correct as-is, because it applies the force at the location of the engine. The blue line speed is almost certainly wrong, but should be relatively easy to find by tuning the rudder effectiveness only. If anyone with ME experience wants to take a few hops in the DC-3 or (YASim) C310 and provide feedback, I'd be happy to try tuning the models. It very well could be a model setup issue at which point it's probably beyond my ability to debug, but with the JSBSim c310, I took off, climbed to a comfortable altitude and speed, and chopped the throttle on my right engine. Then I slowly pitched up to bleed off speed little by little. As the speed bled off, I held my heading with rudder and kept the wings level with aileron. From the readme: Minimum single-engine control speed (Vmca): 75 KIAS However, I was able to fly right through this until I got the stall horn, (about 60 kts?) and all the time, the rudder had plenty of effectiveness to hold heading. In the real thing (assuming the README is correct) at about 75 knots the rudder loses enough effectiveness to hold heading against the one good engine at full throttle and you begin an uncontrollable yaw. This doesn't happen right now in the JSBSim C310 anyway. It sounds like it's got too much rudder power or too much directional stability. It could be the propulsion, too, but if the performance is about right then it's probably the aero. I'm sure this is just a matter of tweaking the configuration file. But this is an important behavior to have reasonably correct in small twins. I also tried this with the YASim C310. I see a definite yaw effect from the engine, but I think I am getting to the stall point there too before I'm getting to the point where the rudder looses effectiveness against the engine. At about 80 kts (yasim version) the rudder can't quite hold heading by itself, but I can add a bit of bank towards the good engine with ailerons and hold my heading until I stall. At the point of the stall in the real aicraft, the good engine would definitely dictate the direction of the spin. I find in the yasim model, the aircraft can stall/spin into the good engine about as easily as the other way. In both cases it's probably just the models that need tweaking, but in their current form, I don't think they are very useful for engine out training. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Visual Reference Point
On Sat, 2004-01-31 at 04:46, Mathias Fröhlich wrote: On Samstag, 31. Januar 2004 12:46, Christian Mayer wrote: Jon Berndt schrieb: I just discovered that our property metrics/eyepoint-x-ft shows that it is expected to be in units of feet. However, it is specified in inches in our config file (in structural frame), and the property is bound to the GetXYZep() function, which reports the eyepoint in the same way it is specified: units of inches, in structural frame. I suppose this ought to be changed. If we'd use SI units everywhere we wouldn't have that prolem... (and if NASA would have consitently used SI they wouldn't have lost one Mars probe...) I am also used to the SI system. But all I have seen up to now in the area of physical aircraft models is given in units of feet and such. So I think the FDM should be able to work using this values. What I can think of is an extension to the property tree, either private to JSBSim or better in Flightgear in general. I would like to be able to tie a value with a given unit into the property tree. Then there should automaticaly appear a set of values in the property tree which represent this value in different units. There are many possible scenarios how this can happen. The most compatible one will be to tie a value with unit into the property tree without the unit extension in the name. Then there are automatically the usual unit values in the tree. For example the angle of attack will be tied to the variable 'alpha' with an angular unit originaly given in rad, but that alpha will not appear as 'alpha' in the tree, but instead two variables appear. One 'alpha-rad' and one 'alpha-deg'. The same can of course be done for unit conversion from and to the SI system. The other possibility, which is not that backward compatible, will be that each value is represented by a whole directory. Inside this directory there are then only unit names. For example the angle of attack will then be accessible through alpha/deg or alpha/rad. I certainly do agree that selectable units would be nice to have, but it would double the property tree memory requirements (since each property would then have to have a units property associated with it. In addition, such a system would significantly increase the amount of code that would execute at each property access. This will also simplify building aerodynamic coeficient lookup talbes which are sometimes given in, say 'lift per degree elevator deflection' or, for an other aircraft type in 'lift per rad elevator deflection'. I know, this is simple scaling, but I think that simple things should be left to a computer ... :) All coefficients must be in consistent units (generally those of force) after the multipliers are applied, so I see no advantage here. There is no formal requirement for this since JSBSim does not attempt to assure unit consistency but it's there nevertheless. If someone has spare time to work on such a automatic unit system ... Also, I have not looked into the property tree implementation if this could be done easily. Greetings Mathias -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Visual Reference Point
On Sat, 2004-01-31 at 04:14, Melchior FRANZ wrote: * Christian Mayer -- Saturday 31 January 2004 12:46: If we'd use SI units everywhere we wouldn't have that prolem... (and if NASA would have consitently used SI they wouldn't have lost one Mars probe...) That's not fair. You know that the U.S.A., Liberia and Burma have very good reasons for not joining the SI system! Yes, we are too lazy and too cheap to go about changing it. :) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Visual Reference Point
On Sat, 2004-01-31 at 08:48, Mathias Fröhlich wrote: On Samstag, 31. Januar 2004 16:41, Tony Peden wrote: I certainly do agree that selectable units would be nice to have, but it would double the property tree memory requirements (since each property would then have to have a units property associated with it. In addition, such a system would significantly increase the amount of code that would execute at each property access. Yes, this would increase memory requirements. I don't know the property tree code well enough to judge about how much this will increase the memory and execution time usage. Just for curiosity, how much memory usage does a single node in the property tree have? Or, do you know how much the usage of the property tree is compared to the scene graph and the textures? This will also simplify building aerodynamic coeficient lookup talbes which are sometimes given in, say 'lift per degree elevator deflection' or, for an other aircraft type in 'lift per rad elevator deflection'. I know, this is simple scaling, but I think that simple things should be left to a computer ... :) All coefficients must be in consistent units (generally those of force) after the multipliers are applied, so I see no advantage here. There is no formal requirement for this since JSBSim does not attempt to assure unit consistency but it's there nevertheless. The advantage would be, in my example, that I have the angle of attack/surface deflections available in rad but the tables I have found for an f-18, I am currently modelling, contain tables for the coeficients in something per deg. So I have to scale this tables by hand/matlab/octave. Yes, and I think that is appropriate for JSBSim. It would be more appropriate to put that kind of functionality into, say, an app that assists in creating a JSBSim config file. From that point of view, it is probably best to pick one consistent set of units and stick with them, which is what we have done. For a more general case, if one has all those aerodynamic tables given in the SI system (are there any aircraft models in the SI system?), one will be able to take these tables and simply use the input values in the matching units. So, for best performance, we are right back to the situation we have now. The only advantage (and being American I'm not sure it is one) is that we've switched to SI as the default. I, for my stuff, can work around, but it would be neat to have. May be it is not worth the effort ... Greetings Mathias -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft frames and reference points
. It takes both, the nose point isn't 'it' like some of you have tried to imply. There was something else to your system, which there had to be to bring the FDM and the visual model frames into full alignment. No single point fix at the nose or even the CG can completely align two frames. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
silly flying. Now have the common reference be the POS. Any visual size scaling looks great without any adjustment to the FDM. It is the much better reference point to work from for matching the visual and FDM models. It is where they both agree with the least calculations and problems from any errors. Matching your nose just SHIFTS your error over if you don't have your visual and FDM centers matched too. And the shift makes the total error motions worse not better. It is perfectly FINE to match the nose, and have BOTH say that it's exactly this far from the POS, and do the calculation once then have the models work from the POS. But the calculation from the nose to the POS has to be the same for both anyway. You're only hiding the error from yourself if you believe matching the nose will be easier and have less error than finding the POS. And point was that the calculations for both visual model and FDM are simplified by using this point. Having the FDM coordinates and model coordinates match up is critically important for collision issues like gear compression. There is a far more important point that has to be matched than the nose. And there was also mention of a CG reference for the FDM. POS which is COL for the plane is the REAL reference point and gets the simplest calculations. The CG arms for calculating the CG are from the COL, not the current CG. CG is purposely put a bit forward of the COL for stability. COL is the real reference point, which is the POS for a flying body. COL is the average point where the plane is being held up by the air. Everything else necessarily happens around this point. I fly RC helis and planes in 3D. I have both my mental model of the physics and the visuals of what is seen to go by. The place they match and rotate about with the easiest calculations is the center, not the nose. I was simply reporting this fact. I know it's a fact I use it every time I fly, it is much better to fly from the center point in 3D than be flying from the nose and have to deal with it's extra motions that often don't agree with the direction the aircraft is actually moving. I can fly by the nose quite well too. But it's easy to see it moves around the true center like mad. Something tells me you guys rarely fly in odd attitudes from outside the aircraft. This is a quite solid fact for me since I see and use it often. You may never properly understand it just from theory if you don't fly from outside, you just won't see why you're wrong about thinking the nose is the right place to match. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Sat, 2004-01-10 at 14:10, Alan King wrote: Jon Berndt wrote: You are in an A-10 with a maverick on one side. You have an aircraft CG (which the FDM is reporting the position of) and an MRP, which the FDM is also supplying to FlightGear. The MRP is given to FlightGear in lat/lon/alt. The FDM calculates that position because it knows where the CG is absolutely, as well as where the MRP is relatively. Since the 3D model builder and the flight modeler for the aircraft agree on the MRP (we hope!) the aircraft can be placed properly in the scene. Now, say we are stationary on the runway and we drop the missile. The CG shifts instantaneously - however the FDM will not report a different position because no force has caused an acceleration which in turn could not have been integrated to produce ultimately a change in position. This is a flaw that may need to be addressed. In any case, let's assume that the FDM *did* shift the reported lat/lon/alt of the CG as reported to FlightGear by the equal and opposite amount that dropping the Maverick resulted in. The vector to the MRP would be shifted by an equal and opposite amount, and the end result would be that the model would not jump and the FDM and the model would agree. In the case of smooth flight where fuel burns off slowly, it's not so critical. It is hard to tell from what's said whether you're using the COL as the reference or the CG. COL is the real reference to use in the FDM, the CG is purposefully forward on most craft for stability. The CG swings around the COL pivot point noticably when you change pitch. Also all moment arms are from COL and you actually load the plane to put the CG where you want it, the COL is the real reference point. If you're not already using this, try a very high wing low CG plane. Pivot it around the CG. Then pivot it around the wing's COL. Which looks even close to the real pivot point? Once the wheels are off the ground, the center of gravity is the point about which the aircraft rotates. It does not rotate around the aero center or any other point. Also, the c.g. does *not* change with pitch attitude. It's location is purely a function of the weight distribution within the vehicle. To model a bomb drop correctly you simply use the COL as the suspension point, and calculate all forces off of it on each pass, including the moment arms. With the Maverick gone and no longer having it's moment arm in the equation for CG the next calculation pass the CG will shift automatically, and the new distance between the CG and the COL will take care of any resulting motions on it's own and move the plane till things are back to balance. It would be built into the calculation pass, and move on it's own. Really you can just calculate total CG once or rarely and just move the CG when the bomb drops by subtracting it's moment arm. But the COL should be the motion and suspension point of the craft not the CG. The change in the CG relative to the COL should automatically introduce the forces to change the overall orientation around the COL. The COL can shift too as orientation changes but it's the point to calculate from, no one said an accurate model was easy. Just accurate. You can use any point as a point of reference as long as you make sure all translations are in all the calculations. You can start from the CG, and then calculate the COL is over here, and use that to move the craft. But the craft should swing around the COL either way, so you have to do extra translations to make the CG reference point move. COL and CG can both move, but COL is the real hang point of the aircraft so using it simplifies calculations for a truly accurate model. That's why weight and balance calculations are relative to it instead of where the starting CG was. The starting CG is used in the calculations, along with it's moment arm from COL. There are less translation adjustments if you reference everything from that point. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Sat, 2004-01-10 at 19:20, Alan King wrote: Jon Berndt wrote: I see what you're doing now. You are letting them just use the nose, and then shifting the FDM nose point until the FDM center is near the visual center. Not really. The FDM still calculates the position of the CG of the aircraft. It's just that we know exactly where the agreed-upon MRP is at all moments of time, so we calculate that and give it to FlightGear. We could just as easily agree that the wingtip was the common known point, calculate that, and have FlightGear place the 3D model in the view so that the wingtip was at the specified point. The only thing the FDM does as an auxiliary calculation to aid the 3D model placement is to additionally calculate the MRP position in world space and make that available to FlightGear. Or, at least, we will when I code it. Jon Ok that gets back to the same question then. What else besides the nose point does FlightGear use to place the visual model? Say your CG is at the origin. Your nose is 10 feet forward. FG puts the visual model's nose at the 10 foot position since that is the common reference point. What makes sure that where the CG is on the visual model is at 0? Nothing. It's not necessary. Every dimension supplied to the FDM is automatically referenced to the c.g. position. In other words, if the c.g. is at 10 feet and the reference point at 20, the only thing that's relevant to the FDM is the difference between the two. If you follow that, you'll realize that the location of zero is of absolutely no significance. You do a 20 foot long plane FDM, with CG at 10 feet. I draw a 3000 foot long plane. The noses match. Does about 2980 feet of my plane sink into the ground? You need only tell the FDM that model's reference point is 2980 feet forward. What makes sure that the CG is put at the right place in the visual model with the nose as the only reference? Does FG just scale the total model, the FDM also gave a length for the model, and FG assumes the visual model has the wing in the right place? It doesn't need to be. If the reference point is known to the FDM, it can properly calculate it's location in space, and that's all that's needed. The CG location is 100% irrelevant to the visual model. Only six pieces of info are needed by the code that draws it in the scene: the x, y, and z of the reference point and the pitch, roll, and heading angles. If the x,y, and z are calculated correctly then the model will appear to rotate around it's cg once it's off the gear. Maybe FG uses your CG, matches the nose, then just guesses the CG of the visual model of the overall size? There just has to be some other piece of data that correlates. If not there is no telling if the real FDM CG is where it's supposed to be on the visual model. An off center reference point like the nose isn't enough if you have no other data to calculate back and match the center. If they're actually accurate together, there is something else matching. And if there isn't anything else matching in some accurate way, then there is no telling if the FDM CG and where it should be on the visual model are really matching. What else is FG doing to put them in the same place? Nothing at all. It's not needed. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Sat, 2004-01-10 at 18:31, Alan King wrote: Tony Peden wrote: Once the wheels are off the ground, the center of gravity is the point about which the aircraft rotates. It does not rotate around the aero center or any other point. Yes, been a while since I'd used the POS. It is the other way around, with a fixed POS it's the best point to use. With no outside force fixing the point of suspension it will shift around the CG and the CG is the best to use as reference. No, it really isn't. The c.g. location is best computed by the FDM as it runs, since it moves in flight as fuel is burned, ordnance is dropped, etc. Also, the c.g. does *not* change with pitch attitude. It's location is purely a function of the weight distribution within the vehicle. Wasn't saying it would actually change, only that it would translate. OK, I suppose you could argue this if you're thinking in terms of an earth fixed coordinate system. But it doesn't it's the other way around the CG is the reference point and the suspending point moves around when it's free to move. The motion's all the same relatively as always, but it's when the POS is fixed that it is the better point of reference to work from not when it's free to move. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autocoordination
On Fri, 2004-01-09 at 12:30, David Culp wrote: Take the A320 (on FG) and watch the ball. All I want to know, which property to use for trigger function to keep the ball centered. since you discussed this topic so deeply, I'm sure someone can name me the property... Here's the yaw section from the T-38 FCS: !-- YAW FCS *** -- COMPONENT NAME=Rudder Command Sum TYPE=SUMMER INPUT fcs/rudder-cmd-norm INPUT fcs/yaw-trim-cmd-norm CLIPTO -1 1 /COMPONENT COMPONENT NAME=Yaw SAS Rate TYPE=SCHEDULED_GAIN INPUTvelocities/r-aero-rad_sec SCHEDULED_BY velocities/ve-kts ROWS 3 30 0.00 60 5.00 220 3.00 /COMPONENT COMPONENT NAME=Yaw SAS Beta TYPE=SCHEDULED_GAIN INPUTaero/beta-rad SCHEDULED_BY velocities/ve-kts ROWS 2 30 0.00 60 0.00 /COMPONENT COMPONENT NAME=Yaw SAS Sum TYPE=SUMMER INPUTfcs/yaw-sas-rate INPUTfcs/yaw-sas-beta CLIPTO -0.2 0.2 /COMPONENT COMPONENT NAME=Rudder Sum TYPE=SUMMER INPUTfcs/rudder-command-sum INPUTfcs/yaw-sas-sum CLIPTO -1 1 /COMPONENT COMPONENT NAME=Rudder Control TYPE=AEROSURFACE_SCALE INPUTfcs/rudder-sum MIN -0.35 MAX 0.35 OUTPUT fcs/rudder-pos-rad /COMPONENT The component called Yaw SAS Rate is what one would call a yaw damper. It's job is to provide an extra Yaw_moment_due_to_yaw_rate for airplanes that are defficient in this quality. The component looks at beta rate (in JSBSim it is called velocities/r-aero-rad_sec). That is yaw rate, which is different from beta rate in a similar way that angle of attack rate is different from pitch rate. Beta rate (or betadot, as it's more commonly called) is aero/betadot-rad_sec in JSBSim. The component called Yaw SAS Beta is what you are looking for. It could be called an auto-coordinator, because it is based on the beta angle. In this case I have the component turned off. To turn the component on you simply change the scheduling gains from zero. For instance, look at the yaw damper. At and below 30 knots the yaw damper gain is zero (off). Between 30 knots and 60 knots the gain is interpolated from zero to 5.0. Between 60 knots and 220 knots the gain is interpolated from 5.0 to 3.0. I recommend this component be turned off at low speeds, otherwise it will fight a crosswind even when the airplane is stationary. The outputs of the yaw damper and auto-coordinator are summed, then limited to %20 rudder in order to prevent it from overpowering the pilot's input. This is just one way of building a yaw SAS. Dave -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
On Fri, 2004-01-09 at 17:29, Paul Surgeon wrote: On Saturday, 10 January 2004 00:35, Erik Hofman wrote: No, sorry. AC_EARORP is the published offset from CG to where the forces act. For the F-16 that would be 35% chord (and CG is 25% chord). Just *maybe* I got it this time around. :) So any distance in the FDM is just an offset from (0,0,0)? If that is true I could offset all the distances in the FDM by an arbitrary value (let's say 1000 inches) and the FDM will still behave the same? I could pick a point 10 meters in front of the plane and measure everything from there too. In fact I could define all the distances using negative values as well (thinking in terms of 2nd Cartesian quadrant). The _only_ thing that matters in JSBSim is the direction that is positive for each axis. Positive forward, right, and up for the coord system used in the config file. The way I'm understanding all of this is that the nose of the aircraft CAN be used as the origin of the FDM but doesn't have to be. Yes. I could just as well work from the tail and just enter negative offsets. Correct? Yes, yes, yes! Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My Flight in a B-1B Flight Simulator at Dyess AFB
On Wed, 2003-12-24 at 05:51, David Megginson wrote: Cameron Moore wrote: One question though. I mentioned trying to line up with a fuel tanker and how the delayed movement was throwing me off. My guess is that this behavior was due to slow control surface movements. My question is if JSBSim simulates control surface movement speeds (excluding the flaps which do) or is the control surface deflection always exactly equal to the control input? Hinge moments for control surfaces probably have something to do with it, but remember also that you're flying a heavy, fast plane. Even if the plane is very responsive to control input (which has more to do with aerodynamic damping effects than control-surface response speed), you're not going to be able to change the flight path on a dime. All other things being equal, a plane that flies twice as fast (say, because of heavy wing-loading) needs twice as much time and four times as much space to make a change in its flight path -- that's why a little Cessna or Piper can start its landing flare over the runway itself, while a transport jet has to start flaring at least a half mile back (pulling up the nose at the last moment would only change the attitude in which the jet smashed into the runway). Airliners aren't that sluggish ... the flare is initiated below 50 ft AGL and that is definitely over the runway. Jet fighters turn fast only by pulling ridiculously high G-forces, and even then, they need a lot of time and space to turn around. I'm sure that inertia has a lot to do with it as well, but I don't know enough about physics to describe those effects. Inertia is a player, but most aircraft do not have large roll moments of inertia .. the mass tends to be concentrated close to the roll axis. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My Flight in a B-1B Flight Simulator at DyessAFB
On Wed, 2003-12-24 at 08:01, Andy Ross wrote: Nick wrote: If the simulation is accurate the delays are due to the aircraft inertia and not control system delays. Hydraulic controls don't have a humanly discernable amount of delay. Simulators have their own delays too, the time it takes a signal to get through the circuit from the control to the computer and them to be processed in the next frame., but this is on the order of 50-100 milliseconds. Hydraulics *do* have a maximum slew rate, though, which might be what he meant. On a Cub, you can snap the stick from one side to the other and the ailerons actually move. With a hydraulic system, you can only move the stick so fast; the fluid in the pipes needs time to flow, and the pumps can only handle so much volume at once. Aircraft hydraulic systems are typically high pressure, low flow to minimize those sorts of problems. There is a transition-time attribute in YASim that you can use to specify speeds for surface deflections. I added it for flaps, obviously, but I think I've seen that Lee has used it for this kind of applicaiton. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My Flight in a B-1B Flight Simulator at Dyess AFB
On Wed, 2003-12-24 at 17:53, David Megginson wrote: Tony Peden wrote: Airliners aren't that sluggish ... the flare is initiated below 50 ft AGL and that is definitely over the runway. I guess that brings us back to the old discussion about round-out vs. flare (U.S. books seem to distinguish the two). The jets are are nose-high and slowing about 1/2 mile back, whatever you want to call that, while the single-engine props are sometimes still nose-low at full approach speed when they cross the runway threshold. The nose up attitude is, I suspect, nothing more than a product of the angle of attack needed to fly at 1.3-1.4 times the stall speed. Procedures wise, though, once you are at landing flaps and trimmed on glideslope and final approach speed (which could be at the outer marker) the pilot would, on an ideal day, maintain speed and attitude all the way to the flare. Inertia is a player, but most aircraft do not have large roll moments of inertia .. the mass tends to be concentrated close to the roll axis. I'm thinking of the effect of inertia on changing the flight path, not on changing the orientation. I obviously have no real-life experience, but I imagine that the hard part of an in-air refueling is getting the plane into the right place relative to the tanker and keeping it there, which involves modifying the plane's velocity and path of flight rather than simply its pitch and roll. I understand how velocity affects that (a plane twice as fast needs twice the time and four times the space to make the same change in direction with the same load factor), but I don't understand how inertia plays into it. All the best, and happy holidays to everyone, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] My screen shot.
On Thu, 2003-11-13 at 07:55, Andy Ross wrote: Norman Vine wrote: Somethng like this is easy enough to implement with the current hitlist code but ... I don't understand why the compressability of the gear has any bearing on the point of contact. It is the AC that is changing not the Terrain Gear don't always compress perpendicular to the ground, and not all aircraft contact points are landing gear. Wing tips, for example, might hit the ground at funny angles or hit terrain objects like buildings that aren't flat. But they won't compress at all until contact, at which time the point of contact is known. The location of ground contact (and thus the point of force application on the aircraft) is going to be somewhere on the line between the point of maximum gear compression and maximum gear extension. Where? At the point where this line segment interects the terrain polygons. (Strictly, at the intersection nearest the max compression point if there is more than one). Why wouldn't the gear always contact the ground at max extension? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] gear door sequencing
--- Frederic BOUVIER [EMAIL PROTECTED] wrote: David Culp wrote: Wow Fred! It's been a while since I tried the A320. That's a fantastic model, and the gear door sequencing looks great. Thanks, It is still missing the speedbrakes, slat and reverse. BTW, as a non native english speaker, I need some clarifications on terminology. Am I correct when I say : Slat are in front of the wing, Yes. Speedbrakes are on the top of the wing ( the extrados ? ) and can be used flying, The panels on top of the wing are usually called spoilers but they can function as speedbrakes. Speedbrakes can, in general, be located anywhere on the aircraft. Though those mounted on the fuselage are usually on top (F-15) or somewhere aft of the wing (F-16). Reverse are small doors on the engine nacelle that open once the plane is landed and try to stop before the end of the runway. Yes. Thrust reversers force some or all of the airflow out of the engine in the forward direction and slow down the aircraft. Note that depending on the design, the actual mechanisms involved can be quite large. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [wms-dev] CWXML-BXML library release
On Mon, 2003-09-22 at 23:00, Norman Vine wrote: FYI -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Craig Bruce Sent: Tuesday, September 23, 2003 1:39 AM To: [EMAIL PROTECTED] Subject: [wms-dev] CWXML-BXML library release For anyone who may be interested, CubeWerx has made a public beta release of its cwxml library. The home page is at: http://www.cubewerx.com/cwxml/ and a Binary-XML design performance report is available at: http://www.cubewerx.com/main/HTML/Binary_XML_Encoding.html What is CWXML? CWXML is an high-performance, open-source C-language library for parsing and generating XML and BXML (below) formats with a straightforward API. Initial testing indicates that it is 3 or more times as fast as other popular libraries such as expat and libxml2 at parsing XML and much faster again with BXML. The library is being developed by CubeWerx as the reference implementation for the BXML format. The parser accepts and automatically recognizes the following formats: XML, GZIPped XML, BXML, BXML with internal GZIP, and BXML with external GZIP. It is licensed under the GNU LGPL. What is BXML? BXML (Binary XML) is an straightforward, open, patent-unencumbered binary-encoding format for XML data that is a stand-alone work-alike drop-in replacement for an XML file that mirrors the XML markup structures in a way that is similar to the in-memory representations of many parser libraries. BXML was developed by CubeWerx Inc. for the OpenGIS® Consortium and it makes all XML documents more compact and efficient to parse and generate by using a symbol table for element/attribute names and length-prefix encoding all arbitrary-length structures (strings, blobs, arrays). But it especially makes dense-numeric XML documents much more efficient by allowing raw arrays of different common types of numbers. For example, imagery data, the butt of many XML-bloat jokes, can be handled in BXML just as well if not better than it is handled in PNG format. A numeric array can pass from end-to-end in a client/server environment as a raw chunk of data without ever being recoded. Dense numeric data also compresses faster and more compactly when encoded in binary rather than text. BXML also has features for random access. The BXML specification is available from: Kinda ruins XML, doesn't it? http://www.opengis.org/techno/discussions/03-002r8.pdf It was originally designed in part to address GML-bulk/slowness problems. --++-- Dr. Craig S. Bruce| Tel: 819-771-8303 x205 | CubeWerx Inc. Senior Software Developer |Fax: 613-771-8388 | Gatineau, Québec, Canada [EMAIL PROTECTED] | http://www.csbruce.com | http://www.cubewerx.com/ --++-- There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- J.S. Bach ___ wms-dev mailing list [EMAIL PROTECTED] http://mail.digitalearth.org/mailman/listinfo/wms-dev ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Compiling Under Cygwin
I'm building FG under Cygwin on XP home this morning. All is well, but I did find that I needed to add a link directory (the linker couldn't find libsgmath): $ LDFLAGS=-L/usr/local/lib ./configure I installed Cygwin this morning and plib, SG, and FG are from CVS and AFAIK I did nothing different or unusual. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Beyond presets
On Fri, 2003-09-19 at 13:00, David Megginson wrote: Unfortunately, while the presets hierarchy brought some benefits, it also broke saving and restoring flights. I think that it's time to consider doing away with the presets hierarchy, and trying something like this: 1. Make an in-memory copy of the property tree that we can revert to when the user wants to reset; we could even keep a stack of reset points, if that was useful to anyone. 2. Add a few /sim/startup properties to indicate what information should be used for position, orientation, etc. For example, /sim/startup/init/position-type : (latlon|airport|navaid|runway) /sim/startup/init/altitude-type : (msl|agl|glidepath) /sim/startup/init/orientation-type : (rph|runway) /sim/startup/init/time-type : (utc|local|sunpos) This sounds awful close to /sim/presets, so it sounds to me like we may always need the functionality. That being the case, why change it? etc. I'm sure that people can think of a better classification. From this point on, then, our initialization code can simply look at these to decide whether to initialize based on the airport, etc. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Sound probs
Over the past couple of weeks, I've been having problems with the sound in FG. I get this message: slDSP: getBufferInfo: Broken pipe on the terminal and lose the sound altogether. My audio apps and tuxracer work fine, so I suspect an FG or plib issue. This is from yesterday's CVS of FG, SG, and plib. Any ideas? -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound probs
On Sun, 2003-09-14 at 09:27, Matevz Jekovec wrote: Tony Peden wrote: Over the past couple of weeks, I've been having problems with the sound in FG. I get this message: slDSP: getBufferInfo: Broken pipe on the terminal and lose the sound altogether. My audio apps and tuxracer work fine, so I suspect an FG or plib issue. This is from yesterday's CVS of FG, SG, and plib. Any ideas? I have the same problem and I'm playing without sound the last few *months* :(. I have SB Live! and ALSA. Do you use ALSA too? Yes, I'm using 0.9.6 and my sound card is a C-Media CM8738. Have you tried any other plib-based programs? - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound probs
On Sun, 2003-09-14 at 09:35, Tony Peden wrote: On Sun, 2003-09-14 at 09:27, Matevz Jekovec wrote: Tony Peden wrote: Over the past couple of weeks, I've been having problems with the sound in FG. I get this message: slDSP: getBufferInfo: Broken pipe on the terminal and lose the sound altogether. My audio apps and tuxracer work fine, so I suspect an FG or plib issue. This is from yesterday's CVS of FG, SG, and plib. Any ideas? I have the same problem and I'm playing without sound the last few *months* :(. I have SB Live! and ALSA. Do you use ALSA too? Yes, I'm using 0.9.6 and my sound card is a C-Media CM8738. Have you tried any other plib-based programs? Well, it appears to be something about the way FG is doing sound. tux_aqfh works just fine against cvs plib (you have to add -lplibjs to the makefile, though) - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound probs
On Sun, 2003-09-14 at 12:13, Frederic Bouvier wrote: Matevz Jekovec wrote: But I'm having this strange feeling why are we the very few which have this Alsa problems. What about the others, Erik, Curtis, Norman, Frederic, Jim, LeeE?? Which driver/card are you using and does sound work for you normally? coughTry windows ?/cough Windows brings it's own set of problems, does it not? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] EAA Sport Aviation - article
I'd like to have a copy, if you don't mind. Thanks, On Mon, 2003-09-08 at 08:49, Alex Perry wrote: From: Alex Perry [EMAIL PROTECTED] I've just been reading the April 2003 issue of EAA's Sport Aviation magazine and pages 50 through 58 are a nice article titled Virtual Building about Flight simulation for the homebuilder by Chuck Bodeen. It includes a discussion comparing the benefits of FlightGear, X-plane-0.66 and MSFS2002. From: Erik Hofman [EMAIL PROTECTED] A comparison between FlightGear *and* MSFS *and* X-plane. This and David's post give me the feeling we're on the right track! Erik asked: Any conclusion on FlightGear? Alex asked: [...] I am writing to request permission to scan pages 2 and 50-58 and distribute the images to the engineers that develop the FlightGear product. Editorial at EAA replied: As long as it's an internal distribution, that would be fine. Thanks for asking. I'll send a set of scanned images to Erik (off list). Any other developers who're interested, just send me a note. Our license to the images (as above) allows you to forward them to other developers but not other non FGFS people. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
--- David Megginson [EMAIL PROTECTED] wrote: Tony Peden writes: I don't know, maybe it's just me but I've written a lot of perl I couldn't read a month later ... You just haven't rewired your brain chemistry yet. After about 12 years, perl code starts to look normal and everything else (C/C++, the sky, your family) looks strange. And you are suggesting that this is a good thing? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker50/Models
On Fri, 2003-09-05 at 08:01, James Turner wrote: On Friday, September 5, 2003, at 03:12 pm, Martin Spott wrote: 3.) I know, you should not employ the flaps at 200 kts But if you do so, the aircraft climbs like attached to a high speed elevator :-) I've been flying the Fokker 100 quite a bit, and I've noticed similar instabilities. Roughly (I am not a pilot) - very rapid control response, especially on the roll axis). This sometimes extends to a 'snap' condition where I command an aileron reversal (okay, I just pull my joystick to the other side), and there is a very prolonged period with no response (for example, 8 or 10 seconds, usually continuing the previous roll command) until the roll suddenly flips over. - a similar elevator effect to that martin described, when deploying the flaps at high speeds - very odd high pitch angle behavior ... I can't really describe it, alas. It seems like way too much lift is getting developed at high angles of attack, without a corresponding increase in drag to slow the aircraft. Essentially, the aircraft flies pretty well (if a bit twitchy) providing you stick to a 'good' flight regime, but handling deteriorates exponentially when I go even moderately beyond it. I'm aware that part of this may be running 'past the end of the data' in JSBsim, but other models do not seem to have these problems. Can this be alleviated by tuning the last data point for various coefficients, which I assume is what JSBsim extrapolates from? Just for the record, JSBSim never extrapolates a table and always holds last value. In practice, this can have as bad an effect as extrapolation, but at least we're not making up data as we go along. (I was about to say the 747 is much more forgiving of my 80-degree banks, but of course, it uses YASim). Anyway, aside from the nit-picking, it's a lovely plane, at least until we get an ERJ ;-) James -- There is a very fine line between 'hobby' and 'mental illness' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
On Thu, 2003-09-04 at 15:17, Curtis L. Olson wrote: Jon S Berndt writes: Which is better: awk gawk nawk Those are for the old geezers :-) and the occasional quick command line hack (like extracting a particular set of fields from each line of an input stream.) I'd recommend learning perl or python or both as replacements. :-) I concur. Use python if you want someone else to be able to read it. Curt. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] glHorizon
On Thu, 2003-09-04 at 22:06, Jon Berndt wrote: Did I mention this link yet? http://www.web-discovery.net/ Very cool! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
On Thu, 2003-09-04 at 17:06, Curtis L. Olson wrote: Tony Peden writes: On Thu, 2003-09-04 at 15:17, Curtis L. Olson wrote: Jon S Berndt writes: Which is better: awk gawk nawk Those are for the old geezers :-) and the occasional quick command line hack (like extracting a particular set of fields from each line of an input stream.) I'd recommend learning perl or python or both as replacements. :-) I concur. Use python if you want someone else to be able to read it. And use perl if you want to be able to read it yourself. :-) I don't know, maybe it's just me but I've written a lot of perl I couldn't read a month later ... Curt. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] --ceiling option
On Tue, 2003-09-02 at 11:53, David Megginson wrote: [EMAIL PROTECTED] writes: Why don't we use SI Units in flightgear? Why unknown feets when meter is the international standard in this world? Ah, this is a long-standing thread. Personally, I'd love to use SI internally, but for the user interface, we still need to use Imperial, because that's what most of the aviation world uses. As far as I know, even countries that use SI for some things (such as runway length or altimeter setting) still use a lot of Imperial for flying, including altitude and airspeed. This is a safety issue ... it's much more important to avoid confusion in ATC commands than it is to use a system that makes more sense. Changing everyone's altimeter and airspeed indicator now (or even back when countries were switching to SI) is a herculean task bordering on impossible. One exception is temperature -- nearly everyone is using degC now for aviation weather. By the way, I live in Canada, which is also a Metric country, so I have to convert constantly between the liters I buy fuel in and the U.S. gallons in my aircraft's published performance data. Even though Canada switched to SI in the 1970's, however, we still give runway length and altitude in feet, visibility in statute miles, and distance in nautical miles. We give the altimeter setting primarily in inHg, but the METAR includes the hPa setting in comments. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] On-Ground Resets with JSBSim
On Sun, 2003-08-31 at 09:22, Tony Peden wrote:
Resets on the ground with JSBSim generally result in the c172 upside
down on the ground. This is due to the trimming routine attempting to
trim the aircraft for an in-air condition. This behavior is controlled
by the /sim/presets/onground prop. On startup, this is set to true (as
it should) and on reset it is reset to that value by the
globals::restoreInitialState(). It does, however, get set to false by
the following code in fgInitPositio():
if ( fgGetDouble(/sim/presets/altitude-ft) -9990.0 ) {
fgSetBool(/sim/presets/onground, false);
} else {
fgSetBool(/sim/presets/onground, true);
}
IIRC, that's there for LaRCSim/UIUC. Does anyone know if it's still
needed?
Well the UIUC Beech 99 can't do a proper on-ground reset with or without
it. Anyone object to removing the code above?
--
Tony Peden [EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: ..OT: blue paint bucket toss, was: [Flightgear-devel] [OT]Angry rant: the end of david@megginson.com
On Wed, 2003-08-27 at 10:04, Matthew Johnson wrote: On Wed, 2003-08-27 at 04:19, Tony Peden wrote: On Tue, 2003-08-26 at 14:08, David Megginson wrote: Matthew Johnson writes: Good point, something goes wrong on a commercial airliner very few, if anyone ever gets out alive... Not at all. Things go wrong in airliners flown by scheduled carriers all the time, and usually no one suffers anything more than stress from a delay or rerouting. Injuries and fatalities are very rare in scheduled airline incidents or accidents. Yep, several failures/circumstances generally have to stack up in order for something bad to happen. Anyone see Anatomy of a Disaster about flight 587? Not sure how technical it was, but the program seem to suggest that modern composite fibers aren't as strong as aluminum. I saw a bit of it ... they showed some testing they did in which they calculated the loads on the tail. They exceeded the design ultimate load, which means that any other material would have failed too. Material selection was, in this case, irrelevant. Matt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Angry rant: the end of david@megginson.com
when he purchased his first computer, and was very proud that he mastered the art of computing. Now, after a couple of weeks, his computer was infected by a virus, which happily started sending me emails. Now, can we hold people like him responsible for this? I don't think so. What's more, it scares these people away from using computers at all. When you're new to computers, you expect them to work, and be able to safely use whatever tools are available in whatever configuration they are. If microsoft were a responsible company (which they are not), they would have recalled all those insecure systems back to their factory and upgraded these systems to something that is safe. Okay, there's the upgrade feature, but this is not good, because it puts the responsibility for upgrading where it doesn't belong, namely the user. To draw a parallel with the aviation industry: Boeing has recalled all their older 747s back after a design flaw was discovered that had resulted in mid-air engine loss (Erik: Remember the Bijlmerramp in 1991, near Amsterdam??). It cost the company millions, but at least flying the older 747's is safe again. Somebody commented that taking away the freedom to remotely run insecure code, as a tradeoff for enhanced security is a _bad_ thing. Well, other than this _feature_ of windows being completely useless (if MS really wanted to improved task automization they'd better develop a good scripting language). To draw another parrallel with the avaition industy, I would _very much_, like to have the freedom to board planes, or visit the cockpit during flight, without being treated as a terrorist suspect, and one could argue that just because of a few individuals who don't know their responsibilities and bring bombs aboard, we shouldn't have all these security people around? Mind you, a recent slashdot article showed that the sobig virus _is_ probably a lot scarier than most people think, and amongst others, installs open relay smtp servers (for spamming purposes) and password stealers on the infected machines. Now, shouldn't this be stopped at _all_ costs??? Mind you folks: MS is chaired by a guy who once said 640k ought be enough for everybody :-) Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: ..OT: blue paint bucket toss, was: [Flightgear-devel] [OT]Angry rant: the end of david@megginson.com
On Tue, 2003-08-26 at 14:08, David Megginson wrote: Matthew Johnson writes: Good point, something goes wrong on a commercial airliner very few, if anyone ever gets out alive... Not at all. Things go wrong in airliners flown by scheduled carriers all the time, and usually no one suffers anything more than stress from a delay or rerouting. Injuries and fatalities are very rare in scheduled airline incidents or accidents. Yep, several failures/circumstances generally have to stack up in order for something bad to happen. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: Aircraft Carriers
On Thu, 2003-08-21 at 22:22, Russell Suter wrote: Tony Peden wrote: On Thu, 2003-08-21 at 19:12, Russell Suter wrote: Tony Peden wrote: On Thu, 2003-08-21 at 09:54, Christopher S Horler wrote: Can anyone tell me the largest a/c that can operate from an a/c carrier? The E-2C (or the cargo version of the same plane) is probably the biggest that currently operates from U.S. carriers. I guess that depends on what the unit of measure is. It certainly isn't the heaviest... It's close. It also appears to be the longest and have the most span. It might be heaviest in empty weight. I believe it comes in at around 40,000 lbs. empty. Off the top of my pointed head, I think the EA-6B Prowler comes in at around 34,000 lbs. empty. I'd have to check the NATOPS manual for that. I don't about the S-3B Viking. As for max take-off weight, the Super Hornet FA/18 E/F come in at a whopping 66,000 lbs. Hmm ... never would of thunk it ... whereas the Hawkeye maxes out at around 53,000 lbs. The Prowler is somewhere around 61,000 lbs... -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: Aircraft Carriers
On Thu, 2003-08-21 at 09:54, Christopher S Horler wrote: Can anyone tell me the largest a/c that can operate from an a/c carrier? The E-2C (or the cargo version of the same plane) is probably the biggest that currently operates from U.S. carriers. Thanks, Chris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: Aircraft Carriers
On Thu, 2003-08-21 at 19:12, Russell Suter wrote: Tony Peden wrote: On Thu, 2003-08-21 at 09:54, Christopher S Horler wrote: Can anyone tell me the largest a/c that can operate from an a/c carrier? The E-2C (or the cargo version of the same plane) is probably the biggest that currently operates from U.S. carriers. I guess that depends on what the unit of measure is. It certainly isn't the heaviest... It's close. It also appears to be the longest and have the most span. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 flightmodel
On Wed, 2003-08-20 at 14:47, Manuel Bessler wrote: Hi all, I'm working on a Boeing 717-200 flightmodel (jsbsim) and the 3D visual model in blender. (I've uploaded it here for now: http://cockpit.varxec.de/fgfs/B717_model_1.tar.bz2 [180k]) This is my first attempt at a flight model. I've learned some stuff about aerodynamics in the process, but am still barely scratching the surface. Since the 717(aka MD-95) is still pretty new, there's not much information about it on the net. I've used some numbers from the tables at www.bh.com I got started with David Culp's Aero-Matic scripts but heavily modified the fdm config file afterwards. My biggest problem with the flightmodel is that elevator seems _very_ sensitive. (ie. when flying with the keyboard, pressing up/down _once_ will let the plane pitch about 10+ degrees up/down) I compared my values in the FLIGHT_CONTROL section of the config with some others, like the F100, and they are the same although the F100 doesn't seem to suffer from the same problems. I've also used MoI values similar to those of the F100. Any suggestions for the fdm/aero beginner ? The problem is probably not in the flight controls, but in the aero. Try either reducing pitching moment due to elevator or increasing pitching moment due to alpha. I can be more specific if you e-mail me your config file. One note of caution: the keyboard increments are necessarily kind of big anyway. Another problem (I think) is the lack of lift. I have only found something for the DC-9 (which is granddaddy of the 717): Clmax=2.0 Aero Matic guessed around 1.4 for my input. 1.4 is probably a skosh high for flaps up. For full landing flaps, it's going to be considerably higher. Do you have any stall speeds? Now, I don't know how to correct that into the values in the fdm config. 3D Modelling: I've messed with blender a few times over a couple of years now. But I'm not a big artist and I am not very good with coming up with smart ways of how to model a certain thing. I was just wondering if there's a blender tutorial for modelling planes, esp. for flightgear. I googled for it but didn't find anything. The fuselage front and rear were the biggest problems for me. I ended up using nurbs circles along the length of the plane and then converting the nurbs circles into meshes. Then I manually created the faces (ie. marking 4 vertices, FKEY, until done) which was tedious work :) Is there a better way of doing this ? I've got the basic model finished, now I need to add(or seperate) the moving surfaces out of the wing and tail. Maybe cutting out using boolean ops. Is that how you do this ? It'd be nice if we had a tutorial (like those of the blender community) of how to make a visual model for flightgear using blender. Any help is appreciated. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] california was Some Europeancities satelite photos
It looks like you need to be a citizen, 35 or older, and a resident of at least 14 years. Arnold probably quailifies. On Sun, 2003-08-17 at 12:07, Russell Suter wrote: Actually, that would be a change to our Constitution - Article II, Section I. Arnt Karlsen wrote: On Sun, 17 Aug 2003 13:04:28 -, Jim Wilson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Lee Elliott [EMAIL PROTECTED] said: better politicians - surely, this is an oxymoron? Lol...yes indeed. It depends on your point of view. In this case they are better in my view because they are in California and _not_ Maine. Although I suppose there's a remote (hopefully) possibility that Arnold would run for president :-/ someday. Just to get under Teddy's skin. ..relax, he's Austrian by birth. Until you change your laws, you cannot elect him (nor me ;-) ) president of the US. ;-) -- Russ Conway's Law: The structure of a system tends to mirror the structure of the group producing it. -- Mel Conway Datamation (1968) __ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some European cities satelite photos
On Sun, 2003-08-17 at 13:46, David Megginson wrote: Curtis L. Olson writes: Yeah, we still have a lot of My governor can beat up your governor bumper stickers and t-shirts ... it would be a shame for them to go to waste. We obviously can't use them in MN any more. Remember that, unlike that actor from the monkey movies who once became California governor, the actor from the action movies cannot go on to become president without a constitutional ammendment. Is Arnold not a citizen? No person except a natural born citizen, or a citizen of the United States, at the time of the adoption of this Constitution, shall be eligible to the office of President; neither shall any person be eligible to that office who shall not have attained to the age of thirty five years, and been fourteen Years a resident within the United States. All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Born in the U.S.A.
On Sun, 2003-08-17 at 15:20, David Megginson wrote: Tony Peden writes: Is Arnold not a citizen? No person except a natural born citizen, He is not a natural-born citizen. or a citizen of the United States, at the time of the adoption of this Constitution, He was not a citizen at the time of the adoption of the constitution. shall be eligible to the office of President; neither shall any person be eligible to that office who shall not have attained to the age of thirty five years, and been fourteen Years a resident within the United States. These are additional criteria, not substitute ones. There was a small controversy when a charity dedicated to getting a woman elected as president gave money to Jennifer Granholm's gubernatorial campaign in Michigan: she can never go on to become U.S. president without a constitutional ammendement, since she was born in Canada. As far as I understand, a vice-president who was not born in the U.S. would have to be passed over in the line of succession if the president were incapacitated, since the statement refers to holding the office rather than just being elected to it. So if Arnie were V.P. and the president were incapacitated, the presidency would go to the Speaker of the House. Hmmph .. well that pretty much flies in the face of the melting pot, now doesn't it? All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
On Thu, 2003-07-24 at 04:17, Frederic Bouvier wrote: David Culp wrote: ... Would it be possible to make the increment aircraft dependant, instead of global ( I need here of a 0.25 increment ) ? I add this to the -set file for the 737: [snip] Thank you David. That do it. Could you explain the syntax of the part in the jsbsim config file : COMPONENT NAME=Flaps Control TYPE=KINEMAT INPUTfcs/flap-cmd-norm DETENTS 9 00 14 24 53 10 3 15 3 25 3 30 2 40 2 OUTPUT fcs/flap-pos-deg /COMPONENT What is the second column ? I guess the first is the flap defection. It's the time required to transition between detents. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
--- David Culp [EMAIL PROTECTED] wrote: COMPONENT NAME=Flaps Control TYPE=KINEMAT INPUTfcs/flap-cmd-norm DETENTS 9 00 14 24 53 10 3 15 3 25 3 30 2 40 2 OUTPUT fcs/flap-pos-deg /COMPONENT Tony, since the input is flap-cmd-norm, should I have the left column go from 0.0 to 1.0? Up to you. Or is the left column the output as well? Yes, it does. If you want to define all your aero coeffs to vary with flaps from 0 to 1, you can do that. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flap position
On Thu, 2003-07-24 at 05:19, Frederic Bouvier wrote: Tony Peden wrote: On Thu, 2003-07-24 at 04:17, Frederic Bouvier wrote: Could you explain the syntax of the part in the jsbsim config file : COMPONENT NAME=Flaps Control TYPE=KINEMAT INPUTfcs/flap-cmd-norm DETENTS 9 00 14 24 53 10 3 15 3 25 3 30 2 40 2 OUTPUT fcs/flap-pos-deg /COMPONENT What is the second column ? I guess the first is the flap defection. It's the time required to transition between detents. So, is it normal to see the same value for different detents ? It's entirely dependent upon the aircraft's flap system. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
On Thu, 2003-07-24 at 10:14, Michael Selig wrote: At 7/24/03, Oliver C. wrote: Am Donnerstag, 24. Juli 2003 10:19 schrieb Jon Stockill: Heads down guys - we just got another mention on slashdot :-) http://games.slashdot.org/article.pl?sid=03/07/23/1837201 In the article i read the following: In fact, flight characteristics are calculated in real time from aircraft design data, not static tables like MS Flight Simulator. This statement in the context of the full article suggests that static tables (table lookup data) are the determining factor insofar as realism goes. I wish things were that black and white. The Devil is in the Details. Yes, indeed. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Incoming!!!!!!!!!!!!
On Thu, 2003-07-24 at 18:31, David Megginson wrote: Lee Elliott writes: So the b-52, with anhedral, should fly better upside down? So it would seem. I'd hate to see an engine flame out, though, and the flight crew end up having to make an approach and landing with only seven engines. Landing in a twin with one engine out is not terribly challenging, so I'd expect that on 7/8 it's not a big deal at all. All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] forwarded message from Andrei Barbu
On Thu, 2003-07-24 at 19:09, Curtis L. Olson wrote: Hi, Andrei has kindly offered to do a bit of web page redesign for the FlightGear project. The included message has a link to his proposed changes for the front page. What do people think? The sample is up at geocities so ignore the advertising; that of course is not part of the redesign. :-) Nice work. I vote to accept. __ From: Andrei Barbu [EMAIL PROTECTED] To: Curtis L. Olson [EMAIL PROTECTED] Subject: Website updated Date: 24 Jul 2003 19:03:12 -0700 Hey, I upgraded the website so I've you've seen it until now look at it again. I upgraded the menu system and made headings, should make everything look much nicer and leaner. I also explained what's going on with the site, and added a copyright at the bottom. http://www.geocities.com/a_barbu2/index.htm Andrei __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com __ Regards, Curt. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] weird reset
On Sat, 2003-07-19 at 14:04, Curtis L. Olson wrote: [EMAIL PROTECTED] writes: Am Samstag, 19. Juli 2003 22:21 schrieb Christopher S Horler: This sometimes happens when I reset - I can't reproduce it everytime, I'm looking into things that may make it happen - it seems almost like some values are being initialized incorrectly i.e. the plane starts the right way up then goes through a 180 degree half loop. http://www.zen11419.zen.co.uk/snapshot10.png I agree. I have the same problem. This is something that I've noticed recently too. It appears to only be a problem with JSBSim aircraft, and at least for me happens on 100% of the resets or on-the-ground repositions. Something in the JSBSim ground trim code seems to have changed I did make some changes, but they don't appear to be the problem. It's wanting to do an in-air trim following the reset even though it's on the ground. Regards, Curt. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] weird reset
On Sat, 2003-07-19 at 14:12, Tony Peden wrote: On Sat, 2003-07-19 at 14:04, Curtis L. Olson wrote: [EMAIL PROTECTED] writes: Am Samstag, 19. Juli 2003 22:21 schrieb Christopher S Horler: This sometimes happens when I reset - I can't reproduce it everytime, I'm looking into things that may make it happen - it seems almost like some values are being initialized incorrectly i.e. the plane starts the right way up then goes through a 180 degree half loop. http://www.zen11419.zen.co.uk/snapshot10.png I agree. I have the same problem. This is something that I've noticed recently too. It appears to only be a problem with JSBSim aircraft, and at least for me happens on 100% of the resets or on-the-ground repositions. Something in the JSBSim ground trim code seems to have changed I did make some changes, but they don't appear to be the problem. It's wanting to do an in-air trim following the reset even though it's on the ground. /sim/presets/onground is false. I'm not sure why. Regards, Curt. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] offset-distance broken?
--- David Megginson [EMAIL PROTECTED] wrote: Wendell Turner writes: I use fgfs to practice instrument approaches, starting with the aircraft positioned just outside the IAF. However, in 0.9.2, the --offset-distance doesn't seem to work. Curt has offset-distance set up right now to work only when you're lined up on an airport runway. The presets stuff needs a lot of work. I remember putting in an offset-azimuth at the time that I did the offset-distance. Does that not work anymore? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] offset-distance broken?
On Wed, 2003-07-02 at 12:28, Matt Fienberg wrote: Would there be a way to specify inbound 8 miles northwest of [ICAO] much like the way winds are specified? Much like [EMAIL PROTECTED] for northwest winds at 8 knots, how about [EMAIL PROTECTED] along with maybe --inbound-target=KSJC or the approach fix or VOR designation? I'm still working on VFR, forgive me if my fix terminology isn't correct... ;) I often want to start up FG such that I'm 8 miles northwest of KORH, inbound implying a 135 heading. When I first wrote that --offset code, you could do this, though not with that notation. --offset-distance=8 and --offset-azimuth=315 would, I believe, get you what you want. Thanks, Matt Tony Peden wrote: --- David Megginson [EMAIL PROTECTED] wrote: Wendell Turner writes: I use fgfs to practice instrument approaches, starting with the aircraft positioned just outside the IAF. However, in 0.9.2, the --offset-distance doesn't seem to work. Curt has offset-distance set up right now to work only when you're lined up on an airport runway. The presets stuff needs a lot of work. I remember putting in an offset-azimuth at the time that I did the offset-distance. Does that not work anymore? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] offset-distance broken?
On Wed, 2003-07-02 at 18:37, Wendell Turner wrote: Tony Penden writes: On Wed, 2003-07-02 at 10:28, Tony Peden wrote: --- David Megginson [EMAIL PROTECTED] wrote: Wendell Turner writes: I use fgfs to practice instrument approaches, starting with the aircraft positioned just outside the IAF. However, in 0.9.2, the --offset-distance doesn't seem to work. Curt has offset-distance set up right now to work only when you're lined up on an airport runway. The presets stuff needs a lot of work. I remember putting in an offset-azimuth at the time that I did the offset-distance. Does that not work anymore? This does work from the command line. You need to specify the heading to the runway as the offset-azimuth value. The only heading that works is if --runway=x is specified, in which case the heading is towards the airport. It doesn't seem possible now (it was in earlier versions) to specify any other headings (outbound for procedure turn, along dme arc, etc.) --offset-azimuth works. It doesn't affect the aircraft heading, however, only its position. Try: fgfs --offset-distance=3 --offset-azimuth=300 --vc=100 --altitude=1500 And you should find that you end up south of KSFO and that the heading to the threshold is 300. Wendell ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [PATCH]Autopilot/newauto.cxx:resetelevator_trim on alt unlock
On Sun, 2003-06-08 at 08:34, Norman Vine wrote: David Megginson writes: Norman Vine writes: What the correct behaviour is I don't know and I would not be surprised if different APs did it differently but my guess is that just changing our AP elevator control to use the main control and not the 'trim' control would make a 'better' system It will depend on what plane you're modelling, but again, I'm fairly certain that we have things right for most small plane (and many large plane?) autopilots. I agree we probably have it right for most 'light planes' but I suspect that heavier planes and military aircraft have a much more sophisticated system We really could use some input here from those who have flown with more sophisticated aircraft control systems then what you find on the typical LWP ! As for myself I would be very nervous using any altitude control system that didn't return elevator trim to 'neutral'(1) on disengagment because as you say it is a potential killer Whose to say that neutral trim is better? And aside from that, there really is no such thing as neutral trim for aircraft that trim with the entire stabilizer. Also there is one real practical problem with resetting the trim: trim systems tend to be fairly low rate devices, so returning them to some safe position could actually take some time, say 10-20 seconds. (1) the neutral state being the 'preset' elevator position normally used for level flight Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel][PATCH]Autopilot/newauto.cxx:resetelevator_trim on alt unlock
On Sun, 2003-06-08 at 09:26, Norman Vine wrote: Tony Peden writes: Also there is one real practical problem with resetting the trim: trim systems tend to be fairly low rate devices, so returning them to some safe position could actually take some time, say 10-20 seconds. That these are typically 'low rate' systems is a good point, but then again I am guessing that the main vs. the trim controls don't have a much faster rate but I really don't know :-) The elevator rate is typically either pilot limited (how fast can he pull) or, for fully powered systems, are capable of high enough rates that in many cases the pilot again becomes the limiting factor. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE:alt unlock
On Sun, 2003-06-08 at 11:36, Norman Vine wrote: Jon Berndt writes: As for myself I would be very nervous using any altitude control system that didn't return elevator trim to 'neutral'(1) on disengagment because as you say it is a potential killer Tony wrote: Whose to say that neutral trim is better? And aside from that, there really is no such thing as neutral trim for aircraft that trim with the entire stabilizer. Also there is one real practical problem with resetting the trim: trim systems tend to be fairly low rate devices, so returning them to some safe position could actually take some time, say 10-20 seconds. Tony is exactly right. In the F-16, to the best of my recollection, the autopilot and trim commands are summed. This means that when the autopilot is on, if there has been some trim already put in, the autopilot adds to that setting. If the trim is activated during autopiloted flight, the autopilot will correct for that in holding altitude (for instance), so the net effect is zero. If the autopilot is turned off, the trim is NOT returned to any neutral setting - it remains the same. However, there are sumps (washouts) in the FCS to temper any transients that might be seen. I don't doubt that you guys are right, I just am trying to make sure that we are talking about the same 'oranges' In the FGFS AP model we have an elevator control (EC) and an elevator_trim (ETC) control. The elevator_trim control is what is adjusted by the AP in FGFS but I am guessing that there is either (1) a coupling between the ETC and EC or (2) that the AP on heavy planes controls the directly EC and not the ETC. Depends on the aircraft. If you can get the rate from the trim, why not use it? But as I have said I could easily be all 'wet' Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel][PATCH]Autopilot/newauto.cxx:resetelevator_trim on alt unlock
On Sun, 2003-06-08 at 11:36, Norman Vine wrote: David Megginson writes: The only problem comes when the AP is trying to handle turbulence -- it might be trimmed all the way up or down handling a temporary spike when it disengages. Apparently newer AP's are better at detecting and handling that as a special case, but the old ones made for some pretty interesting moments, so a lot of pilots insist(ed) on hand-flying through rough air. Try flying with the HUD not the Panel and engage the AP when at cruising altitude then use the arrow keys to increase the desired altitude under AP control by 1000 ft or so and note the elevator_trim and elevator control positions on the HUD This should highlite the what the initial 'complaint' was about It doesn't really matter ... you are still going to run into the same problems when the autopilot disconnects. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel][PATCH]Autopilot/newauto.cxx:resetelevator_trim on alt unlock
On Sun, 2003-06-08 at 16:50, David Megginson wrote: Norman Vine writes: Try flying with the HUD not the Panel and engage the AP when at cruising altitude then use the arrow keys to increase the desired altitude under AP control by 1000 ft or so and note the elevator_trim and elevator control positions on the HUD This should highlite the what the initial 'complaint' was about It's not all that obvious to me, except that (as far as I can tell) the AP moves the trim. In real life, changing the trim actually causes the elevator or stabilator to move -- our summing up of the two is simply a kludge. The implementation of the c172 in JSBSim is such that the elevator *does* move. It just doesn't feedback into the elevator command that's displayed on the panel. All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RE: alt unlock
On Sun, 2003-06-08 at 18:32, Norman Vine wrote: Tony Peden writes: On Sun, 2003-06-08 at 17:43, Norman Vine wrote: Tony Peden writes: The implementation of the c172 in JSBSim is such that the elevator *does* move. It just doesn't feedback into the elevator command that's displayed on the panel. Exactly ! OK - This is what I am trying to feret out How should this feedback be modeled ?? Or asked another way given the lack of feedback should the AP be operating on the Elevator Control directly rather then the elevator trim And the trim left as a mechanism that allows setting the offset from the 'neutral' position of the Elevator with respect to the standard positioning In the case of JSBSim, just look at elevator-pos rather than what's fed into elevator-cmd. Sounds simple and AFAIK we are already reading the elevator-pos from all of the FDMs for instrument positioning but ... I think FG reads the elevator command before it even goes to the FDM. It is *definitely* not reading the actual surface position from JSBSim. The problem is that it is the elevator_trim that is being adjusted by the autopilot ... There may be some details to work out, but once that's done the trim indicator should show the neutral (or hands-off) position of the elevator. So my guess is that my 'turnbuckle' analogy below is what is wanted but this is a rather major, albeit relatively simple to implement, change in the logic and am trying to make sure that this is what is wanted. My suggestion will, I believe, give the desired result. Also, this would be model specific so that the indicators would once again be independent if the trim doesn't drive the elevator. :-)) i.e. if this were a mechanical linkage the 'trim' would be a turnbuckle that could adjust the lenght of a piece of the linkage. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in a cave ?
On Sun, 2003-06-01 at 13:51, David Megginson wrote: Jim Wilson writes: I don't speak Netherlandic How about dutch? ;-) I'm pretty sure that the language is called Neanderthal, actually. Trouble. ;-) All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help request
On Fri, 2003-05-30 at 07:25, David Megginson wrote: Jim Wilson writes: Luca Masera [EMAIL PROTECTED] said: The 2nd step doesn't work. After 1157 feet the altimeter shows 1000 and the things go worst after 5000 feets. The problem is in the rotations, I tink, but I haven't an interpolation of the formula that calculate the pressure. The altimeter does *not* indicate your altitude: it indicates calibrated barometric pressure. A lot of the time, the difference does not matter, as long as all aircraft are seeing the same error: for example, I was cruising at 6500 ft on Wednesday, using the proper altimeter setting, and showing up on Toronto Centre's radar at 6500 Hmm, do you have a mode C transponder? If that's the case, you and ATC should always agree since ATC is getting the altitude from your aircraft. (also adjusted for the altimeter setting), but my GPS consistently showed me just over 6150 feet for two hours. There are special rules for flying in cold temperatures over the mountains, especially in Canada -- we have to leave a very big safety factor. All the best, Daivd -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rearranged /controls/ properties
On Tue, 2003-04-01 at 08:21, Erik Hofman wrote:
David Megginson wrote:
Now that we're rearranging the /controls/ subtree, it might be a good
time to clean up the naming.
I am all for (property naming) consistency and I am for selecting the
tree layout now, and stick with it from now on.
There are a few property names I wouldn't have chosen, but I think it
would be of the greatest importance to pick one, and get over it ;-)
1. Consistency
--
Most of the property names use lower case and hyphens ('-') as word
separators. I suggest that we fix the following to be consistent:
/controls/flight/BLC
/controls/engines/engine[%d]/WEP
/controls/fuel/tank[%d]/fuel_selector
/controls/fuel/tank[%d]/to_engine
/controls/fuel/tank[%d]/to_tank
/controls/electric/APU-generator
/controls/pneumatic/APU-bleed
Sound good to me.
2. Units
In flightgear, we use suffixes for most property names to indicate the
units (such as /position/altitude-ft or /environment/wind-speed-kt).
Many of the control properties, however, are either normalized values
(0:1 or -1:1) or boolean flags.
Would it make sense to add suffixes to these as well?
/controls/flight/aileron-norm
/controls/gear/gear-down-flag
(or something similar)?
Maybe we shouldn't even make a distinction between flags and normalized
values and call every boolean -*-norm also.
I'd prefer the -norm be left to values that continuously vary rather
than discretes.
3. Switches
---
Note that Curt's electrical system has a /controls/switches subtree,
while the recent rewrite has a /controls/lighting subtree. We need to
choose one or the other.
Stick with switches, I expect more switches will be available that are
non lighting related.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Tony Peden [EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] The End of Python
On Tue, 2003-04-01 at 07:29, Curtis L. Olson wrote: David Megginson writes: It looks like Python's days are numbered; I just read on Slashdot about a programming language that uses *only* whitespace: http://compsoc.dur.ac.uk/whitespace/ I expect that most current Python programmers will have switched over by the end of the year. Any die-hard fanatics left over will no doubt write a Punctuation programming language, using only the characters [EMAIL PROTECTED]*() (above 0-9 on the U.S. keyboard), as a pure act of spite to try to split the Perl community. One real advantage of this langauge is that it's source files compress really well. This can save a lot of disk space, especially with a project the size of Flight/Sim/TerraGear. As soon as the wsfront utility is finished, we could seriously consider porting the entire project over. Compile times can really benefit too. WS doesn't use tokens as part of it's syntax, and a large portion of a typical compiler is devoted to parsing tokens, hashing them, and ultimately just translating them into a number anyway. WS skips this entire level of indirection which can be a huge performance boost and can drastically reduce the compiler's memory foot print. This also enables the programmer to write much more direct and straightforward code. The only issue I can see up front is on windows ... typically windows will misinterpret certain combinations of white space characters. This could be one slightly sticky problem, at least until MS fixes this bug. Speaking of which, WS sneakily avoids another major bug in windows. Because it doesn't directly use characters, it avoids windows problems with lack of case sensitivety, and isn't affected by it's tendency to change certain capitalizations. Best of all WS is intuitive and not encumbered by huge unwieldy standards bodies who drag their heels on every good idea or who try to lock you into proprietary solutions. Some groups are complaining that the name of this language isn't culturally neutral. They are suggesting perhaps BackSpace would be a better name since this is often the most frequently used character in the WhiteSpace language. We'll have to keep on eye on the development of this language. If nothing else we could use it as our default embedded scripting language. If this isn't incentive enough to keep FG cvs working I don't know what is. It's clear you've had entirely too much time on your hands today. ;-) Regards, Curt. -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] squared tag in joystick files
On Sun, 2003-03-30 at 20:05, Michael Selig wrote: At 3/30/03, you wrote: Michael Selig writes: I noticed the 'squared' effect when I started flying w/ my R/C joysticks. Using the actual joysticks exactly models what an R/C pilot feels, so no exponent fudging is desired in that case. Also, exponential rates and mixing if used are done onboard the R/C transmitter, so again nothing needs to be done on the fgfs side. Great. Under our current system, the 'power' property is not applied by default -- it has to be specified separately for each axis in each joystick-specific config file, so there should be no problem leaving it out for your R/C joysticks. That's what I've done. That R/C joystick file is committed. In special cases (e.g. some airplanes in the current fgfs hanger), suppose one wanted to change a property that is set in the specific base package joystick file (or any other xml file). Can the related tags be added to the -set.xml file with the effect of over-riding the previous values? There have been instances where I have wanted to do this, but I don't think it worked. It's doable, but complicated. Let me know what you're thinking of. Things that I would like to over-ride and post to the fgfs cvs for flying the uiuc airplanes (and new ones coming): [1] I'd like to add keyboard customization that would work w/ the ASW-20. Spoilers working w/ j/k keys: key n=106 namej/name descDecrease spoilers./desc binding commandproperty-adjust/command property/controls/spoilers/property min0/min step type=double-0.25/step /binding /key key n=107 namek/name descIncrease spoilers./desc binding commandproperty-adjust/command property/controls/spoilers/property max1/max step type=double0.25/step /binding /key [2] In preferences.xml, I have changed 'eye-heading-deg-path' per below. The LaRCsim/UIUC code computes this value. The advantage is that in the second view, the view direction is in the direction of the airplane (Gamma horizontal in effect). The result is that when rudder is applied, the airplane will yaw, but the view direction will not. It is a much more natural way to see the airplane and tendency for vertigo is greatly reduced when things are unsteady. With the ASW-20 landing w/ sideslip (cross-controls), the 2nd view is down the runway w/ the airplane in a big sideslip. !-- view 2 -- view nameChase View/name typelookat/type config from-model type=boolfalse/from-model from-model-idx type=int0/from-model-idx eye-lat-deg-path/position/latitude-deg/eye-lat-deg-path eye-lon-deg-path/position/longitude-deg/eye-lon-deg-path eye-alt-ft-path/position/altitude-ft/eye-alt-ft-path eye-heading-deg-path/orientation/Gamma_horiz_deg/eye-heading-deg-path Frankly, I think this should be applied w/ all FDMs, but JSBSim and YASim will need to compute Gamma_horiz_deg first. Flight path angle is computed by JSBSim. It's probably not passed to FG, however. [3] The final one is obviously the joysticks.xml file. When I do fly w/ my regular MS joysticks, I'd like to be working one-to-one. I'm working on some fighter planes now and I'd like to remove the squared effect for those -set.xml files. So effectively, I am thinking of customizations of all three: joysticks.xml, preferences.xml, and keyboard.xml. To me it would seem logical for these extensions/over-rides to reside in add-on files that are called from the *-set.xml file. Any light you can shed on this would be appreciated. Regards, Michael All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] squared tag in joystick files
On Sun, 2003-03-30 at 21:16, Michael Selig wrote: At 3/30/03, you wrote: On Sun, 2003-03-30 at 20:05, Michael Selig wrote: At 3/30/03, you wrote: Michael Selig writes: I noticed the 'squared' effect when I started flying w/ my R/C joysticks. Using the actual joysticks exactly models what an R/C pilot feels, so no exponent fudging is desired in that case. Also, exponential rates and mixing if used are done onboard the R/C transmitter, so again nothing needs to be done on the fgfs side. Great. Under our current system, the 'power' property is not applied by default -- it has to be specified separately for each axis in each joystick-specific config file, so there should be no problem leaving it out for your R/C joysticks. That's what I've done. That R/C joystick file is committed. In special cases (e.g. some airplanes in the current fgfs hanger), suppose one wanted to change a property that is set in the specific base package joystick file (or any other xml file). Can the related tags be added to the -set.xml file with the effect of over-riding the previous values? There have been instances where I have wanted to do this, but I don't think it worked. It's doable, but complicated. Let me know what you're thinking of. Things that I would like to over-ride and post to the fgfs cvs for flying the uiuc airplanes (and new ones coming): [1] I'd like to add keyboard customization that would work w/ the ASW-20. Spoilers working w/ j/k keys: key n=106 namej/name descDecrease spoilers./desc binding commandproperty-adjust/command property/controls/spoilers/property min0/min step type=double-0.25/step /binding /key key n=107 namek/name descIncrease spoilers./desc binding commandproperty-adjust/command property/controls/spoilers/property max1/max step type=double0.25/step /binding /key [2] In preferences.xml, I have changed 'eye-heading-deg-path' per below. The LaRCsim/UIUC code computes this value. The advantage is that in the second view, the view direction is in the direction of the airplane (Gamma horizontal in effect). The result is that when rudder is applied, the airplane will yaw, but the view direction will not. It is a much more natural way to see the airplane and tendency for vertigo is greatly reduced when things are unsteady. With the ASW-20 landing w/ sideslip (cross-controls), the 2nd view is down the runway w/ the airplane in a big sideslip. !-- view 2 -- view nameChase View/name typelookat/type config from-model type=boolfalse/from-model from-model-idx type=int0/from-model-idx eye-lat-deg-path/position/latitude-deg/eye-lat-deg-path eye-lon-deg-path/position/longitude-deg/eye-lon-deg-path eye-alt-ft-path/position/altitude-ft/eye-alt-ft-path eye-heading-deg-path/orientation/Gamma_horiz_deg/eye-heading-deg-path Frankly, I think this should be applied w/ all FDMs, but JSBSim and YASim will need to compute Gamma_horiz_deg first. Flight path angle is computed by JSBSim. It's probably not passed to FG, however. I am referring to the flight path angle in the horizontal plane, not the flight path angle proper (in the vertical plane). I'm not sure if that was clear. Does JSBSim compute the flight path angle in the horizontal plane? That would be drift angle, wouldn't it? I think we compute ground track heading and drift = heading - ground track. The file preferences.xml currently has: eye-heading-deg-path/orientation/heading-deg/eye-heading-deg-path. This causes the view to sway back and forth w/ yaw. Regards, Michael ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
--- Major A [EMAIL PROTECTED] wrote: A pilot familiar with that plane is almost certainly going to find it very unstable in the pitch axis, and complain that the nose bounces up and down too much. In the real plane, the dynamic pressure from the relative wind tends to hold the control surfaces in one spot, and it takes a bit of effort to move them from where they want to be (a *lot* of effort for a big deflection). A home-computer joystick or yoke might have a little spring in it, but in general, it's going to be far too easy for the computer user to create an elevator deflection, and the plane's going to feel unstable. Just an idea -- if someone were to build proper force-feedback yoke/pedals/etc., would FlightGear be able to drive them realistically? I.e., is force on the controls part of the FDM? The flight control system in JSBSim will allow for it as it stands, but work would have to be done to get that info to FG. Also, none of our models currently calculate the forces. Fly! allowed one to change the exponential effect. Possibly it is misnamed, x^n involves an exponent, perhaps it was 'n' that could be varied. MSFS2K appears to have changed to some intrinsic non-linear mapping compared to FS98. I don't know about Fly!, but exponential traditionally is a misnomer. A lot of RC transmitters allow you to set it, but that usually means that the response is proportional until you reach a certain deflection, then makes a kink and the control starts reacting with more authority, but still linearly. No such thing as an exponential function, which is probably because exponentiation is rather difficult to implement in analogue electronics. Fly!, and MS FS/CFS allow one to change 'null zone' and 'sensitivity' for the JS in the menu. Lower sensitivity adds more low Is the null zone there in a real aircraft (backlash), or just a feature of the sim to allow the pilot to go and grab a cup of coffee? -1.0 = -1.00 -0.5 = -0.25 0.0 = 0.00 0.5 = 0.25 1.0 = 1.00 This is a good response, but it also implies that at 0 deflection, the control is totally nonresponsive (gradient is zero). Shouldn't we simply add a linear term here? That would make the control linear around the centre and transition into a square response at higher deflections. Umm, I think that he's trying to reduce the response around the center. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Jsbsim-devel] MSFS Aircrafts
On Wed, 2003-03-26 at 15:16, David Megginson wrote: Erik Hofman writes: I wouldn't have a problem with that either if they respect the GPL, which in most cases they don't. Further more it take a considerable amount of time gathering all the data, and just taking the data for your own good is, so to say, not nice. Is our data GPL'd, or just the specific representation of it in the config files? I know that Microsoft (for example) has not been able to enforce IP rights over their file formats. Besides, if our data were GPL'd, we'd have to prove that we had the right to do that in the first place. Probably true, but credit (if it's due) is not terribly much to ask for. All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
On Thu, 2003-03-20 at 04:23, Gerhard Wesp wrote: http://flightgear.org/Projects/RayChair/raychair.html http://flightgear.org/Projects/ Oops. Should have looked more closely on your homepage. Thanks! We are a bit behind on this part. There is a project called OpenGC that has been working with FlightGear, but I don't know the current status. But your reply sounds as if there's interest. :-) Does jsbsim also take yaw angle into account Yes. (fuselage drag)? It's up to the modeler. The default c172 models drag due to sideslip. I.e., is it possible to perform a slip (haven't had a real chance to try yet due to lack of pedals). Yes. Use KP enter and zero for the rudder. You'll see the nose slice and find that you have to put in aileron to maintain heading. For yasim I take it it is possible. -Gerhard -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Architectural questions
On Thu, 2003-03-20 at 03:22, David Megginson wrote: Erik Hofman writes: We have three FDM's of which two of them use windtunnel/flight-test data and one is based on physical dimensions of the aircraft. The latter is a bit less accurate but is easier to design a working aircraft for. To be fair, YASim is not necessarily less accurate, though it does use a solver to fill in many of the blanks. It depends entirely on how you want to define accurate. The coefficient approach used in JSBSim and LaRCsim/UIUC makes it possible to duplicate the unique characteristics of a particular aircraft throughout the normal flight envelope. It is, however, more difficult to get reasonably good behavior in spins, stalls, and turbulence. The YASim approach makes it easier get the latter behaviors about right. In terms of unique characteristics, however, you can only match them at a couple of places in the flight envelope. Everywhere else, you take what you get. In fact, YASim is currently the only FDM that performs calculations for each lifting surface separately -- YASim figures out the angle of attack, lift, and drag for each surface then calculates moments from the differential lift and drag, while JSBSim uses a single angle of attack for the entire aircraft and simulates the differences in lift and drag using a long series of moment coefficients. Both are fine in regular flight, but YASim's approach is likely to work better for stalls, spins, and other aerobatic maneuvers outside of the regular flight envelope. Note that it's far from perfect so far, but at least the potential is there (likewise, it would be much easier to simulate something like a tailplane stall from icing in YASim). JSBSim could do the same thing by providing an option to specify separate coefficients and relative orientations for each lifting surface. Then, if the right wing were producing more lift than the left, you would have a left roll; if the right wing were also producing more drag, you would have a right yaw; and so on. All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
On Thu, 2003-03-20 at 04:35, David Megginson wrote: Jon Berndt writes: I can think of a couple of situations where YASim would have advantages - *at*present*: - Calculating any force or moment that is a result of rotational motion while the aircraft is at zero translational velocity. - Clearly, any condition that is not covered by full aerodynamic coefficients. Note that JSBSim would get all of this for free simply by allowing coefficients to be (optionally) specified for individual surfaces, each with its own orientation. All JSBSim would have to do is sum up the moments and forces (mostly forces) for the collection of surfaces. How would we specify the characteristics of each of those surfaces? All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Architectural questions
On Thu, 2003-03-20 at 05:30, David Megginson wrote: Tony Peden writes: How would we specify the characteristics of each of those surfaces? Do you mean the position/orientation, the shape, or the aerodynamic behaviour? The aero behavior. Coefficients are generally apply only to the whole and complete aircraft (with the exception of a tail-off model). This means its very hard to split them up arbitrarily. All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Short-field landing
On Sat, 2003-03-15 at 12:29, David Megginson wrote: Major A writes: I think it's reasonably gentle at less than 1m/s for each landing gear. No other part of the plane touched the runway. Remember this is with no flaps at all, and there is no stall involved. In a regular landing, you want the gear barely sinking at all at the point of contact -- maybe a few cm/sec. For a short-field landing, you plant it harder, but I'm not sure of the exact vertical velocity. 12 fps is a lot. All the best, David -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Shuttle
On Fri, 2003-03-14 at 16:45, Jon Berndt wrote: I have much improved the JSBSim shuttle flight model. In a few minutes I will commit the modified shuttle.xml file to the JSBSim repository. This can be moved to the BASE PACKAGE immediately, or sooner. ;-) Use this command line: fgfs --aircraft=shuttle --offset-distance=8.0 --altitude=15000 --pitch=-20 .0 --vc=300 If someone knows the shuttle runway identifier I'd like to know what it is. Then we could land in the right place. How about this one: http://www.airnav.com/airport/X68 It's in FG's airport database. Procedure: 1) Establish an 18 degree downward pitch angle 2) When you reach 10,000 ft. push over to 20 degrees below the horizon to pick up speed. 3) At 2,500 ft AGL begin a slow flare and establish a 3 degree glideslope. 4) Aim close and touch down on the runway at less than 3 ft/sec touchdown rate of descent. Airspeed at Main Gear WOW should be roughly 220 knots. 5) Push the nose over later and brake like hell. Your rollout will likely be about 8,000-10,000 feet. I'll try and add a drag chute later. :-) Jon -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Call it a day.
--- Erik Hofman [EMAIL PROTECTED] wrote: Major A wrote: Ignore the previous replay. 100 kt is about right. It definately shouldn't be much higher. But the lack of flaps makes it a bit difficult at this time. Really? Are you saying the F-16 can really approach that slowly? I'm not a pilot, but with FGFS, an 100kt approach in a 747 or A4 or TSR.2 is pretty much impossible, in my experience. I would be very surprised if the F-16 allowed a much slower approach than all other jets. I just got conformation the F-16 landingspeed is minimum 115 kt. I think the reason for this is the fact that the fan of the engine conbtributes the most to the drag! I presume an idling fan has a lowwer drag coefficient. Fighters, especially those that are supersonic, have relatively small wings. That's the biggest reason. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
