Jump to content

A/C goes nose up when activating autopilot


Recommended Posts

vor 3 Stunden , Seekay sagte:

I got my fuel and weights from Simbrief, the flight plan indicated that they were within limits, and I loaded the plane using the EFB's ZFW mode which (presumably) should set the CG correctly and notify me if there's a problem. I don't pay much attention to the CG indicator, I just trust the numbers Simbrief gives me, but I'm absolutely certain that I've never seen the indicator go beyond the takeoff, landing and approach CG limits.

SimBrief doesn't care about CG. It just gives you the weight (payload/ZFW, whatever you are looking for) and assumes you set the CG correctly. However, when the plane is loaded using the EFB's ZFW mode, the CG should have been set correctly and within the limits. With the passengers/cargo mode you can mess things up.

 

vor 3 Stunden , Seekay sagte:

I didn't check the attitude but I was climbing straight ahead with the HSI centered at 290 knots and had the autopilot speed bug set to 290 so I should've been right on the FD, no?

If you have speed mode enabled, speed bug set set to 290 and were actually flying at 290kt, you should have been exactly on the FD (at least regarding the attitude). But has the plane been trimmed for that attitude as well?

 

vor 11 Minuten, TomAce sagte:

If you use the original SimBrief profile for the CRJ, you will get the wrong ZFW. SimBrief set the passenger weight differently than the CRJ which again conflict with the EFB and FMS. SimBrief passenger weight includes bags, but the CRJ adds more weight in addition to the passenger weight and therefore the ZFW will be wrong.

Note that the SimBrief profile in the download section here is off as well.

 

*edit*

I just checked the profile and it in fact uses 84kg per passenger. However, when setting the number of passengers suggested by SimBrief using the EFB, the ZFW was way above what was calculated by SimBrief. I need to check this again and try to figure out the issue.

Link to comment
Share on other sites

1 minute ago, SinusJayCee said:

SimBrief doesn't care about CG. It just gives you the weight (payload/ZFW, whatever you are looking for) and assumes you set the CG correctly. However, when the plane is loaded using the EFB's ZFW mode, the CG should have been set correctly and within the limits. With the passengers/cargo mode you can mess things up.

 

If you have speed mode enabled, speed bug set set to 290 and were actually flying at 290kt, you should have been exactly on the FD (at least regarding the attitude). But has the plane been trimmed for that attitude as well?

 

Note that the SimBrief profile in the download section here is off as well.

The best thing I learned with the CRJ is that the weight & balance must be correct. The ZFW must be correct in the FMS and EFB, and I like it to be on point with my flight plan from SimBrief as well.

Link to comment
Share on other sites

vor 7 Minuten, Kamil M sagte:

I would suggest we stay on topic here with  OP issue  not ZFW ….

