trying to spin

[Johan G]

Should a single engine jet fighter be able to spin?

Many if not most of them are. Many fighters are deltas or nearly deltas and one of the more scary things to happen in one of those is getting into flat spin, even more so inverted flat spin.

The P in PARE (reducing power) mnemonic is important here, as not doing so increases the risk of flat spin. Also the way out when already within a flat spin is by increasing power.

I would guess that on top of that there is an increased risk of compressor stall or even flame out in a flat spin.

If so how do I put it into spin?

I would guess you would do it as with a regular aircraft, but I might be wrong.

By the way, have a look at this post, Pilot ejects at 8000 ft due to unrecoverable flat spin and... (The "Cornfield bomber").

[dany93]

Should a single engine jet fighter be able to spin?
If so how do I put it into spin?

Johan G has replied to your question better than I would have done.

I would add:
- a difference with jet fighters vs single engine propellers is that jet aircraft propulsion is symmetrical : differently, single engine propeller ones have torque and P-factor which initiate roll spin, particularly at full throttle even with straight coordinated flight and wings leveled. No such asymmetry with jet aircraft.
- as Johan G has written, delta aircraft probably have a very different handling due to their smaller wing span and different shape. Aft propulsion can only make things worst.

To put an aircraft into a spin can be understood from my post above. That's imperfectly explained, based on my understanding, I'm not an aerobatic pilot and IRL instructors do not practice this. On most aircraft this manoeuvre is forbidden, too dangerous.
Important: stall occurs apparently at too low speed, but really because of too high Angle of Attack.
In stall conditions (stick pulled up, too low speed), spin occurs in asymmetrical conditions : during a turn, or / and when slip skid ball is off center.
A very steep turn, yoke pulled up (to try keeping the altitude and turn rate) can induce stall and spin (even at relatively high speed, because of high AoA).
The best (worst !) is e.g. a left turn with too much left rudder i.e. slip skid ball full at right ('uncoordinated turn' with slip skid ball to the exterior = side slipping, skidding turn).
(if someone can correct or improve my explanations, thanks!).

In FG, just a few aircraft have an attempt to correctly render (with imperfections) spin due to stall.
This non-linear and complicated behavior is very difficult to simulate well, the results strongly depend on the FDM type and the modeller. Non-linearity is not a problem in JSBSim, but multiple cross effects make a very hard point even if it were with a much more sophisticated software.
- With JSBSim, stall and spin must be explicitly added in the FDM. Handling obviously depends on the code quality, still experimental. Here, we can appreciate the great flexibility of JSBSim which allows us to add and try such not initially anticipated things.
- With YASim, aircraft generally spin with no additional code, but those I've tested often do it in a poorly realistic manner, sometimes even rolling in the wrong direction in forward slipping.

[dany93]

there is a slight improvement in the controls that i can't put my finger on, is that what you ment by increase effectivness?
i found that indeed the rudder is better suited now for crosswind approach, it seems to move the plane around with more force thus coming in smoother in centerline, i don't know if there is an effect or it's placebo lol, but this what i would describe it

True. I've increased rudder effectiveness (+40%, although not enough at my taste for crosswind decrabbing and forward slip bank angle, unless there is something else not well tuned).
Also:
- decreased Roll moment due to side slip by a factor 0.25 (the aircraft was too stabilized against roll)
- increased elevator efficiency (+34%) to reach the stall AoA in all cases.
But my aim was to insert stall and spin behavior while respecting as much as possible the initial FDM. This sophisticated FDM has been done by people more competent than me, although it would need some minor refinements from my point of view.

i found the spin effect however a little increased, tried going in a spin on the left wing and the aircraft rolled about 60* left, nose down. trying to recover by pitching up while lossing altitude caused it to "snap spin" and tip over into the ground. a little snappy, but is this supposed to be the way it spins?

Truly said, I've neither quantitative data, nor experience. Your description is a mix of dynamic stall in a turn (at constant altitude) and strong dive recovering by pulling the yoke up (which in itself can induce a stall break, symmetrical or not). Obviously violent. Even more difficult to quantify, but I think it's qualitatively correct. If I understand well, you should have waited for stall recovery (enough speed with yoke at neutral for small AoA) before pulling up gently.
The spin effect is more than a little increased because it didn't occur initially. I agree, it may be too snappy (C172's are said rather gentle from this point of view). Connoisseur's remarks are welcome and I'm ready to make corrections to follow them (if I can...). Despite this, I think that the spin is too easy to recover from when seriously started (more difficult to improve in the FDM, I think).

That's a first version for C172P. At least a reminder of what's not to be done if someone wants to land with all parts in the right order . And a bit of what's to be done to recover (cut throttle, yoke at neutral, counter with rudder, wait for stall recovering to pull up again gently). If there is enough room underneath...

Thanks for your tests and remarks.

[hvengel]

...
In FG, just a few aircraft have an attempt to correctly render (with imperfections) spin due to stall.
This non-linear behavior is very difficult to simulate well, the result strongly depends on the FDM and the modeller.
- With JSBSim, stall and spin must be explicitly coded. Handling obviously depends on the code quality.....

This is very true. To get something even close to realistic spin behavior without causing issues in the normal flight envelope is very difficult and requires lots of fine tuning of the spin related code. This can easily require hundreds of hours of tweaking and testing on the part of the person working on the spin code. This is definitely non-trivial.

In addition at this point all of the spin capable JSBSim aircraft are individual efforts that have similarities in the spin code but also have areas where the code has significant differences. Although I think most of them, like the JSBSim P-51D, are derived from dany93's original work on the C-172. There is very little in the way of standardization in the spin code other than perhaps the general concepts being used. I think it would be good to sort out a standardized/generalized set of spin related JSBSim functions that could be documented and then used by modelers who have not yet spin enabled their JSBSim aircraft. But this is a big task since the spin code needs to be specifically tuned to each aircraft and generalizing the spin code in a way that allows this tuning in a simple way will be very difficult.

I would be willing to help out with an effort to do this. At this point I think there are only a handful of FDM modelers with any experience doing JSBSim spin work and it would be helpful if all (or most) of them were involved. In addition, I think it would be helpful to have someone representing the main JSBSim project involved as well since I think it might actually helpful integrate some support for this into the JSBSim code base to make it easier to do across a wide range of aircraft.

[dany93]

There is very little in the way of standardization in the spin code other than perhaps the general concepts being used. I think it would be good to sort out a standardized/generalized set of spin related JSBSim functions that could be documented and then used by modelers who have not yet spin enabled their JSBSim aircraft. But this is a big task since the spin code needs to be specifically tuned to each aircraft and generalizing the spin code in a way that allows this tuning in a simple way will be very difficult.

P51D's spin and stall code:
- is more sophisticated than the one I propose for C172P,
- allows for flat spin (that I could not get).
- is partly specialized for P51D's known behavior.
However, part of it is by patches which I think could be inserted in many FDMs with superficial (although delicate) adjustments.

C172P's spin and stall code:
It's more simple (I hope not too basic). As a start point, if possible to help those wishing to insert this piece of code in their JSBSim FDM and test it, here is its current version.
It is easy to insert as patches in an existing FDM.
The spin and stall patches are shown below in their context, pointed out by comments.
The relevant parameter is the angle of attack (stall above 16 -17 deg), main others are yaw rate and beta (side-slipping rate).

First part is during side slipping (crabbing), stall on the downwind wing (screened by fuselage turbulence).
N.B.: Too strong diedra effect in the FDM prevents spinning.

Code: Select all

        <axis name="ROLL">
            <function name="aero/coefficient/Clb">
                <description>Roll_moment_due_to_beta</description>
                <product>
                    <property>aero/qbar-psf</property>
                    <property>metrics/Sw-sqft</property>
                    <property>metrics/bw-ft</property>
                      <table>
                          <independentVar>aero/beta-rad</independentVar>
                          <tableData>
                             -0.3490    0.0322
                              0.0000    0.0000
                              0.3490   -0.0322
                          </tableData>
                      <value>0.25</value>
                      </table>
                      <!-- stall and spin (1): crabbing -->
                      <table>
                        <independentVar lookup="row">aero/alpha-wing-rad</independentVar>
                        <tableData>
                          0.279     1
                          0.297     5
                        </tableData>
                      </table>
                </product>
            </function>

Second part is less roll damping in stall conditions:

Code: Select all

            <function name="aero/coefficient/Clp">
                <description>Roll_moment_due_to_roll_rate_(roll_damping)</description>
                <product>
                    <property>aero/qbar-psf</property>
                    <property>metrics/Sw-sqft</property>
                    <property>metrics/bw-ft</property>
                    <property>aero/bi2vel</property>
                    <property>velocities/p-aero-rad_sec</property>
                    <value>-0.4840</value>
                    <!-- stall and spin (2): less roll damping -->
                    <table>
                      <independentVar lookup="row">aero/alpha-wing-rad</independentVar>
                      <tableData>
                         0.279    1
                         0.297    0.3
                      </tableData>
                    </table>
                </product>
            </function>

Third (most important) part is for spin due to stall on the inner wing during turn (which is even stronger if the slip-skid ball is on the external side of turn, i.e. skidding turn):

Code: Select all

            <function name="aero/coefficient/Clr">
                <description>Roll_moment_due_to_yaw_rate</description>
                <product>
                    <property>aero/qbar-psf</property>
                    <property>metrics/Sw-sqft</property>
                    <property>metrics/bw-ft</property>
                    <property>aero/bi2vel</property>
                    <property>velocities/r-aero-rad_sec</property>
                      <table>
                          <independentVar lookup="row">aero/alpha-rad</independentVar>
                          <independentVar lookup="column">fcs/flap-pos-deg</independentVar>
                          <tableData>
                                      0.0000  30.0000
                              0.0000  0.0798  0.1246
                              0.0940  0.1869  0.2317
                          </tableData>
                      </table>
                    <!-- stall and spin (3): yaw effect -->
                    <table>
                      <independentVar lookup="row">aero/alpha-wing-rad</independentVar>
                      <independentVar lookup="column">velocities/r-aero-rad_sec</independentVar>
                      <tableData>
                                 -0.15  -0.1   0    0.1   0.15
                        0.279     1      1     1    1     1
                        0.297     50     20    1    20    50
                      </tableData>
                    </table>
                </product>
            </function>

Fourth part is loss of ailerons efficiency when stalled (such as you need rudder to come out of it):

Code: Select all

            <function name="aero/coefficient/ClDa">
                <description>Roll_moment_due_to_aileron</description>
                <product>
                    <property>aero/qbar-psf</property>
                    <property>metrics/Sw-sqft</property>
                    <property>metrics/bw-ft</property>
                    <property>fcs/left-aileron-pos-rad</property>
                    <value>0.2290</value>
                    <!-- stall and spin (4): less efficient ailerons -->
                    <table>
                      <independentVar lookup="row">aero/alpha-wing-rad</independentVar>
                      <tableData>
                         0.279    1
                         0.297    0.3
                         0.611   -0.1
                      </tableData>
                    </table>
                </product>
            </function>

After that, some of its parameters have to be fitted to the aircraft, that's inescapable. However, if the refinement needs (as usually) many attempts, the principle is easy to understand.
One fitting may be for the stall angle of attack, which is not that different from an aircraft to the other.
After (or before) that, I would not say that the FDM must be fitted for the spin and stall code, but rather that the spin and stall code should be inserted in an already well balanced FDM. If FDM fitting is needed, this should not give a FDM degradation for normal conditions. My (limited) experience is that FDM fitting to have 'stall and spin' work has led to an improvement of the FDM in normal conditions.
Probably, the coefficients will need adjustments for the reactivity, e.g. to take inertia into account.

Do you think this piece of code can be a start point, or is it too much basic, or difficult to generalize ?
If it turns out that it is usable and satisfying enough, its patch aspect should allow its integration in Aeromatics, making every aircraft potentially spinnable under asymmetric stall.
Known limits at this point:
- I could not apply it to an aerobatic aircraft (it made the aircraft too prone to spin in aerobatic manoeuvres!).
- As already said, it does not render flat spin.
No attempts on heavy aircraft, jet fighters, etc...

I can't say which of the stall and spin codes (P51D or C172P) or a mix of both, could be better or / and easier to integrate for a start point in an Aeromatic-type FDM, but I think that's a way to consider.

[hvengel]

Well this is a starting point but I also think it is too simple and too complex at the same time.

Too simple. I think the thing that makes the P-51D spin code different is that it actually has a feedback loop that involves alpha, beta and roll which does not exist in the C-172 code. This feedback loop is very delicate and has to be very finely tuned to work correctly. Too much feedback and the spin is way too violent - too little and the spin does not develop the way it should. For very docile aircraft the feedback loop may not be needed but for aircraft that are less docile it definitely is needed. This feedback loop is the reason the P-51D will flat spin. It is also deeply imbedded in the FDM code so it is not apparent when looking at the FDM code. This will make extracting it for modularization non-trivial. It took a lot of effort to get this working and to understand how this worked but I also believe that this needs to be there even for more docile aircraft to allow fine tuning of the spin characteristics since it allows for a very wide range of spin characteristics.

Too complex. I am thinking in terms of a set of, perhaps complex, JSBSim functions that are just included in the FDM and never touched by the person setting up the FDM. There would also be a set of, normally very simple, functions that are easy for the FDM maintainer to understand and modify that could also be extended to do more complex tuning in straight forward ways that would be used to control/tune how this behaved (used to set parameter values for the complex spin functions). The idea being to make the functions that the FDM maintainer used simple to deal with under most circumstances and also well isolated from the complex parts of the spin code but to allow the FDM maintainer to do powerful spin modeling.

To better understand the too simple part. For many FDMs the alpha stall angle is fixed (IE. one set of polars is used for lift, drag and pitch moment) so the stall will always happen at the same alpha angle no matter what speed the aircraft is traveling. This is one of the assumptions of your spin code since this is how the C-172 is. The P-51D is different in this regard because the polars change with the Reynolds Number in particular near the stall alpha angle where the shape of the lift and drag curves near stall changes at different air speeds. So at 300MPH indicated it stalls (snaps) with perhaps a 1/2 degree greater alpha angle then at 100MPH indicated. Dealing with this in your simple frame work would be difficult since users would need to make major modifications to the actual spin code. Too complex and too in the weeds for users because the code makes simplifying assumptions. I think the "how badly stalled" part of this can be isolated in a user configurable function that is FDM specific while the actual spin code is untouched by the FDM maintainer. IE. this can be made modular which will make it more accessible. I also think I understand this part of the code well enough to do this generalization at this time.

I also think the feedback loop tuning could be handled in a similar way although it might be more complex to isolate the tuning functionality. I have to take another look at the code to understand what is required here to modularize this functionality.

This will require a significant amount of effort to fully generalize. Definitely non-trivial but at this point I think we understand the problem well enough to have a go at it with a reasonable expectation of success. I think I need to have a look at the P-51D spin code to start making it modular and to also isolate the tuning code from the actual spin code. This will increase my understanding of how this can be modularized and generalized. Give me a few weeks to have a go at this in my fgdata git clone and at that point I think we can have a look at it to see what should/could be done.

[hvengel]

One other difference between the C172P spin code and the P-51D spin code is that C172P code only does spin stuff for positive alpha values but the P-51D code also takes negative alpha values into consideration. So the P-51D will do inverted spins but the C172P will not. For the C172P this may be OK since it would be difficult to get it into a position to be stalled while inverted or to stall under negative G conditions where as the P-51D can pull very high negative G either upright or inverted and will do things like negative G snap rolls and stalls. So the C172P code is not the general case for all aircraft and inverted spin support should be part of a generalized set of spin functions. IE. The C172P code is too simple.

[dany93]

I understand better.
And I realize the gap amplitude that I felt. Difference between a game and a simulator....
Hence my phrase: (about C172P spin and stall)

At least a reminder of what's not to be done if someone wants to land with all parts in the right order . And a bit of what's to be done to recover (cut throttle, yoke at neutral, counter with rudder, wait for stall recovering to pull up again gently).

Not more.

[hvengel]

Yes I agree. Your C172P spin work was the starting point and inspiration for the P-51D spin code. Without that we wouldn't be talking about this subject at all beyond complaining about the lack of spin enabled aircraft. The C172P spin code is not perfect but is probably "good enough" for aircraft with very docile spin characteristics like the C172P and other modern GA aircraft.

When I started working with this code in the P-51D FDM I quickly discovered that I needed to extend it to make it simulate the documented stall/spin characteristics of the P-51D which are not nearly as docile as modern GA aircraft but also not as extreme as some high performance aircraft. After lots of experimentation I found a combination of functions and tuning values that worked and in the process discovered that these could be tuned to cover spin behaviors from very mild to totally unrecoverable. As a result I gained a better understanding of the factors involved to create a more complete spin simulation in JSBSim. I am fairly certain that this extended spin code can be adapted to almost any aircraft and tuned to simulate anything from very docile to extremely dangerous spin behavior.

Being a software engineer I tend to think about how things can be coded to handle the general case and that is what I am proposing be done with the XML spin code. But this is almost always more difficult than coding to handle a subset of cases and also requires a better understanding of what is going on. Typically the process of arriving at a general solution involves understanding a range of specific cases and then using those cases to arrive at a general solution. The C172P spin code gave us a starting set of the factors involved in spin modeling as well as a starting framework although these were only enough to model aircraft with docile spin behavior. The P-51D code built on that and has added additional factors. At this point I don't know if every factor is accounted for but it is not unusual for computer algorithms to ignore factors that have a small impact on the end result. I think that we now have enough factors identified to account for 95%, and perhaps more, of what is needed to get accurate spin modeling across a wide range of aircraft.

In addition to being generalized this must also be accessible to your average FDM maintainer. That I can understand this well enough to tune it is not good enough. This needs to be something that is accessible enough that most FDM maintainers will be able to setup a "close enough" spin simulation for their FDM in less than a days effort. This is actually a major challenge. In addition I think this will need extensive documentation to help users understand how to tune spin behavior.

I just moved and am in the middle of getting organized again after the move so my time available to work on this is limited right now otherwise I would have the extended spin code extracted from the P-51D with a first cut generalization in a few days. Since I proposed putting together a generalized JSBSim spin modeling XML framework I have been thinking about how that might be done and my vision about how this will look has been solidifying. I will be branching my fgdata clone for this in a few days and will start pushing changes to that branch in a few days later. At first these will be focused on isolating the spin code with minimal changes. If you are setup for gitorious please let me know and I will give you update access to my online clone. That way I can get valuable feedback from you about how to make this even better at the very least and perhaps you can also contribute to the code.

[dany93]

Huge program...

Thanks for your confidence.
I am on gitorious to work with a french team, but not the git of FlightGear.org. Having just a minimalist knowledge of this, I don't know if that's enough to access to your branch (only your aircraft, I don't want to pull every one from FG hangar!). Probably I will need your help for this.
If I can participate, I'll try, hoping I can get understanding of the IRL P51D's behavior. But you understand I'm very far from your software knowledge.

[hvengel]

If you have a gitorious id you already have read access to everything on gitorious. With a gitoriums id getting you update access to my on-line fgdata clone is a non-issue. PM your gitorious id and I will give you access. I will also move all of my latest changes over to that clone.

The bigger issue is that there is currently no way that I know of for you to clone only the P-51D part of fgdata and fgdata is huge. The last time I cloned it this took about 8 hours over a fast connection. The other issue related to only getting the P-51 part of fgdata is that there are a number of other directories in Aircraft/instruments-3d that are needed for the P-51D to function fully because these directories have things like the VHF radio and, with the latest version, the computing gun sight. Unfortunately I think the only way this will work is if you clone all of fgdata.

[dany93]

Sorry, cloning all of fgdata is too much for me.
However, an intermediate possibility may be to have access to your FDM alone, which can be sent merely by e-mail (or possibly uploaded with a link, but that's more heavy for you). I understand that's not so convenient for you, and not as efficient because I cannot have the very last version nor push changes, but anyway I don't know if can bring much for the code. The question is, is your current FDM compatible with my version of the P51D (official FG site version) ?

[hvengel]

The FDM is nearly identical at this point to the released version although there is some FDM work to improve ground and take off handling but these changes did not impact the spin code.. Most of the resent work is related to the new computing gun sight, improved 3D models (drop tanks, bomb racks, rockets and mounts, propeller, throttle quadrant), improved weapons system simulation and migration to the new checklist functionality. None of these changes affects the FDM.

I can probably zip up a file that has the p51 and other related fgdata/Aircraft/ directories that you can then upzip into your fgdata/Aircraft/ directory and find a place to put this on-line for you to download. One of the issues with gitiorious when working with a repository like fgdata where it is really a very large collection of smaller more or less standalone projects (IE. each aircraft) is that it is difficult to just grab an individual aircraft from the repository to work on. Before FG switched to gitorious you could download individual aircraft directories fairly easily so users did not need to download 5 or 6 gig of data to get one aircraft. It would be really nice to be able to clone individual aircraft.directories but no one has figured out a way to do this and not end up with even more issues.

[dany93]

If your current FDM is nearly identical to the one I have, no need, no question for now.
My question was rather for later, when you improve your FDM. As long I can test your future FDMs just by file replacement into my P51D version, no problem. I don't need new computing gun sight etc for that. Possibly some new nasal files if they are needed, in interaction with the future FDM. It is just a matter of interactions of other files with the FDM, not to have the very last version of the entire aircraft. As long as this works, it avoids problems at extracting the aircraft files from gitorious.

[hvengel]

It should be possible to do this by making patches available as well that can be applied to the released version. I don't think that there will be any need for Nasal and in fact I think this needs to run at the FDM rate rather then the frame rate. In addition JSBSim has all of the hooks needed to do what I have in mind although the XML syntax might get a little complicated.

A little more about what I am thinking.

In the current P-51D functions for the spin related roll and yaw the response curves (for lack of better terminology) are hard coded. I found that I couldn't use linear functions for this as things quickly diverged because the system was not properly damped. Using linear functions either resulted in the spin being too docile (IE. over damped) or too violent (under damped) and I couldn't get anything in between. By using non-linear functions I could damp the system and get just about any spin behavior I wanted by altering the shape of these curves. Since I was only concerned with getting the P-51 spinning I hard coded the curves but this does not allow for the general case.

What I think is needed to generalize this is to parametrize the system so that the shape of these curves can be controlled by setting a few parameter values for each curve. If I were working in C++ this would be fairly simple to do since I think I could probably find example code on-line that is designed to do exactly this type of thing (IE. generate curves with different shapes based on a few parameters) What I have to do is translate this into JSBSim XML functions which may be hard to do.

At this point I am thinking that there will be 3 parameters for each of these two curves. The first will control how close to the stall point the knee of the curve is - this will determine how quickly the spin develops. The second will determine how high the knee is - this will set how fast the spin is. The third will determine the shape of the tail - this will control spin damping. The mix between the roll and yaw spin response curves can be used to tune how much tendency the spin has to go flat. That is by increasing the strength of the yaw response and decreasing the strength of the roll response you will increase the flatness of the spin.

There also needs to be a way to control any tendency to drop one wing. For example the P-51 series is known for dropping the right wing when it stalls and there needs to be a way to set which direction and how strong this tendency is as well as allowing for aircraft that have no tendency to drop a specific wing.