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.
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.
It took us some time to rebuilt the majorly broken plane but we were able to do another testflight with arduplane 4.6.1. Following changes were made based on your advises.
1. Flight: basic FBWA test start with few meter altitude
Successeful start from ground and nice landing after short glide phase. We were still concerned about that pitch overshoot (and almosst crash). Does this indicate possible wrong stock PID already?
2. Flight: actual maiden FBWA + autotune flight
Pilot1 start in FBWA with same overshoot problem as in flight1.
Pilot1 then wanted to do a advised long turn and intended to come back over us after start to do autotune.
Then it did once again a 360° roll and went out of control.
Luckily after the roll pilot2 took over, capable of manuel flying and saved the plane to be horizontal and we did a luckily more or less save crash landing with minor broken parts of the plane again.
Few things i noted in the log:
EKF is able to get the full 360° roll so it was not a EKF malfunction?
attitude / roll controller doesnt follow the desired roll?
PIDR.FF and PIDR.I has quite high negative values. ATT.Roll at the 360° roll fits quite 1:1 to the super high PIDR.FF values?
shortly after roll EKF-flags indicate GPSGLITCHING, could be cause by antenna facing to the ground during roll?
switch to DCM after roll
pilot1 flew with most of the time full throttle in FBWA and plane reached quite high speeds of max 36m/s groundspeed
We now are a bit out of knowledge what could have caused the problem as we double checked params and followed your advises. Anyone has a idea what could cause such behaviour in FBWA?
The Believer can be moved in the air with the default values. As far as I remember, Arxangel made its first flight with the standard values without any problems. Another setup from this forum provides some orientation: MFE Believer, documenting setup.
The speed parameters still don’t fit, Airspeed_cruise with 12 m/s and Airspeed_min 9 m/s are clearly too low. The Scaling_Speed with 15 m/s could fit. But the fact that the pilot flew at full throttle and 33 most time does not fit at all.
I also don’t understand why you continued to define the ailerons as flaperons without defining a switch to operate them. Switch to Ailerons first. If everything works out, you can still bother with flaperons (which I don’t like for aerodynamic reasons with outboard ailerons, but that has nothing to do with this)
The docility in FBWA was very very sloppy throughout. Unfortunately, I can’t say exactly what led to the roll (CG ok ? aileron deflection wide enough ?). In any case, the integrator is gradually overflowing to the point where the roll occurs.
The pilot does the right thing and switches back to manual, but unfortunately he switches the engines off (by mistake, as he did on take-off) !!! With engine power he would have stayed up.
I wouldn’t be discouraged and next time fly manually first, see if everything works and then go to FBWA.
While we appreciate your feedback a lot we fail to understand how most of your comments relate to the unintended and unexpected roll that happened two/three times in FBW A and AUTO.
We did not have problems taking off. The plane was able to hold desired attitude e.g. on takeoff. We had no power problem.
What we will do before the next flight:
Check the hardware setup, e.g. aileron movement, FC mounting
Disable differential thrust and flaperons in AUTO
Test flight the ArduPilot version on a smaller plane with known behavior
Have a pilot on the controls that can fly manual
Fly slower
Double check the speed parameters even though we fly without airspeed sensor
Maybe fly with tuning parameters from the manufacturer
