Talk:Aircraft checklists: Difference between revisions

Talk:Aircraft checklists (view source)

Revision as of 14:53, 9 May 2013

4,728 bytes added , 9 May 2013

→‎In-air startups & supporting Startup Situations

Hooray

Administrators

20,741

edits

@@ Line 17: / Line 17: @@
 == In-air startups & supporting Startup Situations ==
+{{cquote|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:
+) 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.
+) 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.
+) 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.
+) 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.
+) The function now being called zeros the settings for aileron trim, elevator trim, and rudder trim.  Again, this is clearly not desired behavior. <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20095.html |title= location-in-air|
+author=John Denker|date=Sun, 07 Jan 2007 09:20:14 -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}}
 {{cquote|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.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25882.html |title= Setting position via property tree|author=Curtis Olson |date=  Tue, 26 Jan 2010 07:54:25 -0800}} </ref>|Curtis Olson}}
 {{cquote|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.

Talk:Aircraft checklists: Difference between revisions

Talk:Aircraft checklists (view source)

Revision as of 14:53, 9 May 2013

Navigation menu

Search