Extreme axcelerations during engine start up.

[hvengel]

I have had this issue for a long time but it is very intermittent. Sometime when I am starting the engine of the P-51D there are forces generated that are so high that the aircraft will instantaneously accelerate to very high speeds going backwards. The sim will halt when this happens and in the past once it started doing this the only way to get things back to normal was to restart my computer, I have never been able to trace the source of these very high forces. To give an idea how strong these forces are here are some values from the property browser after this has happened:

fdm/jsbsim/accelerations/a-pilot-x-ft_sec2 -5.688e +14
fdm/jsbsim/accelerations/a-pilot-y-ft_sec2 -7173506.175
fdm/jsbsim/accelerations/a-pilot-z-ft_sec2 5.79e +15
fdm/jsbsim/accelerations/n-pilot-x-norm -1.769e +13
fdm/jsbsim/accelerations/n-pilot-y-norm -223149.72
fdm/jsbsim/accelerations/n-pilot-z-norm 1.8e +14

As you can see the forces are huge. Also note that the force along the x axis is toward the rear of the aircraft.

I think this may have something to do with the engine so I recorded some interesting numbers related to the power plant:

fdm/jsbsim/propulsion/pt-lbs_sqft 7.95e +43
fdm/jsbsim/propulsion/tat-c 1.14e +14
fdm/jsbsim/propulsion/tat-r 2.06e +14

I am sure what is causing this but I am hoping that someone here has some ideas about where to look for the source of the forces that are causing this.

When this happens it does this right when the starter is engaged.

[daveculp]

I've not seen this using my models, which use vanilla engine and prop configuration plus an auto mixture system. My hunch is it is coming from a system you've written as part of your power plant setup. Are able to remove them one at a time to find the bug?

[hvengel]

It was worth a try although I think I did this once before. In any case I removed all of my custom engine code and it is still doing this. In addition inspecting the custom properties every thing looks OK. But I suspect that when this is happening that a spurious value is somehow output but for only a very short time (perhaps only one FDM cycle).

It is acting like there is a division where the denominator is very close to 0 which would result in a very large output. So I added <Clampto> sections to my custom engine related code so that none of these functions would ever output anything real close to 0. It seemed to work but the problem is very intermittent (I can go for months and not see it although it has happened the last two days) so I am not certain that the issue is really fixed. Will have to keep an eye on it.

[Necolatis]

I know it is unrelated to this discussion, but I just downloaded the p51 from SVN, and got this (FG 3.3 nightly):

Code: Select all

FGPropertyManager::GetNode() No node found for propulsion/engine/enclosure-attenuation-level

In file C:/Users/Nikolai/Documents/FlightGear/Aircraft/p51d/p51d-jsbsim.xml: line 579
 Read model 'autopilot' while expecting model 'system'

Aircraft system element has problems in file C:/Users/Nikolai/Documents/FlightGear/Aircraft/p51d/p51d-jsbsim.xml
Unknown exception in the main loop. Aborting...

Not sure if I have done something wrong? Or is it not currently in a flying condition?

[Bomber]

Is it always on your first flight of the plane.. Or could you already have flown without issue and then respawned.... Could the problem be with how your previous flight ended?

[hvengel]

I have not tested with 3.3 yet (was planning to do this in the next few days) but it is working with 3.2 and is in perhaps the best flying condition ever.

Line 579 loads the auto throttle functionality <system file="autothrottle"/> (this system tries to maintain manifold pressure when the altitude changes). This uses the JSBSim autopilot/PID functionality and it appears that 3.3 has major issues with this (It throws which is always a bad thing). I use the JSBSim autopilot/PID functionality for two different systems currently - autothrottle and autocooling. So I suspect that commenting out line 579 would result in the same error on the next line in the <system... section.

From the JSBSim manual:

An aircraft system is specified as a string of components within the <channel> element of a <system>, <autopilot>, or <flight_control> specification in the aircraft configuration file

So an autopilot specification section is clearly a valid JSBSim construct.

Most likely this is a bug in the 3.3 JSBSim support as FG should support all standard JSBSim constructs. The autopilot JSBSim functionality has been there for a long time although it probably is not used by many aircraft (likely only more advanced ones). I did a quick grep of the full FGADDONS directory and it looks like there are three aircraft that use the JSBSim autopilot stuff - extra500, tu154b and the P-51D. All very advanced models. This should be reported in the bug tracker so it gets fixed before release. Could you report this and post the bug number back here so I can follow it please?

[hvengel]

bomber,

It happens in a random way. Sometimes the first time it is run and sometimes after running FG with the P-51D a number of times. It can also stop happening at random and is very intermittent. This makes fixing it very difficult since debugging is nearly impossible (IE. did it stop happening because of a change I made or is it random?).

I suspect that one of my custom engine functions may have been outputting a random value that is very close to 0 right as the starter is engaged. This may be happening for a single FDM cycle when the engine functions are first invoked at engine start up. This near 0 value probably is propagated through the piston engine code and as a result I get a very large value someplace (think 1/0.00000000000000000000000000000001 only with perhaps 15 or 20 or more zeros) and this results in a huge force someplace in the system. If this theory is correct then the <Clipto> sections I added to my code should fix it since these functions will never output anything that approaches 0 or that approaches infinity. So at this point the lowest absolute value that any of these functions can output is 0.01. Only time will tell if this "fix" actually worked.

[Necolatis]

This should be reported in the bug tracker so it gets fixed before release.

https://code.google.com/p/flightgear-bu ... il?id=1616

[AndersG]

