More autopilot questions

[Havner]

Hi.

 

Again, not asking about complete basics. I know how the autopilot works, I fly it/use it without any problems. But recently when I asked about the dampening I was pointed to the following articles:

 

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

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

 

It nicely summarized the knowledge, but after reading it I wanted to go further and understand everything completely. And I got two things that bother me and I can't find them explained. They even seem to behave in contrary to what is described there (I think).

 

I fly with the center trimmer option so any accidental inputs caused by my joystick not returning to the center fast enough are excluded.

4 channels are on. Altitude is on barometric so we don't have any accidental nose movements.

 

So to the questions:

Let's stabilize the heli by the book at 150kph forward flat flight. Hold the trimmer, set the proper attitude, let it speed up to the 150kph, keep the speed, release the trimmer. Now the autopilot reference point for pitch and bank is as close as possible to the trim position. The autopilot doesn't have to fight the trim position much to keep the attitude.

 

Let's split the forces the autopilot has to correct to the pilot input (stick movement) and external ones (weather, wind, air effects).

 

With this flight when a wind will blow for a second I suppose the autopilot will try to correct the attitude to its remembered reference point within its 20% of authority.

But let's add some user input. Let's gently push the stick forward (without the trim, not the proper solution, but that's my point) for about 10% of it's movement and let's keep it that way. The nose will dive and the pitch change is still within the autopilot authority. But the autopilot doesn't correct it.

 

1. Why? From what I see it does that in Route and Hover modes. But not in the default one (attitude keep). According to my understanding and the article it should. The same goes for bank. Route mode fights the pilot input. The default one doesn't.

 

Having said that (that the autopilot for some reason doesn't correct the user input in the default mode) let's push the stick even further (20-30%) and let the heli stabilize. Then hit (just hit once, push and release immediately) the trimmer. The nose will dive (not because of my joystick, the diamond on the red overlay with stick positions doesn't move a pixel). I get that this might happen when autopilot is using its max authority of 20% and by hitting the trimmer we release it immediately. But here as per point 1. it wasn't using any of its authority.

 

2. So why the dive? It should just remember the current pitch/bank as a new reference point and keep it.

 

I hope it's understandable. If needed I can provide tracks but I think it's easy enough to do by yourself.

Edited September 24, 2013 by Havner

[PeterP]

Collective Brake - aka Collective Trim ... and why you should use it.

[Havner]

Collective? My example is based on cyclic. I know what collective brake

is. I mentioned that the flight is stabilzed in altitude. I don't see a reference to your article.

 

EDIT: As a side note I almost always use the collective brake when moving the collective. I see completely no relation between my questions and your article.

Edited September 24, 2013 by Havner

[Hunden Ynk]

I'm not sure I getall you say, but I'll shoot and you can correct me if I misunderstood anything. Also, I'm no expert, so my findings might be a bit naive, and hope I might learn something as well.

 

It seems that the AP out of Route and Hover mode is polite enough to never try to negate the inputs of the pilot. Here's how it behaved under my quick test:

 

From level flight I moved the cyclic slightly to the right, yielding a bank angle of about 5°. Holding that very same cyclic position, and the bank angle kept stable at 5°. (For testing purposes I disabled the heading AP channel, not sure if necessary though.)

If I moved the cyclic slight more to the right, I could get to a position where it would hold 10° for example. However, at a certain cyclic position, the AP would no longer be a able to hold a given bank angle, and the angle would continue to increase even as I held the stick steady. That must be past the famed 20%. If I moved the cyclic back to the neutral position, the helicopter would evenly move back to that initial 0° bank.

 

If the same maneuver would be performed with the trimmer held down, FD on, or Bank AP channel off, i.e. no AP. The bank angle would continue to increase as the cyclic was kept in that slight right position, the one that otherwise would hold 5°. To maintain a constant bank, one would have to center the cyclic when preferred angle has been achieved. And to get back to 0°, the cyclic would need to be deflected in the opposite direction.

 

So there's a delay for the AP to kick in, allowing you to perform small changes in attitude without interference of the AP. But the AP will eventually kick in and while it will stabilize the movement at most, it will never actively steer you back as it does in route mode. Meaning, never turn your 5° bank to zero. Unless you move the controls back towards the trimmed position, then it will.

You can also experience this if banking nice and steady without holding down the trimmer, and thinking - I want to trim this bank angle. By pressing trim at that moment, you will cancel out the effect the AP was in fact having, and your bank might jump from 30° to 60°. Is that what you describe in your point nr. 2?

[Havner]

I think that's not exactly what I was asking. I mean it kinda was but your answer doesn't answer anything for me :-)

 

For the first part of your post:

My findings are different. In route/hover mode the AP tries to negate user input (Hover for sure, Route I will check again). Meaning that if I bank right by 5% with Hover on the AP will correct it back to 0% (it will actually try to go a little bit to the other side to go back to the reference point above the earth).

 

1. But my first question was about the default Bank/Pitch hold mode which _doesn't_ do that. And according to all the documentation it should. It just shifts the reference point by the user input (the exampled 5%) and keeps it shifted.

 

Without AP yes, when you bank right by 5% you need a left cyclic to go back to 0%. This is obvious.

 

About the second part:

If you have a reference point for AP of bank at 0% and then you bank 5% as you say without the trimmer and the AP _doesn't_ correct you (it doesn't go back to 0%, it let's you stay at 5%) what input it has then? None. So by hitting the trimmer you are not canceling any of its input. So there shouldn't be a jump. In Hover, where AP does correct you: YES. In pitch/bank hold where it doesn't: NO jump.

My question was:

 

2. Why the jump? And if you read carefully what you wrote you should also have an impression that there shouldn't be any jump. There was no correction. It just behaves like the reference point is shifted by this 5% and then kept.

 

To sum up:

 

1. In the default pitch/bank hold mode why the AP doesn't correct user input? The user input just seems to shift the AP reference point.

2. If the AP in the default pitch/bank hold doesn't correct user input (from 1st question) why the jump when you just hit the trimmer when pitched/banked.

Edited September 25, 2013 by Havner

[Hunden Ynk]

Sorry for lacking the ability to explain what I mean properly, I'm curious about this though:

And according to all the documentation it should.

Where is that? I'm finding the manual a bit sparse on the AP documentation.

 

Finally you can try the Route without task mode, meaning Route mode on, but no WP, TP or airfield selected on the PVI-800, if you're dissatisfied with the AP.

[Havner]

Sorry for lacking the ability to explain what I mean properly, I'm curious about this though:

Where is that? I'm finding the manual a bit sparse on the AP documentation.

 

Sorry for not clarifying. Not mentioning the official documentation as it is definitely lacking details on AP.

 

But from the sources I've found. Specifically from the mentioned articles.

 

For example, if the Bank Hold channel is active, the assigned bank angle is 0 degrees, and the navigation system is reporting a bank angle of 10 degrees to the right, the autopilot will input left cyclic pressure until the bank angle returns to the assigned bank angle of zero degrees.

 

There is no distinction between user input and external sources that can cause the bank/pitch changes. And it's also not mentioned in the part 2 describing Hold modes, that user inputs are treated differently then external sources.

 

Finally you can try the Route without task mode, meaning Route mode on, but no WP, TP or airfield selected on the PVI-800, if you're dissatisfied with the AP.

 

It's completely not about dissatisfaction. I can fly the heli and I can make it do what I want it to do. I just want to fully comprehend the details of the AP internal workings. Following the mentioned article.

Edited September 25, 2013 by Havner

[Hunden Ynk]

Yeah those articles are great, and I would praise the ground EinsteinEP has walked on! :thumbup: Having said that, I don't think they can be seen as reference style docs. Perhaps he just forgot to mention it?

[Havner]

Yeah those articles are great, and I would praise the ground EinsteinEP has walked on! :thumbup:

 

Amen to that :-)

 

Having said that, I don't think they can be seen as reference style docs.

 

Unfortunately we don't have anything else but our own discussions. I don't think there is anything more complete about AP that those articles.

 

Perhaps he just forgot to mention it?

 

Maybe. That's why I'm trying to clarify. What is the behavior in the details. Because it differs a little from what he described.

[guitarxe]

Might be a dumb question, but are you pushing the stick 10% forward or 10 degrees forward?

[Havner]

10% of its max movement. Below autopilot authority. Make it just a minor move. As little as possible to see the nose pitch down. Doesn't really matter. The principle is the same.

 

Having said that, I don't think they can be seen as reference style docs. Perhaps he just forgot to mention it?

 

What bothers me though is if thats the case there shouldn't be any jump in question 2. But there is. Sonething is not logical or just unexplained here.

Edited September 25, 2013 by Havner

[Hunden Ynk]

It makes sense to me, which I tried to explain in my (mad?) rambling post. I'll try again, like this; if you're moving the cyclic in any direction. (AP channels on, trimmer not held down) The AP must in fact have an effect, since without it, your off-neural cyclic position would continue to alter the angular position of the aircraft, 5° bank becoming 10°, 15°, 25°, etc. But that doesn't happen, meaning the AP must be inputting the reverse of your stick movement. Now press trim, and bam, the AP effect goes away and the aircraft's position jumps. I might be wrong, but my brain says it's OK.

[Havner]

Yeah, now I get what you're saying :-) But it doesn't seem to be the case in my opinion. I never said autopilot is not doing anything. Of course it is. It's just doing something different that I would expect it to.

 

Let me elaborate on your case. You move the cyclic. 3 things are possible.

1. It starts to rotate and doesn't stop until you correct it (no autopilot)

2. It stays pitched in the direction of your cyclic move but doesn't counter by itself

3. It gets pitched in the direction of your cyclic move but tries to return to the set reference point.

 

Now, both 2 and 3 require an autopilot. It's just that in my understanding number 3 should happen.

 

Number 2 means only that the hold channel is still functioning around a new temporal reference point set by your shifted cyclic. The stabilization around that new point works. Thats for sure. So there is some autopilot contrary to a situation where there is none. But it doesn't use its 20% authority it should to return to the reference pitch/bank. And this is something I dont understand. Why it doesn't behave like in point 3. My impression from everyone describing the autopilot is that's the way it should.

 

That when you have channels turned you have to 'fight' the autopilot. According to this you don't as it doesn't counter your input. Your input just changes the reference point around which autopilot stabilizes.

Edited September 25, 2013 by Havner

[Fishbreath]

1. Why? From what I see it does that in Route and Hover modes. But not in the default one (attitude keep). According to my understanding and the article it should. The same goes for bank. Route mode fights the pilot input. The default one doesn't.

 

In your example, route mode doesn't actively fight the pilot input because pitch has moved away from the datum—it fights the pilot input because speed has moved away from the set point. It's the same with roll/yaw and heading.

 

As for the bouncing, Hunden Ynk seems to me to have the right explanation. The behavior where it appears to be 'holding' a stick input can be adequately explained by proportional responses—the autopilot doesn't input full deflection if you aren't a long way off of your set point, so that it can avoid overcorrecting. I'd imagine adding stick input confuses it—it's only a little bit away from where it ought to be, but the authority it's allowed to use to correct for a small error isn't big enough to overcome the small, but slightly larger amount of deflection imposed by the flight controls.

[Hunden Ynk]

Yeah, now I get what you're saying :-)

Cookie for me! :)

 

Have you tried Route-without-task-mode, it works like number 3 on your list. (At least I think, since I'm too lazy to confirm right now.) Now wouldn't it be silly of Kamov to make two modes that function in the same way? And I personally find the operation of number 2 to be more intuitive as a default kind of mode.

[Suchacz]

10% of its max movement. Below autopilot authority.

If you move the cyclic control 10% away from the trimmed position, AP will correct your input with its 20% authority back to the trimmed position, so the real input will be 8%. But if you press the trim button, you will disable this correction and the real input jumps to your absolute position of the cyclic control.

 

There is no "20% input vakuum" around the trimmed position as you think. Look at the pic below... :joystick::thumbup:

...

Yep

Edited September 25, 2013 by Suchacz

[Havner]

In your example, route mode doesn't actively fight the pilot input because pitch has moved away from the datum—it fights the pilot input because speed has moved away from the set point. It's the same with roll/yaw and heading.

 

But pilot input is actually causing the roll/yaw to move away from the datum as well. And as you said yourself that it's the same for roll/yaw (pitch/bank) so it should try to move it back.

 

As for the bouncing, Hunden Ynk seems to me to have the right explanation. The behavior where it appears to be 'holding' a stick input can be adequately explained by proportional responses—the autopilot doesn't input full deflection if you aren't a long way off of your set point, so that it can avoid overcorrecting. I'd imagine adding stick input confuses it—it's only a little bit away from where it ought to be, but the authority it's allowed to use to correct for a small error isn't big enough to overcome the small, but slightly larger amount of deflection imposed by the flight controls.

 

I'm not sure I understand you here. Are you saying that AP has more authority to overcome external causes then the pilot input? Or are you saying that it takes time for it to do so? The second is obvious. I do wait for it to stabilize (if there is anything to stabilize) after I move the cyclic.

 

Cookie for me! :)

 

