Modeling STICK-FORCE-PER-'g' and the effect of dynamic pressure on flight controls.

[Murmur79]

Real aircraft with reversible flight controls are designed to have a certain stick-force-per-'g'. In other words, when the pilot pulls the yoke with a given effort, the resulting g-load is at a first approximation constant, and does not depend on the indicated airspeed (provided the aircraft has not reached stall). Indeed, aeronautical regulations impose min and max stick-force-per-'g' gradients for different aircraft classes.

The existence of a fixed stick-force-per-'g' naturally comes from the effect of dynamic pressure on flight controls: at higher indicated airspeeds, a given effort on the yoke produces less elevator deflection (due to increased dynamic pressure), but a given elevator deflection produces higher g-load (again, due to increased dynamic pressure). The two effects cancel out, and the result is a fixed stick-force-per-'g'.

Now, even though common PC flight controls lack force feedback, it would be possible to model this behaviour in FG C172.

As it is now, in the simulated C172 a given flight control displacement (=a given effort, for a non-force-feedback PC flight control!) produces the same flight control deflections, at every airspeed. The result is that the flight controls become more and more sensitive, the higher the indicated airspeed. In other words, there is no such thing as a "stick-force-per-'g'" in the FlightGear C172: the same effort/displacement will produce ever higher g-loads at higher airspeeds, and this is very different to how a real aircraft feel (and to how aeronautical regulations prescribe it should feel!).

This issue is also why people often complain of the simulated aircraft being too sensitive on flight controls.

What I am proposing, is scaling down the max deflection of flight surfaces as inversely proportional to dynamic pressure. For example, the elevator could have a max deflection of 100% at the dynamic pressure corresponding to 65 KCAS, and then gradually decrease its max deflection at higher speeds (reaching 25% at 130 KCAS, i.e. a 4X increase in dynamic pressure).

This would yield a fixed stick-force-per-'g', just like a real aircraft: pull with a force of say 500gr on the joystick, and the C172 will reach say 1.5g, whatever the airspeed.

The only collateral effect would be that max flight control deflections would become progressively limited at higher airspeeds. I do not think this poses a problem: for example, in the case of elevator, the most important thing is to have full authority available at approach speeds and below (this is why I chose 65 KIAS in my example). It is however less important to have full authority at higher airspeeds, for two reasons:

1. pitch trim would retain full authority on elevator deflection at every airspeed: the limited authority would only apply to untrimmed flight control deflections;

2. at higher airspeeds, full control authority is not necessary anyway: remember that modeling a stick-force-per-'g' assures that a certain g-load can be reached anyway, at every airspeed. If you think about it, large control deflections are never used at high speeds.

Modeling this behaviour would also allow to improve another aspect of aircraft handling: in real aircraft, elevator is generally more stiff than ailerons. Indeed, regulations prescribe that the max control force on ailerons can be just ONE HALF of the max control force on elevator.

With my proposal, this could be easily simulated: e.g. make the max elevator deflection available below 65 KIAS, and the max aileron deflection available below 92 KIAS (=65*sqrt(2)). This way, at 92 KIAS and above, the deflection of ailerons for a given control force on the joystick/yoke, will be double the deflection of elevator for the same control force. Again, just like it happens in the real aircraft.

I already made all these proposed changes and experimented with them on my private FlightGear install, and they work exactly like they should. But I'm new here and I don't know what should I do now to share them with you.

[Murmur79]

Sources:

---

---

---

[wlbragg]

I think this is a great idea and I am anxious to try it out. The easiest way to get this added to the production model is to submit a Merge Request (PR) same as you did for #1471
Once you submit it I'll test it and if all is well merge it.
If that is not possible for you, you can paste the code here and I will implement it.

[Murmur79]

Sorry maybe I'm doing a mess with branches, I'm a beginner on git, but I think I created a branch #1472 with the needed changes to the code. Please note that the branch does not include the changes I described for the other issue, #1471.

Anyway, in the branch for #1472 I added the simulation of dynamic pressure for all three controls (elevator, ailerons, rudder). There is full elevator authority up to around 66 KCAS, and full aileron and rudder authority up to around 94 KCAS. This should assure sufficient control authority in all flight phases.

The main difference should be progressively less sensitive controls at higher speeds. At 94 KCAS and above, the elevator will be double as stiff as ailerons, so the aircraft should feel less sensitive in pitch but still sensitive enough in roll.

A given control force (i.e. a given joystick/yoke deflection, if the device is not force-feedback) should give approximately the same g-loading, whatever the airspeed (above 66 KCAS). So for example, in a 45 degree turn, you will need to apply the same force on the yoke, regardless of airspeed. This should mirror the behaviour of the real aircraft.

The main limitation as it is now, is that the max attainable g-load will not allow accelerated stalls at high airspeed (in a trimmed condition). This could be changed by increasing the max dynamic pressure for 100% elevator deflection (i.e. higher than the current 66 KCAS): the higher it is set, the higher the attainable g-loads at high airspeeds.

[wlbragg]

Thank you, can't wait to test this.

@dany93 I would really appreciate if you could test this as well and provide any critique.

[hbeni]

As it is now, in the simulated C172 a given flight control displacement (=a given effort, for a non-force-feedback PC flight control!) produces the same flight control deflections, at every airspeed. The result is that the flight controls become more and more sensitive, the higher the indicated airspeed. In other words, there is no such thing as a "stick-force-per-'g'" in the FlightGear C172: the same effort/displacement will produce ever higher g-loads at higher airspeeds, and this is very different to how a real aircraft feel (and to how aeronautical regulations prescribe it should feel!).

I think (from my 10 minutes at the yoke of a C182T) that it is correct that the flight controls get more sensitive with more airspeed.
The Yoke is running simple pulleys and stings, and there is no damper or so. As such a given deflection of the yoke moves the aileron a given angle.
What I experienced was that at 120 knots a light touch on the yoke already was noticeable inducing a turn, so yes it was sensitive, way more than on slow flight.

If i understand correctly, your implementation changes the notion of "yoke travel" from displacement to effort.
That is exactly what is the problem in a Sim: We lack force-feedback; because, in the real pane the pressure on the yoke is very noticeable, preventing from itself big inputs (because you instantly adapt to the felt pressure, ie. needed effort). This effort is not feelable in a sim (unless you have a force feedback joystick that would make movements harder with increased pressure).

So from my point of view: What we really need is force feedback in some good way.

---

I tried the branch and it is well flyable.

Again, my suggestion would be to make this customizable, so the user can actively disengage in the aircraft options.
I feel mouse users will have different needs than yoke/joystick users.

[dany93]

@hbeni, I completely agree with your considerations in the previous message.

[Murmur79]

I think (from my 10 minutes at the yoke of a C182T) that it is correct that the flight controls get more sensitive with more airspeed. The Yoke is running simple pulleys and stings, and there is no damper or so. As such a given deflection of the yoke moves the aileron a given angle. What I experienced was that at 120 knots a light touch on the yoke already was noticeable inducing a turn, so yes it was sensitive, way more than on slow flight.

If i understand correctly, your implementation changes the notion of "yoke travel" from displacement to effort. That is exactly what is the problem in a Sim: We lack force-feedback; because, in the real pane the pressure on the yoke is very noticeable, preventing from itself big inputs (because you instantly adapt to the felt pressure, ie. needed effort). This effort is not feelable in a sim (unless you have a force feedback joystick that would make movements harder with increased pressure).

The issue with how flight control deflections are currently modeled, is that the simulated aircraft becomes actually MORE sensitive than the real one.

I'll explain: in the real aircraft, if you pull the yoke with a force of say 3lbs, you will get say a 1.5 g-load. And this holds true (at first approximation) at every airspeed.

In the FG C172 instead, as it is now, the situation is comparable to that of a hypothetical real aircraft in which the controls DO NOT become stiffer with increasing airspeed. Imagine yourself back to flying the C182T: now suppose that the flight controls at 120 kts would be as light on the touch as they were at 60kts. You would very easily overcontrol or over-g the aircraft at 120kts! Indeed, that is exactly the reason why a stick-force-per-'g' is required by aeronautical regulations.

This is so important that even real aircraft without force feedback use the same implementation I'm suggesting here: the A320 has sidesticks (which are effectively spring joystick) and the g-load commanded by the FBW is proportional to sidestick displacement. In other words, even in an Airbus, the same effort on the controls will produce lower flight control deflections at higher airspeeds (as it happens on a real C172, as well!). That is exactly what I'm proposing here.

I tried the branch and it is well flyable.

Again, my suggestion would be to make this customizable, so the user can actively disengage in the aircraft options. I feel mouse users will have different needs than yoke/joystick users.

I agree with that. The ideal would be to have that optional in the aircraft options page. I would say though, that my modification could be useful even to users who fly with a mouse.

[hbeni]

Also, probably maybe a "nice" idea if we switched to the "effort" based yoke approach:
When on ground and we don't have pressure over the elevator, the elevator is heavy and should pull the yoke completely forward. Once airspeed is catching up, the elevator could hold itself more and more.

https://youtu.be/2go2vw1DP0A?feature=shared&t=656

[hbeni]

In other words, even in an Airbus, the same effort on the controls will produce lower flight control deflections at higher airspeeds (as it happens on a real C172, as well!). That is exactly what I'm proposing here.

Yes, what I wrote above:
Essentially you are damping control inputs because you assume a fixed force from the pilot against the yoke; whereas currently we assume a fixed travel (and thus variable needed force) from the pilot.

You can't compare an Airbus to a 172. The Airbus has no mechanical-only linkage to the flight controls. the 172 does; as such there is no damping whatsoever in the 172.
I don't want to say your approach is "wrong" or so, just point out that the current model is also "correct" in its respect; its modelled systems-wise instead of human-perspective.

[Murmur79]

Also, probably maybe a "nice" idea if we switched to the "effort" based yoke approach: When on ground and we don't have pressure over the elevator, the elevator is heavy and should pull the yoke completely forward. Once airspeed is catching up, the elevator could hold itself more and more.

https://youtu.be/2go2vw1DP0A?feature=shared&t=656

That would be nice, to my knowledge only a few aircraft in some other sims do that. But it's probably harder to implement correctly.

Note that the modification I'm proposing here, even if does not involves the behaviour of flight controls on the ground at zero airspeed, is actually an effort based one: higher airspeed = higher effort for the same control deflection. I'm strongly convinced it would be very important to implement that for a better realism in aircraft feeling. I reckon it could be made optional though as you suggested.

[Murmur79]

Yes, what I wrote above: Essentially you are damping control inputs because you assume a fixed force from the pilot against the yoke; whereas currently we assume a fixed travel (and thus variable needed force) from the pilot.

That is an inevitable compromise: pc flight controls don't have force feedback in 99.9% of cases, so you have to choose if implement a displacement based or an effort based flight control simulation.

As you said in the previous post, you seem to actually favor an effort based simulation (which is what I'm proposing).

Aeronautical regulations also give priority to effort over displacement: it's for this reason that they impose a min and max "stick-force-per-'g'", and not a "stick-displacement-per-'g'".

You can't compare an Airbus to a 172. The Airbus has no mechanical-only linkage to the flight controls. the 172 does; as such there is no damping whatsoever in the 172. I don't want to say your approach is "wrong" or so, just point out that the current model is also "correct" in its respect; its modelled systems-wise instead of human-perspective.

The analogy between the A320 and the C172 (and every other existing aircraft, actually) is that in both cases, if the pilot pulls on the flight controls with a given force, the aircraft will be subjected to approximately the same g-load, whatever the airspeed. This is so important that even aeronautical regulations prescribe it as a necessity for aircraft to be certified.

This is what I'm trying to implement in FG C172.

[Murmur79]

@hbeni my modification is basically a simplified version of what is currently used in the Extra500, from the thread you quoted in the other message:

HHS81/c182s#382 (comment)

With my mod, the C172 flight controls would work similarly to how they implemented it in the FlightGear Extra500. My mod would be a bit more simplified and easier to implement, but in flight they would work very similarly.

I agree with you that it could be made optional like it is in the Extra500.

[wlbragg]

my suggestion would be to make this customizable

I really need more education to debate the merits of this modification, but I like this enhancement. I agree we need to make it opt-in as two out of three people in this discussion are cautious about mandating a change like this. Making it opt-in solves any dispute in philosophy at really no cost. So I will add the opt-in to the Simulation Options gui.

Also, probably maybe a "nice" idea if we switched to the "effort"

I want to try to implement this. I really like the idea. I think the same type of table adding in the pressure per IAS (or whatever the best indicator would be) to the elevator control property but keeping the ability to override this pressure the same as we do with an autopilot that can be overridden with control input. Anyone want to take this on? If not I might try my hand at it.

[Murmur79]

I want to try to implement this. I really like the idea. I think the same type of table adding in the pressure per IAS (or whatever the best indicator would be) to the elevator control property but keeping the ability to override this pressure the same as we do with an autopilot that can be overridden with control input. Anyone want to take this on? If not I might try my hand at it.

It's not trivial, because you need to model 3 different hingemoments acting on the elevator:

.hingemoment due to the pilot/autopilot pulling or pushing the yoke (can be considered proportional to joystick deflection);
.hingemoment due to elevator weight (proportional to normal g-load);
.hingemoment due to aerodynamic pressures: this is the most complex to model, and it would depend on dynamic pressure, elevator deflection, trim tab deflection, and angle of attack. In theory, it could also depend on flap deflection (which changes wing downwash over elevator).

So, it wouldn't be easy to model in an "engineering accurate" way, for a lot of data is needed, but maybe it could be done in a simplified way, in order to get the basic effect of elevator drooping down on the ground at zero or low airspeeds. I'm willing to help with that, if you want to go forward.

[wlbragg]

but maybe it could be done in a simplified way

Yes, absolutely. You could add it to this PR as it is in the same realm.

While your at it, if you add a conditional to this "stick-force-per-'g'" code (a new property), I will add it in the set file property initialization and make the choice available in the GUI.

[hbeni]

I give that some more tought, and from what i have tested, mouse flying is absoluteky a go here.
So I would suggest, that we may debate a little bit more wether this might be a candidate for opt-out (making it „on“ as default). Joystick users will benefit out-of-the-box from it, whereas mouse users arent harmed much 😅

[hbeni]

C182 could also benefit from this Implementation.
I opened a ticket there.

[Murmur79]

I give that some more tought, and from what i have tested, mouse flying is absoluteky a go here. So I would suggest, that we may debate a little bit more wether this might be a candidate for opt-out (making it „on“ as default). Joystick users will benefit out-of-the-box from it, whereas mouse users arent harmed much 😅

Great! I'm sorry if I've sounded a bit "pushy" with my explanations. Your observations were appreciated! Indeed your link to the Extra 500 gave me new ideas for the elevator drooping effect.

While your at it, if you add a conditional to this "stick-force-per-'g'" code (a new property), I will add it in the set file property initialization and make the choice available in the GUI.

I'll try to work on it tomorrow. Maybe I have some ideas on how to implement it in an easy way.

[hbeni]

Great! I'm sorry if I've sounded a bit "pushy" with my explanations. Your observations were appreciated! Indeed your link to the Extra 500 gave me new ideas for the elevator drooping effect.

The problem I had when thinking about to implement this was, that the sim is unable to have a sense of when the pilot has the yoke grabbed and when not. With a mouse this is not distinguishable from the sim's perspective, and with a joystick this holds true also.
so my idea was to drop the yoke as a follow-on action to the removal of the wind gust lock, and then let it alone.
(again, because we don't have force-feebdack and also no simulation of the friction of the pulleys/strings etc)

[dany93]

Sorry, probably my lack of knowledge, but I can't have access to the #1472 branch by the github procedure.

I did a git clone [email protected]:Murmur79/c172p.git,
By

git remote show origin
* distant origin
  URL de rapatriement : [email protected]:Murmur79/c172p.git
  URL push : [email protected]:Murmur79/c172p.git
  Branche HEAD : master
  Branches distantes :
    #1471  suivi
    #1472  suivi

I see the #1472 branch, but I have access only to master.
git checkout #1472 changes nothing: I only have the master content.

git checkout #1472
Your branch is up to date with 'origin/master'.

Please, can @Murmur79 create a branch in the https://github.com/c172p-team/c172p github repository?
This is the second time I have this problem at importing a branch from an external repository. It is a mess, usual procedures don't work, I don't know why.
I had no such problems after cloning the c172p and J3Cub repositories, I'm wondering where the difference is...

[hbeni]

@dany93 try this (in your "normal" 172p repo clone):

# Add a new remote called "Murmur...."
git remote add Murmur79 [email protected]:Murmur79/c172p.git 

# fetch the remote state
git fetch Murmur79         

# Checkout the remote branch for investigation (pick one of the two commands)
# git checkout Murmur79/#1472       # checkout the branch (detached head)
# git checkout -t Murmur79/#1472    # checkout the branch (creates an actual local tracking branch)

# to verify you actually see the changes you expect
git log                                            

---

Doing it like this saves you from your mess and clearly lets you separate the origins of remote repos.
And it makes merging etc easy.
I have this at the moment:

beni@segin:~/workspace/fgfs/c172p-git$ git remote -v
Murmur79        [email protected]:Murmur79/c172p.git (fetch)
Murmur79        [email protected]:Murmur79/c172p.git (push)
origin  ssh://[email protected]/hbeni/c172p.git (fetch)
origin  ssh://[email protected]/hbeni/c172p.git (push)
upstream        https://github.com/c172p-team/c172p.git (fetch)
upstream        https://github.com/c172p-team/c172p.git (push)

upstream is this repo here
origin is my github fork (where i push my changes and make PRs from)
Murmur79 is like described above. Usually I clean out my remotes after a while when all related work was finished.

This works pretty well so far.
My only pitfall is always that i forget the -tswitch for the checkout, so i get a "detached head"; but if you just wanna peek that is perfectly OK.

[dany93]

Thank you very much @hbeni for this detailed explanation. It works perfectly, and the procedure is very easy to follow. Once we have it...

For my understanding if it is not too much, can someone explain me why a "normal" git clone procedure does not enable getting the branch contents (apart from master)?

[hbeni]

For my understanding if it is not too much, can someone explain me why a "normal" git clone procedure does not enable getting the branch contents (apart from master)?

Because with cloning you probably only get the "main" branch configured for that repo.

[Murmur79]

The easiest way to implement this with consistent results would be like that:

1. an equation to calculate the aero hingemoment (as a function of trim tab setting, dynamic pressure and control deflection); Roskam data contains the needed coefficient, so it can be made quite accurate;

2. an equation to calculate the unbalanced weight hingemoment (as a function of normal and axial g-loading and control deflection); this must be estimated by trial and error and flight tests; will determine how fast or slow the elevator will rise up during takeoff roll;

3. an equation introducing a very weak spring-centering force: this is a little fudge needed to assure consistent behaviour when dynamic pressure is zero, or when the flight control has no unbalanced weight (e.g. rudder in level flight, or ailerons);

4. from 1, 2 and 3 impose a total hingemoment of zero and calculate the resulting control deflection;

5. add the control deflection due to pilot action (this depends on dynamic pressure, and is what I already coded for this branch);

6. clip the resulting deflection to [-1;1].

This method should assure consistent results in any flight phase, with no unwanted side effects.

Now it only needs to be coded... 😬

[Murmur79]

The problem I had when thinking about to implement this was, that the sim is unable to have a sense of when the pilot has the yoke grabbed and when not.

This is a valid concern and necessitates some type of compromise. In the implementation I described above, it would work like that:

when the aircraft has zero airspeed on the ground and the joystick is centered, the elevator will droop down, as if controls were not grabbed; but the pilot can still move the elevator with his joystick/yoke/mouse: in other words, it would work very similar to how it works now when the aircraft is stopped on the ground and you trim the nose all the way down.

[dany93]

My current thinking, which has already been written by @hbeni and @Murmur79 in this issue.

• Murmurs79's proposal is a circumventing to pretend a force feedback JS.
  The force feedback is replaced by a displacement feedback (which in fact also gives a greater force a the end of the JS travel) at the price of a lower control efficiency.
  Advantage: the aircraft is softer in cruise flight, easier to control. Very probably a more realistic feeling in "normal" flight. It will satisfy people who complain against brutality (too sensitive).
  Drawback: We loose the possibility of applying over-g accelerations or stalls, such as in too brutal pitch up or too steep turns at high or moderate airspeed. Not to be done on purpose in reality, but it can (and does) happen.

• A force feedback joystick is the only solution, but it is excessively difficult or impossible to simulate for a usual JS. Compromises are inevitable.

If the feature is optional, the decision is much easier to make.

[wlbragg]

@hbeni do you know what the difference is between your solution for @dany93 to get the 1472 and this one below?
@dany93 I looked at the instructions under the "command line instructions" link, to the right of the #1472 "Merge pull request" button.

git checkout -b 'Murmur79-#1472' master
git pull https://github.com/Murmur79/c172p.git '#1472'

[dany93]

@wlbragg I tried your procedure and it didn't work.
I had the master content, I could see the branches in the list, but the git checkout #1472 gave nothing else than the master content.

I read (was it the cause ?)

However, the following steps are not applicable if the base branch is protected.

Or I missed something...

[wlbragg]

@dany93
This is probably my total ignorance with git foo. I think doing it per the instructions on GitHub is giving me a totally independent git repo of Murmur79-#1472 branch, not connected in any way to the main git repo other than it was cloned from the origins main branch. I think @hbeni git foo was merging in the remote Murmur79-#1472 branch beside the main master branch so you can access either, which is what you were looking for in the first place.

Because the later instructions says to check out master, merge Murmur79-#1472 and push to origin master which would overwrite origin master. Thus the warning about "protection".

After I used the instructions I posted I had Murmur79 repo and then was able to switched from Murmur79 repo master to Murmur79-#1472 and test.

[Murmur79]

Drawback: We loose the possibility of applying over-g accelerations or stalls, such as in too brutal pitch up or too steep turns at high or moderate airspeed. Not to be done on purpose in reality, but it can (and does) happen.

I thought about that. This could be mitigated by increasing the max speed for max deflection. With the parameters I used (limited elevator deflection starting above 65 KIAS), the pilot can pull around 2.5g max at high airspeeds.

But if we change that speed from 65 KIAS to e.g. 85 KIAS, max pull would increase to 4.3g, which should already be above max structural g-limit for the C172. And stall would still be possible at most airspeeds.

My preference would be some middle ground, e.g. using a reference speed that allows stalls at normal airspeeds (up to steep turns in cruise), even if it won't allow over-g (3.8g in the C172, I think?)

Certainly making it optional is the best idea.

I've been busy these last days, I'll try to code something soon.

[wlbragg]

I've been busy these last days, I'll try to code something soon.

@Murmur79 don't worry about rushing on this, we all work at our own pace which is dictated by our personal and professional lives. None of us are in any hurry to get things done. This is a "do at your own pace" zone.

[hbeni]

Re: #1472 (comment)

@hbeni do you know what the difference is between your solution for @dany93 to get the 1472 and this one below? @dany93 I looked at the instructions under the "command line instructions" link, to the right of the #1472 "Merge pull request" button.

git checkout -b 'Murmur79-#1472' master
git pull https://github.com/Murmur79/c172p.git '#1472'

Just another way to do the same. Seems to be shorter, thanks :) And allows better control over the local branch name. Need to memorize this :)

