Autostart

This article is a stub. You can help the wiki by expanding it.

A so called autostart feature has begun to be provided by an increasing number of aircraft in the last couple of years. It is usually implemented in the form of FlightGear scripts (via Nasal) and/or custom property rules.

Some people dislike autostart functions, stating that 'realistic FDMs / cockpits are still of little use when people don't know how to use them.'

Other developers like this feature, and add 'an autostart menu entry to all my aircraft for those who dont want to go through the startup procedure.'

One method used by developers is writing a complete autostart routine and placing in it the same steps that you would do manually without autostart. For example, you switch on the master (battery), so in autostart, you set the master property. You start the first engine; you set the property. You just do all the same way as you would do it manually, only automatically, step by step. One application of this is the Boeing 707, which simulates the time need to complete all the procedures, instead of doing things instantly as a simple Nasal 'setprop' would.

Thus, supporting autostart all boils down to manipulating the cockpit properties programmatically, i.e. using a Nasal script - so that instead of clicking on a cockpit hotspot, you directly set the associated property to the corresponding value.

This used to be manually coded through Nasal scripts; however some people are using other methods.

Background

An aircraft in the air doesn't have a well-defined unique state. Especially when the systems are modeled in a realistic way, this can get very much in the way. For instance, the Concorde is trimmed by pumping fuel aft as you climb to cruise altitude. The 'in air' state of the plane with all fuel in the forward tanks you would have on approach is completely different from the 'in air' state you'd have at 52.000 ft and Mach 2 where as much fuel as possible is in the aft trim tank. If you want to start in air to practice a landing, you probably want to have flaps out and be in approach configuration - if you want to initialize FlightGear at cruise altitude, you'd want flaps up and the aircraft in cruise configuration. One case in point is included here - a problem in many gliders which otherwise initialize fine in air is that FG tries to initialize in air with some throttle set. So a glider may get initialized with spoilers out (as they're usually controlled by the throttle lever) - which is certainly not the intended behaviour. So the initialization procedure should somehow have to guess what you're trying to do, know what type of aircraft you're in and adjust the state of the aircraft accordingly - and that just doesn't work easily out of the box - what this needs is for the aircraft designer to specify one (several) in air states which can be loaded on request - as outlined above. One example of this is the Space Shuttle, which uses seperate -set files for seperate modes. For instance, you can initialize FlightGear in entry mode, and have all the before-deorbit checks complete, or start in orbit.

This UI feature could use some work. 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 that 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. We also need a way to request that state. This would be a fairly major addition, but it's something to consider after the next release.

So, 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 parametried and customized as required for each individual aircraft. And that's something that would be also needed here.

Checklists

More recently, using Stuart's checklists system, it should be possible to combine both features, and built autostart on top of checklists, plus some Nasal scripting to glue it all together. For more about this, do see the talk page about this at: Talk:Aircraft Checklists

Automated checklists would be a more organized way to do the "cheat". The code that is run is more or less the same.

So we want to make the Aircraft Checklists system sufficiently flexible, so that the whole autostart system can be built on top of it

The original idea was to take Stuart's new Aircraft Checklists feature and extend it such that the checklists are purely procedural, so that they could not just be used as interactive checklists for humans, but also as checklists ("scripts") for the program (fgfs) to change the aircraft configuration accordingly - programmatically. So that "autostart" and similar features would no longer be purely based on custom Nasal scripts, but instead automatically be supported by all aircraft that provide a corresponding checklist, that could then be used by the simulator to switch to a certain state directly.

More recently, this is commonly implemented on top of the "Aircraft Checklists" feature, i.e. by making checklists executable: Aircraft Checklists#Automated checklist execution

In other words, if you don't like the idea of coding all this from scratch, there's is a much better method using Stuart's checklist system - you basically convert checklists into XML, which in turn can be "executed" by FlightGear for each step of the checklist: Aircraft Checklists

