P-factor: strong pitch moment with aircraft stopped in crosswind about jsbsim HOT 31 CLOSED

@dany93

As much as I can understand, the
angle = atan2(tangentialVel, localAeroVel(eU))
is a kind of generalized AoA (in a plane rotated around the U direction)
(correct?)

Correct.

In this case (stopped aircraft with pure crosswind),
localAeroVel(eW) / tangentialVel = 1,
angle = Pi/2
Is it too much, and enough to give this exaggerated pitch moment? Possible, the angle factor in flight is normally less than 0.3 rd.
Anyway, not a mathematical divergence (like tg(Pi/2)).

Indeed, this is not a divergence but this obviously gives an exaggerated weight to the case of a motionless aircraft with orthogonal cross wind.

IMHO the problem of the current formula is that it is based on the relative wind due to the aircraft motion. However, the air velocity at the propeller is different because the propeller "pulls" air through itself and that is what produces thrust. So we should account for the air velocity locally produced by thrust when computing the angle.

We know from the momentum theory that the air velocity at the propeller plane is localAeroVel(eU)+Vinduced (using the variable names from FGPropeller.cpp) so my suggestion would be to modify the code at line 261

@@ -258,7 +258,7 @@ double FGPropeller::Calculate(double EnginePower)
     double tangentialVel = localAeroVel.Magnitude(eV, eW);
 
     if (tangentialVel > 0.0001) {
-      double angle = atan2(tangentialVel, localAeroVel(eU));
+      double angle = atan2(tangentialVel, localAeroVel(eU) + Vinduced);
       double factor = Sense * P_Factor * angle / tangentialVel;
       SetActingLocationY( GetLocationY() + factor * localAeroVel(eW));
       SetActingLocationZ( GetLocationZ() + factor * localAeroVel(eV));

Since Vinduced is not null when the propeller produces thrust (even if the aircraft is motionless), we are guaranteed that angle should not reach values as high as π/2.

Disclaimer: This change is not based on a rigorous analysis of the aerodynamics that generate the P-factor but is rather a guesstimate/fudge factor/engineering judgment (choose your preferred name 😃)

Can you check this change on your side and let us know if it improves the situation ?

from jsbsim.

@bcoconni

Can you check this change on your side and let us know if it improves the situation ?

Sorry, I can't test it. Probably due to my lack of knowledge (I'm not a code developer, at best just able to use download_and_compile.sh).

I updated (a copy of) my version by download_and_compile.sh
But it only gives the next version, which does not contain your change.
Result from gitk:

FlightGear  f24d0a0 Mon, 25 Jun 2018 23:39:22 +0100 (EDIT: Maybe not, see below)
SimGear     a4e2fdf Sun, 24 Jun 2018 20:07:40 +0000
FGData      f8a549f Sun, 24 Jun 2018 22:44:50 +0100
PLIB        a542b8a Wed, 4 Oct 2017 17:33:51 +0200

Linux Mint 18, OSG 3.2.1, Qt 5.5

[EDIT]
My compilation failed on the Launcher. I guess this is the cause why FG was not updated. In the simulator (About...), the FG Revision number is my previous one. In contradiction with the gitlog (gitk).
I've posted a question in FGDevel mail list. Waiting...
[/EDIT]

I tried by manually changing line 261 in
FGPropeller.cpp, under flightgear/src/FDM/JSBSim/models/propulsion/
and doing download_and_compile.sh
but it has no effect in the simulator. Confirmed by another test change. Despite my change being kept and can be seen in FGPropeller.cpp (as "not added" for git).
I guess this is not the correct procedure, my change does not seem to be included in the compilation.
What should I do to test this change (or, if possible and easy enough, any change that I'd like to test)?

Thank you, and sorry.

from jsbsim.

The compilation works again now (thanks to James fix).
However, I don't know how to test your change.
I confirm that a change in FGPropeller.cpp, under flightgear/src/FDM/JSBSim/models/propulsion/
and doing download_and_compile.sh FGFS
has no effect in the simulator.

What is the correct procedure?
Is it possible to (easily enough) test such a change in the source code without doing a manual compilation?

from jsbsim.

@dany93

What is the correct procedure?
Is it possible to (easily enough) test such a change in the source code without doing a manual compilation?

Once you've applied the changes to FGPropeller.cpp, find the directory where FlightGear has been built. It is generally called build but the script you mentioned might not follow this convention. In that case, you should be able to locate the directory that contains a file named CMakeCache.txt.

From there, run the following command

> make

FlightGear should then be compiled and the resulting executable fgfs should be located in the subdirectory src/Main.

At any time, you should be able to check if one or several source files are modified by running the command

> git diff

If this command returns nothing then it means that no change has been applied to the code.

from jsbsim.

@bcoconni

I tried your procedure but something still goes wrong.

My organization is the one by download_and_compile.sh.

I created a directory for these attempts,
fgfs2018-3-p-factor/
which contains (duplicated from my last d_&_c):

• build (Nr1)
• flightgear (Nr2), git repository, branch next
• install (my usual directory with a flightgear folder containing bin, fgdata etc...).
• openscenegraph (empty), plib, simgear.

build (Nr1) contains a
flightgear folder with:

• src/FDM/JSBSim folder (fgfs2018-3-p-factor/build/flightgear/src/FDM/JSBSim)
• CMakeCache.txt file (fgfs2018-3-p-factor/build/flightgear)

flightgear (Nr2) contains
src/FDM/JSBSim/models/propulsion/FGPropeller.cpp
(fgfs2018-3-p-factor/flightgear/src/FDM/JSBSim/models/propulsion)
I've modified FGPropeller.cpp.

From inside the fgfs2018-3-p-factor/build/flightgear folder (which contains CMakeCache.txt),
I run make

~/fgfs2018-3-p-factor/build/flightgear $ make
[  0%] Built target fgsqlite3
[  6%] Built target iaxclient_lib
[ 11%] Built target flite_hts
[ 12%] Built target hts_engine
[ 12%] Built target PLIBJoystick
[ 12%] Built target fgelev
[ 16%] Built target fgpanel
[ 16%] Built target fgviewer
[ 17%] Built target UGsmooth
[ 17%] Built target MIDGsmooth
[ 17%] Built target GPSsmooth
[ 17%] Built target fgcom
[ 19%] Built target fgtraffic
[ 29%] Built target JSBSim
[ 29%] Built target testAeroMesh
[ 37%] Built target fgtestlib
[ 37%] Built target fgtest
[ 37%] Built target testAeroElement
[ 37%] Built target fgrcc
[ 37%] Automatic moc for target fglauncher
[ 37%] Built target fglauncher_automoc
[ 40%] Built target fglauncher
[ 40%] Automatic moc for target fgqmlui
[ 40%] Built target fgqmlui_automoc
[ 41%] Built target fgqmlui
[ 41%] Built target fgjs
[ 41%] Built target js_demo
[ 43%] Built target yasim-atmotest
[ 46%] Built target yasim-proptest
[ 48%] Built target yasim
[ 48%] Built target JSBsim_bin
[ 48%] Built target metar
[ 48%] Built target autosaveMigration
[ 48%] Automatic moc for target fgfs
[ 48%] Built target fgfs_automoc
[100%] Built target fgfs

But I see no trace of building compiling:

• fgfs2018-3-p-factor/build/flightgear/src/Main contains a fgfs Appilcation (293.5 Mo), but it is still from 29 june 2018 (my last d_and_c updating).
• Even after that, how can I get the fgfs compilation appear in my usual fgfs2018-3-p-factor/install/flightgear/bin? Just copy-paste it?

Sorry, I would have liked learning how to do this but, if that's too much asking you, I have an idea (which seems to work but still to be tested more) with a simple xml scripting in the FDM.

            <!-- P-factor, experimental, june 2018 -->
            <function name="aero/coefficient/Cnpfact">
                <description>Yaw_moment_due_to_p_factor</description>
                <product>
                    <property>velocities/u-aero-fps</property>
                    <property>/engines/active-engine/rpm</property>
                    <property>aero/alpha-rad</property>
                    <property>aero/coefficient/p-factor-coeff</property>
                </product>
            </function>

Anyway, thank you for your efforts.
Maybe I should limit myself at using d_&_c.

from jsbsim.

@dany93

Sorry, I would have liked learning how to do this but, if that's too much asking you

Don't worry, you're not asking too much. We are here to help each other 😃

If you run git diff from fgfs2018-3-p-factor/build/flightgear, does it report the modification you made to FGPropeller.cpp ?

Another means to check that the modification is taken into account is to output a message in the console.

@@ -173,6 +170,8 @@ FGPropeller::FGPropeller(FGFDMExec* exec, Element* prop_element, int num)
                       &FGPropeller::SetInducedVelocity );
 
   Debug(0);