EDIT: Ah, found the difference.

• The way I do it usually gives me a "remote tracking branch", which means It is connected to that other repo. This allows me to just git pullin that branch to get remote updates.
• The other way just pulls remote content into a local (but not tracking) branch. You need to again give the remote repo, or add branch tracking information manually.

[hbeni]

Re: #1472 (comment)

Talking about stall, also tests for spin characteristics should be conducted. It should be doable to break a spin stall.
And again, extensive tests for the autopilot should be done!

[Murmur79]

I'm realizing I've not enough knowledge of JSBSim to fully implement what we want to do.

But I have a plan on how it should be done, and I already wrote all the necessary equations. Is there anybody available to help me with coding them in the c172p.xml? Also, I don't know how the conditionals etc. work in order to make it opt-in/out, so if someone else who's more experienced with coding for JSBSim could help me, I think this could be done relatively quickly.

The basic equation to implement would be this:

delta_e = [ (M_e * d * g * n) - (C_h_de * q * S_e * c_e * delta_trim) ] / [ -C_h_de * q * S_e * c_e + k ]

where:
M_e = elevator mass (to be estimated)
d = distance between elevator hinge and elevator c.g. (to be estimated)
g = gravity (internal FG property)
n = normal g-load (internal FG property)
C_h_de = hingemoment coefficient (-0.585, from Roskam data)
q = dynamic pressure (internal FG property)
S_e = elevator area (14.53 ft2)
c_e = elevator chord (1.3 ft, estimated from 3-views)
delta_trim = trim elevator angle (internally it's -1/+1, but in the formula it should be translated in radians, i.e. -0.4887 (-28 degrees nose up) to 0.4014 (23 degrees nose down))
k = dummy return spring constant (ft*lbs/rad), could be very weak; its only purpose is to ensure consistent behaviour at low or zero dynamic pressures.

Once delta_e (i.e. the elevator deflection due to elevator weight + aerodynamic trimming forces) is calculated, we map and clip it back to [-1;+1] and add the "fcs/elevator-cmd-norm-gain" (which depends on dynamic pressure), which I already coded in my previous commit.

[Murmur79]

In case going "the full monty" would be too hard to do, or if there isn't anybody willing to tackle it, I'm hoping at least the STICK-FORCE-PER-'g' I already implemented could be considered for a future release. I could do some more flight tests as suggested above and easily tune it if needed, and then just add the conditionals in the code so it could be made opt-in. We would lose the elevator drooping on the ground (which is mostly aesthetic and not really important for aircraft handling), but the important stick-force-per-'g' feature would still be there, and allow a less sensitive aircraft at higher airspeeds.

[wlbragg]

The conditional portion will be easy to implement, I guess I'd have to see exactly where and how the new FDM logic is enabled in order to suggest the conditional method to use as I can think of a couple ways it could be done in the FDM section.

[dany93]

@Murmur79 wrote

The basic equation to implement would be this:
delta_e = [ (M_e * d * g * n) - (C_h_de * q * S_e * c_e * delta_trim) ] / [ -C_h_de * q * S_e * c_e + k ]

For the equation, see JSBSIM Reference Manual, 2.5 Math, 2.5.1 Functions.
Possibly slightly heavy to write in xml.
This being said, I think that inflating the codes and spending time with this is not worth taking into account the low importance of this feature. Nobody will notice.

[dany93]

@Murmur79
About the bogus stick force per g, the reduction in control efficiency may be a problem for the aircraft ceiling. This point needs to be checked.
This feature comes down to introduce a non-linearity for surface controls. I've always been very reluctant to do this, as no aerodynamic justification has been provided.

[Murmur79]

For the equation, see JSBSIM Reference Manual, 2.5 Math, 2.5.1 Functions. Possibly slightly heavy to write in xml. This being said, I think that inflating the codes and spending time with this is not worth taking into account the low importance of this feature. Nobody will notice.

I actually concur with you. The thing I consider most important is the flight control stiffness as a function of dynamic pressure ("fixed stick-force-per-'g'") which I already coded. And it only required adding a single table in xml, so very straightforward.

I wanted to add the elevator drooping because @wlbragg seemed very pleased with that feature 🙂 but I'm realizing it's significantly harder to code, and indeed it's mostly aesthetic and limited to the beginning of the ground roll, whereas the "fixed stick-force-per-'g'" feature has more concrete effects in aircraft handling.

@Murmur79 About the bogus stick force per g, the reduction in control efficiency may be a problem for the aircraft ceiling. This point needs to be checked.

Hmm... I don't see any reason it would have an effect on aircraft ceiling. Even with my modification, using the elevator trim always allows full control authority. E.g. if elevator trim is set to full nose-up, the elevator will be at max deflection, even with joystick centered (as it is now). Notwithstanding that, max ceiling is reached at a speed around L/D max, so with elevator around the center/neutral, far from full nose-up or -down. I'm willing to do the required flight tests though.

This feature comes down to introduce a non-linearity for surface controls. I've always been very reluctant to do this, as no aerodynamic justification has been provided.

From a different point of view, it could be argued that my feature actually adds linearity between applied force and produced g-load: as it is in real aircraft, and as dictated by regulations. The justification is the increasing dynamic pressure makes flight controls stiffer. In other words, this feature waives displacement linearity to embrace force linearity. Due to limitations of PC flight controls, giving up either is a necessary compromise. In theory, my modification would yield an aircraft whose handling and feel is closer to the real one, with the only compromise of not being able to over-stress it at high airspeeds.

I think making it opt-in would not cause issues. If you have flight tests in mind that you think could produce unfavorable results, let me know and I'll do them.

[dany93]

@Murmur79 wrote

the flight control stiffness as a function of dynamic pressure (...) it only required adding a single table in xml, so very straightforward.

For this contribution, I agree.

Even with my modification, using the elevator trim always allows full control authority. E.g. if elevator trim is set to full nose-up, the elevator will be at max deflection, even with joystick centered (as it is now)

You are right, sorry. I hadn't thought at the trim which does not decrease in your code with dynamic pressure.

I think making it opt-in would not cause issues

I agree (as I already wrote).

[wlbragg]

I think making it opt-in would not cause issues.

I think that has always been my preference and easy enough to do.

I wanted to add the elevator drooping because @wlbragg seemed very pleased with that feature 🙂 but I'm realizing it's significantly harder to code, and indeed it's mostly aesthetic and limited to the beginning of the ground roll, whereas the "fixed stick-force-per-'g'" feature has more concrete effects in aircraft handling.

All true, but if you can do this, it will be a unique feature that is yet one more visually accurate simulation feature. But it is certainly your choice to attempt it or not.

Something like the elevator drooping until the air flow raises it is a visual that might actually get noticed in playback videos, especially if added to the replay system.

I do have a question about this though.
Modeling it using a physics equation like this and actually tied to the yoke and elevator position and influencing the airstream, wouldn't this feature actually change a, hands-off, takeoff roll out and the effect of taking your hands off the yoke in an untrimmed flight profile? Does the default position we leave or have the elevator in currently accurately reflect what to expect in a real aircraft? I'm thinking, it would be impossible to leave your hands off the yoke and have the elevator raised at all when idle on the runway. Or to have your aircraft in a climb or dive without elevator trim and take your hands off the yoke, what should happen, I can't imagine without airflow over the elevator being modeled into its actions on the entire system would not yield accurate results. I'm explaining this poorly, but I hope I am getting the point across. Airflow on the elevator at any given angle and speed does not only affect the attitude of the aircraft, it would certainly affect the position of the elevator with a hands off approach. This is not currently modeled as of now? What I am asking is, is this not only influencing the elevator on the ground, but it should be influencing it at all times when the airspeed is enough to apply enough pressure to cause the elevator and yoke to move?

[hbeni]

I think the dropping should - if we decide we want it - be very simply just simulate that drop just in the moment the gust lock is released.

Very certainly we do not want to simulate „no hand ob the yoke“ in other moments.
So i would just do a nasal listener calling interpolate on the yoke position.
But that just works whithout joystick i guess.

[wlbragg]

Very certainly we do not want to simulate „no hand ob the yoke“ in other moments

I guess my question is, why not? I suppose it is impossible to distinguish if the user is holding the yoke or not? So how do you know when the user is applying force, we're back to force feedback, yes?
OK then, if we can't use this equation to model this behavior at all times effectively without force feedback, then I am back to my original thoughts on it which are similar to @hbeni, it probably is only worth doing it in a visually pleasing pseudo coding, such as until the airspeed is sufficient to raise it, same as we do to close the doors if you leave them open. Or only to drop it once the gust lock is released. A full featured equation may be entirely overkill if we can't use it in all flight envelopes.

[Murmur79]

All true, but if you can do this, it will be a unique feature that is yet one more visually accurate simulation feature. But it is certainly your choice to attempt it or not.

Something like the elevator drooping until the air flow raises it is a visual that might actually get noticed in playback videos, especially if added to the replay system.

Airflow on the elevator at any given angle and speed does not only affect the attitude of the aircraft, it would certainly affect the position of the elevator with a hands off approach. This is not currently modeled as of now? What I am asking is, is this not only influencing the elevator on the ground, but it should be influencing it at all times when the airspeed is enough to apply enough pressure to cause the elevator and yoke to move?

That's a sharp observation, I've also pondered over it.

Indeed, the effect of the unbalanced weight of the elevator on the real aircraft, should be to bias the commanded pitch trim to be a little more down that it would be (if the elevator were balanced). Also, the bias would increase with decreasing dynamic pressure, so the net effect should be that the stick-free stability of the aircraft should be a little higher if the elevator is unbalanced, than if it were not.

But I see multiple problems with trying to model this:

1. It is hard to model in an accurate way without having access to detailed data (hingemoment due to unbalanced weight of the elevator);
2. Its effect is likely very minor: at flying speeds, the aerodynamic forces are order of magnitudes higher than the weight of the elevator;
3. For all we know, its (minor) effect on stability and flight dynamics could already be included in the aerodynamic coefficients gathered from flight tests and used for the C172 flight model.

[Murmur79]

OK then, if we can't use this equation to model this behavior at all times effectively without force feedback, then I am back to my original thoughts on it which are similar to @hbeni, it probably is only worth doing it in a visually pleasing pseudo coding, such as until the airspeed is sufficient to raise it, same as we do to close the doors if you leave them open. Or only to drop it once the gust lock is released. A full featured equation may be entirely overkill if we can't use it in all flight envelopes.

It could be done in a simplified way, e.g. with the elevator gradually rising to its trimmed position once a certain minimum airspeed is reached. It would be just a visual thing though.

[Murmur79]

Well, now that's interesting for the matter at hand. Apparently, even when stationary and with engine at idle, the propwash is already enough to move the elevator all the way nose up or so, if trim is used! (The aircraft in the video should be a C150 though):

https://www.youtube.com/watch?v=Kz8tj9W78mY

[Murmur79]

Ok, better keep it simple.

I updated the c172p.xml in my #1472 branch.

I just increased by 20% the max dynamic pressures for max control deflections, for elevator, ailerons and rudder. So in this update the flight controls should remain a bit more effective throughout all the speed regimes.

Compared to the default c172p, this aircraft will feel progressively less sensitive with elevator above 73 KCAS, and progressively less sensitive with ailerons and rudder above 103 KCAS.

So, the pilot will keep full control authority at approach speeds and below. Also, full rudder authority is retained below 103 KCAS, and sideslipping approaches can be made as usual.

Full joystick/mouse deflection should give 3g's and some more at speeds above 90 KIAS, which should be plenty for normal flight maneuvers.

I also increased the tables resolution.

If someone would like to add the needed code changes to make it opt-in, you can do it (or give me some hints on how it could be done).

[hbeni]

Hi, sorry for not giving feedback for so long.

If someone would like to add the needed code changes to make it opt-in, you can do it (or give me some hints on how it could be done).

That is an easy task, just add a switch that selects the qbar value to be used given on the users setting.

• The setting should be defined in the c172p-main.xml at a suitable place like <stick-force-per-g> type="bool">false</stick-force-per-g> ( I propose somewhere at the fdm/jsbsim/fcs/ subnode; line 1221:

            <fcs>
                <yaw-trim-cockpit type="double">0.0</yaw-trim-cockpit>
                <stick-force-per-g type="bool">false</stick-force-per-g>
            </fcs>

(i advise to keep it opt-in for now)

• then, at the FDM you can switch on that:

            <switch name="fcs/stick-force-per-g-qbarUW-psf">
                <default value="0"/>
                <test logic="OR" value="aero/qbarUW-psf">
                   fcs/stick-force-per-g EQ 1
                </test>
            </switch>

• and finally use the result of the switch instead of aero/qbarUW-psf. <independentVar>fcs/stick-force-per-g-qbarUW-psf</independentVar>

• For better UX experience, the prop should be added to the gui and also as savestate property.

---

ℹ️ I did all this for you in my copy, see hbeni@5ba720c
(my repo ar github, branch #1472: https://github.com/hbeni/c172p/tree/%231472
Basicly you should be able to just pull in my commit to your branch.

[hbeni]

And something else for discussion:
Maybe this should also be handled in flightgear istself? I assume, this is nothing C172 special and affects all planes (at least the "simple" small piston ones)

[Murmur79]

Hello, thank you for the reply. Unfortunately I'm busy over other things now, and being that I'm a complete noob on coding and github, I don't even remember how to do things here. But I've checked the modifications in your #1472 branch (thank you a lot, much appreciated!!!) and they look fine to me. If you are able to finalize this thing yourself without my intervention, you can do it.

Regarding implementing this in flightgear itself: yes, it would fit with most non-FBW aircraft (and certainly with all GA aircraft), but the problem is that the parameters should be set per-aircraft. Specifically, the dynamic pressure below which full control deflection is available, should be set at or above typical approach speeds of a given aircraft, in order to keep full control authority during the approach and landing phase.