Need help with log analysis (EKF_FAILSAFE launching from ThrowMode (drop))

Hello, I am experimenting with launching a drone from another vehicle.
My drone is a simple X-frame. FC is matek H743 slim (I use it on my other drones as well) with ELRS happymodel 2.4 lite. Also HC-06 module attached for easier connection to not use USB cable all the time. LogAnalyzer output is shown below just in case. Also here is flight log link:

Here is how I fly: bigger drone picks up small one (but before this small one is powered and given time to calibrate gyros). Then big one climbs about 30 meters. After this small drone is cwitched to ThrowMode and released from the big one. After successfully arming in ThrowMode after drop it switches to Brake mode. Then as I understand it is supposed to stand still but because of EKF errors it switches to Land mode. Though instead of landing just flies into some direction :slight_smile: So I switch it into RTL and it starts to fly back, but then suddenly moves sidewise and starts to loose height. I try to switch it to STABILIZE and full throttle to avoid hitting the ground, but it is too late :frowning:

So I am trying to understand what can be the reason for the errors I see in the log. I assume while small drone is hanging off the big one it is swaying because of the wind and big drone movement and some sensors may be out of sync, but I’ve only got maybe 3 compass variance messages before arming and switching to ThrowMode and all PreArm checkes were ok (first time we indeed had very instable small drone swaing and rotating, so I could not even Arm and I did not want to disable arming prechecks, but then we ensured it sits more secure, and apart from already mentioned couple compass variance warnings did not have any errors before dropping it).

I am attaching log screenshot where I mapped values according to (Looking for “The Leans” section) because it looks like drone has been leaning and because of this loosing height.
I can provide other data if needed. Or do analysis myself but I am afraid I need some inputs.

Also want to note that I was flyig the drone in STABILIZE the day before and it was flying ok also in AltHold mode and AUTO mode (though I’ve noticed some strange behaviour after takeoff, but then it returned to the given course).

A couple of words to describe screenshot: when STABILIZE mode is entered drone is about to hit the ground, as can be seen by altiture graph, so everything after this is not so interesting.

Thanks in advance for advice. The same day I also got similar issues with my 7inch with similar setup just by flying in STABILIZE, so sad day :frowning:

LogAnalyzer output:

Log File C:\Users\alari\Documents\Mission Planner\logs\QUADROTOR\1\2023-02-20 11-45-48.log
Size (kb) 138.7021484375
No of lines 2803
Duration 0:00:01
Vehicletype ArduCopter
Firmware Version V4.3.3
Firmware Hash 34e8e02c
Hardware Type 
Free Mem 0
Skipped Lines 272
Test: Autotune = UNKNOWN - No ATUN log data
Test: Brownout = GOOD - 
Test: Compass = GOOD - mag_field interference within limits (2.74%)
Max mag field length (553.11) > recommended (550.00)
Test: Dupe Log Data = GOOD - 
Test: Empty = FAIL - Empty log? Throttle never above 20%
Test: Event/Failsafe = GOOD - 
Test: GPS = GOOD - 
Test: IMU Mismatch = NA - 
Test: Motor Balance = UNKNOWN - 'QUAD/X'
Test: NaNs = FAIL - Found NaN in CTUN.DSAlt
Test: OpticalFlow = FAIL - 'FLOW_FXSCALER' not found
Test: Parameters = FAIL - 'MAG_ENABLE' not found
Test: PM = UNKNOWN - No PM log data
Test: Pitch/Roll = UNKNOWN - Unknown mode in TestPitchRollCoupling: THROW
Test: Thrust = GOOD - 
Test: VCC = UNKNOWN - No CURR log data

Auto Analysis is mostly useless. Post a link to the .bin flight log.

Added link to flight log. For some reason could not attach it directly here even though file is less than 4.4MB

The flood of NAV_SCRIPT_TIME messages make it a pain to tease out the details. After spool up you had a potential thrust loss error from the motors commanded to almost max. Then you had a GPS Glitch long enough to cause an EKF failsafe and switch to LAND Mode. Then it or you switched to RTL and then another GPS glitch, then a Vibe FS which triggered Vibration Compensation. This is when it felt like it was flying away because in that mode control is weak.

I would simplify this setup and test each function on it’s own. Does the dropped craft basically fly? Got a log just of that?

Sorry, yes I forgot to remove lua script, but I just disable messages to see modes switches.
Yes, as I wrote I has been flying same copter day before in Stab mode as well as AltHold, Auto (over waypoints and my custom script which was flying it using Archimedes spiral). Also it was landing fine in Land mode. I will try to look for a log.

That also removes other useful messages. Get rid of the script and go back to tuning the drop craft I suppose. Vibe levels are very high, PID’s mostly at default, Notch filter not configured. It looks like you have some work do do there before dropping it. I would suggest making these changes, perform a 1-2 minute hover test in AltHold and post that log (or check vibration levels and configure the notch filter yourself):

Then tuning starts.

Also, have a read thru this:
Setting Motor Range
It might help with good spool up of the motors when dropped.

definitely will do another test (need to fix the drone though). I did not setup notch filter before but will try. regarding PIDs I did fly in AltHold and modified PSC_ACCZ_P, PSC_ACCZ_I after it, as ardupilot docs suggest. Vibrations may be part fo the reason, though I did not look as I had them when flying drone normally.
Am I also right that when I see Err:GPS-2 this means start fo GPS glitch and when I see Err:GPS-0 - this is Glitch cleared (it coinsides with corresponding messages at the bottom of a graph). And so everything which is inbetween GPS-2 and GPS-0 means GPS had issues? Then I really had a lot of non-gps flying.

P.S. I also converted binary to text log and deleted script messages by using regex, so I now can see messages more easilly )

Thank you for the help, I’ll work more on the drone. And will try to give you updates

Yes, I saw you did enter the Initial Setup parameters and the PSC values. A good start!

Yes. After 5s it will EKF FS and trigger whatever action is set. LAND in this case.

And as for GPS. I see that it has enough (>15) number of satellites and HDOP was ok, lat/long/alt numbers are quite smooth as well and true to the actual drone path. So I do not understand what in this case GPS glitch means. Is it because projected position got from IMU differs from what is read from GPS and if they are differ than some threshold we have a glitch (at least according to this. So it can be that even if GPS is healthy but IMU gives garbage, ardupilot can initiate GPU glitch?

Yes, think so. The Position Innovations go to hell. XKF3>IPN/IPE

Got a log from a normal mission (takeoff, go to wp1, do some spiraling using my script, RTL). Interesging that there was also FAILSAFE_VIBE right after drone finished takeoff (I assume abrupt change in velocity might have caused it) but Clips are still zero. Then on the way back, right after switching to RTL (given as a script commans, so it is not marked as RTL mode change) vibrations raise quite a bit (though surprisingly no failsafe) and right after this a second peak just when the drone was passing a metal fence, but maybe it is just a coincidence as at the same time ground speed was changing as the drone was approaching landing point.

The vibrations levels need to be greatly reduced before you can proceed. I have a few Matek H743 FC’s and you cannot mount them too soft. Process to follow:
Remount the flight controller with soft grommets/standoffs.
Set these:
Then make some flights and configure the dynamic notch filter.
Run Auto Tune

Thank you @dkemxr!
I actually already performed tuning though with my smaller 5’ copter. I can say that it flies much better now. Also did notch filtering, though no autotune yet. Now will try to do similar thing with the drone in question, just waiting for better carbon props.