Crash Detection

[seanmcleod]

Given the number of reports with aircraft hitting the ground very hard and then rebounding with extreme velocities based on massive spring compression in the gear and sometimes ending up with NaNs a while after the massive bounce I took a look at the crash detection logic.

So first off it looks like we need two timesteps with WOW before the crash detection function is called.

jsbsim/src/models/FGLGear.cpp

Lines 416 to 420 in 6e0b852

	// Require both WOW and LastWOW to be true before checking crash conditions
	// to allow the WOW flag to be used in terminating a scripted run.
	if (WOW && lastWOW) CrashDetect();
	lastWOW = WOW;

So my first question is, since when I searched for the word 'crash' in the source code the only references I found were in FGLGear what about crash detection when the gear isn't down? There are reports printed for contact points hitting the ground but does that mean no crash detection in that case?

Now in terms of the actual crash detection function.

jsbsim/src/models/FGLGear.cpp

Lines 554 to 566 in 6e0b852

	// Crash detection logic (really out-of-bounds detection)
	void FGLGear::CrashDetect(void)
	{
	if ( (compressLength > 500.0 ||
	vFn.Magnitude() > 100000000.0 ||
	GetMoments().Magnitude() > 5000000000.0 ||
	SinkRate > 1.4666*30 ) && !fdmex->IntegrationSuspended())
	{
	cout << "*CRASH DETECTED* " << fdmex->GetSimTime() << " seconds: " << name;
	// fdmex->SuspendIntegration();
	}
	}

So fdmex->SuspendIntegration() has been commented out, so the only effect of crash detection is to write a crash comment to the console, the sim continues, potentially outputting NaNs later on etc.

Looking through the history for FGLGear I see the integration suspension was commented out by @jonsberndt in 2014 -
a1360ba

With a commit comment that is a question - "Turned off suspension of integration in landing gear model is this a good thing for everyone?"

Which is what I'm basically querying 😉

My gut feel is it would be better to stop. @jonsberndt, @bcoconni, @agodemar can you remember the advantages/pros for not suspending integration?

[seanmcleod]

what about crash detection when the gear isn't down? There are reports printed for contact points hitting the ground but does that mean no crash detection in that case?

Ah, taking a further look I see that structural contact points are modelled as FGLGear instances with default values for spring constant etc.

jsbsim/src/models/FGLGear.cpp

Lines 87 to 105 in 6e0b852

	name = el->GetAttributeValue("name");
	string sContactType = el->GetAttributeValue("type");
	if (sContactType == "BOGEY") {
	eContactType = ctBOGEY;
	} else if (sContactType == "STRUCTURE") {
	eContactType = ctSTRUCTURE;
	} else {
	// Unknown contact point types will be treated as STRUCTURE.
	eContactType = ctSTRUCTURE;
	}
	// Default values for structural contact points
	if (eContactType == ctSTRUCTURE) {
	kSpring = in.EmptyWeight;
	bDamp = kSpring;
	bDampRebound = kSpring * 10;
	staticFCoeff = 1.0;
	dynamicFCoeff = 1.0;
	}

[bcoconni]

It seems it's raining NaNs these days 😆 : 3 issues reported within a week or so.

I agree we can't leave the current situation unchanged and I was also thinking about how the dreaded crash induced NaNs should be handled. One option should be to restore the integration suspension as you suggest. I am not sure why this was commented out in 2014. Given the detection thresholds (in the millions) I can barely imagine a situation where these thresholds would be reached but one would want to continue the simulation ?

Alternatively, I was considering addressing the issue by comparing the amount of deformation energy (i.e. $\frac{1}{2}k\Delta x^2$ where $\Delta x$ is the compression length and $k$ the stiffness) to the vehicle kinetic energy. The idea would be to cap the compression length to a value such that the vehicle velocity would not change abruptly from the current time step to the next. The drawback would be that during violent ground hits, the vehicle would unrealistically sink into the ground before the gear compression has managed to revert the direction of the vertical velocity. However I'd tend to think that it's better to sink a bit into the ground rather than being propelled into outer space at warp speed ...and getting NaNs.

Disclaimer: regarding this kinetic/deformation energy idea, this is just a vague idea as I have not much investigated the concept. So take it for what it is i.e. some intuition or gut feeling.

[seanmcleod]

Given the detection thresholds (in the millions) I can barely imagine a situation where these thresholds would be reached but one would want to continue the simulation ?

Yep, when I saw those figures I was surprised they were so large. I'm sure there are a lot of extreme bounces that don't even get reported as a crash.

I wonder what FlightGear do, do they have their own crash detection logic? Or do they let aircraft bounce into space?

I was assuming the crash detection code would use some rough maximum vertical speed, maybe say twice the typical maximum landing gear VS that airliners say for example have to be certified to handle at maximum landing weight?

What I'm wondering is whether we should add say another element to FGLGear that allows the FDM developer to specify a maximum rating for the particular gear before it breaks. So the main gear of say an aircraft like the F-18 designed for landing on aircraft carriers could have a much higher rating compared to an airliner and compared to a general aviation aircraft like the C-172.

FDM developers could then also specify a lower rating for the nose wheel gear compared to the main landing gear.

Also FDM developers could specify a much lower rating for structural contact points.

For FDMs that don't include the new element we go with some default for gear and structural contact points.

[bcoconni]

What I'm wondering is whether we should add say another element to FGLGear that allows the FDM developer to specify a maximum rating for the particular gear before it breaks. So the main gear of say an aircraft like the F-18 designed for landing on aircraft carriers could have a much higher rating compared to an airliner and compared to a general aviation aircraft like the C-172.

I think that such a feature could already be coded in XML except maybe for a couple of extra properties that would need to be added for the FDM designer to access, I'm thinking to the local vertical velocity for example.

But even if this feature would be coded in JSBSim, it would still require the FDM designer to set some parameters in their model in order to avoid death by NaNs. So we need to implement a safety net for the (likely ?) case where the model would not be using these features.

That's the reason why I was considering using kinetic energy vs deformation energy because it would be sort of a dimensionless approach whatever the size of the aircraft is. Once all the vehicle kinetic energy is transferred to the gear compression the aircraft has no other option but to stop its movement. And as the gear compression is caped, it cannot accumulate further energy. Then when the gear extends, it transfers its energy back to the aircraft but, as the gear has not stored more than the initial vehicle kinetic energy, the vehicle velocity is not going through the roof.

And as a safety net for the safety net there would still be the method FGLGear::CrashDetect().

[seanmcleod]

But even if this feature would be coded in JSBSim, it would still require the FDM designer to set some parameters in their model in order to avoid death by NaNs.

My suggestion was that if the designer didn't specify the new FGLGear element then JSBSim would assume some default, e.g. say 2,000fpm for say landing gear and say 500fpm for structural contacts.

[dpculp]

There was a time, maybe 15 years ago, when we had some crash detection added to JSBSim, but one of the FlightGear/JSBSim users had a fit because this broke his "crash animation" which he had worked very hard on. As far as I know this was the only reason for not halting integration after crashing. The user was Gerard Robin, a.k.a. "grtux", and I believe he retired from simming soon thereafter. I don't know if any of his crash animation code is still in use. I'll ask at the FlightGear forum.

[dpculp]

I've started a thread at Flightgear forum on this subject. It seems there are several users taking advantage of different types of crash handling.

https://forum.flightgear.org/viewtopic.php?f=49&t=41219

[gallonmate]

I searched through various files/history, Flightgear mailing list & forum, and then actually crash testing various aircraft with JSBSim (with Unreal Engine) with SuspendIntegration being re-enabled in crash detection . Here's some points I found (and thoughts I have). Sorry for the long comment:

SuspendIntegration

