You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
support request => Please do not submit support request here, see note at the top of this template.
Describe the issue
I've been debugging a crash in an Unreal Engine project and found the cause to stem from the FGTrim::DoTrim routine (although maybe it also stems from improper initial conditions? I'm not entirely sure).
What is the current behavior?
When executing a ground trim, if the initial altitude above ground level is 0, the trim routine will succeed but set the altitude axis control value to NaN. This also happens whenever the control value min = control value max for any axis. This happens due to the following code in FGTrim::solve:
When x1 = x3, as it does in the case of a ground trim at 0 altitude (according to line 216), d0 will be 0 and x2 will be NaN, which causes everything else to be NaN, and the trim succeeds with NaN altitude (which causes a crash in Unreal Engine).
What is the expected behavior?
I believe the solve method should check if d0 is 0 and if so, set x1 as the control value, see if the axis is within tolerance, and return accordingly, since the potential solution space is narrowed to just that one value. Something like the following placed at line 558:
What is the motivation / use case for changing the behavior?
It's misleading for the trim routine to succeed and yet return NaN values which can potentially lead to crashes, so I believe this special case should be dealt with by the trim routine.
Hmm, I haven't looked at the trim code in detail yet, but whenever I see an AGL of 0 the immediate issue that comes to mind which comes up fairly frequently is that means the gear and it's spring are massively compressed, since the AGL is relative to the CG and not the bottom of the gear.
This sort of massive compression of the gear spring with it's spring coefficient often means you get a massive rebound of the aircraft, sometimes to such an extent that you end up with NaNs.
Now I'm not sure whether in this case, i.e. ground trim in particular that the ground trim code is handling this issue specifically or not.
I'm submitting a ...
Describe the issue
I've been debugging a crash in an Unreal Engine project and found the cause to stem from the FGTrim::DoTrim routine (although maybe it also stems from improper initial conditions? I'm not entirely sure).
What is the current behavior?
When executing a ground trim, if the initial altitude above ground level is 0, the trim routine will succeed but set the altitude axis control value to NaN. This also happens whenever the control value min = control value max for any axis. This happens due to the following code in FGTrim::solve:
jsbsim/src/initialization/FGTrim.cpp
Lines 558 to 567 in 6c1abbe
When x1 = x3, as it does in the case of a ground trim at 0 altitude (according to line 216), d0 will be 0 and x2 will be NaN, which causes everything else to be NaN, and the trim succeeds with NaN altitude (which causes a crash in Unreal Engine).
What is the expected behavior?
I believe the solve method should check if d0 is 0 and if so, set x1 as the control value, see if the axis is within tolerance, and return accordingly, since the potential solution space is narrowed to just that one value. Something like the following placed at line 558:
What is the motivation / use case for changing the behavior?
It's misleading for the trim routine to succeed and yet return NaN values which can potentially lead to crashes, so I believe this special case should be dealt with by the trim routine.
Please tell us about your environment:
Other information
I'm new to JSBSim so apologies if my terminology is incorrect or if I've made some other mistake.
The text was updated successfully, but these errors were encountered: