Octo Crash Requesting some additional analysis

ArduCopter Copter 4.6
1

Greetings All,

On the second flight day of a Frankenstein coaxial octo-coper we resurrected we experienced some strange issues that resulted in a crash. I have downloaded and reviewed the .bin and log file, I do not have a tlog file as we were only using a herelink with logging not enabled to command and control the UAV. Here is a link the the .bin and log files:
(FIT-CRASH - Google Drive)
The UAV is question is a Watts Innovation Prism Sky, that we removed all the Auterion/doodle labs equipment, and replaced with a Pixhawk Orange and a herelink. This was done as another user of the equipment shorted original equipment, and with Watts disappearing into the ether, we deemed it best to replace with hardware we are more familiar with.

We were testing over water, training a new person to use the craft, so I was not in direct control of the UAV, but standing next to him. We did a first flight without any issues, until the end of the flight when we had a RTL as we were bringing the UAV back to land:

Mode timeline (seconds from log start):

  • 671.36 — Mode 16 (PosHold)
  • 1768.87 — RTL
  • 1997.32 — back to PosHold
  • 2281.80 — EKF failsafe → forced LAND
  • 2282.70 — message: “GPS Glitch or Compass error”

When we launched the UAV for a second flight with the same set of batteries, it experienced the EKF failsafe and went into LAND mode, but it did not do a RTL, it drifted away from us slowly descending until the front skids hit the ground, flipping it and breaking all 4 front props and getting some sand in one of the motor pods. This is what I can glean from the logs…does anyone have any further insight or what we should do in the future to prevent this from happening again?

What the logs show
• Firmware/type: ArduCopter 4.6.1 (CubeOrange, ChibiOS).
• Failsafe path: EKF failsafe → forced LAND, followed moments later by “GPS Glitch or Compass error.”
• Earlier clues: multiple EKF3 mag/yaw realignments well before the final event (classic sign of mag/compass inconsistency).
• Power: battery healthy; no brownout signature near the event.

Hard numbers
• LAND at: t = 2281.80 s from log start.
• GPS quality (±30 s around LAND):
o NSats median before: 15 → after: 28
o HDOP median before: 0.40 → after: 0.81
o This wasn’t a satellite collapse; the “GPS glitch” message is consistent with EKF disagreement (compass/yaw) rather than GNSS die-off.
• Battery (±15 s around LAND):
o V median before: 47.35 V → after: 46.26 V
o No battery failsafe. Voltage behavior looks normal for load transitions.

What likely caused the crash
A navigation estimate failure (EKF) driven by compass/yaw inconsistency, not power loss. The EKF tripped and forced LAND. The GPS constellation stayed strong; the system was fighting mag interference / calibration / orientation issues. Vibration could aggravate it (we were flying it at top speed, over 26 m/s), but the event sequence points squarely at mag yaw.

What to fix before next flight
• Compass setup & wiring
o Make the external compass the primary: enable it, disable internal ones you don’t use, disable Pixhawk compass and only use CAN GPS ones.
o Confirm COMPASS_ORIENT matches the actual mount.
o Re-run compass calibration outdoors, away from metal.
o If power leads/ESCs run near the mast, either reroute/space them or run CompassMot compensation.
• Arming checks
o Don’t arm unless NSats ≥ 12 and HDOP ≤ ~1.3 (we had this correct).
o If you’re using GPS-Yaw or dual GPS, verify EK3_SRC1_YAW reflects what you actually intend (Compass vs GPS-Yaw) and that dual-GPS orientation/priority are sane.
• Vibration sanity (needs BIN)
o In the BIN, check VIBE.VibeX/Y/Z < ~30 and IMU Clipping ~0. If elevated, balance props, add isolation, avoid tight zip-ties across the FC.
• Failsafe policy
o You’re currently on FS_EKF_ACTION=LAND. Since we fly over obstacles/water, we want to change this to RTL from LAND
• Enable logging on HereLink, we only have logs on the UAV, so if we have another problem and it falls into water we will not have any data for analysis.

2

What log are we meant to look at? I didnt see a crash or much else you describe.

Z axis vibrations are getting high in places, you’ll need to do something about that. It’s a physical issue. Also set these to gather noise data for setting up the harmonic notch filter:

INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4

Compass calibrations are quite close to correct and not a big issue, but the magfit file I’ve attached will improve them, particularly where battery current is affecting them. There may be no need to move the compasses (GNSS units). You can add the settings from the file using the MissionPlanner full parameter list and Compare or Load from file.
MAGFit-FIT-RS.param (903 Bytes)

This will prevent takeoff in ANY mode until home can be set, it’s practically mandatory for bigger copters:
FENCE_ENABLE,1
Check the other fence settings, radius and altitude.

Use Loiter mode instead of PosHold. It’s much more configurable which is quite important for big copters. Also set these which will suit your copter:

ATC_INPUT_TC,0.20
INS_ACCEL_FILTER,10
LOIT_ACC_MAX,300
LOIT_ANG_MAX,25
LOIT_BRK_ACCEL,125
LOIT_BRK_JERK,200
PSC_VELXY_D,0.25

Those will make the copter a bit less like a small racing quad.

This is really the only option because if the EKF has lost it’s position there’s no way to know where the launch point is to do an RTL. It’s likely the copter will drift with the wind during Land if there’s no valid position.

There’s more tuning to be done, come back when you’ve worked through those things and done a small test flight with some circles, ascents and descents.

EDIT: update to latest stable firmware too
Also set these parameters, the values are in meters so be careful:

GPSn_POS_X
GPSn_POS_Y
GPSn_POS_Z
1 Like