Aircraft file with fatal error

[muell869]

I'm with the University of Minnesota's UAV Research Lab. I'm modifying Flight Gear's Rascal model to fly with altered properties derived from an OpenVSP simulation. When running JSBSim, it looks like everything goes well until we reach the aerodynamics section of the aircraft xml file, showing "FATAL ERROR: JSBSim terminated with an unknown exception." I'm fairly sure there's something I'm missing while creating the tables, because it will parse when I replace the tables with the value of 1.

As a side note, the breakpoints used in the aerodynamic tables are velocities in meters per second. Is there a way to use those units in JSB, or must I adjust before creating the aircraft file?

Any help is appreciated!

Best,

Louis Mueller

RascalModel.zip

[seanmcleod]

@muell869 what was the issue? I presume you found and fixed some issue in your input data given that you closed the issue?

[muell869]

Hi Sean, I closed it because I wasn't sure if this was an appropriate place to post a user issue. I haven't made much headway!

[seanmcleod]

I would say this is an appropriate forum. There is a possibility that there is a bug in JSBSim in parsing your FDM, or at a minimum even if you have made a mistake in your FDM ideally JSBSim should spit out a meaningful error message rather than just crashing.

[muell869]

Sure, thank you. Attached is the working rascal config file. The unknown exception is displayed when using the file previously attached.

What is more confusing to me is that the original rascal model will run with the new aerodynamics definitions inserted into its config file, so it seems that something else is throwing JSBSim off in the new file. I also noticed that the new metrics, mass prop, etc make the old model completely unusable in FlightGear when swapped, even though the dimensions are not very different.

OriginalRascal.xml.zip

[seanmcleod]

@muell869 do you not see any error message printed to the console before the fatal exception?

I unzipped your RascalModel.zip and tried using it as follows:

C:\source\jsbsim>.\Debug\JSBSim.exe --aircraft=Rascal110-JSBSim --initfile=reset00.xml

The first error I came across was:

In file aircraft/Rascal110-JSBSim/Rascal110-JSBSim.xml: line 101
Could not open file: 18x8
FATAL ERROR: JSBSim terminated with an unknown exception.

What seems to be happening here is that JSBSim is happy to load your engine model from the same directory as the FDM but it can't seem to find the thruster file 18x8.xml in the same directory. So I copied the thruster file to my JSBSim's engine directory and now I get further.

    Loading Component "guidance/angle-to-heading-rad" of type: ANGLE
No filename given.

In file aircraft/Rascal110-JSBSim/Rascal110-JSBSim.xml: line 126
Could not open file: RascalAP

Aircraft autopilot element has problems in file Path "aircraft/Rascal110-JSBSim/Rascal110-JSBSim.xml"
  JSBSim could not be started

Since you haven't included the RascalAP file in the zip file.

Can you include the full package of files? I'll then continue testing.

[seanmcleod]

Quickly commenting out the autopilot I then get the following:

    Function: aero/coefficient/CMn/Elevator
FGPropertyManager::GetNode() No node found for metrics/qbar-area
FATAL ERROR: JSBSim terminated with an exception.
The message was: FGPropertyValue::GetValue() The property metrics/qbar-area does not exist.

Why do you think metrics/qbar-area exists?

And taking a quick look at the original Rascal FDM you attached it doesn't attempt to use a property called metrics/qbar-area.

Original Rascal:
<property>aero/qbar-psf</property>
<property>metrics/Sw-sqft</property>

Versus:
<property>metrics/qbar-area</property>

Are you not seeing these error messages from JSBSim?

[bcoconni]

@muell869
By the way, which version of JSBSim are you using ?
Have you checked your model with the last executable from our releases ?

[muell869]

I'm sorry, I sent you an older config file. I did get an error for the unknown property and changed it to
aero/qbar-area. Here is the aircraft folder I've modified. Engine and thruster models were moved to the correct places in JSBSim. I'm trying to use the output.xml script and RascalAP, but have since tried simply flying the modified aircraft in FlightGear. FlightGear logs show aero does not exist, and running through JSBSim standalone still shows the unknown exception.

I am using the current version of JSBSim in Debian 9.

I really appreciate your help!

Rascal.zip

[seanmcleod]

Okay using your updated files I see the following now. I don't see any issue loading the FDM, I'm using the following to run it in stand-alone JSBSim:

C:\source\jsbsim>.\Debug\JSBSim.exe --aircraft=Rascal110-JSBSim --initfile=reset00.xml

The FDM loads fine and the simulation starts executing, by the look of it your reset00.xml drops this small model from a height of 5ft, so JSBSim outputs ground contacts, it looks like it bounces into the air and ground contacts are reported again, and then JSBSim quits with a floating point exception, floating point overflow.

---- JSBSim Execution beginning ... ----------------

Start: Friday July 06 2018 22:30:37 (HH:MM:SS)
0: GEAR_CONTACT: 0.5 seconds: RIGHT_MLG 1
1: GEAR_CONTACT: 0.691667 seconds: RIGHT_MLG 0
2: GEAR_CONTACT: 0.725 seconds: RIGHT_MLG 1
3: GEAR_CONTACT: 0.75 seconds: LEFT_MLG 1
4: GEAR_CONTACT: 0.8 seconds: TAIL_LG 1
5: GEAR_CONTACT: 1.2 seconds: LEFT_MLG 0
6: GEAR_CONTACT: 1.2 seconds: RIGHT_MLG 0
7: GEAR_CONTACT: 1.2 seconds: TAIL_LG 0
8: GEAR_CONTACT: 1.20833 seconds: LEFT_MLG 1
9: GEAR_CONTACT: 1.20833 seconds: RIGHT_MLG 1
10: GEAR_CONTACT: 1.20833 seconds: TAIL_LG 1
11: GEAR_CONTACT: 1.21667 seconds: LEFT_MLG 0
12: GEAR_CONTACT: 1.21667 seconds: RIGHT_MLG 0
13: GEAR_CONTACT: 1.225 seconds: TAIL_LG 0

Floating point exception happens in:

void FGQuaternion::ComputeDerivedUnconditional(void) const
{
…
  // Now compute the transformation matrix.
  double q0q0 = q0*q0;

q0 = 4.4958790873390375e+178

Which is being called from:

bool FGPropagate::Run(bool Holding)
{
...
  VState.qAttitudeLocal = Tl2b.GetQuaternion();

Has anything been changed in terms of the gear properties compared to the standard Rascal model?

[muell869]

There have been no changes made to the ground reactions, but I've been told that they are touchy for this particular model. The rosemount.xml file should start the aircraft in the air.

Using the Rascal model and JSBSim --aircraft=Rascal --initfile=rosemount.xml --realtime --logdirectivefile=data_output/flightgear.xml, I get a relatively successful flight where everything parses and works in FlightGear and JSBSim. Using the attached file and JSBSim --aircraft=US120 --initfile=rosemount.xml --realtime --logdirectivefile=data_output/flightgear.xml, however, only gets this far.

---- JSBSim Execution beginning ... --------------------------------------------

Start: Tuesday July 10 2018 10:45:09 (HH:MM:SS)
Simulation elapsed time: 0.008333
Floating point exception

What am I missing that changes the behavior of the model? US120.xml and US120AP.xml should be the same files as Rascal110-JSBSim.xml and RascalAP.xml but with different names.

Just swapping the Rascal110-JSBSim.xml file in FlightGear continues to crash before starting and giving the aero does not exist error.

Thank you for your help!

US120.zip

[seanmcleod]

@muell869 please include a full/self-contained zip file. I had a clean setup of JSBSim and after unzipping US120.zip I was missing things like your 18x8.xml propeller etc. So please include an Engines sub-directory so that anyone taking a look doesn't have to dig through older zip files you've posted to put a working version together.

So running your US120 model using initfile=rosemount.xml I see JSBSim hitting the same floating point exception in the same code location as I described just above. It hits this exception after 34 simulation time steps, i.e. after only 0.28s.

Glancing at some of the other state I see massive numbers for the rotational velocities, e.g.

VState.vPQRi
{data=0x000000000052a6f0 {-5.2934079557424215e+195, 8.4219972102204590e+195, 7.2765853578321047e+195} }

Which I'm guessing is what then leads to the floating point exception.

You initialize the model with a velocity of 150ft/s but the aircraft isn't trimmed, and so I'm guessing that the model very quickly starts spinning like mad. So I would guess there is an issue in your aero data etc.

Have you done a diff to confirm that there really isn't any difference between US120 and Rascal?

[seanmcleod]

@muell869 in order to debug your model I'd suggest logging the forces and moments at 120Hz (i.e. every simulation frame), of which there are only 34 before JSBSim crashes.

Then take a look and see if there is a specific force or moment that appears to be a couple of orders of magnitude off which is causing this extreme spin. This will then help you narrow down which part of your FDM to inspect to spot the error.

[WillemEerland]

Regarding the "bouncy" behaviour, I managed to get a ground trim by replacing

<damping_coeff unit="LBS/FT/SEC"> 100 </damping_coeff>
with

<damping_coeff unit="LBS/FT/SEC"> 10 </damping_coeff>

Goodluck!

[muell869]

Thank you for all of your help. After quite a few revisions I have been able to make a somewhat functioning model. It flies about how I would expect in Flight Gear, but with any aggressive maneuvers there is a floating point exception. Could this have to do with the breakpoints in the aerodynamic lookup tables being too narrow? My understanding is that aerodynamic data will remain static once the aircraft exceeds the table bounds, but it doesn't make sense to me why that would break the simulation.

US120Model.zip

[seanmcleod]

@muell869 previously when I glanced at the floating point exception for your earlier model it was due to the rotational rates reaching angular rates on the order of 1e+195 rad/sec, implying that one or more of the forces or moments must've have been off by a couple of orders of magnitude in order to generate those sorts of angular rates.

I'd guess there is a moment coefficient like Cmq which possibly generates a moment off by a couple of orders of magnitude once the pitch rate isn't close to 0, i.e. which is why you only see it with aggressive maneuvers.

So I'd suggest logging your forces and moments and then script in say a large elevator step change and see which force(s)/moment(s) increase dramatically. If they don't then try large step changes to the rudder, ailerons etc.

You'll then be able to zero in on the particular forces/moments causing the issue.

[bcoconni]

@muell869
Has your problem been fixed ? Can this issue be closed ?

[muell869]

Yes, apologies for the confusion.

[kvnjonathan70]

hi, i am facing an extreme spin issue, which is getting me sick
i have made the aerodynamic file from CFD produced coefficients, CFD output is showing a stable aircraft. I have taken the same reference point (nose tip) as CFD and same reference area and length for forces and moment calculation. when i first tried 'do simple trim' its failed. when i initialize an aircraft it tends to oscillate (pitch up n down) at any velocity.

real model is ready, i do not wish to change it CG location and even if i do change the CG locations it still oscillates from small amplitude to large and then starts spinning. i have check the sign convention, its in body axis, where lift is positive and pitch coefficients are negative. from where is the couple generating ?

[seanmcleod]

@kvnjonathan70 I'd suggest creating a new issue, rather than adding to this closed issue with a very vague title as well.

[kvnjonathan70]

sure sir