Think I might finally understand Trim problem!

[ZaltysZ]

Thanks for the suggestions ZaltysZ, I'll try the move the stick 5% then click n times to reach 50% idea.

 

I'm not clear what you mean by Click-click though. Click-hold-move is obvious but Click-Click has no move in the sequence, so it suggests just clicking without trying to move! Not really sure what move-move-click means either, as that implies trying to move twice before clicking, so if you could clarify what you mean that would be great.

 

Click-click is when you constantly click trim button while you are moving the stick. Move-move-click is when you move the stick a lot, but click trim only once at the end.

[doveman]

Click-click is when you constantly click trim button while you are moving the stick. Move-move-click is when you move the stick a lot, but click trim only once at the end.

 

Gotcha, thanks.

[P1KW]

The FD is not used in reality: You lose many aids that are for something.

 

 

Unfortunately, the absence of adequate control devices on the market, forcing us to modify existing:

More realistic control since I've been flying BS (with G940) thanks to the bug in the last version and this little program from AveragePilot:

Who said the G940 force can not relax while pressing the trimmer button ?

This guy has done at home.

 

Damper and friction effects in force feedback for Black Shark

 

 

For the yaw I removed the spring to the pedals and I added hydraulic touch, with that touch the pedals are very viscous. Two pneumatic pistons.

Thanks again to a third, this code from Peterp;

 

How to unchain the rudder from trim

 

 

Both should be included in DCSW. I'm sure ED reads these things.

 

In any case, the human being has an amazing ability to adapt. If no joysticks, end up flying the Ka-50 with a mouse, but I understand that I comment above is the most natural.

 

Greetings!

 

Excuse my poor English, if I put something stupid, let me know.

Edited January 24, 2013 by P1KW

[doveman]

Unfortunately, the absence of adequate control devices on the market, forcing us to modify existing:

 

Well really I think ED should make the sim able to be used properly with the devices that are available, whether FFB or not.

 

For the yaw I removed the spring to the pedals and I added hydraulic touch, with that touch the pedals are very viscous. Two pneumatic pistons.

Thanks again to a third, this code from Peterp;

 

I used to use this mod as I understand the difficulty in trimming the rudder with no physical feedback of the position they're trimmed to but now I think it's a bit of a sledgehammer, as without the ability to trim the rudder, not only are we not learning to fly the KA-50 properly but we have to constantly maintain pressure on the rudder controls (whether pedals, or twist-stick or rocker on the throttle) to fly straight, so I think it's better to just use the controls indicator instead. Those of use without FFB sticks really need this on anyway so that we can see where the stick is trimmed to, so we might as well use it for the rudder as well.

[Ich666]

So, to kind of conclude this thread, can we say that Trimming is working fine, its just that we shouldnt do big changes in flight path and, if we do, trim twice?

[doveman]

So, to kind of conclude this thread, can we say that Trimming is working fine, its just that we shouldnt do big changes in flight path and, if we do, trim twice?

 

Not at all, as my track should show and some of the other videos in this thread and elsewhere also show, trimming when barely moving and trying to achieve a hover results in severe oversteering and trimming twice when banking not that much whilst in flight just results in two oversteering lurches and the shark still not settling on the point the pilot was aiming for. It may be that ZaltysZ's suggestion to move the stick 1% and click multiple times to reach a 5-10% bank helps but unless this is how real pilots fly the shark then it's a workaround at best.

 

Until ED implement a way for players with non-FFB sticks (not that I think that's the issue but some people with FFB sticks don't seem to have the problem, so I'm concentrating on non-FFB users) to use Trim as intended without it lurching, I consider it still bugged. If the problem is that in the real shark the pilot can feel the stick lurching as the AP is disengaged when he clicks Trim and can compensate the other way to prevent it lurching, then perhaps ED need to at least give an option that does that automatically (i.e. applies the same correctional opposing movement that the pilot would in response to the AP disengaging) to make up for the fact that us virtual pilots can't feel the effect on the stick of the AP disengaging.

 

They also need to clarify in the manual and elsewhere what the correct way is to use Trim, as the current instructions as contradictory and confusing. Of course it may be that the problem with Trim needs to be sorted before any good instructions can be written.

[Suchacz]

I dunno if these link are here, but to be sure I'll add them. Really great articles, it will answer most of your questions :thumbup:

 

SimHQ's DCS: Black Shark - Autopilot: Part 1 and 2, and DCS: Black Shark and the Trimmer

http://www.simhq.com/_air13/air_429a.html

http://www.simhq.com/_air13/air_430a.html

http://www.simhq.com/_air13/air_428a.html

Edited January 24, 2013 by Suchacz

[P1KW]

Well really I think ED should make the sim able to be used properly with the devices that are available, whether FFB or not.

Not the solution, ED can make simulators, not miracles.

The first FS I fly was handled better with mouse, at that time there was no analog joys.

 

 

 

I used to use this mod as I understand the difficulty in trimming the rudder with no physical feedback of the position they're trimmed to but now I think it's a bit of a sledgehammer, as without the ability to trim the rudder, not only are we not learning to fly the KA-50 properly but we have to constantly maintain pressure on the rudder controls (whether pedals, or twist-stick or rocker on the throttle) to fly straight, so I think it's better to just use the controls indicator instead. Those of use without FFB sticks really need this on anyway so that we can see where the stick is trimmed to, so we might as well use it for the rudder as well.

 

Maybe has not understood.

The PeterP code is perfect with pedals without spring.

If you insist on the spring will have to use the ED solution.

In most helicopters pedals have no center, only a touch viscous. The pilot places, and there they stay.

 

Greetings!

[ZaltysZ]

Oversteer happens because of AP, and not because of stick type.

 

Steps to reproduce:

1) Ka-50 is in hover and it is trimmed for hover. Hovering mode is off. All autopilot channels, except altitude, are on.

2) Cyclic is pushed forward, collective is increased to keep the same altitude. Trim button isn't touched at all (Ka-50 still remains trimmed for hover).

3) Once Ka-50 accelerates to 140km/h, cyclic and collective are adjusted to keep helicopter in stable level flight at 140km/h

4) Trim button is quickly clicked (without holding it).

 

Result: huge (significant) nose drop after step 4.

 

I don't have FFB stick myself, however I gave these instruction to my friend and he reported the same issue using FFB stick.

 

I understand why it happens: pilot works against AP (by moving aircraft attitude far away from angles which are tried to be held by AP), and his input gets less effect because AP opposes him; then trim button is pressed, and AP opposition suddenly disappears causing oversteer as pilot input regains its full effect.

 

What I don't understand is why it is allowed to disconnect AP so quickly (on trim press), but connect it so slowly (on trim release). This difference causes abrupt oversteer, which can be fatal at certain speeds. Why it doesn't remove AP input gradually and not abruptly (that would give pilot a chance to lessen oversteer), or why it doesn't disconnect AP only after holding trim longer than lets say 300ms (that way short click would never remove AP input, but only tell it new angles to hold)?

 

My logic tells that such dangerous flaw should not exist in real life approved military design. But... world is wonderful not only in good way :doh:, so it still might be "realistic".

[Daniel M]

Oversteer happens because of AP, and not because of stick type.

 

Steps to reproduce:

1) Ka-50 is in hover and it is trimmed for hover. Hovering mode is off. All autopilot channels, except altitude, are on.

2) Cyclic is pushed forward, collective is increased to keep the same altitude. Trim button isn't touched at all (Ka-50 still remains trimmed for hover).

3) Once Ka-50 accelerates to 140km/h, cyclic and collective are adjusted to keep helicopter in stable level flight at 140km/h

4) Trim button is quickly clicked (without holding it).

 

Result: huge (significant) nose drop after step 4.

 

I can not duplicate using center trim option. I can "understand" this happening with that option turned off because your joystick is moving the virtual joystick. You trim to hover, pretend perfect 0,0, get to step 4 and when you hit trim the virtual joystick is trimmed forward(for fwd flight) but the computer is also reading that you have pitch input so it forces a nose down, am I incorrect? I forget what the timing is but, don't you have half a second to get the stick "recentered" in the non-center trim option?

 

 

Aka step 4 should be 4) Trim button is quickly clicked(without holding it) and joystick returned to center?

 

*edit: i might have the center trim option reversed....i use the "old way" of click trim, and you get no joystick input into the game unless you recenter joystick, vs the new way of "it recenters after .5 seconds"

Edited January 24, 2013 by Daniel M

[ZaltysZ]

I can not duplicate using center trim option. I can "understand" this happening with that option turned off because your joystick is moving the virtual joystick. You trim to hover, pretend perfect 0,0, get to step 4 and when you hit trim the virtual joystick is trimmed forward(for fwd flight) but the computer is also reading that you have pitch input so it forces a nose down, am I incorrect? I forget what the timing is but, don't you have half a second to get the stick "recentered" in the non-center trim option?

 

 

Aka step 4 should be 4) Trim button is quickly clicked(without holding it) and joystick returned to center?

 

*edit: i might have the center trim option reversed....i use the "old way" of click trim, and you get no joystick input into the game unless you recenter joystick, vs the new way of "it recenters after .5 seconds"

 

Nope, it happens with time based trim, center based trim and even FFB (which does not require to recenter the stick). This is not trim issue, this is AP stabilization system issue. You tell AP to keep 0, then you input 50, AP wants to keep 0, so it counters your input with -20 (max it can), and net effect ends to be 50-20=30. The moment you press trim button, AP stabilization gets disabled and that -20 disappears, so net effect quickly jumps from 50-20=30 to 50-0=50. This wouldn't be a problem, if AP could quickly go from 0 to -20 again once you release trim button, but it can't, so even after quick trim click you end with so called oversteer.

 

P.S: if you don't have FFB stick, then yes: 4 should be 4) Trim button is quickly clicked(without holding it) and joystick returned to center?

Edited January 24, 2013 by ZaltysZ

[doveman]

I can not duplicate using center trim option. I can "understand" this happening with that option turned off because your joystick is moving the virtual joystick. You trim to hover, pretend perfect 0,0, get to step 4 and when you hit trim the virtual joystick is trimmed forward(for fwd flight) but the computer is also reading that you have pitch input so it forces a nose down, am I incorrect? I forget what the timing is but, don't you have half a second to get the stick "recentered" in the non-center trim option?

 

 

Aka step 4 should be 4) Trim button is quickly clicked(without holding it) and joystick returned to center?

 

*edit: i might have the center trim option reversed....i use the "old way" of click trim, and you get no joystick input into the game unless you recenter joystick, vs the new way of "it recenters after .5 seconds"

 

No, the old way is click trim and you have x seconds to re-center the stick during which input is ignored and the new way (Central Trimmer Mode) is click trim and all input is ignored until the stick is re-centered.

 

I don't think your theory about the problem is right either as this oversteering appears to happen the moment trim is clicked, so there's no opportunity to re-center the stick to prevent additional input. In Central Trimmer Mode of course, with input locked out until the stick is recentered, if that was the problem then it shouldn't happen at all. However it was found that PeterP's rudder trim mod caused problems with that, so they can't be used together which complicates matters.

[doveman]

Not the solution, ED can make simulators, not miracles.

 

It's a matter of coding, hardly a miracle!

 

Maybe has not understood.

The PeterP code is perfect with pedals without spring.

If you insist on the spring will have to use the ED solution.

In most helicopters pedals have no center, only a touch viscous. The pilot places, and there they stay.

 

Well if the KA-50 has these pedals that stay where they're left, then I'm not sure why it would need to trim the rudder but I believe it does and if so, if you disengage the rudder from trim with PeterP's mod, you're no longer flying a sim of the KA-50.

 

I don't have any pedals, only a rocker on my throttle which is spring-loaded so that can't be left in a fixed position, so the Controls Indicator is very useful for me.

[doveman]

Oversteer happens because of AP, and not because of stick type.

 

Steps to reproduce:

1) Ka-50 is in hover and it is trimmed for hover. Hovering mode is off. All autopilot channels, except altitude, are on.

