Error EKF Primary-1 and CRASH - HARD LANDING

ArduCopter Copter 4.5
1

Hi,

We have a hexacopter with 10 kg payload. There is a small radar and signal generator on the drone. We have tuned the drone. It has nice flight performance. The log of good flight performance is as follows:

But we had a very risky flight with Error EKF Primary-1 in the log. Drone flies well at first 3-4 minutes. Then I have seen compass invariance error I think I am not sure but it was something related to compass. Then drone made very strange behaviour on roll/pitch directions, not too much yaw but. I looked at at the log a little bit. It seems there is also roll/pitch commands but I dont think it is my rc commands. In the log there is Error EKF Primary-1 error just before the problem. I tried to land and descend hopefully drone recovered attitude but it was a hard landing. Drone has 1 CUAV C-RTK and 1 Here3 GPS. Primary yaw is coming from Here3 GPS. Below is the log file.

I am not sure whether this problem is related to compass data, the effect of our payload on RC or compass, or something related to autopilot. We use the drone for research and development purposes but I am not confident with the overall system after these problems. I would be glad if you can review the log and share your toughts.

2

Hard to review the logs when there’s an access restriction…

3

Sorry, it is open now.

4

The compass calibrations are definitely an issue.
Start by disabling the internal compass
COMPASS_USE2,0
Then set these other compass calibrations:

COMPASS_OFS_X,295.7297797648962
COMPASS_OFS_Y,-209.46598128248723
COMPASS_OFS_Z,144.0406002898747
COMPASS_DIA_X,1
COMPASS_DIA_Y,1
COMPASS_DIA_Z,1
COMPASS_ODI_X,0
COMPASS_ODI_Y,0
COMPASS_ODI_Z,0
COMPASS_MOT_X,0
COMPASS_MOT_Y,0
COMPASS_MOT_Z,0
COMPASS_SCALE,1
COMPASS_ORIENT,0
COMPASS_OFS3_X,-228.5661414199577
COMPASS_OFS3_Y,-20.385750650452124
COMPASS_OFS3_Z,165.88216091415563
COMPASS_DIA3_X,1
COMPASS_DIA3_Y,1
COMPASS_DIA3_Z,1
COMPASS_ODI3_X,0
COMPASS_ODI3_Y,0
COMPASS_ODI3_Z,0
COMPASS_MOT3_X,0
COMPASS_MOT3_Y,0
COMPASS_MOT3_Z,0
COMPASS_SCALE3,1
COMPASS_ORIENT3,24
COMPASS_MOTCT,0

but this is far from perfect. The problem is your compasses are all affected by current/magnetic fields and you do not have the current sensor working.
If you can get the current sensor working, or acquire one that will handle the required current, the compass calibration can be greatly improved.

Once you get a current sensor working do a test flight with plenty of yaw and circles and ascent and descent. Then we use the web-based Magfit utility to provide an updated calibration.

The vibrations are unnaturally low, I’m curious about how you have the flight controller mounted.

1 Like
5

Thank you for your message @xfacta.

How you achieve these compass offset parameters? Using the magfit tool or something else?

I looked at the log more carefully I agree with you there is problem with compasses. It is better to move away power sources from autopilot and compasses. We will do that in next flight. When I look at the crash data (second one), XKF1 yaw values are differentiating slowly.

image
image1486Ă—464 11.4 KB

But I wonder how we dont have problem while tuning flight (the first data). We also have batteries close to autopilot and compass in the first data. Only difference is that we powered the payloads: radar, signal generator and a modem. So in the first data, there is no differentiation between XKF1 yaw values.

One more question: we do compass calibration with a small 4S battery not the exact 12S-32A batteries just for convenience. Do you think that we have to do calibration while 12S-32A batteries are working?

Regarding your curiosity, we have CUAV X7+ mounting on vibration damper with 3M. Our frame has large arms and quite vibrating, so we had to resolve that in the first place. I think that low vibration is always good for performance, but do you have any concerns about very low vibration?

6

If the tuning flight was done without payload it might been “fine” aka bellow warning thresholds at lower currents.

7

Tuning flight was done with the same payload, same physical configuration. In crash, there were cars moving close to the drone. I think this might cause interference.

8

I have already raised the problem more than once - EFK Primary. This problem has been around for many years! ! ! ! ! ! A lot of drones were damaged, they all had the same problem - take off, 2-3 minutes of flight, EFK Primary message and after 10 seconds crash. I did a test - I used the EFK610 frame and installed three types of flight controller - 1. CUAV 5+ 2. B Paladin v.2 3. Skydroid S1-4G. Only CUAV 5+ had the problem ! :frowning:

9

Hi Alex
Can you point to where you’ve posted about the problem or logged it in Github? I’m interested to see what’s going on. I cant fix the issue but I can read all about it and maybe help in some way.
The EKF messages are indicators of some other fault, so are you saying the EKF was not handling compass issues correctly, or something like that?

