On Monday 25 Jan 2010, Pete Morgan wrote: > I'm having a successful time tuning my first autopilot on the > 787. > > I've managed to get rid of the "jerks" and wobbles, mainly by > using a "noise-spike" filter with <max-rate-of-change>. That > thanks to Syd Adams for that wonderful tip. > > All flight level changes, and NAV, heading can be tuned very > well, at the current tuning speed of 250 knots. > > However, at lower and higher speeds, the behaviour changes, > sometimes significantly. > > So it it possible to have two different PID/configs's operating > at different airspeeds.. > > eg in psuedo code > > <config> > {if getprop("airspeed") < 150 } > <Kp>0.07</Kp><beta>0.5</beta> > {else} > <Kp>0.06</Kp><beta>0.3</beta> > {if} > </config> > > Hope it makes sense.. > pete
You can vary the proportional gain of the pid controllers by specifying a property and default value instead of just sticking a fixed value between the <Kp> tags e.g. <Kp> <prop>/autopilot/FCS/settings/example-gain</prop> <value>-0.2</value> </Kp> ...so that the actual value for <Kp> is read from the property tree node /autopilot/FCS/settings/example-gain. A default vaue of -0.2 is written to this node but it can be changed in flight, either by another pid-controller, an autopilot filter or by a Nasal script. Having actually come across this same problem of a pid controller becoming unstable at higher speeds, my choice was to use a reciprocal filter to drive the gain, as the autopilot filters are very efficient and incur very little overhead e.g. <filter> <name>Mach/ruddervator-pitch-trim gain reciprocal filter</name> <debug>false</debug> <enable> <prop>/autopilot/FCS/locks/ruddervator-pitch-trim-gain</prop> <value>true</value> </enable> <type>reciprocal</type> <gain> <prop>/autopilot/settings/pitch-trim-reciprocal-gain</prop> <value>-0.004</value> </gain> <input>/velocities/mach</input> <output>/autopilot/FCS/settings/example-gain</output> <u_min>-0.02</u_min> <u_max>-0.005</u_max> </filter> ...so that the gain value used by the altitude-hold pid-controller is reduced as the Mach value increases. Note that you can also vary the rate at which the pid-controller gain is backed off by varying the filter gain, as that's also taken from a property tree node. Note also that you can vary the <u_min> and <u_max> clamp values for filters and pid-controllers in flight too, by reading them from a property tree node in the same way that you can read and change the gains e.g. <u_min> <prop>/autopilot/FCS/settings/altitude-hold-umin</prop> <value>-200</value> </u_min> <u_max> <prop>/autopilot/FCS/settings/altitude-hold-umax</prop> <value>200</value> </u_max> A word of advice though: you can end up with very complex autopilot configurations (the last one I did was 1256 lines long), with lots of new property tree nodes being referenced, so it pays to think it all through first and get yourself organised so that you can keep track of everything - don't just start adding new nodes etc. willy-nilly. I suggest adding a new parent node beneath /autopilot e.g. /autopilot/FCS and then add all your custom stuff beneath that node instead of just adding lots of new nodes beneath /autopilot. As your autopilot becomes more complex it pays to set up new sub-parent nodes to group together each type of thing you're working with e.g. /autopilot/FCS/settings /autopilot/FCS/targets /autopilot/FCS/controls LeeE ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel