feedback concerning our FDM

[gilbertohasnofb]

Hey guys, someone in the forum posted some feedback concerning our FDM, see:

I love what you've accomplished with the c172p!

I have one little gripe though...To me it doesn't seem like p-factor+slipstream vs. torque roll isn't quite correct. I often have my ball being far off for what I think should be ok. During slow, high-powered climb, the p-factor+torque+slipstream does what it's supposed to do (left yaw + bank). Counteracting this with right rudder is simple enough. But the ball slips way to the left, and indeed I end up yawing to the right, with what I feel is "natural" amount of rudder to counteract the left tendencies. To actually fly straight, I have to just a little bit of rudder but way more aileron. Is it possible that the fdm gives too much roll and too little yaw from p-factor/torque/slipstream? Or is it just my stick/rudder calibration which is way off?

I collected a little bit of data. I used aileron trim and rudder trim to make it fly straight with the ball in the middle in a climb. The hud shows that the aileron trim is more than the rudder trim, while I would expect it to be the opposite. Result is: http://www.pvv.org/~titlesta/fgfs/coordination.png

Some googling shows that it's been discussed in jsbsim threads before without any big conclusions.

(My "what I find natural" reference comes from a couple of c172 and a lot of pa28 flights in real life.)

What do you think, @dany93, @onox, @Juanvvc, @tigert ?

[onox]

Why does his attitude indicator look weird? (blue/brown instead of blue/black)

[gilbertohasnofb]

@onox I also noticed that. That's the AI we use with the panel theme created by @thevirtualfer, but for some reason in that screenshot the AI is being shown with one of the HD themes I believe. I tested them in the sim just now and they seem to be working fine, so I don't know how the user managed that.

That said, I would vote to simply remove this second AI and use just the default one for all liveries.

[dany93]

Honestly, I have no clear response. At this level of demand if there is some lack of realism, we are reaching my limits in JSBSim.

(I write this like a response to alge in the Cessna 172P forum )

Thank you for your feedback

Your stick/rudder (rudder pedals I guess for a good accuracy and realism) calibration is probably not in question. I guess you know that every axis can be softened close to the center by <power type="double">2.0</power> (making it quadratic)

I (hope to) understand that your main concerns are:

• the quantitative and relative effects of p-factor, spiralling propwash effect and roll due to the propeller torque.
• the (excessive?) rudder efficiency (to finely control the slip-ball)

p-factor: It is tunable in JSBSim, however I have never really done this. The effect is rather hard to check. Anyway, if we would like to adjust it, I do not see what quantitative data we could use. That's purely guess and feeling. Fortunately, it is relatively weak for this aircraft (it would be stronger during takeoff acceleration for a tail wheel one).

Spiraling propwash effect (important effect): It is hard-coded in JSBSim (I do not know how) and, I think, qualitatively correct. Here too, there is a total lack of quantitative data for this (at least at my knowledge). Once ago, I had to code that to circumvent a lack in JSBSim, but this still was guess and feeling.

Propeller torque (effect on roll tendency) I think it is correct, resulting from a relatively simple calculation (internal in JSBSim).

Rudder and ailerons efficiency: Decreasing the rudder efficiency would be the first idea to solve your issue. But these settings (rudder and ailerons efficiency) result from the necessity to control the aircraft in crosswind takeoff and landing. Also forward slipping, which is almost the same thing. To counter a stable 20 kt crosswind, we need a bit more than 60% of current max rudder. Thus, its efficiency may only be slightly decreased, which would not change much for your issue, at the price of loosing a security margin.

The slip-skid ball sensitivity to rudder also depends on other factors, particularly the side force due to side slipping. All of these are cross-coupled, the compromises are hard to get and need numerous attempts. With, here too, no quantitative data. I do not know for the C172P, but (IRL) I've seen large differences between several ultralight aircraft models for the slip ball sensitivity.

[algefaen]

Hey, thanks for the response. I totally understand that this is hard stuff to get right in a simulator, especially when we don't have control of the internals of jsbsim. I don't think the problem is due to input issues or ball sensitivity though - that's why I tried to remove those factors with adjusting trim and showing the hud. There's a lot of factors here and it's hard to nail down individual contribution from the different sources.

I will (insh'alllah) be flying quite a few hours in a c172sp this spring - if there's any creative and practical way I can collect data for you, I could probably do that. It would be quite simple to just get a video of instruments during a trimmed climb with no rudder and/or no aileron input, for example.

[HHS81]

@dany93

particularly the side force due to side slipping

You want might look at David Megginsons page It gives much coefficients for side force then actually used in the fdm. Maybe it will help here?

I currently trying to improve the Cessna 182 fdm further, and using the real coefficients collected by David Megginson. And I stumbled about the same issues like algefaen. In the moment I can decide if want to have it able for forward slips, or not that "p-factor+slipstream vs. torque roll "-Issue.

On videos of Cessna 172/182 I have never seen any aileron input while takeoff or climb, unfortunately we can't see the rudder inputs. Maybe that would be helpful as well .

[HHS81]

@dany93 according the TCDS the rudder control movement is much to high. It is 25deg, but should be about 16deg. Could that be an explanation?

See page 14 of TCDS

[dany93]

Many thanks @HHS81 for David Megginson page! I didn't know that, very interesting. I checked a few coefficients from the FDM, they are often close to or exactly those from the table (David Megginson's FDM, of course!). When I added changes on this FDM (mainly for stall and spin) I had permanently in mind respecting, not to degrade the current FDM. It was justified...

Thank you too for the rudder movement, I hadn't noticed that. After searching, I cannot find it in the POH. I will try it and see how much it makes the control easier, and if it is enough for the crosswind landing. Because, as I wrote

To counter a stable 20 kt crosswind, we need a bit more than 60% of current max rudder. Thus, its efficiency may only be slightly decreased, which would not change much for your issue, at the price of loosing a security margin.

[HHS81]

Thank you too for the rudder movement, I hadn't noticed that. After searching, I cannot find it in the POH.

It is not in the POH, but in the Type Certification. I added a link in my previous posting.

[dany93]

Yes I've seen it and found it in your linked TCDS. But after that, I've searched for it in the POH, where it should have been, I believed. Thank you once more, sorry for the confusion.

[dany93]

Pull request https://github.com/Juanvvc/c172p-detailed/pull/722

@algefaen @HHS81

I have set the rudder angular amplitude at +/-16° (instead of +/-25°), but the rudder authority was insufficient for decrabbing with 20 kt crosswind landing. I had to slightly increase its angular efficiency to partly compensate. The final result is a small decrease (by -27%) in rudder efficiency, but only small as I wrote above. Unless there would be another set of parameters that I don't see, I cannot go below. The relevant ones (those for side force and yaw moment) are in accordance with Megginson table.

For these tests, thanks @wlbragg and @onox for the "Repair" option :sweat_smile: .

[HHS81]

...but the rudder authority was insufficient for decrabbing with 20 kt crosswind landing

@dany93 Which is, according the POH and some flight school pages ist not the best recommended landing technique for a Cessna 172.

The POH states on page 4-21: "...the wing-low method gives the best control."

A user on the cessna172club-forum has the opinion that the side-slip method is better because with crab he

" ... never sure that will have enough rudder authority to kick out of the crab and align the airplane with the runway "

The Cessna 172 Training Manual doesn't recommend the crabbing technique on touchdown as well- the nose should be put in line with rwy by lowering the wing into wind.

AOPA recommend as well the side-slip/ wing-low technique.

[onox]

So the PR decreased the maximum angle of the rudder + increased the efficiency?

From what I understand in the comments, the new maximum angle of the rudder is good. But I also read in https://github.com/Juanvvc/c172p-detailed/issues/721#issuecomment-188388092:

Decreasing the rudder efficiency would be the first idea to solve your issue.

So shouldn't the efficiency be decreased instead of increased to fix @algefaen's issue?

[onox]

Now I read this:

I had to slightly increase its angular efficiency to partly compensate. The final result is a small decrease (by -27%) in rudder efficiency

How is increasing the angular efficiency decreasing the efficiency? :open_mouth: When I look at the PR, I see the yawing moment is increased, so the rudder is more sensitive now, correct? Shouldn't the rudder be less sensitive to address @algefaen's issue (so that you need to press the pedals further)? In other words, make the value -0.06?

Note: I'm an FDM noob, so maybe I'm just misunderstanding it.

[dany93]

Hi @onox,

I've modified 2 parameters:

• maximum angle (amplitude) from +/-25° to +/-16° (16/25 = 0.64, that is -36% efficiency)
• angular efficiency, i.e. the (lateral) "lift" effect per angle unit (lateral force or yawing moment per degree of deflection of the rudder). From -0.07 to -0.08 per radian. This gives 0.08/0.07 = 1.14 that is +14% efficiency. The final result is a 0.64 x 1.14 = 0.73, that is -27% efficiency for the same amplitude on the rudder pedals command (same "normalised" deflection, whatever it is, 0.1 or 0.5 or 1). That is, less sensitive to the pilot action.

Is that OK?

After reading HHS (to who I have still to respond) and reading again the POH(s), I think I can decrease a bit more (demonstrated crosswind is 15 kt and not 20 kt as I believed). I have to check again and test it. Too early to merge it.

[algefaen]

Hi! Regarding "demonstrated crosswind", I was taught that that's what the test pilots demonstrated without any crosswind technique at all (and which did not damage the landing gear / tyres). I.e. flying in crabbed and not doing any de-crabbing. That wouldn't need any rudder authority at all, just strong legs and good shoes. A quick google search shows that this is just one of many interpretations though, so I don't know.

I feel we should be able to land our baby in up to 20kts with the correct technique.

[HHS81]

@algefaen @dany93 O.k, I just tested the c172p with max rudder angle of +/-16°; and aero/coefficient/Cndr of -0.0604. This is the lowest real value given for the c182. The value is probably not correct for the c172p, as the c182 has much higher max rudder angle (+/-26°).

Approaching crabbed and then translated into wing-low (crossed controls) in short final I managed easily direct crosswinds from left up to 20-25ktn! :smiley: On ground I run out of nose gear steering at higher wind speeds than 20ktn, but that's probably due a missing feature (the nose gear steer deg can be increased by applying left or right braking - see c182s for a possible implementation).

[dany93]

@algefaen That's the first time I read that "flying in crabbed and not doing any de-crabbing" can be done without damage. Even if it is more or less inferred in the POH, but I thought not having well understood. Every others (like HHS links) insist on the nose alignment with the runway line. For obvious reasons.

@HHS81 Thanks for the tests. I see that you finally agree on the necessity to use the crossed controls at crosswind landing. Hence on the need for a rudder with enough authority. As I've read in the POHs that demonstrated crosswind is 15 kt (and not 20 kt as I believed), I've decreased the rudder efficiency with angle from -0.08 to -0.0645 (per radian). Compared with my initial values before this discussion begins, this makes a reduction of (16°/25°)x(0.0645/0.07) = 0.64 x 0.92 = 0.59. That is -41%. I hope it will be enough for @algefaen. With these values, landing with 15 kt crosswind is a pleasure. 20 kt still possible.

As this is a compromise between crosswind landing and easiness on the rudder, I let you make your choice. For me, that was not an issue even before this discussion. If you agree on this last value, that's fine.

[algefaen]

The "demonstrated crosswind is without any technique" was something my instructor told me, but his words are by no means the law. Obviously it's a good idea to apply some kind of technique for crosswind landing, be it de-crabbing at the end or a low wing approach. (=

I still have a feeling that jsbsim gives too much roll and not enough yaw at climbout, which was my initial complaint. But adjusting these parameters locally does give less of the "my ball is skidding far to the left" problem, so maybe it was only too much rudder being applied, it's hard to know.

Thanks for spending all this time on this anyway!

[dany93]

I still have a feeling that jsbsim gives too much roll and not enough yaw at climbout

Too much roll, I don't know... That's the reaction to the prop torque. But not enough yaw seems possible in my opinion too. Once, when JSBSim had a lack, I coded some "yaw to due to propwash" to circumvent it, but that was not without drawbacks.

[HHS81]

@dany93 Maybe it would help to alter the value of this part in the FDM:

<function name="aero/function/qbar-induced-psf">
    <description> q bar including the propulsion induced velocity.</description>
    <product>
        <property>aero/function/velocity-induced-fps</property>
        <property>aero/function/velocity-induced-fps</property>
        <property>atmosphere/rho-slugs_ft3</property>
        <value>0.5</value>
    </product>
</function>

??

[onox]

The final result is a 0.64 x 1.14 = 0.73, that is -27% efficiency for the same amplitude on the rudder pedals command (same "normalised" deflection, whatever it is, 0.1 or 0.5 or 1). That is, less sensitive to the pilot action.

Okay, I get it now. I thought that you just had modified the upper bound for clipping (from 25 to 16), but the rudder-pos-rad actually changed for /controls/flight/rudder = 0.1 during testing.

[dany93]

@dany93 Maybe it would help to alter the value of this part in the FDM:

<function name="aero/function/qbar-induced-psf">

Why? What is your idea? Otherwise, the expression is correct unless the velocity-induced-fps would be wrong. qbar-induced-psf is used to take into account the propwash on the rudder and elevator authority vs their deflection (typically, with stopped aircraft or at very low airspeed, high RPM). You know, I guess.

