EKF Lane Switch messages

ArduCopter Copter 4.2
, , , ,
1

Hi everyone!

We’re having a few EKF Lane Switch messages in some of the flights. It’s happening in two identical drones.

Basically, it’s a 25kg MTOW drone with orange cube+ and two Here3 receivers.

The lane switch messages are coincident with yaw reset messages in the logs (screenshot below).

The flight itself is nominal, no compass or mag field messages or alerts.

Compass calibration was done twice and this is still happening.

I’m just afraid I might me missing something so it would be nice if you have any insight about it.

WhatsApp Image 2023-06-27 at 08.37.51
WhatsApp Image 2023-06-27 at 08.37.511530×717 195 KB

https://drive.google.com/drive/folders/1VroLtmuZNeF5i0nQB7IFEGJjbGgifAT6?usp=sharing

2

Use Magfit for compass calibration. It might not solve the problem but it’s the correct method.

1 Like
3

And updating to ArduCopter 4.3.7 might help as well.

1 Like
4

I’m working with Gabriel in this project and I have some comments to share:

image
image1261×363 93.9 KB

image
image1278×403 109 KB

image
image1216×418 122 KB

image
image1600×337 77.5 KB

OBS: the last screenshot is from a flight with a drone from the same model but with a slightly different propeller, so the tuning could be a bit off.

Considerations:

  • I can see that the yaw_reset always match the XKF3 ErSc peaks and also the RErr variations.

  • Innovation in magnetic field strenght and velocity doesn’t seem to be related.

  • Innovation in position (Down Component) seems to be related.

Questions:

  • The vibration graphics show very low levels (under 8 m/s²), and indeed the cube and the whole electronics block are sitting on dampers. Could the cube be “too isolated” from the airframe?
  • Could (should) we safely raise the EK3_ERR_THRESH to 0.5 instead of 0.2?
  • Should we change EK3_GSF_RUN_MASK or EK3_GSF_USE_MASK?

I’m aware that some changes were done from 4.3.X on, but changing FW is always a sensitive topic for us, as it could raise questions from regulators. Anyway, we’ll start testing it with dev drones.

Thanks a lot!

5

this github issue has been an interesting read about this exact topic maybe you will also find it useful.

6

Yes! I’m following that discussion too. Thanks :slight_smile:

7

I looked at the latest log I could find in your folders, 64.bin
I dont see the EKF lane switches in that log, mainly precision landing
You will have to be more specific otherwise.

You should definitely update to latest stable firmware (now 4.3.7) - there have been some important control loop and timing fixes (amongst many other things) since the version you are using.

I wouldn’t change any EK3 params until tuning is better (as per below) and we can better identify where the real problems are.

Vibrations are low, so that should not be a problem. I think there is still noise in the system because the harmonic notch filter is not working as good as it could. This will allow Autotune, or even manual tuning, to work much better.
Adjust these to improve the harmonic notch filter:

INS_HNTCH_REF,0.16
INS_HNTCH_FREQ,38
INS_HNTCH_BW,20
INS_HNTCH_FM_RAT,0.7

MOT_THST_EXPO ?
What motors and ESCs do you have? There might be a slight improvement here.
I would also reduce your D terms to:
ATC_RAT_PIT_D,0.005
ATC_RAT_RLL_D,0.005

Use these to improve the GPS position, since the GNSS units are not giving equal quality signal, maybe due to interference or different firmware versions.

GPS_PRIMARY,1
GPS_AUTO_SWITCH,4

There could still be improvements to your compass calibrations, if you can do a flight with circles and a figure8, plus some ascent and descent. Just use AltHold or Loiter. We can use that with MagFit. I think this has been discussed before, but I’m sure we can do more.

2 Likes
8

Hi @xfacta

I truly appreciate the attention you are giving to this matter. Thanks a lot!

We just found a crack in the airframe and that should explain the worse log. Well, we will retune, repeat some flights following your instructions and then we come back here to share results. We are also testing the 4.3.7 FW in parallel.

Thanks again :slight_smile:

9

Hi @xfacta !

We conducted more test flights, after retuning and using your recommendations. The lane switch was still showing up, and last Friday I guess I found the root cause:

  • This drone is using a new airframe we developed. The geometry and propulsion are not new, but the new airframe was developed to be almost completely sealed in order to fly safely in rain.
  • I expected to have some issues related to the barometer, because the cube is “too isolated” from the external environment, and I noted that the altitude variation is around 10m, different from when the drone wasn’t enclosed, which was around 5m variation.

The screenshot below shows that the moments of higher variations, the amplitude of the derived climb rate also increases and it matches lane switch messages.

image
image1191×430 82.9 KB

Maybe I’m tripping a bit, but the baro having a bit more variance is something I was expecting. Inside the folder below you’ll have access to some additional logs.
image

https://drive.google.com/drive/folders/1KELWBLiCJOe2dfZGz0d60Migd-y9p980?usp=sharing

SN0005 is an example from an old prototype, not sealed, in which the baro variation is smaller. SN0009 is a sealed one. BARO - 0024 is the log from the screenshot.

Thanks a lot for helping us sort this out.

10

hi, can you help me to analyze the problem with my drone, because there is an EKF primary changed 1 notification and the potential thrust loss of the drone cannot be controlled anymore.
here I use FC Cube Orange with firmware 4.2.2

https://drive.google.com/drive/folders/1suz0vaQ2TIxLZQtND8Os3oln93fmXbS8

11

@AbdulRosyid-dev update to at least ArduCopter 4.3.7, retest and open a new discuss thread.

12

As amilcarlucas says please open your own discussion, since it is likely you have a whole different set of problems. Thrust loss generally means the copter is under-powered/overweight.
EKF lane switches are usually not a problem by themselves, but indicators of other issues, like vibrations and interference to other sensors.

13

The barometer was indeed the root cause.

It was too isolated from the external environment and, being the only POSZ reference, the EKF wasn’t very happy.

1 Like