No airspeed sensor used (but connected and disabled by Parameters)
Takeoffweight ~5kg
The weather conditions were suboptimal, with steady winds North-East Wind around 25 km/h and gusts (up to 25km/h). The takeoff itself was smooth and uneventful. However, shortly takeoff was completed, the plane suddenly performed a almost 360° unintended roll in AUTO mode. After that the pilot took over in FBWA mode, but the aircraft remained unstable and ultimately crashed.
EKF position variance began increasing soon after takeoff and again before the crash for unknown reasons
We had some EKF-GPS-Glitch flags a few times but the GPS seemed pretty stable - saw that this is also set if EKF doesnt fit to GPS but still dont understand why EKF gets inaccurate then
ROLL_LIMIT_DEG set to 45° but plane did roll angles > 45°
Desired Pitch and Roll is hardly met by the controller
Could a gust or wind cause such roll behaviour ?
Could a possibly vibrating FCU cause such roll behaviour?
Is it possible there was basically too less airspeed and the plane stalled and crashed?
Any input or suggestions would be highly appreciated. We really want to understand the issue before we take off with the next one.
You can speculate a lot and the crash is certainly annoying. When trying to find the cause, it is also annoying and not speculative that you have switched off the IMU logging. This means you can’t include the rotation rates and you can’t say anything about possible vibrations. An evaluation is therefore hardly possible. Why has this been changed? On the arming check it is noticeable that the barometer check has been removed and is also not available in the log file, although the speedybeef405wing has a barometer. All in all, the response to pitch and roll is very poor. Did you fly an autotune and then set the TECS parameters? The ailerons are defined as flaperons, but there is no switch or speed indication for the flap function, unless I have overlooked this. At the end of the flight, it is noticeable that the pilot took the throttle out completely and the aircraft then lost even more altitude. Without IMU data it is not possible to say for sure whether he pulled or pushed, but he did one or the other.
I am therefore unable to determine what triggered the roll.
There was another reported crash with a F405 based FC with Ardupilot 4.6 related to roll in automatic flight modes.
Therefore don’t use AP 4.6, flash the next Plane with 4.5.7, enable logging for all standard values. I would recommend fitting FPV gear to the plane and record to have the OSD info.
In general it is not advisable to fly a heavy plane on a maiden in automatic flight modes and without FPV gear.
I would also recommend getting rid of the automotive connectors and the electronics box. If the flight controller is in there, how should the barometer work for altitude control?
it was indeed a fault on our side to disable IMU logging for such maiden flight of a heavy plane, we disabled it as we use Companion PC based bin log recording (set File and Mavlink bit in LOG_BACKEND_TYPE) in our planes and we observed that the SERIAL interface to the companion was not fast enough to cope with all log data, so we disabled some streams. But its very stupid to do this on a maiden development flight…
we indeed missed the disabled the barometer arming check, but we check the barometer in our paper based preflight checklist. i cant proove it with the logs but usually a broken barometer should be recoginezd in our preflight check process.
we didnt do a AUTOTUNE as this was the actual maiden flight where we wanted to do it. we used the stock ArduPlane 4.6 parameters. We were thinking of using the 4.3.6 based parameters from https://fw.makeflyeasy.com/Frame_params/Believer.param but decided to not do it, as we had good experience with using stock parameters with a Skywalker Titan plane and on ArduPlane 4.4.* in the same weight class
We use Flaperons for better takeoff via TKOFF_FLAP_PCNT=50 and dont do any manual flaps via RC. Looking at the video of the takeoff i dont see this to be honest, but takeoff went very good so we didnt further investigate
Dont do any throttle or switching to FBWA instead of FBWB was maybe a wrong decision indeed.
After the unintended 360° roll the FCU and battery and therefore als COG and its box could have moved inside the plane, so this could also lead to strange behaviour.
I think there are multiple sources of error which could have lead to the crash ultimately.
@menschel thanks for looking into the data and images!
Nice catch to this flight with similar problems. I will try to check out the problems inside the thread more in detail.
We didnt know that the 4.6 release had these possible flaws, so next time we will use the suggested version and try to use OSD.
We plan to design this plane to be IP67, so the FCU will be later in a sealed box and we need to use proper connectors. This time the box had multiple big holes for working Barometer, but we also have good experience with a sealed box and a few holes with watertight but air transparent membranes to work with barometers.
As long as the flap function of the flaperons is still extended, the Believer reaches a speed of approx. 20 m/s during climb. After retracting the flaps, 40 m/s are quickly reached (145 km/h).
You have left AIRSPEED_CRUISE at 12 m/s (default value) and AIRSPEED_MAX at 22 m/s. Autothrottle cannot work with these values.
The radii required to follow the waypoint path cannot be flown physically either.
WP_LOITER_RADIUS is 60 meters. The maximum groundspeed achieved in the wind was 43 m/s (155 km/h). To fly a radius of 60 metres at this speed would require a bank angle of 72°.
I have had good experiences for first flights with the default values for pitch/roll PIDs with 500g to 10kg planes, provided that you only fly in FBWA/autotune at first in order to set the PID values for the attitude well. With completely incorrect TECS/speed/Radius values and not yet set Atittude control values in strong winds and gusts in mission flight, this will go wrong of course.
I see no indication of a firmware error. In contrast to the thread cited by menschel, the DCM and EK3 attitude estimate in your flight are consistent throughout. Also, the roll is performed under EK3 without immediate change. But most of all there are enough reasons for an involuntary roll with the mixture of gusts, (still) catastrophic attitude control settings and Arduplane has terminated the roll itself, so I think of a mixture of gust and bad roll control.
I hope that the damage in the picture looks worse than it is and that you can repair the plane.
