Unknown Drone Crash in Stabilize

Hi, my team and I flew our drone after re-calibrating, and it crashed. We are unsure what caused the crash. Could anyone provide us with any insight as to why the drone crashed?

To give more context, the drone flew well for the first 10 seconds until it started oscillating and grew violent. From the logs, the current supplied to esc 1 and esc 2 are oscillating and when one goes to the peak the other is going to the min. They are supposed to be somewhat close from what I saw from a previous good flight. Could there be some issue with the connection that supplies PWM to the motor?

There was also a battery failsafe that got triggered at 22.38 volts (it was set to trigger this failsafe at 22.8V) but after checking with the battery charger, it was 23.1V after the crash

Drone Crash

Thanks!

I hope there’s not too much damage and you can get it flying again.

FOLLOW UP
It looks like the copter has recovered from a crash dump and may even do another crash dump during this test.
Can you gather the entire SD Card contents, zip it up and upload for examination.
I wouldnt fly until this is checked and resolved.

It looks like the crash was caused by worsening oscillations is due to nothing more than PIDs being too low and copter unable to make strong enough corrections.
Try these:

ATC_ANG_RLL_P,6.0
ATC_ANG_PIT_P,6.0
ATC_RAT_RLL_P,0.10
ATC_RAT_RLL_I,0.10
ATC_RAT_RLL_D,0.005
ATC_RAT_PIT_P,0.10
ATC_RAT_PIT_I,0.10
ATC_RAT_PIT_D,0.005

You can set these for Harmonic Notch filtering at least until further test flights give more complete data

INS_HNTCH_ENABLE,1  // set this then refresh params to see the rest
INS_HNTCH_FM_RAT,1
INS_HNTCH_MODE,3
INS_HNTCH_OPTS,0
INS_HNTCH_REF,1

The voltage drop is due to the increased current demands from the motors and ESC, and the battery does recover afterwards. The battery voltage is not a concern.
But you should still set these:

BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2 or 3

You are using DSHOT which is good. There wont be a connection or “PWM” issue between the flight controller and ESCs. All 4 ESCs are returning valid data for the whole flight, and no errors.

For the next flight use Stabilise mode again and only if everything appears OK switch to AltHold mode.

1 Like

OK, it looks like we’ve also got those low PIDs recommended in another thread about this copter.

Let’s clear up the crash dump first then decide what to do.

Hello Xfacta,

Thank you for your reply and sorry for the delayed response.

We tested the recommended PID values last week and in the process of carrying out the deflection tests to check for oscillation, the drone oscillated about 6 times but when we used the current values the oscillations were less than 3 for both the pitch (PID Test 17 video and T17 logs) and roll (PID Test 18 video and T18 logs) axis once the deflection test was carried out.

Regarding the crash dump file, could you please tell us more about this? Here is the requested zip file.

Thank you!

@Tempest_25 the hard fault that caused the crash_dump.bin to be produced seems to have happened on or before the 7th of April 2023. It shows in log 434.BIN.
Logs 433 and earlier are for a different flight controller (a CubeOrangePlus), so it looks like the microSD was moved from one board to another. Do you happen to have the logs from before 7th April for the CubeOrange? We’re hoping to find the log where the crash dump happened, and the log immediately after that.
The tlogs may also be useful. Can you zip up the tlogs you have for the period of 7th of April and earlier for this CubeOrange?
Thanks!

1 Like

Unfortunately, I can’t find the SD card for the Cube Orange but here are some logs I have on my laptops for the 7th of April.

Thanks for the help and support!

@Tempest_25 thanks, it isn’t in those tlogs. Can you zip up the .tlog files from the previous few days? As the microSD switched from one board to another I can’t tell what day the issue happened, only that it was on or before the 7th of April. Only the *.tlog files are needed

I have attached here all the .tlog files I currently have access to on my laptop. Could you please let me know what the crash dump bin file can tell us and help us?

Thank you!

Hello @tridge,

I was able to find the misplaced SD card and there were only 2 logs that were on or before April 7th.
I have uploaded them here (It is in the same folder as what was last uploaded) but the new files are named 2023-04-07 07-07-32 and 2023-04-07 07-33-41.

@Tempest_25 @xfacta I’ve spent quite a lot of time on this and I’m afraid we don’t know why the CubeOrange had a hardfault. We do know it was sitting on the ground disarmed, and the battery was connected. The fault appeared to happen while clearing a DMA buffer in DShot. We can see all of the DShot state in the crash dump and it all looks fine. I’ve also been over it carefully with @andyp1per who maintains the DShot code and he and I both can’t see a cause.
I’ll let you know if we do find something, but for now unfortunately this is a mystery. We could blame cosmic rays or a power glitch, but that is a fairly thin excuse.