This is directly related to the topic. If the ZFW and in particular the CG are out of range, there is a pretty good chance that this results an unstable flight situation even without any bug or issue. (Which doesn't mean that there is no issue.)

Link to comment
Share on other sites

1 hour ago, Kamil M said:

I would suggest we stay on topic here with  OP issue  not ZFW ….  @Mathijs Kokcould you please update us if the team was able to address that AP behavior ? Any possible fixes in works ? Thank You 

I had the exact same issue and ZFW was the fix. Don’t know why you suggest this. For me the CRJ works very well now.

  • Like 1
Link to comment
Share on other sites

I have corrected CRJ profile values in simbrief long time ago. My ZFW is accurate as in sim payload . Still the issue is there for me. That is why I think its not related and awaiting some official comments

  • Like 1
Link to comment
Share on other sites

19 minutes ago, Kamil M said:

I have corrected CRJ profile values in simbrief long time ago. My ZFW is accurate as in sim payload . Still the issue is there for me. That is why I think its not related and awaiting some official comments

Ok, I understand. Hope you will find a fix soon.

Link to comment
Share on other sites

vor 15 Minuten, Kamil M sagte:

I have corrected CRJ profile values in simbrief long time ago. My ZFW is accurate as in sim payload.

Just to be sure: I didn't open the MSFS Weight & Balance manager, did you? This can completely screw up the weight and its distribution (in particular empty CG).

 

If we can rule that out, there is definitely something else strange happening for you. As wrote already, I've never seen 10,000ft/min on AP engagement. Again, that doesn't mean that I think that the AP engagement works entirely as expected. The plane increases the rate of climb for me as well when the AP is turned on, but not as severe as it does for you.

Link to comment
Share on other sites

7 hours ago, SinusJayCee said:

If you have speed mode enabled, speed bug set set to 290 and were actually flying at 290kt, you should have been exactly on the FD (at least regarding the attitude). But has the plane been trimmed for that attitude as well?

 

Yes, I was trimmed and hands off at 290 knots.

 

8 hours ago, TomAce said:

If you use the original SimBrief profile for the CRJ, you will get the wrong ZFW. SimBrief set the passenger weight differently than the CRJ which again conflict with the EFB and FMS. SimBrief passenger weight includes bags, but the CRJ adds more weight in addition to the passenger weight and therefore the ZFW will be wrong.

If you set passenger weight in Simbrief profile to 186 pounds/ 84 kg it will be correct. 
When I set this correct my plane stopped the odd behavior when turning AP on and I got correct ZFW in EFB.

 

I use the EFB to set the overall ZFW of the plane (in ZFW mode, you simply enter the ZFW and the amount of fuel and it does the balancing), therefore the numbers given by Simbrief should still be valid as long as the ZFW is less than MZFW and TOW is less than MTOW, which they have been on every single one of my flights. And like I said, I've never seen the CG go out of bounds on the EFB's weight and balance chart.

 

Also, my takeoff trim is always within a few tenths of the center position (7.5) which indicates that the CG is correct; if it wasn't, I would need excessive amounts of trim to compensate for it.

 

Link to comment
Share on other sites

  • 2 months later...

I just tried the newest update and the problem is still there. The autopilot goes nose up into close to a stall after handflying to 10.000 feet. Is Aerosoft still trying to fix the issue?

Link to comment
Share on other sites

22 minutes ago, falcon55 said:

I just tried the newest update and the problem is still there. The autopilot goes nose up into close to a stall after handflying to 10.000 feet. Is Aerosoft still trying to fix the issue?

I have been flying the CRJ since the first release and never seen this problem. And why do you handfly to 10000 ft? You should activate AP at about 600-1000 ft. First press NAV or HDG, then SPEED and then activate AP. 

Link to comment
Share on other sites

Yes, turning on the AP shortly after takeoff is the only workaround to not encounter this issue. The reason for this seems to be that the trim at that time is close to 7.5.

 

But you cannot reasonably suggest that the aircraft should not be handflown? The autopilot is merely a tool to reduce the workload. I like enjoy the experience of actually flying the plane at low level and workload permitting.

  • Like 3
Link to comment
Share on other sites

vor 20 Stunden , TomAce sagte:

And why do you handfly to 10000 ft? You should activate AP at about 600-1000 ft. First press NAV or HDG, then SPEED and then activate AP. 

Not really. First, it is fun to handfly the plane. Second, handflying may be required on certain departures (e.g. LOWI). And third, just because some people activate the AP quite early, it should still be possible to activate it later without any issues.

  • Like 1
Link to comment
Share on other sites

Updated to latest, confirm the AP TRIM jolt still happens. 

Just to reiterate the scenario for developers to understand:
1. Takeoff
2. Handfly

3. Since hand flying, gonna trim nose down to maintain level flight at say 5000ft.

4. Once stable at altitude, engage autopilot with ALT and NAV

5. Look at trim display while doing step (4).

6. You will see the trim jumping back up to default 7.5.......

 

Seems like AP and Manual trim values are two different persistent values....   <--------------- this is the rootcause. AP only persistently remembers the trim that it changes DURING AP is on. So if AP remembers the last AP changed trim to be 7.5, but currently the plane is flying at trim 3.0(cause user handfly and manually trim it), once AP engages it's gonna go all south LOL. 

  • Upvote 1
Link to comment
Share on other sites

  • 2 weeks later...

I've been having this issue since release. Not every time I fly but often enough that it ruins the immersion a lot. I usually engage below 10,000 so maybe that's why it doesn't happen all the time, idk. Anyways, I have the plane at climb speed and trimmed where almost no input is required, A/P setup with speed mode and desired altitude selected, then when I engage the A/P and the plane pitches up and up and up while trim goes down. I let it try to settle it's self, but usually airspeed then becomes too low, and I have to take control, like several thousand feet above where I started. I'll see if I can replicate it with consistency when I fly again.

Link to comment
Share on other sites

  • 3 weeks later...

Still having this same issue. 

 

Note that it doesn't happen after consecutive flights, but when starting up straight from the loading screen, on the first activation of AP, after an extended period of manual flying during climb, (as opposed to engaging shortly after takeoff) there will be a hard pitch-up every time.

 

This will settle down and start flying normally within 30s to 1 min - If AP is engaged during climb with some headroom before altitude capture, there's enough time for it to stabilize and from then on it flies straight. 

 

However, if you engage while capturing or at level flight, the jerk will be quite large enough to force the AP out of capture and it'll be a lot of frantic button pushing to get it back down again. (It usually bumps up about 1000~2000ft, ATC does not like it when that happens)

 

 

Once that first tantrum is dealt with, one may land, setup another flight and take off again so that in such following flights, the issue will not be repeated. 

Conversely, if you return to main menu and start a new flight from there, be prepared to have a tussle with the AP as you first engage it.

 

On my next flight, I will try to engage the AP while taxiing without any modes active (plus variations of this experiment) - We shall then learn if a period of "AP on" time suffices to smooth out the waking throws of this most not-a-morning-person piece of avionics.  This could make for a practical workaround if nothing else...

 

Anyways, the issue seems to be something like an incorrectly initialized internal state of the pitch control loop.  This would explain why it doesn't repeat itself on follow up flights unless you make a main-menu pit stop in between

 

 

I suppose this is very much less noticeable if AP is engaged immediately after T/O mostly due to how the pitch trim at that time is set much further nose-up than it would be further up the climb.  The AP seems to disregard the current trim position and begins tracking down slowly from a much higher setting than the one selected.  This is what causes the "bump" and why it is so much more severe when AP is engaged near cruising speeds than it is right after takeoff.

 

 

 

  • Upvote 1
Link to comment
Share on other sites

I have done experiments and was able to isolate the exact nature and possible fix for the AP pitch up bug.

 

The issue goes as follows and can be easily reproduced even on the ground:

 

Problem:  The internal variable used by the AP to track the pitch trim position does not update while AP is off.

 

Symptoms include:

 

  • Engaging the autopilot in flight conditions where the pitch trim is set significantly far from neutral (such as, during late climb near cruise speeds) will cause an abrupt pitch up maneuver while the AP slowly tracks all the way down from it's last used trim position.
  • On a first flight starting from the loading screen, this internal trim value will be 7.5, regardless of takeoff trim setting and pilot inputs while AP is kept off.
  • If AP is engaged immediately after takeoff, this neutral state is near enough most T/O trim settings that the bump is very subtle and easy to miss.
  • On subsequent non-restart flights, the AP engages with the last trim position it had at the time it was disconnected. As pilots are creatures of habit, that position most often matches the currently set real trim state, and the bump is also minimized.
  • The issue can be easily reproduced while on the ground. Simply select a nose-down pitch setting on a freshly started flight, then engage the AP and observe the trim indicator. Notice how it will snap back to center immediately instead of tracking from the current position. (This snap-back is why the plane pitches hard up in the conditions mentioned above)

 

 This should be simple to fix, having isolated the exact nature and manifestation of the problem.


 

 

Practical Solution:  Ensure that whenever AP is engaged, the variable used to track pitch trim position is first copied from the actual state of trim on the aircraft. Alternatively, maintain a constant track of the trim state regardless of AP being on or off, so that when it's engaged, the internal AP state will match the selected trim position.

 

 

Even if the problem itself extends deeper somehow than a simple flawed initialization of the trim value, its practical effects are such that a symptomatic implementation of the solution above should almost certainly* suffice.

 

Science-minded people will never say "definitely",  even when they almost certainly* mean it. 

 

 

Unfortunately, there is no viable workaround. The AP will always snap the trim to its last used state when engaged.  Pilots can only take (unreasonable to impose) measures to prevent disruption of their flight path, either by engaging AP very early on takeoff while the trim is set near neutral, or by trying to cope with the bump during some part of the ascent where ATC won't mind the jerking.

 

 

  • Upvote 5
Link to comment
Share on other sites

9 hours ago, Moach said:

I have done experiments and was able to isolate the exact nature and possible fix for the AP pitch up bug.

 

The issue goes as follows and can be easily reproduced even on the ground:

 

Problem:  The internal variable used by the AP to track the pitch trim position does not update while AP is off.

 

Symptoms include:

 

  • Engaging the autopilot in flight conditions where the pitch trim is set significantly far from neutral (such as, during late climb near cruise speeds) will cause an abrupt pitch up maneuver while the AP slowly tracks all the way down from it's last used trim position.
  • On a first flight starting from the loading screen, this internal trim value will be 7.5, regardless of takeoff trim setting and pilot inputs while AP is kept off.
  • If AP is engaged immediately after takeoff, this neutral state is near enough most T/O trim settings that the bump is very subtle and easy to miss.
  • On subsequent non-restart flights, the AP engages with the last trim position it had at the time it was disconnected. As pilots are creatures of habit, that position most often matches the currently set real trim state, and the bump is also minimized.
  • The issue can be easily reproduced while on the ground. Simply select a nose-down pitch setting on a freshly started flight, then engage the AP and observe the trim indicator. Notice how it will snap back to center immediately instead of tracking from the current position. (This snap-back is why the plane pitches hard up in the conditions mentioned above)

 

 This should be simple to fix, having isolated the exact nature and manifestation of the problem.


 

 

Practical Solution:  Ensure that whenever AP is engaged, the variable used to track pitch trim position is first copied from the actual state of trim on the aircraft. Alternatively, maintain a constant track of the trim state regardless of AP being on or off, so that when it's engaged, the internal AP state will match the selected trim position.

 

 

Even if the problem itself extends deeper somehow than a simple flawed initialization of the trim value, its practical effects are such that a symptomatic implementation of the solution above should almost certainly* suffice.

 

Science-minded people will never say "definitely",  even when they almost certainly* mean it. 

 

 

Unfortunately, there is no viable workaround. The AP will always snap the trim to its last used state when engaged.  Pilots can only take (unreasonable to impose) measures to prevent disruption of their flight path, either by engaging AP very early on takeoff while the trim is set near neutral, or by trying to cope with the bump during some part of the ascent where ATC won't mind the jerking.

 

 

 

This makes sense. I always wondered why the plane aggressively pitches down when I engage the autopilot and speed mode after takeoff. If I'm doing 160-180 knots in the early climb with the throttles at TOGA or CLB, I'll have a significant amount of nose up trim dialed in and the autopilot is just ignoring that and going back to neutral trim, causing the nose to drop.

Link to comment
Share on other sites

16 minutes ago, Seekay said:

 

This makes sense. I always wondered why the plane aggressively pitches down when I engage the autopilot and speed mode after takeoff. If I'm doing 160-180 knots in the early climb with the throttles at TOGA or CLB, I'll have a significant amount of nose up trim dialed in and the autopilot is just ignoring that and going back to neutral trim, causing the nose to drop.

 

Yes, I have also verified that the problem does indeed happen both ways - So if you had your trim set above neutral, it'll pull down when you engage the AP (on your first flight, otherwise, it depends on where the trim was when you last disengaged it)

Link to comment
Share on other sites

I am running into the same issue. Manually climbing to 10.000, level off and set Auto Pilot. AP is climbing rapidly 2-3 thousand feet and then levels off again.  Only ALT + NAV are active. I didnt have that behavior in the beginning I think, but at some point started to use the TOGA Button at take offs, what sets the Flight Director indicator nose up. Tried without TOGa Button and the AP worked. May be just a coincidence 🙂

Gabriel

Link to comment
Share on other sites

3 hours ago, Gabriel Furchert said:

I am running into the same issue. Manually climbing to 10.000, level off and set Auto Pilot. AP is climbing rapidly 2-3 thousand feet and then levels off again.  Only ALT + NAV are active. I didnt have that behavior in the beginning I think, but at some point started to use the TOGA Button at take offs, what sets the Flight Director indicator nose up. Tried without TOGa Button and the AP worked. May be just a coincidence 🙂

Gabriel

 

If your second attempt was done after having landed and taken off again without returning to the main menu, then it was most likely a coincidence that it worked normally.

 

It would have had a less abrupt pitch up the second time not because of the non-usage of TOGA, but because the AP's internal trim position wouldn't be as far off from the actual setting on the aircraft at the time of engaging.

 

 

I've explained it here how the AP fails to keep up with trim changes while it's disconnected, and how this results in the abrupt pitch-up maneuver we've all experienced.    

 

It's a simple problem, but with quite complex results.  That's possibly why it took so long for us to figure out just what was happening.  But it should be just that, really.  Several more flights here have only further confirmed the issue being just as I've stated above.

 

 

To sum it up again in slightly different words, this is what this bug really is:

 

When you press the AP button to turn it on, the pitch trim will instantaneously snap to the last position it had when you disengaged it. (Which is neutral on your first flight since loading up the sim)

 

Having snapped to this old position, the AP then slowly moves the trim towards stabilizing the aircraft.

 

If you were flying fast with a lot of nose-down trim, that will cause a major pitch up motion on your first flight. (you can try and counter it with the yoke by pushing against the AP and releasing very gently, it works as often as not)

 

Conversely, if you had disengaged AP at a high/fast cruise and put it back on again shortly after your next takeoff, when you're low and slow, the resulting pitch down motion just might end up with the plane being used for a tunnel boring machine.  

 

You can avoid too much trouble by anticipating what it'll do depending on where your trim is now and where it was back when you last shut off the AP. If it's lower, be ready for a hard-up, if higher, expect a nose-dive.  Hold it steady with firm yoke pressure and very gently return it to center as the AP settles down.  It takes some 30s for it to stop fighting, after that it'll fly more or less normal until the next round

 

 

These are experimentally verified behaviors which serve to confirm my findings on the real nature of this issue. Until the fix comes along, keep this in mind and be extra careful when you set the AP on.  It also helps to make sure you have that seat belts sign on before you push the button...

Link to comment
Share on other sites

I posted a couple days ago but my experience was when I was coming into land, flaps 20 but letting the airspeed drop too low. The aircraft would pitch up and up. I’d I disconnected AP and re-enabled it once I had recovered some altitude and the airspeed it would snap the nose up causing me to stall.

Link to comment
Share on other sites

I have been experiencing this issue for months, and just had it happen now. Had the plane trimmed out to follow the FD, and once I engaged AP it set max trim and started climbing like a rocket. Happened in Vs mode as well, even trimmed out. Why haven't we seen a fix yet? The only thing we've gotten is either its pilot error, and "we're looking into it". This makes the aircraft almost unflyable.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

Just wanted to add that I'm experiencing exactly the same as described above - hand fly most of the departure up to 10k+ ... properly trimmed and on course. Engage AP (vertical mode SPD 290 ... speed at which I'm already flying and trimmed for) and get a violent pitch up, lose 60+ kts and have to force the nose down.

 

Appreciate Aerosoft are a little busy at the moment with the Twotter fixes but would be good to have at least an update on fixing this one.

 

Cheers! 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use