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 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 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
[Flightgear-devel] New Autopilot Documentation
Roy Vegard Ovesen wrote: I've slapped together a short document on controller tuning. [ snip ] Thanks Roy! 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. :-) The last two sections of the document describe the autopilot configuration file format and provides some specific tips for tuning the PID modules to work well for your specific aircraft. There is a generic/example autopilot configuration which all aircraft will inherit by default. So, aircraft designers don't necessarily need to create something from scratch. 99% of the time you should be able to copy an existing configuration from a similar aircraft and mostly be 99% done before you've even started. But we need to boot strap ourselves and get a few well working config files for the various classes of aircraft before my previous statement is 99% true. :-) 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. -- 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
