Re: [Flightgear-devel] new autopilot - heading hold
David Culp [EMAIL PROTECTED] said: We just need another calculation in the update_helper for the /orientation/heading-magnetic-deg value. Yes, I looked through update_helper, and the other error calculations are compatable with inertial systems, so only the heading source need be changed. Perhaps all we need is to reinstate a way to select inertial versus non-inertial sources, perhaps with autopilot/config/use-inertial-sources, then have update_helper use /orientation/heading-magnetic-deg when use-inertial-sources is true, and use the DG source when use-inertial-sources is false. That sounds like it might be the right way to do it. Is it better to use a general flag like that or to have one that is specific to indicated heading as in the old autopilot code? Does this work for the designers (Curt et al), using configuration properties to manipulate the behavior of the helper? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
Roy Vegard Ovesen [EMAIL PROTECTED] said: On Tue, 3 Feb 2004 17:10:07 -, Jim Wilson [EMAIL PROTECTED] wrote: Roy Vegard Ovesen [EMAIL PROTECTED] said: The obvious thing you missed is the fact that newauto.cxx is no longer used, it has been removed from the makefile. So many of the properties under /autopilot/config/ do no longer apply. Yes, but that doesn't solve the problem. We just need another calculation in the update_helper for the /orientation/heading-magnetic-deg value. How about synchronising the DG to the magnetic compass or to the true heading, depending on what you want? Wouldn't that solve this problem? At some point there is a lot of detail to fill in as far as how boeing systems should be modeled, but for now just getting the heading right off the FDM output is fine. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
Jim Wilson wrote: That sounds like it might be the right way to do it. Is it better to use a general flag like that or to have one that is specific to indicated heading as in the old autopilot code? Does this work for the designers (Curt et al), using configuration properties to manipulate the behavior of the helper? I'd be more inclined to simply add a new helper calculation. As time goes forward, given all the variety of sensors and autopilot hardware and vintages of sensors and autopilots, this could get extremely messy and confusing. I'd prefer to simply add a new calculation to the helper function section. 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] new autopilot - heading hold
Curtis L. Olson [EMAIL PROTECTED] said: Jim Wilson wrote: That sounds like it might be the right way to do it. Is it better to use a general flag like that or to have one that is specific to indicated heading as in the old autopilot code? Does this work for the designers (Curt et al), using configuration properties to manipulate the behavior of the helper? I'd be more inclined to simply add a new helper calculation. As time goes forward, given all the variety of sensors and autopilot hardware and vintages of sensors and autopilots, this could get extremely messy and confusing. I'd prefer to simply add a new calculation to the helper function section. Yes, that leaves the options open. May I suggest this then? (I'm trying to get the 747 a/p together :-)) patch: http://www.spiderbark.com/fgfs/xmlauto-jw.patch patchedfile: http://www.spiderbark.com/fgfs/xmlauto.cxx Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
Jim Wilson wrote: It is indeed! Is the altitude hold working for you? I'm finding that the first stage is outputing values that ocilate from max to min and back in probably 5 or 6 (not timed yet) cycles. Anyway, I haven't looked at the code or adjusted any of the parameters yet. I just wanted to know if maybe it's something unique to my setup before messing with numbers. Altitude hold should now be working fairly well for the C172. 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] new autopilot - heading hold
Jim Wilson wrote: Curtis L. Olson [EMAIL PROTECTED] said: Jim Wilson wrote: That sounds like it might be the right way to do it. Is it better to use a general flag like that or to have one that is specific to indicated heading as in the old autopilot code? Does this work for the designers (Curt et al), using configuration properties to manipulate the behavior of the helper? I'd be more inclined to simply add a new helper calculation. As time goes forward, given all the variety of sensors and autopilot hardware and vintages of sensors and autopilots, this could get extremely messy and confusing. I'd prefer to simply add a new calculation to the helper function section. Yes, that leaves the options open. May I suggest this then? (I'm trying to get the 747 a/p together :-)) patch: http://www.spiderbark.com/fgfs/xmlauto-jw.patch patchedfile: http://www.spiderbark.com/fgfs/xmlauto.cxx Sounds good. I added something very similar. 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] new autopilot - heading hold
Yes, that leaves the options open. May I suggest this then? (I'm trying to get the 747 a/p together :-)) Beat me to it :) Here are two other calculations you'll need, vertical speed error and mach error. // Calculate vertical speed error static SGPropertyNode *target_vert_speed = fgGetNode( /autopilot/settings/vert-speed-fpm, true ); static SGPropertyNode *vert_speed = fgGetNode( /velocities/vertical-speed-fps, true ); static SGPropertyNode *vs_error = fgGetNode( /autopilot/internal/vert-speed-error-fpm, true ); vs_error-setDoubleValue( target_vert_speed-getDoubleValue() - vert_speed-getDoubleValue() * 60.0); // Calculate mach error static SGPropertyNode *target_mach = fgGetNode( /autopilot/settings/mach, true ); static SGPropertyNode *mach = fgGetNode( /velocities/mach, true ); static SGPropertyNode *mach_error = fgGetNode( /autopilot/internal/mach-error, true ); mach_error-setDoubleValue( target_mach-getDoubleValue() - mach-getDoubleValue() ); Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
On Wed, 4 Feb 2004 13:28:39 -0600, David Culp [EMAIL PROTECTED] wrote: Beat me to it :) Here are two other calculations you'll need, vertical speed error and mach error. // Calculate vertical speed error static SGPropertyNode *target_vert_speed = fgGetNode( /autopilot/settings/vert-speed-fpm, true ); static SGPropertyNode *vert_speed = fgGetNode( /velocities/vertical-speed-fps, true ); static SGPropertyNode *vs_error = fgGetNode( /autopilot/internal/vert-speed-error-fpm, true ); vs_error-setDoubleValue( target_vert_speed-getDoubleValue() - vert_speed-getDoubleValue() * 60.0); // Calculate mach error static SGPropertyNode *target_mach = fgGetNode( /autopilot/settings/mach, true ); static SGPropertyNode *mach = fgGetNode( /velocities/mach, true ); static SGPropertyNode *mach_error = fgGetNode( /autopilot/internal/mach-error, true ); mach_error-setDoubleValue( target_mach-getDoubleValue() - mach-getDoubleValue() ); Dave I think this is taking it one step too far. We don't need to calculate vertical speed error, that is done inside the controller (when you use /velocities/vertical-speed-fps ans input and /autopilot/settings/vert-speed-fps as reference). The reason for the heading bug error calculation was to make the turning to the heading bug more intelligent. If we had used current heading as input and heading bug as reference to a controller it would have turned right all the way from 10 deg to 350 deg through 180 deg, insted of just turning left from 10 to 350. Our solution was to figure out how many degrees left (negative) or right (positive) we need to turn. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
I think this is taking it one step too far. We don't need to calculate vertical speed error, that is done inside the controller (when you use /velocities/vertical-speed-fps ans input and /autopilot/settings/vert-speed-fps as reference). I see. Thanks. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
On Tuesday 03 February 2004 02:23, Jim Wilson wrote: Curtis L. Olson [EMAIL PROTECTED] said: For everyone: I've integrated this into a larger document which attempts to explain the basic ideas behind control theory and then describes the specific PID algorithm we have implimented for FlightGear. This information isn't strictly necessary for building aircraft specific autopilot configurations, but it's such cool stuff it's worth mentioning. :-) It is indeed! Is the altitude hold working for you? I'm finding that the first stage is outputing values that ocilate from max to min and back in probably 5 or 6 (not timed yet) cycles. Anyway, I haven't looked at the code or adjusted any of the parameters yet. I just wanted to know if maybe it's something unique to my setup before messing with numbers. Best, Jim I started with putting the generic AP in the TSR2 and got similar behaviour. I haven't had a chance to see the docs yet but I've got a reasonable alt hold by reducing Kp Ti, quite drastically. !-- Altitude hold. 2 stage cascade controller. -- !-- Stage #1 sets target rate of climb based on diff between current alt -- !-- and target altitude. -- pid-controller nameAltitude Hold (Altimeter based) Stage 1/name debugfalse/debug enable prop/autopilot/locks/altitude/prop valuealtitude-hold/value /enable input prop/instrumentation/altimeter/indicated-altitude-ft/prop /input reference prop/autopilot/settings/target-altitude-ft/prop /reference output prop/autopilot/internal/target-climb-rate-fps/prop /output config Kp0.1/Kp!-- proportional gain -- beta1.0/beta!-- input value weighing factor -- alpha0.1/alpha !-- low pass filter weighing factor -- gamma0.0/gamma !-- input value weighing factor for -- !-- unfiltered derivative error -- Ti20.0/Ti !-- integrator time -- Td0.1/Td!-- derivator time -- u_min-40.0/u_min !-- minimum output clamp -- u_max40.0/u_max !-- maximum output clamp -- /config /pid-controller Obviously, I've upped the u_min u_max here too. Heh! - I'll get the docs tomorrow... LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
Lee Elliott [EMAIL PROTECTED] said: On Tuesday 03 February 2004 02:23, Jim Wilson wrote: Curtis L. Olson [EMAIL PROTECTED] said: For everyone: I've integrated this into a larger document which attempts to explain the basic ideas behind control theory and then describes the specific PID algorithm we have implimented for FlightGear. This information isn't strictly necessary for building aircraft specific autopilot configurations, but it's such cool stuff it's worth mentioning. :-) It is indeed! Is the altitude hold working for you? I'm finding that the first stage is outputing values that ocilate from max to min and back in probably 5 or 6 (not timed yet) cycles. Anyway, I haven't looked at the code or adjusted any of the parameters yet. I just wanted to know if maybe it's something unique to my setup before messing with numbers. Best, Jim I started with putting the generic AP in the TSR2 and got similar behaviour. I haven't had a chance to see the docs yet but I've got a reasonable alt hold by reducing Kp Ti, quite drastically. !-- Altitude hold. 2 stage cascade controller. -- !-- Stage #1 sets target rate of climb based on diff between current alt -- !-- and target altitude. -- pid-controller nameAltitude Hold (Altimeter based) Stage 1/name debugfalse/debug enable prop/autopilot/locks/altitude/prop valuealtitude-hold/value /enable input prop/instrumentation/altimeter/indicated-altitude-ft/prop /input reference prop/autopilot/settings/target-altitude-ft/prop /reference output prop/autopilot/internal/target-climb-rate-fps/prop /output config Kp0.1/Kp!-- proportional gain -- beta1.0/beta!-- input value weighing factor -- alpha0.1/alpha !-- low pass filter weighing factor -- gamma0.0/gamma !-- input value weighing factor for -- !-- unfiltered derivative error -- Ti20.0/Ti !-- integrator time -- Td0.1/Td!-- derivator time -- u_min-40.0/u_min !-- minimum output clamp -- u_max40.0/u_max !-- maximum output clamp -- /config /pid-controller Obviously, I've upped the u_min u_max here too. Heh! - I'll get the docs tomorrow... Hi Lee, Curt fixed that today. It even works pretty well with the 747. With the one he commited, the gain is higher than what you have (Kp=1.0), a little longer intergration period (Ti=25.0) and the derivator is way down to almost 0 (Td=0.1). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
On Wed, 4 Feb 2004 21:39:23 - Jim Wilson [EMAIL PROTECTED] wrote: Curt fixed that today. It even works pretty well with the 747. With the one he commited, the gain is higher than what you have (Kp=1.0), a little longer intergration period (Ti=25.0) and the derivator is way down to almost 0 (Td=0.1). I'm wondering if a PID controller is only marginally better than a PI controller. What if you remove the D control altogether? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
On Wed, 4 Feb 2004 00:48:00 +, Lee Elliott [EMAIL PROTECTED] wrote: !-- Altitude hold. 2 stage cascade controller. -- !-- Stage #1 sets target rate of climb based on diff between current alt -- !-- and target altitude. -- pid-controller nameAltitude Hold (Altimeter based) Stage 1/name debugfalse/debug enable prop/autopilot/locks/altitude/prop valuealtitude-hold/value /enable input prop/instrumentation/altimeter/indicated-altitude-ft/prop /input reference prop/autopilot/settings/target-altitude-ft/prop /reference output prop/autopilot/internal/target-climb-rate-fps/prop /output config Kp0.1/Kp!-- proportional gain -- beta1.0/beta!-- input value weighing factor -- alpha0.1/alpha !-- low pass filter weighing factor -- gamma0.0/gamma !-- input value weighing factor for -- !-- unfiltered derivative error -- Ti20.0/Ti !-- integrator time -- Td0.1/Td!-- derivator time -- u_min-40.0/u_min !-- minimum output clamp -- u_max40.0/u_max !-- maximum output clamp -- /config /pid-controller Obviously, I've upped the u_min u_max here too. Heh! - I'll get the docs tomorrow... Some notes on tuning cascade controllers: When tuning cascade controllers it is common practice to first tune the inner loop or the secondary controller in Lee's example that would be the vertical speed controller, and then tune the outer loop or the primary controller. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
Jon S Berndt [EMAIL PROTECTED] said: On Wed, 4 Feb 2004 21:39:23 - Jim Wilson [EMAIL PROTECTED] wrote: Curt fixed that today. It even works pretty well with the 747. With the one he commited, the gain is higher than what you have (Kp=1.0), a little longer intergration period (Ti=25.0) and the derivator is way down to almost 0 (Td=0.1). I'm wondering if a PID controller is only marginally better than a PI controller. What if you remove the D control altogether? I suspect the derivative is going to be critical for making the 747 A/P work well. There's a lot more weight being tossed around, so overshooting targets becomes a major problem. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
On Wednesday 04 February 2004 21:39, Jim Wilson wrote: Lee Elliott [EMAIL PROTECTED] said: On Tuesday 03 February 2004 02:23, Jim Wilson wrote: Curtis L. Olson [EMAIL PROTECTED] said: For everyone: I've integrated this into a larger document which attempts to explain the basic ideas behind control theory and then describes the specific PID algorithm we have implimented for FlightGear. This information isn't strictly necessary for building aircraft specific autopilot configurations, but it's such cool stuff it's worth mentioning. :-) It is indeed! Is the altitude hold working for you? I'm finding that the first stage is outputing values that ocilate from max to min and back in probably 5 or 6 (not timed yet) cycles. Anyway, I haven't looked at the code or adjusted any of the parameters yet. I just wanted to know if maybe it's something unique to my setup before messing with numbers. Best, Jim I started with putting the generic AP in the TSR2 and got similar behaviour. I haven't had a chance to see the docs yet but I've got a reasonable alt hold by reducing Kp Ti, quite drastically. !-- Altitude hold. 2 stage cascade controller. -- !-- Stage #1 sets target rate of climb based on diff between current alt -- !-- and target altitude. -- pid-controller nameAltitude Hold (Altimeter based) Stage 1/name debugfalse/debug enable prop/autopilot/locks/altitude/prop valuealtitude-hold/value /enable input prop/instrumentation/altimeter/indicated-altitude-ft/prop /input reference prop/autopilot/settings/target-altitude-ft/prop /reference output prop/autopilot/internal/target-climb-rate-fps/prop /output config Kp0.1/Kp!-- proportional gain -- beta1.0/beta!-- input value weighing factor -- alpha0.1/alpha !-- low pass filter weighing factor -- gamma0.0/gamma !-- input value weighing factor for -- !-- unfiltered derivative error -- Ti20.0/Ti !-- integrator time -- Td0.1/Td!-- derivator time -- u_min-40.0/u_min !-- minimum output clamp -- u_max40.0/u_max !-- maximum output clamp -- /config /pid-controller Obviously, I've upped the u_min u_max here too. Heh! - I'll get the docs tomorrow... Hi Lee, Curt fixed that today. It even works pretty well with the 747. With the one he commited, the gain is higher than what you have (Kp=1.0), a little longer intergration period (Ti=25.0) and the derivator is way down to almost 0 (Td=0.1). Best, Jim Ah - that's interesting - I wasn't sure how small some of the numbers could be. I tried reducing it, but not nearly enough, and not seeing much difference, reset it. Had a chance to look at the docs today - er... ;) Something new to play with:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
On Wednesday 04 February 2004 21:52, Roy Vegard Ovesen wrote: On Wed, 4 Feb 2004 00:48:00 +, Lee Elliott [EMAIL PROTECTED] wrote: !-- Altitude hold. 2 stage cascade controller. -- !-- Stage #1 sets target rate of climb based on diff between current alt -- !-- and target altitude. -- pid-controller nameAltitude Hold (Altimeter based) Stage 1/name debugfalse/debug enable prop/autopilot/locks/altitude/prop valuealtitude-hold/value /enable input prop/instrumentation/altimeter/indicated-altitude-ft/prop /input reference prop/autopilot/settings/target-altitude-ft/prop /reference output prop/autopilot/internal/target-climb-rate-fps/prop /output config Kp0.1/Kp!-- proportional gain -- beta1.0/beta!-- input value weighing factor -- alpha0.1/alpha !-- low pass filter weighing factor -- gamma0.0/gamma !-- input value weighing factor for -- !-- unfiltered derivative error -- Ti20.0/Ti !-- integrator time -- Td0.1/Td!-- derivator time -- u_min-40.0/u_min !-- minimum output clamp -- u_max40.0/u_max !-- maximum output clamp -- /config /pid-controller Obviously, I've upped the u_min u_max here too. Heh! - I'll get the docs tomorrow... Some notes on tuning cascade controllers: When tuning cascade controllers it is common practice to first tune the inner loop or the secondary controller in Lee's example that would be the vertical speed controller, and then tune the outer loop or the primary controller. That's interesting - I concentrated on getting good values in the output from the first stage before I considered looking at the second, which I don't think I touched in the end. I figured I'd need reasonable data going into the second stage if I were to make any sense of what it did. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
On Wednesday 04 February 2004 22:03, Roy Vegard Ovesen wrote:
On Wed, 04 Feb 2004 15:44:15 -0600, Jon S Berndt [EMAIL PROTECTED] wrote:
I'm wondering if a PID controller is only marginally better than a PI
controller. What if you remove the D control altogether?
That would crash the algorithm with a divide by zero. I've prepared a
patch to make it possible to set Td to zero and completely remove the
derivate action.
The tuning docs say
Eliminate integral and derivative action by setting the
derivative time, $T_{d}$, to its minimum value (zero) and the
integral time, $T_{i}$ to its maximum value.
I read that as saying that I should start by setting Td to zero.
error in the doc?
LeeE
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new autopilot - heading hold
Arguably, it should be the FDM that provides vertical speed in fps but if that doesn't happen in the near term, then I don't see a problem with the autopilot doing a quick conversion for it's own use. Regards, Curt. JSBSim has this: velocities/v-down-fps But, we also have this: velocities/h-dot-fps Let me know if you need to make sense of these ... Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
On Mon, 2 Feb 2004 18:39:23 -0600, David Culp [EMAIL PROTECTED] wrote: Thanks Curt, Jeff, Norman and Wendell for the slick new autopilot system. I've been playing with it, trying to adapt the generic autopilot to the 737. I see that I can set the autopilot to use actual mag heading, rather than DG heading, by setting autopilot/config/indicated-heading-magnetic to true. I wasn't able to get it to work until I changed a line in xmlauto.cxx, where the heading error is calculated. The current code finds the error by comparing the target heading with the DG heading. I changed line 630 to use the property /orientation/heading-magnetic-deg instead, and now it works fine. So, it appears that newauto.cxx allows for the heading source to be selected, but FGXMLAutopilot::update_helper() has it hard-wired to the DG. Or, very likely, I missed something obvious. The obvious thing you missed is the fact that newauto.cxx is no longer used, it has been removed from the makefile. So many of the properties under /autopilot/config/ do no longer apply. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
So, it appears that newauto.cxx allows for the heading source to be selected, but FGXMLAutopilot::update_helper() has it hard-wired to the DG. Or, very likely, I missed something obvious. The obvious thing you missed is the fact that newauto.cxx is no longer used, it has been removed from the makefile. So many of the properties under /autopilot/config/ do no longer apply. Ah, got it. Thanks. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
Roy Vegard Ovesen [EMAIL PROTECTED] said: The obvious thing you missed is the fact that newauto.cxx is no longer used, it has been removed from the makefile. So many of the properties under /autopilot/config/ do no longer apply. Yes, but that doesn't solve the problem. We just need another calculation in the update_helper for the /orientation/heading-magnetic-deg value. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
Jim Wilson wrote: Roy Vegard Ovesen [EMAIL PROTECTED] said: The obvious thing you missed is the fact that newauto.cxx is no longer used, it has been removed from the makefile. So many of the properties under /autopilot/config/ do no longer apply. Yes, but that doesn't solve the problem. We just need another calculation in the update_helper for the /orientation/heading-magnetic-deg value. Yup, we don't want to break things for heading bug tracking. *Add*ing the calcuation to the update_helper() function would be the thing to do. I'm also thinking it would be interesting to add enough information so that we could have a mode that holds the runway centerline with the nosewheel/rudder. 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] new autopilot - heading hold
We just need another calculation in the update_helper for the /orientation/heading-magnetic-deg value. Yes, I looked through update_helper, and the other error calculations are compatable with inertial systems, so only the heading source need be changed. Perhaps all we need is to reinstate a way to select inertial versus non-inertial sources, perhaps with autopilot/config/use-inertial-sources, then have update_helper use /orientation/heading-magnetic-deg when use-inertial-sources is true, and use the DG source when use-inertial-sources is false. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new autopilot - heading hold
On Tue, 3 Feb 2004 17:10:07 -, Jim Wilson [EMAIL PROTECTED] wrote: Roy Vegard Ovesen [EMAIL PROTECTED] said: The obvious thing you missed is the fact that newauto.cxx is no longer used, it has been removed from the makefile. So many of the properties under /autopilot/config/ do no longer apply. Yes, but that doesn't solve the problem. We just need another calculation in the update_helper for the /orientation/heading-magnetic-deg value. How about synchronising the DG to the magnetic compass or to the true heading, depending on what you want? Wouldn't that solve this problem? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New Autopilot Documentation
A question. When defining a cascade controller, is it important that the early stages of the controller go before the later stages in the config file? Alternatively, do the individual PID controllers get processed in the order they appear in the config file each frame, or are any dependencies worked out behind the scenes? If order is important, I assume that you could get a 1 frame lag between each PID stage if they are in the wrong order. Richard snip http://www.flightgear.org/Docs/XMLAutopilot/ This document is a first stab. I'm sure it's full of mistakes and possible misunderstandings or oversites. Hopefully there aren't too many outright falsehoods. Feel free to submit feedback and corrections. Original is in latex format. I already know I need to work on the html formating of the description of the algorithm variables. :-) Regards, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
On Mon, 2 Feb 2004 10:55:05 -, Richard Bytheway [EMAIL PROTECTED] wrote: A question. When defining a cascade controller, is it important that the early stages of the controller go before the later stages in the config file? The Primary controller (the one that sets the reference set-point for the secondary) should be processed first. Alternatively, do the individual PID controllers get processed in the order they appear in the config file each frame, or are any dependencies worked out behind the scenes? The comment in the top of the generic-autopilot.xml claims that the controllers are processed in the order that they appear. AFAIK no dependancies are worked out behind the scenes. If order is important, I assume that you could get a 1 frame lag between each PID stage if they are in the wrong order. True. If it would affect performance will depend on the process dynamics. If the dynamics are in the order of the time between two frames then I guess it would. Still, I of course think that we should do it right, as Curt has done in generic-autopilot.xml. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Autopilot Documentation
Richard Bytheway wrote: A question. When defining a cascade controller, is it important that the early stages of the controller go before the later stages in the config file? Yes, this is the optimal arrangement. Alternatively, do the individual PID controllers get processed in the order they appear in the config file each frame ... Yes. ... or are any dependencies worked out behind the scenes? No, the pid evaluator just runs each pid module in the order they are specified in the config file. If order is important, I assume that you could get a 1 frame lag between each PID stage if they are in the wrong order. Yes, that is what would happen. 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] New Autopilot Documentation
Curtis L. Olson [EMAIL PROTECTED] said: For everyone: I've integrated this into a larger document which attempts to explain the basic ideas behind control theory and then describes the specific PID algorithm we have implimented for FlightGear. This information isn't strictly necessary for building aircraft specific autopilot configurations, but it's such cool stuff it's worth mentioning. :-) It is indeed! Is the altitude hold working for you? I'm finding that the first stage is outputing values that ocilate from max to min and back in probably 5 or 6 (not timed yet) cycles. Anyway, I haven't looked at the code or adjusted any of the parameters yet. I just wanted to know if maybe it's something unique to my setup before messing with numbers. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Thu, 29 Jan 2004 01:45:18 -, Jim Wilson [EMAIL PROTECTED] wrote: But to go back to the C172 example, does anyone actually understand how this issue is handled in a cessna autopilot or any of the others that might be installed in a 172? Will it stall the aircraft? Or...hmmm...trying to remember... does the 172 even have an AP for the pitch axis? A quick browse to the Cessna web site reveals that the C172 can be delivered with the KAP 140 Two Axis w/Altitude preselect Autopilot from Bendix/King. I just downloaded the Pilot's Guide from this link: http://www.n612sp.com/KAP%20140%20AUTOPILOT.pdf After browsing through this document, it is my understanding that the autopilot will stall the aircraft because it has no input telling it speed or angle-of-attack. I think Pilot's Guides could be waluable references when we begin to implement real world autopilots. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Thu, 29 Jan 2004 11:40:38 +0100, Roy Vegard Ovesen [EMAIL PROTECTED] wrote: I just downloaded the Pilot's Guide from this link: http://www.n612sp.com/KAP%20140%20AUTOPILOT.pdf It seems that this pdf file does not contain the entire document. For the complete document use this link: http://bkweb01.ais.honeywell.com/static/bk_club/pilotguides/techpubs/006-18034-_0.pdf -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Jim Wilson wrote: But to go back to the C172 example, does anyone actually understand how this issue is handled in a cessna autopilot or any of the others that might be installed in a 172? Will it stall the aircraft? Or...hmmm...trying to remember... does the 172 even have an AP for the pitch axis? Hello, I can't give an exact matching case, but here is some info on a S-TEC System Twenty/System Thirty autopilot in a Piper Warrior II, a plane in the C172 class. The Twenty is a 1-axis AP, controlling the ailerons. Feedback to the controller is from the turn coordinator (with the AP built into the same case). There are 4 operating modes. One is a stabilizer, with a panel knob to control the pitch. With the knob centered, you have a wing leveler. Turning the knob left or right gives a controlled left or right bank, up to 90% of a standard rate turn. Mode 2 is heading hold, where the input is from the heading bug of the DG. It adjusts the bank to keep the bug centered. Modes 3 and 4 get input from the needle on the CDI, tracking to/from a VOR or following a localizer on an approach. Mode 3 is lower gain for a smoother ride when the VOR signal is a bit erratic. Mode 4 holds more actively as you would want on an approach. The model Thirty adds pitch control in the form of altitude hold. It uses an absolute pressure transducer for altitude sensing, and an accelerometer is mentioned but not discussed. You first stabilize at the desired altitude, and switch the pitch control on, which then maintains altitude. If the elevator servo runs out of capability, two lights signal the pilot to adjust the pitch trim up or down to get back into control range. No attempt is made to help on climb or descent, that would likely put it out of price range for these smaller single engine planes. -- Bill Earnest [EMAIL PROTECTED] Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
William Earnest wrote: I can't give an exact matching case, but here is some info on a S-TEC System Twenty/System Thirty autopilot in a Piper Warrior II, a plane in the C172 class. The STEC is currently the AP of choice for any light aircraft, whether shipped as a factory option or not. Lots of people retrofit older planes with them. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot: Propulsion only FCS
Again, this is something that the JSBSim FCS components could handle - you need building blocks. Reading about the flight control system of the thrust vectoring fa-18 HARV in http://techreports.larc.nasa.gov/ltrs/PDF/NASA-96-tm110216.pdf and loooking at the released MATLAB code of a simulation of this plane available from http://www.dfrc.nasa.gov/Research/HARV/Work/NASA2/nasa2.html gives me the impresson that even those control theory blocks are not sufficient for modelling this plane. Look into the file roll_stick_limits.m, there is plain computational code to get the aileron, stabilizer and rudder command of an f-18. So everything which cuts down flexibility in the area of the flightcontrol system/autopilot is a problem. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot: Propulsion only FCS
Yikes! That's interesting. It's interesting that the file is called roll_stick_limits. Judging by the title alone it would seem to be simply a complicated way to calculate the limits of pilot stick roll inputs. In fact, this is what the comment at the top of the file says: this function calculates the roll command limits for the honeywell control laws I'd like to see a verbal description of this. It's probably a variable roll rate limit based on alpha -- it is an experimental high alpha research vehicle after all. No matter what system is in place in FlightGear, this kind of research stuff would only be possible with special custom code. Hmm, I have not looked very deep in that. But as far as I understood this honeywell control laws are also implemented in the standard fa-18, not only the research HARV fa-18. What I have understood up to now is as follows: One can get roll moment via the ailerons, this is the normal case. Also by differential stabilizer (elevator) deflections and using the rudder. This is what is modeled in this file. Also some of these vaious papers about those two fa-18 planes which were(are?) owned by the NASA, I have found some references which claim that the trailing edge flaps together with the leading edge flaps are used under some circumstances to produce a roll moment. But back to the aileron, stabilizer and rudder. This control law tries to compute the most effective combination of surface deflections with a minimum of movement of those surfaces. It will also take in account the deflection and rate limts for this aerosurfaces. This is done by some linear optimization algorythm. And I guess that this is too hard to do with blocks ... Other than that I guess that more and more flightcontrol systems will become more sophisticated in the future. Because if there is already a computer in the flightcontrol system, why not use it for more then those control theory blocks. Greetings Mathias -- Mathias Fröhlich, e-mail: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Tue, 27 Jan 2004 09:38:17 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Right now we have limits built into the altitude hold modules. For instance, for the C172, I don't want to command a climb if the speed is less that 70 kts. So I take the target climb rate and tail that off to zero as the speed goes down to 70. It's a hack I know, but it seems to help. Is there a better way to do that anyway given a generic pid algorithm? Would we want to build in hooks to the generic pid algorithm so we can set up these sorts of limits? I don't think this should be part of the PID algorithm. I think we should use your hack and apply it to the setpoint to the v/s or pitch. This means that we need some sort of if ... then functionality. I just started looking at Nasal, and I think that could be used for summing, gaining, if...then, etc. As I understand it, the autothrottle predicts the airspeed 10 seconds ahead of time, and uses that as the input. I didn't know this, but it seems to me that this strategy is something that some autopilot designer has found out that this would be a good thing. If I were to design a autothrottle, knowing nothing about past autothrottle experience, I would use the current airspeed as input. Would the differential component of the PID algorithm be able to account for this? That might just do the trick. Would we want some code someplace that puts the predicted speed into the property tree for the generic pid algorithm to use, or would we want to build in some sort of property prediction ability into the pid algorithm (in case the 'd' component doesn't quite do what we want?) I think a hack is the way to go, and if we can use Nasal to do it we can implement this hack, the one-eighty-hack and any other hack that we might need. By the way, did you get my reply with answers and the updated PID algorithm?? I'm not sure I got through your spam-filter. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot: Propulsion only FCS
Lee Elliott wrote: I think I've heard of some of the stuff Curt's referring to - the next gen US fighters are planned to be thrust vectoring only. Taking the control surface stuff out of the wing removes channeling, making it more simple but also stronger and more resiliant to damage - you don't have to worry about the control surfaces getting damaged. I suspect there's a stealth motivation too. Big, flat, flapping control surfaces act like signalling mirrors to a radar station. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Roy Vegard Ovesen wrote: I just started looking at Nasal, and I think that could be used for summing, gaining, if...then, etc. It certainly could. In the past I've warned (for performance reasons) about getting into situations where a zillion Nasal scripts expect to run every frame, but for the single case of an autopilot it should be OK. In fact, you could hack one up for a prototype without any C++ code at all. Just write an autopilot.update() function that inspects properties for input, writes its output to /controls, and registers itself to run again via settimer(). Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Roy Vegard Ovesen wrote: I don't think this should be part of the PID algorithm. I think we should use your hack and apply it to the setpoint to the v/s or pitch. This means that we need some sort of if ... then functionality. I just started looking at Nasal, and I think that could be used for summing, gaining, if...then, etc. That might be interesting. Maybe we need an official autopilot.nas file so the parsing of the nasal code wouldn't have to happen each frame (even though it is lightning fast.) :-) I think a hack is the way to go, and if we can use Nasal to do it we can implement this hack, the one-eighty-hack and any other hack that we might need. By the way, did you get my reply with answers and the updated PID algorithm?? I'm not sure I got through your spam-filter. Yes that got through, thanks. For what it's worth, looking at my spam filter, I see that it is catching 1 new spam message every 7 minutes on average. It's no fun being this popular. :-( I'm guessing I do lose a legit email now and then, but a new spam message every 7 minutes all day every day just isn't anything I could deal with manually. 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] New autopilot
Roy Vegard Ovesen [EMAIL PROTECTED] said: On Tue, 27 Jan 2004 09:38:17 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: Right now we have limits built into the altitude hold modules. For instance, for the C172, I don't want to command a climb if the speed is less that 70 kts. So I take the target climb rate and tail that off to zero as the speed goes down to 70. It's a hack I know, but it seems to help. Is there a better way to do that anyway given a generic pid algorithm? Would we want to build in hooks to the generic pid algorithm so we can set up these sorts of limits? I don't think this should be part of the PID algorithm. I think we should use your hack and apply it to the setpoint to the v/s or pitch. This means that we need some sort of if ... then functionality. I just started looking at Nasal, and I think that could be used for summing, gaining, if...then, etc. You are right, it shouldn't. But it should be in a C++ subclass that calls the PID algorithm. We really should end up with something people can understand easily. Ideally we could provide an interface so that people who really want to work within the black box can, while others could work with a less flexible interface and still achieve a reasonable level of realism. I feel that approach would, in part, help attract more modelers to FlightGear. For the more sophisiticated users, Nasal is an excellent choice for involved custom wrappers to access the PID logic. I think a design that incorporates that might give us the best of both worlds, so to speak. But to go back to the C172 example, does anyone actually understand how this issue is handled in a cessna autopilot or any of the others that might be installed in a 172? Will it stall the aircraft? Or...hmmm...trying to remember... does the 172 even have an AP for the pitch axis? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot
Hi All As one of only a few people who have built an autopilot for FG.I would ask what the perseved problems are with the current system. While I admit there are improvements to be made What is there is pretty good. At the risk also of seeming rude I would ask what experence the people who are proposing changes to the autopilot/autothrottle systems have in this area. If someone is keen to code up a system then may I suggest a Flight Management System.FG could realey use one of these.Failing that maybe a weather radar Jon Berndt writes ../roll-rate -++---+ /controls/elevator ../yaw-rate -+-- | Autopilot | -- /controls/ailerons ../heading -++---+ /controls/... My 707 course notes indicate 14 inputs and 6 outputs What's inside the black box? That's what I want to configure. Why???.Thats why they are called a black box. And unless you work for Bendix/King or one of the other black box manufactures you will never know.After all what is in the black box is there bread and butter. Yes. Me too. That's why JSBSim does things the way it does! :-) My recommendation is to take this design very slowly, chew on it a while, think about it. You want to do this right the first time. And, again, make it optional. Jon Cheers Innis _ E-mail just got a whole lot better. New 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] New autopilot
Roy wrote: What's inside the black box? That's what I want to configure. Innis replied: Why???.Thats why they are called a black box. And unless you work for Bendix/King or one of the other black box manufactures you will never know.After all what is in the black box is there bread and butter. First, For some aircraft the autopilot block diagrams can be found. For those it would be nice to be able to model the autopilot mechanization as closely as possible. Second, for some other aircraft the mechanization of the autopilot might be proprietary (or even classified), but the designers might want to use FlightGear to test the implementation (even though the general public would never see the result). Third - and this happens for JSBSim periodically - a student or researcher might want to use building blocks to design a special purpose autopilot or flight control system (or a portion of one) for a thesis or other paper in an academic setting. Most people probably won't care to what level of detail the autopilot functionality is mechanized in FlightGear. However, once a general purpose heading A/P is crafted, or a wing leveler, etc., then those items as specified in a configuration file could be reused. They could also be easily tweaked. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
I agree with Jon. JSBSim (and possibly others) seems to be a notable flightdynamics model even in research. It will be better not to restrict posibilities in the area of modelling planes with their flightcontrol systems including the autopilots behavour. Greetings Mathias Roy wrote: What's inside the black box? That's what I want to configure. Innis replied: Why???.Thats why they are called a black box. And unless you work for Bendix/King or one of the other black box manufactures you will never know.After all what is in the black box is there bread and butter. First, For some aircraft the autopilot block diagrams can be found. For those it would be nice to be able to model the autopilot mechanization as closely as possible. Second, for some other aircraft the mechanization of the autopilot might be proprietary (or even classified), but the designers might want to use FlightGear to test the implementation (even though the general public would never see the result). Third - and this happens for JSBSim periodically - a student or researcher might want to use building blocks to design a special purpose autopilot or flight control system (or a portion of one) for a thesis or other paper in an academic setting. Most people probably won't care to what level of detail the autopilot functionality is mechanized in FlightGear. However, once a general purpose heading A/P is crafted, or a wing leveler, etc., then those items as specified in a configuration file could be reused. They could also be easily tweaked. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Mathias Fröhlich, e-mail: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot
Hi Jon Jon Berndt writes Most people probably won't care to what level of detail the autopilot functionality is mechanized in FlightGear. However, once a general purpose heading A/P is crafted, or a wing leveler, etc., then those items as specified in a configuration file could be reused. They could also be easily tweaked. This is what I dont understand what is wrong with the current system which can do heading,V/S,wing leveler,vor/loc(nav),approach,and autothrottle are these not accurate enough?. Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious reason that the model would bring the computer to a halt.I am just wondering if this in its own way is not doing the same thing. Anyway the one question I would realy like answered is what is wrong with the current system.If the answer is nothing then why change. Famous Saying if it an't broke don't fix it Jon Cheers Innis _ Protect your inbox from harmful viruses with new 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] New autopilot
On 1/27/04 at 10:30 PM Innis Cunningham wrote: Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious Almost certainly neglible compared to the rendering. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Innis Cunningham wrote: This is what I dont understand what is wrong with the current system which can do heading,V/S,wing leveler,vor/loc(nav),approach,and autothrottle are these not accurate enough?. Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious reason that the model would bring the computer to a halt.I am just wondering if this in its own way is not doing the same thing. Anyway the one question I would realy like answered is what is wrong with the current system.If the answer is nothing then why change. Famous Saying if it an't broke don't fix it Functionally the current autopilot is ok, but the underlying algorithm is very basic. Also, if you look through the code, it is a big hairy mess. And this was after a rewrite of the original C version. The problem is that we need to do more with the autopilot than what it's doing right now. For instance I want to be able to hold a specific pitch, or hold a specific speed with pitch. I might also want to hold a target roll rate (like 1 degree/sec) for 20 seconds. It would be possible to paste this onto the current system, but it's already a big mess of code in there and this will make just make the problem worse. I understand that if it aint broke, don't fix it but if I have to mess with a mess, I like to clean it up. :-) That's not to say anything negative about the current autopilot contributors. Just that I think the required functionality had long ago outgrown the infrastructure we had setup and so as people have added things, it's become quite a jumble. Also, we have several people here knowledgable in the field of control theory and people that understand how autopilots are supposed to work. Add that in with someone who (thinks he) understands the internals of FG and I think we have an opportunity to really improve the entire auto pilot infrastructure. That's where I'm coming from anyway ... 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] New autopilot
Roy Vegard Ovesen wrote: On Mon, 26 Jan 2004 13:13:44 -, Richard Bytheway [EMAIL PROTECTED] wrote: That would be the responsibility of the autopilot designer. If he/she designed a control structure that used two separate controllers that acted on the ailerons, that would be his/her problem. In fact it might turn out to be a good thing. ;-) Does this imply that we also need a summer class/unit/module which can take the outputs from various controllers and sum them to feed to the actuator? Yes, a summer class/unit/module would be a handy tool. A gain class/unit/module would also be usefull. This would be for control mixing, right? Elevons, ailerators, thrudders, and, flailerons, and that sort of stuff? This should be a fairly straightforward extension to the current system I am working on. Now I have a question for the expert. I see two issues, and I'm curious about the best way to solve them. Right now we have limits built into the altitude hold modules. For instance, for the C172, I don't want to command a climb if the speed is less that 70 kts. So I take the target climb rate and tail that off to zero as the speed goes down to 70. It's a hack I know, but it seems to help. Is there a better way to do that anyway given a generic pid algorithm? Would we want to build in hooks to the generic pid algorithm so we can set up these sorts of limits? As I understand it, the autothrottle predicts the airspeed 10 seconds ahead of time, and uses that as the input. Would the differential component of the PID algorithm be able to account for this? Would we want some code someplace that puts the predicted speed into the property tree for the generic pid algorithm to use, or would we want to build in some sort of property prediction ability into the pid algorithm (in case the 'd' component doesn't quite do what we want?) 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] New autopilot
This is what I dont understand what is wrong with the current system which can do heading,V/S,wing leveler,vor/loc(nav),approach,and autothrottle are these not accurate enough?. Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious reason that the model would bring the computer to a halt.I am just wondering if this in its own way is not doing the same thing. Anyway the one question I would realy like answered is what is wrong with the current system.If the answer is nothing then why change. Famous Saying if it an't broke don't fix it Disclaimer: I don't fully understand the current autopilot system, but I think I get the gist of the new proposal. As I understand it, the proposal is to rework the autopilot so that it is configurable within the XML for each aircraft, rather than being buried in the C++ code. To do this, there is a need for a controller that is XML configurable, which can have inputs, outputs and magic numbers associated either with entries in the property tree, or fixed in the XML. It makes sense to implement as few types of controller as possible, and make them as flexible as possible. A PID controller does everything we need for simple controllers (wing leveller by aileron, or speed by throttle for instance), and can be stacked (or cascaded) for more complex situations. It can also have the I and/or D components set to 0 if you want a P, PI or PD only controller. We might also need some simple auxiliary units, such as a summer and a limiter, although these could probably be combined into a summer which has the ability to clip the output. There is nothing in the proposal that would make use of this system compulsory. The current system isn't broken, it just isn't as easy to set up, or as flexible as a system could be. Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Tue, 27 Jan 2004 18:18:36 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: Why???.Thats why they are called a black box. And unless you work for Bendix/King or one of the other black box manufactures you will never know.After all what is in the black box is there bread and butter. If nobody knows what's inside the autopilot, how can we make one? I want do design the black box, that is the kind of flexibility I'm looking for. Besides, I don't think it makes sense to have black boxes in an open source project. ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Tue, 27 Jan 2004 22:30:17 +0800, Innis Cunningham [EMAIL PROTECTED] wrote: This is what I dont understand what is wrong with the current system which can do heading,V/S,wing leveler,vor/loc(nav),approach,and autothrottle are these not accurate enough?. I'm sure the performance of the current autopliot system is very good. But I think that it's not very flexible. Also how much more computing power will be required for what ever extra detail may be involved.A 3D modeller would not even think of modeling the insides of the engine or every rivit in the aircraft for the obvious reason that the model would bring the computer to a halt.I am just wondering if this in its own way is not doing the same thing. Anyway the one question I would realy like answered is what is wrong with the current system.If the answer is nothing then why change. Here is my list of things that I think are wrong or should I say bad: * All aircraft have the same autopilot * Some functions are missing, like pitch-hold, and my favourite: aoa-hold ;-] * You can't tune the controllers By tuning I mean the manipulation of the proportional-, integral- and derivate-gains to achieve stability and smoothness. * Recognizing that there are a number of different strategies to implement a wing-leveler, or any other function, you are tied to the one that is hardcoded in C++. * The controller algorithm don't have integrator anti-windup (wich I consider essential) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Just a bit more grist for the mill - as if it were needed:) One of the type of up-coming generations of a/c are likely to be controlled by thrust alone. No moving control surfaces and probably tailess. What I haven't figured out yet is if the concept's relying upon a very simple aerodynamic model, with lots of excess thrust, in which case simulating it might be possible(?), or it might rely upon clever aerodynamics, which I would have thought would be pretty difficult to simulate. But bearing that in mind, the AP design and structure will need to be flexible enough to work with these sorts of a/c control systems. I guess it also touches on the area of missile control systems too. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot: Propulsion only FCS
My understanding is that they will be doing a lot of thrust vectoring ... lots of research is/has been done in that area. Curt. No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion only: http://www.dfrc.nasa.gov/DTRS/1999/PDF/H-2331.pdf Differential thrust (per side) induces a sideslip - induces roll. Changes in thrust (thrust line offset from CG in Z) induces pitch changes as well as accel/decel. Etc. Again, this is something that the JSBSim FCS components could handle - you need building blocks. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot: Propulsion only FCS
No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion only: I meant No thrust vectoring is necessary, nor used in the examples in the referenced paper. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot: Propulsion only FCS
Jon Berndt wrote: My understanding is that they will be doing a lot of thrust vectoring ... lots of research is/has been done in that area. Curt. No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion only: http://www.dfrc.nasa.gov/DTRS/1999/PDF/H-2331.pdf Differential thrust (per side) induces a sideslip - induces roll. Changes in thrust (thrust line offset from CG in Z) induces pitch changes as well as accel/decel. Etc. Again, this is something that the JSBSim FCS components could handle - you need building blocks. I thought some were discussing this in the context of fighters of the future. Just ignore me. :-) 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] New autopilot: Propulsion only FCS
I thought some were discussing this in the context of fighters of the future. Just ignore me. :-) Curt. Oops. Yes, that has been done, most recently on an F-15 I believe. I must have misinterpreted the context of the discussion. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot: Propulsion only FCS
On Wednesday 28 January 2004 02:26, Jon Berndt wrote: My understanding is that they will be doing a lot of thrust vectoring ... lots of research is/has been done in that area. Curt. No. This paper describes tests on a B-747, C-17, and MD-11 using propulsion only: http://www.dfrc.nasa.gov/DTRS/1999/PDF/H-2331.pdf Differential thrust (per side) induces a sideslip - induces roll. Changes in thrust (thrust line offset from CG in Z) induces pitch changes as well as accel/decel. Etc. Again, this is something that the JSBSim FCS components could handle - you need building blocks. Jon I think I've heard of some of the stuff Curt's referring to - the next gen US fighters are planned to be thrust vectoring only. Taking the control surface stuff out of the wing removes channeling, making it more simple but also stronger and more resiliant to damage - you don't have to worry about the control surfaces getting damaged. Infact, the entire wing could sustain a lot of damage but as long as there's something there, it'd probably be flyable with such a control system. The planiforms I've seen have been trapizoidal, with an area cut out of the middle, along the fuselage! No tail surfaces, just vectoring thrust. Landing must be a laugh - difficult to imagine landing without flaps - very high AoA perhaps. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot: Propulsion only FCS
Lee wrote: I think I've heard of some of the stuff Curt's referring to - the next gen US fighters are planned to be thrust vectoring only. Taking the control surface stuff out of the wing removes channeling, making it more simple but also stronger and more resiliant to damage - you don't have to worry about the control surfaces getting damaged. Infact, the entire wing could sustain a lot of damage but as long as there's something there, it'd probably be flyable with such a control system. The planiforms I've seen have been trapizoidal, with an area cut out of the middle, along the fuselage! No tail surfaces, just vectoring thrust. Landing must be a laugh - difficult to imagine landing without flaps - very high AoA perhaps. LeeE http://www.nawcad.navy.mil/strike/projects/x31.cfm http://www.nawcad.navy.mil/strike/projects/fall2001/x31_fall2001.cfm (4 MB, X-31 landing) http://www.dfrc.nasa.gov/Gallery/Movie/X-31/Medium/EM-0036-04.mpg (800 KB, X-31 post-loop stall; this one will blow you away) http://www.dfrc.nasa.gov/Gallery/Movie/X-31/Medium/EM-0036-08.mov (350 KB, Mongoose manuever; this one will blow you away more) http://www.dfrc.nasa.gov/Gallery/Movie/X-31/Medium/EM-0036-05.mov ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Hi Curt Curtis L. Olson writes Also, we have several people here knowledgable in the field of control theory and people that understand how autopilots are supposed to work. Add that in with someone who (thinks he) understands the internals of FG and I think we have an opportunity to really improve the entire auto pilot infrastructure. That's where I'm coming from anyway ... Ok in that case I hope we end up with a great autopilot. Although I am wondering if a basic autopilot for a light plane, a commercial jet,a fighter and other types would be the same. or would you need a separate one for each class. The things I found I can't do with the current setting is hold pitch angle,hold angle of attack,hold roll rate,But as all these things are in the property tree I would have thought it would be easy enough to add them to the autopilot locks property. Maybe not. It is my understanding that most commercial aviation autopilots have a set roll rate,yaw rate and pitch rate. Is this not the case Regards, Curt. Cheers Innis _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot
That would be the responsibility of the autopilot designer. If he/she designed a control structure that used two separate controllers that acted on the ailerons, that would be his/her problem. In fact it might turn out to be a good thing. ;-) Does this imply that we also need a summer class/unit/module which can take the outputs from various controllers and sum them to feed to the actuator? Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Mon, 26 Jan 2004 13:13:44 -, Richard Bytheway [EMAIL PROTECTED] wrote: That would be the responsibility of the autopilot designer. If he/she designed a control structure that used two separate controllers that acted on the ailerons, that would be his/her problem. In fact it might turn out to be a good thing. ;-) Does this imply that we also need a summer class/unit/module which can take the outputs from various controllers and sum them to feed to the actuator? Yes, a summer class/unit/module would be a handy tool. A gain class/unit/module would also be usefull. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Roy Vegard Ovesen [EMAIL PROTECTED] said: I disagree. I think we should have one generic controller class. Remember that we don't want to control the ailerons, we want to control the roll angle or the turn rate through the ailerons. We tell the controller that we want 20 degrees left bank angle and then the controller figures out what aileron deflection is required. We don't tell the controller that we want 7 degrees aileron deflection, that we can (easily) do with the stick. In the same way we want to control the pitch or the vertical speed through the elevator, we don't want to control the elevator. My point is that there are usually more than one thing that can be controlled through the various control-surfaces. And it would then be limiting the flexibility if there were a specific controller for the ailerons that used roll angle as it's set-point/reference/desired value. That has nothing at all to do with what I said. We are controlling individual control surfaces. Period. I don't think we should have subclasses for each desired action/process. Only each control surface type. Roll control ends up being intrinsically part of aileron control is it not? Pitch control is intrinsically part of elevator control, regardless of whether you are targeting speed or pitch (maybe you are confusing control targets with outputs?). The variable input sources and targets and how those are handled are all that needs to be configured per instance. Keeping it to that will make the configuration process much simpler. Let me propose an altitude-hold control structure using generic PID controllers: First off I would control the vertical speed through the elevator control-surface: Desired Vertical Speed--PID Controller--Elevator ^ | Sensed Vertical Speed The output of the PID-Controller would have to be limited to the elevator-deflection angle limitations of the particular aircraft. Actually I would set the limits a bit below the limitations of the aircraft. Now I can set the Desired Vertical Speed to what I want. It is my responsibility to set it to a value that I know/think the aircraft is capable of. Now, in order to climb to my desired altitude I would need a positive Vertical Speed. So I design a structure that controls altitude through Vertical Speed. If I want higher altitude I demand positive Vertical Speed etc. This leads to the final control structure: Desired Altitude--PID--Desired Vertical Speed--PID--Elevator ^ ^ | | Sensed AltitudeSensed Vertical Speed The output from the first PID controller offcourse has to be limited to the vertical speed capabilities of the aircraft. If its not, the first PID will demand more vertical speed than the aircraft can handle. Now it becomes the pilot's resposibility to limit the Desired Altitude within the capabilities of the aircraft. Note that the two PID controllers in this example are of the same generic class. There is no principal differense between the controller that controls the Vertical Speed and the one that controls Altitude. The two controllers have to be tuned to achieve stability and smoothness. They do not interoperate. Generally you will operate the system in a climb or descent mode using various techiniques (pitch hold, vs target, etc). Altitude hold is queued in ARM mode (armed) to take effect when the aircraft reaches an altitude that is within X feet of the target. At which time it switches to an altitude hold mode. AFAIK there are some aircraft that will even fly into the ground if you setup a descent and ARM a target altitude above where the aircraft is. In any case there is only one system function controlling the elevator at a time and V/S and ALT HLD are two seperate functions that are, as you mentioned, often configured to operate according to the aircraft's capabilities. Best regards, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Mon, 26 Jan 2004 16:21:19 - Jim Wilson [EMAIL PROTECTED] wrote: That has nothing at all to do with what I said. We are controlling individual control surfaces. Period. I don't think we should have subclasses for each desired action/process. Only each control surface type. Roll control ends up being intrinsically part of aileron control is it not? Pitch control is intrinsically part of elevator control, regardless of whether you are targeting speed or pitch (maybe you are confusing control targets with outputs?). The variable input sources and targets and how those are handled are all that needs to be configured per instance. Keeping it to that will make the configuration process much simpler. I'm not sure if this makes a difference for what you are referring to, but it's not necessarily that cut-and-dried. For an aircraft with no H-Tail (like the shuttle), both roll and pitch control are managed with elevons. For an aircraft like the F-14 (IIRC) roll is managed with differential H-Tail, as well as spoilers. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Jim Wilson wrote: That has nothing at all to do with what I said. We are controlling individual control surfaces. Period. I don't think we should have subclasses for each desired action/process. Only each control surface type. Roll control ends up being intrinsically part of aileron control is it not? I'm half with you. We certainly don't want separate subclasses for every conceivable action, that's madness. But assuming a set number of standard control surfaces isn't right either. A helicopter has roll control yet no ailerons. The harrier has ailerons *and* roll jets, with an autostabilizer that uses both depending on conditions. I'd strongly suggest an architecture where the autopilot specifies a black box, with all input and output done via property nodes: ../roll-rate -++---+ /controls/elevator ../yaw-rate -+-- | Autopilot | -- /controls/ailerons ../heading -++---+ /controls/... No control system assumptions in the C++ type system, and it's still perfectly configurable. Just remap the input and output nodes per-aircraft if you want, maybe via an override in the -set.xml file. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: That has nothing at all to do with what I said. We are controlling individual control surfaces. Period. I don't think we should have subclasses for each desired action/process. Only each control surface type. Roll control ends up being intrinsically part of aileron control is it not? I'm half with you. We certainly don't want separate subclasses for every conceivable action, that's madness. But assuming a set number of standard control surfaces isn't right either. A helicopter has roll control yet no ailerons. The harrier has ailerons *and* roll jets, with an autostabilizer that uses both depending on conditions. I'd strongly suggest an architecture where the autopilot specifies a black box, with all input and output done via property nodes: ../roll-rate -++---+ /controls/elevator ../yaw-rate -+-- | Autopilot | -- /controls/ailerons ../heading -++---+ /controls/... No control system assumptions in the C++ type system, and it's still perfectly configurable. Just remap the input and output nodes per-aircraft if you want, maybe via an override in the -set.xml file. Good point (as is Jon's) but in all such design cases there are tradeoffs. What I'm looking at is ease of configuration and that may be a reasonable tradeoff against the limitations of defining a standard set of control surface subclasses (i.e. having to add a special case for the harriers rather unique feature). It could also be possible to design in a way that allows both the complex approach to configuring generic controllers and a set of subclasses for simplified configuration of more standard aircraft. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Mon, 26 Jan 2004 17:42:02 - Jim Wilson [EMAIL PROTECTED] wrote: Good point (as is Jon's) but in all such design cases there are tradeoffs. What I'm looking at is ease of configuration and that may be a reasonable tradeoff against the limitations of defining a standard set of control surface subclasses (i.e. having to add a special case for the harriers rather unique feature). It could also be possible to design in a way that allows both the complex approach to configuring generic controllers and a set of subclasses for simplified configuration of more standard aircraft. Whatever is done needs to be bypass-able, if desired - which, I suspect it will be, simply by defining _no_ autopilot in Flightgear configuration files for an aircraft. We (JSBSim) already have all this capability for ourselves. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
Hi, That has nothing at all to do with what I said. We are controlling individual control surfaces. Period. I don't think we should have subclasses for each desired action/process. Only each control surface type. Roll control ends up being intrinsically part of aileron control is it not? Pitch control is intrinsically part of elevator control, regardless of whether you are targeting speed or pitch (maybe you are confusing control targets with outputs?). The variable input sources and targets and how those are handled are all that needs to be configured per instance. Keeping it to that will make the configuration process much simpler. That's not entirely true. For example (AFAIK) B-727 uses ailerons as a means of roll control on lower speeds, and speed brakes on higher speeds. The other example might be MU-2, AC that relies entirely on speedbrakes for roll control (i.e no ailerons at all). ciao, Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Mon, 26 Jan 2004 16:21:19 -, Jim Wilson [EMAIL PROTECTED] wrote: That has nothing at all to do with what I said. We are controlling individual control surfaces. Period. I don't think we should have subclasses for each desired action/process. Only each control surface type. Do you mean a different controller algorithm for the different control surfaces? Or do you mean a different configuration for each control surface? I think we are misunderstandig eachother. Let me try to show what I think that you mean. Say we have two controllers, one is acting on the ailerons and one acting on the elevator. The one acting on the ailerons allows us to set a desired roll angle. The one on the elvator to set a desired pitch angle. Now do you mean that there should be any differences in the algorithms of these two controllers because they are controlling different control surfaces? They do not interoperate. On my Altitude Holder Deluxe[TM] they do. :-) Generally you will operate the system in a climb or descent mode using various techiniques (pitch hold, vs target, etc). Altitude hold is queued in ARM mode (armed) to take effect when the aircraft reaches an altitude that is within X feet of the target. At which time it switches to an altitude hold mode. AFAIK there are some aircraft that will even fly into the ground if you setup a descent and ARM a target altitude above where the aircraft is. That's another strategy. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New autopilot
On Mon, 26 Jan 2004 09:10:23 -0800, Andy Ross [EMAIL PROTECTED] wrote: I'd strongly suggest an architecture where the autopilot specifies a black box, with all input and output done via property nodes: ../roll-rate -++---+ /controls/elevator ../yaw-rate -+-- | Autopilot | -- /controls/ailerons ../heading -++---+ /controls/... What's inside the black box? That's what I want to configure. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New autopilot
On Mon, 26 Jan 2004 09:10:23 -0800, Andy Ross [EMAIL PROTECTED] wrote: I'd strongly suggest an architecture where the autopilot specifies a black box, with all input and output done via property nodes: Elaborate? ../roll-rate -++---+ /controls/elevator ../yaw-rate -+-- | Autopilot | -- /controls/ailerons ../heading -++---+ /controls/... What's inside the black box? That's what I want to configure. Roy Vegard Ovesen Yes. Me too. That's why JSBSim does things the way it does! :-) My recommendation is to take this design very slowly, chew on it a while, think about it. You want to do this right the first time. And, again, make it optional. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