1 Like
10

We solved our problem using GPS for yaw with 2-RTK modules. For our case, I understand that EKF Primary Error comes from mismatch between compass data. Here3 Compass were drifting. But, we had risky flights until realizing that. I think this issue needs further investigation.

Now we use 2-RTK modules, set GPS with compass fallback for yaw data source (EK3_SRC1_YAW=3), and using only autopilot compass (RM3100-CUAV X7+) incase fallback occurs. Now I want to check whether autopilot compass is consistant with the RTK yaw data, but I am not sure which data to analyze in the logs. RTK yaw data is under GPS labels, but not sure about where to check autopilot compass yaw. ATT.Yaw and XKF1.Yaw seems to be the same. GPS[0] and GPS[1] yaws are not same.

image
image1617Ă—407 6.21 KB

I wonder ATT and XKF1 yaw data are fusing of GPS yaw data? I want to be sure that autopilot compass yaw is consistant with RTK GPS yaw, so need to be sure about the location of autopilot compass yaw data in the logs. I am sharing the log file as follows.

11

Hi @emrecan,

Similar to what @xfacta has said above the vehicle suffers from interference on the compass. A physical solution really would be bets. E.g. move the compass farther from ESCs, power wires, etc.

plot.ardupilot.org allows plotting the compasses by selecting, Presets, Sensors, Compass, Compass and then a graph like below appears. We can see the that magnetic field length can be anywhere from 348 to 680. Anything over about 30% change means you’re likely to see bad yaw estimates. 348 → 680 is almost 200%.

image
image1440Ă—480 58.8 KB

Sorry I cannot immediately think of a way to compare the compass yaw to the GPS-for-yaw easily. If you’re feeling brave you could set up EKF sensor source switching to change between GPS-for-yaw and compass in real time.

By the way, we’ve discovered a long standing serious bug involving GPS-for-yaw and the COMPASS_LEARN=3 parameter. I will post shortly about it but in any case, if you’re using GPS-for-yaw (which I think you are) please do not set COMPASS_LEARN = 3. This bug will be fixed in 4.5.2.

12

Thank you for your message @rmackay9, we don’t use compass learn it is 0.

Do you have any comment about using the internal compass of CUAV X7+ as a fallback sensor, it has RM3100 compass. Maybe people from CUAV @cuav_le @CUAV-Ricky could comment on this. We are using GPS for yaw (CUAV 9Ps modules) but I am not confident about fallback situation. RTK to internal compass fallback. I disabled 9Ps external compasses since having compass invariance errors even we have calibrated them and also 9Ps compass data seems to be too noisy. (can see on the above log)

@xfacta, do you have any idea about comparing the RTK GPS yaw data with internal compass yaw data using the logs. I was thinking about a formulation using the magnetic fields?

13

Hi @emrecan,

I think if you don’t have a reliable compass it is OK to use GPS-for-yaw with no fallback to compass. The EKF can cruise along with no compass for quite a long time using only the gyros so the vehicle won’t immediately lose control if the GPS-for-yaw fails.

14

Hi @rmackay9, I will use MagFitTool offsets to align internal compass. I think this is the best option for us.

We need to use Waypoint Navigation so no compass is not an option for us I think. Do you think EKF heading estimation(without compass) is enough for navigation flight?

15

Hi @emrecan,

I’m not sure I understand the question but…

GPS-for-yaw normally produces very good headings, more than enough for autonomous navigation.

The EKF with not compass and no GPS-for-yaw won’t work I think. GSF is available for completely non-compass flights but I wouldn’t rely on that for regular operation.

16

Hi @rmackay9,

My main question was, comparing RTK-GPS yaw data (under GPS[0] and GPS[1] in the log) with the internal compass yaw data. But in the logs there is only magnetic fields (under MAG[0]) not the yaw data for the internal compass. ATT and XK1 yaw data are functions of GPS[0] and GPS[1].

I want to be confident to use EK3_SRC1_YAW = 3 (GPS with compass fallback) but I am not confident with the internal compass yaw data. That is why I want to check internal compass yaw using the flight data that use RTK-GPS yaw.

Btw, I used the following calculations to compute internal compass yaw data using magnetic fields and it seems to be consistant when MagFit Tool offsets are applied.

image
image1012Ă—666 17.4 KB

To sum up, if someone use RTK GPS yaw and want to check the other source of yaw data incase fallback occurs, it seems that logs are not directly available for this comparison. If this is the case, I think it will be helpful to include other yaw sources directly in the log even they are not primarly used.

1 Like
17

Hi @emrecan,

Yes, indeed it would be nice to be able to easily compare the yaw from the compass to the GPS-for-yaw. Could I ask that you go ahead and raise an enhancement request in the issues list here?