Thanks for the updates to xmlauto.cxx.
As well as fixing the reload bug in cvs, the enabled tag for the
filters is very useful.
Would it be possible to add a null filter type i.e. a filter that
acts as a simple pass-though?
The reason I think this would be useful is that it would provide a
very low-cost method of re-routing control inputs between different
sub-systems and controllers - the sort of stuff you really need to
do in Fly-By-Wire/Flight Control Systems.
Also on my wish-list for this area would be the ability to change
some of the pid controller parameters 'in-flight' without having to
re-load the A/P e.g. reducing elevator control gain as airspeed
increases. Because the resolution/frequency of the controllers is
effectively limited by the frame-rate there can be practical
difficulties in tuning a controller to work optimally over wide
ranges such as you'd get with most of the fast jets - typically
~120-150kts during approach and landing up to 700kts (AFAIK YASim
doesn't do supersonic so I don't try to seriously tune for the
supersonic regime).
Just for info, while re-working the YF-23 I've been playing with
using closed feedback loop pid controllers as flight surface and
engine control drivers/servos with some good results:)
The config below is what I'm using as an elevator input driver/servo
(there's also an identical controller for elevator-trim input,
aileron input, rudder input and throttle & reheat control inputs)
and so far it's working pretty well here.
<pid-controller>
<name>Ruddervator Surface Driver</name>
<debug>false</debug>
<enable>
<prop>/autopilot/FCS/locks/elevator</prop>
<value>true</value>
</enable>
<input>
<prop>/autopilot/FCS/controls/flight/elevator-norm</prop>
</input>
<reference>
<prop>/autopilot/FCS/internal/target-elevator-norm</prop>
</reference>
<output>
<prop>/autopilot/FCS/controls/flight/elevator-norm</prop>
</output>
<config>
<Ts>0.05</Ts>
<Kp>0.45</Kp>
<beta>0.00001</beta>
<alpha>0.1</alpha>
<gamma>0.0</gamma>
<Ti>0.05</Ti>
<Td>0.0</Td>
<u_min>-1.0</u_min>
<u_max>1.0</u_max>
</config>
</pid-controller>
I've also found that using more complex controller hierarchies can
help with the 'kick' problem you can get when switching between
different A/P modes. Instead of switching between two entirely
separate two stage controller cascades, with a three or four stage
cascade, you only need to switch the top level controller, or in
some cases switch the top level controller off completely and
re-route the control input further down the cascade. Having common
controllers lower down the hierarchy, which don't change seems to
eliminate most of the 'kicks'
LeeE
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
