When I first saw this I felt sure this would be a case of the arming checks and Fence being disabled and trying to take off before there is a good 3D Fix - but it’s not.
Although I dont understand the Fence parameters of 5000km radius and 15km altitude - you only need to set these to the radius and altitude with respect to the takeoff point, not for where you might travel to one day in the future. You could set radius 800m and altitude 140m unless your local laws or your certifications allow more.
There’s a couple of problems in this flight:
- vibrations - the flight controller and EKF do as they should and switch to a good IMU
- the movement looks commanded even though the RC input only shows some small correction. GPS position and speed are good, and they match IMU data so poor position data doesnt appear to be the issue.
Z axis vibrations are a bit high and could affect some aspects of flight and also the landing detector. The X and Y axis vibrations dont appear to be too high, but they are clearly at a frequency that affects the IMUs badly.
Just after you take off the flight controller switches to the second IMU because it’s not happy with the first IMU - in the log it looks like IMU0 is much more effected by the X and Y axis vibrations than IMU1. IMU2 is approximately the same as IMU0, and the only good looking Accel data is from IMU1. You will need to set EK3_PRIMARY,1 but dont neglect the vibrations, or you are compromising the built in redundancy of the IMUs.
ATC_INPUT_TC is very large, which means your RC control will be very sluggish - try 0.25 or less.
The real issue
The problems mentioned so far are just contributing factors. I think the real problem is a rangefinder mis-configuration. Parameters show two front facing rangefinders, which is unlikely. Probably one should be set as downward facing. I think both have issues. You can see in this screenshot the GPS speed is rising until both of the rangefinders go beyond a certain distance.
- rangefinder1 quickly goes out of range, and is a bit noisy anyway. Maybe it’s even useless as a forward facing unit.
- rangefinder2 reports very well and is likely downward facing - it’s readings closely match the actual altitude, but it’s set as forward-facing. So the copter uses the AVOID params to try and slide away from the “obstacle” - and does so until altitude reaches about 5m, where you can see the GPS speed decreases to nothing.
The thing that baffles me is the pitch, roll and speed all exceed the relevant AVOID parameters, but maybe there’s something else going on that I’m not aware of. I feel sure sorting out the rangefinders will solve the primary issue.
And of course dont forget about the vibrations.
Harmonic Notch Filter could do with configuration, but dont let that stop you from investigating and improving the vibrations. If your antivibration work is successful you could leave the harmonic notch filter disabled - but a test flight will verify that.
Start with these:
INS_HNTCH_ENABLE,1 // write this then refresh params to see the rest
INS_HNTCH_MODE,1
INS_HNTCH_BW,15
INS_HNTCH_FREQ,35
INS_HNTCH_FM_RAT,0.7
INS_HNTCH_HMNCS,3
INS_HNTCH_REF,0.18
INS_LOG_BAT_MASK,1
and do a cautious takeoff in Stabilise mode or AltHold just in case you need to land if there is any introduced side-effect. At these low frequencies, some lag in the PIDs can cause oscillations.
