Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong calculation of vPQRdot in FGAccelerations class #1034

Closed
1 of 3 tasks
mathieuflament opened this issue Feb 5, 2024 · 4 comments
Closed
1 of 3 tasks

Wrong calculation of vPQRdot in FGAccelerations class #1034

mathieuflament opened this issue Feb 5, 2024 · 4 comments
Labels

Comments

@mathieuflament
Copy link
Contributor


I'm submitting a ...

  • bug report
  • feature request
  • support request

Describe the issue

As far as we understand, the vector vPQRdot in FGAccelerations class is the derivative of the angular velocity of the body w.r.t the ECEF frame, expressed in body frame coordinates, and the vector vPQRidot is the derivative of the angular velocity of the body w.r.t the ECI frame, also expressed in body frame coordinates.
In method FGAccelerations::CalculatePQRdot, the variable vPQRdot is derived from vPQRidot using the expression :

vPQRdot = vPQRidot - in.vPQRi * (in.Ti2b * in.vOmegaPlanet);

It should be vPQRdot = vPQRidot + in.vPQRi * (in.Ti2b * in.vOmegaPlanet) instead.

Proof :

2022-04-09_122409

The correct expression is the last equation above, expressed in body frame coordinates.

What is the current behavior?
To highlight the problem, we have slightly modified the orbit check-case, with an initial angular rate w.r.t the ECI frame of vPQRi=[15deg/s, 0., 0.]. The body is a spinning ball around its X-axis (pointing to the East), orbiting the Earth in the equatorial plane. In this scenario, the body X-axis and the angular velocity vector are constant in the ECI frame, i.e. vPQRidot is null. The angular velocity vector w.r.t ECEF frame, namely vPQR, is then simply equal to the Earth sidereal rate vector projected on the (rotating) Y-Z plane of the body frame.

The following graph shows the Q and R components of the vPQR vector, and vPQRdot vector, straight from the BallOut.csv output file produced by the JSBSim program :
BallOut_orig

The sign error on vPQRdot is obvious.

Fortunately, as the equation of motion are integrated in the ECI frame using vPQRidot in FGPropagate class, this error has a limited effect on trajectory computations:

  • the calculation of vPQRidot is OK,
  • the calculation of vPQRi by integrating vPQRidot is OK,
  • the calculation of vPQR from vPQRi is OK,
  • the attitude computations are OK.

Only the outputs and further computations based on vPQRdot are affected by a (small) error.

What is the expected behavior?

Once the sign error on the term in.vPQRi * (in.Ti2b * in.vOmegaPlanet) is corrected in FGAccelerations::CalculatePQRdot (l.158 and l.162) and FGAccelerations::SetHoldDown (l.214), consistent results are restored, as shown by the following figure:
BallOut_corrected

All the other output variables in the BallOut.csv file have remained exactly the same, confirming that a change in vPQRdot values has no adverse side-effect on the simulation loop.

Please tell us about your environment:

  • OS : Linux Debian 12
  • JSBSim 1.2.0
  • Language C++

Other information
We would like to thank the JSBSim developer team for their invaluable contribution to the flight dynamics simulation community.

@jonsberndt
Copy link
Contributor

Hi, Mathieu,

Thanks for this detailed report. JSBSim is where it is today in part due to continuous feedback from the larger community.

This issue got my attention - it's a very interesting issue. I was initially surprised to read of it partially due to the fact that JSBSim has been involved in comparisons against a number of other high-fidelity simulations and fared very well. But, as you pointed out, "this error has a limited effect on trajectory computations" so that could be why it has gone unnoticed if it is indeed an error.

I'll take a closer look at this myself (this one is going to need some quiet time and a few cups of coffee ;-), and I'm sure that Bertrand and Sean and others may also take a close look. I just wanted to post a note of appreciation for the thoughtful report.

@bcoconni
Copy link
Member

bcoconni commented Feb 6, 2024

Indeed, thank you for the excellent bug report @mathieuflament 👍 Clear and thorough.

I agree with your analysis, and while investigating the code history, I discovered that the error was introduced almost 13 years ago by myself via commit fdf7cf7. However as you mentioned the side effects are very limited as vPQRdot is used in just a few places, namely:

outstream << (radtodeg*Accelerations->GetPQRdot()).Dump(delimeter) << delimeter;

which writes the value of vPQRdot to a CSV file.

FGColumnVector3 moment = MassBalance->GetJ() * Accelerations->GetPQRdot()

where vPQRdot is used to determine the position at which the aircraft will sit on the ground at the simulation start.

FGColumnVector3 wdot = vPQRdot;
if (dt > 0.) // Zeroes out the relative movement between the aircraft and the ground
wdot += (in.vPQR - in.Tec2b * in.TerrainAngularVel) / dt;

where vPQRdot is used to compute the friction forces between the landing gears and the ground. Most likely the sign error has a small effect on this computation as the norm of in.vOmegaPlanet is very small (≈7.3e-5 rad/s).

This is most likely why the error remained unnoticed for such a long time. Anyway the bug must be fixed so you could perhaps submit a pull request (referencing this issue) to fix it ?

Thanks.

@bcoconni bcoconni added the bug label Feb 6, 2024
bcoconni added a commit to bcoconni/jsbsim that referenced this issue Feb 10, 2024
bcoconni pushed a commit to mathieuflament/jsbsim that referenced this issue Feb 10, 2024
bcoconni pushed a commit to mathieuflament/jsbsim that referenced this issue Feb 10, 2024
@bcoconni
Copy link
Member

The PR #1036 that fixes the bug reported in this issue has been merged in master. I guess that this issue can now be closed ?

@bcoconni
Copy link
Member

bcoconni commented Mar 2, 2024

Closing this issue as the bug has been fixed in PR #1036.

@bcoconni bcoconni closed this as completed Mar 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants