Re: [Flightgear-devel] Autopilot GUI
Steve Knoblock wrote: Perhaps the autopilot element could include the location of the Autopilot dialog. Then if the default was loaded it would just load the existing dialog. If a location was specified, then it would load the custom dialog. Something like systems autopilot pathAircraft/c172p/Systems/KAP140.xml/path gui-dialogAircraft/c172p/Systems/KAP140-dialog.xml/gui-dialog /autopilot Just my EUR 0.02: If possible (I've not looked at NASAL scripting yet) he auto pilot dialog should be defined in the autopilot definition itself. So if an aircraft does not have an autopilot there would automatically be no autopilot dialog. If an aircraft uses the default autopilot it's dialog is displayed, likewise for a special autopilot. This asumes that menus can be changed dynamically by NASAL scripts like e.g. Mozilla's can through overlays. If not, I think this capability should be added anyway and then used for the autopilot dialog and any other dialog that may be specific to an aircraft (like fuel and payload). Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Autopilot GUI
I decided to look more closely at autopilot behavior after hearing that one could direct the Wright Flyer on autopilot. Here is the results, with a discussion afterward about the Autopilot GUI dialog. * Wright Flyer does follow the default autopilot if settings are made on the Autopilot dialog. The config (-set.xml) file does not specify settings for the default autopilot or even a SYSTEMS container. The FDM is 'larcsim' * J3Cub also follows the default autopilot if settings are made through the Autopilot dialog. The config file does specify an autopilot element and several settings are defined. However, it does not specify an autopilot in the SYSTEMS container. The FDM is 'yasim' * Cessna 172p does not follow any settings made through the Autopilot dialog. The config file specifies a SYSTEMS container. The FDM is 'jsb' Looking at the contents: J3Cub: systems electrical pathAircraft/j3cub/cub-electrical.xml/path /electrical /systems Cessna: systems autopilot pathAircraft/c172p/Systems/KAP140.xml/path /autopilot electrical !-- null electrical system path here so we can use a nasal based -- !-- model defined later in the nasal section of this file. -- path/path /electrical /systems From this, I conclude * An aircraft that does not specify autopilot as a system uses the default autopilot. * An aircraft that specifies an autopilot uses the specified autopilot in place of the default autopilot. These rules explain the behavior of the Cessna. Because it specifies an autopilot, the default autopilot is either overridden or never loaded. The NASAL scripted autopilot is loaded. Therefore, the Autopilot dialog has no effect on the aircraft. Looking at the gui code for the Autopilot dialog (autopilot.nas and autopilot.xml), they both modify properties belonging to the default autopilot: /autopilot/* As far as I know, the C code that used to be default autopilot has been completely replaced by a PID controller configuration. Given the presence of 'generic-autopilot.xml' in the Generic folder under Aircraft, my guess is that when the SYSTEM does not specify an AUTOPILOT, this is loaded instead. This is where you specify a PID controller part of the autopilot system (the panel interface and scripts are other files). One might be tempted to say that all autopilots should use the same standard autopilot properties. On the other hand, there always seem to be features that are not covered by a set of generic autopilot settings. I am unsure if there is any chance for confusion if one did try to use the same properties, given that it seems only one autopilot can be loaded at one time. It may be best if each autopilots defines its own internal property space. That leaves the Autopilot dialog. The simplest way for a Autopilot dialog to work is if the properties are standard and shared by all autopilots. There would need to be some sort of flag property to tell if an aircraft has an autopilot, but other than that the dialog would be the same. On the other hand, if autopilots come with a variety of settings not found in the generic dialog, then it would be preferable to have some system where the autopilot can replace the Autopilot dialog with one of its own or add its own dialog in. I suppose one way to look at the existing autopilot as if it were the same as an add on like the KAP140, only it just is there by default. It has a config file and its own gui dialog, just as say, the Digitrak I built does, and could be built for the KAP140. The only difference is that the Autopilot dialog is _always displayed_. I suppose it comes down to saying there will only be one autopilot dialog and forcing all autopilot code to interface to it, or someway of specifying a dialog for each autopilot. If no autopilot is specified on the aircraft, the dialog should not display at all, not even the default. As has been suggested, another solution is to create a NULL autopilot for aircraft that do not need one. This would be an autopilot config file, I suppose, with PID controllers that do nothing or just empty? Not sure. That still leaves the question of the autopilot dialog open. It would still be there and mysteriously not do anything. There needs to be a way of telling the GUI that autopilot is not supported on this aircraft, so don't display it. It is relatively simple to determine whether to show the Fuel and Payload dialog. It appears only one FDM supports fuel and payload 'yasim', which if not found, an unsupported message is displayed. However, we do not want to prohibit an aircraft from having an autopilot merely because one might think it improbable. It used to be true that fitting an autopilot to very small aircraft like the J3Cub was impossible, but with digital systems like the Digitrak, the mechanism is much less complicated and the control much more capable, so even a J3Cub might be retrofitted with an autopilot. I'd even give the Wright Flyer half
Re: [Flightgear-devel] Autopilot
On Wed, 2005-11-30 at 16:55, Jon Stockill wrote: Steve Hosgood wrote: 3) It was broken in 0.9.8 but is fixed now. I *think* I may have tried it in 0.9.9 with the same results. Not sure. Can't check right now. It'll still be the same. The C172 doesn't use the generic autopilot code - it has a KAP140 autopilot model - which is controlled by clicking the buttons on the device in the cockpit. Others wrote with much the same info. Guys, this is a 1.0.0 killer. I knew there was an autopilot on the cockpit display, but on my monitor at home (1024x768) it was a bit difficult to read. So, like any random punter would, I figured that the (fully functioning) autopilot dialog box would be an alternative interface to the *same bloody autopilot*. Not so, it appears. If we want to have FG 1.0.0 laughed at by one and all on release day, this is the way to go. Pleeese fix it? Can anyone else point out instances where a non-greyed-out menu item or dialog box offers what looks like an alternative UI for a cockpit instrument, but actually does nothing of the sort? Any other related inconsistencies? Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
On Thursday 01 December 2005 09:48, Steve Hosgood wrote: I knew there was an autopilot on the cockpit display, but on my monitor at home (1024x768) it was a bit difficult to read. This is a problem for many instruments in many a/c - on higher resolution screens too. The solution is to make frequent use of the FOV keys and the mouse controlled view direction - in other words, look at the relevant instrument with the mouse and zoom in a little with the x key. Usually, you can find a balance between keeping some kind of visual reference to what the a/c is doing and being able to see the particular instrument or device clearly enough to use. With a little practice, this becomes almost automatic. Outside of a clever head and eye tracking system, I doubt there's a much better way of replicating what your eyes and visual processing systems do so effortlessly IRL. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Autopilot
Folks, was there a bug in the autopilot on the c172 default airplane in 0.9.8? I fill in the fields and tick the boxes on the Autopilot dialog box, take my hands off the stick and the bloody thing wanders all over the sky. 1) Maybe this is an accurate model of the c172 autopilot? :-) or 2) Maybe the c172 doesn't have an autopilot. If the latter, then surely the dialog box ought not to be available (i.e be greyed out in the relevant menu). or (I suppose) 3) It was broken in 0.9.8 but is fixed now. I *think* I may have tried it in 0.9.9 with the same results. Not sure. Can't check right now. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
Steve Hosgood wrote: 3) It was broken in 0.9.8 but is fixed now. I *think* I may have tried it in 0.9.9 with the same results. Not sure. Can't check right now. It'll still be the same. The C172 doesn't use the generic autopilot code - it has a KAP140 autopilot model - which is controlled by clicking the buttons on the device in the cockpit. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
-- Steve Hosgood wrote: Folks, was there a bug in the autopilot on the c172 default airplane in 0.9.8? I fill in the fields and tick the boxes on the Autopilot dialog box, take my hands off the stick and the bloody thing wanders all over the sky. IIRC the C172p uses the KAP140 (or somesuch) autopilot instead of the default one, and so the Autopilot dialog doesn't work. Instead, you access the autopilot through the panel/3D cockpit. -Stuart ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
On Wednesday 30 November 2005 17:34, Steve Hosgood wrote: or 2) Maybe the c172 doesn't have an autopilot. It has an autopilot, but you operate it with buttons on the panel, you know, like in Real-Life[TM]. If the latter, then surely the dialog box ought not to be available (i.e be greyed out in the relevant menu). Is this possible, Melchior, to disable the autopilot menu entry just for the C172? I think it's the right thing to do, besides adding a big plackard with RTFM next to the autopilot on the panel ;-) Seriously, you really need to read the Pilots Guide for the KAP140 to operate it. It is available for download from the Bendix/King website (Warning: it's huge! about 12MB) https://www3.bendixking.com/servlet/com.honeywell.aes.utility.PDFDownLoadServlet?FileName=/TechPubs/repository/006-18034-_2.pdf -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
--- Roy Vegard Ovesen wrote: If the latter, then surely the dialog box ought not to be available (i.e be greyed out in the relevant menu). Is this possible, Melchior, to disable the autopilot menu entry just for the C172? Thanks the Melchior's XML menu changes, I would think the .nas file for the KAP140 should be able to disable the appropriate parts of the menu tree dynamically when initialized. Or (better), it could replace them with an appropriate menu UI, for those who don't want to use the panel. -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Autopilot questions
Hey gang, I'm starting to prepare to integrate Flight Gear as a surrogate for a real UAV as part of a UAV control system that I'm developing. We've looked at several other simulators, but FG seems to be the best one for the job at hand. I do have several questions though about the autopilot system that I was hoping somebody could answer. Specifically, it seems (through my experimentation on 0.9.8) that some aircraft have more robust APs than others. For instance, the F-16 model shows on the display the next WP. Others don't show anything. Some seem to handle the WP following system, others don't. What we're specifically looking for is (at a minimum) a single engine (preferably prop, or better yet Helo in lieu of a real UAV model which nobody seems to have built yet for FG) aircraft model that can do a combination of altitude + speed holds, as well as auto fly from current location to a specific lat/long waypoint. There has been some discussion in my group as to the possible need to have a full flightplan (series of waypoints) that we could send to the sim to fly in order, but we don't think we need that at the current time. Instead we're probably going to do a fly to here, monitor the aircraft position, when we get there tell it to now fly to there, repeat... type control. We're doing our interfacing with FG through the Java telnet interface, so I'll need to know what parameters I need to modify to do each of those autopilot things. Any help is appreciated! --Mike Mike Kopack ISX Corporation 1800 Parkway Place Suite 900 Marietta, GA 30067 678-581-2025 [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
On Fri, 27 May 2005 15:26:58 -0500, Curtis wrote in message [EMAIL PROTECTED]: Vance Souders wrote: I want to implement an acrobatic AI autopilot and was debating a few different ways of tackling the problem. I was thinking of either creating a spline based system or tuning the current autopilot to fit my needs. In a spline based system, the user can sit in the cockpit as the plane flies the spline if I do it this way, I would ignore the FDM and provide the gauges with bogus data that would most likely be interpolated from values specified at nodes along the spline. It seems to me that the spline system would be easier than getting the autopilot to do exactly what I need (precision formation flying, landing, taxiing). Im still investigating different ways of handling this, so Im open to any suggestions people can provide. I think it all boils down to what you want to accomplish. If you just need to see the aircraft going through the desired path then you could fake it ... but an autopilot that knows how to fly aerobatics would also be a really interesting project to tackle. It all depends on what you want to get out of it as the end result. ..I read him as wanting to do a RC F3A etc pattern work autopilot, this can both drift with the wind, and crab upwind to stay in the box, say taking a tournament program as input and just fly it, some guys fly these for a living. I managed to get my part of such a tournament at least as expensive, I shut down town, as in half of the city. ;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. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Autopilot
I want to implement an acrobatic AI autopilot and was debating a few different ways of tackling the problem. I was thinking of either creating a spline based system or tuning the current autopilot to fit my needs. In a spline based system, the user can sit in the cockpit as the plane flies the spline if I do it this way, I would ignore the FDM and provide the gauges with bogus data that would most likely be interpolated from values specified at nodes along the spline. It seems to me that the spline system would be easier than getting the autopilot to do exactly what I need (precision formation flying, landing, taxiing). Im still investigating different ways of handling this, so Im open to any suggestions people can provide. Thanks, Vance ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
Vance Souders wrote: I want to implement an acrobatic AI autopilot and was debating a few different ways of tackling the problem. I was thinking of either creating a spline based system or tuning the current autopilot to fit my needs. In a spline based system, the user can sit in the cockpit as the plane flies the spline if I do it this way, I would ignore the FDM and provide the gauges with bogus data that would most likely be interpolated from values specified at nodes along the spline. It seems to me that the spline system would be easier than getting the autopilot to do exactly what I need (precision formation flying, landing, taxiing). Im still investigating different ways of handling this, so Im open to any suggestions people can provide. I think it all boils down to what you want to accomplish. If you just need to see the aircraft going through the desired path then you could fake it ... but an autopilot that knows how to fly aerobatics would also be a really interesting project to tackle. It all depends on what you want to get out of it as the end result. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Autopilot oscillation
Ive written a small class to load waypoints into the autopilot from an XML file. Its working but the aircraft will severely oscillate on occasion. Any ideas where I should start to minimize the oscillations? Thanks, Vance ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Autopilot waypoints
Is there a way to specify autopilot waypoints via an XML configuration file? Thanks, Vance ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Autopilot bug?
Hi, I have tried the altitude and heading hold features of the autopilot (ctrl-A and ctrl-H with arrow keys or F11 autpilot dialog box). They work very well with j3cub aircraft but with the default cessna 172 either of them don't work at all. I suppose this is a bug. -Timo ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot bug?
Timo Saarinen wrote: Hi, I have tried the altitude and heading hold features of the autopilot (ctrl-A and ctrl-H with arrow keys or F11 autpilot dialog box). They work very well with j3cub aircraft but with the default cessna 172 either of them don't work at all. I suppose this is a bug. The particular autopilot included with the default C172 (KAP-140) must be operated by clicking on the panel buttons. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot bug?
On Tuesday 05 April 2005 21:22, Curtis L. Olson wrote: Timo Saarinen wrote: Hi, I have tried the altitude and heading hold features of the autopilot (ctrl-A and ctrl-H with arrow keys or F11 autpilot dialog box). They work very well with j3cub aircraft but with the default cessna 172 either of them don't work at all. I suppose this is a bug. The particular autopilot included with the default C172 (KAP-140) must be operated by clicking on the panel buttons. Shouldn't the keyboard controls and the dialog be disabled then? Of course it would be nice to get some kind of message that you must operate the panel with mouse instead of the standard keyboard shortcuts. -Timo ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] autopilot error ?
Hello, with the default c172 I see this error: Reading autopilot configuration from /home/mas/CVS/FlightGear/data/Aircraft/c172p/Systems/KAP140.xml Unknown top level section: filter Detected an internal inconsistancy in the autopilot configuration. See earlier errors for details. Deleting a sample JSBSim startup complete [ the End ] I believe this was introduced about 20 days ago. Can anyone confirm ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] autopilot error ?
On Thursday 04 November 2004 12:21, Martin Spott wrote: Hello, with the default c172 I see this error: Reading autopilot configuration from /home/mas/CVS/FlightGear/data/Aircraft/c172p/Systems/KAP140.xml Unknown top level section: filter Detected an internal inconsistancy in the autopilot configuration. See earlier errors for details. Do you have the latest CVS? Filters were added to xmlauto.*xx mid October: http://baron.flightgear.org/pipermail/flightgear-cvslogs/2004-October/008703.html The KAP140 autopilot was updated a couple of days later: http://baron.flightgear.org/pipermail/flightgear-cvslogs/2004-October/008753.html So if you have a recent build it should recognize the filter tag in autopilot configurations. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] autopilot error ?
Roy Vegard Ovesen wrote: Do you have the latest CVS? Filters were added to xmlauto.*xx mid October: http://baron.flightgear.org/pipermail/flightgear-cvslogs/2004-October/008703.html That's it. I already removed anything with '*kap140*' in the filename and pulled a fresh version from CVS. After I did the same with the 'xmlauto*' files as well I managed to build a binary that doesn't crash. Thanks, Martin. P.S.: I always find it interesting that it is not sufficient to maintain a source tree with 'cvs update' -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] autopilot error ?
On Thursday 04 November 2004 15:21, Martin Spott wrote: Roy Vegard Ovesen wrote: Do you have the latest CVS? Filters were added to xmlauto.*xx mid October: http://baron.flightgear.org/pipermail/flightgear-cvslogs/2004-October/008 703.html That's it. I already removed anything with '*kap140*' in the filename and pulled a fresh version from CVS. After I did the same with the 'xmlauto*' files as well I managed to build a binary that doesn't crash. So... problem solved, or? Thanks, Martin. P.S.: I always find it interesting that it is not sufficient to maintain a source tree with 'cvs update' I have used 'cvs -z3 up -dPA' with great success when I update. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] autopilot error ?
Roy Vegard Ovesen wrote: So... problem solved, or? Yep - thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
[EMAIL PROTECTED] wrote: Isn't it more apropriate to have a multidimentional PID c ntroller rather than multipl 1 dimentional PID controllers? Or is that just the same? I'm not sure what you mean by multidimentional PID controller, but I believe that that it would be the same as multiple one dimentional PID controllers. The one described is one dimentional because all variables are scalars. In a multidimentional version the target, input and output would be vectors and gains matrices. With the matrices you should be able to express interaction between the components. e.g. as you said rudder and ailerons have overlapping effects. I'd say with two 1-dimenational controllers you ignore that fact and get imperfect results. What is the benefit of cascading PID controllers? Lets look at an autopilot that is supposed to steer the aircraft towards the heading bug. Suppose that the only thing we can man pulate is the aileron. Obviously we need a PID controller with aileron as its output. We choose roll angle as input. Now we can set the reference to say 20 degrees, and a properly tuned PID controller will hold a 20 degree roll angle. But how do e get it to steer towards the heading but? One solution is for the pilot to set the reference roll angle apropriately so that the aircraft steers toward the heading bug. Another is to let another PID controller set the reference roll angle. The outp t of this controller is then connected to the reference of the first controller. This is what we call a cascade configuration. For this example the benefit is that, well without cascading we wouldn't be able to do what we wanted (steer towards the h ading bug). For situations where cascading is not required, it can still be used and might give a more robust or smoother control loop. could you not take the heading as input and aileron controll as output directly, since the effect of the ailerons (roll) is directly connected to change of heading. Birger signature.asc Description: OpenPGP digital signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot
-- Original Message -- Date: Tue, 13 Jul 2004 18:57:13 +1200 From: Birger Brunswiek To: FlightGear developers discussions [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Autopilot Reply-To: FlightGear developers discussio s [EMAIL PROTECTED] rvovesen wrote: Isn't it more apropriate to have a multidimentional PID c ntroller rather than multipl 1 dimentional PID controllers? Or is that just the same? I'm not sure what you ean by multidimentional PID c ntroller, but I believe that that it would be the same as multiple one dimentional PID controllers. The one described is one dimentional because all variables are scalars. In a multidimentional version the target, input and output would be vect rs and gains matrices. With the matrices you should be able to express interaction between the components. e.g. as you said rudder and ailerons have overlapping effects. You mean a state-space form?!: x' = x + Bu y = Cx + Du I think that would make the autopilot-configuration a bit more complicated. One of the things that was requested on this list when we redone the autopilot system was that it had to be simple to configure. For the state-sp ce form one would require a matematical model of the aircraft, the A matrix. With PID controllers you don't need matematical models. Since every aircraft have different matematical models, that would add to the complexity of configuring the autopilo . I'd say with two 1-dimenational controllers you ignore that fact and get imper ect results. Yes, since we don't have a matematical model to help us out, we ignore that fact. But we still know, in our head, that rudder and aileron interact and consequently we tune the two PID controllers in a slightly different way. So in theory we ignore it, but in pactice we consider it. could you not take the heading as input and aileron controll as output directly, since the effect of the ilerons (rol ) is directly connected to change of heading. Pleasy try it out! ;-) I guess that you will learn that as the controller demands full aileron deflection, the aircraft will roll, roll and roll until it's inverted, and it won't stop t ere, it will continue to roll. And the aircraft will return to almost the same heading as it had befor the roll started. :-( Back to the state-space form. There is nothing stopping you from implementing a state-space form to the existing autopi ot code. The source files to look for are xmlauto.* in the autopilot subdir. If you think that a multidimentional state-space model would give better performance than the PID controllers, go ahead! I also think that it would give better performa ce, and I would gladly help you in implementing. -- Roy Vegard Ovesen -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot
-- Original Message -- Date: Mon, 12 Jul 2004 12:09:04 +1200 From: Birger Brunswiek To: FlightGear developers discussions [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Autopilot Reply-To: FlightGear developers discussions [EMAIL PROTECTED] ver these books which I'm going to get from the library: (name and ISBN) PID controllers / by Karl J. ?str?m and Tore H?gglund. 1556175167 Adaptive Control (2nd Edition) 0201558661 Control Theory : Multivaria le Nonlinear Methods 0748408789 The Control Handbook 0849385709 Handbook of PI and PID controller tuning rules / Aidan O'Dwyer. 1860943500 Digital Control of Dynamic Systems (3rd Edition) 0201820544 Advanced Control Unleashed: Plant Performance Management for Optimum Benefit 1556178 58 Control Systems Engineering 0471445770 I'll add one of the textbooks that I used in my education: Process dynamics and control 0471863890 Isn't it more apropriate to have a multidimentional PID c ntroller rather than multipl 1 dimentional PID controllers? Or is that just the same? I'm not sure what you mean by multidimentional PID controller, but I believe that that it would be the same as multiple one dimentional PID controllers. If we look at multivariable control, where we have multiple inputs and multiple outputs, we still use one PID controller for for each input-output pair. Consider an autopilot that is supposed to control the ailerons and the rudder. We know from experie ce (and probably from theory) that an aileron deflection will result in a roll, and that a rudder deflection result in a yaw, but also in a roll. Aileron deflection also result in a yaw, but I guess not as much as rudder deflection. So we have tw inputs: aileron and rudder, and two outputs: roll and yaw. Theese variables are not independent, the aileron does not only control roll, and the rudder does not only control yaw. They both interact. Of course the aileron controls roll much more tha it controls yaw and the rudder controls yaw more than it controls roll. So our two PID controllers would be: one with roll as input and aileron as output, and one with yaw as input and rudder as output. This might seem obvious, but still one should know the theory behind and note that it also makes sense in theory. When it comes to tuning the two PID controllers, one has to keep in mind that they interact. In general more conservative controller settings must be used, but I guess you'll fin more on multivariable controller tuning in one of the books :-) What is the benefit of cascading PID controllers? Lets look at an autopilot that is supposed to steer the aircraft towards the heading bug. Suppose that the only thing we can man pulate is the aileron. Obviously we need a PID controller with aileron as its output. We choose roll angle as input. Now we can set the reference to say 20 degrees, and a properly tuned PID controller will hold a 20 degree roll angle. But how do e get it to steer towards the heading but? One solution is for the pilot to set the reference roll angle apropriately so that the aircraft steers toward the heading bug. Another is to let another PID controller set the reference roll angle. The outp t of this controller is then connected to the reference of the first controller. This is what we call a cascade configuration. For this example the benefit is that, well without cascading we wouldn't be able to do what we wanted (steer towards the h ading bug). For situations where cascading is not required, it can still be used and might give a more robust or smoother control loop. -- Roy Vegard Ovesen -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autopilot
I have found this to be an excellent reference most of which is directly applicable to aircraft. MANEUVERING AND CONTROL OF MARINE VEHICLES by Michael S. Triantafyllou and Franz S. Hover Department of Ocean Engineering Massachusetts Institute of Technology Cambridge, Massachusetts USA http://ocw.mit.edu/OcwWeb/Ocean-Engineering/13-49Maneuvering-and-Control-of-Surface-and-Underwater-VehiclesFall2000/LectureNotes/ Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] autopilot properties
What is the difference in these properties? /autopilot/route-manager/wp-last/id ='' (none) /autopilot/route-manager/wp/id = 'KANP' (string) /autopilot/settings/route-manager/wp/id ='KGAI' (string) They seem to be overshadowing each other. Have some of these been superceeded by the new route-manager code? Which one is the official next waypoint? (Or is it some artifact of nasal generating new branches of the property tree?) Or yet, is mucking with the property tree via fgTie/xxSet/xxGet the proper way to change these, or would a better method be via a nasal script, for example, that calls something like: autopilot.update(hdg-true) If so, then how does an external program call a nasal script to change things (like the telnet interface does)? Wendell - Friends don't let friends squawk 1200. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot
[EMAIL PROTECTED] wrote: A Google search for pid control gives some useful tutorials on what pid is. doh... yes I must have overlooked them before ;-) but actually I was looking at a more in-depth description. On my way I came across over these books which I'm going to get from the library: (name and ISBN) PID controllers / by Karl J. Åström and Tore Hägglund. 1556175167 Adaptive Control (2nd Edition) 0201558661 Control Theory : Multivariable Nonlinear Methods 0748408789 The Control Handbook 0849385709 Handbook of PI and PID controller tuning rules / Aidan O'Dwyer. 1860943500 Digital Control of Dynamic Systems (3rd Edition) 0201820544 Advanced Control Unleashed: Plant Performance Management for Optimum Benefit 1556178158 Control Systems Engineering 0471445770 One important thing to note is that to make a fairly complete autopilot you need several pid controllers. One pid controller can only control one flight control, for example the elevator. Another has to control the ailerons. Often you need a pid controller to control the pid controller that controls the elevator. This is called a cascade configuration. Isn't it more apropriate to have a multidimentional PID controller rather than multiple 1 dimentional PID controllers? Or is that just the same? (I'd guess it's not the same...) What is the benefit of cascading PID controllers? Birger ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autopilot
Reading the autopilot documentation I find that the step from the PID controller described to the one actually implemented quite big ... The algorithm described here: http://www.flightgear.org/Docs/XMLAutopilot/node3.html is the one that is implemented. Can the guys who have worked on that perhaps point me to a pile of books of webpages I should read to get a bet er understanding of it? I haven't couldnt find much usefull information myself. A Google search for pid control gives some useful tutorials on what pid is. One important thing to note is that to make a fairly complete autopilot you need several pid controllers. One pid controller can only control one flight control, for example the elevator. Another has to control the ailerons. Often you need a pid controller to control the pid controller that controls the elevator. This is called a cascade configuration. -- Roy Vegard Ovesen -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Autopilot
Reading the autopilot documentation I find that the step from the PID controller described to the one actually implemented quite big ... Can the guys who have worked on that perhaps point me to a pile of books of webpages I should read to get a better understanding of it? I haven't couldnt find much usefull information myself. Thanks in advance ... Birger signature.asc Description: OpenPGP digital signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] autopilot and route-manager
Is there an autopilot that still uses the /autopilot/settings/waypoint method of setting waypoints? (i.e., one that can accept modifications to the waypoint list via the telnet interface)? Or has that been replaced with /autopilot/route-manager/wp/id ? If so, how does an external program (currently telnet, not nasal) modify the waypoint via the route-manager method? (The old way worked fine in earlier versions of fgfs.) Setting the wp/id seemed to have no effect on the route being flown. Wendell ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot fun
Lee Elliott wrote: On Monday 22 March 2004 16:01, Martin Spott wrote: Try this: Choose the YF-23, start FlightGear, set the autopilot for altitude (1000+ ft) and heading in the first step, set speed (some 350 kts) as a second step and watch a wild horse riding through the air :-) The latest YF-23 pending update (note name change from 'yf23') has an auto take-off function in the AP that does pretty much that just by selecting 'TO' mode. Great, the autopilot behaves much calmer than the previous one, although it still starts to oscillate a bit when I exceed 650 kts, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot fun
Lee Elliott wrote: Ta for pointing out the high-speed oscillation problem - I've got to confess that all the recent AP changes were only tested at relatively low speeds i.e. flying circuits to check take-offs landing. I'll have a look into it. When you're done with that I'll send you my suggestions for auto-landing (despite the fact that I suspect auto-landing to be really boring ;-)) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot fun
Martin Spott said: Lee Elliott wrote: Ta for pointing out the high-speed oscillation problem - I've got to confess that all the recent AP changes were only tested at relatively low speeds i.e. flying circuits to check take-offs landing. I'll have a look into it. When you're done with that I'll send you my suggestions for auto-landing (despite the fact that I suspect auto-landing to be really boring ;-)) Hehe...well actually it is pretty exciting from an engineering perspective ;-) For the oscillations, it seems that using the PI simple controller setup fixed this issue in the 747...althought I would have to do a lot more testing at various altitudes and mach numbers to be sure that it is indeed fixed. One thing is that in some cases the 747 would climb to altitude and level off at a stable cruise, but things like turbulance and/or entering a command to change altitude would introduce the porpoising. To test for that quickly, I get the aircraft cruising nice and smooth, then pull the stick all the way back for a couple seconds and let it go (this is a joystick so it springs back to neutral). If things are ok the upset aircraft will stabilize in just a few seconds. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot fun
On Tuesday 23 March 2004 22:28, Martin Spott wrote: Lee Elliott wrote: Ta for pointing out the high-speed oscillation problem - I've got to confess that all the recent AP changes were only tested at relatively low speeds i.e. flying circuits to check take-offs landing. I'll have a look into it. When you're done with that I'll send you my suggestions for auto-landing (despite the fact that I suspect auto-landing to be really boring ;-)) Martin. It's not boring - it's an interesting problem:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Autopilot fun
Try this: Choose the YF-23, start FlightGear, set the autopilot for altitude (1000+ ft) and heading in the first step, set speed (some 350 kts) as a second step and watch a wild horse riding through the air :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot fun
On Monday 22 March 2004 16:01, Martin Spott wrote: Try this: Choose the YF-23, start FlightGear, set the autopilot for altitude (1000+ ft) and heading in the first step, set speed (some 350 kts) as a second step and watch a wild horse riding through the air :-) Martin. The latest YF-23 pending update (note name change from 'yf23') has an auto take-off function in the AP that does pretty much that just by selecting 'TO' mode. It does wallow a bit, at first though. The take-off sequence finishes by leaving the a/c in a mach-hold climb. trouble is that the last time I tried it, it was at 100,000ft and still climbing at 50ft/s - whoops:( You shouldn't need to set anything else, although you can set a series of waypoints as long as you hit ctrl-h a couple of times to disable true-heading-mode beforehitting 'TO'. It'll switch to the waypoints, if set, after it's finished it's initial climb-out. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot fun
Lee Elliott wrote: The latest YF-23 pending update (note name change from 'yf23') has an auto take-off function in the AP that does pretty much that just by selecting 'TO' mode. Hey, I thought, all these near-ground automatisms are for wimps o.k., I admit being a wimp and will try this out ;-) Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AUTOPILOT
Thanks Roy I will do some reading. Cheers Innis Roy Vegard Ovesen writes Browse to: http://www.flightgear.org/Docs/XMLAutopilot/ There is a generic autopilot in the data/Aircraft/Generic folder. This should become apparent when you read the docs and the generic example. You have to get the bindings right in the instrument xml file(s). The generic autopilot is accessible from the autopilot-menu. Here you can de-/activate the various modes. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ SEEK: Now with over 50,000 dream jobs! Click here: http://ninemsn.seek.com.au?hotmail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AUTOPILOT
Thanks David Do I only need to rebuild FG for this to take effect. Cheers Innis David Culp writes The new autopilot is in CVS as of today. Try it out. Some of it works, some doesn't, but we might be able to get it finished before the release. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Find love today with ninemsn personals. Click here: http://ninemsn.match.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AUTOPILOT
Innis Cunningham said: Thanks David Do I only need to rebuild FG for this to take effect. Cheers Innis David Culp writes The new autopilot is in CVS as of today. Try it out. Some of it works, some doesn't, but we might be able to get it finished before the release. Hi Innis, FYI, I think what David meant to say is he checked in to cvs a start on a new 737 autopilot configuration. So you might want to look at that too. That would require just a base package update assuming you are running code built within the last two or three weeks. Otherwise, yes rebuild (not a bad idea anyway). Check this cvs log entry: http://baron.flightgear.org/pipermail/flightgear-cvslogs/2004-March/007114.html Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AUTOPILOT
Thanks Jim As I am not very strong with this CVS stuff.I realised after I posted that all I had to do was update my CVS base as my build is only about 5 days old. Cheers Innis Jim Wilson writes Hi Innis, FYI, I think what David meant to say is he checked in to cvs a start on a new 737 autopilot configuration. So you might want to look at that too. That would require just a base package update assuming you are running code built within the last two or three weeks. Otherwise, yes rebuild (not a bad idea anyway). Check this cvs log entry: http://baron.flightgear.org/pipermail/flightgear-cvslogs/2004-March/007114.html Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ We've 100s of NEW questions! Play Millionaire online to win . Click here http://sites.ninemsn.com.au/minisite/millionaire/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] AUTOPILOT
Hi Guys I wonder if someone could tell me were I can find the instructions for the new autopilot system so I can redo the 737 autopilot to work. If someone has built an autopilot with the new system could they tell me the xml file so I might get an idea how it is done. Or is there a key press to activate the autopilot using the generic autopilot xml. What I would like to know is how I get the switches like Heading,Vor/loc,Approach and the like to work now. Cheers Innis _ Personalise your phone with chart ringtones and polyphonics. Go to http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AUTOPILOT
I wonder if someone could tell me were I can find the instructions for the new autopilot system so I can redo the 737 autopilot to work. The new autopilot is in CVS as of today. Try it out. Some of it works, some doesn't, but we might be able to get it finished before the release. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AUTOPILOT
On Fri, 12 Mar 2004 21:33:04 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: Hi Guys I wonder if someone could tell me were I can find the instructions for the new autopilot system so I can redo the 737 autopilot to work. Browse to: http://www.flightgear.org/Docs/XMLAutopilot/ If someone has built an autopilot with the new system could they tell me the xml file so I might get an idea how it is done. There is a generic autopilot in the data/Aircraft/Generic folder. Or is there a key press to activate the autopilot using the generic autopilot xml. What I would like to know is how I get the switches like Heading,Vor/loc,Approach and the like to work now. This should become apparent when you read the docs and the generic example. You have to get the bindings right in the instrument xml file(s). The generic autopilot is accessible from the autopilot-menu. Here you can de-/activate the various modes. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] autopilot nav1 heading problem
Somehow I need to incorporate distance (from the transmitter) into the the
nav1 heading control, or find another way to solve the same problem. As you
get closer to the target, the cone gets narrower, but more important is that
the size of adjustments to correct for a give angle error become smaller.
In the old autopilot I corrected for this with the following code:
// clamp closer when inside cone when beyond 5km...
if (current_radiostack-get_navcom1()-get_nav_loc_dist() 5000) {
double clamp_angle =
fabs(current_radiostack-get_navcom1()-get_nav_cdi_deflection()) * 3;
if (clamp_angle 30)
SG_CLAMP_RANGE( adjustment, -clamp_angle, clamp_angle);
}
This cut down the roll angle target dramatically during the last couple
minutes of the approach. This was just a hack that worked, and I suspect
there is a much better solution.
Basically the problem is that the large aircraft carry too much momentum and
thus tend to oversteer especially in the zone where smaller and smaller
corrections are required. And a given distance off course will produce larger
and larger error angles. Thus the heavy aircraft will produce S patterns of
increasing amplitude rather than actually zeroing in on the glideslope.
Playing with the gain doesn't help because of the response times involved (and
the fact that you don't want to shake up the passengers too much).
One idea I had was to base the error not on an angle from the radial but on
the distance from the center of the cone. The required response to correct
this value would be consistant all the way down the cone.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot nav1 heading problem
One idea I had was to base the error not on an angle from the radial but on the distance from the center of the cone. The required response to correct this value would be consistant all the way down the cone. I agree, cross-track error is the way to go. cross_track_error = distance_to_station * sin( radial_error ) , where distance_to_station is horizontal range (not DME). Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Autopilot update.
I'm tempted to commit my autopilot changes to cvs. Here's what I have done so far. - I've implimented Roy's suggested PID algorithm. Compared to what we had, this algorithm is better behaved, is much more configurable, and much more tunable. It can be made to do a much better job of easing into large control inputs rather than slamming the controls full stop. It handles the integrator windup problem. And also impliments the D portion of the PID which we never had before. For what it's worth the new algorithm works on the change in error from the previous frame rather than the absolute error. - I have completely overhauled the autopilot config mechanism. The autopilot and it's various modes are now configured via an xml data file. There is a global generic one that all aircraft will inherit, but this can be easily overridden with an aircraft specific AP config in the aircraft-set.xml file. This has had a cascading effect on a lot of files (gui, input, controls, hud, etc.) that made reference to the HUD. - newauto.cxx and newauto.hxx are now axed. I will probably let them exist (but not be compiled) for a while in case there are any nuggets left in there that we still want to extract. - I've rewritten the autopilot config dialog box to match my new updates. - Here are the various modes that are currently implimented: Heading modes: - wing leveler - heading bug hold - true heading hold (the route manager manipulates the true heading) - Nav1 CDI hold Pitch/Altitude modes: - Pitch hold - AOA hold - Altitude hold - AGL hold (i.e. crude terrain following) - Nav1 GS hold Velocity modes: - Speed hold (by manipulating throttle) - Speed hold (by manipulating pitch) - You can tweak the autopilot config/gains on the fly via a roundabout mechanism. Open up the property browser and find the /autopilot/new-config/ tree. Find the particular PID controller you want to manipulate and make changes. Then select Reconfig Autopilot at the bottom of the Autopilot menu. Right now the autopilot config sliders don't work. What I haven't done. - I need to write up some documentation on the new PID algorithm, the meaning of the input parameters, and some basic strategies for tweaking the gains. - I haven't set up (or ported) any specific autopilot configurations for existing aircraft, other than the C172. - XML instruments that reference/control the autopilot will need to be updated. - I haven't addressed issues of FCS systems. That would be an interesting follow up of this project. We would probably need to put an abstraction layer in between the control inputs and the control surface output. For simple aircraft like the cub, these could be directly mapped, but for complex aircraft like an airbus, we could put a FCS in between. So if I do a commit now, there might be some temporary breakage and a slightly different subset of functionality, but I think this will be a good stepping stone from which we can then move forward towards addressing the remaining issues. Comments? Any objections to committing my updates? Thanks, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autopilot update.
Comments? Any objections to committing my updates? Thanks, Curt. Does this make it any easier to bypass the FlightGear autopilot (and perhaps soon-to-exist) FCS system, so the FDM could provide this functionality, if desired - perhaps by simply not including an autopilot/FCS file or definition through your new method? This is very important to the JSBSim guys, to have that capability. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot update.
Jon Berndt wrote: Does this make it any easier to bypass the FlightGear autopilot (and perhaps soon-to-exist) FCS system, so the FDM could provide this functionality, if desired - perhaps by simply not including an autopilot/FCS file or definition through your new method? This is very important to the JSBSim guys, to have that capability. Not defining an autopilot for a particular aircraft (or defining a null autopilot) is trivial to do. If the autopilot is defined within JSBSim, how will it be manipulated from FlightGear (as far as activating/deactivating the different modules or adjusting the reference/target points.) What about things like route following (gps) or Nav CDI/GS holds? How does that get communicated to JSBSim? Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autopilot update.
If the autopilot is defined within JSBSim, how will it be manipulated from FlightGear (as far as activating/deactivating the different modules or adjusting the reference/target points.) What about things like route following (gps) or Nav CDI/GS holds? How does that get communicated to JSBSim? Yes this is where it gets complicated. There are modes that are obviously relevant to mere flight dynamics, such as attitude hold, heading select, wings level, terrain following, etc. -- and even these use *sensor* inputs as opposed to actual FDM aircraft state data. The other modes that are tied more firmly to instrument/navigation/ILS etc. are of no interest to JSBSim. So, the answer might be to allow a split. Unless I am mistaken, it seems that ought not to be impossible. This question arises for several reasons, one of which is that I might want to model non-standard craft (I'll leave it at that for the moment). I want to control it in a specified way without worry that the flight will be affected in ways that I am unaware of -- that is, I'd like complete control (and *know* that I have complete control). Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot update.
Jon Berndt wrote: Yes this is where it gets complicated. There are modes that are obviously relevant to mere flight dynamics, such as attitude hold, heading select, wings level, terrain following, etc. -- and even these use *sensor* inputs as opposed to actual FDM aircraft state data. The other modes that are tied more firmly to instrument/navigation/ILS etc. are of no interest to JSBSim. So, the answer might be to allow a split. Unless I am mistaken, it seems that ought not to be impossible. I can't think of a reason why that wouldn't be straightforward and doable. This question arises for several reasons, one of which is that I might want to model non-standard craft (I'll leave it at that for the moment). I want to control it in a specified way without worry that the flight will be affected in ways that I am unaware of -- that is, I'd like complete control (and *know* that I have complete control). I think it would be totally up to the aircraft designer how they want to impliment the FG autopilot vs the JSBSim autopilot or some mix of the two. The FG side is completely reconfigurable on a per-aircraft basis. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot update.
David Culp wrote: Comments? Any objections to committing my updates? It looks great, and I think the sooner it gets commited the better, so we'll have plenty of time to work with it before 0.9.4. I already have a wish list :) mach hold, and vertical speed hold. Ok, it's been at least an hour and no one has objected. :-) I will try to follow up with some documentation this weekend still. Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot update.
Comments? Any objections to committing my updates? It looks great, and I think the sooner it gets commited the better, so we'll have plenty of time to work with it before 0.9.4. I already have a wish list :) mach hold, and vertical speed hold. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autopilot update.
Curtis L. Olson writes: Sent: Saturday, January 31, 2004 2:40 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Autopilot update. Curtis L. Olson Sent: Saturday, January 31, 2004 1:32 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Autopilot update. Comments? Any objections to committing my updates? Ok, it's been at least an hour and no one has objected. :-) Hmm... 1 hour 08 minutes on a weekend Was any discussion really wanted :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot update.
Norman Vine wrote: Hmm... 1 hour 08 minutes on a weekend Was any discussion really wanted :-) Being a volunteer and doing this on weekends and evenings, I've got to move quickly when I do get the chance. I've been working hard on this and trying to factor in comments and suggestions made over the last week or two. I was just giving people a last chance speak now or forever hold your peace. :-) Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot update.
Curtis L. Olson [EMAIL PROTECTED] said: Ok, it's been at least an hour and no one has objected. :-) Ah! Oh! Should've been checking my email! ;-) I will try to follow up with some documentation this weekend still. Even very rudimentary unedited notes would help. Thinking about trying to get the 747 running again in the next day or so. If you got anything at all please forward or post to the list. Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot update.
On Saturday 31 January 2004 20:00, Curtis L. Olson wrote: Norman Vine wrote: Hmm... 1 hour 08 minutes on a weekend Was any discussion really wanted :-) Being a volunteer and doing this on weekends and evenings, I've got to move quickly when I do get the chance. I've been working hard on this and trying to factor in comments and suggestions made over the last week or two. I was just giving people a last chance speak now or forever hold your peace. :-) Regards, Curt. Aye, go for it :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot update.
Curtis L. Olson wrote: David Culp wrote: Comments? Any objections to committing my updates? It looks great, and I think the sooner it gets commited the better, so we'll have plenty of time to work with it before 0.9.4. I already have a wish list :) mach hold, and vertical speed hold. Ok, it's been at least an hour and no one has objected. :-) I will try to follow up with some documentation this weekend still. Small glitch at run time : route = 0D7673D8 Failed to load autopilot configuration: fgfsbase/Aircraft/Generic/generic-autopilot.xml CVS Updated and no generic-autopilot.xml -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot update.
Frederic Bouvier wrote: Small glitch at run time : route = 0D7673D8 Failed to load autopilot configuration: fgfsbase/Aircraft/Generic/generic-autopilot.xml CVS Updated and no generic-autopilot.xml Gaahhh! I swear I added that file. Ok, it's there now. Sorry about that. Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Autopilot PID algorithm
On Thu, 22 Jan 2004 11:46:00 -0600, Curtis L. Olson [EMAIL PROTECTED]
wrote:
I have a PID controller algorithm from one of my textbooks, I could
send it to you with lots of comments.
If it's not too much typing for you, it would be worth taking a look at.
Ok! Here is the PID controller algorithm that I would like to see
implemented:
delta_u_n = Kp * [ (ep_n - ep_n-1) + ((Ts/Ti)*e_n)
+ (Td/Ts)*(edf_n - 2*edf_n-1 + edf_n-2) ]
u_n = u_n-1 + delta_u_n
where:
delta_u : The incremental output
Kp : Proportional gain
ep : Proportional error with reference weighing
ep = beta * r - y
where:
beta : Weighing factor
r: Reference (setpoint)
y: Process value, measured
e : Error
e = r - y
Ts : Sampling interval
Ti : Integrator time
Td : Derivator time
edf : Derivate error with reference weighing and filtering
edf_n = edf_n-1 / ((Ts/Tf) + 1) + ed_n * (Ts/Tf) / ((Ts/Tf) + 1)
where:
Tf : Filter time
Tf = alpha * Td , where alpha usually is set to 0.1
ed : Unfiltered derivate error with reference weighing
ed = gamma * r - y
where:
gamma : Weighing factor
u : absolute output
Index n means the n'th value.
Inputs:
enabled ,
y_n , r_n , beta=1 , gamma=0 , alpha=0.1 ,
Kp , Ti , Td , Ts (is the sampling time available?)
u_min , u_max
Output:
u_n
if (enabled)
{
// Calculates proportional error:
ep_n = beta * r_n - y_n;
// Calculates error:
e_n = r_n - y_n;
// Calculates derivate error:
ed_n = gamma * r_n - y_n;
// Calculates filter time:
Tf = alpha * Td;
// Filters the derivate error:
edf_n = edf_n_1 / (Ts/Tf + 1)
+ (ed_n * (Ts/Tf) / (Ts/Tf + 1);
// Calculates the incremental output:
delta_u_n = Kp * ( (ep_n - ep_n_1)
+ ((Ts/Ti) * e_n)
+ ((Td/Ts) * (edf_n - 2*edf_n_1 + edf_n_2)) );
// Integrator anti-windup logic:
if ( delta_u_n (u_max - u_n_1) )
delta_u_n = 0;
else if ( delta_u_n (u_min - u_n_1) )
delta_u_n = 0;
// Calculates absolute output:
u_n = u_n_1 + delta_u_n;
// Updates indexed values;
u_n_1 = u_n;
ep_n_1 = ep_n;
edf_n_2 = edf_n_1;
edf_n_1 = edf_n;
}
else if (!enabled)
{
u_n = 0;
ep_n = 0;
edf_n = 0;
// Updates indexed values;
u_n_1 = u_n;
ep_n_1 = ep_n;
edf_n_2 = edf_n_1;
edf_n_1 = edf_n;
}
Comments?
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Autopilot in jsbsim
I played around with the wing-leveler example from Automatic flight in jsbsim. I noticed that the solution had the problem of intergator-windup. I tried to limit and/or clip the intergator component, but that didn't do what I thought it would. Does anyone have a solution to this problem? Note that cliping the summer (as the example does) does not solve the windup problem. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autopilot in jsbsim
I played around with the wing-leveler example from Automatic flight in jsbsim. I noticed that the solution had the problem of intergator-windup. I tried to limit and/or clip the intergator component, but that didn't do what I thought it would. Does anyone have a solution to this problem? Note that cliping the summer (as the example does) does not solve the windup problem. -- Roy Vegard Ovesen First of all, let me know how you played with the JSBSim wing-leveler example - I mean, did you use JSBSim in its standalone mode, or did you somehow integrate this with JSBSim within FlightGear. I ask, because I have never tried it within FlightGear, as I have not looked at how to make sure the FlightGear autopilot and the JSBSim flight control/autopilot features could be made to work independently - i.e. how to make a choice on which capability to use. I'd be concerned that they might end up fighting each other. Also, can you explain what you mean by integrator windup? I've run tests in JSBSim with that component and it holds steady for quite a while until I stopped the test. I am guessing you mean that the aircraft grows a bias over time. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 9 Jan 2004 06:31:23 -0600, Jon Berndt [EMAIL PROTECTED] wrote: First of all, let me know how you played with the JSBSim wing-leveler example - I mean, did you use JSBSim in its standalone mode, or did you somehow integrate this with JSBSim within FlightGear. I ask, because I have never tried it within FlightGear, as I have not looked at how to make sure the FlightGear autopilot and the JSBSim flight control/autopilot features could be made to work independently - i.e. how to make a choice on which capability to use. I'd be concerned that they might end up fighting each other. Yes, I used FlightGear. I did a cut and paste into the c172p.xml file from the example code in the manual. I had to modify it a bit: I rederected the output into the fcs/roll-trim-cmd-norm property (the example uses some property under ap/) I figured that the autopilot should use the trim to control the aircraft, is this correct/reasonable? I'm pretty sure that the jsbsim autopilot and FlightGear's autopilot are not fighting each other. I haven't activated the FlightGear autopilot at all! And it works great (the jsbsim one), exept for the integrator windup. Also, can you explain what you mean by integrator windup? Integrator windup is a problem with all PID controllers. When the actuator, in our case the roll trim, goes into saturation (uses all available trim deflection), and still is unable to bring the wings level, the integrator keeps on integratin the error. Problems arise when the actuator (roll trim) goes out of saturation. By then the integrator has been winding up it's contribution to the PI controller output signal. The integrator then has to unwind, the time it takes to unwind ofcourse depends on how long it has been winding-up. While the integrator is unwinding the controller isn't working as it is supposed to. I provoked this actuator saturation by pushing the stick to the right, the autopilot tried to counter this with the roll trim. As I pushed the stick further to the right eventually the roll trim was unable to keep the wings level. The roll trim goes into saturation (full deflection), but is still not able to keep the wings level. This is when the intergator begins winding up. Hope this explains a bit! I've run tests in JSBSim with that component and it holds steady for quite a while until I stopped the test. I am guessing you mean that the aircraft grows a bias over time. When the wings are level and the actuator (roll trim) stays out of saturation, this PI controller works great. It does not grow a bias as long as the actuator is able to do it's job, it only grows a bias when the actuator does not have enough power (deflection angle) to do it's job. The solution to this is to stop the intergation when the actuator goes into saturation. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autopilot in jsbsim
When the wings are level and the actuator (roll trim) stays out of saturation, this PI controller works great. It does not grow a bias as long as the actuator is able to do it's job, it only grows a bias when the actuator does not have enough power (deflection angle) to do it's job. The solution to this is to stop the intergation when the actuator goes into saturation. Knowing nothing about the jsbsim structure, and only a little about PID control, could you arrange the control loop so that the Integral term is only updated when the output is between 2% and 98%? Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 9 Jan 2004 13:58:11 -, Richard Bytheway [EMAIL PROTECTED] wrote: Knowing nothing about the jsbsim structure, and only a little about PID control, could you arrange the control loop so that the Integral term is only updated when the output is between 2% and 98%? This is the solution I'm looking to implement, but sadly my knowlege about the jsbsim structure is so limited that I could not think of a way to do it. Maybe the SWITCH component could be used as an if structure? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 14:52:28 +0100 Roy Vegard Ovesen [EMAIL PROTECTED] wrote: The solution to this is to stop the intergation when the actuator goes into saturation. Aha! Good explanation. Yes, I think this should not be too hard to fix, but I don't have time to play with that myself at this time. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 15:24:15 +0100 Roy Vegard Ovesen [EMAIL PROTECTED] wrote: This is the solution I'm looking to implement, but sadly my knowlege about the jsbsim structure is so limited that I could not think of a way to do it. Maybe the SWITCH component could be used as an if structure? Yes, I think this is exactly a possibility. Have you seen this paper: http://jsbsim.sourceforge.net/AutomaticFlightInJSBSim.pdf ?? There is a decent description of the switch in there. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 14:52:28 +0100 Roy Vegard Ovesen [EMAIL PROTECTED] wrote: Also, note that the derivative part of the example wing leveler control was a complete guess - and I think it actually may not play a large part (or *any* part) in the maintaining wings-level at all. I have also considered using the wing leveler as part of a heading hold control law. Instead of using a roll angle of *zero* to maintain (i.e. wings level) one could insert a desired roll angle. That's only a part of it. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 09:15:53 -0600, Jon S Berndt [EMAIL PROTECTED] wrote: On Fri, 09 Jan 2004 15:24:15 +0100 Roy Vegard Ovesen [EMAIL PROTECTED] wrote: This is the solution I'm looking to implement, but sadly my knowlege about the jsbsim structure is so limited that I could not think of a way to do it. Maybe the SWITCH component could be used as an if structure? Yes, I think this is exactly a possibility. Have you seen this paper: http://jsbsim.sourceforge.net/AutomaticFlightInJSBSim.pdf ?? Yes, that's where I cut and pasted the wing leveler example from :-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 09:13:33 -0600, Jon S Berndt [EMAIL PROTECTED] wrote: On Fri, 09 Jan 2004 14:52:28 +0100 Roy Vegard Ovesen [EMAIL PROTECTED] wrote: The solution to this is to stop the intergation when the actuator goes into saturation. Aha! Good explanation. Yes, I think this should not be too hard to fix, but I don't have time to play with that myself at this time. I've found more problems caused by the integrator: When our jsbsim autopilot is deactivated (ap/wingslevel_hold = false) the integrator is still integrating the difference between actual roll angle and desired roll angle (zero). So if the pilot makes a bank to one direction, and then brings the wings level, the integrator has been winding up during the bank. If the pilot then activates the autopilot the contribution from the integrator will be much more than it should be. If we had the ability to reset the integrator to an arbitrary value, we could reset it to zero whenever the autopilot was deactive. To fix the windup when it was active, we could reset it to the walue it had when saturation occured. I think this should be implemented in the jsbsim source code, not in the fdm_config xml file. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 22:39:20 +0100 Roy Vegard Ovesen [EMAIL PROTECTED] wrote: I think this should be implemented in the jsbsim source code, not in the fdm_config xml file. Yes. And it is true there probably should be an initialization capability for filters, integrators, etc. I'll try and look into this very soon. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot in jsbsim
On Fri, 09 Jan 2004 15:51:40 -0600, Jon S Berndt [EMAIL PROTECTED] wrote: Yes. And it is true there probably should be an initialization capability for filters, integrators, etc. I'll try and look into this very soon. How about adding a new flight control component: PID controller?! I've been searching my textbooks on control systems and found a few PID controller algorithms. I could begin to implement one that takes care of the integrator windup problem and has some other usefull features. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autopilot in jsbsim
How about adding a new flight control component: PID controller?! I've been searching my textbooks on control systems and found a few PID controller algorithms. I could begin to implement one that takes care of the integrator windup problem and has some other usefull features. Well ... I'm open to the discussion. At the moment, though, I wonder how useful it would be if one already has the other individual components? Besides the integrator initialization issue, is there anything else that the current component building blocks could not handle? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] autopilot, maintaining elevation
Hi, I am playing with the autopilot and maintaining an altitidue above sea level works great. Is there a method for maintaining an elevation above the ground? Seamus ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot, maintaining elevation
Seamus Thomas Carroll writes: I am playing with the autopilot and maintaining an altitidue above sea level works great. Is there a method for maintaining an elevation above the ground? Ctrl-t will toggle a mode that attempts to maintain the current altitude above ground. The algorithm is very simplistic though and doesn't take any sort of look ahead into consideration. It only looks at the current elevation above ground and tries to climb or decend to achieve the goal elevation. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot, maintaining elevation
On Thursday 08 January 2004 21:40, Curtis L. Olson wrote: Seamus Thomas Carroll writes: I am playing with the autopilot and maintaining an altitidue above sea level works great. Is there a method for maintaining an elevation above the ground? Ctrl-t will toggle a mode that attempts to maintain the current altitude above ground. The algorithm is very simplistic though and doesn't take any sort of look ahead into consideration. It only looks at the current elevation above ground and tries to climb or decend to achieve the goal elevation. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http:// www.flightgear.org Just today I hacked that bit of code to expose the agl-ft setting in the property tree. However, the hack replaces the old behaviour - ctrl-t doesn't take the current agl-ft but the value set in the p-tree instead. Also, ctrl-t needs to be cycled if the value is changed, so it's not a very good hack. At the same time, I've been thinking about look-ahead algorithms quite a lot - especially with regard to trying to avoid taking a lot of look-ahead ground elevation samples each frame. I think I may have something - just an algorithm (but it only needs one look-ahead sample per frame) - that might work (in a straight line;), but it still needs a bit more thought. Of course, if someone already knows how to do this stuff... ;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] AUTOPILOT
Hi Guys I would like to have the selections on my autopilot panel work only when the Autopilot is engaged.But I dont seem to be able to do it using the property. /controls/autoflight/autopilot/engage. Is this the property to use and how should it be implimented in the XML file.Is there an A/C in FG that already has something like this as I have had a look at some of the A/C panels and can't see how to do it. Also is it possible to turn an instrument on and off using a panel hotspot.The reason for the question is so you could turn a panel like the radio panel(instrument) on adjust the frequencies and then turn it off(hide it)again. Thanks for any suggestions. Cheers Innis The Mad Aussi _ Get less junk mail with ninemsn Premium. Click here http://ninemsn.com.au/premium/landing.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] AUTOPILOT
On Sunday 14 December 2003 13:40, Innis Cunningham wrote: Hi Guys I would like to have the selections on my autopilot panel work only when the Autopilot is engaged.But I dont seem to be able to do it using the property. /controls/autoflight/autopilot/engage. Is this the property to use and how should it be implimented in the XML file.Is there an A/C in FG that already has something like this as I have had a look at some of the A/C panels and can't see how to do it. Also is it possible to turn an instrument on and off using a panel hotspot.The reason for the question is so you could turn a panel like the radio panel(instrument) on adjust the frequencies and then turn it off(hide it)again. Thanks for any suggestions. Cheers Innis The Mad Aussi Provided you could get the trigger events sorted out, and the texture blending animation method works for 2d panels, you should be able to fade panel instruments in and out. I'm sure it could be made to work for 3d panels. Hmm... pop-up instruments? LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] autopilot target heading
If the heading mode is FG_HEADINGWAY_POINT does autopilot block use
a similar procedure like in VOR or ILS navigation by using a rolling motion
to intersect waypoint in a pre-determined heading or does it use the angle
difference between its current heading and the heading calculated by the
waypoint's coordinates and fly to that heading without taking final heading
into account
In the source code I saw items like wp_course and wp_distance.
Target heading was adjusted to waypoint course such as:
if ( wp_distance 100 ) {//I think it flies to a cetain
waypoint until it reaches the limit
TargetHeading = NormalizeDegrees(wp_course);
can you briefly describe how wp_course is calculated?
Regards
Mehmet
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and Control Documentation
Salut Julie, how urgent do You need the describtion and how detailed do You want it to be? I am writing on a training manual for FlightGear (it's in the doc directory), but haven't started the autopilot section by now. If You have some time, I will rearange my schedule and start with the autopilot section next. But I think I will need at least two or three weeks. Best wishes, Carsten julie barbic schrieb: Hi, I am student working on building a flight simulator wihthout any user interface. I have managed to run independently the JSBSim. But now I would like to write a script to autopilot the aircraft through given waypoints. So I would like to know if anyone has a detailed documentation which describes well how to control and autopilot an aircraft. To begin, I would like to make the aircraft be for instance at a constant altitude. Thanks in advance for your help. Julie - Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Testez le nouveau Yahoo! Mail___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Autopilot and Control Documentation
Hi, I am student working on building a flight simulator wihthout any user interface. I have managed to run independently the JSBSim. But now I would liketo write a script to autopilotthe aircraft through given waypoints. So I would like to know if anyone has a detailed documentationwhich describes well how to control and autopilot an aircraft. To begin, I would like to make the aircraftbe for instance at a constant altitude. Thanks in advance for your help. JulieDo You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Testez le nouveau Yahoo! Mail___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] autopilot system
My question is about the variables that are used in the autopilot system. As far as I can understand the target heading is calculated by the angle between the aircraft and the waypoint with the proper heading and the rate of change of angle times the distance between the coordinates which are summed together. The aircraft is supposed to possess max roll until it reaches the rollout point where linearisation occurs to findtarget roll and aileron commands. However I didn't understand how max roll is calculated. Is it the roll angle that aircraft stands stable without stall (ie. the angle for minimum turn radius) or a value chosen for the aircraft. The second one sounds more logical to me because when the lateral distance is large to reach a navigation point we can'tturn with the roll value for minimum turn radius if we don't want to make circles while reaching our point so how can it be calculated. Inone of the documents inthe flight gear site I found that therollout point which resembles an angle is approximately same with the maxroll which is taken 20 for Chessna and the rollout smooth point is approximately half of its maxroll angle. Are these ratios true for other aircraft or they are values found bycertainhandyequations that are dependantto the coefficients of the aircraft which is the main thing that I am wondering and want to learn about because I am trying to experiment with different aircraft by changing the values in the config files and try to make a realistic stuff while having fun and learning about aviation.
Re: [Flightgear-devel] autopilot system
Mehmet Velicangil [EMAIL PROTECTED] said: can it be calculated. In one of the documents in the flight gear site I found that the rollout point which resembles an angle is approximately same with the maxroll which is taken 20 for Chessna and the rollout smooth point is approximately half of its maxroll angle. Are these ratios true for other aircraft or they are values found by certain handy equations that are dependant to the coefficients of the aircraft which is the main thing that I am wondering and want to learn about because I am trying to experiment with different aircraft by changing the values in the config files and try to make a realistic stuff while having fun and learning about aviation. The max roll values for the aircraft that I did were not derived by any scientific method. In some cases max roll was estimated from information available on the web (instructive or flight manual type data), estimated from web photos of aircraft in a bank, or just a wild guess. As far as rollout is concerned my main concern, where it varies, was simply to ensure that the aircraft did not overshoot the target in NAV mode. There isn't any rule AFAIK that it has to be equal to the roll, but you are welcome to experiment and submit any improvements or corrections. The aircraft that I have worked with as far as autopilot config is concerned are the 747, c310 and A4. Basically, the autopilot still requires more work. A little over a year ago autopilot was fixed to c172 requirements and not configurable. The configurability I added was mostly just a stopgap to get the it to operate without stalling and crashing the new higher performance aircraft. At this point I wouldn't read too much into what you see as far as those configurations are concerned :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot selecting and disabling
Jon Berndt wrote: I'm not aware of the internals of the autopilot, but it might be usefull to wait a bit until the script manager is working properly, and then make the autopilot script driven. What is the script manager? David comitted a new FlightGear/src/Scripting directory containing early scripting code. At this time it's a matter of registering and running a script in one go. I've made a script manager where you could register a large number of scripts (for example at startup), which will run at a predefined priority over multiple frames. The scripts can also be stopped and started again individually. This means it would be possible to run certain scripts for the lifetime of FlightGear without a big performance hit, and with the abillity to manipulate FlightGears internals. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Autopilot selecting and disabling
As some of you may know, I have been interested in an autopilot capability for JSBSim in the standalone version. Also, providing a configurable autopilot for JSBSim airplanes flying in FlightGear (via a config file) is also something I'd like to be able to do. Recently, I have completed the basic functionality in the FCS components needed to build an autopilot for JSBSim aircraft, using our components. The two new components created are switch and deadband components. Can someone outline the basic interface that would need to be hooked up (via FGInterface?), and if/how the internal autopilot could be disabled? Jon JON S. BERNDT Coordinator, JSBSim Project www.JSBSim.org [EMAIL PROTECTED] smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Autopilot selecting and disabling
Jon Berndt writes: As some of you may know, I have been interested in an autopilot capability for JSBSim in the standalone version. Also, providing a configurable autopilot for JSBSim airplanes flying in FlightGear (via a config file) is also something I'd like to be able to do. Recently, I have completed the basic functionality in the FCS components needed to build an autopilot for JSBSim aircraft, using our components. The two new components created are switch and deadband components. Can someone outline the basic interface that would need to be hooked up (via FGInterface?), and if/how the internal autopilot could be disabled? John, You can look at src/Autopilot to see how that works. I'm not sure it's been designed to be cleanly replaced by something else. But, since it's driven from the property system, you ought to be able to put another autopilot system inline as long as you keep the first one disabled. Also, consider that for the default autopilot, we have modeled gyros and other systems that are actually used as input to the autopilot (at least on smaller planes.) This makes our current autopilots behave less ideally, and more like real life. Half the fun of learning how to use these things (and your instruments for that matter) is learning the nature of and how to deal with your sensor errors. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autopilot selecting and disabling
Also, consider that for the default autopilot, we have modeled gyros and other systems that are actually used as input to the autopilot (at least on smaller planes.) This makes our current autopilots behave less ideally, and more like real life. Half the fun of learning how to use these things (and your instruments for that matter) is learning the nature of and how to deal with your sensor errors. Excellent, thanks. I would expect then to look at the outputs of the signal conditioners like the gyros, etc. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Autopilot selecting and disabling
Curtis L. Olson writes: Jon Berndt writes: Can someone outline the basic interface that would need to be hooked up (via FGInterface?), and if/how the internal autopilot could be disabled? You can look at src/Autopilot to see how that works. I'm not sure it's been designed to be cleanly replaced by something else. But, since it's driven from the property system, you ought to be able to put another autopilot system inline as long as you keep the first one disabled. I think it is time to design the pure virtual AutoPilot Interface in C++ rather then rely on such a 'hack'. This shouldn't be to hard to do since most autopilots will have quite a large set of components in common IMHO this should of been done a *long* time ago rather then trying fit one autopilot to all aircraft This would be a good time to separate out the FlightComputer functional components from the autopilot too. ie primitive APs have no concept such things as a waypoint to steer to or constant height above terrain In extreme speak I think a major refactoring is in order and this presents us with a good time to do it Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot selecting and disabling
Norman Vine wrote: I think it is time to design the pure virtual AutoPilot Interface in C++ rather then rely on such a 'hack'. This would be a good time to separate out the FlightComputer functional components from the autopilot too. ie primitive APs have no concept such things as a waypoint to steer to or constant height above terrain I'm not aware of the internals of the autopilot, but it might be usefull to wait a bit until the script manager is working properly, and then make the autopilot script driven. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot selecting and disabling
Norman Vine writes: This would be a good time to separate out the FlightComputer functional components from the autopilot too. ie primitive APs have no concept such things as a waypoint to steer to or constant height above terrain In extreme speak I think a major refactoring is in order and this presents us with a good time to do it Agreed. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot selecting and disabling
On Mon, 13 Jan 2003 16:05:07 +0100 Erik Hofman [EMAIL PROTECTED] wrote: I'm not aware of the internals of the autopilot, but it might be usefull to wait a bit until the script manager is working properly, and then make the autopilot script driven. Interesting. I had not heard of that. It's along the lines of what I've been thinking about for JSBSim. We have a scripting capability, now (see FGScript.cpp) in JSBSim. We can also define an autopilot (separate from a normal control system) in our XML config file. So, theoretically, we ought to be able to use the scripting capability for guidance, and the autopilot/FCS for control, allowing completely automated flights from start to finish. This is great for regression testing, because plots can be automatically generated, as well, and this can be done repeatedly under the control of an external script (perl, python, etc.). In five minutes a set of 50 runs could be made for different cases and plotted up for evaluation. As Norman mentioned, a one-size-fits-all autopilot is not optimal. I'd bet, though, that the general layout of an autopilot for each aircraft is quite similar, with the exception of specific gains. This lends itself well to a configuration file approach, with the further benefit of a rapid development cycle. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Autopilot VOR-Tracking Algorithms
Curt and I have been having a discussion offline about algorithms for NAV mode on a simple autopilot (like those typically found in a light Cessna or Piper). The current autopilot does not have a working NAV mode -- it was just a quick kludge, with ability to correct for a crosswind. What algorithms are commonly used to get and keep the CDI centered in a simple AP? It should be easy enough to start with the rate and direction of CDI deviation from center. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot VOR-Tracking Algorithms
What algorithms are commonly used to get and keep the CDI centered in a simple AP? It should be easy enough to start with the rate and direction of CDI deviation from center. I'm tempted to say that there isn't a standard we can simply use; I've used some very different ones even in a small sample of aircraft. Can we add enough hooks to the panel instrument so that it can capture and track all the modes and arming/active status ... even if some of that information is in properties that are not visible on the panel ? Given that, we can define the functionality as a set of transfer functions from properties to properties, where the selection of which functions are active is determined by decoding the panel instrument's status. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot VOR-Tracking Algorithms
At 05:31 PM 7/10/2002 -0400, you wrote: Curt and I have been having a discussion offline about algorithms for NAV mode on a simple autopilot (like those typically found in a light Cessna or Piper). The current autopilot does not have a working NAV mode -- it was just a quick kludge, with ability to correct for a crosswind. What algorithms are commonly used to get and keep the CDI centered in a simple AP? It should be easy enough to start with the rate and direction of CDI deviation from center. I'd say the simplest to implement, while still being reasonably usable, would be a proportional plus derivative law. Command a heading equal to the course, plus a factor times the CDI deflection, plus a factor times the time derivative of the deflection; with the right coefficients, that will damp out any overshoot. Provide an intercept mode that will follow a pilot-selected heading until the CDI comes off the peg. I flew a Cherokee back around 1970 that had an unbelievably crude nav mode: it was a single-axis autopilot that did nothing but command a bank angle proportional to the CDI deflection, truncated at about 15 degrees. If the needle was on the peg, the airplane would fly in lazy circles forever -- but if you did the intercept manually, it worked surprisingly well. rj ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot VOR-Tracking Algorithms
David Megginson [EMAIL PROTECTED] said: Curt and I have been having a discussion offline about algorithms for NAV mode on a simple autopilot (like those typically found in a light Cessna or Piper). The current autopilot does not have a working NAV mode -- it was just a quick kludge, with ability to correct for a crosswind. What algorithms are commonly used to get and keep the CDI centered in a simple AP? It should be easy enough to start with the rate and direction of CDI deviation from center. The technique that I had in mind is probably one that would work for most aircraft. Flying to the needle causes some issues especially with airliner sized aircraft. The current code adjusts the heading by taking the needle deflection and multiplying it by the distance to the navaid. In order to get the 747 on the radial at all I had add a tighter clamp to the heading output of the current code once it got inside the cone, because at 10 or 15 miles out the adjustments were way too high. At 15 miles X 2 degrees deviation it was commanding a 30 degree turn! The momentum of the 747 caused it to stay on 2 degrees (or go even higher) until there was a steep roll angle going that would shoot it way over the other side of the radial. Basically what I had in mind was an adjustment of the target heading based on the resulting devation values. I don't have the actual formula written down, but it would involve doubling the devations and subtracting them from the target heading and including an integral accumulated error adjustment similar to the PI method that Curt used for altitude/gs. For example if the needle indicates off radial by 0.3 degrees, the adjustment to the heading would be -0.6 degrees adjusted with a small fraction of accumulated error so that 0 could be acheived. Pardon me if I have the sign reversed on one of the values in the example, but the idea is to fly on a course that attempts to cross back over the radial, using the accumulated error to drive the size of the errors and resulting course adjustments to 0. Very strong crosswind gusts possibly could blow it too far off course, but I'm not sure that wouldn't be normal behavior for most AP systems. Note that this will only operate while the signal is intercepted. Something else (arm type modes) will have to do the actual interception and trigger the system into the NAV mode at which point the above method would engage. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autopilot VOR-Tracking Algorithms
Basically what I had in mind was an adjustment of the target heading based on the resulting devation values. I don't have the actual formula written down, but it would involve doubling the devations and subtracting them from the target heading and including an integral accumulated error adjustment similar to the PI method that Curt used for altitude/gs. IIRC, the F-16 uses P+I for pitch (altitude/attitude hold) but that's for both AP and non-AP flight - the pitch AP command merely enters the pitch channel summed with the pitch trim command. Roll (heading, attitude hold, etc.) seems to be purely proportional with rate limiting and a spaghetti-like control surface mixing. The problem I see with any autopilot is that it's going to need tweaking to avoid being all over the place - I don't see one AP design as being sufficient for the variety of aircraft we have or will have. You are talking about something that is highly configurable aren't you? Without code? FWIW I designed the JSBSim FCS components to also be able to handle being assembled into an autopilot. The question I have is, how would the desired heading, or roll attitude, or switch positions, be communicated to us, if we so desired it? Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Autopilot VOR-Tracking Algorithms
Jim Wilson writes: The technique that I had in mind is probably one that would work for most aircraft. Flying to the needle causes some issues especially with airliner sized aircraft. The current code adjusts the heading by taking the needle deflection and multiplying it by the distance to the navaid. But how does a simple AP know the distance to the navaid, without cheating? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Autopilot VOR-Tracking Algorithms
Jon Berndt [EMAIL PROTECTED] said: Basically what I had in mind was an adjustment of the target heading based on the resulting devation values. I don't have the actual formula written down, but it would involve doubling the devations and subtracting them from the target heading and including an integral accumulated error adjustment similar to the PI method that Curt used for altitude/gs. IIRC, the F-16 uses P+I for pitch (altitude/attitude hold) but that's for both AP and non-AP flight - the pitch AP command merely enters the pitch channel summed with the pitch trim command. Pitch hold will actually be an active mode in the AP code. It will be usable in a flight director mode, and I suppose it is possible that you could have a configuration that used a combination of thrust and trim commands to maintain a pitch on a glide slope. The thrust would be on a seperate controller anyway. How these would interact is probably more likely just a thrust setting that is calculated manually or by flight computer based on weight and other conditions entered into the equation. The trim would adjust to the GS inputs and the correct pitch would more or less be maintained. One other possible input might be something similar to the AoA sensor that the A-4 uses, but I'm not sure if they are reliable enough for an autothrottle. I'm no expert, but have been studying, so please add corrections and suggestions. Roll (heading, attitude hold, etc.) seems to be purely proportional with rate limiting and a spaghetti-like control surface mixing. The problem I see with any autopilot is that it's going to need tweaking to avoid being all over the place - I don't see one AP design as being sufficient for the variety of aircraft we have or will have. You are talking about something that is highly configurable aren't you? Yes I've been laying this out (until the other day when I decided to swap computers). You can get a rough idea by looking at /sim/autopilot/config (the properties I added to get the non c172 aircraft working--more or less--with the existing code). I'm finding that some of those adjustments aren't really necessary, but there will be many more. Also there will be configuration for which capabilities are supported by a particular device/system. This is for the basic AP function set. When we get to the more sophisticated flight computer level it remains to be figured out whether individual FMC models should be independantly coded or if there is a way to make an abstracted configurable FMC class. At the very least we would have to include the ability to run timed test sequences and semi-complex approach and landing sequences. Without code? FWIW I designed the JSBSim FCS components to also be able to handle being assembled into an autopilot. Is there something there I should be looking at? The question I have is, how would the desired heading, or roll attitude, or switch positions, be communicated to us, if we so desired it? Sounds like property nodes to me :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
