GyroKit library and GyroRotor program

Jean Fourcade

Newbie
Joined
Sep 24, 2014
Messages
76
Location
Toulouse France
Dear all,

I have been involved in gyroplane between 1995 and 2004, building and flying a Dominator and studying flight mechanics of this very special aircraft. Then I was interested in other activities.

Few years ago I got interested again in gyroplane, looking on internet, and I was very surprised to read on Tervamaki web site a page concerning gyroplane stability where he speaks about “thrust line psychosis” and concludes that the work of the Glasgow university was a misconceptions on gyroplane longitudinal stability. Tervamaki oppose to the work of Glasgow university a paper from Prof. Laine and the way it is presented make think that there were some mistake on Hounston’s work.

Now this page has changed. The word “misconception” is no more used but there is still a remark (we don’t know from whom) which says that Houston reports have done damage to the evolution of safer gyroplanes.

The current trend concerning the design of autogyros seems to be : ok, we know that in HTL gyro the rotor thrust line goes in front of the CoM but this not a problem because it can be compensate by an adequate horizontal stab !

For instance, eddie , on a recent post said :

eddie said:
The thrustline was never the problem of instability,it was the lack of a horziontal stab.The knee jerk reaction was to lower the thrust line. Which with time the horz stab has proven to be the fix. the high rise gyro will become a thing of the past as the new euro gyro is more attractive and flys just fine. Its called progress, some approve and some don"t.

Personally, I disagree with this point of view because LTL gyro are, by far, the more stable and safer gyro you can design. Of course, such a scientific opinion has to be proven.

The Studies of the longitudinal stability of rotary wing aircraft and especially computation of long period mode (phugoid) are not simple. As I know there is no free software that everybody can use to compute such modes and I thought it will be a good idea to try to make one. The GyroKit library is a Java library which was developed for that purpose. The library is not finish yet but it is time to speak about it. This library is distributed under the http://www.cecill.info licence which gives you access to all sources code. The library can be found on my web site here.

The library includes also some programs and the first one developed is the GyroRotor which purpose is to compute aerodynamic characteristics (force and torque, flapping and torsional deflection coefficients) of a rotor in uniform translation and rotation.

The following figure shows an example where data are the one from the Kelett KD-1 rotor. For more details see the user manual of the program that provides you description of input/output parameters of the software.



The next figure shows the results of a simulation where the aircraft speed is 97.68 km/h, rotor incidence 7.079 degrees and blade pitch 5.5 degrees. One interesting result is the twist of the blade which value at 3/4 radius is -1.35 degrees.



Within the library you will find the "applications" package which contains the KD1.java class and the R22.java class.

The KD1.java class compares the results of the GyroRotor program with the data measures in flight as given by the NACA report 600. The two following figures show the flapping coefficient (a0, a1, b1, a2, b2) and the Fourrier coefficients of the blade twist (u0, u1, u2, v1, v2).





The next figure shows the twist of the two bigger coefficients (u0 which is the mean coefficient and v1 the first sine component) along blade radius.



The R22.java class computes the power diagram of the R22 helicopter. The curves shows are compared to the R22 user manual.



The GyroRotor program computes also blade angle of attack distribution. The following figure shows aoa distribution for the R22 helicopter at full speed.



Finally, the GyroRotor program computes also the rotor derivatives with respect to rotor disc frame or body-fixed frame. As the rotor program takes into account the blade twist, it allows computing for instance the effect of twist on Mq derivative.

I will be back on that point on a future post.

Be aware that this program has not been intensively used and that there may be some bugs.

Remarks are welcome.

Jean Fourcade
 
Last edited:
Hi Jean, this is a great job you have accomplished here. It takes Yukka's simple gyro simulation program one step further -- at least for the rotor at this point. I hope you will continue to develop it.

-- Chris.
 
It is wonderful to have you back, Jean.

For those who don’t know, Jean Fourcade was (and perhaps still is) an engineer/scientist at the French space agency at Toulouse.
 
Hi Chuck,

Glad to be in touch with you again ! Yes, I am still working on space flight mechanics (not yet the age of retirement, although it is coming soon ...)
 
Few years ago I was very surprised to read on Tervamaki web site a page concerning gyroplane stability where he concludes that the work of the Glasgow university was a misconceptions on gyroplane longitudinal stability. Tervamaki oppose to the work of Glasgow university a paper from Prof. Laine and the way it is presented make think that there were some mistake on Hounston’s work.
I already said what I think of Houston's work concerning the gyroplane stability: Poor, despite exceptional measurement device used. He treated and concluded on the long-period stability with a blocked stick. Therefore, it's conclusion may be true (*), but she is irrelevant for the usual conditions of flight: Short period with fix stick, or long period with free stick.
(*)"Autogyro stability is insensitive to changes in most configurational parameters with the exception of vertical location of centre of gravity."
So, insensitive in tail parameters ??? I guess this is what has shocked Jukka, like me.
The GyroRotor program computes also blade angle of attack distribution. The following figure shows aoa distribution for the R22 helicopter at full speed.
Remarks are welcome.

Your fig. shows at 0,75 R :
For azimut 0° , angle of attack 7°. I obtains 6.7°.
For azimut 90° , angle of attack 2.5°. I obtains 2.6°.
For azimut 180°, angle of attack 7°. I obtains 6.8°.
For azimut 270° , angle of attack 10.5°. I obtains 10.2°.
Very close !

For other checking of your GyroRotor, I evalued inertia of Magni's rotor 36 kg 8,50m according Averso's drawing:192 kg.m2
My mail for more is [email protected]
 
Last edited:
Wow!!
Free Java tools for the world rotorcraft community that will allow more of us lay people to explore and learn in real time!!!

Wow... U-ROCK!!!!!
I love this site and you people!!!
Thank you!
 
Hi Jean-Claude,

Jean-Claude and I, have several times cross-checked our softwares. We always, as today, found them consistant.

So, insensitive in tail parameters ??? I guess this is what has shocked Jukka, like me.

I know, Jean-Claude, but this is what they found. I took the following figure from the Glasgow report which shows the eigenvalues of the stability derivatives matrix with and without tail plane.



If we believe their simulations, this figure shows that the short period modes of VPM M16 without tail plane are still stables. Of course, the damping decreases and the period increases, but they are still compliant with BCAR Section T (left region of the blue line). As, moreover, the phugoid does not change significantly, they concluded that the stability of the VPM M16 is insensitive in tail parameter.

Thank you for the moi value of the Magni rotor. I asked you this value because the one in the Glasgow report is wrong (51.6 kg m2, not consistent with the coning angle of their simulations). Since then, I have seen in the forum that the blade mass was not good. With a value of 18.5 kg we get 112.26 kg m2 for the flapping inertia, close to your value for both blades.
 
Last edited:
Hi Jean,

your gyro program looks great and it is very exciting to have a professional now, who writes a gyro stability program, in the ranks and files of the rotaryforum! I have downloaded your program and will try to get it to run over the weekend (I have worked with JAVA and eclipse between 1995 and 2001, so my knowledge of this language is a bit rusty...;-)
From the input it seems that you have implemented the forumlae of naca 600 in your rotor class and this is what I also did in one module of my own gyro stability program. I am really looking forward to comparing results of our calculations. My ultimate goal is to calculate the stability parameters of the longitudinal stability matrix. I am still very unsure about how close my parameters are to data of real aircraft. I understand that part of the output of your program is also the stabiltiy matrix, so this is another area where I would very much like to compare results. It seems there are exciting times ahead!
 
Last edited:
If we believe their simulations, this figure shows that the short period modes of VPM M16 without tail plane are still stables.
Je ne comprends pas comment les simulations de Glasgow donnent une stabilité positive à un autogire HTL sans queue, puisque dans ces conditions la poussée du rotor doit nécessairement être en avant de G pour l'équilibre statique.
I do not understand how Glasgow's simulations gives a positive stability to a gyroplane HTL tailless, since under these conditions the rotor thrust must necessarily be in front GC for static balance.

I asked you this m.o.i. value because the one in the Glasgow report is wrong (51.6 kg m2, not consistent with the coning angle of their simulations). Since then, I have seen in the forum that the blade mass was not good. With a value of 18.5 kg we get 112.26 kg m2 for the flapping inertia, close to your value for both blades.
Leurs erreurs sont hélas nombreuses.
Partant d'une masse de pale fausse (8,5 kg), je suppose qu'ils ont simplement calculé son inertie par la formule 1/3 M.R^2, donnant 51,6 kg.m2 avec le rayon de 4,267 m
Plus grave est leur mesure de HTL: 0,027 m tandis que la vraie valeur est Dix fois plus. Observez encore l'inertie de lacet totalement improbables: IZZ = 4425 kg.m2 ! Selon mes calculs, I ZZ= 270 kg.m2
Enfin, tout aussi improbable le changement de HTL de -3" à +3". Il aurait fallu pour cela déplacer 34 kg du haut en bas du mât. Hélas, aucune photo de ce dispositif.

Their mistakes are unfortunately numerous.
Starting from a false blade mass (8.5 kg), I guess they just inertia calculated by the formula 1/3 M.R^2, giving 51.6 kg.m2 with the radius of 4,267 m
More serious is their measurement HTL: 0.027 m while the true value is ten times more. Observe yet the yaw inertia mentioned, totally improbable: IZZ = 4425 kg.m2! According my more close to 270 kg.m2
Equally improbable, HTL change from +3" to -3". It would have taken 34 kg from mast head to the root. Unfortunately no photos for this device..
 
Last edited:
Hi Juergen,

Here are some additional informations :

The java class used in the GyroRotor program to compute rotor characteristics is called GlauertRotor.java, in tribute to the Glauert works, but is mainly based on Wheatley NACA reports 487, 591 and 600.

As you will see there are two improvements :

- the first one is to use the Shaydakov induced velocity. The Shaydakov theory is a constant induced velocity which can be used when rotor incidence is greater thant 30 degrees and allows to compute vertical descent (90 degrees incidence).

- the second improvement concerns the modélisation of the blade twist which is not supposed linear (as naca report 600) but is computed with a five order polynomial function.

The 25 déformation coefficients are solved via a matrix inversion. The coefficients of this matrix are calculated analytically. I used the Maple software to generate the java code from the analytical expressions and cross-checked results between Maple and Java.

The derivatives in the GyroRotor programm are calculated numericaly by finite différence. I cross-checked most of them with theirs analytic expressions (but without taken into account the blade twist which will give too long expressions).

As you said the goal is to calculate the matrix stability derivatives to evaluate short and long period modes of a given gyroplnane.

I am also very interrested to compare my results with yours. This portends very interesting and exiting exchanges !

Jean
 
Last edited:
I didn't have much time this evening but I just couldn't resist to run a quick and dirty series of calculations using input data for the Kellet KD-1 and the nace-600 module (no modifications, just implementing the bare formulae of the report) of my gyro stability program. The input values were only close to the ones in this thread so just some general observations. Using a constant drag value of 0.165 longitudinal and lateral flapping angles a1, b1 are close to Jeans diagrams, which also show the measured values of naca 600. Coning angle though was much larger. Also disk angle and with it inflow ratio were larger (I take it that incidence NFP is the angle of the no feathering plane, right?). My stability derivatives are calculated via applying finite differences to the full model. The value of Routh's Discriminant is halved for the case of constant drag. Results, including the stability matrixes, are in the pictures below. The values do not take into account variable rotor speed. I have only just started to explore this area based on Nikolsky's report. (http://www.rotaryforum.com/forum/showthread.php?p=615088). I have attached the input file with the KD-1 data I am using for comparison.
So much for tonight (23:46). More to come.
 

Attachments

  • dN_eq_Np165.JPG
    dN_eq_Np165.JPG
    21.6 KB · Views: 2
  • ThreeTermPolar.JPG
    ThreeTermPolar.JPG
    21.7 KB · Views: 2
  • KelletKD1wtws.txt
    9.6 KB · Views: 0
Last edited:
You are right, the NFP incidence is the angle relative to the no-feathering plane.
Be aware that my diagrams of the KD1 gyro are not computed with a constant blade profile drag coefficient. I have computed this coefficient as well as the rotor incidence so that the lift equal the KD1 weight and so that the total rotor torque is zero for the given rotor speed (see the KD1.java class in the "Application package"). I got this :



In theory, the blade total drag is the sum of the profile drag and lift induced drag. In naca 600 formulas, as you know, the lift induced drag is not taking into account. So the "profile drag coefficient" is in fact the "total drag coefficient". So the need to make the "profile drag coefficient" varying with rotor incidence. The profile drag coefficient should be in fact consider as a tuning parameter to get the good rotor speed.

I suggest first that we compare our results (flapping, forces, inflow) for some given points where we fix air speed and rotor incidence, without taken into account blade twist if possible. Then we could compare rotor derivatives.
 
Last edited:
Of course you are right, Jean, we should attack the problem in a professional way, I just got carried away a bit last night. My program uses a full aircraft model, rotor, fuselage, empenage and performs a trim calculation. The result is, amongst other things, the rotor state. I understand that your rotor module works a bit like a wind tunnel experiment, you prescribe the shaft angle and from that and aircraft mass calculate the rotor state required to generate the required lift. If I am right then the easiest way would be if I run calculations for several mu values and give you a table of shaft angles and wind speeds. It would take quite some tweaking of the model to do it the other way round and try to reproduce the shaft angles you might have used for input. We will see how we overcome the problem of drag values. I am using a three term drag polar and this one can not be used as a single valued function since the weighting of the zero term is too large. We will probably need some sort of iteration, or rather a bit handing results back and forth e.g. to find a common lift slope value, until our results are comparable. If you think that this is a viable way of tackling the problem I will post the first table of mu and shaft values tonight.
PS: I should perhaps add that my module for rigid rotor blades is based on naca-716. It seems a good idea to start with the case, where blade twist is not taken into account.

Cheers,

Juergen
 
Last edited:
GyroKit installation

GyroKit installation

Regarding your program I have created a new JAVA project in eclipse and imported your files. This seems alright so fare, does it? (see picture) From my JAVA days I seem to remember that you can basically place your files at will and than have to include them in the JAVAPATH variable, so I would just copy the *.jar files to the project but then, how do I set the PATH variable correctly? Also the junit component seems to be missing in my eclipse (indigo). I have downloaded it but it is currently not recognized in the project. Do you think it would help to install the latest eclipse?
 

Attachments

  • GyroKitProject.JPG
    GyroKitProject.JPG
    12.7 KB · Views: 2
  • junit_error.JPG
    junit_error.JPG
    18.6 KB · Views: 2
Juergen,

I agree with what you said : generate somme points with your software and give me rotor incidence and air speed and I will run my software. As for the blade drag we have to think about it. One suggestion is that I compute the drag to have the same rotor speed as you.

You dont need JUnit until you run the test programs. You have to install external library like commons-math3, Miglayout, and JFreeChart. You can find theses library in the "dist" directory in the GyroRotor zip file.

As for the JAVAPATH I am not sure to understand your need.

I think that any version of Eclipse will do the job but you need Java 7 compiler.

Jean
 
Last edited:
Hi Jean,

here are results for six flight speeds. The results are grouped as in the picture below. The first block of genral data has been used for all the test cases. I have marked the data which you, from what I understood, wanted to use as input for your program. These are shaft angle alfaS, resultant flight speed and rotor speed. I have also attached the input data for the aircraft which were used for all the flight cases. The results have been calculated using standard atmosphere and my naca-716 module which does not take into account any dynamic blade twist. Please let me know if there is something I have missed.

Cheers,

Juergen
 

Attachments

  • prog_comp_input_data_structure.png
    prog_comp_input_data_structure.png
    13.1 KB · Views: 2
  • KelletKD1ntws_prog_comp.txt
    9.4 KB · Views: 1
  • prog_comp_jf.txt
    4.7 KB · Views: 0
Last edited:
Hi Jean,

unfortunately I am still having problems to fire up your program. When I try to create a debug configuration I would have to enter a file here that contains a
public void main()
method, or so I seem to remember, but the selection window (rightmost in the pic) does not allow to select files, what am I missing here?
 

Attachments

  • GyroKit_debug_config.JPG
    GyroKit_debug_config.JPG
    103.2 KB · Views: 0
making progress

making progress

I am now able to select modules with a main class after having added them to the BuildPath. The new error message is:
Error: Could not find or load main class rotor.GlauertRotorDerivativeTest
I had added the directory
workspace_mars\GyroKitMKII\GyroKit\test\inducedvelocity
to the classpath (this is the variable I erroneously called javapath in a previous post) so eclipse should find it, no?
 

Attachments

  • GyroKit_debug_could_not_find_main_class.jpg
    GyroKit_debug_could_not_find_main_class.jpg
    130.6 KB · Views: 0
different idea

different idea

rereading the error message it says "could not find or launch" so another possibility would be that the application does not launch because of the errors I get: "Multivariate function can not be resolved to a type". This seems to indicate, that commons.math is not found. I have included the tar.gz, is that ok, any other idea?
 

Attachments

  • GyroKit_debug_commons_math.JPG
    GyroKit_debug_commons_math.JPG
    8.7 KB · Views: 0
Top