Talk:Aircraft checklists

Reloading

is there any way to reload the checklist without restarting flightgear [1]

Checklists and Replay

With ThorstenB's work on allowing Instant Replay flights to be saved via the flight recorder subsystem detailed in $FG_ROOT/Docs/README.flightrecorder and flights to be continued at a later time, it would seem like a good idea to consider making the replay system aware of checklists supported by the aircraft, so that different aircraft/cockpit configurations can be applied. Supporting such a use-case would drastically improve turnover rates at events like FSWeekend or LinuxTag, i.e. when demonstrating FG to new users. Basically, we would need a way to completely reset the aircraft to a predefined state and then apply a certain checklist.

Checklists & Autostart + limits.nas

Hooray: Based on the end user feedback we've seen on the forums, the autostart feature is another popular (read: important) thing for new users [2]. And that's obviously something else which isn't currently standardized: autostart is implemented in a custom fashion for each aircraft. But using the new checklist system, it would probably even be possible to streamline the implementation of autostart features, simply by providing the raw, properties/scripts, that need to be processed in order to do an autostart. That would mean that autostart could be implemented on top of the checklist system, because it would also use a common/shared XML file that exactly describes how to perform an autostart step-by-step. These steps would then be detailed in the checklist itself - but given that not just the human-readable descriptions are provided, but also the simulator-related actions to perform, an autostart feature could be automatically provided for aircraft that have a full checklist implemented. At that point it would even be possible to add a button to each checklist item to interactively view the necessary step, and perform them just by clicking a button, including other checklists (landing, go-around etc). According to the git logs, User:Zakalawe has recently added state machine support - so that adding an autostart framework on top of the checklists system would seem feasible.

On a related note, I've been wondering whether we should start the sim with the engines running when starting from a runway. Being on the runway with the engine off isn't particularly realistic. If we were feeling particularly keen also having the altimeter set and the radios tuned to the tower frequency might be nice. Ah, that's a much more contentious one. The problem, from my point of view, is that our -set.xml files only encode one aircraft state (usually cold-and-dark). To encode (accurately) engines-running or in-flight as the start state, needs some kind of profile system where properties can have different values, and XML / Nasal can be initialised differently. That would make nice in-air starts possible (gear already up, throttles at sane position), as well as offering 'cold, dark and parked' or 'on the active and ready to go' as options. (And end all the per-aircraft 'auto-start' menu options - since they'd become standardised). — James Turner

I'm planning to extend this function (bindings support) so that checklists with one or more items containing a <binding> element can have an (optional) button to execute the entire checklist. I'm still thinking of how best to implement this, as I think one would want a gap between each item. — Stuart Buchanan

As part of the development of the Lockheed 1049h, I have produced a detailed set of checklists with bindings. The bindings are sufficient to start (and shutdown) the aircraft by pressing the action buttons displayed in the checklist dialog. I have also written a Nasal script that “executes” a list of checklists in a generic way. This iterates over each item in a given list of checklists and executes the binding for items where the associated condition is not met. Before continuing to the next item, it waits for the previous condition to become true and has a timeout for conditions that would never be satisified through the checklist bindings. — Richard Senior

In-air startups & supporting Startup Situations

Let's start with some "use case" analysis: Scenario 1: User wants to practice landings. Using command-line options, the user initializes the system to 4 mile final and 1500 feet above the runway. User lands OK, and wants to try it again. For maximum realism, he should taxi back, take off, and fly the pattern. But for best use of lesson time, it would be nice to relocate to a similar point (at this airport or another) and take it from there. Certainly the user could accomplish this by quitting out of the simulator and going wherever he likes using the command-line options on new invocation of the simulator, but it would be much more elegant to go there /without/ quitting and restarting. For this purpose the simulator provides the location-in-air popup. Scenario 2: Same as above, but practicing instrument approaches. The time savings are even greater, because the distances involved are often greater. The initial approach fix could be 20 or 30 miles from the airport. Scenario 3: The pilot makes a mistake enroute, and would like to "back up" a few miles and try it again. In this case it is particularly valuable to define the reference point as an offset relative to "here" i.e. relative to the aircraft's present position. Scenario 4: The pilot is on a long, boring leg, and would like to "fast forward" a few miles to get closer to a more interesting part of the journey. Note: All such use-case scenarios are black-box descriptions of what is desired. That is, the pilot doesn't care how any of it is implemented internally. OTOH, we now need to take off our pilot hats and put on our developer hats. We need to discuss implementation issues. The location-in-air popup is implemented as follows: It fills in some variables, and then invokes some sort of "reset" on the FDM. The interface seems to be called "presets-commit" if I'm reading the xml correctly. All evidence indicates that the function being called was not designed to be used this way, i.e. not to be used in flight and not to be used repeatedly. Instead it was supposed to be used once, during initial startup. There are numerous problems that need to be fixed. I don't much care how they get fixed, including defining and implementing a new "relocate" function, or robustifying the old "reset" or "preset" function so that it can handle a wider range of uses. or whatever. Specific problems include: 1) If the property "/sim/presets/trim" is "true" when presets-commmit is called, it attempts to "trim" the aircraft. I'm not sure what is the objective of such trimming, but by its own standards the procedure often fails. It prints error messages on the console complaining about various kinds of failures; see appendix below. My observations suggest that repeated calls to the "presets-commit" progressively increase the probability of failure. That is, the failure /probability per call/ is increasing. 2) Even if the "trim" function succeeds, it messes with the throttle settings. This is weird and undesirable in situations (such as mine) where there is a hardware throttle, because it creates a conflict between where the FDM thinks the throttle is and where the hardware throttle is. 3) One particularly weird thing is the behavior of the offset-azimuth and offset-distance properties. My observations indicate that they allow me to apply an offset relative to the reference point /if/ the reference point is an airport, VOR, or NDB ... but, strangely, not if the reference point is a lat/lon. In the latter case, it just relocates to the lat/lon and ignores the offset. This seems like a bug to me. It is significant, because relocating relative to "here" occurs in many use-cases, and is implemented in terms of the lat/lon of the present position. 4) The function now being called turns off the magnetos. This is clearly not desired behavior if all I'm trying to do is relocate. This is a low-priority bug, because I can work around it by saving and restoring the magneto settings. 5) The function now being called zeros the settings for aileron trim, elevator trim, and rudder trim. Again, this is clearly not desired behavior. I have a pretty-much workable workaround for the worstof these bugs. The big clue is that "presets-commit" apparently just deletes the old FDM instance and creates another. To make the new FDM happy, I had to delete a bunch of nodes from the property tree. Some other nodes needed to be set to -9999; merely deleting them was not good enough. This allows me to relocate-in-air once without getting flipped upside down (or worse). There is still some opportunity for improvement in connection with presets-commit and with FDM init in general. — John Denker

it's quite common to want to start a flight simulator on a 5 or 7 or 10 mile approach so you can practice ILS landing. — Curtis Olson

As previously reported, the corresponding presets have no effect during a re-init, e.g. via fgcommand("presets-commit"). — John Denker

Once the users intentions have been communicated to the FDM module, it's really up to the particular FDM, (JSBsim or YAsim) to do the right thing with the provide information. That does seem to have broke down at some point. I used to be able to happily start both YAsim and JSBsim aircraft in flight, but had zero luck last time I tried. — Curtis Olson

Note, it appears (as best as I can see) that in air startups are broke and probably haven't worked for a while with JSBSim and YASim. They do however continue to work fine with an external proprietary fdm I've been using for another project. — Curtis Olson

Unfortunately the underlying FDMs (JSBSim and Yasim) also have some limitations in this area - some won't correctly trim the aircraft unless it starts on the ground and stationary. Thorsten Brehm has done some improvements in this area but you still need to experiment to find all the settings for a particular aircraft, unfortunately. The real solution is each aircraft needs some additional code, which represents the 'in-air' state, or at least some sensible values) - engines running, gear up, fuel pumps on, etc. And then we need a way to request that state. This would be a fairly major addition, but it's something to consider after the next release. — James Turner

Yes, that's correct - we would basically have to expose a handful of feasible startup scenarios/situations and it would be up to the aircraft developer to ensure that those are valid and implemented properly. Just think about all the complex aircraft we have where a shared "start in air" feature would inevitably be broken, such as the concorde or even "just" helicopters... Stuart has recently demonstrated with his "Aircraft Checklists" system that it is possible to implement such a shared foundation that provides a generic infrastructure that then needs to be parametrized and customized as required for each individual aircraft. And that's something that would be also needed here. — Hooray

Richard Senior has created an automated checklist script to implement autostart on the Lockheed 1049h:

It is trivial to add other checklist sequences. For example, on the 1049h, although I initially created an “autostart” sequence, I now have "ground-start” and “in-air-start” sequences. The ground start fires up the aircraft ready to take off and the in-air start runs the checklists necessary to get it into a flying state (gear up, flaps up, etc.). — Richard Senior

Canvas based Checklists

Stuart: Hopefully as we move to using Canvas in the future we'll be able to improve the checklist display to include a set of dots linking the items.[3]

Hooray: Using the Canvas instead of PUI, we could provide a generic framework that could also be used for an EFB, i.e. checklists could show up on MFDs optionally, using a custom style.