Startup Profiles: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
 
No edit summary
Line 92: Line 92:
<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17544.html |title= Startup position offsets (fg_init)|author=Curtis Olson |date=Sun, 24 Aug 2008 19:25:57 -0700}} </ref>|Curtis Olson}}
<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17544.html |title= Startup position offsets (fg_init)|author=Curtis Olson |date=Sun, 24 Aug 2008 19:25:57 -0700}} </ref>|Curtis Olson}}


{{FGCquote
|1= 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.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/24944253/
  | title  = <nowiki>Re: [Flightgear-devel] Issue with default starting scenario</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Apr 6th, 2010
  | added  = Apr 6th, 2010
  | script_version = 0.25
  }}
}}


{{cquote|As previously reported, the corresponding presets have no effect during a re-init, e.g. via fgcommand("presets-commit").<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20095.html |title= a few more bugs|author=John Denker|date=  Tue, 30 Dec 2008 09:50:28 -0800}} </ref>|John Denker}}
{{cquote|As previously reported, the corresponding presets have no effect during a re-init, e.g. via fgcommand("presets-commit").<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20095.html |title= a few more bugs|author=John Denker|date=  Tue, 30 Dec 2008 09:50:28 -0800}} </ref>|John Denker}}

Revision as of 19:56, 25 February 2016

Note  Also see the new <variant-of> tag which could be used for this
Cquote1.png 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)
— James Turner (Nov 23rd, 2015). [Flightgear-devel] Launcher changes for 3.8.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— James Turner (Nov 23rd, 2015). Re: [Flightgear-devel] Launcher changes for 3.8.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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)
Cquote2.png
Cquote1.png 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.[1]
— John Denker
Cquote2.png
Cquote1.png 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. [2]
— Curtis Olson
Cquote2.png
Cquote1.png 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.
— James Turner (Apr 6th, 2010). Re: [Flightgear-devel] Issue with default starting scenario.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png As previously reported, the corresponding presets have no effect during a re-init, e.g. via fgcommand("presets-commit").[3]
— John Denker
Cquote2.png
Cquote1.png 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. [4]
— Curtis Olson
Cquote2.png
Cquote1.png 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.[5]
— Curtis Olson
Cquote2.png
Cquote1.png 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.[6]
— James Turner
Cquote2.png


Cquote1.png 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.[7]
— Hooray
Cquote2.png

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

Cquote1.png 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
Cquote2.png
Cquote1.png My current guess is very crude: 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.
— James Turner (Nov 23rd, 2015). Re: [Flightgear-devel] Launcher changes for 3.8.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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)
Cquote2.png
  1. John Denker (Sun, 07 Jan 2007 09:20:14 -0800). location-in-air.
  2. Curtis Olson (Sun, 24 Aug 2008 19:25:57 -0700). Startup position offsets (fg_init).
  3. John Denker (Tue, 30 Dec 2008 09:50:28 -0800). a few more bugs.
  4. Curtis Olson (Wed, 31 Dec 2008 10:43:18 -0800). amazing FDM initialization bug.
  5. Curtis Olson (Tue, 26 Jan 2010 07:54:25 -0800). Setting position via property tree.
  6. Zakalawe (Fri Dec 07, 2012 12:19 pm). Re: starting in the air.
  7. Hooray (Fri Dec 07, 2012 12:19 pm). Re: starting in the air.