James Turner <[EMAIL PROTECTED]> said: > > c. Heading Select (HDG-SEL) uses ailerons to turn toward heading bug (or > > setting from FMC). Switches to active Heading Hold when target reached. > > Changing heading bug after Heading Hold is active requires initiating > > HDG-SEL > > again (won't automatically go there like it does now). > > This needs to be configurable, most HDG modes I've 'used' on big jets > remain live, i.e if you spin the heading bug, they track immediately. > It's possible there is a ALT mode out there that does the same thing > (though that would be pretty crazy, I admit)
Ok I'll probably do that with HDG for now. > > d. Heading NAV Arm (HDG-NAV1-ARM, HDG-NAV2-ARM) Maintain HDG (Heading > > Hold) or > > Wing Leveler (WL) until radial is intercepted. Upon interception, > > automatically switch to active HDG-NAV1 or HDG-NAV2. Note that on ILS > > this > > will be synonymous with APR ARM and APR mode which will also arm for GS. > > The intercept conditions need to be programmable. Also, the mode may not > engage at all based on criteria in some systems. Example: the 777's NAV > mode will not engage if the CDI is greater than some value (2nm?) *and* > the current heading it not an intercept. (at least, according to the > simulation I have used) We can tweak for that. My goal at this point is to change the way the current autopilot blindly switches to 30degrees off the radial in order to create an "interception". > > AXIS 2) Vertical control modes: > look fine > > > > > AXIS 3) Yaw damper: > I am anxious that this be a totally separate system from the autopilot, > it's a very independent system apart from the fact it drives control > surfaces and the switch is usually on the MCP :-) If we ever go as far > as systems modeling at the block level, that's especially the case (yaw > dampers usually have separate gyros, and sometimes separate inputs to > the control surface actuator servos) It is and it isn't a seperate system. If I'm not mistaken it is controlled by the autopilot on most aircraft. But probably doesn't have anything to do with the flight computer. It is engaged seperately and runs without any of the ap modes engaged. As I said, for now it'll just be simplistic using the current method of coordinating with aileron movements (and therefore only "active" when autopilot is engaged). > > > > Engage: > > > > Upon engagement the autopilot will begin processing any preselected > > modes > > (limited to one Arm and one Active mode per axis at a time). If no > > mode is > > preselected then vertical will default to PITCH and lateral will > > default to > > HDG-HLD. It may be desirable to have these defaults configurable, > > since some > > autopilots may default to either ALT HLD for vertical or WL for lateral. > Definitely. Also note that we're going to need some ability to reject > engagement of modes altogether, so there is really a multi-stage set of > the conditions for each mode: Well the only condition that I'm aware of is some ga autopilots won't engage during flight if "TEST mode" was not run on the ground :-). I believe it is up to the flight computer to calculate more complex conditions. Of course if there are disengage conditions then the effect would be the same. Also, implictly there can only be one Active and one Arm mode for each axis (doesn't need to be configurable). > - conditions to transition to another mode (largely an FMC problem, but > it does interact I suspect) Arm modes implicitly have a transition which will be defined. The FMC would handle more complex transitions such as those run during LAND modes. > > The autopilot will be able to disengage. Certain conditions will > > require it. > > Suggestions on how to specify conditions would be welcome. Note that > > the > > current autopilot will reduce pitch to prevent a stall (as "min climb" > > is > > approached). I believe that the more correct behavior would be to > > disengage > > once airspeed reaches a certain minimum. Some aircraft have other > > automated > > stall prevention measures (e.g. automatic nose dropping on aircraft > > that are > > incapable of stall recovery), but those involve separate systems that go > > beyond the scope of typical autopilot functionality. > > Actually, I believe some auto-pilots will just 'kill you' in this > situation :-) So it needs to be configurable for certain. That's right. First pass on this, that's probably what'll happen. But it is something to keep in mind. On the aircraft with some sort of automatic stall prevention, it is separate from the autopilot (could even be a mechanical device on the wings...that makes the nose drop before stall is achieved). Point is it works regardless of who or what is at the controls. > This looks like 90% of what we need (i.e, I can't see anything missing, > but we haven't built it yet :-) Yeah but it looks good :-D I've started layout out the class definition and hope to have at least the lateral working next week. Shouldn't take all that long to finish. Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