An aircraft system is specified as a string of components within the <channel> element of a <system>, <autopilot>, or <flight_control> specification in the aircraft configuration file

So an autopilot specification section is clearly a valid JSBSim construct.

Most likely this is a bug in the 3.3 JSBSim support as FG should support all standard JSBSim constructs.

I think it is a bug or unintended consequence of some JSBSim code cleanup which I seem to recall happened during the year. However, if you load an <autopilot> element from a <system>-tag I'd say it is not super clear that that is a desired behaviour even if did work before.

The bug report would probably do more good on the JSBSim-devel list than in the FlightGear bug tracker, in any case.

/Anders

[hvengel]

The tu154b uses a JABSim autopilot and looking at it the syntax used to load the autopilot is different than what I used. My code for this dates back to the FG 2.4 time frame. I have changed the P-51D to use the same syntax and this has been checked into FGADDONS. It works with FG 3.2.

Necolatis - could you update your local copy of FGADDONS and retest the P-51D? If it is OK I will close the ticket you opened about this issue.

[Necolatis]

Yes, it finished loading with only this:

Code: Select all

FGPropertyManager::GetNode() No node found for propulsion/engine/enclosure-atten
uation-level
Failed to tie property fcs/sine-wave-generator to object methods
Failed to tie property fcs/elevator-control to object methods

[hvengel]

Thank you.

[hvengel]

Back to the original subject of this thread. The problem is actually worse in FG 3.3 and commenting out of of my custom engine related XML and Nasal does not affect the issue. Looking at the JSBSim piston engine I see that there is a debug function that can turn on more messages to the console. How can I change the debug level for the piston engine code so that it provides me with more information? Specifically I would like to set it to

16: When set various parameters are sanity checked and a message is printed out when they go out of bounds

Anyone know how to do this?

[AndersG]

There doesn't seem to be a command line option for setting the debug level even in JSBSim/standalone - so I don't know - you might have to set it in the source and recompile.

Have you tried --enable-fpe with FlightGear? It should hopefully trigger on the first NaN which might give a hint of where things go bad.

/Anders

[hvengel]

With --enable-fpe it crashes while starting up with nothing in the log or on the console to indicate why.

I just did a debug level log and found this near the end of the log:

flight:4:..\..\..\source\src\FDM\groundcache.cxx:335:prepare_ground_cache(): scenery_available returns false at lon = 1.#QNANdeg, lat = 1.#QNANdeg, elev = 1.#QNANm [ 1.#QNAN, 1.#QNAN, 1.#QNAN ] 10
flight:4:..\..\..\source\src\FDM\groundcache.cxx:335:prepare_ground_cache(): scenery_available returns false at lon = 1.#QNANdeg, lat = 1.#QNANdeg, elev = 1.#QNANm [ 1.#QNAN, 1.#QNAN, 1.#QNAN ] 10
nasal:5:..\..\..\source\src\Scripting\NasalSys.cxx:360:Nasal getprop: property /accelerations[0]/pilot[0]/z-accel-fps_sec[0] is NaN
nasal:5:..\..\..\source\src\Scripting\nasal-props.cxx:266:Nasal getValue: property /position[0]/altitude-ft[0] is NaN

The last two lines are apparently related to this but doing some greps on the FGDATA Nasal directory and property /position[0]/altitude-ft[0] is really only used in dynamic_view.nas and redout.nas. Only in redout.nas is it doing a getprop() call. So I disabled blackout/redout support and after that change I found the following in the log file:

flight:3:..\..\..\..\source\src\FDM\JSBSim\JSBSim.cxx:537:17: Crash Detected: Simulation FREEZE.
flight:3:..\..\..\..\source\src\FDM\JSBSim\JSBSim.cxx:537:18: Crash Detected: Simulation FREEZE.
nasal:5:..\..\..\source\src\Scripting\NasalSys.cxx:1093:Nasal runtime error: floating point error in math.exp()
nasal:5:..\..\..\source\src\Scripting\NasalSys.cxx:1099: at C:/Users/Public2/fgdata/Nasal/dynamic_view.nas, line 299
nasal:5:..\..\..\source\src\Scripting\NasalSys.cxx:1103: called from: C:/Users/Public2/fgdata/Nasal/dynamic_view.nas, line 212
nasal:5:..\..\..\source\src\Scripting\NasalSys.cxx:1103: called from: C:/Users/Public2/fgdata/Nasal/dynamic_view.nas, line 334
nasal:5:..\..\..\source\src\Scripting\NasalSys.cxx:1103: called from: C:/Users/Public2/fgdata/Nasal/dynamic_view.nas, line 336
input:3:..\..\..\source\src\Main\fg_commands.cxx:195:Program exit requested.

After turning off dynamic view the log had the following:

flight:3:..\..\..\..\source\src\FDM\JSBSim\JSBSim.cxx:537:17: Crash Detected: Simulation FREEZE.
flight:3:..\..\..\..\source\src\FDM\JSBSim\JSBSim.cxx:537:18: Crash Detected: Simulation FREEZE.
flight:3:..\..\..\..\source\src\FDM\JSBSim\JSBSim.cxx:537:19: Crash Detected: Simulation FREEZE.

Looking at the JSBSim code on-line JSBSim\JSBSim.cxx:537:18 is a SG_LOG() call in the main FDM loop but it sets "crashed = true" just before this call. I tried doing a bulk log to see if I could capture more info about the crash but when it crashes it seems to lose most of the log content (probably because the file was not properly closed).

Now it stopped having the issue. So I don't have any way to do any debugging at this point and I don't know when it will be back again.