Whenever a user raises or lowers the collective (axis), the game's rotolib or advanced flight model will add or modify pedal input without the user adding any pedal input.
Description
Details
- Legacy ID
- 3264994918
- Severity
- None
- Resolution
- Open
- Reproducibility
- Always
- Category
- Advanced Flight Model
- Get in the gunner seat of the AH-99 and increase altitude.
- Steady and set auto hover.
- Switch to gun view and test by raising or lowering the collective joystick axis. Take note pedal input is added even though the user is not using the pedal axis! Further more, each pedal axis input used whenever the collective is used, is relative to the collective axis input. (ie. collective up = left pedal, collective down = right pedal -- I might have these reversed, but the reaction is consistent.)
I'm not sure if this is normal due to the tilt tail rotor of the AH-99, but am betting since we're dealing with computerized corrected flight controls, this should not be happening at all.
Also, the game sees my Saitek X52 Pro axis as the following:
Left pedal = Saitek X52 Pro Stick Z- rotate
Right Pedal = Saitek X52 Pro Stick Z rotate
Collective raise (analogue) = Saitek X52 Pro Stick Z- axis
Collective lower (analogue) = Saitek X52 Pro Stick Z axis
Being concerned about conflicting axis or bindings, I also removed mouse bindings to ensure these were not generating unwanted axis input. However upon deactivating Helicopter Advanced flight model, the above unwanted pedal input (generated whenever the collective is used) ceased to occur! For the time being I've switched Advanced flight model off, however I can nolonger see any of the gauges. This bug occurs even with all options within the Advanced flight model set to generic options.
Event Timeline
When you add collective, you modify the angle of attack of the blades. The governor adds more fuel to the mixed gaz in the turbine, because the resistance of the air on the blades raises, and it tends to decelerate the rotor.
The action of raising the power of the rotor brings a reaction: More par effect, that has to be compensated with the antipar (pedals).
In fact, every movement of every control in the helicopter (Collective, cylic and pedals) needs some response from the rest of the controls.
Raising or lowering the collective needs an antipar compensation. It´s not a programming mistake. It´s a programming win for realism ;)
rule of thumb - if you're bound on using "auto hover" - then leave advanced flight model turned off
helicopters are definitely not stable creatures -- for every control input given, it'll try to kill you in a different way in return
a stable hover is achieved by a fine balancing act, which requires a lot of constant corrections... it does become intuitive after a while with some practice - and a good joystick....
curiously - the Huron and Taru helicopters should have a lot less of such tendency to yaw from torque - this simply because the two equally sized counter-spinning rotors should cancel each other out (to some degree, it ain't perfect)
So you're stating there's no on-board equipment within real life helicopters to achieve auto-hover? (I could have sworn manual hovering was something left over from the 1970's.)
If you noticed as well within ARMA 3, auto-hover takes effect gradually upon activation. As if to display the feature was engineered intentionally to work alongside manual control. (During Apha and Beta, auto-hover took effect instantly and abruptly with no gradual effect.)
Although always a good exercise establishing good manual hovering skills in the event the on-board auto-hover ever fails, auto-hover allows pilots to concentrate on other instruments or perform other risk assessments. (And for the occasion the pilot has a magazine handy and happened along a really good article!)
Well no, I'm afraid you've misread my point.
Of course, real life helicopters (not all, but the more advanced ones) are equipped with autopilot systems which are often capable of maintaining a stable hover.
my point was to observe that in ArmA - the "autohover" feature is NOT in any way a means to represent those systems. In fact, it had been present in the earliest versions of this game, even in Operation Flashpoint - in the early 2000's - this was all way before AFM was introduced...
which is why I strongly advise anyone who's relying on it not to do so with AFM enabled. Since it was not built to safely fly anything more realistic than the basic model (may have been updated a bit, but still)
also, a lot of the real-life counterparts of the ArmA rotor fleet do not have any autopilot.
the MH9 or AH9, based on the RL MD500 namely, does not feature any automation, in fact it also does not feature an "auto force trim" switch (as represented by "set manual trim") - instead, it has a hat-switch that incrementally adjusts the forces on the cyclic with repeated pilot input.
as a freebie - the ArmA MH9 (by 2035, some upgrades, right?) has an auto-force-trim that works even on the pedals (whereas the MD500 has trim only for the cyclic) -- it does not however, seem to have any true autopilot installed - look around the cockpit, pretty basic stuff, eh??
so back to my point -- auto hover is not analogous to autopilot -- it's a legacy system from previous arma versions placed there for the sake of helicopter accessibility for the joystick-impaired (and the lazy) - and it was not built to correctly respond to the minutious intricacies of each and every different helicopter in the game under AFM.
AFM is based on Rotor-Lib, a Third Party rotor wing simulation platform which was built with RL pilot training and high-level flight-sims in mind. It was used on "Take on: Helicopters" and that's why it was added to ArmA 3 as well.