Unexplained Accident

Last week, I flew for the first time with a new plane equipped with the Matek F405 Wing V2 board. I took off in Stabilization mode, and for about one minute, everything seemed fine. I was flying in this mode and didn’t notice any errors. Then I switched to RTL mode, and after a few seconds, the plane started behaving strangely. In the end, it resulted in a crash.

I downloaded the log file from the flight controller and started analyzing it. I also have a video from the goggles, which includes OSD data. In RTL mode, the AHR2 and ATT data don’t make much sense to me. Towards the end, just before the crash, the data began to diverge, even though this hadn’t happened before.


It seems to me that the autopilot was receiving incorrect data from the sensors, which ultimately led to the crash. Can anyone try to explain this accident to me?


Hi, i’m not an expert at all I hope so else will help you
But Yes, it looks like your compasses are performing very poorly towards the end of the flight (high SM, expected magnetic field far from measured magnetic field). When you switch to RTL, the drone tries to climb to 100 m (RTL_ALT), so the current increases, which could explain some interference. But at the same time, during takeoff, you had less magnetic disturbance despite even higher current, so I’m not entirely sure. You are flying a plane with no airspeed sensors ? Are you sure your plane can archieve long turns at 45° roll ?

All indications are that the origin of the accident was a lack of compass calibration. Your compass is affected by the magnetic field generated by high current demands.

In this first graph you can see how on the two occasions that you set the motor to 100% (high current demand) the magnetic field is totally altered.

These second and third graphs confirm that on the second occasion the EKF3 estimates become invalid (values greater than 1); the first one that becomes invalid is the magnetic compo (SM), then the velocity (SV) and finally the position (SP). The height estimate (SH) was close to being invalid (0.94). These estimates are correct between 0 and 0.5, between 0.5 and 1 is acceptable (but undesirable) occasionally and above 1 they are invalid.

This is a good example of how a compass is not always a good idea in a fixed-wing aircraft, especially as it is not necessary here. A compass in a fixed-wing aeroplane can provide additional safety when flying in strong winds and close to the stall limit. But it definitely increases the complexity of the system, which can lead to a higher error rate and a crash or similar if there are errors in the setup.

I sincerely thank everyone for the time spent analyzing my flight, and I am glad that an explanation was found. I never suspected the compass and had no idea that the issue could be there, considering it was installed approximately 15 cm away from the battery’s power cables (and on the completely opposite side from the battery). I did perform calibration by rotating the aircraft. The only thing that comes to mind is that the compass is part of the GPS, so perhaps this could have played a role.

Are you really sure about the compass to be the issue?
It does not explain how the plane can roll >120deg in RTL.
I consider AP4.6 Release to be a Beta after all the issues I’ve found in the last few month, and even one after it was released.

1 Like

Agreed. There’s something else going on here.

The log shows the plane thinks it’s at a 45 degree bank, and the OSD suggests that as well. The OSD was tracking the horizon reasonably until about second 0:14 in the video.

But that much field on the top of the screen tells another story.

How was the FC mounted in the plane? Any chance it moved?

2 Likes

I agree with you, that’s why I had doubts about compass in my first reply

  1. the proposed inflight calibration is not that much better compared to existing cal
  2. As I said, during takeoff the current is higher and the calibration error is lower

Yes I was wondering if the FC (or the compass) can moove

If the compass moved there would be an EKF error and that would get filtered out. Wouldn’t impact a plane very much.

2 Likes

how is the flight controller mounted in the plane? is it stuck down?

that’s what I see, the plane was flying ok but then the OSD suddenly disagrees with what is actually happening. That it happens when its banked over makes me think the flight controller has tipped over inside the plane.

Given the hypothesis of a poorly fixed controller, I tried to analyze accelerations, turns and vibrations that could justify the controller coming loose from its anchor.

In moments prior to takeoff (yellow) there is a vibration typical of the manipulation before launch; its values are acceptable.

At launch (blue) there is a very strong acceleration in x-axis compatible with the fact of launching the aircraft; but a value over 160 m/s2 is very high (some mechanical means were used for the launch). There is also a strong roll spin of 343º/s. This twist suggests that either the autotune was not done or that it was done at a very high level. Both the acceleration and the roll could have been the cause of the controller’s de-hooking. However, during the next phases of the flight nothing strange appears again.

At the end, and prior to the beginning of the sinking, important roll turns (green) appear again, although this time they are more prolonged and alternate (although maintaining their maximum values).

These last turns could be the cause of the detachment of the controller (???).

Curiously, the impact on the ground is not recorded.

1 Like

Likely the battery pulled itself out of the connector on impact.
I experienced that as well when I crashed an AR Pro on maiden throw, couple of month ago. Same type of FC btw.
From my impression OSD shows signs of unstable traffic from FC because whole values vanish and reappear.

This flickering of some OSD elements is an occasional behaviour of Walksnail Avatar and not a problem of the flight controller or its connection to the VTX. This is due to the lower priority of the OSD compared to the video content

1 Like

Once again, thank you for the time spent investigating the cause of the accident.

The disappearing OSD data is indeed a problem with the Walksnail Avatar video transmitter.

I cannot confirm nor deny the assumption that the flight controller was separated from the aircraft. After the accident, the mounting plate with the board was detached from the fuselage, but given the impact force, this is not surprising. The flight controller remains firmly attached to the mounting plate.

What can be confirmed is the discrepancy between the aircraft’s physical position and the position expected by the flight controller. I considered how this could be possible and concluded that even a board detached from the aircraft’s fuselage could not have changed its position so drastically. The fuselage interior is not large enough to allow the board to shift to this position. The battery was also attached to the mounting plate inside the fuselage, and its weight could certainly have torn the plate loose. However, even then, it would not have been possible for the board to rotate at such a large angle. After the accident, the battery remained strapped to the mounting plate, even though it was outside the aircraft.

1 Like

If it never detached then my next guess would be either the imu or its power supply.

I found mention of a f405 wing with imu failure here so it wouldn’t be unheard of
https://www.reddit.com/r/RCPlanes/comments/mip2qz/matek_f405wing_inav_issue_faulty_accelerometer/