Let me share my thoughts about the autopilot:
* I would like to see the autopilot move from c++ code into the instrument configuration xml-files.
This is my general plan. Right now I have the autopilot config in a separate .xml file
* The autopilot should get input from other instruments (airspeed indicator, altimeter, attitude indicator, etc.), and not from /position/altitude-ft, /velocities/..., etc. That way the wing-leveler would be unuseable if the attitude indicator was "broken". Failures in the underlying instruments and systems would affect the autopilot.
Yup, each autopilot component will be able to take input from any property, and output to any other property. As long as we have the instrument values modeled and placed in the property tree, we can use them. The trick will be for someone who knows a little about autopilots to be able to tell us what inputs drive what functions.
* A PID-controller that can be accessed from the instrument configuration files. This could be used to build the autopilot controller structure as an instrument. This means that one could build different autopilot instruments for different aircraft. The Cub for example might have a simple autopilot with only heading hold and altitude hold. And because the Cub does not have an attitude indicator instrument, a wing-leveler would not be available. And in addition the heading hold would not be allowed to use roll information.
I've been hacking things out here a bit this evening and here's what I've come up with for a simple proportional wing leveler. All of this is in a state of flux, is subject to change, and only exists on my local HD.
I'll intersperse some explanatory comments ...
autopilot.xml:
<proportional>
<name>Wing Leveler (Turn Coordinator based)</name>
<enable>
<!-- enable this component when the defined property equals the
specified value -->
<prop>/autopilot/locks/heading</prop>
<value>wing-leveler</value>
</enable>
<input>
<!-- the input source -->
<prop>/instrumentation/turn-indicator/indicated-turn-rate</prop>
</input>
<target>
<!-- what we want to drive the input value to, this can also be a
property name -->
<value>0.0</value>
</target>
<output>
<!-- the output property name -->
<prop>/controls/flight/aileron</prop>
</output>
<config>
<!-- output = (target - input) * factor + offset -->
<factor>0.5</factor>
<!-- I don't know if it makes sense to offer an offset here, but it's
easy to add and I've seen similar things other places in the
code so I stuck it in. -->
<offset>0.0</offset>
<post>
<!-- I might be better off moving this to the output section, but
this lets us clamp the output result -->
<clamp>
<min>-1.0</min>
<max>1.0</max>
</clamp>
</post>
</config>
</proportional>So if you set /autopilot/locks/heading = wing-leveler, this component will become active and start driving the turn rate to zero using the ailerons.
Here's a more complicated two stage heading bug follower (still using simple proportional control):
<!-- this first stage calculates a target roll degree based on the
difference between our current heading and the heading bug
heading. It writes the result to a temporary property name. This
temp property is the input to the second stage. Both stages use the
same enable property and value. -->
<proportional>
<name>Heading Bug Hold (DG based) Calc Target Roll</name>
<enable>
<prop>/autopilot/locks/heading</prop>
<value>dg-heading-hold</value>
</enable>
<input>
<prop>/instrumentation/heading-indicator/indicated-heading-deg</prop>
</input>
<target>
<prop>/autopilot/settings/heading-bug-deg</prop>
</target>
<output>
<!-- I just made up this property name -->
<prop>/autopilot/internal/target-roll-deg</prop>
</output>
<config>
<!-- this is an obvious hack that I'm not real comfortable with. It
maps the resulting "error" term to +/- 180 by adding or
subtracting 360 until the value get's into that range. -->
<pre>
<one-eighty>true</one-eighty>
</pre>
<factor>1.5</factor>
<offset>0.0</offset>
<post>
<clamp>
<min>-30.0</min>
<max>30.0</max>
</clamp>
</post>
</config>
</proportional> <!-- this second stage calculates the aileron deflection needed to
achieve the previously calculated target roll degrees. -->
<proportional>
<name>Heading Bug Hold (DG based) (Calc target ailerons)</name>
<enable>
<prop>/autopilot/locks/heading</prop>
<value>dg-heading-hold</value>
</enable>
<input>
<prop>/orientation/roll-deg</prop>
</input>
<target>
<!-- this matches the output property name from the first stage -->
<prop>/autopilot/internal/target-roll-deg</prop>
</target>
<output>
<prop>/controls/flight/aileron</prop>
</output>
<config>
<factor>0.05</factor>
<offset>0.0</offset>
<post>
<clamp>
<min>-1.0</min>
<max>1.0</max>
</clamp>
</post>
</config>
</proportional>So that's what I've come up with so far. Am I completely nuts? Any suggestions? I have no formal education in control theory, so what I know has been gleaned from here and there so I probably don't know much of the correct terminology and there are certainly tricks and things that I'm not aware of.
I'm hoping to do a good job of roughing in the flexible xml structure and interfacing to flightgear, then get some help on the control theory side from the experts.
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
