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 c172p. I did not include
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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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 deg; 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 offset180/offset and offset/environment/magnetic-variation-deg/offset 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.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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 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 offset.../offset 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 offset.../offset 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.phpp=sourceforgeCID=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
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.phpp=sourceforgeCID=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 fgfs.mail.list.fix.diff ' 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 flightgear-devel@flightgear.org. +Send bug reports to flightgear-devel@lists.sourceforge.net. .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 flightgear-devel@flightgear.org. +Send bug reports to flightgear-devel@lists.sourceforge.net. .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 flightgear-devel@flightgear.org. +Send bug reports to flightgear-devel@lists.sourceforge.net. .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 flightgear-devel@flightgear.org. +Send bug reports to flightgear-devel@lists.sourceforge.net. .SH SEE ALSO fgfs(1) .SH AUTHORS diff -ru
[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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
