These are all controllers for ailerons, elevators, rudders, etc. A small and
easily definable set which is ideal for subclassing. Maybe we could have a
subclass for each of these controls rather than trying to abstract a generic
controller class.
I disagree. I think we should have one generic controller class. Remember that we don't want to control the ailerons, we want to control the roll angle or the turn rate through the ailerons. We tell the controller that we want 20 degrees left bank angle and then the controller figures out what aileron deflection is required. We don't tell the controller that we want 7 degrees aileron deflection, that we can (easily) do with the stick.
In the same way we want to control the pitch or the vertical speed through the elevator, we don't want to control the elevator.
My point is that there are usually more than one thing that can be controlled through the various control-surfaces. And it would then be limiting the flexibility if there were a specific controller for the ailerons that used roll angle as it's set-point/reference/desired value.
Then these could have both generic and unique properties
that are somewhat easier to configure.
The xml for the AP configuration would
include a controller-type property that would imply certain characteristics
(such as integrating roll limits in the aileron controller).
Every controller would need limits in its output because when you think about it every actuator, be it ailerons, elevator, rudder, thrust, etc. has a limit.
It will also be important not to have more than one controller for a given type active at any one time.
That would be the responsibility of the autopilot designer. If he/she designed a control structure that used two separate controllers that acted on the ailerons, that would be his/her problem. In fact it might turn out to be a good thing. ;-)
Let me propose an altitude-hold control structure using generic PID controllers:
First off I would control the vertical speed through the elevator control-surface:
Desired Vertical Speed-->PID Controller-->Elevator
^
|
Sensed Vertical SpeedThe output of the PID-Controller would have to be limited to the elevator-deflection angle limitations of the particular aircraft. Actually I would set the limits a bit below the limitations of the aircraft. Now I can set the Desired Vertical Speed to what I want. It is my responsibility to set it to a value that I know/think the aircraft is capable of.
Now, in order to climb to my desired altitude I would need a positive Vertical Speed. So I design a structure that controls altitude through Vertical Speed. If I want higher altitude I demand positive Vertical Speed etc. This leads to the final control structure:
Desired Altitude-->PID-->Desired Vertical Speed-->PID-->Elevator
^ ^
| |
Sensed Altitude Sensed Vertical SpeedThe output from the first PID controller offcourse has to be limited to the vertical speed capabilities of the aircraft. If its not, the first PID will demand more vertical speed than the aircraft can handle. Now it becomes the pilot's resposibility to limit the Desired Altitude within the capabilities of the aircraft.
Note that the two PID controllers in this example are of the same generic class. There is no principal differense between the controller that controls the Vertical Speed and the one that controls Altitude.
The two controllers have to be tuned to achieve stability and smoothness.
-- Roy Vegard Ovesen
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