+
+  cout << "Hi there !!!" << endl;
 }
 
 //%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

After that change has been implemented in FGPropeller.cpp and fgfs has been compiled, you should see the message Hi there !!! in the console when fgfs is executed.

If it does not, you can force the compilation with the following commands then check again for Hi there !!! in the console.

> make clean
> make

Regarding the execution of fgfs, theoretically it should be able to be executed from any place using a relative path (replace path/to by the relevant path)

> ./path/to/fgfs2018-3-p-factor/build/flightgear/src/Main/fgfs --aircraft=c172p

from jsbsim.

@dany93
Try

make clean; make

for flightgear to rebuild all parts.

And then (if the build succeeds)

make install

to get the binary copied to the install directory (I assume here that your build is configured to install into the directory you mention above).

It looks like the dependency handling in FlightGear is somewhat less than ideal since it apparently didn't pick up the modified source file.

from jsbsim.

Thank you, @bcoconni and @andgi

Don't worry, you're not asking too much. We are here to help each other

Thank you for your patience, but I will understand if eventually you prefer to give up.

If you run git diff from fgfs2018-3-p-factor/build/flightgear, does it report the modification you made to FGPropeller.cpp ?

No. Not a git repository

Only
fgfs2018-3-p-factor/flightgear
is a git repository. It does report my modification (like git status does) made in src/FDM/JSBSim/models/propulsion/FGPropeller.cpp

.

from jsbsim.

@dany93

• Did FlightGear compile when you run make ?
• Is there an executable fgfs in fgfs2018-3-p-factor/build/flightgear/src/Main ?
• What does happen when you run that executable from fgfs2018-3-p-factor/build with the following command ?

> ./src/Main/fgfs

You don't need to install FlightGear

from jsbsim.

Thank you, @bcoconni and @andgi

Don't worry, you're not asking too much. We are here to help each other

Thank you for your patience, but I will understand if eventually you prefer to give up.

If you run git diff from fgfs2018-3-p-factor/build/flightgear, does it report the modification you made to FGPropeller.cpp ?

No. Not a git repository

Only
fgfs2018-3-p-factor/flightgear
is a git repository. It does report my modification (like git status does) made in src/FDM/JSBSim/models/propulsion/FGPropeller.cpp

(I was doing tests, which makes that I had began starting this message and forgot it...)

Did FlightGear compile when you run make ?

I did it this morning, I got the content in this message. I would say it is building... Compiling?

Is there an executable fgfs in fgfs2018-3-p-factor/build/flightgear/src/Main ?

Yes. fgfs Application (293.5 Mo). I launched it (./fgfs for me), and it works (after having given my path to fgdata). It launches FG with the content of my .fgfsrc file. Good...
However from my test, the p-factor bug (nose lifted up under a 3 - 4 kt crosswind from left) happens. Which is another clue that my modification is not compiled. Despite it is seen by git in src/FDM/JSBSim/models/propulsion/FGPropeller.cpp.

from jsbsim.

@dany93

Which is another clue that my modification is not compiled. Despite it is seen by git in src/FDM/JSBSim/models/propulsion/FGPropeller.cpp

Not sure. It may be that the patch does not work...

However from my test, the p-factor bug (nose lifted up under a 3 - 4 kt crosswind from left) happens.

Is the engine running when that happens ?
Do you notice a difference when the engine is idling ? At half power ? At full power ?

Is the aircraft moving ? Stopped ? Brakes applied ? Are you moving the controls ?

from jsbsim.

@dany93
Did you run make clean before running make ?

from jsbsim.

I reproduced that @algefaen noticed.
Brakes applied. Crosswind (90 +/- 2 - 3deg), 3 to 4 kt, from left or right
Engine at idle: almost nothing.
Full thrust: as described (nose lifted up or strongly puhsed on the ground).
It seems to happen progressively with the thrust.
I'm not moving the controls.
The aircraft sometimes moves a bit, like if the brakes would not hold or some slipping on the ground. I would say that's not an important point.

With the engine stopped, nothing happens with 3 - 4 kt crosswind. But I noticed another bug, with 15 kt crosswind, even engine stopped. However, I do not want mixing the difficulties.

Up to now, the only single time I ran make was without make clean. I more or less presume that I should?... What is it for?

from jsbsim.

@dany93

Up to now, the only single time I run make was without make clean.

Could you please edit FGPropeller.cpp and add the line in green around line 170 ?

@@ -173,6 +170,8 @@ FGPropeller::FGPropeller(FGFDMExec* exec, Element* prop_element, int num)
                       &FGPropeller::SetInducedVelocity );
 
   Debug(0);
+
+  cout << "Hi there !!!" << endl;
 }
 
 //%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

then execute make. You should have a line like below displayed among the messages in the console.

[ 25%] Building CXX object src/FDM/JSBSim/CMakeFiles/JSBSim.dir/models/propulsion/FGPropeller.cpp.o

Then run fgfs and check if Hi there !!! is displayed somewhere on the console.

If it is not, run make clean then make and check again.

Let me know what you get.

from jsbsim.

Just for you to check if that's correct:

~/fgfs2018-3-p-factor/flightgear $ git diff
diff --git a/src/FDM/JSBSim/models/propulsion/FGPropeller.cpp b/src/FDM/JSBSim/models/propulsion/FGPropeller.cpp
index f2910ef..6cc2b3a 100644
--- a/src/FDM/JSBSim/models/propulsion/FGPropeller.cpp
+++ b/src/FDM/JSBSim/models/propulsion/FGPropeller.cpp
@@ -173,6 +173,8 @@ FGPropeller::FGPropeller(FGFDMExec* exec, Element* prop_element, int num)
                       &FGPropeller::SetInducedVelocity );
 
   Debug(0);
+  
+  cout << "Hi there !!!" << endl;
 }
 
 //%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -258,7 +260,7 @@ double FGPropeller::Calculate(double EnginePower)
     double tangentialVel = localAeroVel.Magnitude(eV, eW);
 
     if (tangentialVel > 0.0001) {
-      double angle = atan2(tangentialVel, localAeroVel(eU));
+      double angle = atan2(tangentialVel, localAeroVel(eU) + Vinduced);
       double factor = Sense * P_Factor * angle / tangentialVel;
       SetActingLocationY( GetLocationY() + factor * localAeroVel(eW));
       SetActingLocationZ( GetLocationZ() + factor * localAeroVel(eV));
@@ -479,3 +481,5 @@ void FGPropeller::Debug(int from)
   }
 }
 }
+
+

1- make: same as above.
2- make clean, then make:

dany@dellinux ~/fgfs2018-3-p-factor/build/flightgear $ make clean
dany@dellinux ~/fgfs2018-3-p-factor/build/flightgear $ make
[  0%] Built target fgsqlite3
[  6%] Built target iaxclient_lib
[ 11%] Built target flite_hts
[ 12%] Built target hts_engine
[ 12%] Built target PLIBJoystick
[ 12%] Built target fgelev
[ 16%] Built target fgpanel
[ 16%] Built target fgviewer
[ 17%] Built target UGsmooth
[ 17%] Built target MIDGsmooth
[ 17%] Built target GPSsmooth
[ 17%] Built target fgcom
[ 19%] Built target fgtraffic
[ 29%] Built target JSBSim
[ 29%] Built target testAeroMesh
[ 37%] Built target fgtestlib
[ 37%] Built target fgtest
[ 37%] Built target testAeroElement
[ 37%] Built target fgrcc
[ 37%] Automatic moc for target fglauncher
Generating InstallSceneryDialog.moc
Generating LocationController.moc
Generating QtLauncher.moc
Generating moc_AddOnsController.cpp
Generating moc_AircraftModel.cpp
Generating moc_AircraftSearchFilterModel.cpp
Generating moc_AirportDiagram.cpp
Generating moc_BaseDiagram.cpp
Generating moc_CatalogListModel.cpp
Generating moc_DefaultAircraftLocator.cpp
Generating moc_InstallSceneryDialog.cpp
Generating moc_LaunchConfig.cpp
Generating moc_LauncherArgumentTokenizer.cpp
Generating moc_LauncherController.cpp
Generating moc_LauncherMainWindow.cpp
Generating moc_LocationController.cpp
Generating moc_MPServersModel.cpp
Generating moc_NavaidDiagram.cpp
Generating moc_PathUrlHelper.cpp
Generating moc_PixmapImageItem.cpp
Generating moc_RecentAircraftModel.cpp
Generating moc_RecentLocationsModel.cpp
Generating moc_SetupRootDialog.cpp
[ 37%] Built target fglauncher_automoc
Scanning dependencies of target fglauncher
[ 40%] Built target fglauncher
[ 40%] Automatic moc for target fgqmlui
Generating LocalAircraftCache.moc
Generating PropertyItemModel.moc
Generating QQuickDrawable.moc
Generating QmlAircraftInfo.moc
Generating moc_FGQmlInstance.cpp
Generating moc_FGQmlPropertyNode.cpp
Generating moc_LocalAircraftCache.cpp
Generating moc_PopupWindowTracker.cpp
Generating moc_PreviewImageItem.cpp
Generating moc_PropertyItemModel.cpp
Generating moc_QmlAircraftInfo.cpp
Generating moc_QmlNavCacheWrapper.cpp
Generating moc_QmlPositioned.cpp
Generating moc_QmlRadioButtonHelper.cpp
Generating moc_QtQuickFGCanvasItem.cpp
Generating moc_ThumbnailImageItem.cpp
[ 40%] Built target fgqmlui_automoc
Scanning dependencies of target fgqmlui
[ 41%] Built target fgqmlui
[ 41%] Built target fgjs
[ 41%] Built target js_demo
[ 43%] Built target yasim-atmotest
[ 46%] Built target yasim-proptest
[ 48%] Built target yasim
[ 48%] Built target JSBsim_bin
[ 48%] Built target metar
[ 48%] Built target autosaveMigration
[ 48%] Automatic moc for target fgfs
Generating moc_GraphicsWindowQt5.cpp
[ 48%] Built target fgfs_automoc
Scanning dependencies of target fgfs
[100%] Built target fgfs

I do not have this line
[ 25%] Building CXX object src/FDM/JSBSim/CMakeFiles/JSBSim.dir/models/propulsion/FGPropeller.cpp.o
neither
Hi there !!! in the console at launching.

from jsbsim.

@dany93
OK. Thanks.

The modifications you made to FGPropeller.cpp seem correct.

You mentioned earlier that fgfs2018-3-p-factor was a duplication of the original copy that was made by download_and_compile.sh so it is possible that cmake is still referencing the original directory rather than the copy fgfs2018-3-p-factor

Could you please modify FGPropeller.cpp directly in the original copy from d_&_c.sh ? And run make from there ?

Up to now, the only single time I ran make was without make clean. I more or less presume that I should?... What is it for?

make clean deletes all the object files that were built previously. The idea is to force the compilation of everything rather than just the last edited file.

from jsbsim.

Thank you.
Don't be surprised, I have to leave for a moment.

from jsbsim.

it is possible that cmake is still referencing the original directory rather than the copy fgfs2018-3-p-factor

I made the test (with an old 2017.4.0, compiled from scratch), I think you are right. The fgfs appli was compiled. Good catch!!!
For me, it's late, I'll resume to morrow.

Still, I very often do a duplication + updating rather a new compiling, and I never had an issue (with d_&_c.sh at least)

from jsbsim.

As I wrote above, I very often do a duplication in order to keep a working FG (just in case) and to avoid having to download the full pack. Up to now, I made an updating with almost always no issue with the d_&_c script.

If I want trying such modifications and compile them, do you think that a fresh d&c is the only solution, or can it be circumvented more easily on a duplicated instance?

Which makes that I had to search for an old compilation done from scratch.
I found a 2017.4.0 instance (fortunately).

On this instance, I made my modifications in FGPropeller.cpp, ran make ==> everything worked.

Compilation:

~/fgfs2017-4-0-B/build/flightgear $ make
[  0%] Built target fgsqlite3
(...)
Scanning dependencies of target JSBSim
[ 26%] Building CXX object src/FDM/JSBSim/CMakeFiles/JSBSim.dir/models/propulsion/FGPropeller.cpp.o
(....)
[ 50%] Linking CXX executable fgfs
[100%] Built target fgfs
_____________________________________

FG Launching, console:

~/fgfs2017-4-0-B/build/flightgear/src/Main $ ./fgfs
FlightGear:  Version 2017.4.0
Hi there !!!
Hi there !!!

You were right.

Tests, with
double angle = atan2(tangentialVel, localAeroVel(eU) + Vinduced)

Aircraft at rest, with brakes ON, full thrust.
Crosswind about 80 to 85 deg or 95 to 100 deg, from left or right side, 3 kt or 12 - 15 kt.

• 3 kt crosswind (left or right side): The nose moderately pitches down. Normal.
• 12 kt crosswind: much improved, with some reserve.
  From left: nose pitches down, but only moderately. Like if a bit of the pitch up tendency would remain.
  From right: normal.

This in an important improvement because, previously, 3 kt crosswind from left side made the nose wheel lift up above the ground.
I think that it could be a viable solution (still to be observed more and to be tested by @algefaen).

However, as the + Vinduced addition is a kind of hack with (IMHO) no obvious physics justification, which moreover does not seem to fully solve the symptoms, I'd like to ask you about one or two suggestions (following message).
[EDIT] After more thought, I'm not so sure. Your argument with + Vinduced might find a justification...

from jsbsim.

Asymmetric Thrust Explained
P Factor?

Alternative suggestions / thoughts:

According to the most simple calculations (and at small angles), the P-Factor effect (moment) is proportional to the relative airspeed (usual airspeed, from the nose).
Rather, proportional to sinus(Angle), airspeed, propeller RPM.

      double angle = atan2(tangentialVel, localAeroVel(eU));
      double factor = Sense * P_Factor * (localAeroVel(eU) / 169) * (angle / tangentialVel);

(localAeroVel(eU) / 169) is a reduced velocity (dimensionless, arbitrary factor), taking the value = 1 at 100 kt. The aim is keeping the amplitude of the effect at most speeds with the same p_factor value (backwards compatibility). It obviously would give a zero moment at rest and pure crosswind.
(if I understand well, and assuming localAeroVel(eU) in ft/sec).
Not tested, I still have to think more about it (and get your opinion). I'd like it if it could work.
EDIT
After thought, It does not seem to be such a good solution. It would cancel the pitch-moment due to crosswind at rest on the runway.
/EDIT

If everything goes bad, another possibility (not my preference) might be zeroing the lever arm inSetActingLocationZ( GetLocationZ() + factor * localAeroVel(eV))
(pitch moment due to P-factor crosswind). Or commenting the line.

from jsbsim.

@bcoconni

The more I think about it, the more I'm sure of nothing... (except that it is complicated).

At rest on the runway with a pure crosswind (close to + or - 90 deg), the pitch moment should be true. Only, it was excessive with the initial version.
My (localAeroVel(eU) / 169) factor, valid for basic conditions (no crosswind) would break this contribution at rest.

Your + Vinduced addition already improves (reduced pitch effect).

In the simple calculation (vectors), I find that the P-factor moment is proportional to sin(AoA). No difference for small angles (usual conditions in flight), but AoA overestimates the yaw moment for large angles.
What about taking sin(angle) instead of angle?

      double angle = atan2(tangentialVel, localAeroVel(eU) + Vinduced);
      double factor = Sense * P_Factor * sin(angle) / tangentialVel;
      SetActingLocationY( GetLocationY() + factor * localAeroVel(eW));
      SetActingLocationZ( GetLocationZ() + factor * localAeroVel(eV));

from jsbsim.

@bcoconni

Unless I do a mistake, the PFactor Pitch (engine N) and PFactor Yaw (engine N) columns have their contents exchanged.

If I cancel the Z lever arm (pitch moment due to crosswind)
SetActingLocationZ( GetLocationZ() + 0 * factor * localAeroVel(eV))
the pitch column has usual values (up to 250), but the yaw column is full of zeros.

from jsbsim.

@dany93

Sorry I did not have much time to reply to your messages these last days.

I think that it could be a viable solution (still to be observed more and to be tested by @algefaen)

Great !

However, as the + Vinduced addition [...snip...] does not seem to fully solve the symptoms

According to the description you gave, I understand that this brings some improvements but you did not mention which symptoms remained to be cured ? You could give more details ?

the + Vinduced addition is a kind of hack with (IMHO) no obvious physics justification

Well that's a bit harsh 😃

Indeed this modification is not based on a rigorous mathematical resolution of the aerodynamics equation but it did not come out of the blue either. When I submitted this change, I mentioned that angle was computed from the aircraft velocity and that this is not entirely relevant at the propeller.

The production of thrust is the result of a local airflow through the propeller which longitudinal (X) velocity is localAeroVel(eU)+Vinduced. This latter expression is based on Froude's momentum theory of propeller and is built on a solid (albeit simplified) theoretical foundation.

The engineering judgement I made is that the P-factor is the result of a linear combination of the momentum theory and of the crosswind velocity component. The real airflow is probably non linear which means that my assumption probably breaks down for strong cross winds.

Alternative suggestions / thoughts:

double angle = atan2(tangentialVel, localAeroVel(eU));
double factor = Sense * P_Factor * (localAeroVel(eU) / 169) * (angle / tangentialVel);

You could get the exact same result by dividing the value in <p_factor> by 169 in the XML definition of your aircraft. There is no added value to hard code this value in the C++ source.

If everything goes bad, another possibility (not my preference) might be zeroing the lever arm in SetActingLocationZ( GetLocationZ() + factor * localAeroVel(eV)) (pitch moment due to P-factor crosswind).

Well, you can disable the whole P-factor computation by not setting <p_factor> in the first place. If you mean that in some conditions we might need to cancel out the action of the P factor, that is a different story. But we need to define what are such conditions.

What about taking sin(angle) instead of angle ?

That's an option. Any function f that is such that f(0.0) == 0.0 is acceptable for now.
Have you tried to implement that change and to test it ?

Unless I do a mistake, the PFactor Pitch (engine N) and PFactor Yaw (engine N) columns have their contents exchanged.

I'll check that later this week and let you know my findings.

Very interesting discussion @dany93, your thorough inspections are really bringing much added value to JSBSim. I am sure we will end up with a much improved P-factor simulation.

from jsbsim.

@dany93
I just pushed this change to FlightGear since you reported that it improves the situation.

