EKF Lane Switching, Vibration Compensation and GPS/Compass Errors at ~30 m/s in Loiter

ArduCopter Copter 4.6
1

Hi everyone,

I am trying to diagnose an issue with a 10-inch FPV quad running ArduCopter. The build is:

  • Flight Controller: Matek H743 V4
  • GNSS: Matek M9N-G4-3100
  • Motors: 3120 900KV
  • Battery: 6S
  • Propellers: 10x10
  • Firmware: ArduCopter 4.6.x
  • Frame: 10-inch FPV

I have completed the initial tuning and the aircraft flies quite well in general. I do not see any obvious stability problems during normal flight. The problem occurs when flying in Loiter at approximately 30 m/s and I brake. Hard braking manoeuvres from ~30 m/s in Loiter reliably trigger a cascade of events: an EKF3 primary-core lane switch, followed within milliseconds by a GPS Glitch or Compass error flag, followed exactly 1.0 second later by Vibration compensation ON. Handling degrades noticeably until vibration compensation clears roughly 40-60 seconds later. Looking for a sanity check on the diagnosis and any known mitigations before I keep pushing this build’s speed envelope.

GPS placement

I initially suspected electromagnetic interference from the battery and power wiring, so I moved the GPS further away from the battery, ESC/power wiring and harness but is did not solve the problem.

What I’ve ruled out via log analysis

  • Compass interference: raw field magnitude rock-stable (~488-495) through the entire event, no anomaly
  • Vibration: VIBE stayed well within healthy range (nowhere near the ~30 threshold), zero clipping events, and no asymmetry between IMU0 and IMU1 (near-identical mean/max on both, in general and during the braking window specifically)
  • EKF3 innovation consistency (XKF4.SV/SP/SH/SM): all stayed below the 1.0 fail threshold in the logged samples around both occurrences

I would appreciate some guidance from the ArduPilot/EKF developers on what could cause this behaviour and how can I resolve it.

Flight Logs are attached here

Thanks in advance

2

@rmackay9 @andyp1per @Leonardthall @Eosbandi , kindly suggest how gps glitch error leading to “vibration compensation on” during braking be ‘resolved’. Actually, it results in loss of control for few secs till vibration compensation off msg is displayed. It is worth noting that fpv speeds arent quite high at present while vibe levels are very low during the flight.

Regards

3

You will get vibration compensation when the EKF altitude goes bad - so may be nothing to do with vibration. I have seen this with excessive baro variance. Its not enabled in acro. I think the detect/release mechanism needs some work - it detects within a second but then stays active for 15s even if the problem has passed.

4

Hi @Yasir_khizar,

I think we’d need to see a log before we can say anything but as Andy says the description sounds like the EKF is getting unhappy for some reason.

BTW, vibration compensation can be disabled as described on the wiki but it’s probably better to look first at the hardware.

5

I would not call VIBEs at 15 during the pitch at -40 “very low”.

But what happens looks to me like deep altitude controller oscillations, with motor outputs frequently reaching minima which disappointed the attitude controller as well. These continued in AltHold, so this is most likely irrelevant to GPS, although the somewhat reduced severity on switching to AltHold indicates that position controller was somewhat contributing to the oscillations.

newplot
newplot1915×1378 442 KB

As for why exactly this gets triggered… the obvious answer “braking forced throttle to zero and still was not happy” appears to be not exactly valid as the oscillation startup does not get motor outputs to minima yet. So at the moment I don’t really have anything resembling cause analysis, just few pointers.

6

Except for PSC_ACCZ_P&I why don’t you try returning the other PSC parameters to default (like Jerk_Z) and see what happens.

Not that it relates to this issue but take another look at the Notch filter. The BW is way to high for multi-source.

7

What I also tend to see is that the altitude estimation is definitely having some fun.

First and foremost, during oscillations the barometer is in an opposite phase compared to the rest of the system. (The top three plots are scaled such that higher means higher; EKF and althold controller are upside down wrt that). This likely means it’s too sensitive to propeller (negative) pressure contributions: high throttle increases the perceived altitude.

newplot
newplot1915×1378 374 KB

Yet another thing is that Lane 1 aka XKF[0] - the currently active lane - is (probably?) overestimating the magnitude of altitude changes, whereas Lane 2 aka XKF[1] is showing something more correlated to GPS inputs.

For the altitude and vertical speed, they use the same sources apart from the accelerometers (am I right here? seems so), but for accelerometer measurements, there is a slight but noticeable difference on X and Y axes as follows:

newplot-acc
newplot-acc1915×1378 525 KB

I am still not exactly sure what to make out of it, except that you definitely want a better barometer positioning.

Notch is somewhat misconfigured as @dkemxr mentioned, I would also add that FM_RAT=1 is suboptimal on FPV machines, but I do not think these problems are because of it.

8

Thanks for taking a look, and for the pointer on FS_VIBE_ENABLE — appreciate the input.

On the hardware side, here’s what’s already been checked/mitigated ahead of this reply, in case it saves you some digging:

  • Vibration: VIBE.X/Y/Z stay well within the healthy range throughout the flight (nowhere near the ~30 m/s² danger threshold), and there are zero accelerometer clipping events logged. Per-IMU comparison (IMU0 vs IMU1) shows no meaningful asymmetry either
  • Notch filtering: RPM-based (bidirectional DShot), confirmed tracking correctly against motor telemetry. Although I would look into the BW as pointed out by @dkemxr and @MaxBuzz . Thank you for you input.
  • Raw accelerometer data: peak magnitude during the braking manoeuvres themselves tops out around 1.6g — no saturation.

So on the sensor/hardware side, nothing I can find points to a genuine vibration or interference problem at the time these events trigger.

Given that, @rmackay9 and @andyp1per , I would really appreciate your help on two things:

  • If this is hardware-related — is there something specific in the logs pointing that way that I’m not seeing? Happy to dig into any particular field/metric you’d flag, or try a specific bench test.
  • If this is EKF-side — what would be the right approach to actually resolve the underlying trigger (rather than just suppress the symptom) before I consider FS_VIBE_ENABLE=0? Given the failsafe exists specifically to catch genuine accelerometer clipping and my logs show none at the trigger point, I’d rather understand and address whatever’s producing the sustained IVD/IPD/SV disagreement than disable the protection outright — especially since I’m still pushing this build’s speed envelope further
  • also, let me know if further logs are required for better analysis of this problem.

Thanks for your feedback

9

Thank you for taking time for takign a look at these logs. I would adjust the BW of notches. Tone them down a bit. I followed the wiki guide for this though.

10

There is a switch to lane 2 at the beginning (not sure why), so it’s start using IMU2, and lane 2 EK3_SRC2 have different POSXY/VELXY/VELZ/YAW sources configured than first, GPS will not help EKF to estimate position.
PSC_JERK_Z looks strangely high, that can contribute to ACCZ (PIDA) controller oscillations.
Setting PSC_ACCZ_SMAX, 125 may help mitigate if it will happen again (not sure about value, manual says that limit cycle detection recommends no more than 25% of maximum slew rate observable, in log I see ~500 max during flight, >900 with oscillations)

So for me it’s looks like that this “more vibration resistant two-stage controller” oscillating, but not sure how to debug it, PIDA controller eliminated due failsafe.
Also it would be good to see 2nd IMU data, so set INS_LOG_BAT_MASK, 3

11

I don’t think so. See the Warning section here:
Notch filter

12

Hi everyone,

First, thanks for your help and guidance especially @dkemxr. Setting the PSC values to default helped in resolving the Vibration Compensation problem. I have also set the BW to 1/4 of the freq as suggested.

Afterwards, I tested the copter at higher speeds and angles all the way upto 85 degrees. While testing at 80 and 85 degrees I found another issue.

