Talk:Aircraft checklists: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (→‎In-air startups & supporting Startup Situations: https://sourceforge.net/p/flightgear/mailman/message/15602927/)
m (Switch to the {{forum link}} template for all forum links.)
Line 6: Line 6:


== Checklists & Autostart + limits.nas ==
== 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 [http://flightgear.org/forums/viewtopic.php?f=25&t=19836#p182372]. 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.
'''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 {{forum link|p=182372}}. 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.


{{cquote|
{{cquote|

Revision as of 07:23, 11 June 2019

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] This is a link to the FlightGear forum.. 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.

Cquote1.png

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). [1]
— James Turner
Cquote2.png
Cquote1.png
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.[2]
— Stuart Buchanan
Cquote2.png
Cquote1.png

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
Cquote2.png

In-air startups & supporting Startup Situations

1rightarrow.png See Startup Situations for the main article about this subject.

See also: https://sourceforge.net/p/flightgear/mailman/message/15602927/

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.

05/2015 updates (pm2wiki)

that's looking really good, and you've already incorporated other long-standing feedback from the talk page - I do think that this is the right thing to do in the mid-term, i.e. establishing, and extending, the notion of "checklists" to use this for the autostart/tutorial systems, which can then become totally aircraft agnostic - in fact, we could even have fairly generic tutorials doing a pattern at KSFO, and things should work regardless of the user select a c172p or a 777 - I think the main thing needed to make this happen is to get rid of hard-coded assumptions (think v-speeds) in tutorials, and instead look up the proper values by referring to the checklist mark-up - which would allow us to provide pretty generic tutorials, and people using/extending those would automatically help improve tutorials for other aircraft at the same time.

I guess it would make sense to send a heads-up to Stuart so that he can have a look, because all systems are basically his work (checklists, tutorials and autostart infrastructure) - and he once came up with the idea to unify things like you have begun doing it now.

I guess it would be good to review the autostart and tutorial code to see if this is already sufficiently well integrated, and maybe extend the docs on the wiki accordingly, to provide a "best practice" guide on creating aircraft-agnostic tutorials (assuming that the flight profile itself and the airport/runway are suitable - e.g. KSFO 28R should work for pretty much all instances).

Stuart has also been establishing and maintaining the c172p as the "reference implementation" for checklists and tutorials, so that should probably be the first starting point for us to adopt the system there, so that aircraft developers can refer to this as an example.

I guess it would make sense to review the flight recorder system, too - because checklist-properties are automatically relevant to the flight recorder/replay system, too - which basically means that as long as those are properly integrated (even if that just means including an XML for making certain properties known), people could expect to be able to even save/load and replay checklist-based flights, without any mis-match of simulator events.

From a regression testing standpoint it would actually be great if checklist-based autostart/tutorials could be made to work so that we can even execute tutorials in a non-interactive fashion, i.e. referring to the plethora of bug reports that are often hard to reproduce.

Overall, this may take a few more release cycles to address probably, so it would probably be a good idea to move this over to th wiki, so that others can take a look and follow the discussion - the really cool thing about establishing "checklists" as the interfacing mechanism for aircraft agnostic tutorials is that we could even come up with a simple scripted "mission generator" that would simply load a checklist, with a departure/destination airport plugged in, and maybe some failures (as per galvedro's work), to create nice little "challenges". --Hooray (talk) 09:56, 1 May 2015 (EDT)

Supporting complex aircraft

sanhozay mentioned that supporting complex aircraft may be tricky currently - so at some point it might make sense to get in touch with Hyde (777) or Gijs(744) to see what is needed in terms of extensions in order to support complex aircraft, too. Even if that just means gathering a list of feature requests (I may find time to look into that in a few weeks time).--Hooray (talk) 09:58, 1 May 2015 (EDT)

  1. James Turner (Tue, 05 Mar 2013 03:39:23 -0800). Crazy usability suggestion of the day.
  2. Stuart Buchanan (Wed, 01 May 2013 14:54:56 -0700). Further enhancement to checklists - binding support.