Arducopter EKF failsafe triggered by arming

Hi, I am attempting to use Arducopter 4.0.4 to control a conventional helicopter. However, the EKF failsafe is being activated as soon as the vehicle is armed, leading to erratic swashplate movements. Any help in resolving this would be greatly appreciated.

What I expect to happen
Power on system, allow sufficient time for a GPS lock. Verify swashplate control response. Vehicle arms normally (using rudder arming) and the swashplate control response is consistent with the pre-arm response.

What actually happens
Power on system, allow sufficient time for a GPS lock. Verify swashplate control response. Vehicle arms normally (using rudder arming) and EKF failsafe is activated (see attached log file). This causes the rcin/rcout response to become erratic, beyond the effects of normal D and I control terms.

What steps have I taken to resolve?

  • Repeated all calibrations (accelerometer, level, compass)
  • Tried different power sources to rule out electrical noise
  • Reviewed sensor data in the logs (all look reasonable)

Hardware
Cube Black on a standard dock, Here2 GNSS, Futaba R7003SB RX. All powered via 5v directly into the servo rail.

Software
Arducopter v4.0.4
MissionPlanner 1.3.7.0 (connected via USB/RFD868)

Questions

  • What is the cause of the EKF failsafe? The EKF variances look low and the IMU, magnetic, GPS and baro data all look reasonable
  • Why is the EKF failsafe activated only by arming? Why does it not activate before this point, and what does arming change that leads to an EKF issue?
  • What can be done to resolve this issue?

Many thanks, Tom.

00000018.BIN (709.9 KB)

Conventional Helicopters need 4.0.6-rc1

@amilcarlucas why is that? Is there something that changed regarding EKF from 4.0.4 to 4.0.6-rc1 that is specific to helicopters? I have been flying my heli with the stable release (4.0.5) with no EKF issues.

@tomalxreed are the arming checks enabled? If they aren’t then please enable them and see what messages are generated when you try arming. You may even get pre-arm messages.

@bnsgeyer I assumed the fixes you did in 4.0.6-rc1 would help here.

No, the fixes are strictly flight control improvements. There was nothing that would affect EKF.

Hi @tomalxreed Tom,
Thanks for the detailed write up. I looked at your log and in particular, your parameters within the log. Have you set up a heli with arducopter before? I think your swashplate is jumping around because you have very unusual rate controller gains for a heli. Did you use the tradheli wiki to set up your heli? I don’t know of any helicopters that can use gains this high
ATC_RAT_RLL_P = 0.2
ATC_RAT_RLL_D = 0.01
ATC_RAT_PIT_P = 0.2
ATC_RAT_PIT_D = 0.01

I suggest you reduce these to the following values
ATC_RAT_RLL_P = 0.02
ATC_RAT_RLL_D = 0.001
ATC_RAT_PIT_P = 0.02
ATC_RAT_PIT_D = 0.001

I suggest you raise these to the values below
ATC_RAT_RLL_VFF = 0.15
ATC_RAT_PIT_VFF = 0.15

Also what drove you to make
H_CYC_MAX = 4245
This seems very high. But I see you have a mechanical mixer for your swashplate so this is probably ok.

So I also see that you don’t have your arming checks enabled. Please set
ARMING_CHECK = 1

Hopefully you will get some pre-arm messages that will explain why the EKF is unhappy.
Regards,
Bill

Hi Bill, thanks for your reply. The ATC_RAT_* gains are set to very high values in order to visualise the control response and make sure that the direction is appropriate. I’m aware these are very high for flight.

What I am observing is an inconsistency in the response between being disarmed and armed (EKF failsafe on). Even with the gains being set to inappropriate values, I would expect the response to be at least consistent.

H_CYC_MAX = 4245 is required to achieve full deflection.

Thanks, will repeat the test with ARMING_CHECK enabled.

Well I would suggest making the changes to ATC_RAT gains that I suggested. The _VFF gains will help you visualize the swashplate response to your inputs. Plus that is what we recommend for first flights.

Well in acro, we release the target values (desired aircraft response) when the aircraft is armed. When you enable motor interlock (turn on the motor) then the integrators are released. The movement of the swashplate after arming may be due to the high P and D gains and the controller trying to make the aircraft match the target aircraft. So that is probably why you are seeing inconsistencies between disarmed and armed.

Excellent, thanks very much for the explanation. I didn’t realise control system terms (integral values etc.) were being clipped whilst disarmed.

So it sounds like I have two distinct issues here:

  • Gains are set inappropriately, which only become problematic on arming. Solution is to set gains to more appropriate values
  • EKF failsafe is being triggered, probably completely independently of the arm/disarm command. Solution is to set ARMING_CHECK=1 and run through any arming failure messages.

Many thanks for the support, will report back with results in case it benefits other users :slight_smile: