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