Using fdmex->SuspendIntegration() does not exactly halt JSBSim, depending on how JSBSim is being called to run in the first place. In the case of FlightGear (also Uneal plugin), SuspendIntegration (which sets IntergationSuspended true) does not prevent simulation from being called to update again. FlightGear (also Unreal Plugin) simply call JSBSim to run a step and SuspendIntegration doesn't stop another simulation step from being called. In the case of JSBSim running a Script file, SuspendIntegration appears to stop running the script.

• FlightGear Crash Detection:

  FlightGear's calls JSBSim through JSBSim.cxx and looks for a Message
  https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/FDM/JSBSim/JSBSim.cxx

      case FGJSBBase::Message::eText:
              if (msg->text == "Crash Detected: Simulation FREEZE.")
                  crashed = true;

And then stops calling JSBSim if crashed is true.

           void FGJSBsim::update( double dt )
           {
               if(crashed) {
                  if(!fgGetBool("/sim/crashed"))
                      fgSetBool("/sim/crashed", true);          
                 return;
           }

But "Crash Detected: Simulation FREEZE" message is no longer created by JSBSim, it was removed in a commit from 2016, 944647c

So from what I can see, FlightGear continues to run JSBSim and will only stop simulation when a FlightGear user says to stop sim, if aircraft reaches -100 below agl, or if aircraft model has system to tell Flightgear to stop sim. (Does FlightGear handle NaNs internally or just continue?).

JSBSim's Crash detection

JSBSim's Crash Detected heavily depends on each aircraft model (and their coefficients). In general it's not reliable. It sometimes will produce a Crash Detected even when the vehicle's bounce is not too extreme and no NaNs are produced. Other times hard ground hits produce NaNs and there was no Crash Detected.

• JSBSim's Crash detection with FlightGear:

As @dpculp said, Flightgear aircraft authors created various visuals and physical damaged states that produce broken wings or broken gear struts. The c172p, p51d, shuttle, and many others have a damage system where the wings can be broken off. These systems appear to use JSBSim <contact> points to calculate stress/damage. Would altering how contact/gear crash detection currently is, affect their Flightgear damage systems? Flightgear authors/users want to see the vehicle simulation even after the vehicle has been physically damaged/crashed.

Forcing JSBSim to halt simulation will no doubt cause complaints from FlightGear users. Which is sort of ironic because FlightGear currently looks for JSBSim crash detection, but "Crash Detected: Simulation FREEZE." message has not existed for a few years. And fixing that Message would possibly cause complaints 😥

Moving On

If there are any updates to Crash Detection, I'd suggest at the least using a property bool which enables/disables Crash Detection or enables/disables the stopping of sim due to Crash Detected. This way if JSBSim defaults to stop on crash in a future update, FlightGear, or each JSBSim user, can easily disable Crash Detect for their needs.

There's also the possibility of using using more than one Crash Detector. Then users can disable/enable ones that work better for different situations. For example high speed craft might make better use of one algorithm than another.

Besides all of that, Crash Detection seems more like a last chance catch, where something else shouldn't be happening in the first place? Is the issue more due to each Aircraft, how users might initialize some extreme/wrong values, frequency/time steps of the sim, or is there some small issue in the core physics model? I'm not suggesting there is an issue, merely thinking of all reason.

Extra Details

After reading through topics, it's seem that each aircraft model's coefficients have an effect on their stability which then increase or decrease the chance of causing some NaNs. Both in aerodynamic data and contact point data.

787-8 can trigger a Crash Detected with no NaNs, by striking the ground while banking and pitched down, the aircraft bounces but not too extreme and continues flying as normal. This aircraft does produce NaNs occasionally depending on the angle of impact, etc.

F15 I wasn't able to trigger a Crash Detected. It either got stuck in the ground, fly through/below the ground, or bounced semi-realistically. It doesn't seem to produce many or any NaNs with impacts. Edit: I can produce NaNs in a nose dive impact, similar to the c172p.

C172P It's difficult to produce any NaNs with impacts but it was possible. Usually in a Nose Dive Impact w
The c172p in JSBSim is also very bouncy. Then I flew a modified c172p using FlightGear Team's latest c172p, there is almost no bounce. Comparing their coefficients and friction explains why. But FlightGear Team's c172p still can produce NaNs by impact almost nose first into the ground.

Original JSBSim c172p "Left Tip":

            <static_friction> 0.2 </static_friction>
            <dynamic_friction> 0.2 </dynamic_friction>
            <rolling_friction> 0.2 </rolling_friction>
            <spring_coeff unit="LBS/FT"> 20000 </spring_coeff>
            <damping_coeff unit="LBS/FT/SEC"> 2000 </damping_coeff>

FlightGear Team's c172p "Left Tip"":

            <static_friction> 0.75 </static_friction>
            <dynamic_friction> 0.5 </dynamic_friction>
            <spring_coeff unit="LBS/FT">       1830.15 </spring_coeff>
            <damping_coeff unit="LBS/FT/SEC">   366.03 </damping_coeff>

If we can reliable crash/impact a model into the ground that causes NaNs nearly every time, maybe that would help find a root cause & solution. I think with the c172p it might provide reliable crashes with NaNs due to hitting the ground at a certain/angle speed in a nose dive. Edit: Yes I can repeatedly crash the c172p, in the same manner, reliably causing NaNs, and Crash Detected is not always triggered. I wonder if half of the words in my comment were pointless. 😅. I'll maybe investigate later and share if I find anything interesting.

[seanmcleod]

Sorry for the long comment:

No need to apologize. I definitely prefer these sorts of comments compared to comments that are trying to explain an issue the user is having with so, so, so little information you have to be a mind reader to try and figure out the issue they're having 😉

But "Crash Detected: Simulation FREEZE" message is no longer created by JSBSim....

Yep, doesn't seem like a very robust communication mechanism relying on some specific string output to the console. Suggest we create a new property in JSBSim that we set which then FlightGear and FDM users can use to trigger whatever they want to do when a crash is detected in JSBSim.

In addition to a property that is set when a crash is detected we can have another property that controls what JSBSim does when a crash is detected, e.g. does it suspend integration or not etc.

Crash Detected is not always triggered.

Take a look at the crash detection code I posted a link to originally. Note how extreme most of the checks are, hence the reason you sometimes don't get a crash detection for an impact that obviously in the real world would be a crash with no bouncing.

jsbsim/src/models/FGLGear.cpp

Lines 554 to 566 in 6e0b852

	// Crash detection logic (really out-of-bounds detection)
	void FGLGear::CrashDetect(void)
	{
	if ( (compressLength > 500.0 ||
	vFn.Magnitude() > 100000000.0 ||
	GetMoments().Magnitude() > 5000000000.0 ||
	SinkRate > 1.4666*30 ) && !fdmex->IntegrationSuspended())
	{
	cout << "*CRASH DETECTED* " << fdmex->GetSimTime() << " seconds: " << name;
	// fdmex->SuspendIntegration();
	}
	}

Hence the reason I suggested we change the crash detection logic. I suggested one approach, @bcoconni suggested a different approach.

Someone on the FlightGear forum posted the following with regards to my suggestion of using some descent velocity to decide whether the gear would be broken and use that as a crash detection.

With reference to FAR § 25.473 ( https://www.ecfr.gov/current/title-14/c ... ion-25.473) 10fps seems to be usable default value (maybe 11fps to add a slim margin).
Landing gear systems are being designed according to Regulations, so this is a valid approach for the majority of cases.

With multiple failure modes and also special type of aircraft it is of course beneficial to be able change this on FDM-side.
Just as a suggestion.

edit: safety factor 1.5 is certainly to be considered as well. 15fps as a suggestion, could be further refined by more research.

[gallonmate]

Hence the reason I suggested we change the crash detection logic. I suggested one approach, @bcoconni suggested a different approach.

Deformation Energy

Re-reading @bcoconni idea with deformation energy, his comment copied below, I think he means checking gear forces before applying to vehicle and before crash detection. Basically improving the spring/compression forces. Is that correct @bcoconni? #819 (reply in thread)

Then when the gear extends, it transfers its energy back to the aircraft but, as the gear has not stored more than the initial vehicle kinetic energy, the vehicle velocity is not going through the roof.

And as a safety net for the safety net there would still be the method FGLGear::CrashDetect().

This should help prevent extreme bounces and violent spin reactions from happening in the first place, right?

Descent Velocity

Using descent velocity would cover situations involving medium speed impacts and up to the highest-speeds of descent impact. But will likely miss low descent speed situations. For example a vehicle with high forward speed while in a low banking turn, the wing tip touches the ground, the aircraft enters a tumbling spin possibly producing NaNs, but it never reaches a high enough descent speed on impact to trigger a detection. If a lower threshold is used to catch low speed impacts, this would limit the usage of JSBSim in a default setup. Unless multiple thresholds/stages are used. Example - Low threshold is just notification that a gear/crash has occurred. High threshold actually stops sim to prevent NaNs.

Using Both

I think both Deformation Energy and Descent Velocity should be used inside the crash detector. To provide users a straightforward way to be notified of probable crashes. As well as allowing a simple framework for users to create their own simple damage states, ie actually broken gear, or broken wing.

Talking about this all now, I wonder if Crash Detection should also catch extreme destabilization which produce NaNs. As seen in this recent issue #818, the vehicle immediately enters an impossible spin with just aileron input. Which then produces NaNs soon after reaching extremely high rotational rates. What if some simple check is performed looking for impossible g-forces. Or just check all local frame axes for some extreme rotational speed, and which then trigger a "Crash Detected". But Crash Detection is in FGLGear, so maybe a new class is needed?

Summary and Suggestion:

Improve the spring/compression forces applied to the vehicle with a limit of Deformation Energy, this would be done before Crash Detection. Then improve Crash Detection to be based on three things, Descent Velocity, Extreme Destabilization, and Deformation Energy(but now use location or acceleration changes as energy). Maybe even moving Crash Detection to it's own class, since Extreme Destabilization can be useful for the the entire simulation, without needing ground/weight on wheel checks.

There could also be two levels of threshold or stages for the detections. A low generic value which triggers a property and updates the log, notifying user that some damage/vehicle impact has occurred. And then much higher extreme threshold which only triggers at impossible values before reaching NaNs, which then pause simulation & notify user. "Vehicle impacted ground with xxx velocity". Or "Vehicle destabilized producing 1000 G's". Or "Vehicle reached 12 trillion rotations per minute."

@seanmcleod suggested two properties, which seems great:

Suggest we create a new property in JSBSim that we set which then FlightGear and FDM users can use to trigger whatever they want to do when a crash is detected in JSBSim.

In addition to a property that is set when a crash is detected we can have another property that controls what JSBSim does when a crash is detected, e.g. does it suspend integration or not etc.

If multiple detection systems are agreed and added, having properties to enable/disable them individually would be also ideal.

[seanmcleod]

While looking into something else I came across this diagram. The red boundary line is the structural design envelope for the F/A-18E/F aircraft.

[seanmcleod]

Some more background info on landing gear strength for commercial airliners.

https://www.boeing.com/commercial/aeromagazine/articles/qtr_3_07/article_03_3.html

FAR criteria require that landing gear design be based on:

• A sink rate of 10 feet per second at the maximum design landing weight; and
• A sink rate of 6 feet per second at the maximum design takeoff weight.
  ..

Typical sink rates at touchdown are on the order of 2 to 3 feet per second, and even a “hard” landing rarely exceeds 6 feet per second. Additionally, the landing loads are based on the worst possible landing attitudes resulting in high loading on individual gear. The 747-400 provides an excellent example. The 747-400 body gear, which are the most aft main gear, are designed to a 12-degree nose-up body attitude condition. In essence, the body gear can absorb the entire landing load.