Thank you for all your support. My team and I will work on making use of another Cube Orange.

Thanks a lot Tridge

@Tempest_25
I think you should probably do the boot loader update process, it may not do anything but just to be sure. Then reset to defaults and reconfigure as per below. If you start with a new flight controller and decide that one is suspect, you can still follow exactly the same process and set these same parameters.

  • Save the parameters you have now to a .param file - they can always be extracted from previous logs too
  • Reset all to defaults and start over all configuration
  • Select frame type and class
  • Do the mandatory calibrations - accel, compass, RC
  • Set flight modes and switches (some are in params below)
  • Set up the voltage and current monitor (it may be working by default)
  • Move the motor outputs to Servo10,11,12,13 (Aux2,3,4,5) with the Setup/Mandatory/Servo Output screen
  • Use Initial Parameters with “Suggested” settings and apply everything

You will need these parameters set first in order to do the calibrations

BRD_BOOT_DELAY,3000
CAN_D1_PROTOCOL,1
CAN_D2_PROTOCOL,1
CAN_P1_DRIVER,1
CAN_P2_DRIVER,1
GPS_TYPE,9
NTF_LED_TYPES,231

Then set all these listed parameters for now, do not reload the old parameters from file, I’ve carefully selected them from your previous configuration.
Some of the ENABLE parameters will require you to “write” and then refresh parameters before you see more of them, but read to the end before you start setting these manually - there is an easy way.

ADSB_TYPE,1
ATC_ANG_RLL_P,6.0
ATC_ANG_PIT_P,6.0
ATC_RAT_RLL_P,0.10
ATC_RAT_RLL_I,0.10
ATC_RAT_RLL_D,0.005
ATC_RAT_PIT_P,0.10
ATC_RAT_PIT_I,0.10
ATC_RAT_PIT_D,0.005
BARO_PRIMARY,1
BRD_SAFETYENABLE,0
FENCE_ACTION,1
FENCE_ALT_MAX,50
FENCE_ENABLE,1
FENCE_RADIUS,100
FENCE_TYPE,3
FLTMODE1,0
FLTMODE2,2
FLTMODE3,5
FLTMODE4,9
FLTMODE5,6
FLTMODE6,15
GPS_GNSS_MODE,67
INS_ACCEL_FILTER,10
INS_HNTCH_ENABLE,1
INS_HNTCH_MODE,3
INS_HNTCH_FREQ,60
INS_HNTCH_BW,30
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
LOG_BITMASK,180222
MOT_PWM_TYPE,6
PSC_ACCZ_I,0.54
PSC_ACCZ_P,0.27
RTL_CLIMB_MIN,200
RTL_CONE_SLOPE,2
RTL_LOIT_TIME,1000
SERIAL2_BAUD,115
SERIAL2_OPTIONS,16
SERIAL2_PROTOCOL,16
SERIAL5_PROTOCOL,2
SERVO_BLH_AUTO,1
SERVO_DSHOT_ESC,1
SR0_ADSB,5
SR1_ADSB,5

You can copy/paste these into notepad and save as a .param file, then in the Full Parameter list you can load the new .param file. This avoids typing errors. Since there are “enable” parameters included, write and refresh then load and write the param file a second time.
You can do a compare too, to ensure they are all set as planned.

There’s some that are fractionally different to how you had them before but dont be alarmed, I’ve thought about them carefully and they wont be critical and not affecting flight, except maybe the PIDs I’ve specified but they should be safe.

Check and set RTL Altitude - the default is 15meters (1500) but I use 45m to clear trees - set it to suit your terrain.
After successful flights, you can also check and change FENCE_ALT_MAX and FENCE_ALT_RADIUS

Use Motor Test to check motor directions and MOT_SPIN_ARM and MOT_SPIN_MIN as per usual before flight. You had default values before and that might be OK, try to get MOT_SPIN_ARM as low as possible but still reliable. MOT_SPIN_MIN should be just a bit higher like MOT_SPIN_ARM+0.03
In the test flight just use Stabilise for takeoff and a short test, if everything is going OK change to AltHold and do some gentle pitch and roll.

The FENCE settings will seem to make it take a LOOOONNGG time before you can arm, but this would be the same if you were to wait in Loiter mode for the “Green Light”. The advantage is it means you’ve got a GPS 3D Fix and Home can be set before you can arm in any flight mode.
You get used to it and it allows you to stand around and think of anything that’s been missed, and consider the flight plan, instead of arming and flying in Stabilise before you should.

Try to avoid changing any other params unless you think I’ve missed something important. For example you had DISARM_DELAY,25 which I think would be a bad idea. The default is 10 and for my copters I set DISARM_DELAY,5
Thinking back, that disarm delay and even MOT_SPIN_MIN could have been contributors to the crash.