If it is for spiralling propwash effect, I had this way for the DR400 in oct 2012 when JSBSim (or FG?) showed an error (the aircraft even steered to the right!). My first idea was to take qbar-induced-psf (or prop-induced-velocity-fps) for the yawing moment on the vertical tail. But I didn't like it and I preferred to use the thrust. I had to make its contribution decrease vs airspeed. Secondly, the rudder trim was trickier to adjust. I cancelled that as soon as this JSBSim error was fixed. Anyway, this is cheating and I do not like these ways. Just circumventing, with future drawbacks. Hours of tests, trials and errors, based on personal feeling, for something which fails by elsewhere. Beside this, people already complained that the amphibious steered too much leftwards when almost stopped, at start of rolling. Imagine if we increase the spiralling propwash effect...

[HHS81]

Well, my thought was that it might be too strong. That's why.

Myself don't have any problem with using qbar-induced-psf. JSBSim don't know the position of the rudder and elevator, so it don't know if it is affected by the propwash or not. So having this flexibility is a good thing. You don't have this possibilities with YASim.

[dany93]

I guess that by 'position' you mean the distance from the propeller or CG. The horizontal and vertical stabilizer positions can be entered in Aeromatic (Htail arm and Vtail arm) but I don't see where they are used. However, JSBSim (maybe) can estimate them from the Wing Span. I don't know how JSBSim do, but a spiralling propwash effect is rendered (steering leftwards for a clockwise propeller) by doing nothing more than default inputs. Even with p_factor=0. You are right, we do not have any possibility to adjust this effect, and using the qbar-induced-psf or velocity-induced-fps brings that flexibility.

I do not think the default JSBSim effect is too strong. But if it is, how do you do to cancel it before adding your own contribution?

[HHS81]

I guess that by 'position' you mean the distance from the propeller or CG.

Not really. There are different types of so called tailplanes. On the cessna 172 it is fuselage mounted tailplane, being in the stream of the prop. But there are also T-Tails, mounted on the fin and not being in the stream of the prop. I could test the behavior of the different types in X-plane once: a fuselage-mounted aircraft reacts with nose up/down on ground by moving the elevator when engine is running. The T-Tail aircraft not. With qbar-induced-psf or velocity-induced-fpsyou can decide which behavior the aircraft will have.

[HHS81]

@dany93 Just to remember: the value used here (angular efficiency = 0.0645) is from the Cessna 182 which has a much higher rudder deflection angle than the Cessna 172P. So due to it, it might be still too much, and the real values are probably lower.

[dany93]

@HHS81 OK for the use of qbar-induced-psf or velocity-induced-fps for the rudder and elevator behavior. It is in the C172P which reacts well on the ground by moving the elevator. At least the 160HP because I have still to 'git push' it for the 180 HP which was forgotten when the engine was added.. Thank you for your explanations.

But please, can you fix me: angular efficiency = 0.0645 value is per angle unity of deflection (per radian). For the Cessna 172P which have a lower rudder deflection angle than the Cessna 182 , I would expect a higher value for the same effect on yaw moment, each at maximum angular deflection. If both need the same maximum yaw moment, of course.

[HHS81]

@dany93

If both need the same maximum yaw moment, of course.

That's the point. Do they need? The Cessna 182 is longer and heavier, the tail is more far away from CG than the c172p. It also has more power and with that p-factor is higher. I'm not an aeronautical engineer, that's why I can't calculate if the c172p needs the same maximum yaw moment.

[dany93]

@HHS81 Thanks. I understand. I didn't ask you to give me the needed yaw moment. Rather, it was was because I had the feeling of not getting something.

About the C172P, my opinion is that it is slightly better than previously. As crosswind landing with 15 kt or a bit more is possible, I would say that's fine for this time.

[HHS81]

I understand. I didn't ask you to give me the needed yaw moment.

yep, and I never understood that you wanted me to do. :smiley: So everything alright!

But myself would have found it helpful if I could calculate it, to see how different the Cessna 172 is to the Cessna 182, and how things are really working.

[HHS81]

Glad that I could help in some way!

[dany93]

@HHS81 Sure that could help! I learnt. I discovered Megginson's table. And reflection is always good. Thank you for your responses.

[onox]

So is -0.0645 is final value for now? Or do you still want to lower it a bit? If is ok, then we can merge the PR.

@algefaen What do you think?

[dany93]

For me that's OK, at least for now. There's more loss than benefit at lowering it more. For @algefaen issue, the benefit would be insensible. Unless there would be a new way in the future, but I do not see.

[onox]

Fixed in PR #722