James Turner <[EMAIL PROTECTED]> said: > yeah, this is basically what I was expecting, The current auto-pilot > code is a bit hard-coded to use the radio stack for NAV modes, for > example, we need a general course deviation or heading deviation (once > we decide which) input, and then a NAV/GPS toggle on the panels, I guess.
If I'm not mistaken (and I easily could be) the FMC would usually just feed the autopilot heading and speed data when using non-radio-stack "NAV" modes. The FMC monitors the course and the AP only needs to follow the commands from the FMC (heading select, flight level and speed select). Generally AP's aren't all that smart which is why we have computers on board on some aircraft. Even landing modes are basically just rolling to a angle of attack, holding the heading and rolling out on the ground. > There's a sort of sliding scale here: ranging from 1 class + lots of > configuration to no configuration but lots of classes. I'd prefer it if > the auto-pilot was broken down a little so that we could mix and match > pieces, and reduce the number of configuration options. One *possible* > sub-division I imagined was to configure separate blocks to handle each > state/mode. (with default impls of course). The the MCP/FCP buttons > would basically select a different FGAutopilotMode in as the current > (but we might need two in parallel, ... maybe FGAutoLateralMode and > FGAutoVerticalMode? not sure) That's true and I've considered all ranges. Probably I will just stick with one class and subsystem. None of the code is all that involved and developing a more complex structure wouldn't gain all that much in the near term. Fundamentally the modes aren't independant because the AP as a unit has to be able to keep track of all the selections. As mentioned before, configuration will include defining the modes supported by the unit being modeled. If we actually do need more flexibility, then we can simply build a manager class and split things up underneath any way we want. > This allows people (err ... me, I guess) to write FGBoeingFLCHMode and > so on if seems necessary. > > I'm open to other ideas about subdividing the code, I'm just a bit wary > of 'one big class + one big config file'; > It'll work and the config file won't be that bad. I would suggest that FGBowingFLCHMode would be a single command from the FMC to the autopilot. It is a pretty basic autopilot function. The autopilot's xml configuration would define the major attributes for "FL CH" mode: that we're flying to selected altitude and controlling pitch to maintain the speed selected. Other details such as whether a mode is arm type or takes over the axis immediately would be hardcoded for the mode's implementation (they tend not to vary). I'm a little fuzzy though on who's going play the thrust computer and set the flight gear "throttle" value for climb mode. Perhaps we should have an autothrottle class and the FMC would tell the autopilot to do "FL CH" and tell the autothrottle we want climb thrust. > The KLN-89b is designed for GA use (and it's the 'official' manual, not > the manual for a simulation), but it also has much simpler auto-pilot > interactions (basically just driving the HSI, I think) > Great, I'll check these out. Thanks, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
