Elevator surface should not move while trimming on the ground

[gilbertohasnofb]

The elevator trim tab will affects the position of the elevator only if there is enough air flow, i.e. it depends on the airspeed. So while on the ground there should no movement to the elevator surface due to trimming, but in-flight the animation of the elevator should get affected. In order to achieve that one would have to limit the max position change of the elevator surface as being proportional to airspeed.

For more info, see discussion here: #992

[dany93]

The https://github.com/c172p-team/c172p-detailed/pull/992 issue has too many messages and github hides many of them. Particularly, this important (and difficult to write) one has become almost impossible to reach from within the discussion, even from its hyperlink. As I would not want it to be lost, I make a second copy of it here.

@wlbragg, My current understanding on the trim effect on elevator deflection in FG. (if it can help at least in its great lines and to be confirmed)

Internal Properties, [interval] /elevator [-1, 0, +1] whatever elevator-trim /elevator-trim [-1, 0, +1]

/fdm/jsbsim/fcs/elevator-cmd-norm [-1, 0, +1] whateverelevator-trim

/fdm/jsbsim/fcs/pitch-trim-cmd-norm = elevator-trim [-1, 0, +1]

Calculated in the FDM (lines from 674, <flight_control name="FCS: c172">)

(/fdm/jsbsim/fcs/) elevator-cmd-norm + pitch-trim-cmd-norm, clip to [-1, +1] ==> =pitch-trim-sum

pitch-trim-sum is limited inside [-1, +1], and affected by the elevator-trim value, which gives a zero offset due to trim and cuts the amplitude on one side of the interval.

If X = elevator-trim value, the pitch-trim-sum interval is [-1+X, X, 1], the central value X being taken for elevator = elevator-cmd-norm = 0 The trim effect is that one end of the interval is no longer reached, and we have an offset for elevator = 0 Example : elevator-trim = +0.3 ==> pitch-trim-sum interval is [-0.7, 0.3, 1], with 0.3 for elevator = 0 = elevator-cmd-norm

After that, pitch-trim-sum is converted into degrees [-28, +23 for trim = 0], radians, elevator-pos-norm. Like pitch-trim-sum, these last ones are affected by the trim offset.

Currently, the used quantity is connected to elevator-pos-norm (or -deg or -rad) for the FDM and elevator animation. It should not be changed for the FDM.

Elevator Animation: If you wish to modulate the trim effect seen on elevator vs airspeed (seen trim effect between 0 at rest and full effect at moderate to high airspeed), I think that the starting quantity is pitch-trim-cmd-norm = elevator-trim Create a property animation-pitch-trim-cmd-norm = pitch-trim-cmd-norm x K, with K between 0 (at rest) and 1 (with airspeed). To be added to elevator-cmd-norm for the elevator animation (in replacement for pitch-trim-cmd-norm used by the FDM). Maybe clip the sum inside [-1, +1] or the corresponding degrees. Which gives, for the animation elevator-cmd-norm + pitch-trim-cmd-norm x K, clip to [-1, +1]

Thus, the elevator deflection seen would be elevator-cmd-norm at rest (usually expected value), and elevator-cmd-norm + pitch-trim-cmd-norm in flight. Although I'm not sure about surface-positions/elevator-pos-norm (=pitch-trim-sum and used for the animation).

Hard to explain... Please tell me if mistakes or unclear.

I'm wondering how many users notice this anomaly in the elevator animation vs trim...

[gilbertohasnofb]

@dany93 Thank you so much for the message above, it's always disheartening to open an old thread with over 150 messages of which only a few might be relevant. I really appreciate it.

[dany93]

Some messages linked to this subject:

https://github.com/c172p-team/c172p-detailed/pull/992#issuecomment-369549067 https://github.com/c172p-team/c172p-detailed/pull/992#issuecomment-369551181 https://github.com/c172p-team/c172p-detailed/pull/992#issuecomment-369557362 https://github.com/c172p-team/c172p-detailed/pull/992#issuecomment-369596454 https://github.com/c172p-team/c172p-detailed/pull/992#issuecomment-369640834 https://github.com/c172p-team/c172p-detailed/pull/992#issuecomment-369645751 https://github.com/c172p-team/c172p-detailed/pull/992#issuecomment-369933270 --> How The 4 Types Of Trim Tabs Work

https://github.com/c172p-team/c172p-detailed/pull/992#issuecomment-370158266 --> detailed FDM + animation point of view (same as copy above). https://github.com/c172p-team/c172p-detailed/pull/992#issuecomment-371109188 --> a summary

[okroth]

Ahem, actually the trim tab balances the hinge moment of the elevator - sufficient air flow given. Both forces are proportional to speed squared; just with too low speed the balance weight of the elevator dominates. In reality, the elevator is not the mixed signal of yoke pitch and trim as it is in the C172 flight model, or any RC airplane model. The elevator is linked directly to the yoke; only when the yoke moves, the elevator does too. The trim tab changes the neutral force point.

[legoboyvdlp]

It should be possible to calculate a hinge moment then, and add that to the yoke input. That would be a significant change to how the flight controls work though and might not work as well as I think.

Ideally, the 3D yoke would move unless you have input in, at which point we assume you are holding it and move it smoothy to the commanded position.

[wlbragg]

Quick cheat... You know, I got to thinking about this and it may be as simple as using new and independent properties to drive the animation and then putting a condition on the fdm portion that requires, say, airspeed or whatever before the fdm effect takes place. But for sure it should be possible to have the fdm components use the trim amount to influence the elevator. It seems like a simple problem.

[okroth]

If you multiply the trim-cmd-norm with q-bar and some constant that normalises it to 1 at max Va you will get what you need: speed dependent trim flap influence. One could compute hinge moments, but as the user's input is not force but position, you can't add them directly. It needs a force feed back system to do that (I am building such a thing)

[legoboyvdlp]

If the user input was mapped to be force instead of the actual yoke position it would work... That would definitely need to be an option though, as it would be a significantl change.

[okroth]

Yes that would work. Only that the force on the stick / yoke / rudder is proportional to movement and squared airspeed, which is not modelled in standard joysticks / yoke devices. One can easily add a force feed back system in the (JBSim) FDM and use the output values to feed a FFB joystick.

[dany93]

@okroth wrote

If you multiply the trim-cmd-norm with q-bar and some constant that normalises it to 1 at max Va you will get what you need: speed dependent trim flap influence.

I agree for the animation. This message (see "Elevator Animation").

But be careful not to decrease the elevator trim influence in the FDM at low airspeed. In FG, the trims are a cheating which makes them behave differently from reality. This message again. Setting a trim value comes to offset the elevator position (which is limited to +/-1) for any joystick position. In particular for the "0" JS position of course.Thus, when one adds a pitch up trim value, the pitch up effect of the elevator at full joystick amplitude is reduced. Full trim ==> no joystick effect is left even at full joystick deflection. Decreasing the elevator trim influence at low airspeed will need more trim to balance the aircraft in flight, which will worsen the effect drawback.

The force feedback emulation with ordinary JS is a difficult problem. I have already seen such an attempt in FG but it didn't give the expected effect. I'm even wondering if that can be done (in fact, I doubt it can be).

[tigert]

The interesting thing is also that the weight of the elevator is pulling the yokes fully forward when the plane is parked in the ground without engine running.

When you start the engine, the airflow pushes the elevator, but not as much as to center it. You can see and feel the vibration though. This is why you should hold the yoke to avoid damage to the elevator after you start, and even before starting well as when the weather is gusty, once you remove the control lock pin.

When you do the engine run-up at 1700 rpm, that is enough to center it though, and you really need to hold the yoke or the turbulent airflow will rattle things around a lot.

This all is a bit difficult to model though, as most joysticks have centering springs, which more or less have the same effect as if you would just hold the yoke centered with your hand. There are some add-ons for MSFS and Prepar3D that use a force feedback joystick to implement this as well as the elevator trim feel.