:-D

 

Have you tried Route-without-task-mode, it works like number 3 on your list. (At least I think, since I'm too lazy to confirm right now.) Now wouldn't it be silly of Kamov to make two modes that function in the same way? And I personally find the operation of number 2 to be more intuitive as a default kind of mode.

 

Of course I have tried it. I know how it behaves. And again as I told you before. I'm not asking these questions to learn how to fly. I'm asking them to understand the details. I agree fully that the way pitch/bank hold works is somewhat intuitive. But if it works the way I think it does there shouldn't be a jump in case of the trimmer. And there is. So I'm trying to understand.

 

If you move the cyclic control 10% away from the trimmed position, AP will correct your input with its 20% authority back to the trimmed position, so the real input will be 8%. But if you press the trim button, you will disable this correction and the real input jumps to your absolute position of the cyclic control.

 

There is no "20% input vakuum" around the trimmed position as you think. Look at the pic below... :joystick::thumbup:

 

Nice. This would actually explain everything. But:

1. If that was the case then the AP would not have the authority to counter the exact same pilot input in Hover mode while trying to go back to the earth reference point. And it does. Tested.

2. The "jump" would be equal to the 20% of the user input. While in real life the jump is equal to the amount of pitch/bank you caused on the plane. Pitch the heli forward by 5%, trim, it jumps by another 5%. Pitch it by 15%, trim, it jumps by another 15%.

 

EDIT: Ok, I agree that the 2nd point might actually be very subjective. About the amount of the jump. But what about the 1st? If the AP is only correcting 20% of your input it would never have the authority to correct you for the hover mode. And it really does. Stabilize yourself in perfect hover, enable Hover AP and move the cyclic slightly to the left. It will counter it and go the right bank until it gets back above the datum earth point.

Besides in the rest of the AP modes it would never be able to do anything when you don't move the stick. 20% of zero is zero.

Edited September 25, 2013 by Havner

[Fishbreath]

But pilot input is actually causing the roll/yaw to move away from the datum as well. And as you said yourself that it's the same for roll/yaw (pitch/bank) so it should try to move it back.

 

In my experience, the autopilot will actively fight me in pitch (to maintain my set speed) as well as bank and yaw (more slowly, for whatever reason) while I'm in route mode. (Even if I'm remembering wrong, that's not necessarily an inconsistency—it might just be a Kamov design choice, or a design limitation.) It doesn't appear to be fighting in the standard trimmed mode because of the point below.

 

I'm not sure I understand you here. Are you saying that AP has more authority to overcome external causes then the pilot input? Or are you saying that it takes time for it to do so?

No, I'm saying that the amount of input the autopilot will use to correct a difference from the set point depends on how big that difference is. A small error causes a small input from the autopilot, and a large error causes a larger one, but by the time you've reached a large error, you're pulling more than the autopilot's full authority anyway.

 

Between route/hover modes and trimmed mode, the autopilot function is fundamentally different. Trimmed autopilot mode is counteracting errors from a defined correct attitude. Route mode is actively trying to hold a set of flight parameters, and errors in flight parameters are not the same as errors from a defined attitude. Flight parameters such as speed, heading, and altitude are the integrals of attitude changes, so holding a nose-down attitude or enough rudder to change course rapidly builds enough error for the autopilot to use its maximum authority.

[Havner]

In my experience, the autopilot will actively fight me in pitch (to maintain my set speed) as well as bank and yaw (more slowly, for whatever reason) while I'm in route mode. (Even if I'm remembering wrong, that's not necessarily an inconsistency—it might just be a Kamov design choice, or a design limitation.)

 

Ok, up to here we have a full understanding.

 

It doesn't appear to be fighting in the standard trimmed mode because of the point below.

No, I'm saying that the amount of input the autopilot will use to correct a difference from the set point depends on how big that difference is. A small error causes a small input from the autopilot, and a large error causes a larger one, but by the time you've reached a large error, you're pulling more than the autopilot's full authority anyway.

 

Sorry, I still don't understand. Let's get some facts here.

The reference points for trim/hold/default AP mode are pitch/bank/heading/altitude. No speed. Let's just focus on the first 2. AP has 20% of authority. I move the cyclic by a very little ammount. Just enough to see the nose move (let's say pitch down). So the autopilot has to use only small input to counter it and try to get back to the refence pitch? That's what are you saying? So why doesn't it use it? I'm not increasing the error during the test. I move the cyclic by small ammount, the nose pitches down by small ammount and I keep it like this.

 

Between route/hover modes and trimmed mode, the autopilot function is fundamentally different.

 

Agreed as the game shows. Just trying to get the facts here.

 

Trimmed autopilot mode is counteracting errors from a defined correct attitude.

 

Isn't small user input also an error for the AP? It's defined correct attitude is changed by it.

Edited September 25, 2013 by Havner

[Fishbreath]

Sorry, I still don't understand. Let's get some facts here.

The reference points for trim/hold/default AP mode are pitch/bank/heading/altitude. No speed. Let's just focus on the first 2. AP has 20% of authority. I move the cyclic by a very little ammout. Just enough to see the nose move (let's say pitch down). So the autopilot has to use only small input to counter it and try to get back to the refence pitch? That's what are you saying? So why doesn't it use it?

 

<snip>

 

Isn't small user input also an error for the AP? It's defined correct attitude is changed by it.

 

Yes, a small error is an error that the autopilot will correct. On the first paragraph, I'm afraid we're still talking past each other. I did just think of an example, though.

 

Say you're landing the Su-25T (or anything with ILS). You notice that you're a little below the glideslope. You don't go to full throttle and full back stick to correct, however, even though you have that much control authority—you add a little throttle and a little bit of back stick. In other words, you elect to make a small correction, even though you have more control authority to use, because you're only correcting a small error.

 

That's what the autopilot is doing. It will only use a small amount of control input to correct small errors—it has the nominal capability to use more authority, but its programming is such that it will never use it to correct errors below a certain size. When you introduce a small error with stick pressure, however, you're confusing the autopilot—your manual control input is greater than the amount of correction the autopilot is programmed to use for the size of the error you've induced. To make it more concrete, say you hold 10% controls against the autopilot, inducing a five-degree pitch error. (I'm just making up numbers, but it's not important for the answer here.) "Oh," the autopilot says, "I only need to use a 5% control input to correct for five degrees of pitch error." As you're ramping up to your 10% input for five degrees of pitch, it's ramping up to its 5% of input for five degrees of pitch. You'll always win.

 

If the autopilot worked a little differently, ramping up its correction inputs to its maximum authority if the original correction inputs failed to bring the attitude back to the set point, it would behave like you're expecting.

[Flagrum]

For the situation "pilot banks 5°, AP counters -5° --> effective bank = 0° --> stable bank"

 

I think this is just by design: to allow the pilot adjustments while perfectly stabilized. Otherwise, if the AP would always use it's full authority to counter every deviation of the desired attitude, the pilot's stick would be dead for +-10% of it's respective current position. Quite annoying and dangerous if you ask me. :o)

 

But this is only an opinion of mine, not bases on any hard evidence, though.

[Havner]

That's what the autopilot is doing. It will only use a small amount of control input to correct small errors—it has the nominal capability to use more authority, but its programming is such that it will never use it to correct errors below a certain size. When you introduce a small error with stick pressure, however, you're confusing the autopilot—your manual control input is greater than the amount of correction the autopilot is programmed to use for the size of the error you've induced. To make it more concrete, say you hold 10% controls against the autopilot, inducing a five-degree pitch error. (I'm just making up numbers, but it's not important for the answer here.) "Oh," the autopilot says, "I only need to use a 5% control input to correct for five degrees of pitch error." As you're ramping up to your 10% input for five degrees of pitch, it's ramping up to its 5% of input for five degrees of pitch. You'll always win.

 

So basically assuming that the autopilot goal is to keep the pitch angle constant (if it has the authority) it is choosing wrong strength for the adjustments. That's what I'm reading from your post.

It wants to correct the full 5 degrees of my pitch change but is choosing wrong ammount of authority to do so. That only means that it's bugged. If it wants to achieve a designed goal and it doesn't that's pure definition of a bug.

 

If the autopilot worked a little differently, ramping up its correction inputs to its maximum authority if the original correction inputs failed to bring the attitude back to the set point, it would behave like you're expecting.

 

I'm not saying it should use its maximum authority. It should use as much as it needs to achieve its goal

 

For the situation "pilot banks 5°, AP counters -5° --> effective bank = 0° --> stable bank"

 

Ok, this actually got me thinking whether we are on the same ground in terms of bank/roll, pitch/yaw definitions. Bear with me as I'm not native English obviously. I do understand those terms as a constant angle between heli position and let's say the horizon.

 

Am I right? Or those terms mean (in terms of AP) that the delta of this angle is kept zero. Meaning that there is no side or forward roll. The heli just keeps the angle steady. Whatever the angle is.

 

I think this is just by design: to allow the pilot adjustments while perfectly stabilized. Otherwise, if the AP would always use it's full authority to counter every deviation of the desired attitude, the pilot's stick would be dead for +-10% of it's respective current position. Quite annoying and dangerous if you ask me. :o)

 

Yes, with this I agree. I'm not saying it should behave any differently. I'm saying two other things:

1. I expected it to behave differently reading all the docs and reports of pilots "fighting" the AP in the hold mode (when there is no fighting if it behaves the way we talk about it).

2. If it really behaves that way I don't get the jump after I trim it in such situation.

 

When I push the stick forward it's not countering me, it just stabilizes itself around new reference point set by my stick. After it does stabilize it it shouldn't use any constant authority to keep it at that point. Or more generally it would be possible to implement it this way. You move the stick -> the reference point of pitch/bank angle against the horizon is shifted, AP stabilizes itself around new reference point. I hit the trimmer -> no jump.

Edited September 25, 2013 by Havner

[Fishbreath]

So basically assuming that the autopilot goal is to keep the pitch angle constant (if it has the authority) it is choosing wrong strength for the adjustments. That's what I'm reading from your post.

It wants to correct the full 5 degrees of my pitch change but is choosing wrong ammount of authority to do so. That only means that it's bugged. If it wants to achieve a designed goal and it doesn't that's pure definition of a bug.

 

I'm not saying it should use its maximum authority. It should use as much as it needs to achieve its goal

 

It may be designed in a way you disagree with, but as far as I know, it's not bugged in the slightest. It's not 'choosing the wrong amount of authority', it's using the amount of authority required to achieve its goal in normal circumstances. Adding control inputs against the autopilot counts as abnormal circumstances, and there is no ordinary situation—by which I mean a situation you'd encounter while within the limits of the helicopter's flight envelope—where the autopilot would ever need to use as much control authority as it would need to to correct a pilot-induced error.

 

