Re: [Flightgear-devel] radials
On 01/03/2007 09:07 PM, Dave Perry wrote: > This may seem a nit. I had the following quote "drilled" into my mind > by Don Berman in one of his well know Instrument Written Ground School > seminars. > > "Radials eminate from the station; direction of flight has nothing to > do with location." 1) That's is correct w.r.t logic and etymology; radials "should" radiate. 2) I assume that is correct w.r.t written tests, although I haven't personally checked lately. 3) OTOH that nit is not correct w.r.t real-world flying. As documentation I offer FAA Order 7110.65R : "Air Traffic Control" http://www.faa.gov/ATPubs/ATC/ in particular chapter 5 section 6 : "Vectoring" http://www.faa.gov/ATPubs/ATC/Chp5/atc0506.html which agrees with my experience of what controllers actually say. If you are west of the station inbound, the may give you vectors to intercept the 090 radial inbound. They call it a radial. They are /required/ to call it a radial. That Order does not explicitly require them to call it the 090 radial (as opposed to the 270 radial) but in practice they do call it 090, for the obvious practical reasons: 090 is also the /course/ they want you to fly. It would be madness for them to mention anything involving 270. Nitpickers might suggest they call it the 090 bearing or the 090 anti-radial or whatever ... but in practice they call it the inbound radial. By way of documentation on this specific point I refer to http://www.faa.gov/atpubs/CNT/2-1-I.htm http://www.faa.gov/atpubs/FSS/fss0504.html among other FAA documents which use the phrase "inbound radial" without the slightest hesitation. There are many other instances where you need to know one thing when taking the written test, and need to know something quite different for flying in the real world. Unless otherwise specified, you can assume what I say comes from the real-world point of view. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The version parameter is missing in FG?
On 1/3/07, Ampere K. Hardraade <[EMAIL PROTECTED]> wrote: Is it just me or does FG currently lack a "version" parameter for returning its version number? In the old days we just printed the version # to the console when we started up. A --version options sounds like a good idea to me. Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] location-in-air ... magnetic bearings from the reference
On Wed, 2007-01-03 at 15:36 -0500, John Denker wrote: > First, some background information. Suppose we are up in the air, > 10 nm west of KXYZ airfield (which is colocated with the XYZ vortac). > 1) If we were inbound to the field, I would report our position > as 10 nm west, inbound on the 090 radial. > 2) If we were outbound from the field, I would report our position > as 10 nm out on the 270 radial. This may seem a nit. I had the following quote "drilled" into my mind by Don Berman in one of his well know Instrument Written Ground School seminars. "Radials eminate from the station; direction of flight has nothing to do with location." So 2) is correct, but 1) is a contradiction. Don would report for 1) 10 nm out, inbound on the 270 radial (West is redundant). The reason he drilled us on this is it a very common miss on both the Instrument and Instrument Instructor Written exams. This distinction is even more important in understanding a hold clearance that is not on any chart. So if we are to redo the location-in-air popup, lets make sure we are not reinforcing a common mistake. This is completely consistent with your later comment: > To summarize: With rare exceptions, locations are specified using the > bearing /from/ the reference. since radial have to do with location, not heading. Best regards, Dave -- Dave Perry <[EMAIL PROTECTED]> - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] The version parameter is missing in FG?
Is it just me or does FG currently lack a "version" parameter for returning its version number? Ampere - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] out-of-date mailing-list addresses
On Wed, 3 Jan 2007 02:37:09 +0100, Arnt wrote in message <[EMAIL PROTECTED]>: > On Tue, 2 Jan 2007 15:53:21 -0600, Curtis wrote in message > <[EMAIL PROTECTED]>: > > > On 1/2/07, John Denker <[EMAIL PROTECTED]> wrote: > > > > > > How about starting with places like these: > > > -- http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > > > > I have taken care of the first one ... didn't know google was still > > showing it in searches. All the flightgear lists on flightgear.org > > are depricated and we should be using the ones at source forge. > > > > -- http://www.flightgear.org/Docs/getstart/node5.html > > > -- source/man/fgfs.1.in > > > -- source/man/pstest.1.in > > > -- source/man/gl-info.1.in > > > -- source/man/js_demo.1.in > > > -- source/man/fgjs.1.in > > > -- source/man/est-epsilon.1.in > > > ..http://80.239.32.253/arnt/fgfs.mail.list.fix.diff ..maybe easier if attached instead, md5sum: ae85f2c71e5aa866a7a0c738c450da37 fgfs.mail.list.fix.diff > ..apply with: ' patch -p4 in your source/man/, I tore it outta my > /opt/src/fgfsbuilder/ trees > stable/src/FlightGear_plib/man/ and > trunk/src/FlightGear/man/ .." -p4 " strips off the 4 un-needed directory levels. > > Hopefully the man page and documenation folks can take care of these > > other references. > > > > Curt. ..and I cannot commit this to cvs myself. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. [EMAIL PROTECTED]:/opt/src/fgfsbuilder$ diff -ru */src/FlightGea*/man/ diff -ru stable/src/FlightGear_plib/man/CVS/Entries trunk/src/FlightGear/man/CVS/Entries --- stable/src/FlightGear_plib/man/CVS/Entries 2006-12-20 15:56:03.0 +0100 +++ trunk/src/FlightGear/man/CVS/Entries2006-12-20 08:43:50.0 +0100 @@ -1,9 +1,9 @@ -/.cvsignore/1.1.1.1/Tue Sep 10 01:14:09 2002//TPRE_OSG_PLIB_20061029 -/Makefile.am/1.1.1.1/Tue Sep 10 01:14:09 2002//TPRE_OSG_PLIB_20061029 -/est-epsilon.1.in/1.1.1.1/Tue Sep 10 01:14:09 2002//TPRE_OSG_PLIB_20061029 -/fgfs.1.in/1.4/Thu Oct 23 15:53:32 2003//TPRE_OSG_PLIB_20061029 -/fgjs.1.in/1.1.1.1/Tue Sep 10 01:14:09 2002//TPRE_OSG_PLIB_20061029 -/gl-info.1.in/1.1.1.1/Tue Sep 10 01:14:09 2002//TPRE_OSG_PLIB_20061029 -/js_demo.1.in/1.1.1.1/Tue Sep 10 01:14:09 2002//TPRE_OSG_PLIB_20061029 -/pstest.1.in/1.1.1.1/Tue Sep 10 01:14:09 2002//TPRE_OSG_PLIB_20061029 +/.cvsignore/1.1.1.1/Tue Sep 10 01:14:09 2002// +/Makefile.am/1.1.1.1/Tue Sep 10 01:14:09 2002// +/est-epsilon.1.in/1.1.1.1/Tue Sep 10 01:14:09 2002// +/fgfs.1.in/1.4/Thu Oct 23 15:53:32 2003// +/fgjs.1.in/1.1.1.1/Tue Sep 10 01:14:09 2002// +/gl-info.1.in/1.1.1.1/Tue Sep 10 01:14:09 2002// +/js_demo.1.in/1.1.1.1/Tue Sep 10 01:14:09 2002// +/pstest.1.in/1.1.1.1/Tue Sep 10 01:14:09 2002// D Only in stable/src/FlightGear_plib/man/CVS: Tag diff -ru stable/src/FlightGear_plib/man/est-epsilon.1.in trunk/src/FlightGear/man/est-epsilon.1.in --- stable/src/FlightGear_plib/man/est-epsilon.1.in 2002-09-10 03:14:09.0 +0200 +++ trunk/src/FlightGear/man/est-epsilon.1.in 2007-01-03 02:04:22.0 +0100 @@ -25,7 +25,7 @@ .B est-epsilon is an OpenGL test program used to show epsilon estimation of GLfloat. .SH BUGS -Send bug reports to . +Send bug reports to . .SH SEE ALSO fgfs(1) .SH AUTHORS diff -ru stable/src/FlightGear_plib/man/fgfs.1.in trunk/src/FlightGear/man/fgfs.1.in --- stable/src/FlightGear_plib/man/fgfs.1.in2003-10-23 17:53:32.0 +0200 +++ trunk/src/FlightGear/man/fgfs.1.in 2007-01-03 02:04:46.0 +0100 @@ -509,7 +509,7 @@ Mouse bindings. .RE .SH BUGS -Send bug reports to . +Send bug reports to . .SH SEE ALSO fgjs(1) .SH AUTHORS diff -ru stable/src/FlightGear_plib/man/fgjs.1.in trunk/src/FlightGear/man/fgjs.1.in --- stable/src/FlightGear_plib/man/fgjs.1.in2002-09-10 03:14:09.0 +0200 +++ trunk/src/FlightGear/man/fgjs.1.in 2007-01-03 02:05:12.0 +0100 @@ -26,7 +26,7 @@ is a joystick utility for the FlightGear Flight Simulator. It allows you to generate an appropriate configuration file for your joystick. .SH BUGS -Send bug reports to . +Send bug reports to . .SH SEE ALSO fgfs(1) .SH AUTHORS diff -ru stable/src/FlightGear_plib/man/gl-info.1.in trunk/src/FlightGear/man/gl-info.1.in --- stable/src/FlightGear_plib/man/gl-info.1.in 2002-09-10 03:14:09.0 +0200 +++ trunk/src/FlightGear/man/gl-info.1.in 2007-01-03 02:05:27.0 +0100 @@ -25,7 +25,7 @@ .B gl-info is an OpenGL test program used to verify a valid OpenGL environment. .SH BUGS -Send bug reports to . +Send bug reports to . .SH SEE ALSO fgfs(1) .SH AUTHORS diff -ru stable/src/FlightGear_plib/man/js_demo.1.in trunk/src/FlightGear/man/js_demo.1.in --- stable/src/FlightGear_plib/man/js_demo.1.in 2002-09-10 03:14:09.0 +0200 +++ trunk/src/FlightGear/man/js_demo.1.in 2007-01-03 02:05:37.0 +0100 @@ -25,7 +
Re: [Flightgear-devel] location-in-air ... magnetic bearings from the reference
I found a way to make it do what I want. Here's my version http://www.av8n.com/fly/fgfs/location-in-air.xml and the diff against the cvs version: http://www.av8n.com/fly/fgfs/location-in-air.diff On 01/03/2007 05:19 PM, Curtis Olson wrote: > Only if you are relocating to a nearby position. If I relocate from MN > to CA (because there's some specific approach or navaid arrangement or > terrain I want to practice with, the difference could be as much as 15 > degrees.) That's a good point. I consider it a bug in what I've written. The canonical behavior is to use the magnetic deviation at the /reference/ point. Can somebody give me a hint how to obtain the deviation at the location of arbitrary navaids and airports? On to a different branch of the discussion: > The flight dynamics are a "black box" as far as FlightGear is > concerned. / OK, black box it is. > You can't just change the position instantaneously inside > that black box because that movement would have incredble forces and > velocities associated with it an all sorts of bad stuff could ensue. OK, changing the rules and looking inside the black box now. a) I don't have any hard evidence, but my gut feeling tells me that the overwhelming majority of FDMs do *not* do it that way. I'll bet they integrate the acceleration to get velocity, and integrate velocity to get position (rather than differentiating position to get velocity). b) There are excellent and profoundly fundamental physics reasons why item (a) should be true. The laws of physics are the same in each and every place. You will break the airplane if you move /part/ of it to a new place and leave other parts behind ... but if you move everything together, there should be no observable consequences. This is connected vie Noether's theorem to the law of conservation of momentum, which is about as close to the heart and soul of physics as you can get. The only way the FDM could think there was a big velocity or acceleration is if it tried to /remember/ some sort of "previous" location. In that case we simply beseech the implementers to relocate the "previous" location when they relocate the current location. The rule is really quite simple: relocate everything together! > ) If the reset is in the air, > then there is code to "trim" the aircraft for straight and level flight > at the initial conditions. It does a rather poor job of trimming. Perhaps we can distinguish two cases: -- parking-to-air relocation, versus -- air-to-air relocation. In the latter case, not messing with the throttle, trim, etc., etc. would seem like a reasonable policy. > I believe that part of this trimming routine > sets the throttle position for level flight. If you have a joystick > throttle that will of course take precidence. Correction: /should/ take precedence. Having tried it several times, I assure you that my USB throttle position does not take precedence. The relocation xml code warps the power setting to 0.5, and the USB throttle does not re-assert itself until I _move_ the throttle. This is unrealistic and annoying. Again, for an air-to-air relocation, leaving stuff alone would seem like a reasonable policy. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] location-in-air ... magnetic bearings from the reference
On 1/3/07, John Denker <[EMAIL PROTECTED]> wrote: I'm coming at this from the perspective of an instrument flying lesson. Being able to reposition the aircraft a few miles from the initial approach fix saves a lot of time. And that is a perspective we fully want to support and promote . The reposition dialog box doesn't do any nasal, it just sets a bunch of > property values and calls the reset function. Yeah, I noticed that. The reset function is brutal. It trashes the pilot's trim settings and who-knows-what-all else. Also, currently location-in-air.xml trashes the throttle settings. The code doesn't explain why. Does anybody have an explanation? Is it to prevent the reset function from doing something even worse? The flight dynamics are a "black box" as far as FlightGear is concerned. You can't just change the position instantaneously inside that black box because that movement would have incredble forces and velocities associated with it an all sorts of bad stuff could ensue. Instead we tell the flight dynamics to "reset" at a new location in the world (either on the ground or in the air.) If the reset is in the air, then there is code to "trim" the aircraft for straight and level flight at the initial conditions. I believe that part of this trimming routine sets the throttle position for level flight. If you have a joystick throttle that will of course take precidence. There are some non trivial issues because FlightGear can't move your throttle for you. I'm not sure thinking in terms of "reset" is the right approach. How about implementing a nice _relocate_ function, splitting it out as a function unto itself ... just changing location without resetting other stuff. The reset function can then make a structured reference to this relocate function. You'll have to take that one up with the flight dynamics authors. :-) But realize that any change in the api (if possible to impliment) has to have underlying support from all the different flight dynamics modules. Also, you probably want to change location and heading and speed all at the same time, right? You can't just change any of these instantaneously in the internal math model without a cascading series of effects. You can't just instantaneously change the direction of the aircraft 45 degrees without incurring tremendous side loads for a few moments until everything settles out. Be aware that in numeric integration, you need to save current value and last value and perhaps even a few past values to make all the math work out. This creates a pipeline that is difficult to interrupt without causing all kinds of side effects. Doesn't it suffice to look at the /environment/magnetic-variation-deg node? Only if you are relocating to a nearby position. If I relocate from MN to CA (because there's some specific approach or navaid arrangement or terrain I want to practice with, the difference could be as much as 15 degrees.) That's what I did in my attempt, i.e. http://www.av8n.com/fly/fgfs/location-in-air.xml I suspect that if ... were working at all, the magnetic-variation-deg part would have been OK. Or am I overlooking something else? Xml is xml, but this get's parsed into a hierarchical structure in FlightGear. However the specific code that interprets that structure needs to be designed to honor the tag. Animation code does honor that tag, but not dialog box code (as far as I know.) I still don't understand why ... didn't work. I would have thought the property-setting that goes on in dialog boxes would be handled the same way as property-setting everywhere else. Is there some fundamental limitation here, or just an easy "opportunity for improvement"? Possibly there is an opportunity for improvement here, but we would need to proceed carefully. It seems like it would make a lot more sense to just ask the user to input the number in the units/frame that the code wants rather than asking for it in some other frame of reference and then translating it. There is some complexity and potentially hidden/unexpected behavior that would be introduced here that I'm not sure I'm 100% comfortable with. I'd rather we just ask the user to input the number that the code wants in the first place. Or change the code to require a different unit/frame of reference and then change the question to match. Regards, Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Flig
Re: [Flightgear-devel] location-in-air ... magnetic bearings from the reference
On 01/03/2007 04:00 PM, Curtis Olson wrote: > we do want this to work intuitively so I would welcome > any changes to improve the in-air reposition dialog box. :-) > I think it makes a lot > more sense to focus on the gui dialog box. Agreed. I'm coming at this from the perspective of an instrument flying lesson. Being able to reposition the aircraft a few miles from the initial approach fix saves a lot of time. > The reposition dialog box doesn't do any nasal, it just sets a bunch of > property values and calls the reset function. Yeah, I noticed that. The reset function is brutal. It trashes the pilot's trim settings and who-knows-what-all else. Also, currently location-in-air.xml trashes the throttle settings. The code doesn't explain why. Does anybody have an explanation? Is it to prevent the reset function from doing something even worse? > So in this case I think what needs to be done is to modify the reset > function (in a backwards compatible way) to understand the property > values that are set from the dialog box and do the right thing with them. I'm not sure thinking in terms of "reset" is the right approach. How about implementing a nice _relocate_ function, splitting it out as a function unto itself ... just changing location without resetting other stuff. The reset function can then make a structured reference to this relocate function. > I think there will need to be some support in the code for this. It's > easy to compute the local magnetic variation for some lon/lat, Doesn't it suffice to look at the /environment/magnetic-variation-deg node? That's what I did in my attempt, i.e. http://www.av8n.com/fly/fgfs/location-in-air.xml I suspect that if ... were working at all, the magnetic-variation-deg part would have been OK. Or am I overlooking something else? > but the > dialog boxes just set property values and trigger internal function > calls (and maybe a bit of nasal here or there.) I still don't understand why ... didn't work. I would have thought the property-setting that goes on in dialog boxes would be handled the same way as property-setting everywhere else. Is there some fundamental limitation here, or just an easy "opportunity for improvement"? > Our font has a very limited number of characters available so I don't > think [the degree] symbol is available. I can live without it. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim glider
Hi all, tonight a nice aerotow was performed (thanks to AJ), some winch starts and the J3 as external cargo with the CH47 (thanks to Joacim). I will do some clean up in the code, and add the gravity force of the tow... Maik Maik Justus schrieb am 01.01.2007 15:57: > Hi Heiko, > > I am thinking of extending the yasim solver to be capable to simulate > gliders (now you need a thruster only for the solver). > > But his is not the real aim. I want to add the ability to use ropes. To > be used for winch as well as for aerotow. > > Maik > > Heiko Schulz schrieb am 01.01.2007 14:56: > >> Hi, >> >> I'm sure not - even the shuttle is jsbsim - why do you >> ask? >> >> Greetings >> HHS >> --- Maik Justus <[EMAIL PROTECTED]> schrieb: >> >> >> >>> Happy new year all, >>> >>> do we have a yasim-glider? >>> >>> Thanks, >>> Maik >>> >>> >>> >>> >> - >> >> >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get >>> the chance to share your >>> opinions on IT & business topics through brief >>> surveys - and earn cash >>> >>> >>> >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> >> >>> ___ >>> Flightgear-devel mailing list >>> Flightgear-devel@lists.sourceforge.net >>> >>> >>> >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >> >> >> >> __ >> Do You Yahoo!? >> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz >> gegen Massenmails. >> http://mail.yahoo.com >> >> - >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >> >> >> > > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] location-in-air ... magnetic bearings from the reference
On 1/3/07, John Denker <[EMAIL PROTECTED]> wrote: First, some background information. Suppose we are up in the air, 10 nm west of KXYZ airfield (which is colocated with the XYZ vortac). [snip] To summarize: With rare exceptions, locations are specified using the bearing /from/ the reference. Also note that in all cases these are /magnetic/ bearings. So ... I recently used the location-in-air popup menu for the first time. I selected a distance of 25 nm and an "azimuth" of 270. I had no doubt that this would put me 25 miles west of the station. Imagine my astonishment when it put me 25 miles east of the station! Yes, that does sound confusing ... An additional nuisance was that this location was /true/ east not magnetic east. Just to add to the excitement, this put me below ground level, in the mountains east of the station. But that is only tangential to the present discussion. Computers just do what you tell them to do. :-) One final remark: Pilots talk about radials, courses, and bearings. The word "azimuth" is not used much. It's a perfectly fine word, and certainly has its place in the /internals/ of a flight simulator. OTOH there are lots of users (including me) who want the user interface (i.e. pilot interface) to be as realistic as possible. The existing location-in-air popup is shockingly unrealistic from a pilot's point of view. This needs fixing. The tricky part is fixing it in a way that doesn't break legacy usages. I suggest we start by making the following distinctions explicit: --true-bearing-to --true-bearing-from --mag-bearing-to --mag-bearing-from Currently, the command-line interface implements --azimuth, which is documented to be "to" the reference, and is apparently equivalent to --true-bearing-to. That's OK with me as far as it goes. 1) I suggest that the command-line interface be extended to support the four explicit bearings itemized above. We can continue to support --azimuth as a fifth option, synonymous with --true-bearing-to, but it should be mildly deprecated on the grounds of ambiguity. I think that --azimuth itself is a rarely used option so I would be a little hesitant to split that into 5 options, none of which will probably be used by more than one or two people. I think it makes a lot more sense to focus on the gui dialog box. 2) I suggest that the location-in-air popup be revised so that it uses the equivalent of --mag-bearing-from, not --azimuth. As part of this, I suggest changing the wording on the popup from: Azimuth (deg): ___ to Bearing: ___° mag from I don't think this will break any of the documentation, because AFAICT the location-in-air popup isn't documented in any detail anywhere. I'd be happy to try implementing this myself, but I would appreciate some help or at least hints. *) I've already changed the appearance of the popup. Easy. *) I spelled out "deg". I tried putting the ° symbol in the xml file, but it complained of a parse error. Using ° didn't work, either. Any suggestions on how to encode symbols? Our font has a very limited number of characters available so I don't think this symbol is available. *) I tried putting 180 and /environment/magnetic-variation-deg commands in the location-in-air.xml file, but the system appeared to just shrug them off. No effect. What's the trick? I think there will need to be some support in the code for this. It's easy to compute the local magnetic variation for some lon/lat, but the dialog boxes just set property values and trigger internal function calls (and maybe a bit of nasal here or there.) The reposition dialog box doesn't do any nasal, it just sets a bunch of property values and calls the reset function. So in this case I think what needs to be done is to modify the reset function (in a backwards compatible way) to understand the property values that are set from the dialog box and do the right thing with them. Has this issue come up before? I didn't see any sign of it. I'm not aware of this issue being brought to light in the past. I suspect that most people don't do a lot of complicated initial positions, but we do want this to work intuitively so I would welcome any changes to improve the in-air reposition dialog box. Regards, Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.so
[Flightgear-devel] location-in-air ... magnetic bearings from the reference
First, some background information. Suppose we are up in the air, 10 nm west of KXYZ airfield (which is colocated with the XYZ vortac). 1) If we were inbound to the field, I would report our position as 10 nm west, inbound on the 090 radial. 2) If we were outbound from the field, I would report our position as 10 nm out on the 270 radial. 3) If we were flying northbound, I would report our position as 10 nm out on the 270 radial. 4) If we were flying northbound, I would report our position as 10 nm out on the 270 radial. 5) Every enroute chart I've ever seen specifies the location of waypoints in terms of distance and bearing /from/ the station. 6) Every GPS I've seen lets you enter waypoints in terms of distance and bearing /from/ some reference. 7) Every NOTAM I've ever seen, when specifying bearings, uses bearing /from/ some reference. To summarize: With rare exceptions, locations are specified using the bearing /from/ the reference. Also note that in all cases these are /magnetic/ bearings. So ... I recently used the location-in-air popup menu for the first time. I selected a distance of 25 nm and an "azimuth" of 270. I had no doubt that this would put me 25 miles west of the station. Imagine my astonishment when it put me 25 miles east of the station! An additional nuisance was that this location was /true/ east not magnetic east. Just to add to the excitement, this put me below ground level, in the mountains east of the station. But that is only tangential to the present discussion. One final remark: Pilots talk about radials, courses, and bearings. The word "azimuth" is not used much. It's a perfectly fine word, and certainly has its place in the /internals/ of a flight simulator. OTOH there are lots of users (including me) who want the user interface (i.e. pilot interface) to be as realistic as possible. The existing location-in-air popup is shockingly unrealistic from a pilot's point of view. This needs fixing. The tricky part is fixing it in a way that doesn't break legacy usages. I suggest we start by making the following distinctions explicit: --true-bearing-to --true-bearing-from --mag-bearing-to --mag-bearing-from Currently, the command-line interface implements --azimuth, which is documented to be "to" the reference, and is apparently equivalent to --true-bearing-to. That's OK with me as far as it goes. 1) I suggest that the command-line interface be extended to support the four explicit bearings itemized above. We can continue to support --azimuth as a fifth option, synonymous with --true-bearing-to, but it should be mildly deprecated on the grounds of ambiguity. 2) I suggest that the location-in-air popup be revised so that it uses the equivalent of --mag-bearing-from, not --azimuth. As part of this, I suggest changing the wording on the popup from: Azimuth (deg): ___ to Bearing: ___° mag from I don't think this will break any of the documentation, because AFAICT the location-in-air popup isn't documented in any detail anywhere. I'd be happy to try implementing this myself, but I would appreciate some help or at least hints. *) I've already changed the appearance of the popup. Easy. *) I spelled out "deg". I tried putting the ° symbol in the xml file, but it complained of a parse error. Using ° didn't work, either. Any suggestions on how to encode symbols? *) I tried putting 180 and /environment/magnetic-variation-deg commands in the location-in-air.xml file, but the system appeared to just shrug them off. No effect. What's the trick? Has this issue come up before? I didn't see any sign of it. I searched for http://www.google.com/search?q=flightgear+location-in-air and found nothing informative. I also search the flightgear-devel list at sourceforge and found nothing informative ... just terse routine cvs log entries. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gold mine of helicopter airfoil data
Look for the naca files on the internet to find them all in a better format. I think they actually have them in database or spreadsheet form somewhere unless they have gotten rid of it. On Wed, 3 Jan 2007 12:24 pm, Joacim Persson wrote: > On Wed, 3 Jan 2007, Heiko Schulz wrote: > >> Hi, >> >> Real nice. But from 1976 - newer one would be good >> too! > > If there is a volume 2 somewhere... > > Leo Dadone is a Boeing guy btw, so I suspect the 40-some listed > airfoils > should at least cover the Boeing rotorcrafts up to 1977. Many of the > airfoils listed are regular NACA airfoils that probably are documented > elsewhere too. Nice to have them in one file though, even if it is a > bit > big. > > Now excuse me, I have to drool over the VR-7 and VR-8 data for a while. > =) > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel www.GlobalBoiling.com for daily images about hurricanes, globalwarming and the melting poles. www.ElectricQuakes.com daily solar and earthquake images. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved c172p autopilot
On Wednesday 03 January 2007 10:27, woodyst wrote: > It can be fixed in "kap140.nas" file, I think. I would study that file well > and if I can, I will send another patch. I've overhauled kap140.nas quite extensively. I've changed to more sensible property data types like boolenas instead of text. I've also fixed the bug that Joacim Persson reported. I'll try to hand it over to someone with write access to CVS tonight. Because of this you should hold off studying the code until the new version is in CVS. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gold mine of helicopter airfoil data
On Wed, 3 Jan 2007, Heiko Schulz wrote: > Hi, > > Real nice. But from 1976 - newer one would be good > too! If there is a volume 2 somewhere... Leo Dadone is a Boeing guy btw, so I suspect the 40-some listed airfoils should at least cover the Boeing rotorcrafts up to 1977. Many of the airfoils listed are regular NACA airfoils that probably are documented elsewhere too. Nice to have them in one file though, even if it is a bit big. Now excuse me, I have to drool over the VR-7 and VR-8 data for a while. =) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Gold mine of helicopter airfoil data
Hi, Real nice. But from 1976 - newer one would be good too! But Maybe this will lead to some nice helos! Greets HHS --- Joacim Persson <[EMAIL PROTECTED]> schrieb: > Thought I'd share this find -- discovered it just > now: > http://ntrs.nasa.gov/ > Document-ID: 19770018207 > Title: US Army helicopter design datcom. Volume 1 > Airfoils > Author: Leo Dadone > Abstract: > This report contains airfoil data of interest for > rotor > applications. The data is presented in the form of > lift, drag, and > pitching moment coefficients and, in most cases, > it covers the > complete Mach number range from low subsonic to > supercritical flow > conditions. An introductory section presents > airfoil data trends > and information pertaining to the source and > usefulness of such > data. > > The pdf is >19MB > > No traces of a volume 2 at NTRS. Maybe there never > was one. > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get > the chance to share your > opinions on IT & business topics through brief > surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Gold mine of helicopter airfoil data
Thought I'd share this find -- discovered it just now: http://ntrs.nasa.gov/ Document-ID: 19770018207 Title: US Army helicopter design datcom. Volume 1 Airfoils Author: Leo Dadone Abstract: This report contains airfoil data of interest for rotor applications. The data is presented in the form of lift, drag, and pitching moment coefficients and, in most cases, it covers the complete Mach number range from low subsonic to supercritical flow conditions. An introductory section presents airfoil data trends and information pertaining to the source and usefulness of such data. The pdf is >19MB No traces of a volume 2 at NTRS. Maybe there never was one. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CH53e data
I just noticed that there might be/is a typo in the ch53e-yasim.xml file. change: ground-effect-constatnt="1.25" to: ground-effect-constant="1.25" Greetings, Wim On 1/3/07, wim van hoydonck <[EMAIL PROTECTED]> wrote: > Hi there, > > I just checked Janes' All the world aircraft (versions 1979-1880 and > 1989-1990) which confirms the data found in Prouty, except for the > main rotor blade twist. For thi,s Janes gives a value of -14 degrees, > but this value is probably measured from the root cutout (so not from > the centre of the hub as in Prouty). > > Performance data (ISA, T/O weight: 25400 kg) for the CH-53E: > - Max level speed @ S/L: 170 kts (315 km/h; 196 mph) > - Cruising speed @ S/L: 150 kts (272 km/h; 173 mph) > - Max Rate of Climb @ S/L:838 m (2750 ft) / sec > - Hovering ceiling IGE max power: 3520 m (11550 ft) > - Hovering ceiling OGE max power: 2895 m (9500 ft) > - Service ceiling max cont power: 5640m (18500 ft) > - Range (optim cruise speed for best range): 1120 nm (2075 km; 1290 miles) > > Powerplant > 3 T64-GE-415 or T64-GE-416 turboshaft engines; > - performance each: >- max rating: 3266 kW (4380 shp) 10 minutes >- intermediate rating:3091 kW (4145 shp) 30 minutes >- max cont rating: 2756 kW (3696 shp) > - rotor transmission: >- rated @ 9792 kW (13140 shp) for 10 sec >- rated @ 8627 kW (11570 shp) for 30 min > > Fuel capacity: > - self-sealing bladder fuel cell in forward part of each sponson, > each w. capacity of 1192 litres (315 US gallon) > - additional 2-cell unit, capacity 1465 litres (387 US gall), > -> total standard internal capacity: 3849 litres (1017 US gall) > - optional drop tanks outboard of each sponson for CH-53E, total > capacity 4921 litres (1300 US gall) > MH-53E can carry 7 internal range extension tanks, total capacity 7949 > litres (2100 US gall) > > Weights: > - empty:15 071 kg (33 226 lb) > - internal payload (100 nm radius): 13 607 kg (30 000 lb) > - external payload (50 nm radius): 14 605 kg (32 200 lb) > - MTOW: 33 339 kg (73500 lb) > > Rotor dimensions: > - MR diameter: 24.08 m > - TR diameter: 6.10 m > - MR blade chord: 0.76 m > - MR blade twist: 14 deg > > > Greetings, > > Wim > > > On 12/18/06, wim van hoydonck <[EMAIL PROTECTED]> wrote: > > Hi there, > > > > > > Some data for the CH53e yasim model, taken from Prouty [1], p. 699. > > > > Looking at the data in cvs, rotor diameters and chords should/could be > > changed, just like control input ranges for the main and tail rotor. > > > > > > Weights (lb): > > - Empty:33009 > > - MTOW (internal payload): 69750 > > - MTOW (external payload): 73500 > > - Fuel capacity (norm): 6682 > > - Fuel capacity (aux): 8450 > > > > Engines: > > - Type: General Electric T64-GE-416 > > - Number:3 > > - Max T.O. rating: 13140 > > - Max usable power: 11570 > > > > Rotor Parameters: Main > > Tail > > - Radius (ft): 39.5 > > 10 > > - Chord (ft):2.44 > > 1.28 > > - solidity 0.138 > > 0.163 > > - No. of blades: 7 > >4 > > - Tip speed (ft/sec):732 > > 733 > > - twist (deg): -20 > > -8 > > - equiv. linear hinge offset ration (e/R): 0.063 0.043 > > - Airfoil: SC1095 > >NACA 0015 > > - Collective range (deg): -1.4 to 19.6 -10 > > to 24 > > - Longitudinal cyclic range (deg): -8.5 to 18.0 - > > - Lateral cyclic range (deg): -9.8 to 6.1 - > > - Polar moment of inertia (slug ft^2) 51800181 > > > > > > Greetings, > > > > Wim > > > > > > [1] Prouty, R. W., Helicopter Performance, Stability and Control > > > > > > -- > > Avoid hangovers - stay drunk! > > > > > -- > Avoid hangovers - stay drunk! > -- Avoid hangovers - stay drunk! - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved c172p autopilot
On 01/03/2007 01:01 AM, Dave Perry wrote: > The ILS minimums for non CAT II or CAT III approaches are usually no > less than 200 1/2 (200 ft AGL decision height and 1/2 mile visibility). > It is not legal to do a 0-0 ILS in the C172P with this autopilot. If you > do not have the runway environment well in sight at the decision height > (usually the GS intersects the DH at the middle marker), you are > required to execute a missed approach. That seems unhelpful on several levels. (A more helpful approach is suggested below.) 1) First of all, visibility (etc.) regulations are irrelevant to the design and simulation of low-end autopilots. The autopilot isn't looking out the window. 2) That isn't a correct statement of the regulations. FAR 91.175(c) is quite a bit more intricate than that. Pilots have enough trouble keeping track of the real regulations; it doesn't help to have made-up pseudo-regulations bandied about. *) To say the same thing another way: There is no law against coupling an autopilot to an ILS signal in good weather and flying it as low as autopilot (and pilot) performance permits. You don't need an IFR clearance, or even an instrument rating. *) There are /some/ situations where regulations are designed around hardware limitations, and/or hardware is designed to meet regulations, but this is not one of those situations. Trying to connect KAP140 performance to Cat-I ceiling and visibility has no basis in legality or practicality. So let's rephrase the question. Autopilot designers should be asking, among other things: -- How accurate is the autopilot? -- How do things like left/right accuracy and sensitivity change as the aircraft gets nearer and nearer to the localizer antenna? -- How do things like up/down accuracy and sensitivity change as the aircraft gets nearer and nearer to the glideslope antenna, which will be approached very closely indeed during a normal landing. Also remember that some people (not all, but quite a few) are interested in _realistic_ simulations. An autopilot that does a fair-to-poor jobs of tracking NAV signals is not particularly unrealistic :-). = In a real aircraft, if the autopilot is controlling the ailerons, you shouldn't be forcing the yoke left or right, and the autopilot will resist you if you try. You can overpower the autopilot if you try hard enough ... but this is not normal procedure. Similarly, in a real airplane, if the autopilot is controlling the elevator, you shouldn't be forcing the yoke in the pitchwise direction. Modelling this is tricky. Ideally we would have force-feedback and position-feedback on our joysticks, but not all of us can afford that. Ignoring joystick input on each autopilot-controlled axis is the most sensible option I've seen proposed. Note: Be sure that the cockpit model shows the yoke moving in response to autopilot inputs. This is particularly important when it comes time to disengage the autopilot; the astute user will position the joystick to match the position of the yoke before transferring control. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CH53e data
Hi there, I just checked Janes' All the world aircraft (versions 1979-1880 and 1989-1990) which confirms the data found in Prouty, except for the main rotor blade twist. For thi,s Janes gives a value of -14 degrees, but this value is probably measured from the root cutout (so not from the centre of the hub as in Prouty). Performance data (ISA, T/O weight: 25400 kg) for the CH-53E: - Max level speed @ S/L: 170 kts (315 km/h; 196 mph) - Cruising speed @ S/L: 150 kts (272 km/h; 173 mph) - Max Rate of Climb @ S/L:838 m (2750 ft) / sec - Hovering ceiling IGE max power: 3520 m (11550 ft) - Hovering ceiling OGE max power: 2895 m (9500 ft) - Service ceiling max cont power: 5640m (18500 ft) - Range (optim cruise speed for best range): 1120 nm (2075 km; 1290 miles) Powerplant 3 T64-GE-415 or T64-GE-416 turboshaft engines; - performance each: - max rating: 3266 kW (4380 shp) 10 minutes - intermediate rating:3091 kW (4145 shp) 30 minutes - max cont rating: 2756 kW (3696 shp) - rotor transmission: - rated @ 9792 kW (13140 shp) for 10 sec - rated @ 8627 kW (11570 shp) for 30 min Fuel capacity: - self-sealing bladder fuel cell in forward part of each sponson, each w. capacity of 1192 litres (315 US gallon) - additional 2-cell unit, capacity 1465 litres (387 US gall), -> total standard internal capacity: 3849 litres (1017 US gall) - optional drop tanks outboard of each sponson for CH-53E, total capacity 4921 litres (1300 US gall) MH-53E can carry 7 internal range extension tanks, total capacity 7949 litres (2100 US gall) Weights: - empty:15 071 kg (33 226 lb) - internal payload (100 nm radius): 13 607 kg (30 000 lb) - external payload (50 nm radius): 14 605 kg (32 200 lb) - MTOW: 33 339 kg (73500 lb) Rotor dimensions: - MR diameter: 24.08 m - TR diameter: 6.10 m - MR blade chord: 0.76 m - MR blade twist: 14 deg Greetings, Wim On 12/18/06, wim van hoydonck <[EMAIL PROTECTED]> wrote: > Hi there, > > > Some data for the CH53e yasim model, taken from Prouty [1], p. 699. > > Looking at the data in cvs, rotor diameters and chords should/could be > changed, just like control input ranges for the main and tail rotor. > > > Weights (lb): > - Empty:33009 > - MTOW (internal payload): 69750 > - MTOW (external payload): 73500 > - Fuel capacity (norm): 6682 > - Fuel capacity (aux): 8450 > > Engines: > - Type: General Electric T64-GE-416 > - Number:3 > - Max T.O. rating: 13140 > - Max usable power: 11570 > > Rotor Parameters: Main Tail > - Radius (ft): 39.5 > 10 > - Chord (ft):2.44 > 1.28 > - solidity 0.138 > 0.163 > - No. of blades: 7 >4 > - Tip speed (ft/sec):732 > 733 > - twist (deg): -20 > -8 > - equiv. linear hinge offset ration (e/R): 0.063 0.043 > - Airfoil: SC1095 >NACA 0015 > - Collective range (deg): -1.4 to 19.6 -10 to > 24 > - Longitudinal cyclic range (deg): -8.5 to 18.0 - > - Lateral cyclic range (deg): -9.8 to 6.1 - > - Polar moment of inertia (slug ft^2) 51800181 > > > Greetings, > > Wim > > > [1] Prouty, R. W., Helicopter Performance, Stability and Control > > > -- > Avoid hangovers - stay drunk! > -- Avoid hangovers - stay drunk! - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved c172p autopilot
On Wed, 3 Jan 2007, Ralf Gerlich wrote: > I'm confused. Does the KAP140 use the trim or not? It does not use trims (i.e. trim tabs, usually) for controlling the aircraft. The AP servos drive the control surfaces directly so the pitch servo operates pitch, not pitch trim (tabs); just as the roll servo operates on the ailerons, not the aileron trim tabs. (And there is no servo operating the rudder or rudder trim tab for the kap140) There is however an optional electric elevator trim function which is not implemented in the FG kap140 model and that can (IRL) be manually operated or automatic. See pp 3 -- 7 in the KAP140 Pilot Guide. The figure on p. 7 in particular. There is a roll servo and a pitch servo. The optional pitch _trim_ servo shown in the figure would move the elevator trim tabs rather than the whole elevator. (depending on aircraft design of course) I suppose the pitch trim servo would actuate the same mechanisms as the pilot uses for trim pitch, so even if the aircraft has some other physical means for pitch trimming than tabs on the trailing edge of the elevator, it would still be two different input points. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved c172p autopilot
Hi, Joacim Persson wrote: >> OTOH if we're not that much after exact internal modelling, we might as >> well use the trim channel ;-) > > The piloting of the aircraft, including AP, should be realistic. In this > case that involves adjusting the pitch trim (manually) -- why there are > warning lights for it on the kap140 panel (irl and in the sim) to inform > him/her that the pitch trim needs to be adjusted to avoid unpleasent > surprises when the AP is disengaged. So it isn't about internal modelling, > but rather external such. ;) I'm confused. Does the KAP140 use the trim or not? Cheers, Ralf - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved c172p autopilot
On Wed, 3 Jan 2007, Ralf Gerlich wrote: > Disabling joystick inputs alltogether should not be an option, except - > perhaps - if you only disable a single axis. Assume that your AP is in > ALT hold mode and you want to do turns. You are right about that of course. And using a separate channel is also a better idea. (And in some AP implementations, not the kap140, the AP is disengaged if the controls are moved a certain amount or with a certain force. But that's beside the kap140 issue.) Noice from the js should be handled elsewhere: deadzone or filtering ...or simply bin old worn-out joysticks with dodgy sensors. ;) > OTOH if we're not that much after exact internal modelling, we might as > well use the trim channel ;-) The piloting of the aircraft, including AP, should be realistic. In this case that involves adjusting the pitch trim (manually) -- why there are warning lights for it on the kap140 panel (irl and in the sim) to inform him/her that the pitch trim needs to be adjusted to avoid unpleasent surprises when the AP is disengaged. So it isn't about internal modelling, but rather external such. ;) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved c172p autopilot
Hi, Joacim Persson wrote: > On Wed, 3 Jan 2007, woodyst wrote: > >> For the moment using trim for autopilot makes the fly more acurate because >> it does not interfere with input devices. > > ...kap140 controlling the aircraft via trim is not accurate regarding how the > kap140 works. :P But you do point out a problem there: input device vs AP > interference. How about disabling joystick inputs altogether when the AP > is in control? I haven't flown any a/c with AP myself in reality, but as has been said the AP moves the yoke, so that the pilot can add input over the AP. Disabling joystick inputs alltogether should not be an option, except - perhaps - if you only disable a single axis. Assume that your AP is in ALT hold mode and you want to do turns. Using trim for the AP is possibly an intermediate solution, but I know that in JSBSim and in YASim you can define control sums, i.e., add different inputs together to make the input given to the FDM. If people have a problem with the AP modifying trim, we could as well give the AP its own input channel for each axis it should control. This input channel would neither be trim nor would it block user input on the joystick. OTOH if we're not that much after exact internal modelling, we might as well use the trim channel ;-) Cheers, Ralf - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved c172p autopilot
On Wed, 3 Jan 2007, woodyst wrote: > For the moment using trim for autopilot makes the fly more acurate because > it does not interfere with input devices. ...kap140 controlling the aircraft via trim is not accurate regarding how the kap140 works. :P But you do point out a problem there: input device vs AP interference. How about disabling joystick inputs altogether when the AP is in control? Speaking of kap140, has anyone applied the onliner-bugfix I posted a week ago? (dec 26th: ROL -> APR/GS mode broken; unless I've misunderstood the function of the kap140 of course ;) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved c172p autopilot
On 1/3/07, Dave Perry <[EMAIL PROTECTED]> wrote: On Wed, 2007-01-03 at 03:08 +0100, woodyst wrote: > I've arrived to that conclusion when I saw that the plain wasn't > unable of performing a 0-0 visibility approach with ILS. The ILS minimums for non CAT II or CAT III approaches are usually no less than 200 1/2 (200 ft AGL decision height and 1/2 mile visibility). It is not legal to do a 0-0 ILS in the C172P with this autopilot. If you do not have the runway environment well in sight at the decision height (usually the GS intersects the DH at the middle marker), you are required to execute a missed approach. > I have improved the file (I think, I've never used a real Cessna 172 > with the KAP140, so I do not know if this result is more or less > realistic): > > - In the KAP140 manual there are a lot of references that indicates > the KAP140 uses elevator trim and not elevator for handling altitudes. > So I have adapted KAP140.xml file to use elevator trim. It results in > softer altitude changes and the autopilot does not conflict with > joystick or yoke. Note, page 7 of the KAP140 Pilot's Guide shows a pitch servo and a pitch trim servo as well as a manual electric trim switch on the yoke. There would be no pitch servo if the autopilot were "flying" the pitch with the pitch trim. But then there would be interesting that the yoke, the pedals would not produce interferences with the autopilot, because in a real plane, the yoke moves when autopilot changes the pitch, but in flightgear it is not possible because of the lack of force feedback in almost all yokes and pedals in the market. So I suggest that FlightGear could remember the last yoke and pedals position and do not apply its values with the autopilot engaged when the values of this devices didn't have changed. If not, whith the original KAP140 config file, the plane is doing a lot of hard turns because the program applies autopilot's values and eventually yoke and pedals values too. Do you agree with this reflexion? If you do, do you think it would be very difficult implementing this solution? I ask it because I have almost started looking at the code, and I do not know how things operate in FlightGear yet. For the moment using trim for autopilot makes the fly more acurate because it does not interfere with input devices. If this problem can not be solved in FlightGear, I will remain with my config file, because I suffer very much when I connect autopilot for making a rest and it starts doing very hard turns and plane's yoke vibrates a lot. Do you suffer this effects too? Note also item 15 on page 85. "A flashing PT with arrows indicates the direction of required pitch trim." The pilot does not have the feel to set the trim, since the pitch servo is carrying the out-of-trim load on the yoke that the pilot would have to carry, were the AP not there. The PT annunciator provides this "feel" feedback. Also see page 89, voice message 2. If the autopilot were flying the pitch via pitch trim, this warning would be meaningless. It is especially important to pay attention to the PT annunciator (and correct any out-of-trim condition) when the GS is acquired. Otherwise, you will have a very nasty surprise near the ground when you disengage the autopilot (at or before the decision height is reached) with a significant out-of-trim condition. This has caused crashes for real. I recall reading a NTSB report for a Martin 404 crash caused by the pilot not noticing a stuck electric trim switch leaving the pitch trim in full down and then disengaging the autopilot at altitude. The ac tried to do an outside loop. I understand. But my trim indicator goes up and down all the time because of the effect I have exposed before. Also I am interested in the opinion of any pilot that has flown a > real Cessna and remembers the real autopilot performing. > I have not flown any Cessna autopilots, but I have flown several hi-performance Piper aircraft that have similar autopilots. The above comments agree with that experience. Does in the real Piper improve the performance of the KAP140 compared to FlightGear's one or it performs in a similar manner. I use FlightGear as a preparation for learning to fly before I start flying one day in real life, because it is my passion. I want to acquire some experience and I appreciate the more realistic experience with FlightGear. I added the KAP140 to the pa24-250 in FlightGear. I have done a number of ILS approaches in the fgfs pa24-250 using the KAP140. It does an adequate job down to just before the DH is reached. It does seem to "chase" the GS a bit more than I would expect from real experience for the last mile before the DH is reached. I solved it incrementing the proportional gain (Kp) from 2 to 3 in the KAP140.xml file. Can you test if this works for you and if it makes this autopilot more realistic? For whatever reason, the KAP140 gives more realistic performance in the pa24 than in the c172
Re: [Flightgear-devel] out-of-date mailing-list addresses
On 01/02/2007 04:53 PM, Curtis Olson wrote: > -- http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > > I have taken care of the first one ... didn't know google was still > showing it in searches. That doesn't really solve the users' problem. Look at it from the naive users' point of view: 1) Google still points to the URL given above. 2) The URL given above doesn't solve the users' problem. 3) The error message on that document is unhelpful. It does not give the users even a hint as to how to solve the problem. Constructive suggestion: on the flightgear site, in the mailman directory, there could be a .htaccess file containing the following line: Redirect permanent /mailman/listinfo/flightgear-devel http://sourceforge.net/mailarchive/forum.php?forum_id=1919 (That looks like two lines in the email, but it needs to be one line in the .htaccess file.) This means that 1) Google will rather soon figure out it should point to the sourceforge list. When google receives an HTTP 301 Moved Permanently result, google is persuaded by it. Google is not persuaded by much else. 2) Any users -- no matter how naive -- who try to look at the wrong site will be sent to the right site automagically. This works no matter how they got there: via google, via out-of-date bookmark, via out-of-date link from another page ... whatever. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
