On Thursday 15 Oct 2009, Johnathan Van Why wrote:
> > It cousnt work like that in the sim. If I want to roll from 180
> > to 27o it turns gently.. in the sim it violently turns the
> > first few degrees..
>
> You mean it immediately slams the ailerons to full deflection?
> I'm sure you could somehow limit that. The simplest method that's
> more advanced than limiting throw is limiting the rate the
> aircraft is commanded to roll. For reference, here's the code
> from the autopilot file: (787-autopilot.xml)
>
> <!-- Heading Bug Hold. 2 stage cascade controller. -->
>
> <!-- Stage #1 sets target roll based on diff between current
> heading --> <!-- and heading bug. -->
> <pid-controller>
> <name>Heading Bug Hold (FDM mag heading based) Stage 1</name>
> <debug>false</debug>
> <enable>
> <prop>/autopilot/locks/heading</prop>
> <value>dg-heading-hold</value>
> </enable>
> <input>
> <prop>/autopilot/internal/fdm-heading-bug-error-deg</prop>
> </input>
> <reference>
> <value>0.0</value>
> </reference>
> <output>
> <prop>/autopilot/internal/target-roll-deg</prop>
> </output>
> <config>
> <Kp>-5.0</Kp> <!-- proportional gain -->
> <beta>1.0</beta> <!-- input value weighing factor -->
> <alpha>0.1</alpha> <!-- low pass filter weighing factor
> --> <gamma>0.0</gamma> <!-- input value weighing factor for -->
> <!-- unfiltered derivative error --> <Ti>10.0</Ti> <!--
> integrator time -->
> <Td>0.00001</Td> <!-- derivator time -->
> <u_min>-30.0</u_min> <!-- minimum output clamp -->
> <u_max>30.0</u_max> <!-- maximum output clamp -->
> </config>
> </pid-controller>
>
> <!-- Stage #2 drives the ailerons to achieve the desired roll
> deg. --> <pid-controller>
> <name>Heading Bug Hold (DG based) Stage 2</name>
> <debug>false</debug>
> <enable>
> <prop>/autopilot/locks/heading</prop>
> <value>dg-heading-hold</value>
> </enable>
> <input>
> <prop>/orientation/roll-deg</prop>
> </input>
> <reference>
> <prop>/autopilot/internal/target-roll-deg</prop>
> </reference>
> <output>
> <prop>/controls/flight/aileron</prop>
> </output>
> <config>
> <Kp>0.1</Kp> <!-- proportional gain -->
> <beta>1.0</beta> <!-- input value weighing factor -->
> <alpha>0.1</alpha> <!-- low pass filter weighing factor
> --> <gamma>0.0</gamma> <!-- input value weighing factor for -->
> <!-- unfiltered derivative error --> <Ti>10.0</Ti> <!--
> integrator time -->
> <Td>0.00001</Td> <!-- derivator time -->
> <u_min>-1.0</u_min> <!-- minimum output clamp -->
> <u_max>1.0</u_max> <!-- maximum output clamp -->
> </config>
> </pid-controller>
>
> You could change the second reference line to:
> <prop>/autopilot/internal/target-limited-roll-deg</prop>
> then make a simple nasal file that takes the delta time (using
> /sim/time/elapsed-sec) and rate-limits the autopilot command like
> so (I can't test this, as my FlightGear doesn't work)
>
> var ratelimit = 10; # degrees per second
> var dtime = 0;
> var time = 0;
> var chg = 0;
> limitroll = func {
> settimer(limitroll, 0);
> dtime = getprop("/sim/time/elapsed-sec") - time;
> time += dtime;
> chg = getprop("/autopilot/internal/target-roll-deg") -
> getprop("/autopilot/internal/target-limited-roll-deg");
> if (chg > ratelimit * dtime) chg = ratelimit * dtime;
> if (chg < -ratelimit * dtime) chg = -ratelimit * dtime;
> setprop("/autopilot/internal/target-limited-roll-deg",
> getprop("/autopilot/internal/target-limited-roll-deg") + chg);
> }
> settimer(limitroll, 0);
>
> This method should work (in theory,) although (as I said before,)
> my FlightGear is not currently working, so I can't test this. It
> may need to be modified.
>
> > The issue is from my point of view is that I can turn into a
> > new heading, violently as a pilot and it will take time to
> > react. The autopilot heading bug does not.. it turn there
> > immedeadetly almost..
>
> The autopilot should simply drive the
> ailerons/elevator/trim/thrust just as a pilot would. The limits
> are the same, although the maximum rate of roll does seem high. I
> believe this is because it is sudden and holds the ailerons in
> their maximum position. Limiting the roll rate like above or
> limiting the aileron throw (the u_min and u_max "tags") should
> fix the problem.
>
> > Precisely the the problem. I think we need to document it as
> > well..
>
> I know there's a document available, at
> http://www.flightgear.org/Docs/XMLAutopilot/. That has
> information about the autopilot's algorithm and tuning. However,
> the most can be learned by combining it and reading through an
> existing autopilot configuration.
>
> I hope this helps.
Rather than use Nasal to limit the roll rate here, I would use a
noise-spike filter instead. To do this...
...add the filter, specifying a suitable max-rate-of-change...
<filter>
<name>Roll rate limiter Filter</name>
<debug>false</debug>
<type>noise-spike</type>
<input>/autopilot/internal/target-roll-deg</input>
<output>/autopilot/internal/target-roll-deg-filtered</output>
<max-rate-of-change>4.0</max-rate-of-change>
</filter>
(This is the filter I used for the AN-225 and it limits the roll
rate to 4 degrees/second - you can experiment to find the best/most
appropriate value)
...and then amend the second stage controller so that it uses the
filtered input...
</input>
<reference>
<prop>/autopilot/internal/target-roll-deg-filtered</prop>
</reference>
Note that the filter will be running all of the time unless you also
include an enabling property. If you want to be able to switch the
filter on and off you should include somethinglike...
<enable>
<prop>/autopilot/locks/heading</prop>
<value>dg-heading-hold</value>
</enable>
in the filter config so that the filter is only active when
dg-heading-hold is engaged.
However, before trying this, you could just see if the cascade can
be tuned a little better by reducing the gains <Kp> in the two
controllers. This will make them less aggressive, but if they're
already optimally tuned you'll get get an over-shoot i.e. the
aircraft will roll beyond the target roll before correcting itself
and coming back to the specified value. If this happens, you
should revert the <Kp> back to the original settings (unless you
also want to start messing around with the other controller
settings, such as <Ti> and <Td>, but be aware that you could be
starting on a long journey here ;-)
Autopilot controller tuning can be (and usually is) a very time
consuming business, but remember that you can try different
settings in flight and don't need to restart FG after changing
something (I strongly advise you to only change one thing at a
time): after you've changed a setting in the autopilot.xml file,
you just need to reload the autopilot from the menu. You'll
probably get a little kick as the autopilot reloads and
initialises, but this is understandable and won't be an issue in
normal use as you shouldn't need to reset the autopilot once you're
happy with it.
A note to all aircraft developers here: it's a good idea to include
a rate parameter in every controller that you use as this should
ensure constant rates across different systems (as long as the
system is capable of achieving the specified rate). You do this by
including a <Ts> entry between the <config> tags i.e. use...
<Ts>0.05</Ts>
... to set a 20Hz rate.
(Although as I mentioned in an earlier post, I'm not sure that the
controller rate control is still working properly)
Heh :) Yet another solution has occurred to me while writing this,
although it would need a new abs (absolute value) filter type...
Feed the current roll value into the abs filter, to ensure a simple
positive value, then feed that into a gain filter to set the gain
on the heading controller cascade. Thus, while the aircraft is
flying level, the gain, and therefore authority, of the
heading/roll controllers is at a minimum but as the degree of roll
increases, the gain of the controllers is increased too, which
increases their authority.
LeeE
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