The aircraft tracks well up to about 75 deg pitch, but as lean angle is increased beyond 75 deg the roll/yaw tracking starts degrading. I have anlayzed the logs and it is clear that Motors/ESCs are not saturated and VIBE.X/Y/Z remain below ~30.

What could be causing this loss of yaw/roll tracking above 75 deg pitch, and what would be the correct way to resolve it?

Could this be related to EKF3, the attitude/rate controller, mixer/control authority, or aerodynamic effects at these high speeds and pitch angles?

Flight Log - 85 Deg

Flight Log - 80 Deg

Flight Log - 75 Deg

@dkemxr,@andyp1per, @rmackay9 . I would be very grateful for your guidance on this issue. Your input and suggestions have been extremely valuable in helping me develop and improve this copter.

Thank you for your time and support.

13

Mandatory
Start by setting ARMING_CHECK,1 and fix anything that needs fixing. Features that aren’t used dont affect the arming check so no need to be so selective.
Also you need to set:

BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2

or the copter will not be able to save itself when the battery has a bad day, or you make a poor time judgement.

First some basics

This would be the correct configuration for the notch filter:

image
image1016×1163 85.7 KB

However the notch filter is not really required, post-filter noise is extremely low so you could just set INS_HNTCH_ENABLE,0 and that will work fine.

Use these slightly adjusted compass settings, just for the sake of completeness. I dont think the compass calibration is very far out at all.

MAGFit.param (301 Bytes)

Now the actual problem
The problem is tuning - specifically the Roll accel max and Angle P are both too low.
Yaw Angle P is probably too high, but it wont be a major issue. The Yaw accel max is probably too low also.

What I would do next:

After applying the other settings (as per above) set AUTOTUNE_AGGR,0.1 and run Autotune on pitch and roll, then Yaw including D term. Quite often they have to be separate flights, but you may be able to do pitch and roll and one session. Do yaw last.

Now do a basic test flight and provide your observations and a log file.
We may be able to manually adjust some of the Autotuned settings down slightly for smooth flight.

After it’s all good you can set these:

LOG_BITMASK,180222
INS_LOG_BAT_MASK,0
INS_LOG_BAT_OPT,0
14

@xfacta @rmackay9 @dkemxr , are we missing any basics. Can u suggest what is actually causing the issue that desired roll/yaw starts deviating based on which ekf yaw alignment is induced (fpv then actually deviates long way). Also, we have noticed that max speed is not being achieved while we are on half way throttle. We actually increased the pitch angle because speed of 200 km/hr and beyond was not being achieved at 75° (throttle output is nearly 40%). Ur valuable insight wud really help…

Regards

15

@Yasir_khizar you are missing the very basics that @xfacta posted.

16

Hi all,

First of all, thank you to @xfacta and everyone who has provided their valuable input so far. I have managed to tune the copter quite well now and have incorporated the suggestions from @xfacta, along with several rounds of tuning to get a good AutoTune.

However, I am still seeing the same divergence issue at higher pitch angles. I have carried out a number of additional tests, including:

  • Switched the EKF yaw source to GSF to eliminate the compass as a potential cause (EK3_SRC1_YAW = 8).

  • Changed EK3_SRC1_POSZ to GPS (3) to eliminate possible BARO-related disturbances.

  • Tried AutoTune with different aggressiveness levels.

  • Increased MOT_SPIN_MAX.

  • Experimented with MOT_YAW_HEADROOM.

Unfortunately, the behaviour has remained essentially the same despite these changes.

I’ve attached the latest flight log below. I also have several other logs from different tests and can provide them if they would be useful for comparison:

Flight Log

I would really appreciate your thoughts on whether this is something that may still be addressed through parameter tuning, or whether the behaviour in the logs points more towards a physical or aerodynamic issue that I should investigate.

If there are any particular log parameters or relationships that you would recommend looking at next, I would be very grateful for your guidance.

Thank you again for your time and help.