Roy Vegard Ovesen <[EMAIL PROTECTED]> said: > 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.
That has nothing at all to do with what I said. We are controlling individual control surfaces. Period. I don't think we should have subclasses for each desired action/process. Only each control surface type. Roll control ends up being intrinsically part of aileron control is it not? Pitch control is intrinsically part of elevator control, regardless of whether you are targeting speed or pitch (maybe you are confusing control targets with outputs?). The variable input sources and targets and how those are handled are all that needs to be configured per instance. Keeping it to that will make the configuration process much simpler. > 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 Speed > > The 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 Speed > > The 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. They do not interoperate. Generally you will operate the system in a climb or descent mode using various techiniques (pitch hold, vs target, etc). Altitude hold is queued in ARM mode (armed) to take effect when the aircraft reaches an altitude that is within X feet of the target. At which time it switches to an altitude hold mode. AFAIK there are some aircraft that will even fly into the ground if you setup a descent and ARM a target altitude above where the aircraft is. In any case there is only one system function controlling the elevator at a time and V/S and ALT HLD are two seperate functions that are, as you mentioned, often configured to operate according to the aircraft's capabilities. Best regards, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
