c172p
c172p copied to clipboard
c172p-team
Modeling STICK-FORCE-PER-'g' and the effect of dynamic pressure on flight controls.
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:
-
pitch trim would retain full authority on elevator deflection at every airspeed: the limited authority would only apply to untrimmed flight control deflections;
-
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.
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.
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.
Thank you, can't wait to test this.
@dany93 I would really appreciate if you could test this as well and provide any critique.
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.
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.
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
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.
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.
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.
@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:
https://github.com/HHS81/c182s/issues/382#issuecomment-778633617
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.
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.
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.
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.
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 😅
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.
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)
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...
@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.
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)?
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.
The easiest way to implement this with consistent results would be like that:
-
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;
-
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;
-
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);
-
from 1, 2 and 3 impose a total hingemoment of zero and calculate the resulting control deflection;
-
add the control deflection due to pilot action (this depends on dynamic pressure, and is what I already coded for this branch);
-
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... 😬
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.
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.
@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'
@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...
@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.
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.