I fly Acro all the time (migrated over from Betaflight), and notice this Yaw alignment quite frequently. Let me know if want the log. And yes it has almost made me crash on a few aggressive takeoffs. I’m running v4.7
The issue is the attitude control which comes from the EKF. On all my logs the reason is large mag interference at takeoff. I still think we could do better, but Leonard and Paul have convinced themselves that at least the right thing is happening. If you use rate acro - Mode Rate Acro by andyp1per · Pull Request #30570 · ArduPilot/ardupilot · GitHub - you won’t experience this.
Well it’s definitely applying correction, but I feel that any automated correction whilst not in a Nav Mode really takes control away from the pilot. It is prioritising heading accuracy over control, and I really feel this should be a background correction. (I bet the Boeing engineers who introduced MCAS have changed their mind too). I like the sound of the pull request you attached. I’m not familiar with including custom pull requests in Ardu that haven’t yet been merged . Can I reference it or something in the build tool?. Are there any parameters to look out for or is it just a case of “go fly”?
Don’t try it yet! It crashed last time I tried it, but I am hoping I have it right now.
I agree with you about the pilot correction.
1 Like
I am thinking that “EK3_MAG_CAL =4” might be the best interim measure?
Yes, certainly that will improve things - sorry should have mentioned that, I use it on all my quads
1 Like
Hi Andy how is this PR coming along?
I’m afraid there is no PR, the yaw alignment occurs because of interference on takeoff - usually MAG. I think the EKF could handle this more cleanly but its not wrong. The way you can avoid this fully is by using rate-only acro.
Sorry I meant the rate-only acro PR. Last time you mentioned is was still a work in progress
4.6.2\4.7.0 Copter, RM3100
During GPS spoofing, the compass heading changes if the value ek3_src1_posxy,3 is set. Changing the existing parameters does not change the situation.
Why does the GPS change the compass value if ek3_src1_yaw = compass?
EK3_MAG_CAL,4 (0-4 testing)
EK3_GSF_USE_MASK,0
EK3_POS_I_GATE,300
AHRS_YAW_P,0.4
It’s working - Rate acro with scaled I-term by andyp1per · Pull Request #31171 · ArduPilot/ardupilot · GitHub
1 Like
Excellent, can’t wait for this one to be merged so I can give it a try!
Andy, does this new acro mode bypass any influence of the accelerometer ( like in Betaflight)? The reason I ask is that from time to time my quad freaks out after a few successive aggressive flips. I suspect that the accelerometer sometimes gets upset during these manoeuvres
Yes-ish. It reduces the influence of the EKF which is what drives attitude control and is what consumes accelerometer data. Its not possible to completely evade the EKF but this comes close. The problem you describe is often caused by the EKF learning bad accel biases during aggressive maneuvers - you can reduce the effect of this by reducing EK3_ABIAS_P_NSE - for instance I use 0.001 on my copters. But note also that if you reduce gyro/accel learning the need for doing an IMU temperature calibration increases.
1 Like
Thanks, I’ll give that a try
Hey Andy I can see that it’s merged now. What are the parameters to enable it once I adopt this new build?
ACRO_OPTIONS = 2
Note though that there appears to be a bug - AC_AttitudeControl: yaw I scaling should use Z-axis by andyp1per · Pull Request #31226 · ArduPilot/ardupilot · GitHub
1 Like
Understood, thanks. I have my eye on the thread
I have loaded the latest firmware with this feature and noticed some Lua scripting errors that weren’t there with the previous 4.7 build. It errors on an attempt to use the function”vehicle:get_mode()”. I know the previous version of this PR used a new flight mode for MODE_RATE_ACRO and was wondering if there was a logic error introduced when you backed that part out
There were no scripting changes in this PR - its likely to be something else.