On 01/06/2007 04:25 PM, Jon S. Berndt wrote:
> I'm not sure what you are talking about here. Could you be more descriptive?
I'll try!
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.
> First, which version of JSBSim are you using?
I don't exactly know. I don't know how to get fgfs to print a
version number. The fgfs binary has a date of 2006-05-17 if
that means anything to you. I think this is just whatever one
gets by asking Debian-etch to install fgfs.
FWIW I am using the /data/ from CVS.
> From what I understand, Erik
> just put a new version of JSBSim in FlightGear CVS.
I guarantee that I'm not using the CVS version. I couldn't get it
to compile. Various people have sent me bunches of patches, but
it still won't compile.
> Second, The trim
> function works good in JSBSim by itself, and I thought it had been working
> with FlightGear, too. So, no, the trim function is not necessarily a
> disaster "in JSBSim", but it may now be getting used improperly, or in a way
> that was not anticipated.
Probably far, far away from what was anticipated.
I suspect the sensible thing to do would be to define
-- a reset function, and
-- a locate (or relocate) function, separate from reset.
That way the reset function could make a structured reference to
the locate function if it wants to ... while other folks could
call the locate function without getting mixed up with all the
other reset-related functionality.
=============================
If you need additional details, please let me know.
=========================
Appendix:
Here is the console output for three successive invocations of the
locate-in-air popup. I don't know exactly what they mean, but I
assume the word "failure" is not a good sign. The first two invocations
reported two failures, and the third reported three failures.
Model Author: Unknown
Creation Date: 2002-01-01
Version: $Id: c182.xml,v 1.17 2006-03-13 15:27:15 ehofman Exp $
Description: Cessna C-182
Trim Results:
Angle of Attack: 0.40 wdot: 1.22e-03 Tolerance: 1e-03 Failed
Throttle: 0.50 udot: -1.91e+00 Tolerance: 1e-03 Failed
Pitch Trim: 0.12 qdot: -8.83e-05 Tolerance: 1e-04 Passed
Trim Statistics:
Total Iterations: 61
Sub-iterations:
wdot: 128 average: 2.10 successful: 43 stability: 3.32
udot: 0 average: 0.00 successful: 0 stability: 74.42
qdot: 1082 average: 17.74 successful: 15 stability: 13.67
Run Count: 29996
Model Author: Unknown
Creation Date: 2002-01-01
Version: $Id: c182.xml,v 1.17 2006-03-13 15:27:15 ehofman Exp $
Description: Cessna C-182
Trim Results:
Angle of Attack: 1.76 wdot: 9.73e-03 Tolerance: 1e-03 Failed
Throttle: 0.45 udot: -7.74e-03 Tolerance: 1e-03 Failed
Pitch Trim: 0.09 qdot: 4.66e-05 Tolerance: 1e-04 Passed
Trim Statistics:
Total Iterations: 61
Sub-iterations:
wdot: 125 average: 2.05 successful: 18 stability: 3.35
udot: 896 average: 14.69 successful: 2 stability: 22.52
qdot: 218 average: 3.57 successful: 55 stability: 4.93
Run Count: 25788
Model Author: Unknown
Creation Date: 2002-01-01
Version: $Id: c182.xml,v 1.17 2006-03-13 15:27:15 ehofman Exp $
Description: Cessna C-182
Trim Results:
Angle of Attack: 7.50 wdot: -2.56e+03 Tolerance: 1e-03 Failed
Throttle: 0.50 udot: -2.21e+02 Tolerance: 1e-03 Failed
Pitch Trim: 0.00 qdot: -7.08e+02 Tolerance: 1e-04 Failed
Trim Statistics:
Total Iterations: 61
Sub-iterations:
wdot: 0 average: 0.00 successful: 0 stability: 11.33
udot: 0 average: 0.00 successful: 0 stability: 64.01
qdot: 0 average: 0.00 successful: 0 stability: 6.98
Run Count: 15147
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
