Roll-Yaw cross-coupling in a hover?

[Simon853]

Further to my recent post about simulating LTE on a computer, I'm trying to address the almost absolute lack of cross-coupling in Microsoft's Flight Simulator. Perhaps someone could help me out here:

If a conventional helicopter is sat in a hover and it is rolled to the left or right, is there any cross-coupled yawing motion? I have Padfield's book on helicopter flight dynamics and he doesn't seem to describe one.

I'm assuming that if the helicopter rolls then the mass of the tail would either add to or subtract from the force generated by the tail rotor. But then again if the weight is distributed evenly fore and aft of the main rotor shaft then this should be nullified. In reality this is unlikely to be the case, with the weight simply distributed within CofG limits though, right?

Essentially I'm trying to identify all (well a few anyway) the factors, both mechanically and pilot-induced that result in hovering instability. (Microsoft seem to tune their flight model to behave like a one of those self-stabilising polystyrene remote controlled toy helis and I'm looking to augment the dynamics to unsettle it in a realistic manner.)

Thanks,

Si

[Matthew Parsons]

Simon, there probably is some amount of roll-yaw cross coupling in the hover, but size and magnitude would depend on type. However, I would be surprised if it's ever much of a concern because you don't normally need large roll angles or roll rates when hovering (there are a few exceptions). What is a concern is the yaw due to the lateral velocity that a roll angle will eventually generate.

[NickLappos]

Simon,

The typical roll as a function of anti-torque thrust is evident, so that an OGE hover might have 1 degree more roll than an IGE, and a light weight hover as much as 1.5 degrees less due to the change in MR power and the ensuing change in anti-torque thrust to trim the helo.

For gentle yaw rates, the roll coupling is very low, mostly because the amount of thrust change to produce small yaw rates is very low, the moment arm for the TR in yaw is large, and the yaw rate damping is nil in a hover, so the thrust is only momentarily higher than trim.. For rapid yaw turns the roll contribution is substantial, but these are almost never used except in airshow maneuvers.

Roll is big in high speed lateral flight, due to both TR thrust and fuselage drag, of course.

[[email protected]]

Simon - if you can find a way of increasing the rate of disc response to cyclic input you will succeed in producing a less stable hover; this is the reverse of what a stabilisiation system does on appropriately equipped helos - it just smooths the pilots inputs by damping the rate response.

[Bertie Thruster]

I'm looking to augment the dynamics to unsettle it in a realistic manner

Why not augment the MS wind speed and direction algorythm? Countering natural variations here is, after all, probably the main task of the pilot while maintaining a stable hover in height and heading against a fixed datum.

[NickLappos]

The best way to make the model seem "real" is to put a little negative damping into the pitch roll and yaw. That is, put in about .5% of control for each 10 deg per second angular rate (in the same direction as the rate). This will make the aircraft mildly rate unstable, and will prevent it from sitting in any one spot. Fiddle with the unstable rate gain until it feels right.

[Graviman]

Simon,

Actually pilot normally has very good authority over rotor pitch and roll rates. The problem is that the rotor is connected to airframe by a single point (which pulls heli to new vector), or at best bt a weak spring (known as effective hinge offset). This leads to the fuselage following the rotor through a low pass filter, the time constant being reduced as the hinge offset goes up. This is why bearingless rotors provide a much snappier response to teetering.

Padfield no doubt discusses flapback, which causes the dynamic instability, and pitch roll coupling, which makes hingeless rotors feel marginal. Pilot controlling pitch and roll through an underdamped spring (as Nick suggests) is probably the best way to model the dynamics. I have only the R22 as a basis of evaluation (ie no significant cross coupling, and tail rotor at CG height), but this seems about right.

Any roll/yaw coupling would depend of CG position wrt rotor, which in teetering hover will be in line.

[Simon853]

Thanks everybody. That's all great stuff.

if you can find a way of increasing the rate of disc response to cyclic input you will succeed in producing a less stable hover

I've managed to do that already. It doesn't increase the helicopter's instability, only it's responsiveness. It's half the problem cracked though.

put in about .5% of control for each 10 deg per second angular rate (in the same direction as the rate)

That's an interesting idea. I'll give it a try. I had been wondering whether I could override its self-stabilising tendency by requiring a negative input to counteract a previous positive one. i.e. If slight forward cyclic had been applied then relaxing the joystick wouldn't level the helicopter, (as it does at present, after a delay), but a back cyclic input would be required. Though some decay would be implemented. That would cause a great deal of pilot induced oscillations until people got used to it.

It feels to me like the MS helicopter model's stability feels more like an r/c model with the Bell-Hiller mixer and large paddles than a full-sized one does, (in the hover anyway.)

I'll be sure to post a link so you can try out my software when it's ready.

Si

[Shawn Coyle]

If you're trying to fix MS Flight Sim's helicopter model - good luck. It has quite a few holes in it due to the basic background of a fixed wing model.

For example, try an autorotation at 60 KIAS, and then slow the airspeed to zero. At something below about 5 KIAS, the rotor slows to zero RPM.... (Not like the real thing, I can assure you).
There are a few models that have been made that try to get around the shortcomings - dodosims has done a pretty good job by all accounts. But mostly the helicopter model is quite a compromise.

[Simon853]

Shawn,
No, I'm not trying to fix everything. There are limits to what I can do based upon the implementation of the underlying flight model. I'm just seeking to improve things as much as I can and am concentrating on low speed flight.
There's a lot more that could be done but that would involve pulling apart and rewriting a lot of the low-level behavioural stuff for specific models, whereas I'm trying to write a program that runs alongside FS and augments what's already there for any helicopter.

At something below about 5 KIAS, the rotor slows to zero RPM.... (Not like the real thing, I can assure you).
Yeah, I got (only) about 19 hours in S300 from a couple of years ago but had to quit when I lost the C1 medical. It's all beginning to fade from memory a little, but enough's still there to help my work! Microsoft's modelling does not take relative airflow into account on the rotor, which is why forward airspeed dictates rotor rpm in it, and there's no rotor speed change during flares. (Dodo's 206 does that though, but the scope of their work was a lot more focused and aircraft specific that what I'm currently doing.)

If anyone has FS2004 or FSX and wants to give it a go, an early version of my program can be downloaded here: http://www.mediafire.com/?ehmj9ds4h1n
Note that it is a work in progress and a lot of the responses are using imprecise placeholder code until the proper maths is worked out. Things that are blatantly wrong are probably out of my control within the scope of this project. If you use FS2004 rather than FSX then you might want to disable the Low IAS instability as it's already far more unstable than MS's FSX imlpementation. You need to download an interface dll called FSUIPC (Google it) for it to work. Remember to leave the program running when you run FS.
Feel free to PM me any suggestions.
Regards,
Si