Designing it to use the required amount of authority, up to its maximum, in any circumstances would be significantly harder. The autopilot would have to not only keep track of total error but also its past inputs, and be able to change its control inputs in an instant if the pilot releases the stick (or else it would overshoot and swing past the set point). It would also have to distinguish between error because of pilot-induced control inputs and error because of changes in the environment. The only thing a proportionally responding autopilot has to know is current deviation from the assigned settings.

 

If you want it to behave that way, you can, as we've been over, use untasked route mode to fly around—because constant errors in attitude cause up to increasing errors in course and speed, it ramps up its responses as you add input. As it is, the trimmed autopilot is the way it is because it's much, much easier to design and implement, especially for a vehicle as complicated to control as a helicopter.

[Fishbreath]

Sorry for the double post; there were some other things I wanted to respond to.

 

1. I expected it to behave differently reading all the docs and reports of pilots "fighting" the AP in the hold mode (when there is no fighting if it behaves the way we talk about it).

 

Fly a little in flight director mode, then switch on hold mode. Compared to flight director mode, holding an attitude that isn't the one you've assigned is clearly 'fighting'.

 

When I push the stick forward it's not countering me, it just stabilizes itself around new reference point set by my stick. After it does stabilize it it shouldn't use any constant authority to keep it at that point. Or more generally it would be possible to implement it this way.

 

It doesn't stabilize itself. It never stabilizes on a new attitude without using the trimmer. The autopilot is still trying to return the helicopter to the set attitude, but it doesn't have sufficient control authority to do so. The sum of the control forces is the autopilot's stabilizing force subtracted from your stick force.

 

Here's an experiment, actually: fly in trimmed autopilot mode. Turn on the Ctrl-Enter controls indicator. Push the nose down without trimming, and note where the cyclic indicator is. Center the controls and switch to flight director mode, then make control inputs such that the cyclic indicator is in the same place. You'll find that the same control inputs, given without fighting the autopilot, yield a much more aggressive maneuver.

[Havner]

it's using the amount of authority required to achieve its goal in normal circumstances

 

Ok, but what exactly is its goal in Hold mode? You seem to have some knowledge. Would you care to comment on the second part of my previous post?

 

Adding control inputs against the autopilot counts as abnormal circumstances,

 

The pilot of BS is never ever supposed to do a slight movement of a cyclic to change its pitch/bank without hitting the trimmer first? I find it hard to believe. To navigate, fly a course. For sure. But eg. for a landing I don't agree. I can land spot on with FD. But still, it's easier to do with moving the cyclic around a centered hover/trimmed point without touching the trimmer.

 

EDIT:

 

Ok, you already answered for the second part :-)

 

Fly a little in flight director mode, then switch on hold mode. Compared to flight director mode, holding an attitude that isn't the one you've assigned is clearly

 

I do fly in both sometimes. I know the difference. But I would never ever call it fighting. You fight in route mode. That's for sure. Not in hold. It is different, but AP doesn't counter.

 

It doesn't stabilize itself. It never stabilizes on a new attitude without using the trimmer.

 

Actually it does. Sort of. It doesn't move or is not unstable.

 

The autopilot is still trying to return the helicopter to the set attitude, but it doesn't have sufficient control authority to do so. The sum of the control forces is the autopilot's stabilizing force subtracted from your stick force.

 

Again. This is the part of your explanation I don't get. Why it doesn't have it while:

1. I added very little stick movement. 3-5%?

2. It has enough authority to counter my movement in Hover mode.

 

So the famous 20% of authority means something different for Hold and Hover/Route?

 

Here's an experiment, actually: fly in trimmed autopilot mode. Turn on the Ctrl-Enter controls indicator. Push the nose down without trimming, and note where the cyclic indicator is. Center the controls and switch to flight director mode, then make control inputs such that the cyclic indicator is in the same place. You'll find that the same control inputs, given without fighting the autopilot, yield a much more aggressive maneuver.

 

I already did that experiment. I know what you mean. But still for small cyclic movements I don't understand why there isn't enough authority.

This really could have been implemented in a way that stick movemenet without a trim in such case just moves the reference point and AP stabilizes itself around it.

And in a case pilot decided: "yes, I want to trimm after all" and he hit the trim the jump would not occur.

Edited September 25, 2013 by Havner