2) Cyclic is pushed forward, collective is increased to keep the same altitude. Trim button isn't touched at all (Ka-50 still remains trimmed for hover).

3) Once Ka-50 accelerates to 140km/h, cyclic and collective are adjusted to keep helicopter in stable level flight at 140km/h

4) Trim button is quickly clicked (without holding it).

 

Result: huge (significant) nose drop after step 4.

 

I don't have FFB stick myself, however I gave these instruction to my friend and he reported the same issue using FFB stick.

 

I understand why it happens: pilot works against AP (by moving aircraft attitude far away from angles which are tried to be held by AP), and his input gets less effect because AP opposes him; then trim button is pressed, and AP opposition suddenly disappears causing oversteer as pilot input regains its full effect.

 

What I don't understand is why it is allowed to disconnect AP so quickly (on trim press), but connect it so slowly (on trim release). This difference causes abrupt oversteer, which can be fatal at certain speeds. Why it doesn't remove AP input gradually and not abruptly (that would give pilot a chance to lessen oversteer), or why it doesn't disconnect AP only after holding trim longer than lets say 300ms (that way short click would never remove AP input, but only tell it new angles to hold)?

 

My logic tells that such dangerous flaw should not exist in real life approved military design. But... world is wonderful not only in good way :doh:, so it still might be "realistic".

 

Thanks for explaining the problem clearly ZaltysZ. That is the main question of course, whether the real KA-50 behaves in this way, which as you say would seem to be illogical but doesn't necessarily mean it doesn't!

 

IRL, if the pilot is pushing the stick forward say 2cm and clicks Trim, either the AP suddenly releases it's 20% authority causing a "the other bloke just let go of the rope" effect and the pilot's arm lurching forward, unless he anticipates this and pulls his arm back at the moment he clicks Trim (doesn't sound very practical) or it doesn't and all that happens is perhaps the stick becomes a bit looser but not so much as to cause the pilot to massively oversteer.

 

In BS2, if I'm pushing the stick forward say 2cm and click Trim, if IRL that doesn't cause the pilot's arm (and thus the shark) to lurch forward then it shouldn't in the sim.

 

I also don't really see why the double-input effect has been implemented in the sim because IRL, the pilot moves the stick forward 2cm, clicks Trim and the stick stays in that position and the AP doesn't then see that the stick isn't centered and decide to move the shark even further in that direction, so if I move my stick forward and click Trim and hold the stick in that position, the AP shouldn't double the input. Obviously I might not be able to hold the stick in the exact position and at some point I'll need to let go and let it re-centre but what I would think would work better is if the current position is treated as the zero position, so that any movements away from centre from that position after clicking Trim are still acted upon as they would be IRL (allowing me to make minor adjustments) but any movements towards centre are ignored, until the stick is re-centered, at which point that becomes the zero position again. Or even better perhaps there could be a small zone around the current position in which movements are acted upon, allowing us to make minor adjustments in any direction but once the stick goes outside this zone, towards the centre, input is ignored until the stick is re-centered .

[Suchacz]

Read those SimHQ articles, linked on the previous page. It will make this "problem" easier to understand... :smilewink:

 

Believe me, there is no "strange trim bug" or "strange trim behavior". Everything is simulated the same way as it behaves in R/L. But on the other side, there is no "The one and only trimming method". The only way to get used to it is to understand it, and than fly fly and fly and trim trim and trim :thumbup:

 

My advice: Dont fight with AP. Try to cooperate....

Edited January 24, 2013 by Suchacz

[doveman]

Read those SimHQ articles, linked on the previous page. It will make this "problem" easier to understand... :smilewink:

 

Believe me, there is no "strange trim bug" or "strange trim behavior". Everything is simulated the same way as it behaves in R/L. But on the other side, there is no "The one and only trimming method". The only way to get used to it is to understand it, and than fly fly and fly and trim trim and trim :thumbup:

 

My advice: Dont fight with AP. Try to cooperate....

 

Thanks but I've read those before and they don't answer the questions about BS2's behaviour.

[Suchacz]

Thanks but I've read those before and they don't answer the questions about BS2's behaviour.

No ofense, but it behaves in the right way. As I said, its behavior is correct, try to understand it and use it the right way. It behaves like this for some purpose. Maybe our misunderstanding is based on the controling HW, because I'm flying with G940 FFB stick. Now, it has some issues with DCS:W, but with AveragePilot's FFB utility it works even better than with default ingame FFB (due to friction and damper effect). I feel comfortable in Akula's cockpit and its AP is helping me to fly it and it takes off most of the workload from the poor pilot and you can concentrate yourself on the searching for the bad guys than on flying this unique bird :thumbup:

[ZaltysZ]

Thanks for explaining the problem clearly ZaltysZ. That is the main question of course, whether the real KA-50 behaves in this way, which as you say would seem to be illogical but doesn't necessarily mean it doesn't!

 

IRL, if the pilot is pushing the stick forward say 2cm and clicks Trim, either the AP suddenly releases it's 20% authority causing a "the other bloke just let go of the rope" effect and the pilot's arm lurching forward, unless he anticipates this and pulls his arm back at the moment he clicks Trim (doesn't sound very practical) or it doesn't and all that happens is perhaps the stick becomes a bit looser but not so much as to cause the pilot to massively oversteer.

 

In BS2, if I'm pushing the stick forward say 2cm and click Trim, if IRL that doesn't cause the pilot's arm (and thus the shark) to lurch forward then it shouldn't in the sim.

 

I also don't really see why the double-input effect has been implemented in the sim because IRL, the pilot moves the stick forward 2cm, clicks Trim and the stick stays in that position and the AP doesn't then see that the stick isn't centered and decide to move the shark even further in that direction, so if I move my stick forward and click Trim and hold the stick in that position, the AP shouldn't double the input. Obviously I might not be able to hold the stick in the exact position and at some point I'll need to let go and let it re-centre but what I would think would work better is if the current position is treated as the zero position, so that any movements away from centre from that position after clicking Trim are still acted upon as they would be IRL (allowing me to make minor adjustments) but any movements towards centre are ignored, until the stick is re-centered, at which point that becomes the zero position again. Or even better perhaps there could be a small zone around the current position in which movements are acted upon, allowing us to make minor adjustments in any direction but once the stick goes outside this zone, towards the centre, input is ignored until the stick is re-centered .

 

AP does not care about stick position at all. AP does its job according to yaw,pitch,bank angles of aircraft which were present the moment you released trim button. Pilot and AP are two separate control loops. AP does not move the stick, but it can still affect pitch of blades. I think, I have introduced some misunderstanding with "50-20=30" as it might look like AP cares directly about pilot input. I will make the analogy (and will make it stupid for sake of making it more clear).

 

Let's say you are driving a hypothetical vehicle, which has brakes, accelerator pedal and AP for speed control. You accelerate to 30km/h and tell AP to stabilize that speed. Stabilization means that if you release accelerator a bit, AP will rev engine up a bit by itself, and if you add a bit of accelerator, AP will rev engine down and/or apply some brakes, so that speed will remain 30km/h. Now, if you add lots of accelerator, AP will be overwhelmed as it does hot have the same authority, and despite it trying to rev down and brake, vehicle will still accelerate to 50km/h. So, you are driving at 50km/h fighting AP and winning, but suddenly you realize that you want AP to stabilize the speed at 50km/h. You press the button, and upon doing that you first get AP input (its effort to brake you down to 30km/h) disabled, and then get it memorize the new speed setting (50km/h) on button release. What happens? Vehicle jumps forward at first and easily reaches 60km/h (past the new target speed of 50km/h), because of the delay between disabling AP and enabling it again. "Aggressiveness" of that speed jump depends on the difference between how quickly AP is able to remove its input and how quickly it can reach max of its input. Keep in mind that AP does not care about accelerator or brake pedals. It only cares about speed of hypothetical vehicle, and not about position of brake and accelerator pedals. If we introduced trim system to our vehicle, then that system would care about these positions, but AP would still care only about speed. Overspeed happens in this example not because of presence of AP input, but because of lack (or sudden removal) of that input.

Edited January 25, 2013 by ZaltysZ

[DieHard]

I´ve tried flying with Trim-bumping to death. It never worked for me.

 

Since then i´m flying with said Method (push, manouver, release). Rudders are unchained

 

from Trim via PeterP´s Mod.

 

And to hold Altitude you should not forget to pull the Collective Brake. It´s a mighty

 

Tool for level Flight, e.g in Curves, which often seems to be forgotten. :)

 

I can fly just a couple meters off the deck consistently without ever engaging AP Altitude Hold and using the collective brake, though I do use it in hover. I do have the 3 amigos turned on. I have learned a lot by just observing 74th_Baron and how he flies his Shark.

 

Go practice taking out the two power stations on the 74th's server, the Dynamo 1st phase mission using just the Ka-50. If you engage AP Altitude Hold low, the copter porpoises several meters like a sine wave.

 

I set my collective curve as unset standard stock setting, using the CH Pro Throttle, using the CH Control Manager sensitivity for it set at 100.

 

I uncheck the Central Position Trimmer Mode. I use the method used in the BS1 instructional video. One learns to use what works best for himself and just get used to it.

 

Is my method better than yours? I think it comes down to personal preference and what works best as to my / your PC's setup.

[doveman]

AP does not care about stick position at all. AP does its job according to yaw,pitch,bank angles of aircraft which were present the moment you released trim button. Pilot and AP are two separate control loops. AP does not move the stick, but it can still affect pitch of blades. I think, I have introduced some misunderstanding with "50-20=30" as it might look like AP cares directly about pilot input. I will make the analogy (and will make it stupid for sake of making it more clear).

 

OK, thanks for explaining further. I was thinking that whilst the AP is engaged and the pilot is pushing the stick away from the previously trimmed/AP point that there would be some resistance on the stick (up to 20%) from the AP trying to pull back to the current trimmed position but from what you're saying this doesn't happen, so there's no sudden release of this AP authority on the stick when trim is pressed and therefore no reason why the pilot would suddenly jerk the stick forward. If so, the question is why does the virtual stick in BS2 jerk when clicking Trim? Certainly it seems that what I'm seeing happen is the stick jerking forward when I click-release trim and the AP locking in at the position the stick jerked forward to (although it may be oversteering and trimming even further than the stick postition would account for).

 

I get the other part, that the AP authority being released when clicking Trim can cause an oversteer, which is what Brainless said and why I started this thread. The question however is whether BS2 is behaving the same as the real KA-50 or whether it's overdoing this effect or causing it in situations where it shouldn't be happening because there isn't a large opposing trim/AP to be released (as in just after takeoff when trying to hover). The other question is whether there's a better method to use for non-FFB sticks to simulate the trim function, such as I described.

[ZaltysZ]

If so, the question is why does the virtual stick in BS2 jerk when clicking Trim? Certainly it seems that what I'm seeing happen is the stick jerking forward when I click-release trim and the AP locking in at the position the stick jerked forward to (although it may be oversteering and trimming even further than the stick postition would account for).

 

If you are seeing stick jerk, you are probably having trim jump issue, and not AP issue. The usual reasons:

 

1) Your hand. You do little involounteer movement of your hand when you press trim button. Try using "T" on the keyboard with your other hand to rule out that involounteer movement.

 

