Re: [Flightgear-devel] JSBSim broken?
On Sunday 04 December 2005 11:27 am, Joacim Persson wrote: Reverser is also no functional. Can't tell if this is simply not implemented or if this ... The reverser method has changed. You set the reverser now by adjusting the /fdm/jsbsim/propulsion/engine[x]/reverser-angle property (where x is the engine number), which is the reverser angle in degrees. 90 degrees gives you zero thrust. A good value is about 120 degrees. You have to set this for all engines if you are using one throttle for all engines. The property /engines/engine[x]/Reverser doesn't work any more. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim broken?
I couldn't help but notice that the JSB version of the 747 has a lift-ratio which would make a sailplane pilot envious. One can glide about with full flaps, gear out etc with AoA at 30--40° in 80 kias and keep it level. ;) When running it with --debug-level=debug I get some numbers on JSB's idea about drag, for instance: I appreciate the report. I wanted to let you know I got your email and your bug report is in the queue. I'll put this report in a JSBSim bug report (see www.jsbsim.org). I'd like to emphasize how important it is to get reports from users. THe very best way to let us know about bugs (for JSBSim) is to file a bug report at www.jsbsim.org. That way we are sure it won't get lost. We've got a lot going on right now, and I'll try to get to that ASAP. Maybe someone else can answer that sooner than I. Jon -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim broken?
I couldn't help but notice that the JSB version of the 747 has a lift-ratio which would make a sailplane pilot envious. One can glide about with full flaps, gear out etc with AoA at 30--40° in 80 kias and keep it level. ;) I've filed the bug as: http://sourceforge.net/tracker/?func=detailatid=119399aid=1372940group_id=19399 Thanks, Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim broken?
On Sunday 04 December 2005 11:27 am, Joacim Persson wrote: I couldn't help but notice that the JSB version of the 747 has a lift-ratio which would make a sailplane pilot envious. One can glide about with full flaps, gear out etc with AoA at 30--40° in 80 kias and keep it level. ;) ... The testbed being used here is a fresh cvs version. The first thing I would change is the idle thrust factor at 0 speed and 0 altitude. The value of 0.0836 was an old typo that got copied into several turbine config files. A value of 0.0317 looks better, and is what I'm using in the CFM-56 config. Also, there is no gear drag included. I would copy the gear drag coefficient out of the 737 config and paste it into the 747 config. Also, the newer turbine model allows one to knock off some thrust due to bleed/accessory/installation losses. I would knock off 4 percent. See the 737's CFM-56 config. As far as the drag values go, the CD0 looks good, and matches aeromatic well. The induced drag is calculated a different way than I do it, and I'd have to get the calculator out to compare results with the aeromatic method, which I hope to get to some time. I'm not a fan of the method used in the 747 config, even if the numbers turn out to be good. The flap drag looks good. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim broken?
On Sun, 4 Dec 2005, Dave Culp wrote: As far as the drag values go, the CD0 looks good, and matches aeromatic well. ... The flap drag looks good. Then for some reason all those numbers are ignored. Either in jsbsim internally or in the fg--jsbsim interface. The plane glides virtually forever. Like overshooting the runway by 15nm (after which I got bored) with an attitude of 30° in 90kts at 180' AGL (=no ground effect). (It looks funny though. =) I've been testing other jsbsim models tonight apart from the 747-100: 737, c150, c182 and they all seem to have extremly low or zero drag. They won't stall. But since the jsbsim guys are busy preparing a new release which will affect the config files anyway(?) I think I'll just drop it for now.___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim broken?
On Sunday 04 December 2005 05:55 pm, Joacim Persson wrote: Then for some reason all those numbers are ignored. Actually it seems that what's being ignored is my previous email. I'm not interested in helping you fix your problem if you aren't. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim broken?
Log some output parameters. That can be done using the OUTPUT section of the config file. See the X-15 (?) or C-172x config file. I'll get around to it as soon as I can. I'm _sure_ there's a simple explanation for this. Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joacim Persson Sent: Sunday, December 04, 2005 5:55 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] JSBSim broken? On Sun, 4 Dec 2005, Dave Culp wrote: As far as the drag values go, the CD0 looks good, and matches aeromatic well. ... The flap drag looks good. Then for some reason all those numbers are ignored. Either in jsbsim internally or in the fg--jsbsim interface. The plane glides virtually forever. Like overshooting the runway by 15nm (after which I got bored) with an attitude of 30° in 90kts at 180' AGL (=no ground effect). (It looks funny though. =) I've been testing other jsbsim models tonight apart from the 747-100: 737, c150, c182 and they all seem to have extremly low or zero drag. They won't stall. But since the jsbsim guys are busy preparing a new release which will affect the config files anyway(?) I think I'll just drop it for now. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim broken?
I've been testing other jsbsim models tonight apart from the 747-100: 737, c150, c182 and they all seem to have extremly low or zero drag. They won't stall. Hmmm. I've not heard any complaints about the other aircraft. The 737 has been extensively tested by someone who knows how they fly. Also, if any of these aircraft had zero or artificially low drag, they thrust produced by the engine would propel them to unbelievably high speeds. Now, I haven't tested these models in a long time (yes, I am incredibly busy right now on many fronts), but if the C182 flew at 400 kts I think I'd hear about it. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim: Failed to tie propertypropulsion/c-thrust[0] to a pointer
Le mardi 02 août 2005 à 00:42 -0500, Jon Berndt a écrit : When the JSB a/c model has several engine+propeller we get that JSB message error: Failed to tie property propulsion/c-thrust[0] to a pointer What must be defined in Aircraft.xml to solve it. -- Gerard Which version of JSBSim are you using? Is it the one currently in FlightGear CVS? You'll need to tell me more about your aircraft/propeller config files (or email them to me). Jon 1/ That message is given with JSB 9.7 During convert from old xml to new xml 2/ That message is given with FG CVS During start run. It appear on every A/C which are multi engine-propeller, you can find it with current FG A/C = c310, Boeing314. I get the same message with my own Beech18-C47. If you answer what must be done on c310 i will get the answer for mine. May be, the cause is the description in AC_ENGINE engine 0 refer to file aircraft_engine.xml propeller 0refer to file aircraft_prop.xml engine 1 refer to __the_same_file aircraft_engine.xml propeller 1 refer to __the_same_file aircraft_prop.xml Thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim: Failed to tie property propulsion/c-thrust[0] to a pointer
When the JSB a/c model has several engine+propeller we get that JSB message error: Failed to tie property propulsion/c-thrust[0] to a pointer What must be defined in Aircraft.xml to solve it. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim: Failed to tie propertypropulsion/c-thrust[0] to a pointer
When the JSB a/c model has several engine+propeller we get that JSB message error: Failed to tie property propulsion/c-thrust[0] to a pointer What must be defined in Aircraft.xml to solve it. -- Gerard Which version of JSBSim are you using? Is it the one currently in FlightGear CVS? You'll need to tell me more about your aircraft/propeller config files (or email them to me). Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
On Thu, 28 Jul 2005 00:47:26 +0200, Gerard wrote in message [EMAIL PROTECTED]: Le mercredi 27 juillet 2005 à 23:15 +0200, Arnt Karlsen a écrit : On Wed, 27 Jul 2005 14:18:34 +0200, Gerard wrote in message [EMAIL PROTECTED]: I did NOT ask for deleting that piece of code which is rather good (and could be improved), i only ask for to remove the new AGL test ^^ which delete the UNDERCARIAGE facilities. Am i understandable ? ...well, not neccessarily in the precise way you intended to, if you're in doubt, also write in your native language so we can play with babelfish.org, a couple of your recent post reads out far worse in english than what I believe you meant them to. ;o) for BabeFish.org En français j'écrirai exactement la même chose. ..that's the first half of communication, the part where you _are_ in charge, regardless of whether or not you know what you are saying. ..in the second half of communication, you're _not_ in charge, so you can merely hope, that I'll heed your suggestions in what you say, of what you would like me to read and do etc. ..I judge and rule on that. ;o) boom. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Le mardi 26 juillet 2005 à 23:13 +0200, Mathias Fröhlich a écrit :
Hi,
sorry for the late reaction.
Turns out to be a bad interaction between jsbsims crash detection and my
past initialization changes.
The attached patch fixes this by moving crash detection out of the
initialization phase of jsbsim.
Erik,
Can you apply that please to flightgears cvs.
I will care for JSBsim's cvs.
Thanks and sorry
Hello Mathias,
I don't understand why do you continu to develop on that wrong crash
detection.
It is a nonsense regarding the JSB undercarriage facilities.
it is a nonsense regarding the other old crash detection process
in
FGLGear.cpp line 507
Here's the code:
// Crash detection logic (really out-of-bounds detection)
if (compressLength 500.0 ||
vForce.Magnitude() 1.0 ||
vMoment.Magnitude() 50.0 ||
SinkRate 1.4666*30)
{
PutMessage(Crash Detected: Simulation FREEZE.);
Exec-Freeze();
}
The undercarriage definition is very flexible. It gives the facilities
to manage an aircraft customised crash animation with the help of a
nasal script.
If an improvement must be done it could be done on the old existing code
with specifics properties like that one which is coming from a Dave
mail.
crash-detection
altitude-agl0/altitude-agl
g-z-max11.0/g-z-max
g-z-min5.0/g-z-min
g-x-max20/g-x-max
g-x-min20/g-x-min
qbar1089.0/qbar
pitch-rate3.7/pitch-rate
yaw-rate3.5/yaw-rate
mach0.99/mach
/crash-detection
I fear, the user opinion is not useful for the development team.
I fear the user opinion is not taken in account.
Please tell me, by that way i will continu to subscribe or not.
Thanks
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Mathias Fröhlich wrote: Erik, Can you apply that please to flightgears cvs. I will care for JSBsim's cvs. Done. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
FGLGear.cpp line 507
Here's the code:
// Crash detection logic (really out-of-bounds detection)
if (compressLength 500.0 ||
vForce.Magnitude() 1.0 ||
vMoment.Magnitude() 50.0 ||
SinkRate 1.4666*30)
{
PutMessage(Crash Detected: Simulation FREEZE.);
Exec-Freeze();
}
The undercarriage definition is very flexible. It gives the facilities
to manage an aircraft customised crash animation with the help of a
nasal script.
If an improvement must be done it could be done on the old existing code
with specifics properties like that one which is coming from a Dave
mail.
crash-detection
altitude-agl0/altitude-agl
g-z-max11.0/g-z-max
g-z-min5.0/g-z-min
g-x-max20/g-x-max
g-x-min20/g-x-min
qbar1089.0/qbar
pitch-rate3.7/pitch-rate
yaw-rate3.5/yaw-rate
mach0.99/mach
/crash-detection
The out-of-bounds detection logic was a development piece of code, really. That
can be removed if it is causing a problem.
Jon
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
Le mercredi 27 juillet 2005 à 07:05 -0500, Jon Berndt a écrit :
FGLGear.cpp line 507
Here's the code:
// Crash detection logic (really out-of-bounds detection)
if (compressLength 500.0 ||
vForce.Magnitude() 1.0 ||
vMoment.Magnitude() 50.0 ||
SinkRate 1.4666*30)
{
PutMessage(Crash Detected: Simulation FREEZE.);
Exec-Freeze();
}
The undercarriage definition is very flexible. It gives the facilities
to manage an aircraft customised crash animation with the help of a
nasal script.
If an improvement must be done it could be done on the old existing code
with specifics properties like that one which is coming from a Dave
mail.
crash-detection
altitude-agl0/altitude-agl
g-z-max11.0/g-z-max
g-z-min5.0/g-z-min
g-x-max20/g-x-max
g-x-min20/g-x-min
qbar1089.0/qbar
pitch-rate3.7/pitch-rate
yaw-rate3.5/yaw-rate
mach0.99/mach
/crash-detection
The out-of-bounds detection logic was a development piece of code, really.
That can be removed if it is causing a problem.
Jon
I did NOT ask for deleting that piece of code which is rather good (and
could be improved),
i only ask for to remove the new AGL test
^^
which delete the UNDERCARIAGE facilities.
Am i understandable ?
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
On Wed, 27 Jul 2005 14:18:34 +0200, Gerard wrote in message [EMAIL PROTECTED]: I did NOT ask for deleting that piece of code which is rather good (and could be improved), i only ask for to remove the new AGL test ^^ which delete the UNDERCARIAGE facilities. Am i understandable ? ..well, not neccessarily in the precise way you intended to, if you're in doubt, also write in your native language so we can play with babelfish.org, a couple of your recent post reads out far worse in english than what I believe you meant them to. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
Le mercredi 27 juillet 2005 à 23:15 +0200, Arnt Karlsen a écrit : On Wed, 27 Jul 2005 14:18:34 +0200, Gerard wrote in message [EMAIL PROTECTED]: I did NOT ask for deleting that piece of code which is rather good (and could be improved), i only ask for to remove the new AGL test ^^ which delete the UNDERCARIAGE facilities. Am i understandable ? ...well, not neccessarily in the precise way you intended to, if you're in doubt, also write in your native language so we can play with babelfish.org, a couple of your recent post reads out far worse in english than what I believe you meant them to. ;o) for BabeFish.org En français j'écrirai exactement la même chose. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
... This bug showed up about 10 days ago with an update from cvs. Any ideas what is broken? I've got a hunch. Dave Culp may have an idea. I'll take a look, too. Sorry. I haven't been following the FG CVS logs. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Dave Perry wrote: This bug showed up about 10 days ago with an update from cvs. Any ideas what is broken? Regards, Dave Perry I have started to investigate that problem but not found anything atm. I can reproduce the bug in the same situation as you. FG is *not* freezed. All (?) is working correctly except the screen is not refreshed for some strange reason. The main loop is executed, the render code is executed, you can do a clean exit with escape + enter. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Hi, sorry for the late reaction. Turns out to be a bad interaction between jsbsims crash detection and my past initialization changes. The attached patch fixes this by moving crash detection out of the initialization phase of jsbsim. Erik, Can you apply that please to flightgears cvs. I will care for JSBsim's cvs. Thanks and sorry Mathias On Dienstag 26 Juli 2005 03:38, Dave Perry wrote: I have posted this issue twice before. This is with plib, SimGear, fg, and data all from recent cvs. I have fgfs from cvs up-to-date on my desktop and notebook, both running Linux FC3 and both have this bug after updates from about 10 days ago. I don't know if there are others that use fgfs from front range locations in Colorado, but I use it to practice instrument approaches in this my home area and my two favorite aircraft for this are the c172p and c310, both jsbsim models. _The yasim aircraft still work fine with this scenery._ By the way, I downloaded both w110n30.tgz and w110n40.tgz and reinstalled both with no change to this bug. I have not seen this issue with airports not from these scenery files. I used --log-level=info to try and figure out what the issue is and here is the beginning and end of that log. [EMAIL PROTECTED] data]$ ./bin/fgfs --fg-scenery=/usr/local/Scenery-0.9.8 --log-level=info --airport=2V2 --aircraft=c172 Finished command line arguments Initializing splash screen GeForce FX 5600 Ultra/AGP/SSE/3DNOW! Max texture size = 4096 Depth buffer bits = 24 Loading Airport Database ... Data file version = 715 [FINISHED LOADING] Loading Navaid Databases Standardising rwy number from B to 0B Fixes Attempting to set starting position for 2V2:28R Failed to find runway 28R at airport 2V2 Attempting to set starting position from airport code 2V2 heading 270 runway = -105.164, 40.1644 length = 1459.99 heading = 122.75 Position for 2V2 is (-105.156, 40.1609) new heading is 302.75 Searching for airport code = 2V2 Position for 2V2 is (-105.164, 40.1638) Initializing Time Current greenwich mean time = Tue Jul 26 01:12:53 2005 Current local time = Mon Jul 25 19:12:53 2005 Reading timezone info from: /usr/local/FlightGear/Timezone/zone.tab Using zonename = /usr/local/FlightGear/Timezone/America/Denver First time, doing precise gst General Initialization === == ... Ltoken = OBJECT_BASE name = 1237121.btg token = OBJECT name = CO82.btg token = OBJECT name = 7CO3.btg token = OBJECT name = K18V.btg token = OBJECT name = K18V.btg token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.604, 40.1208 elevation = 1459 heading = 0 token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.742, 40.0566 elevation = 1488 heading = 0 token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.747, 40.0555 elevation = 1497.8 heading = 0 prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 Ltoken = OBJECT_BASE name = 1237129.btg token = OBJECT name = 03CO.btg token = OBJECT name = 03CO.btg prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 Loading tile /usr/local/Scenery-0.9.8/w110n40/w105n40/1237137 token = OBJECT_BASE name = 1237137.btg token = OBJECT name = K11V.btg token = OBJECT name = K11V.btg token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.706, 40.2614 elevation = 1407.8 heading = 0 prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 Loading tile /usr/local/Scenery-0.9.8/w110n40/w105n40/1237145 token = OBJECT_BASE name = 1237145.btg token = OBJECT name = KGXY.btg token = OBJECT_SHARED name = Models/Airport/beacon.xml pos = -104.636, 40.4291 elevation = 1418 heading = 0 token = OBJECT name = CO70.btg token = OBJECT name = CO70.btg token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.724, 40.4375 elevation = 1328 heading = 0 token = OBJECT_SHARED name = Models/Structures/radio-medium.xml pos = -104.724, 40.4378 elevation = 1328.3 heading = 0 prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 Loading tile /usr/local/Scenery-0.9.8/w110n40/w105n40/1237153 token = OBJECT_BASE name = 1237153.btg token = OBJECT name = CO48.btg token = OBJECT name = CO48.btg prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06 prepare_ground_cache(): ac radius = 5.5146, # triangles = 28, # wires = 0, # catapults = 0, ground_radius = 6.37082e+06
Re: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30 airports
Le mardi 26 juillet 2005 à 23:13 +0200, Mathias Fröhlich a écrit :
Hi,
sorry for the late reaction.
Turns out to be a bad interaction between jsbsims crash detection and my
past initialization changes.
The attached patch fixes this by moving crash detection out of the
initialization phase of jsbsim.
Erik,
Can you apply that please to flightgears cvs.
I will care for JSBsim's cvs.
Thanks and sorry
Mathias
Or only comment, in order to come back to the good old process.
// crashed (altitude AGL 0)
//if (get_Altitude_AGL() 0.0) {
// crash_message = Attempted to fly under ground.;
// crash_handler();
// }
--
Gerard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] jsbsim won't start with w110n40 or w110n30airports
I don't know if there are others that use fgfs from front range locations in Colorado, but I use it to practice instrument approaches in this my home area and my two favorite aircraft for this are the c172p and c310, both jsbsim models. _The yasim aircraft still work fine with this scenery._ By the way, I downloaded both w110n30.tgz and w110n40.tgz and reinstalled both with no change to this bug. I have not seen this issue with airports not from these scenery files. This bug showed up about 10 days ago with an update from cvs. Any ideas what is broken? Regards, Dave Perry I've got a hunch. Dave Culp may have an idea. I'll take a look, too. Thanks, Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] jsbsim airstream info
It's alpha and beta. in radians: aero/alpha-rad aero/beta-rad in degrees: aero/alpha-deg aero/beta-deg Jon OK, I'm trying to find what the air velocity relative to the fuselage of a jsbsim plane is. I'm pretty sure the info is in /fdm/jsbsim/atmosphere, but I don't know which values are which. Ultimately this will be used to make a ribbon indicate the wind. If I'm cool, I will be able to make it flap faster as the speed increases. Any help? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim Scripts in FlightGear
Jon S Berndt wrote: I got a request to implement something I've been considering implementing for some time, anyhow. JSBSim has the ability to run scripted flights. Scripts are composed in an XML-format command file. This works quite well for JSBSim in a standalone mode. I have yet to try to implement this in JSBSim.cxx - the interface. However, I suspect it is merely a matter of not taking input from FlightGear, but instead taking input from our script class. The problem I need to know how to solve is in taking a command line option from FlightGear. We still need to specify the name of the script file to use. The script file designates which aircraft to load, as well as the initial conditions file to use. So, what I'd like to do is to implement a command line option in Flightgear that is mutually exclusive with setting initial conditions and aircraft name. Possible? I would go the other way around, implement FlightGear's FDM socket communication protocol for JSBSim and run it as a stand-alone FDM that feeds FlightGear with it's data. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim Scripts in FlightGear
I would go the other way around, implement FlightGear's FDM socket communication protocol for JSBSim and run it as a stand-alone FDM that feeds FlightGear with it's data. Erik I like this idea a lot - but I'm not quite sure how to proceed on this. Do you have any ideas to throw out on how this might work? Mind you, I have had no exposure to the FDM scp. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
Norman Vine said: Martin Spott writes: Erik Hofman wrote: They really should be fabs() in both cases, both GetState() and GetTolerance() return a double instead of an int. Thanks ! Any idea why this doesn't show up on other platforms ? gcc is getting *much* pickier on the road to being c++ standards compliant In other words, they are finally fixing it. Allowing casts from double to int with just a warning is not a good thing. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
Jon Stockill wrote: On a similar toolchain related theme, I just upgraded a machine here to slackware 10.0, which uses autoconf-2.59 and automake-1.8.5, which caused all sorts of problems when attempting to compile current cvs versions of simgear and flightgear. Rolling back to autoconf-2.57 and automake-1.7.7 fixed the problem. If it's something we should be fixing at our end then I'll upgrade again and get more details, if it's an autoconf/automake problem then I'll just hold off on the upgrade until I know it's fixed. If you keep receiving errors/warnings about underquoted definitions in M4 macros, it's most likely really pretty much the same thing as with gcc: the autotools folks intend to become much pickier, too - so, in that case it's not really a FG issue but rather the new versions enthusiastically complain about macros that their old counterparts happily accept - so that kind of issues does not occur if you aren't up to date :-) If I remember correctly, there was also some info about that on the autotools page. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
Boris Koenig wrote: If you keep receiving errors/warnings about underquoted definitions in M4 macros, it's most likely really pretty much the same thing as with gcc: the autotools folks intend to become much pickier, too - so, in that case it's not really a FG issue but rather the new versions enthusiastically complain about macros that their old counterparts happily accept - so that kind of issues does not occur if you aren't up to date :-) That's exactly what I got. It was severe enough to prevent it from doing its job though, which is why I downgraded. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
On Friday 17 September 2004 17:30, Jon Stockill wrote: Boris Koenig wrote: If you keep receiving errors/warnings about underquoted definitions in M4 macros, it's most likely really pretty much the same thing as with gcc: the autotools folks intend to become much pickier, too - so, in that case it's not really a FG issue but rather the new versions enthusiastically complain about macros that their old counterparts happily accept - so that kind of issues does not occur if you aren't up to date :-) That's exactly what I got. It was severe enough to prevent it from doing its job though, which is why I downgraded. Downgrading is not necessary, you just need to delete some files that where generated by the old autotools. After that FlightGear and Simgear compile without errors on Slackware 10 with the new autotools. It only gives some warning messages, but you can ignore them, Take also a look in the mailinglist archive, i had the same problems before there you can read how i solved it exactly. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
Martin Spott wrote: Hello, I must admit that it's not completely clear to me if this stems from using GCC-3.4.1 or simply from the recent changed to JSBsim (I assume the latter) so I'd be happy if anyone could tell me: make[4]: Entering directory `/usr/local/src/FlightGear/src/FDM/JSBSim' [...] g++ -mcpu=hypersparc -mtune=hypersparc -DHAVE_CONFIG_H -I. -I. -I../../../src/Include -I../../.. -I../../../src -I/opt/gnu/include -I/usr/local/include -I/opt/FlightGear/include -I/usr/local//include -DFGFS -O3 -D_REENTRANT -c -o FGTrimAxis.o FGTrimAxis.cpp In file included from FGJSBBase.h:44, from FGModel.h:41, from FGFDMExec.h:43, from FGTrimAxis.cpp:42: /opt/FlightGear/include/simgear/compiler.h:339:1: warning: SG_COMPILER_STR redefined /opt/FlightGear/include/simgear/compiler.h:148:1: warning: this is the location of the previous definition FGTrimAxis.cpp: In member function `void JSBSim::FGTrimAxis::AxisReport()': FGTrimAxis.cpp:440: error: call of overloaded `abs(double)' is ambiguous /usr/include/iso/stdlib_iso.h:91: note: candidates are: int abs(int) /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.1/../../../../include/c++/3.4.1/cstdlib:123: note: long int std::abs(long int) FGTrimAxis.cpp:440: error: call of overloaded `abs(double)' is ambiguous /usr/include/iso/stdlib_iso.h:91: note: candidates are: int abs(int) /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.1/../../../../include/c++/3.4.1/cstdlib:123: note: long int std::abs(long int) make[4]: *** [FGTrimAxis.o] Error 1 They really should be fabs() in both cases, both GetState() and GetTolerance() return a double instead of an int. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
Erik Hofman wrote: They really should be fabs() in both cases, both GetState() and GetTolerance() return a double instead of an int. Thanks ! Any idea why this doesn't show up on other platforms ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
Martin Spott wrote: Erik Hofman wrote: They really should be fabs() in both cases, both GetState() and GetTolerance() return a double instead of an int. Thanks ! Any idea why this doesn't show up on other platforms ? I think the other compilers just issue a warning and convert the double to an int before proceeding. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
Martin Spott writes: Erik Hofman wrote: They really should be fabs() in both cases, both GetState() and GetTolerance() return a double instead of an int. Thanks ! Any idea why this doesn't show up on other platforms ? gcc is getting *much* pickier on the road to being c++ standards compliant Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
Norman Vine wrote: gcc is getting *much* pickier on the road to being c++ standards compliant Even pickier than MIPSpro !? I'm amazed, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
On Donnerstag, 8. Juli 2004 02:23, Oliver C. wrote: My question is now, does it really make sense to create a work around for this, isn't it better to update the STL library? IMHO the STL makes sense, it saves space, keeps the code clean, programmers don't need to invent the wheel a second time and you will need the STL anyway so why shouldn't we use it? I would like to use the C++ native way to get these informations! And RedHat shipped a long time with that old gcc. But, IMO the sense of software is not to make the sysadmin installing it more work because of the raising requirements ... At least not if the workaround is 5 minutes of work ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
On Wed, 7 Jul 2004 15:30:14 - Jim Wilson [EMAIL PROTECTED] wrote: There doesn't seem to be support for the std::numeric_limits references added in the June update. Can we work around this? e.g.: In file included from FGFCSComponent.h:46, from FGDeadBand.h:40, from FGDeadBand.cpp:40: ./FGJSBBase.h:41:18: limits: No such file or directory From FGJSBBase.h: #include limits Looks like Mathias added this. It looks like it compiles under CygWin. It's present under IRIX, and it's also present under whatever Linux Mathias is using. Strange. In any case, the #include limits statement needs to be put in the correct #ifdef block, similar to the rest of the c++ headers. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
Jon S Berndt said:
On Wed, 7 Jul 2004 15:30:14 -
Jim Wilson [EMAIL PROTECTED] wrote:
There doesn't seem to be support for the std::numeric_limits
references added
in the June update. Can we work around this?
e.g.:
In file included from FGFCSComponent.h:46,
from FGDeadBand.h:40,
from FGDeadBand.cpp:40:
./FGJSBBase.h:41:18: limits: No such file or directory
From FGJSBBase.h:
#include limits
Looks like Mathias added this. It looks like it compiles under CygWin.
It's present under IRIX, and it's also present under whatever Linux
Mathias is using. Strange. In any case, the #include limits
statement needs to be put in the correct #ifdef block, similar to the
rest of the c++ headers.
In FGKinemat.cpp,
Would
while ( 0.0 dt fabs(Input - Output) 0.1) {
work for this rather than:
while ( 0.0 dt !EqualToRoundoff(Input, Output) ) {
???
Sometimes the simplist solutions are best. I would think that in many cases
integrating variations in precision on different platforms would not always be
a good thing to do.
The above line of code is the only place the limits and the EqualtToRoundoff
functions built with them, are referenced.
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
On Mittwoch, 7. Juli 2004 17:30, Jim Wilson wrote: There doesn't seem to be support for the std::numeric_limits references added in the June update. Can we work around this? Done in JSBSim's cvs. Please check out a new version. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
Mathias Fröhlich said: On Mittwoch, 7. Juli 2004 17:30, Jim Wilson wrote: There doesn't seem to be support for the std::numeric_limits references added in the June update. Can we work around this? Done in JSBSim's cvs. Please check out a new version. I don't see anything in JSBSim CVS that addresses this problem. Did you read the later posts? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
On Wed, 7 Jul 2004 17:35:31 - Jim Wilson [EMAIL PROTECTED] wrote: Mathias Fröhlich said: On Mittwoch, 7. Juli 2004 17:30, Jim Wilson wrote: There doesn't seem to be support for the std::numeric_limits references added in the June update. Can we work around this? Done in JSBSim's cvs. Please check out a new version. I don't see anything in JSBSim CVS that addresses this problem. Did you read the later posts? Jim: If you are browsing CVS, there is a lag between what is committed and what is presented, I think. If you downloaded from CVS and there is still a problem, that would be surprising - CVS is immediate. Are you still seeing the offending code? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
Jon S Berndt said: On Wed, 7 Jul 2004 17:35:31 - Jim Wilson [EMAIL PROTECTED] wrote: Mathias Fröhlich said: On Mittwoch, 7. Juli 2004 17:30, Jim Wilson wrote: There doesn't seem to be support for the std::numeric_limits references added in the June update. Can we work around this? Done in JSBSim's cvs. Please check out a new version. I don't see anything in JSBSim CVS that addresses this problem. Did you read the later posts? Jim: If you are browsing CVS, there is a lag between what is committed and what is presented, I think. If you downloaded from CVS and there is still a problem, that would be surprising - CVS is immediate. Are you still seeing the offending code? That would explain the problem. I'm using the browser. Currently no changes show. Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
Jim Wilson wrote: Jon S Berndt said: On Wed, 7 Jul 2004 17:35:31 - Jim Wilson [EMAIL PROTECTED] wrote: Mathias Frhlich said: On Mittwoch, 7. Juli 2004 17:30, Jim Wilson wrote: There doesn't seem to be support for the std::numeric_limits references added in the June update. Can we work around this? Done in JSBSim's cvs. Please check out a new version. I don't see anything in JSBSim CVS that addresses this problem. Did you read the later posts? Jim: If you are browsing CVS, there is a lag between what is committed and what is presented, I think. If you downloaded from CVS and there is still a problem, that would be surprising - CVS is immediate. Are you still seeing the offending code? That would explain the problem. I'm using the browser. Currently no changes show. CVS on SourceForge isn't immediate for anonymous access. Only people that connect through ssh see the real repository. Others are seeing the backup server that is updated several times a day. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
On Wednesday 07 July 2004 17:44, Jon S Berndt wrote: On Wed, 7 Jul 2004 15:30:14 - Jim Wilson [EMAIL PROTECTED] wrote: There doesn't seem to be support for the std::numeric_limits references added in the June update. Can we work around this? e.g.: In file included from FGFCSComponent.h:46, from FGDeadBand.h:40, from FGDeadBand.cpp:40: ./FGJSBBase.h:41:18: limits: No such file or directory From FGJSBBase.h: #include limits Looks like Mathias added this. It looks like it compiles under CygWin. It's present under IRIX, and it's also present under whatever Linux Mathias is using. Strange. In any case, the #include limits statement needs to be put in the correct #ifdef block, similar to the rest of the c++ headers. I had the same problem on Slackware 8.1. The problem was, that the STL library on Slackware 8.1 was too old. Updating the STL library should solve the problem. The easiest way to do this is off course by updating the distribution. ;) My question is now, does it really make sense to create a work around for this, isn't it better to update the STL library? IMHO the STL makes sense, it saves space, keeps the code clean, programmers don't need to invent the wheel a second time and you will need the STL anyway so why shouldn't we use it? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim C-172 Performance
Jon S Berndt wrote: 3) This one just occurred to me: I wonder if the control inputs from stick and rudder are linear? Or, are they perhaps graduated? In our FCS model, we take the joystick input and map it linearly to the range of values that the control surfaces can see - essentially. It might make sense that for small excursions about center (no control inputs) that control movements are kept small, but as one makes bigger inputs, that the gain increases. Does anyone have any comments on this? If this was in fact the case, it would not be difficult to modify our control system to model this. In fact, even the friction of the control system (or absence of that) could change the perception ... Maybe the (old) C-172 just need some grease in the bearings? ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim C-172 Performance
Jon S Berndt wrote: 3) This one just occurred to me: I wonder if the control inputs from stick and rudder are linear? Or, are they perhaps graduated? The controller devices can be all over the place, but as I mentioned, I'm trying to factor that out -- for example, I'm looking at how the aircraft reacts to a perturbance rather than how much stick it takes to bank, etc. Tony mentioned phugoids and Dutch roll, both of which I've been watching. I also tested both with a spring-loaded joystick and with the mouse (which has no autocentering action at all). I think you might have been onto something with the moments of inertia: our current IXX, IYY, and IZZ apply to a Cessna 182, which is a heavier plane than a 172, though with the same wing area and wingspan. Here are the 182 numbers we're currently using: IXX = 948 IYY = 1346 IZZ = 1967 What numbers do you have for the Cherokee? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim C-172 Performance
On Thu, 20 May 2004 18:48:13 -0400 David Megginson [EMAIL PROTECTED] wrote: I think you might have been onto something with the moments of inertia: our current IXX, IYY, and IZZ apply to a Cessna 182, which is a heavier plane than a 172, though with the same wing area and wingspan. Here are the 182 numbers we're currently using: IXX = 948 IYY = 1346 IZZ = 1967 What numbers do you have for the Cherokee? I'm not sure I see how the 182 figures into this. Higher values for MoI will make the aircraft slower to react to control inputs, and slower to react to damping. From your discussion yesterday I got the feeling that you were stating that the 172 was too wild - i.e. it was not damping out enough. Smaller MoIs would give better damping results (I think). But it would also make the plane more squirrely when it comes to control inputs. I can try and come up with a better estimate of MoI, but we need to be careful how the fuel numbers figure into that - we need to look at the run-time MoI and not the empty weight MoI in the config file. I have two MoI values at least that I can think of offhand: the Navion and the Cherokee. They are both at home. I ought to be able to compare and contrast those, and define a line, then see where the 172 falls with that. It ought to give me a pretty good estimate. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim C-172 Performance
Jon S Berndt wrote: Well, I got a note back from Cessna and (as I pretty much expected) they were tight-lipped about supplying any aero/mass props data, saying instead that the owner's manual was about all I could get. You could always send up a volunteer to do some flight testing. :-) Don't forget to record temp, pressure, flaps settings, etc. I could suggest some good tests to fly. I hear that often people will video tape the instrument panel so they can go back later and double check and verify the results and so they can concentrate on flying and not on recording data. After thinking about this some more, there are three possibilities I can see for any perceived problems: 2) The MoIs are too low. This is possible - I have not yet checked these out, but again I believe we will find these numbers to be pretty good. I have access to a commercial C172 model that has been FAA certified for a level 3 FTD. I wish I could share more of it, but I will say that the IXX, IYY, IZZ we use in FG are *exactly* the same numbers the commercial C172 uses. I looked at some of the other parameters and they are at least an order of magnitude different so they must be using different units or different conventions or something. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim C-172 Performance
Jon S Berndt wrote: I'm not sure I see how the 182 figures into this. Higher values for MoI will make the aircraft slower to react to control inputs, and slower to react to damping. From your discussion yesterday I got the feeling that you were stating that the 172 was too wild - i.e. it was not damping out enough. Smaller MoIs would give better damping results (I think). As an experiment, I tried halving and doubling the MoI's, and both shared many of the same handling problems. I suspect that the problem might be hiding somewhere in the yaw-roll coupling, but that's a tricky one to debug (it also doesn't help pitch control, of course). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim C-172 Performance
2) The MoIs are too low. This is possible - I have not yet checked these out, but again I believe we will find these numbers to be pretty good. I have access to a commercial C172 model that has been FAA certified for a level 3 FTD. I wish I could share more of it, but I will say that the IXX, IYY, IZZ we use in FG are *exactly* the same numbers the commercial C172 uses. The empty weight values? I suppose they must have originated from the manufacturer. I looked at some of the other parameters and they are at least an order of magnitude different so they must be using different units or different conventions or something. For C172: Clp = -0.484 if p is in rad/sec = Clp = -0.0084 if p is in deg/sec This number is highly reliable by calculation and by comparison. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim C-172 Performance
Relevant technical reports (I think the C-172 is included in this report): http://www.dfrc.nasa.gov/DTRS/1966/Bib/H-451.html Abstract: A review of existing criteria indicated that the criteria have not kept pace with aircraft development in the areas of dutch roll, adverse yaw, effective dihedral, and allowable trim changes with gear, flaps, and power. This study indicated that criteria should be specified for control-system friction and control-surface float. Furthermore, this program suggests a method of quantitatively evaluating the handling qualities of aircraft by the use of a pilot-workload factor. --- Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Altitude Hold Autopilot example
On Friday 30 April 2004 13:59, Jon Berndt wrote: I've made some more progress in building an example autopilot using the JSBSim flight control components. I already have a wing leveler for the C-172, but I added an altitude hold module last night. The idea - in words - behind the altitude hold concept (at least the way I have implemented it) is that once a target altitude has been set, one can determine the error between where you are and where you want to be. This error term is limited to 100, filtered with a slight lag, and then multiplied by 0.1 in order to get a commanded HDOT (time derivative of altitude, or rate of climb) of 600 ft/min. This is a slightly unusual way of doing it, normally the commanded HDOT would be limited to 600 ft/min instead of the altitude error. But this approach works great too. This error is run through the altitude hold switch, and either this quantity or zero is passed to a proportional-integral controller (PI). The output from these two components is summed, multiplied by an appropriate gain, and the signal is sent to the elevator. I have a plot online of altitude versus time as the C-172 is commanded to fly (from takeoff) to 800 feet, then 850, then 600, then 2000 ft: http://www.jsbsim.org/JSBSimAltHoldAP.pdf From the plot it looks like the altitude hold performs very well. But if you try another test where you control the throttle in such a way that the aircraft is unable to hold a 600 ft/min vertical speed. I think you will see that the integrator will wind-up as the HDot Error value never reaches zero. The autopilot is configured in JSBSim as follows: COMPONENT NAME=Altitude Error TYPE=SUMMER INPUT -position/h-sl-ft INPUT ap/altitude_setpoint CLIPTO-100 100 /COMPONENT COMPONENT NAME=Alt Error Lag TYPE=LAG_FILTER INPUT fcs/altitude-error C1 0.25 /COMPONENT COMPONENT NAME=HDot Command TYPE=PURE_GAIN INPUT fcs/alt-error-lag GAIN 0.1 /COMPONENT COMPONENT NAME=HDot Error TYPE=SUMMER INPUT fcs/hdot-command INPUT -velocities/h-dot-fps /COMPONENT COMPONENT NAME=AP Alt Hold Switch TYPE=SWITCH TEST LOGIC=DEFAULT VALUE=0.0 /TEST TEST LOGIC=AND VALUE=fcs/hdot-error ap/altitude_hold == 1 /TEST /COMPONENT This integrator will start winding whenever the elevator is saturating and still unable to achieve the commanded climb rate. COMPONENT NAME=Integral TYPE=INTEGRATOR INPUT fcs/ap-alt-hold-switch C1 0.0041 /COMPONENT COMPONENT NAME=Proportional TYPE=PURE_GAIN INPUT fcs/ap-alt-hold-switch GAIN 0.035 /COMPONENT COMPONENT NAME=Control Summer TYPE=SUMMER INPUT fcs/integral INPUT fcs/proportional CLIPTO -1.0 1.0 /COMPONENT COMPONENT NAME=Elevator TYPE=PURE_GAIN INPUT fcs/control-summer GAIN -1.0 OUTPUT ap/elevator_cmd /COMPONENT -- end -- I've got some ideas for future enhancements, including a scheduled target rate-of-climb, so that the aircraft does not try and achieve 600 ft/min near its service ceiling or something silly like that. Also to be added is an automatic cutoff or safety feature, and perhaps the use of throttle to control altitude as appropriate. I guess I really need to read up on specific A/P operation, but this is presently being modeled to give the ability for JSBSim aircraft to fly automatic batch runs for testing, etc. I am going to include this in the JSBSim automatic flight document soon, and will have a block diagram with this, too. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Altitude Hold Autopilot example
Roy Vegard Ovesen [EMAIL PROTECTED] wrote: On Friday 30 April 2004 13:59, Jon Berndt wrote: between where you are and where you want to be. This error term is limited to 100, filtered with a slight lag, and then multiplied by 0.1 in order to get a commanded HDOT (time derivative of altitude, or rate of climb) of 600 ft/min. This is a slightly unusual way of doing it, normally the commanded HDOT would be limited to 600 ft/min instead of the altitude error. But this approach works great too. We don't [_currently_] have a climb rate property in ft/min, although we could add this easily, and I could also manufacture it in the AP using a gain. I finished this up at 3 a.m. this morning, so keep that in mind! I think your observation is a good suggestion for a modification, though. From the plot it looks like the altitude hold performs very well. But if you try another test where you control the throttle in such a way that the aircraft is unable to hold a 600 ft/min vertical speed. I think you will see that the integrator will wind-up as the HDot Error value never reaches zero. This integrator will start winding whenever the elevator is saturating and still unable to achieve the commanded climb rate. Yep. I've got a wind-up protection feature in the integrator, but I haven't used it, yet - that's another area where I want to add some protection. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
Hi, On Montag, 26. April 2004 00:13, Arnt Karlsen wrote: ..ok, time for another of my stupid questions: Mathias, does your new model code include tire creep? And tire sidewall flex? No. At the moment the gear model I use is mostly unchanged. One problem here is the stiffness of the tire model. This is not a special characteristic of our tire model, I would expect that *every* tire model which models what it is called like, is kind of stiff. Stiff in the sense of differential equations which is what we definitly have here. The effect of a stiff ODE (=ordinary differential equation) is that you see some overshooting in the state values. This is what you see when you arrest the brakes and watch the aircraft jiggling. This effect of numerical timestepping couples then back to the tire physics. The short time loss of enough weight on the wheel while the aircraft is jiggling, reduces the friction of the wheel for a short time. When outer forces are applied (wind, thrust) for example your c172 begins to twist. What we attack at the moment is this part of the problem. And this part is sufficient to eliminate the jitter in the gear model and to prevent the aircraft from twisting with brakes appiled. The other part is the tire model itself. What I have in mind here is this Pacejka model. This is a simple parameter fitting generated formula which is, according to the references I found, often used in professional (car) simulations. This model is also something velocity dependent and, like Andy already told, it is harder to produce zero velocity with such a model. Even what I described above slightly moves because of this characteristic, but the movement is extremly small (about 1e-5ft/s). I expect that this tire model contains some kind of sidewall flex. *BUT* I think this is only included in the sense that such effects might show up somewhere and the parameters fitted contain them in some way. Anyway I expect that this model is much closer to a real tire than what we have now. An extension to that model to make it also position dependent is something which makes the problem only stiffer and we are back at the beginning... What we do at the moment is the first part of the problem. This works as expected on my development branch. But it is a long way until this ends in an enduser distribution ... One thing at one time but time will come ... ..a wee virtual demo on tire side wall flex: Take a parked, say Cessna 172, out at the leading edge of the very wing tip, and push it straight aft, then release, and repeat. ..once you get your repeat pushes close to the system resonance frequency, you will find wee pushes generates quite a yaw oscillation, and that it will swing around a point somewhere near the nose wheel. System here, is, tire side wall flexibility (some people prefer doing calculus on its inverse, tire sidewall stiffness), against _parts_ of the wings + tail + nose etc masses. What you describe here will most likely not happen with someting only velocity dependent. Keep it in your head and try to move your aircraft around its nose with that method when we have a better tire model. It you don't get it turned, we can look if this is doable :-) ..a wee virtual demo on tire creep: park an automobile sideways on a slope, so it leans with one side down, buth with the front (and rear) horizontal. Mark the position of at least the up side tires. Lock the steering wheel, say by turning off the ignition and taking the key out of the lock. Now get your fat ass outta the car and push it. ;-) :) ..15 feet forward, then back to those marks, will do fine. Note how far down the tires crept. Tire creep. ;-) This is what I expect to show up with the Pacejka model. Let's see when this is done ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
On Mon, 26 Apr 2004 09:54:43 +0200, Mathias wrote in message [EMAIL PROTECTED]: On Montag, 26. April 2004 00:13, Arnt Karlsen wrote: ..snip. ..a wee virtual demo on tire side wall flex: Take a parked, say Cessna 172, out at the leading edge of the very wing tip, and push it straight aft, then release, and repeat. ..once you get your repeat pushes close to the system resonance frequency, you will find wee pushes generates quite a yaw oscillation, and that it will swing around a point somewhere near the nose wheel. System here, is, tire side wall flexibility (some people prefer doing calculus on its inverse, tire sidewall stiffness), against _parts_ of the wings + tail + nose etc masses. What you describe here will most likely not happen with someting only velocity dependent. ..no? ;-) No velocity, plane is parked. Wee pushes, to exite the resonance. IME, the wee pushes straight aft gets the the plane dancing quite a bit, try it. ;-) Keep it in your head and try to move your aircraft around its nose ..not around the nose, around the nose wheel, usually around a point somewhere between the nose wheel and the mains. with that method when we have a better tire model. It you don't get it turned, we can look if this is doable :-) ..it even works on wet ice in RL. Also for turning the plane around. ;-) ..snip ..15 feet forward, then back to those marks, will do fine. Note how far down the tires crept. Tire creep. ;-) This is what I expect to show up with the Pacejka model. Let's see when this is done ... .. :-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
On Montag, 26. April 2004 11:49, Arnt Karlsen wrote: What you describe here will most likely not happen with someting only velocity dependent. ..no? ;-) No velocity, plane is parked. Wee pushes, to exite the resonance. IME, the wee pushes straight aft gets the the plane dancing quite a bit, try it. ;-) Sorry, I do not have an aircraft ... :( But I can well imagine. Keep it in your head and try to move your aircraft around its nose ..not around the nose, around the nose wheel, usually around a point somewhere between the nose wheel and the mains. Sorry, this is what I meant. By doing what you explained the vehicle will twist around its longitudinal axis. This will mostly not change the weight force on the nose wheel. So this one will stay fixed. What changes is the weight force on the other two wheels which will loose static friction for a short time. And when you apply a little side force during this time the aircraft will move. The nose wheel is fixed by static friction, thus the ac moves around the nosewheel ... The more I think about that, the more I can imagine that even that is in the Pacejka formula. Not with the real physical reason, but I can well imagine that it will just behave like that ... I am not shure how big the influence of the gear strut dynamics is in this case... Let's see ... I have to push this stuff I have now to Jon first ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
When the a/c is stationary the force on the wheels is the aircraft weight less the lift due to airflow over the lifting surfaces (a function of wind). As the a/c progresses on takeoff the above effect should change as the a/c gains speed. I may have forgotten about gear expansion / damping. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
On Samstag, 24. April 2004 21:31, Andy Ross wrote: It's a misfeature in the gear modelling. YASim has pretty much the same behavior. Both FDMs model gear force as a function of skidding velocity, which is fine for dynamic solutions. But a gear that is planted on the ground is capable of holding an aircraft at zero velocity, which doesn't work with the current FDMs -- zero velocity produces zero force. What's needed is code that, at low speeds, uses a spring model for gear force based on the distance in position from where the gear is stopped. Which sounds easy, but in practice is awfully hard. I've gotten started on this several times, and never produced useful code. Yep, kind of true. Jon and I are working on a solution to this. At least for JSBSim. It is not only the gear modelling which plays a role here, the time integration of the equations of motion play a role too. There is code on a development branch in JSBSim's cvs which addresses this and also works well so far. And Andy, If I remember right, I believe that it was a comment of you about the problem beeing stiff, that made me look into JSBSim's timestepping ... ;) Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
Good morning, I took a couple of classes in Matlab/Simulink last month and this was addressed specifically in the class. Matlab permits you to vary timestep size as you approach the ground. It you extrapolate ahead in time to see if any of the gear have come in contact with the ground you can then retreat to the previous time, cut the timestep size down and then go forward again until you capture the ground contact at a fine enough stepsize to prevent instability. It isn't necessary to run the entire simulation at this reduced stepsize if you can run the gear model as a faster subtask of the main simulation. Matlab then does running checks to vary the timestep size on the basis of a predictor-corrector algorithm (if there is a large discontinuity it will go back and systematically chop down the timestep size until the output is "sensible".It's possible in this modern age to find implementation of these algorithms (Adams-Bashforth is one that I'm familiar with. Naturallyyou are takinga chance on frame overruns if you let the program decide its update rate, but then that's fixable too in this age, using a faster processor. When I worked with commercial airline training simulationsthe common "smoke test" to see if everything was working OK was to taxi on the ground with the autopilot running. This was the peak load situationwhere any problems with overruns were most likely to show up. Hope this helps. Nickolas HeinMorgantown WV - Original Message - From: Mathias Fröhlich To: FlightGear developers discussions Sent: Sunday, April 25, 2004 10:26 AM Subject: Re: [Flightgear-devel] Jsbsim trim On Samstag, 24. April 2004 21:31, Andy Ross wrote: It's a misfeature in the gear modelling. YASim has pretty much the same behavior. Both FDMs model gear force as a function of "skidding velocity", which is fine for dynamic solutions. But a gear that is planted on the ground is capable of "holding" an aircraft at zero velocity, which doesn't work with the current FDMs -- zero velocity produces zero force. What's needed is code that, at low speeds, uses a spring model for gear force based on the distance in position from where the gear is "stopped". Which sounds easy, but in practice is awfully hard. I've gotten started on this several times, and never produced useful code.Yep, kind of true.Jon and I are working on a solution to this. At least for JSBSim.It is not only the gear modelling which plays a role here, the time integration of the equations of motion play a role too.There is code on a development branch in JSBSim's cvs which addresses this and also works well so far.And Andy, If I remember right, I believe that it was a comment of you about the problem beeing stiff, that made me look into JSBSim's timestepping ...;) Greetings Mathias-- Mathias Fröhlich, email: [EMAIL PROTECTED]___Flightgear-devel mailing list[EMAIL PROTECTED]http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
Hi, On Sonntag, 25. April 2004 17:24, Nick wrote: I took a couple of classes in Matlab/Simulink last month and this was addressed specifically in the class. Matlab permits you to vary timestep size as you approach the ground. It you extrapolate ahead in time to see if any of the gear have come in contact with the ground you can then retreat to the previous time, cut the timestep size down and then go forward again until you capture the ground contact at a fine enough stepsize to prevent instability. It isn't necessary to run the entire simulation at this reduced stepsize if you can run the gear model as a faster subtask of the main simulation. Matlab then does running checks to vary the timestep size on the basis of a predictor-corrector algorithm (if there is a large discontinuity it will go back and systematically chop down the timestep size until the output is sensible. It's possible in this modern age to find implementation of these algorithms (Adams-Bashforth is one that I'm familiar with. Naturally you are taking a chance on frame overruns if you let the program decide its update rate, but then that's fixable too in this age, using a faster processor. There are even phantastic free odesolvers included in MATLAB odesuite available. I believe that this toolbox is just delivered with current MATLAB versions. You can just plug them in SIMULINK. So if you are at that situation you can do much more. If you just want to stay explicit for some reason you can just use an explicit solver like the ode45, set the atol and rtol values via odeset and let it run. Solvers like ode45 have adaptive stepsize control to get a result with that given accuracy. The downside of this approach is that explicit solvers will detect this stiffness and dependent on how stiff the problem is will reduce the stepsize to something *very* small. Too small to get some realtime behavour ... The other approach is to use the right tool for the given problem, an implicit solver like the ode15s of the odesuite. It will integrate well even if the problem is stiff or a DAE. ode15s can be restricted to a low order solver if your problem is not smooth enough (not enough often steady differntiable). If it is kind of smooth, or at least the sharp bends occure not that often, as is the case for a gear. A gear model is most likly smooth enough up to the point when the tire leaves the ground, at this point it is only steady but not differentiable. Then it might be a good idea to use a higher order solver anyway. For stiff problems I think it is best to use RADAU5 available from http://www.unige.ch/math/folks/hairer/software.html An excellent page for timestepping anyway. This RADAU5 has order 5 and also if required builtin stepsize control. The MATLAB code is not yet there, but I know that there is one (I have it here, a collegue implemented it in MATLAB) and I also know that the author of that page asked for this MATLAB version of RADAU5 to publish it on this page. So it will appear there ... ... wait. It *is* available via http://na.uni-tuebingen.de/na/software.shtml Hope this helps. Yep, kind of ... :) Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
..ok, time for another of my stupid questions: Mathias, does your new model code include tire creep? And tire sidewall flex? ..a wee virtual demo on tire side wall flex: Take a parked, say Cessna 172, out at the leading edge of the very wing tip, and push it straight aft, then release, and repeat. ..once you get your repeat pushes close to the system resonance frequency, you will find wee pushes generates quite a yaw oscillation, and that it will swing around a point somewhere near the nose wheel. System here, is, tire side wall flexibility (some people prefer doing calculus on its inverse, tire sidewall stiffness), against _parts_ of the wings + tail + nose etc masses. ..a wee virtual demo on tire creep: park an automobile sideways on a slope, so it leans with one side down, buth with the front (and rear) horizontal. Mark the position of at least the up side tires. Lock the steering wheel, say by turning off the ignition and taking the key out of the lock. Now get your fat ass outta the car and push it. ;-) ..15 feet forward, then back to those marks, will do fine. Note how far down the tires crept. Tire creep. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Jsbsim trim
..ok, time for another of my stupid questions: Mathias, does your new model code include tire creep? And tire sidewall flex? There are a lot of tire effects that might be modeled. The question faced in deciding what to model is: given the purpose of this FDM, what should be included to achieve the desired effect? There are some great technical papers hosted in the NASA Langley (and perhaps NASA Dryden) technical report servers. Several years ago when I was doing some initial RD for the JSBSim gear model I had some discussions with Bob Daugherty of NASA Langley about gear modeling (where they do a lot of very serious gear modeling and analysis), and he also referred me to some papers. The range of characteristics that might be modeled include tire slip, tire wind-up, spin up, and complex strut interactions, to name only a few of the more difficult ones. These problems are difficult even for detailed engineering sims, and in the case of trying to model any generic vehicle, these problems are compounded. There are some things I'd like for us to model, but JSBSim also hopes to remain comprehensive and comprehensible at the same time, so modeling some of the more subtle effects probably is not worth the effort. In any case, Mathias and I in particular are working on some sweeping changes for JSBSim that ought to make the gear modeling much more stable. After that, there are many other improvements to make - one of which is looking at the gear model to discern where improvements can (and _should_) be made. In the meantime, we are discussing some changes that might be made and doing some limited research into the matter, including reviewing the approaches used by other simulators such as racing sims. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
On Sun, 25 Apr 2004 17:46:25 -0500, Jon wrote in message [EMAIL PROTECTED]: ..ok, time for another of my stupid questions: Mathias, does your new model code include tire creep? And tire sidewall flex? There are a lot of tire effects that might be modeled. The question faced in deciding what to model is: given the purpose of this FDM, what should be included to achieve the desired effect? There are some great technical papers hosted in the NASA Langley (and perhaps NASA Dryden) technical report servers. Several years ago when I was doing some initial RD for the JSBSim gear model I had some discussions with Bob Daugherty of NASA Langley about gear modeling (where they do a lot of very serious gear modeling and analysis), and he also referred me to some papers. The range of characteristics that might be modeled include tire slip, tire wind-up, spin up, and complex strut interactions, to name only a few of the more difficult ones. These problems are difficult even for detailed engineering sims, and in the case of trying to model any generic vehicle, these problems are compounded. There are some things I'd like for us to model, but JSBSim also hopes to remain comprehensive and comprehensible at the same time, so modeling some of the more subtle effects probably is not worth the effort. In any case, Mathias and I in particular are working on some sweeping changes for JSBSim that ought to make the gear modeling much more stable. After that, there are many other improvements to make - one of which is looking at the gear model to discern where improvements can (and _should_) be made. In the meantime, we are discussing some changes that might be made and doing some limited research into the matter, including reviewing the approaches used by other simulators such as racing sims. ..good. :-) Also, keep that compresses doughnut of compressed air in mind, as in; spin up a pressurized tire for at least 3 minutes, then stop-it-n-yank-it-off-that-shaft and try carry it around. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
On Mon, 26 Apr 2004 03:37:53 +0200, Arnt wrote in message [EMAIL PROTECTED]: ..good. :-) Also, keep that ...errr... doughnut of compressed air in mind, as in; spin up a pressurized tire for at least 3 minutes, then stop-it-n-yank-it-off-that-shaft and try carry it around. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
I've seen this as well, but as far as I can tell, this is due to the wind blowing against the tail. I've seen this more stronger with heavy winds, and the yawing of the aircraft in heavy winds appears to change with changing rudder position, as I expected. Cheers, Durk On Saturday 24 April 2004 20:40, Chris Horler wrote: Jon Anyone else interested. I reset the c172 default start up a/c (reset or not this happens). I reset then put parking brake on. Leave it for 5 mins and then notice it's yawed slightly to port. Chris. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
Durk Talsma wrote: I've seen this as well, but as far as I can tell, this is due to the wind blowing against the tail. I've seen this more stronger with heavy winds, and the yawing of the aircraft in heavy winds appears to change with changing rudder position, as I expected. It's a misfeature in the gear modelling. YASim has pretty much the same behavior. Both FDMs model gear force as a function of skidding velocity, which is fine for dynamic solutions. But a gear that is planted on the ground is capable of holding an aircraft at zero velocity, which doesn't work with the current FDMs -- zero velocity produces zero force. What's needed is code that, at low speeds, uses a spring model for gear force based on the distance in position from where the gear is stopped. Which sounds easy, but in practice is awfully hard. I've gotten started on this several times, and never produced useful code. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jsbsim trim
Andy, It's a misfeature in the gear modelling. YASim has pretty much the same behavior. Both FDMs model gear force as a function of skidding velocity, which is fine for dynamic solutions. But a gear that is planted on the ground is capable of holding an aircraft at zero velocity, which doesn't work with the current FDMs -- zero velocity produces zero force. It sounds as if we were to tell the weather system to model a significantly strong hurricane that we would see the parked aircraft swept away. What I'm leading up to is that if this effect is happening whilst stationary, it's probably making the a/c more difficult to control on takeoff than it really is. That is if it still happens when the a/c is rolling. Just thinking about it... When the a/c is stationary the force on the wheels is the aircraft weight less the lift due to airflow over the lifting surfaces (a function of wind). As the a/c progresses on takeoff the above effect should change as the a/c gains speed. If it's having an effect straight away does it not need offsetting until a certain airspeed is reached (due to the weather system or a/c movement)? What's needed is code that, at low speeds, uses a spring model for gear force based on the distance in position from where the gear is stopped. Which sounds easy, but in practice is awfully hard. I've gotten started on this several times, and never produced useful code. So you're suggesting that the a/c mass, a friction coefficient dependent on weather condition and landing surface and tyre contact area are combined to provide a more realistic static case? If I've interpreted you correctly... what was the problem encountered? Chris. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Flight Dynamics Model Newsletter
Jon Berndt said: I will be publishing a quarterly newsletter firmly centered around JSBSim and flight dynamics modeling. If it takes off (pun intended) and I get more help, perhaps it will go monthly. This is different than a web site insofar as it will be meant for a wider audience than might visit the JSBSim web site - a wider audience than developers. Additionally, I expect it could get printed out and read at leisure away from the computer. The visual design is meant to be somewhat retro. The first issue is released. Normally in the future, it will be linked from the JSBSim home page. I haven't gotten that far, yet. However, you can view it directly here: http://www.jsbsim.org/JSBSimNewsletter_1_1.pdf Comments appreciated. Submissions appreciated more ;-) Although I do end up reading a lot on screen, it is very nice to be able to print something well formatted and read offline (for one my reading glasses work better with paper). So the first issue of Back of the Envelope is printing as I write this. Nice looking layout and the articles look interesting. Many thanks! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
On Freitag, 2. April 2004 15:13, Jim Wilson wrote: Or, in other words, why should a FDM need to know that groundlevels below -9990ft are an error condition of the tile loader? My response is that the Init is merely for setting up and initializing data structures. Hmm, but virtually every FDM calls FGInterface::common_init() in init(). And this one copies the initial values of the aircraft into the FDM. So if this data is screwed up at call of init(), this screwed up data ends in the FDM. This should happen independent of what is on the bus. The updates should basically noop until all the parts it needs are initialized, although with something like this case it might be fine to merely delay the ground trimming, but go ahead and process non-external data. Ok, I can find this is_suspended() call in the first line of JSBSim::update(double). So I guess that this is_suspended() call should return true as long as the remaining subsystems are not set up? Or how is this interface supposed to know when it can start computing physics? Ok, I have prepared all set_* calls in the JSBsim FGInterface with a cout function name function arguments to see what is different when the FDM is initialized at the first time and at reset time. This is the output at flightgear start: virtual void FGJSBsim::init() virtual void FGJSBsim::set_Longitude(double) long = 0.198215 virtual void FGJSBsim::set_Latitude(double) lat = 0.824871 virtual void FGJSBsim::set_Altitude(double) alt = 1949.82 virtual void FGJSBsim::set_V_calibrated_kts(double) vc = 0 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::update(double) is_suspended() 0 void FGJSBsim::do_trim() virtual void FGJSBsim::update(double) is_suspended() 0 What we can see here is that there is no problem with agl or altitude below -9990ft. Also the is_suspended() call is never true. This are the JSBSim FGInterface function entries when I press the reset menu entry: virtual void FGJSBsim::init() virtual void FGJSBsim::set_Longitude(double) long = 0.198215 virtual void FGJSBsim::set_Latitude(double) lat = 0.824871 virtual void FGJSBsim::set_Altitude(double) alt = 1949.82 virtual void FGJSBsim::set_V_calibrated_kts(double) vc = 0 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Euler_Angles(double, double, double) phi = 0, theta = 0.0074002, psi = 4.55583 virtual void FGJSBsim::set_Climb_Rate(double) roc = -0.00421123 virtual void FGJSBsim::set_Gamma_vert_rad(double) gamma = -0.00082482 virtual void FGJSBsim::update(double) is_suspended() 0 void FGJSBsim::do_trim() The set_Climb_Rate, set_Gamma_vert_rad calls are new here. And I think that this is the problem. The rest looks identical. Ok, when I see this, I think that we should eliminate the duplicate calls. And I still think that it is not the job of a specific FDM to check for an error condition of the tile loader, even if this is not the error at the moment. BTW I'm not sure of your characterization of the relationship between these two subsystems. That was my question, is this more than just ground trimming? I get more and more confused with this interface. JSBSim, copies almost all initial conditions at the init() call and updates these values with the ones superseeded by FGInterface::set_* calls. At the first entry to update(double) it checks if some initial conditions have changed and trims if required. So how is this interface class supposed to work? What could a FDM expect to be set up at which call to an interface function? And where is this documented :-) ? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
On Freitag, 2. April 2004 05:47, Jim Wilson wrote: Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. Others don't work too. The A320 for example ends upside down too. The issue appears to be due to a difference between how the FDM is initialized on startup and how it is initialized on restart. On startup the FDM initialization is delayed until a tile is loaded for the startup location, giving an accurate ground elevation value (test for gound_elev -9990). This test is not possible during the reinit phase, because we're only passing through the reinitialize routine once. The more I look at the workarounds we have been accumulating for making flightgear initialize and reinitialize the more I realize that we may be frequently taking the wrong approach to solving such issues. We are failing to build self-sufficient and self-protecting subsystems. :) Hmm, I am not very familiar with the way flightgear interfaces with a FDM. What I can tell now is that JSBSim has a problem with it's timestepping method during reinitialization. But Jon and me are working on this. But this is not the whole problem. Doing this right is not sufficient. Which is why I'm calling this a JSBSim bug. If the altitude is -9990 and/or the ground_elelvation is -9990, would it be possible for JSBSim to not ground trim and instead go for a coffee or freeze or whatever it needs to do while the scenery system gets wound up? In other words, rather than try and find another bandaid, what I would like to do is remove the elevation test from following code in main.cxx and let the fdm take care of itself: I am not shure what happens here. But it appears to me that either FGInterface::update(double) or FGInterface::init() is called while the environment (ground level, etc ...) containes senseless data, true? So, for the coffee question, I think that this could be done. But you told about self-sufficient and self-protecting subsystems. I don't think that this goal could be achieved when code, which in effect tests for an error condition of the tile loader, which is something orthogonal to flightdynamics, is moved into a FDM. Just call FGInterface::init() when the FDM has *all* data required for initialization. The same goes for FGInterface::update(double), it should not be called when the FDM sees screwed up environment data ... Or, in other words, why should a FDM need to know that groundlevels below -9990ft are an error condition of the tile loader? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
Mathias Fröhlich said: On Freitag, 2. April 2004 05:47, Jim Wilson wrote: Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. Others don't work too. The A320 for example ends upside down too. The issue appears to be due to a difference between how the FDM is initialized on startup and how it is initialized on restart. On startup the FDM initialization is delayed until a tile is loaded for the startup location, giving an accurate ground elevation value (test for gound_elev -9990). This test is not possible during the reinit phase, because we're only passing through the reinitialize routine once. The more I look at the workarounds we have been accumulating for making flightgear initialize and reinitialize the more I realize that we may be frequently taking the wrong approach to solving such issues. We are failing to build self-sufficient and self-protecting subsystems. :) Hmm, I am not very familiar with the way flightgear interfaces with a FDM. What I can tell now is that JSBSim has a problem with it's timestepping method during reinitialization. But Jon and me are working on this. But this is not the whole problem. Doing this right is not sufficient. Which is why I'm calling this a JSBSim bug. If the altitude is -9990 and/or the ground_elelvation is -9990, would it be possible for JSBSim to not ground trim and instead go for a coffee or freeze or whatever it needs to do while the scenery system gets wound up? In other words, rather than try and find another bandaid, what I would like to do is remove the elevation test from following code in main.cxx and let the fdm take care of itself: I am not shure what happens here. But it appears to me that either FGInterface::update(double) or FGInterface::init() is called while the environment (ground level, etc ...) containes senseless data, true? So, for the coffee question, I think that this could be done. But you told about self-sufficient and self-protecting subsystems. I don't think that this goal could be achieved when code, which in effect tests for an error condition of the tile loader, which is something orthogonal to flightdynamics, is moved into a FDM. Just call FGInterface::init() when the FDM has *all* data required for initialization. The same goes for FGInterface::update(double), it should not be called when the FDM sees screwed up environment data ... Or, in other words, why should a FDM need to know that groundlevels below -9990ft are an error condition of the tile loader? My response is that the Init is merely for setting up and initializing data structures. This should happen independent of what is on the bus. The updates should basically noop until all the parts it needs are initialized, although with something like this case it might be fine to merely delay the ground trimming, but go ahead and process non-external data. BTW I'm not sure of your characterization of the relationship between these two subsystems. That was my question, is this more than just ground trimming? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. I don't use the reset feature, but I just tried a few runs with the 737 and T38 using the menu item Location | Position Aircraft (on ground), and this works every time. Is there a different reset function? If so, then the answer might be in the code attached to the above menu item. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
On Friday 02 Apr 2004 2:23 pm, David Culp wrote: Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. I don't use the reset feature, but I just tried a few runs with the 737 and T38 using the menu item Location | Position Aircraft (on ground), and this works every time. Is there a different reset function? If so, then the answer might be in the code attached to the above menu item. Dave The reset function I (hardly ever) use is bound to Shift-Esc in data/keyboard.xml: key n=27 nameESC/name descPrompt and quit FlightGear./desc binding commanddialog-show/command dialog-nameexit/dialog-name /binding mod-shift descReset FlightGear./desc binding commandold-reinit-dialog/command /binding /mod-shift /key 'Location | Position Aircraft (on ground)' didn't work for me at a number of Californian airfields with the C172-3d - an external view shows the plane tumbling around the sky like an empty plastic bag! I also tried to position in air, which was more successful, except I wasn't quite ready for the magneto switch being in the OFF position :¬) Good job I didn't have to get out and swing the propeller, eh? Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim initialization bug
Earlier we had a report of a reset issue on the list. It appears that the
problem only affects a couple JSBSim aircraft...the c172 (all of
them) and the 737. Everything else seems to trim fine.
I wonder why this is only an issue with these aircraft ???
Which is why I'm calling this a JSBSim bug. If the altitude is -9990
and/or
the ground_elelvation is -9990, would it be possible for JSBSim to not
ground trim and instead go for a coffee or freeze or whatever it
needs to do while the scenery system gets wound up?
So, which one is the key? What is altitude in the above context? I assume
you are not talking about aircraft altitude ... ? What kind of re-init is
desired or expected?
In other words, rather than try and find another bandaid, what
I would like to do is remove the elevation test from following code in
main.cxx and let the fdm take care of itself:
if ( !cur_fdm_state-get_inited()
globals-get_scenery()-get_cur_elev() -9990 )
{
SG_LOG(SG_FLIGHT,SG_INFO, Finally initializing fdm);
cur_fdm_state-init();
if ( cur_fdm_state-get_bound() ) {
cur_fdm_state-unbind();
}
cur_fdm_state-bind();
}
I'm all for doing it right. I'm sure we can change this to make any
proposal work. I'm a little rusty on this stuff, though, so the more input
you give me the better.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim initialization bug
Jon Berndt said:
Earlier we had a report of a reset issue on the list. It appears that the
problem only affects a couple JSBSim aircraft...the c172 (all of
them) and the 737. Everything else seems to trim fine.
I wonder why this is only an issue with these aircraft ???
Which is why I'm calling this a JSBSim bug. If the altitude is -9990
and/or
the ground_elelvation is -9990, would it be possible for JSBSim to not
ground trim and instead go for a coffee or freeze or whatever it
needs to do while the scenery system gets wound up?
So, which one is the key? What is altitude in the above context? I assume
you are not talking about aircraft altitude ... ? What kind of re-init is
desired or expected?
In other words, rather than try and find another bandaid, what
I would like to do is remove the elevation test from following code in
main.cxx and let the fdm take care of itself:
if ( !cur_fdm_state-get_inited()
globals-get_scenery()-get_cur_elev() -9990 )
{
SG_LOG(SG_FLIGHT,SG_INFO, Finally initializing fdm);
cur_fdm_state-init();
if ( cur_fdm_state-get_bound() ) {
cur_fdm_state-unbind();
}
cur_fdm_state-bind();
}
I'm all for doing it right. I'm sure we can change this to make any
proposal work. I'm a little rusty on this stuff, though, so the more input
you give me the better.
It's probably just ground_elev, although I notice the altitude is - on the
first pass. The init and reinit is fine, what is broken is how a bogus value
(ground_evel of -9990) is handled. The ground elevation test in the
scenery code returns - when the current scenery tile isn't loaded yet.
I'm going to try testing the ground_elev in the update() call in JSBSim.cxx,
but there are several places where elevation is looked at and it isn't clear
to me where (or if) trouble might occur. Probably just checking before
calling dotrim() will fix this particular issue. I would just ask the
question, if we knew that the elevation (and/or altitude?) values could be
bogus, what would we do differently? The other question I guess is how we
define bogus. Is -9990 for any value sufficient?
As far as why those two aircraft not the others... I was hoping someone else
might know :-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBsim fails to build in FGFS cvs
On Fri, 20 Feb 2004 09:08:26 -0800 (PST) Gopal Mor [EMAIL PROTECTED] wrote: The error messages obtained during compilation are as follow FGEngine.cpp:71: no matching function for call to `basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 ::clear ()' I think I have seen this one before, too. It's this line: Name.clear(); Change it to this: Name = ; It's been the former way for five months, so it's strange to see it causing a problem, now. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBsim fails to build in FGFS cvs
Are you using the version in FGFS CVS? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alex Perry Sent: Monday, January 19, 2004 12:49 AM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] JSBsim fails to build in FGFS cvs Making all in filtersjb make[1]: Entering directory `/home/alex/fs/FlightGear/src/FDM/JSBSim/filtersjb' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/alex/fs/FlightGear/src/FDM/JSBSim/filtersjb' make[1]: Entering directory `/home/alex/fs/FlightGear/src/FDM/JSBSim' source='FGEngine.cpp' object='FGEngine.o' libtool=no \ depfile='.deps/FGEngine.Po' tmpdepfile='.deps/FGEngine.TPo' \ depmode=gcc /bin/sh ../../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../../src/Include -I../../.. -I../../../src -I/usr/X11R6/include -DFGFS -g -O2 -D_REENTRANT -c -o FGEngine.o `test -f FGEngine.cpp || echo './'`FGEngine.cpp FGEngine.cpp: In method `JSBSim::FGEngine::FGEngine(JSBSim::FGFDMExec *)': FGEngine.cpp:71: no matching function for call to `basic_stringchar,string_char_traitschar,__default_alloc_templa tetrue,0 ::clear ()' make[1]: *** [FGEngine.o] Error 1 make[1]: Leaving directory `/home/alex/fs/FlightGear/src/FDM/JSBSim' make: *** [all-recursive] Error 1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBsim fails to build in FGFS cvs
What system are you building under? Erik made some changes recently to facilitate building under IRIX. That's the only change that happened in FGEngine.cpp. Strange. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alex Perry Sent: Monday, January 19, 2004 12:49 AM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] JSBsim fails to build in FGFS cvs Making all in filtersjb make[1]: Entering directory `/home/alex/fs/FlightGear/src/FDM/JSBSim/filtersjb' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/alex/fs/FlightGear/src/FDM/JSBSim/filtersjb' make[1]: Entering directory `/home/alex/fs/FlightGear/src/FDM/JSBSim' source='FGEngine.cpp' object='FGEngine.o' libtool=no \ depfile='.deps/FGEngine.Po' tmpdepfile='.deps/FGEngine.TPo' \ depmode=gcc /bin/sh ../../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../../src/Include -I../../.. -I../../../src -I/usr/X11R6/include -DFGFS -g -O2 -D_REENTRANT -c -o FGEngine.o `test -f FGEngine.cpp || echo './'`FGEngine.cpp FGEngine.cpp: In method `JSBSim::FGEngine::FGEngine(JSBSim::FGFDMExec *)': FGEngine.cpp:71: no matching function for call to `basic_stringchar,string_char_traitschar,__default_alloc_templa tetrue,0 ::clear ()' make[1]: *** [FGEngine.o] Error 1 make[1]: Leaving directory `/home/alex/fs/FlightGear/src/FDM/JSBSim' make: *** [all-recursive] Error 1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBsim fails to build in FGFS cvs
I had this problem on my debian system. Apparently bastring.h in the STL is missing clear in some old versions of libstdc++. I ugraded to g++ 3.3 and a new version of libstdc++ and it compiled ok after that. Hope that helps, -Adam Jon Berndt [EMAIL PROTECTED] wrote: What system are you building under? Erik made some changes recently to facilitate building under IRIX. That's the only change that happened in FGEngine.cpp. Strange. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alex Perry Sent: Monday, January 19, 2004 12:49 AM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] JSBsim fails to build in FGFS cvs Making all in filtersjb make[1]: Entering directory `/home/alex/fs/FlightGear/src/FDM/JSBSim/filtersjb' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/alex/fs/FlightGear/src/FDM/JSBSim/filtersjb' make[1]: Entering directory `/home/alex/fs/FlightGear/src/FDM/JSBSim' source='FGEngine.cpp' object='FGEngine.o' libtool=no \ depfile='.deps/FGEngine.Po' tmpdepfile='.deps/FGEngine.TPo' \ depmode=gcc /bin/sh ../../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../../src/Include -I../../.. -I../../../src -I/usr/X11R6/include -DFGFS -g -O2 -D_REENTRANT -c -o FGEngine.o `test -f FGEngine.cpp || echo './'`FGEngine.cpp FGEngine.cpp: In method `JSBSim::FGEngine::FGEngine(JSBSim::FGFDMExec *)': FGEngine.cpp:71: no matching function for call to `basic_stringchar,string_char_traitschar,__default_alloc_templa tetrue,0 ::clear ()' make[1]: *** [FGEngine.o] Error 1 make[1]: Leaving directory `/home/alex/fs/FlightGear/src/FDM/JSBSim' make: *** [all-recursive] Error 1 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] jsbsim
hi, is there a possibility to build a Differentiator of a property analog to the integrator? I did not find somethink like this in the docs for fcs-components. I want to build a d/d(t) of a property. Is this the GRADIENT type of COMPONENT, which is not impl. yet ? for speed properties there is work around, just take the accel. property instead, but I have to calc the d/d(t) of an accel. thx markus Interesting. You've got me stumped for the moment. But, then, I just got up. Let me have some coffee and think about this. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Coefficients Intro
Jon S Berndt writes: Ha! That's probably a better title than Modifications of Stability Derivatives and Aerodynamic Coefficients in JSBSim. The latter might scare people away, whereas yours draws them in. ;-) It is also an accurate description of the noise my O320 engine makes at me when I try to start it in cold weather. Let me know when you find the mistakes that (I'm sure) are present. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim resets (was: Problem: unrealisticYASim stalls)
On Tue, 2003-01-07 at 14:35, Erik Hofman wrote: Curtis L. Olson wrote: I think it would be much cleaner to force a reset to a new location each time we warp to a new location. This allows us to delete the FDM instance and create a new one so it can be freshly inited and trimmed for the new conditions. Otherwise, it's really hard not to carry over some state from the previous location which can cause obscenely large forces and other wierdness. On a side note, I noticed that after a reset there are two instances of /fdm/jsbsim hanging around. I thing the previous one should be removed, but I don't know if that is possible already. Hmm ... thanks. I'll look into that. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim re-init crash
Tony, I'm getting a different crash on reset now, but gdb says it's happening in fgInitFDM() Regards, Curt. Tony Peden writes: This should be fixed. On Tue, 2002-09-24 at 06:44, Curtis L. Olson wrote: Tony, After your recent changes, when I try to do a reset from the FlightGear menu I get: FGPropertyManager::GetNode() No node found for fcs/componentspitch-trim-sum Segmentation fault This doesn't happen in Yasim models so it looks like it's confined to JSBSim. Maybe just a typo in a property name? Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Build Problem Under MSVC
I second that idea to use streams instead of old C formating. We can use ostrstream, or better, ostringstream classes -Fred - Original Message - From: Jon Berndt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 01, 2002 5:15 AM Subject: RE: [Flightgear-devel] JSBSim Build Problem Under MSVC I'd prefer to get away from using _snprintf, snprintf, or whatever. The only reason we use them (IIRC) is to limit the length of an output string. This can be done in other ways, such as using the string class. Since they would not be used in performance critical areas, maybe that's an option? Jon Does it make sense to have _snprintf() instead of snprintf()? I tried defining the function extern, but it wasn't found in the library. I suppose anther question would be, is it safe to use _snprintf() under windows and snprintf() everywhere else? FWIW, _snprintf() is defined in stdio.h. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Build Problem Under MSVC
On Tue, 2002-04-30 at 17:24, Jonathan Polley wrote: Here is one you will all like. It appears as if MSVC does not define snprintf() in any of its headers, but it does have _snprintf() with the same parameter list. RG! In JSBSim/FGFCS.cpp, I had to add a #define to map _snprintf() to snprintf( ) Sorry about that. in order to get the latest CVS updates to build. I wasn't sure if replacing snprintf() with sprintf() would be safe, so I didn't. It's not, that's why snprintf exists. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Build Problem Under MSVC
On Tuesday, April 30, 2002, at 08:57 PM, Tony Peden wrote: On Tue, 2002-04-30 at 17:24, Jonathan Polley wrote: In JSBSim/FGFCS.cpp, I had to add a #define to map _snprintf() to snprintf( ) Sorry about that. Does it make sense to have _snprintf() instead of snprintf()? I tried defining the function extern, but it wasn't found in the library. I suppose anther question would be, is it safe to use _snprintf() under windows and snprintf() everywhere else? FWIW, _snprintf() is defined in stdio.h. -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim Build Problem Under MSVC
I'd prefer to get away from using _snprintf, snprintf, or whatever. The only reason we use them (IIRC) is to limit the length of an output string. This can be done in other ways, such as using the string class. Since they would not be used in performance critical areas, maybe that's an option? Jon Does it make sense to have _snprintf() instead of snprintf()? I tried defining the function extern, but it wasn't found in the library. I suppose anther question would be, is it safe to use _snprintf() under windows and snprintf() everywhere else? FWIW, _snprintf() is defined in stdio.h. smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] JSBSim update ....
On Thu, 11 Apr 2002 18:52:24 +0200 Martin Spott [EMAIL PROTECTED] wrote: make[4]: Entering directory make[4]: *** [JSBSim.o] Error 1 quickstep: 18:51:57 ~ gcc --version 2.95.3 Yep, we're aware of it. I'll fix this when I get home. We use the max/min functions in other parts of JSBSim. I think David was unaware of the compatibility problems min/max faces. I'll have to grep on the JSBSim code to find if/where we are using max/min in other parts of JSBSim and how we got around this. Patience ... we'll fix it, and sorry for the mixup. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: RE: Re: [Flightgear-devel] JSBSim Body Axes question
The definition of a positive aileron deflection is when the right-hand aileron deflects according to the right hand rule - that is, trailing edge down (TED). Unfortunately, this results in a negative roll rate - it would be nice if our choice of coordinate system caused a positive aileron deflection to result in a positive roll rate, but this is not the case. :-( Anyhow, yes, Tony wanted to control each aileron individually, so this was changed. It *should* *be* the same to you and I. It's just that the left aileron will get the negative of the right aileron deflection. A control system *could* use the ailerons as flaps AND as ailerons. These are called flaperons. The space shuttle uses the wing outer control surfaces as ailerons and elevator. These are called elevons. You might also combine flaps, spoilers, ailerons, and elevator and call it a slapevon. Well ... maybe not. ;-) In any case, Tony was right to split out the left and right aileron controls because we might want to model an aircraft that addresses various control surfaces in unique and interesting ways. Jon Yes, It is necessary to control the ailerons separately for widely use. I just found that a positive aileron pos result in a positive roll rate -- the JSBSim version is downloaded 2 weeks ago. It run with C172 model. and I did a little change. If you can be sure that positive aileron pos would result in nagative roll rate, that must be my matter. Let me check it . thank you for your patience. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim compile error
make[4]: Entering directory `/home/david/flightgear/FlightGear/src/FDM/JSBSim' c++ -DFGFS -I../../.. -I../../../src -I/usr/local/include - -I/usr/X11R6/include -g -O2 -D_REENTRANT -c JSBSim.cpp JSBSim.cpp: In method `bool FGJSBsim::copy_from_JSBsim()': JSBSim.cpp:530: no matching function for call to `FGFCS::GetDePosN ()' JSBSim.cpp:531: no matching function for call to `FGFCS::GetDaLPosN ()' JSBSim.cpp:532: no matching function for call to `FGFCS::GetDaLPosN ()' JSBSim.cpp:533: no matching function for call to `FGFCS::GetDrPosN ()' JSBSim.cpp:534: no matching function for call to `FGFCS::GetDfPosN ()' make[4]: *** [JSBSim.o] Error 1 Anyone else getting this? Thanks, David No. GetDrPosN() and similar functions are now gone. Are you running from JSBSim CVS? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile error
On Mon, 2002-04-01 at 03:22, David Findlay wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 make[4]: Entering directory `/home/david/flightgear/FlightGear/src/FDM/JSBSim' c++ -DFGFS -I../../.. -I../../../src -I/usr/local/include - -I/usr/X11R6/include -g -O2 -D_REENTRANT -c JSBSim.cpp JSBSim.cpp: In method `bool FGJSBsim::copy_from_JSBsim()': JSBSim.cpp:530: no matching function for call to `FGFCS::GetDePosN ()' JSBSim.cpp:531: no matching function for call to `FGFCS::GetDaLPosN ()' JSBSim.cpp:532: no matching function for call to `FGFCS::GetDaLPosN ()' JSBSim.cpp:533: no matching function for call to `FGFCS::GetDrPosN ()' JSBSim.cpp:534: no matching function for call to `FGFCS::GetDfPosN ()' make[4]: *** [JSBSim.o] Error 1 Anyone else getting this? Thanks, It sounds like you've got an old version of JSBSim.cxx. David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8qEMSx58m2d272NoRAsAlAJ9Rqv93kcAkfIkPiQhKap1U/A5hrQCfSVvd 0yWSkrnFh2MrTOr032fBe5A= =r9hj -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Body Axes question
On Tue, Apr 02, 2002 at 11:05:18AM +0800, wrote: Could someone help me out please? In the JSBSimCoordinates.pdf from http://jsbsim.sourceforge.net, we know that the Xbody Axis positive forward out through out the nose of the plane, Ybody positive out the right side, Zbody Axis positive downwards. Then we know that: (look from the tail of the plane) (1) roll rate (p) clockwise are positive; (2) roll angle (phi) clockwise are positive; (3) left-aileron up and right-aileron down are positive; Right? The flight controls follow the right hand rule relative to the body axis system. This means that *both* ailerons are positive trailing edge down and negative trailing edge up. Assume the plane flying steadily now, if aileron left-up and right-down , that is aileron position increase , the plane would roll anti-clockwise, that is roll rate (or roll angle) would decrease? Right? But why does JSBSim not match it? When I increase aileron position, the roll rate and roll angle increase too. Who can tell me why? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Re: [Flightgear-devel] JSBSim Body Axes question
On Tue, Apr 02, 2002 at 11:05:18AM +0800, wrote: Could someone help me out please? In the JSBSimCoordinates.pdf from http://jsbsim.sourceforge.net, we know that the Xbody Axis positive forward out through out the nose of the plane, Ybody positive out the right side, Zbody Axis positive downwards. Then we know that: (look from the tail of the plane) (1) roll rate (p) clockwise are positive; (2) roll angle (phi) clockwise are positive; (3) left-aileron up and right-aileron down are positive; Right? The flight controls follow the right hand rule relative to the body axis system. This means that *both* ailerons are positive trailing edge down and negative trailing edge up. In the older version of JSBSim, we control the two ailerons at the same time. The turnning orientation of them are opposite(One up , another down)? if so , left-up and right-down are positive? In the newer version of JSBSim , we can control the two ailerons separately. then Can they somtimes act as flags do? and what is the positive position of them? I am using the older version of JSBSim with ailerons controled simultaneously. thanks. Assume the plane flying steadily now, if aileron left-up and right-down , that is aileron position increase , the plane would roll anti-clockwise, that is roll rate (or roll angle) would decrease? Right? But why does JSBSim not match it? When I increase aileron position, the roll rate and roll angle increase too. Who can tell me why? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: Re: [Flightgear-devel] JSBSim Body Axes question
The definition of a positive aileron deflection is when the right-hand aileron deflects according to the right hand rule - that is, trailing edge down (TED). Unfortunately, this results in a negative roll rate - it would be nice if our choice of coordinate system caused a positive aileron deflection to result in a positive roll rate, but this is not the case. :-( Anyhow, yes, Tony wanted to control each aileron individually, so this was changed. It *should* *be* the same to you and I. It's just that the left aileron will get the negative of the right aileron deflection. A control system *could* use the ailerons as flaps AND as ailerons. These are called flaperons. The space shuttle uses the wing outer control surfaces as ailerons and elevator. These are called elevons. You might also combine flaps, spoilers, ailerons, and elevator and call it a slapevon. Well ... maybe not. ;-) In any case, Tony was right to split out the left and right aileron controls because we might want to model an aircraft that addresses various control surfaces in unique and interesting ways. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Inlining
Julian Foad writes: I experimented with the effect of inlining on code size and compile times (but not run-time performance) on the src/FDM/JSBSim tree within FlightGear CVS as of about a week ago. I did this by supplying different compiler options with make CFLAGS=... CXXFLAGS= Code size: secondsbytes options Smallest:203 761360 -g -O1 -finline-limit-6 -finline-functions Smallest O2: 233 767064 -g -O2 -finline-limit-6 -finline-functions Default: 3881328284 -g -O2 Largest: 3881328284 -g -O2 This morning, I rebuilt both SimGear and FlightGear completely, with CFLAGS and CXXFLAGS set to -g -O1 -finline-limit=6 -finline-functions Here is the size of the old binary (using -O2): textdata bss dec hex filename 3097230 500980 3121944 6720154 668a9a /usr/local/FlightGear/bin/fgfs Here is the size of the new binary (using -O1 etc.): textdata bss dec hex filename 2484117 690300 3121976 6296393 601349 /usr/local/src/FlightGear/src/Main/fgfs The size saving is not all that dramatic: the old binary had text+data=3598210, while the new binary has text+data=3174417, resulting in about a 12% size saving. Compilation time felt much faster, but I didn't actually time it. I ran a few quick framerate tests, both on the ground and in the air, without panel or hud, in external and pilot view. The framerates for both binaries are always within 1fps of each other, so cutting out most of the inlining makes no measurable difference, positive or negative. If other people's tests show the same result, then I suggest that we switch the default CXXFLAGS and CFLAGS, if only for the sake of faster compiles and a slightly smaller executable. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Inlining
Julian Foad wrote: Code size: secondsbytes options Smallest:203 761360 -g -O1 -finline-limit-6 -finline-functions Smallest O2: 233 767064 -g -O2 -finline-limit-6 -finline-functions Default: 3881328284 -g -O2 Largest: 3881328284 -g -O2 Wow. Good stuff. So basically we're looking at a 2x difference in both size and compile time between the best and (what we're using now) the worst. One nit, though, is that those executables are unstripped (I presume -- the -g option would be useless without it). So presuming that the symbol table never enters the cache at runtime (it doesn't, except when inspected by the debugger) and that the symbol tables should be the same for both the inlined and non-inlined versions (probably true), the actual difference in code size is going to be significantly *larger* than 2x. Eeek. I'm going to start turning off inlining using the arguments above as a matter of habit, I think. If I don't see any significant performance change, I'll come back and start whining to the list that we make this the default. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] JSBSim Inlining
Tony Peden writes: Also, I was able to better quantify the performance change due to incorporating the properties code. Prior to this, I had done speed comparisons with the profiling code compiled in, but now I'm not so sure that's fair. So: pre-props: 1.3 seconds average post-props: 1.4 seconds average or about an 8% loss in speed. I'm not surprised that you'd see a small slowdown with heavy property use, but I'm surprised that you're seeing this in standalone JSBSim. I looked at the current JSBSim code, and there are scarcely any property accesses at all: as far as I can tell, only FGCoefficient::Value and FGCoefficient::TotalValue methods touch the property tree at all in the main loop, though I can imagine that these are relatively heavily used. What property-related methods show up near the top in the profiling? The other possibility is that the new multi-FDM stubs are slowing things down, but that seems unlikely. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim Inlining
The other possibility is that the new multi-FDM stubs are slowing things down, but that seems unlikely. There's very little there that's being used - and nothing being used unless it's defined in the config file as a multi-body sim. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] JSBSim Inlining
On Sat, 2002-03-23 at 06:26, David Megginson wrote: Tony Peden writes: Also, I was able to better quantify the performance change due to incorporating the properties code. Prior to this, I had done speed comparisons with the profiling code compiled in, but now I'm not so sure that's fair. So: pre-props: 1.3 seconds average post-props: 1.4 seconds average or about an 8% loss in speed. I'm not surprised that you'd see a small slowdown with heavy property use, but I'm surprised that you're seeing this in standalone JSBSim. I looked at the current JSBSim code, and there are scarcely any property accesses at all: as far as I can tell, only FGCoefficient::Value and FGCoefficient::TotalValue methods touch the property tree at all in the main loop, though I can imagine that these are relatively heavily used. Very heavily used. I don't know the exact number, but the aero model of the c172 accesses the tree at least 60 times per frame. Jon and I have discussed ways to reduce this demand (its a design feature that pre-dates the property tree) and I think we could achieve 1/3 to 1/2 of that. What property-related methods show up near the top in the profiling? SGPropertyNode::getDoubleValue() This makes perfect sense, because it's called in place of FGState::GetParameter which used to be the big hitter. The other possibility is that the new multi-FDM stubs are slowing things down, but that seems unlikely. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] JSBSim Inlining
Tony Peden writes: What property-related methods show up near the top in the profiling? SGPropertyNode::getDoubleValue() This makes perfect sense, because it's called in place of FGState::GetParameter which used to be the big hitter. I had been thinking about eliminating tying to pointers, but in my own tests, I have had very little luck speeding up tying to object methods, so maybe tying to member variable pointers is a reasonable alternative (it also avoids all the template madness). I can optimize that a bit as well. When you use this approach, instead of node-tie(SGRawValuemethods(this, Foo::getBar, Foo::setBar)); you would do node-tie(SGRawValuePointer(bar)); This works, of course, only if your getters and setters don't massage or clamp the values at all. There are some easy optimizations I can perform to make tied pointers as fast as internal values, if they turn out to be helpful. All the best, DAvid -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
