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