2) You are trimming using center based method and activation zone is too large. You have activation zone 0..5, and you move the stick to 10, then you click trim button, and that tells game lock your controls at 10 and take it as new trimmed position. Then you move the stick to 0 position, but the moment you pass 5 game unlocks controls (as stick gets within activation zone), and this causes oversteer, because game thinks stick is deflected away from trimmed position (10) to position 10+5. Of course, that extra 5 gradually diminishes as you continue to center the stick, but before that you perceive noticeable control jerk. If you are trimming within activation zone (happens constantly when trying to nail helo for stable hover), then your controls get controls activated instantly and you get oversteer instantly.

 

3) You are using time based method and you fail to center the stick PRECISELY before activation time ends. Amount of oversteer/understeer depends on how far the physical stick is from its real center the very moment activation time ends. I.e. you click trim at position 10, you move the stick towards center, but you overshoot it by 2 (fault of hand, stick spring or stick electronics) and you don't manage to correct the mistake before activation time ends. So you get virtual stick position of 10-2=8 (understeer) for a brief moment, and you perceive that as control jerk. Same happens if you fail to reach the center at all in time, except that this causes oversteer and not understeer for a brief moment.

Edited January 26, 2013 by ZaltysZ

[rrohde]

Interesting thread.

 

Along the same lines, I was wondering -- what is the best curvature and deadzone settings for the Ka-50, considering the twitchiness of trimming the AP. I am using a X52 HOTAS.

 