Basically, checklists would then follow the DRY (Don't Repeat Yourself) paradigm, and could be used for a number of related purposes, such as:

Talk:Aircraft Checklists#Supporting Startup Situations

• checklists (obviously)
• interactive checklists (i.e. a virtual copilot)
• aircraft autostart (executing a whole checklist, or a number of lists)
• running certain checklists to enable in-air starts
• generic tutorials, which would get aircraft specifics from checklists (such as V speeds, procedures etc)
• limits.nas (aircraft specific limits could be read from various checklists, for different phases of flight)

This will be particularly useful for serious flight simulation purposes, such as proficiency/procedures training, where you need to be able to easily reset to a certain position, using a certain cockpit/aircraft configuration - e.g. to shoot approaches over and over again. Obviously, integration with the startup/replay dialogs would be really useful.

Ideally, all aircraft should adopt this system over time - and if anything is missing, the checklists system (100% scripted) should be extended.

The good thing here is that this turns code into data, so that we can easily unify this for all aircraft to come up with a flexible system, without having to maintain possibly hundreds of different startup systems - especially keeping in mind that many aircraft are no longer maintained, and that the quality of Nasal code in aircraft is generally not overly impressive. The data/XML-based approach has the added advantage that the Nasal code can be maintained by a few peope who are very familiar with Nasal, without them having to be experts in each and every aircraft - while aircraft developers no longer need to be proficient in Nasal and no longer need to know how to write Nasal code that behaves properly in all situations (think reset/re-init or reposition). Having custom-scripted startup/autostart systems is not a good idea - especially because we want to support other use-cases, such as for example in-air starts, e.g. for flying approaches over and over again - an XML-based checklist can be easily executed, and it can even be used to set up the cockpit to some predefined state.

Case Study: Lockheed 1049h

Here Sanhozay tells us about his experience: 'As part of the development of the Lockheed 1049h Constellation, I created a comprehensive set of checklists based on the crew operating manual with other items added sufficient to take the aircraft through all stages of flight. Rather than hand-code an autostart script I wrote a more generic script to run checklist bindings in sequence. This script is now available in FGDATA and can be used on other aircraft - see the relevant wiki page at Automated Checklist Execution.

If you are thinking about writing an autostart menu, you might want to consider using this script and driving the autostart from the checklists. It's not restricted to autostart, you can essentially run any sequence of checklists from any piece of Nasal code. You can see the script in action in the latest Lockheed 1049h. Note that you need a recent copy of FGDATA for this to work. The autostart in this case is intelligent enough to run different checklist sequences depending on whether you are starting on a runway, at the terminal or in the air and also uses automated checklist execution to run an "After Landing" checklist from a keyboard shortcut during that busy time of rollout and taxi.'

Automated Checklist Execution in the Lockheed 1049 - Sanhozay tells us more

'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. Using this script, autostart is implemented like this:

<checklists>
  <checklist include="Checklists/before-starting-engines.xml"/>
  <checklist include="Checklists/start-engines.xml"/>
  <checklist include="Checklists/during-warmup.xml"/>
  <checklist include="Checklists/before-taxi.xml"/>
  <checklist include="Checklists/before-takeoff.xml"/>
  ...
  <checklist include="Checklists/parking.xml"/>
  <autostart>
    <index n="0">0</index>  <!-- Before Starting Engines -->
    <index n="1">1</index>  <!-- Start Engines -->
    <index n="2">2</index>  <!-- During Warmup -->
    <index n="3">4</index>  <!-- Before Takeoff -->
  </autostart>
</checklists>

In the Autostart menu item there is just a simple Nasal binding:

Lockheed1049h.complete_checklists("autostart”);

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.). It works well in practice and feels like a hand-scripted autostart with timers.

I have some tidying up to do on the current script in the 1049h but I would like to make this available for other aircraft. If I make a merge request against fgdata, would it be accepted? I propose $FGDATA/Nasal/autochecklist.nas.

Obviously you can try it out in the latest Lockheed 1049h in FGADDON.

The main feature of Richard's Nasal-based solution is that it automatically discovers and executes the existing bindings in an existing checklist, removing the need to repeat the bindings or the sequence. It seems to me that state machines can be useful inside an autopilot but that, for automated checklist execution, Nasal is still better. (Actually, it is not because of Nasal but because of the introspection features made available in Nasal, which seem to be lacking in XML).'

State Machines

See State machines for the main article about this subject.

we have an XML configurable statemachine, you can define states and it's transitions using our well known <condition> and <binding> elements and fire bindings upon enter and leave of a state. I have just recently fixed a bug in that system and I am using it in a local project with great success.

As any other compoent, they can run as property-rule which throttles update to frame-rate. And there is the update-interval where you can even slow them down to any arbitrary rate (havn't checked the statemachine, if the implement it, though). Just for the records, I am not objecting against the nasal solution. I just want to make sure we not reimplement in Nasal, what is already there because an existing feature is not known.

References

References