Jump to content

A/C goes nose up when activating autopilot


Recommended Posts

vor 55 Minuten, CRJay sagte:

"it's a sim problem, we wash our hands of this"

And this is your interpretation exactly why?

 

Of corse the DEV will file a BUG report to ASOBO BUT...meanwhile you can test it by yourself and if it's true, then you would be doing a great community job to open a thread and even file a bug over at MS.

  • Upvote 1
Link to comment
Share on other sites

Thank you very much for investigating the issue! I'm so glad that there is finally some progress. Let's hope that Asobo will be able to fix the bug. Given that you are partners, I hope the issue has a high priority for them. Or do we need to create a topic in the MSFS forums and vote for it?

Link to comment
Share on other sites

40 minutes ago, GEK_the_Reaper said:

And this is your interpretation exactly why?

 

Because there is a track record of handling issues this way here.

  • Like 1
  • Upvote 2
Link to comment
Share on other sites

vor 8 Minuten, CRJay sagte:

Because there is a track record of handling issues this way here.

So if you were to develop a SW that runs on WIN and DEV it following strictly the WIN SDK, and you were to find out that WIN is messing with your code, would you go ahead and insert all sort of workarounds, with every WIN release just to overcome the problem, or would you file tickets to WIN DEV to inform that the platform has bugs?

 

**********

And not to mention that the ISSUE can be easely overcome IF you fly the ACFT as I have shown you.

  • Upvote 1
Link to comment
Share on other sites

6 hours ago, CRJay said:

So this it not meant to you personally, but if this becomes an "it's a sim problem, we wash our hands of this" item and no attempt is made to fix it on the addon side of things... I just can't even... :').

I'm not sure what you could do without abandoning the API, which suddenly turns into a developer cost nightmare... maybe set the default trim position to something less likely to stall the a/c for now? or every time you kick the AP in, save the trim position beforehand, and the instant you kick the AP in let the trim run infinitely fast until it reaches the saved value when you can revert to the usual trim speed. You might have to freeze some of the trim controllers while you're doing something like that so there's no spiky input ( I'd hope there's some sort of input filter to trim controllers already anyway ). Maybe there's a way to instantly set trim, I've no idea what's CRJ & what's API specific.

 

I also think we've got at least two different problems in the thread - there's a couple of us talking about the AP going a bit haywire on approach, which is not the particular AP engagement bug.

Link to comment
Share on other sites

3 hours ago, CRJay said:

 

Because there is a track record of handling issues this way here.

What a full of crap post. I downvoted it and I don't do that much, but I also don't hide.  

  • Upvote 5
Link to comment
Share on other sites

vor 22 Stunden , GEK_the_Reaper sagte:

@falcon55 @SinusJayCee @Richard Dastardly @CRJay @jay jay so guys...not realy the news youve been waiting for but here I go.

I raised the issue again in the team and we started to test the behaviour on standard ACFT from ASOBO. It came out that ALL of them (even the CJ4 -non standard ACFT) do the same thing -the time you kick in the AP it will TRIM to the default value and the revert to the state it was.

Interesting finding! I'll do some tests myself and file a bug report :)

Link to comment
Share on other sites

  • 1 month later...

Posted it in another thread, thinking I should post it here too:

 

I would like to contribute to this: OP has complained about the autopilot trim suddenly applying full scale trim after engaging the autopilot, despite establishing the aircraft in straight and level flight with proper trim. To this effect, I have identified the root cause of this issue, and have found it to be 100% reproducible.

 

The issue stems from the fact that the autopilot will remember its last "pitch trim setting" from its last disconnect, and upon reconnection will quickly set the trim to that value before allowing the aircraft to adjust. This gets extremely complicated by the fact that the user still has full authority over the elevator, so if the pilot disconnects the autopilot with the trim and control column "fighting each other", and retrims the aircraft so the control column and trim aren't fighting anymore, the aircraft will want to revert to the previous trim setting upon subsequent re-engagement of the autopilot (thus causing the nose to aggressively pitch up). So here are the steps to reproduce it:

  1. Make sure your aircraft is established in straight and level flight and trimmed properly to eliminate all control forces before engaging the autopilot for the first time
  2. Engage the autopilot in your desired modes (I chose HDG and ALT)
  3. Gradually apply nose down command on the joystick. You'll see the aircraft will slowly lose altitude and the trim will compensate by applying nose up trim.
    1. If you'd like to exacerbate the problem, accelerate the aircraft during this stage from a lower speed to a higher speed (e.g., 200 knots to 310 knots)
  4. Now disconnect the autopilot without moving your joystick, then reestablish your aircraft in straight and level flight.
  5. Once stabilized, re-engage the autopilot without changing the FMA commands (e.g., same heading and altitude hold as prior).

If you do this right, you will see the trim jump spectacularly to its previous value. Every time I've done this, I always ended up with the same result.

 

(activate closed captions for step-by-step explanations)

 

  • Upvote 7
Link to comment
Share on other sites

3 hours ago, SinusJayCee said:

Interesting findings! Did you try to reproduce this with default MSFS planes as well?

I tried reproducing it with the default CJ4. I found that, although the trim does behave the same way on those aircraft (jumping to its previous value in a fraction of a second), those aircraft’s autopilots are also very reactive with the trim.

 

So with default you see the trim jump to its old value and right back down to where it should go, which causes a minor undulation which is barely perceptible. The CRJ, on the other hand, has the trim jump sharply to a new value and slowly return to its correct value, and during this time - without intervention - the aircraft will gain a few thousand feet.

 

All in all, the CRJ’s autopilot needs a major overhaul.

  • Like 1
Link to comment
Share on other sites

The core issue is however, that the default AP returns to the previous trim, which is something that Asobo should fix. The CRJ is just more affected than other aircraft. Have you considered reporting your findings to Zendesk?

  • Like 1
Link to comment
Share on other sites

1 hour ago, falcon55 said:

The core issue is however, that the default AP returns to the previous trim, which is something that Asobo should fix. The CRJ is just more affected than other aircraft. Have you considered reporting your findings to Zendesk?

There are two possible solutions here:

  1. Ask Asobo to make trim control more realistic on their aircraft. Of course, Asobo's philosophy is one autopilot for all, which can be a bit of a stretch to connect a two-axis C172 Autopilot to an Boeing 747's (I won't touch on the A320 since it's not even in the same ballpark). Nonetheless, whatever changes they make will have to be thoroughly researched since you have to apply the appropriate reactivity to each aircraft, after which Aerosoft will have to make the appropriate changes to the autopilot anyways.
  2. Ask Aerosoft to split their own autopilot off and design it to meet their requirements. This is more burdensome on Aerosoft, but doesn't require Asobo to revisit every single one of their aircraft.

The decision at the beginning of the CRJ project seemed to be to rely on Asobo's implementation of the autopilot. My post simply makes the case against that, and recommends that Aerosoft pursue developing and integrating their own autopilot system.

 

Nonetheless, I will make a Zendesk report, since the undulation is barely perceptible on default aircraft, and it just looks sloppy (not as bad as the CRJ gaining a few thousand feet, though).

 

EDIT: I should say, two problematic things with the default autopilot that seem to cancel each other out:

  1. The trim jumps immediately to its last setting upon re-engagement of the autopilot
  2. The trim on default aircraft is lightning-speed, and can go from one end of the range to the other. I think Asobo has opted to use the trim as the primary pitch mechanic for the autopilot and made it far too aggressive.

EDIT 2: I have created Zendesk Request #152158 for this subject, pertaining exclusively to the default aircraft.

  • Thanks 3
Link to comment
Share on other sites

Please login to view this video.

 

 

Same phenomena demonstrated on the Cessna 208 Caravan: applying pitch down nose command causes the trim to want to pitch up in response. If you disengage the autopilot, retrim, and re-engage the autopilot, the trim will jump to its last known value.

  • Like 1
Link to comment
Share on other sites

What makes me feel sad is, that we got a beautiful looking hull with some minimal necessary interfacing to a default autopilot (ASOBO), a average sound implementation (is it 2 or 3 different switch sounds, some don't sound at all)


and payed 50 Euros.

 

I've got far better aircraft simulations on X-Plane for the same amount of money. 
We are speaking about TRIM here, not to mention LNAV and not to forget ILS issues

 

Sorry, but i can't hold it... (1 year after)

  • Like 3
Link to comment
Share on other sites

Am 15.3.2022 um 17:00 schrieb JetNoise:

I've got far better aircraft simulations on X-Plane for the same amount of money. 

Most of those aircraft use the default XP features as well. The difference is that the XP stock systems are more matured than the MSFS ones.

 

Am 15.3.2022 um 17:00 schrieb JetNoise:

We are speaking about TRIM here

In fact, we are speaking of the AP, which is fare more complex than trim.

 

Am 15.3.2022 um 14:36 schrieb amahran:
  • Ask Asobo to make trim control more realistic on their aircraft. Of course, Asobo's philosophy is one autopilot for all, which can be a bit of a stretch to connect a two-axis C172 Autopilot to an Boeing 747's (I won't touch on the A320 since it's not even in the same ballpark). Nonetheless, whatever changes they make will have to be thoroughly researched since you have to apply the appropriate reactivity to each aircraft, after which Aerosoft will have to make the appropriate changes to the autopilot anyways.
  • Ask Aerosoft to split their own autopilot off and design it to meet their requirements. This is more burdensome on Aerosoft, but doesn't require Asobo to revisit every single one of their aircraft.

I see no issue in Asobo fixing their AP, at least regarding this specific issue. It apparently stores some old value trim somewhere and it needs to use the current value instead. This wouldn't change the behavior of the default planes, since the reactivity would remain the same. I.e. instead of jumping to an old value and then more or less instantly trimming to the value calculated by the AP, it would just start at the current value and then to the desired value. For CRJ with a more realistic trim speed this would solve the current issues, because the trim wouldn't jump to a wrong (old) value but remains at the value set by the pilot. After that, the AP can set the trim to whatever it thinks is right. This doesn't require any changes by Aerosoft.

  • Like 1
Link to comment
Share on other sites

vor 3 Minuten schrieb SinusJayCee:

Most of those aircraft use the default XP features as well. The difference is that the XP stock systems are more matured than the MSFS ones.

 

In fact, we are speaking of the AP, which is fare more complex than trim.

 

I see no issue in Asobo fixing their AP, at least regarding this specific issue. It apparently stores some old value trim somewhere and it needs to use the current value instead. This wouldn't change the behavior of the default planes, since the reactivity would remain the same. I.e. instead of jumping to an old value and then more or less instantly trimming to the value calculated by the AP, it would just start at the current value and then to the desired value. For CRJ with a more realistic trim speed this would solve the current issues, because the trim wouldn't jump to a wrong (old) value but remains at the value set by the pilot. After that, the AP can set the trim to whatever it thinks is right. This doesn't require any changes by Aerosoft.

 

I am "with you" 100%.

 

So what is ASOBO waiting for to fix this finally ?. It hasn't been in the latest x Sim Updates ....  
Can't be that hard for the AP issue (s?) .

LNAV is something different and i am still wondering why some simmers experience this and others don't ...

 

Oliver

Link to comment
Share on other sites

vor 59 Minuten schrieb JetNoise:

So what is ASOBO waiting for to fix this finally ?. It hasn't been in the latest x Sim Updates ....  
Can't be that hard for the AP issue (s?) .

I bet they aren't even aware that this is in issue.

 

I also imagine that the fix is quite simple. They probably only need to add

on_ap_engage():
	ap_trim = get_current_trim()

But maybe I'm too naive here ;)

Link to comment
Share on other sites

vor einer Stunde schrieb SinusJayCee:

I bet they aren't even aware that this is in issue.

 

I also imagine that the fix is quite simple. They probably only need to add

on_ap_engage():
	ap_trim = get_current_trim()

But maybe I'm too naive here ;)

 

Here you go
 

 

Link to comment
Share on other sites

On 2/2/2022 at 5:03 AM, GEK_the_Reaper said:

@falcon55 @SinusJayCee @Richard Dastardly @CRJay @jay jay so guys...not realy the news youve been waiting for but here I go.

I raised the issue again in the team and we started to test the behaviour on standard ACFT from ASOBO. It came out that ALL of them (even the CJ4 -non standard ACFT) do the same thing -the time you kick in the AP it will TRIM to the default value and the revert to the state it was.

 

It's hard to see it in the TBM but get in it, take clear skies as weather theme, handfly it to e.g. 5000ft at max speed, trim it so it flies level (it's a a trim down and the trim indicator will be above the green band), kick in AP and you will se the indicator moving down (to it's initial value) then again up.

 

Some ACFT TRIM realy quick, some rather slower and depending to the ACFT and current flight conditions yada yada yada you will see more or less the effect.

 

At this time I would say it's a sim issue...

This would be a fine explanation for something like the Twin Otter, which was kept stock as much as possible, however it's been touted on the forums here that the CRJ autopilot contains lots of custom code because the stock one wasn't satisfactory.  I learned this the hard way when I, as a new user to AS products and sims in general, came in last summer asking why my Logitech panel using Logitech drivers didn't work right with the CRJ, and I did not exactly receive a warm welcome.

 

So is there really no way to fix this internal to the CRJ?

Link to comment
Share on other sites

On a slightly different note, to the people saying Simbrief ZFW doesn't match the CRJ ZFW, by default Simbrief includes about 55lbs of baggage with each passenger before anything you set for cargo/baggage weight on the flight.  You can change that on an aircraft level.

Link to comment
Share on other sites

Am 18.3.2022 um 15:42 schrieb Joe Markowski:

So is there really no way to fix this internal to the CRJ?

I will answer you (since you quoted me) but I'm unsure what to tell you. I'm not affiliated with AS in any way so this is purely my gues.

 

AS offer a wide range of products and I think they focus to fix major issues as they arrise. Since MSFS is a "work in progress" most updates come with improvements but also issues. If AS will always hunt issues introduced with the sim, implement a workaround, wait till the workaround no longer works due to a fix from ASOBOs, then remove the workaround (or implement other workarounds for new issues)....they won't be able to do anything else ;) .

 

Now since:

- we identified that this AC behaviour is sim related

AND

- since it can be overcome if you understand what happens (I even posted videos of perfectly smooth flights)-

 

I suppose it is not top priority to generate a fix for it (PLEASE UNDERSTAND THIS IS PURELY MY GUESS).

I know other issues that are beeing worked on (not SIM related but CRJ related).

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

I can confirm, that this issue has been greatly improved with the latest update. You no longer have to fear for your life when turning on the AP. Thank you very much, Aerosoft!

  • Upvote 3
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