Thanks.

[Ich666]

0/0 :)

[DieHard]

Interesting thread.

 

Along the same lines, I was wondering -- what is the best curvature and deadzone settings for the Ka-50, considering the twitchiness of trimming the AP. I am using a X52 HOTAS.

 

Thanks.

 

I use a plus 25 on the Axis Tune sliding scale curvature in X and Y, zero deadzone, other settings are plus 100. Cyclic is a CH Products Fighterstick.

 

My collective is a CH Products Pro Throttle. I only tune it using the CH Control Manager, sensitivity set at plus 100.

 

I think you need to experiment what works best for you and your setup.

 

See previous post (this thread) concerning how I trim.

Edited January 26, 2013 by DieHard

[doveman]

If you are seeing stick jerk, you are probably having trim jump issue, and not AP issue.

 

Whatever I'm having, it makes it unusable. I've made a short video, on the ground straight after start-up had finished, showing how it jerks when I click trim. This was done with Central Trimmer mode off but I tested with it on and it was the same. I'm not sure what it's doing but it seems to be doubling up my input when I press Trim (and I was pressing T on the keyboard for this test). It doesn't appear as bad in the second half of the video but that's because I was trying to see if I could literally let go of the stick and let it re-centre the very instant I pressed Trim and I was probably actually letting go of the stick a split-second before, so that it was moving back towards the centre when Trim actually registered.

 

 

These are my current settings from mods\aircrafts\KA-50\FM\FMOptions.lua:

 

----------- for new helicopter trimmer method -----------------------------------------------
----------- (joystick will be disable after trim until it come to neutral zone) -------------
HelicopterTrimmerZonePitch		= 0.2
HelicopterTrimmerZoneRoll		= 0.2	
HelicopterTrimmerZoneRudder		= 0.4

---------- for old helicopter trimmer method ------------------------------------------------
----------- (aperiodic process)  ------------------------------------------------------------
HelicopterTrimmerTauInverse		= 4.5 --lower value - decrease trim speed after trim button release. 

 

I lowered HelicopterTrimmerTauInverse from 7.0 to 4.5 to give me more time to center the stick so I don't believe it can still be so short that it's registering the stick position twice in the split-second after clicking Trim. I increased the zones for the new method too but when I tested with Central Trimmer mode on, I moved the stick much further than in the video and it still did the same thing, so I don't think it can be that I'm moving the stick within the zone.

 

Even if either mode was working properly though, I still think it would work better if stick movements away from the centre were still registered after clicking Trim (which would emulate the real behaviour, where after the pilot clicks Trim he can still move the stick further and click Trim again (or not), without any timeout or having to re-center the stick) but stick movements towards the centre were ignored until the stick had re-centered, which would allow us to release the stick, as is necessary when using a non-FFB stick as we can't hold it in position all the time, without any unwanted input.

 

This would eliminate any problem of double-input which can happen with the original trimmer method, as it will never go "OK, time's up, hmm stick's forward, you must have re-centered it and moved it forward again so I'll pitch forward some more" and whilst there might be times when we want to make adjustments towards the center and won't be able to until we've re-centered the stick, at least we'll be able to make give additional input away from the center without re-centering, which we can't do now.

 

Another option could be to have a "ignore stick" button, so that when we want to let go of the stick and let it re-center we hold that and the rest of the time the virtual stick tracks the real one, which would allow us to fly much more like the real thing.