@@ -258,7 +258,7 @@ double FGPropeller::Calculate(double EnginePower)
     double tangentialVel = localAeroVel.Magnitude(eV, eW);
 
     if (tangentialVel > 0.0001) {
-      double angle = atan2(tangentialVel, localAeroVel(eU));
+      double angle = atan2(tangentialVel, localAeroVel(eU) + Vinduced);
       double factor = Sense * P_Factor * angle / tangentialVel;
       SetActingLocationY( GetLocationY() + factor * localAeroVel(eW));
       SetActingLocationZ( GetLocationZ() + factor * localAeroVel(eV));

I will let you review with your teammates if that is definitely an improvement over the current situation in which case I will push it to JSBSim as well.

And we still have 2 open topics:

• Should we apply sin to angle ?
• Are PFactor Pitch (engine N) and PFactor Yaw (engine N) correctly reported ?

from jsbsim.

@bcoconni wrote

Sorry I did not have much time to reply to your messages these last days.

No problem. Every one has his own occupations and constraints. And priorities.

Well that's a bit harsh smiley

Sorry, I didn't mean to be unpleasant. 😃

in which case I will push it to JSBSim as well.

Does it mean that it is in JSBSim with the FG pack but not in (some) self-sufficient JSBSim?

double factor = Sense * P_Factor * (localAeroVel(eU) / 169) * (angle / tangentialVel);
You could get the exact same result by dividing the value in <p_factor> by 169 in the XML definition of your aircraft. There is no added value to hard code this value in the C++ source.

I don't understand, there is an added value: the (localAeroVel(eU) factor. But after more thought I wrote that it was not a good solution.
The 1 / 169 was just an arbitrary normalization for the AeroVel(eU). Yes, it could have been combined with the <p_factor>. But I wished not to change the initial inputs from the user.
My idea was to cancel the pitch moment due to pure crosswind at rest. But after more thought I realize that this pitch moment should be true (only, it was way too strong). Thus, I forget this idea.

@algefaen is currently in holidays.

Very interesting discussion @dany93, your thorough inspections are really bringing much added value to JSBSim. I am sure we will end up with a much improved P-factor simulation.

Great. Thank you.

It's late, I'll go on to morrow.

from jsbsim.

@bcoconni wrote

According to the description you gave, I understand that this brings some improvements but you did not mention which symptoms remained to be cured ? You could give more details ?

@dany93 wrote

12 kt crosswind: much improved, with some reserve.
From left: nose pitches down, but only moderately. Like if a bit of the pitch up tendency would remain.

I believed that this pitch moment (up or down) due to P-factor at rest, full thrust with pure crosswind was wrong, to be canceled. I believed that the nose should pitch down with full thrust as if there were no crosswind. Hence my (localAeroVel(eU) factor. As written above, I've changed my mind.
Is it clearer?

What about taking sin(angle) instead of angle ?

That's an option. Any function f that is such that f(0.0) == 0.0 is acceptable for now.
Have you tried to implement that change and to test it ?

Yes (just once or twice). It increases (partly restores?) the nose down movement at full thrust, 12 to 15 kt crosswind from left (it was already well seen from right). As far as the yaw moment, it slightly decreases the needed action on the rudder at start of rolling on the runway, and have (almost?) no effect in flight. As expected. But these measurements are hard to do, they are dependent of an accurate control and stabilization by the pilot. We are dealing with small differences.
Honestly, if your +Vinduced addition does the trick (as it seems to, still to be observed more), I think that the sin(angle) effect might remain unnoticed. Rather, that is (that was?) for the principle, because I think that the angle contribution should have this sin(angle) dependence at high angles (once more, at rest with full thrust, pure crosswind 10 to 15 kt). However, the sinus effect should be (I think) insensitive in flight.
If your +Vinduced addition would not have been enough, the sin(angle) might have helped.

from jsbsim.

@dany93

Does it mean that it is in JSBSim with the FG pack but not in (some) self-sufficient JSBSim?

Well, I just pushed the fix in JSBSim too (commit 82cc389). So it is now available in both JSBSim and FlightGear.

from jsbsim.

@dany93

Unless I do a mistake, the PFactor Pitch (engine N) and PFactor Yaw (engine N) columns have their contents exchanged.

Agreed this should now be fixed by the commit fd1ed15

from jsbsim.

@algefaen wrote

I think this is pretty good now

Merged, commit in C172P master.

Thank you, @bcoconni

from jsbsim.

Merged, commit in C172P master.

Excellent !
Issue closed.

from jsbsim.

@bcoconni should we not make the same changes to the p_factor in the FDM of the C172 models that are included with the JSBSim distribution?

from jsbsim.