Startup Profiles

Status

See also Startup Modes.

James would like to get starting-state support working the C172P and ideally a few other aircraft in FGaddon, he needs aircraft developers, especially the C172 team, to give feedback on the current code so he can make any improvements. Especially, he wants cold-and-dark vs ready-for-takeoff (autostart complete) vs in-air starts to work with the —state argument, then he can car drive this from the launcher. He will ask on the forum as well, the more examples we have of supporting this feature the better.

James wants to get the C++ code at least approximately correct before the upcoming release, so that in the next dev cycle we can expand aircraft support widely.

See the c172 for two example overlays, you /could/ add the data inside the main -set.xml but I’d strongly encourage using separate XML files to keep things manageable. Startup option is —state=<NAME> All other settings are applied on top of the overlay; the /only/ configuration it takes priority over is the -set.xml. No GUI support yet, nor auto-selection based on position. I’m happy to consider any plausible auto-selection rules, for example looking for a ‘catapult’ state for carrier-based aircraft when startup pos is a carrier, picking ‘cold-and-dark’ vs ‘takeoff’ based on runway vs parking-position on the ground. My initial name guesses and selection rules are below. I will add a <description> string to each overlay to allow nicer GUI menu selection. For the auto-selection, I’m considering adding some criteria to the state overlays, basically min / max altitude values to make more intelligent cruise vs climb/approach selection. That and min/max IAS values are about the only ones I can see really working, but even they would cover a good few cases. (Concorde in subsonic climb vs supersonic cruise) states and proposed selection criteria: parked (aka ‘cold-and-dark’?) : selected when at a parking stand or non-runway startup location takeoff (aka ‘engines-running’?) : selected when starting on a runway, or manually via UI cruise: select for in-air start, but maybe only above min-altitude criteria approach: selected when startup pos is relative to a runway / ILS, or cruise is excluded by altitude constraint. climb : manually selected, similar to approach but with higher fuel load presumably (I can’t think of any good way to distinguish approach and climb based on altitude, but figure more people starting in-air want to practice approaches than climb-outs) more specialist ones: moored : parked on water ??? - on a water runway with engines running (‘water-takeoff’?) [these two are to allow automatic selection for amphibious aircraft, compared to current nasty situation that occurs] catapult: takeoff but on a carrier catapult

auto-selection depends on position init, which we currently do /much/ later in startup than where we load the -set.xml. I need to think if applying the state overlay latee is going cause any issues - it certainly needs to be applied before subsystem postinit (when Nasal runs), but I wonder if it should really be done before subsystem create/init, in which case this means moving some parts of position init earlier. Off the top of my head I don’t know any reason position init can’t happen sooner, for common cases - or at least some checks of the kind of position (we won’t know carrier location or active runway, but we’ll know a carrier was requested or that the active runway was). The concern is that the position init code is fairly fragile already, so I’d sooner work around it than start messing with when it runs. We shall see.

auto-selection depends on position init, which we currently do /much/ later in startup than where we load the -set.xml. I need to think if applying the state overlay latee is going cause any issues - it certainly needs to be applied before subsystem postinit (when Nasal runs), but I wonder if it should really be done before subsystem create/init, in which case this means moving some parts of position init earlier. Off the top of my head I don’t know any reason position init can’t happen sooner, for common cases - or at least some checks of the kind of position (we won’t know carrier location or active runway, but we’ll know a carrier was requested or that the active runway was). The concern is that the position init code is fairly fragile already, so I’d sooner work around it than start messing with when it runs. We shall see.

Motivation

The position init code is pretty ugly as people have added many different (useful!) options over the years

One important use of FlightGear is as a pilot training aid, and one huge thing that instructors like to do is setup in-air starts so you can practice a lot of approaches in a short amount of time (that's one of the key benefits of a simulator over a real airplane.)

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.

In-air starts are difficult for many reasons: even if we do manage to have the plane perfectly trimmed for speed, altitude, and power, we can't force a joystick throttle to be in the right position, so everything will break down as soon as the sim gets a signal from the controller. I've been using FlightGear to practice instrument approaches for over 12 years, and have just resigned myself to 5+ seconds of altitude deviations and unusual attitudes until I get the plane under control. That said, if I couldn't do in-air starts in FlightGear, it would lose 80% of its usefulness for me.

It seems, lots of aircraft and people have pieces of the solution, but the lack of a standard which the core simulator also understands is hurting us.

There are many aircraft with complex (realistic) startup procedures, and while *some* aircraft have an autostart function, there is no standardised property to control that function - though one could certainly be defined. Of course, that's classic standardisation chicken-and-egg. I'm all in favour of it, but it's not something that can be done in the short term.

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

The problem 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).

The position init code is a little complex, to allow for starting on a carrier and some other cases, and ideally we would do it from script, but unfortunately there's some technical limitations on doing that. (Not insurmountable, but not quick either). Adding more cases to the position-init code is certainly doable - one suggestion I made some time ago, is when MP is active, to default to starting at a free parking position instead of on a runway. (When no startup position is provided at all). This would avoid people accidentally starting on the runway in MP events, which would be a big usability win. When no parking positions are defined, AI traffic defaults to the 'airport centre' location. Selection a taxiway parallel to the active runway is possible, but for complex airport layouts I can imagine many ways this logic could fail. Personally I think it would be more robust to stick to picking parking positions, and otherwise using the airport centre, because it would encourage people to add the parking position data :) I anyone wants to work on this, it would be a self-contained function in position-init code, just ask here for any questions. All the pieces certainly exist - the taxiways, parking locations and runways for the airport are all accessible.

Use Cases & Issues

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.

Original Idea

Here are a few usability guidelines that might help:

1. Consistency - all aircraft should start in same default state as far as possible (obviously, a glider doesn't have an engine), so that a user isn't surprised when switching aircraft types.
2. Configurability - it should be not only possible but very easy for a user to override the default state without editing XML or Nasal files.
3. Simplicity - the default state should be the easiest one for new users. Experienced users will have an easier time changing the default.

We introduce a new global property, such as /sim/start-state, which can be set to (say) "parked", "in-air", or "idling". The configuration files for every aircraft could respect that property, so that if you set it to "parked", *every* aircraft (even the default 172) would start parked, etc. (we could even put it on the apron instead of the runway if we add parking coordinates to the airports file). I think "idling" should be the default the first time someone runs FlightGear, since it's standard with all flight sims and by far the easiest for new users, but one menu selection should be able to switch to "parked" for people (like you) who prefer to go through the startup and taxiing routine every time. instead of having each designer decide, let the users start the aircraft any way *they* want. I think the default should be with the engine on and idling, but that's a separate discussion. The first step is to agree on a global property and start modifying aircraft configs to honour it; then we can debate what the default value of that property should be.

The sim can also decide where/how to place the aircraft (if not otherwise specified) based on the value. For example, by default, we could place the aircraft 1,000 ft above the airport at cruise speed if the value were "in-air", on the runway threshold (as now) if the value were "idling", and on the apron (assuming we have coordinates) if the value were "parked".

if there were standard subtrees of properties in the aircraft XML config files for key states, users could easily switch using a common menu for all aircraft (where the state is available). Here are some possible reusable states: - parked - idling (ready for takeoff) - cruise - approach - hovering (??) - orbiting (??) It's nice that we already have a flexible config system for this stuff; in fact, we could implement most or all of this with just XML and Nasal, without touching the core C++.

Status

Note  as of 04/2016, a new proposal is being discussed on the FlightGear devel list

James proposed, but didn’t yet have time to implement, a more formal ‘startup profile’ system for all aircraft, likely implemented as XML overlays on the basic -set.xml files.

Currently the entire -set.xml is overlaid on the property tree. I would extend this with additional overlays based on some ‘phase of flight value’, where the values are - cold-and-dark - pre-takeoff - cruise - approach It’s interesting to note the difference between ‘cold-and-dark’ and ‘pre-takeoff’ is essentially the same as what the existing auto-start functionality does in most aircraft. But this would simply be a set of property values. For anything which requires Nasal, I guess the aircraft scripts would have to check the value of /sim/presets/phase-of-flight and adjust things accordingly. (And there’s presumably lots of complexity there) I need input from aircraft authors on how feasible this is, of course. But the usability pay-off is potentially huge; standardised auto-start, nice in-air starts, easier setup of training configs.

This would also solve the in-air start issues, to a degree. As was noted back in the original discussion, this raises some questions about initialising Nasal state and other dynamic systems (the FDMs already support in-air trimming, to various degrees), but James doesn't believe there issues are insurmountable, and the benefit in user experience would be very large - for novice users, for in-air starts, and more.

It would help to know from the C172 team, what pieces would be needed /apart/ from an XML props overlay, to make the C172 do this as a standard feature?

I would set a /sim/initial-config variable to a standard value:

• ‘cold-and-dark’
• ‘engines-running’
• ‘circuit’ aka ‘takeoff'
• ‘cruise’
• ‘approach'

And this could be used to trigger whatever Nasal is needed beyond the property modifications. I imagine this proposal is too simplistic, but I need the aircraft developers to tell me in which specific ways that’s the case.

• add a /sim/startup/state string property
• permit -set.xml files to supply states at /sim/aircraft/states[0..n]
• state has a unique string id such as ‘cruise’ or ‘orbit', for internal use, also a name & description for display in the GUI / launcher / menus; number of states is up to the aircraft developer - we define some standard state labels, so GUI / launcher can pre-select a state when user picks in-air / on final / parking stand / runway to start. (if there’s no matching state for the selected startup location, we carry on as before)
• new command line option —state allows direct selection of state - /sim/aircraft/states[n]/overlay/* can contain arbitrary properties which over-write the -set.xml values eg /sim/aircraft/states[2]/overlay/foo/bar/ot=42 would set /foo/bar/zot=42 when the state is selected.
• /sim/aircraft/states[n]/overlay-file-path can contain a string referencing a props XML file which is overlayed if present eg shuttle-orbit-state.xml contains /foo/bar/zog=3.141, which ends up in the main tree So this gives to ways to supply property customisations, either in-line in the -set.xml file, or in separate files which might be cleaner if there’s many properties and/or states

For security, we might need to restrict which properties can be customised in such an overlay, since otherwise any property in the whole tree could be changed. Although, this is also true for a -set.xml file already I guess. I am assuming these are applied *after* the -set.xml, but prior to config options being overlaid, so if you do still set —vc or similar, they might work, or they might not. For aircraft which need more complex by-state config, this can be done in Nasal by inspecting /sim/startup/state, or of course any other property defined by the property overlay mechanism. I.e I don’t think a manual Nasal hook point is needed. I’m still busy with TerraSync features / bugs so won’t get to this for a week at least, maybe two, but any discussion about how useful / easy / horrible the above would be for real use cases, especially the C172, would be appreciated. Note I’m happy to add property-based configuration to subsystems if it means we can avoid Nasal in the common case - most things already configure via properties but I can imagine a few missing pieces that might need some Nasal right now, but could be fixed not to.

One thing I spent some idle time thinking on, was adding meta-data to states, to allow the system to select one based on startup location criteria. The most obvious examples being to look at altitude and requested IAS, and exclude / select certain states. This would be a way for the 777 to select cruise vs climbout states based on altitude requested, for example. And select flaps up or down, IAS vs Mach, STD vs actual pressure altitude and assorted other nuances. However, this will rapidly become an explosion of states. So I avoided mentioning this in my initial proposal - I’d rather go with simple and robust than clever-and-confusing. Of course the startup parameters are available in /sim/startup as they always have been, so aircraft can still make tweaks from Nasal based on those values, if they wanted to adjust mixture, flaps or whatever based on the actual altitude. I forgot to mention this in my proposal, but I figure once we have a few examples covering Yasim and JSBSim for normal aircraft (sorry Torsten, probably not the Shuttle…), we can see which per-aircraft pieces can actually be generalised / standardised to reduce the amount of copy-and-paste duplication. I don’t imagine we’d get to a point where a particular aircraft needsero customisation to work (same as the generic autopilot always needs tuning), but we might save 75% of the boilerplate. Again, I’d want to get experience with the basic setup I proposed, and then refactor once we have a good range of examples.

FDM Issues

• The Re-/Initialization Process in FlightGear: A Specification Proposal (Jon S. Berndt)
• JSBSim issues (replay related)

Related Features

• Autostart
• Aircraft Checklists

Problem

Note, it appears that in air startups are broken and probably haven't worked for a while with JSBSim and YASim.

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.

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.

Background

In-air starts are problematic, but fixing this is a Bigger Problem (TM) which I may take a look at after the release. (Probably means extending the -set.xml files to overlay different property states when starting in-air)

The challenge (perhaps) is that many aircraft authors have modeled the complex startup procedures of their aircraft. Try starting the AN-2 for instance ... it's quite a procedure (fortunately the tutorial walks you through the steps.) As our systems modeling gets better and better it may be harder and harder to be able to initialie each aircraft with the engine(s) running.

Currently the entire -set.xml is overlaid on the property tree. I would extend this with additional overlays based on some ‘phase of flight value’, where the values are - cold-and-dark - pre-takeoff - cruise - approach It’s interesting to note the difference between ‘cold-and-dark’ and ‘pre-takeoff’ is essentially the same as what the existing auto-start functionality does in most aircraft. But this would simply be a set of property values. For anything which requires Nasal, I guess the aircraft scripts would have to check the value of /sim/presets/phase-of-flight and adjust things accordingly. (And there’s presumably lots of complexity there) I need input from aircraft authors on how feasible this is, of course. But the usability pay-off is potentially huge; standardised auto-start, nice in-air starts, easier setup of training configs.

Discussion

Note  In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives). While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible.

here's my suggestion: *all* aircraft start with the runway threshold with the engine idling, unless the user has overridden that. Engine on/off is a decision that it doesn't make sense leaving to individual aircraft designers, since it's a cross-cutting user experience question. — David Megginson (Apr 6th, 2010). Re: [Flightgear-devel] Issue with default starting scenario. (powered by Instant-Cquotes)

I have added boxes to "Location/Position Aircraft in Air" - enable/disable engine running, set flap position, park-brake on/off, gear up/down. (I also have airbrake position and brake-chute arm) — Alan Teeder (Nov 23rd, 2015). Re: [Flightgear-devel] Launcher changes for 3.8. (powered by Instant-Cquotes)

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

My original idea was to use different *-set files to do positioning and system initialiation based on phase of flight. This did not work. Now I'm using different set files to mark phase of flight and Nasal to correctly position/initialize the state of systems. In general, I found this complicated. For instance, starting in the final glide phase, I definitely want to initialize with APU and hydraulics on (otherwise airfoils don't work). APUs take some 30 seconds to spin up to full RPM, only then can the hydraulics pumps be engaged, however engaged hydraulics pumps prevent the APU from starting - so you have to do the exact sequence of APU on - wait - hydraulics pumps on. There's no way to initialize this in a single frame. There is also no way that JSBSim picks it up 'running' if I just set the properties in the *-set file to what they'd be if the system would be running. While a correctly timed Nasal script is able to flick all the switches to power the hydraulics up, it's going to take 30 seconds, which is a long time if you're in air and without control. So, there's a 'cheat' switch which by-passes the APU/hydraulics modeling and just tells to the system that hydraulics power is unconditionally available - I use the cheat switch to power during startup and switch to the regular system after 45 seconds when doing an in-air startup. There's by now a handful of different solutions taking care of other subsystems which come with their own problems when they should be initialized running (or absent - for instance SRBs are needed only for two minutes and not allowed to hang around...) Point being, there's no way this is going to be easy. For more complicated systems modeling, you need a combination of custom-rigged JSBSim and Nasal to initialize a correct in-air start. Initializing with a viable state vector is also not that easy - I had to code Earth's rotation into the startup Nasal to get to the same orbital parameters independent of heading, I suppose airplanes will have to explicitly encode wind. I think it's a task that can be done, but especially for the complex planes (i.e. precisely when this would be most useful because 'just' initializing them in-air doesn't do the trick) this requires a dedicated effort by the developer and changes all the way into the systems modeling itself (plus a handful of dirty tricks). There's little that can be automated (as I said, I had to work around a handful of different challenges), and it can be done right now with different *-set files setting a flag which phase of the flight to describe. — Thorsten Renk (Nov 24th, 2015). Re: [Flightgear-devel] Launcher changes for 3.8. (powered by Instant-Cquotes)