Help Analyzing Log: CRASH No Motor Output After Switching to RTL

Hi everyone,

I’m looking for some help reviewing a log from a recent flight where our drone experienced an unexpected crash. We’re trying to understand why, after switching from Stabilize mode to RTL, the drone did not appear to regain control or stabilize. Climbrate also looks like it doesnt update after switch to RTL

Specifically, I’m puzzled by the following:

  1. No Motor Output in RTL Mode:
  • According to the RCOUT data, the motor output remained at 0 even after the mode switched to RTL.
  • My understanding is that in RTL mode, the system should have increased the motor output to stabilize the drone and climb to the configured RTL_ALT. Why didn’t this happen?
  1. Unexpected Behavior Post-Mode Change:
  • In Stabilize mode, we observed reduced motor outputs as the drone began to fall.
  • Once RTL was triggered, it seems like the system didn’t engage properly to regain altitude.

We are looking for insights on what could have caused this behavior:

  • Was there an issue with the motor outputs, flight controller, or a specific configuration parameter?
  • Could it be related to the mode switch logic, or something else in the system state at the time?

I’ve attached the relevant log file for analysis. Any guidance or advice on what to look for would be greatly appreciated!

Thanks in advance for your help!


Attached Log Details:

  • Date of Incident: November 20, 2024
  • Modes Observed: Stabilize → RTL
  • Behavior: Drone fell without stabilizing or climbing in RTL mode

Looking forward to your feedback.

Screenshot alone seems to indicate no attempt to raise the throttle in stabilize, causing low output on all motors. I think RTL was selected when it was too late to recover. Would have to download the log to be certain (I will later unless someone beats me to it).

Remember, you have rather direct throttle control in stabilize mode, so a low RC input will likely cause a dramatic descent.

When is it too late to recover? Its weird that it didnt even try to.

This was a strange behaviour, i think caused by a disconnect/reconnect of the RC (Although it was on RTL mode, it switched to stabilize before going to RTL, weirdly)

I’m assuming interrupted by the ground (or disarmed). Again, need to see the log, and I’m not in a position to do that right away. It looks like an inadvertent switch to stabilize with no attempt to raise the throttle.

Why would it? What @Yuri_Rage described is exactly what happened. Switching to Stabilize at low throttle is also known as Rapid Return To Earth mode.

Can you check if all RC values dropped to zero/min? That would explain it as a potentially misconfigured failsafe.

They are center stick except for throttle. Many have done this, flying in Auto with the throttle down and hit Stabilize either by mistake or on purpose and not realize the consequence. I have done that.

1 Like

Hi @dkemxr we know that happened but that is not the issue, the issue is that it switched to RTL almost inmediately and RTL didnt do its job, it was still at 119m when sitched to RTL from 120 that it was flying in auto and Stabilize.

So while i get your point, that is not the answer.

@Yuri_Rage Thanks for your feedback! I can confirm all RC values dropped to min

Where?


Here RC Out values, i think thats what @Yuri_Rage was asking, no?

That’s the same data I plotted. I believe he was asking about RC Inputs related to a failsafe action but he can confirm.

The motor outputs dropped to zero. It rolled over almost flipping upside down. Hard to recover from that…

Exactly, the problem is that it rolled over already on RTL, when it should have powered up the motors and stabilized the drone again. That is exactly the problem

No, what I wanted to see was INPUT. If all values dropped simultaneously, that would indicate an RC signal loss that could explain a mode switch and low throttle. If that were the case, then we could deduce that the failsafe mode of the receiver is not properly accounted for by the autopilot RC failsafe configuration.

However, that is not the case. The only channel that changes is the mode channel.

What we do see is a switch to stabilize with very little throttle command, a tumble of the aircraft, and an inability to regain stability. There is a spike in commanded throttle output from RTL, but the attitude looks pretty out of control at that point, and it’s hard to tell exactly what’s happening, especially because it appears there may be some GCS commands being sent that I’m not savvy enough to decipher with my own log review skillset.

The root cause is a rapid descent as a result of the switch to stabilize mode. Everything else after that is likely inevitable (and perhaps exacerbated by frantic GCS commands that I can’t see).

Thank you both for your input and comments, I still see a problem here… As you mention there is a spike in Commanded Throttle when RTL, but if you look at the actual servo output nothing is happening, this is why the drone flips and why the rapid descent happens, in stabilize it didn’t even lose 1 meter of altitude.

The problem is the servos are not responding to commanded throttle commands

One more observation: you have an automatic parachute release configured to deploy upon reaching a critical sink rate.

This section of the log shows motor output reducing due to the stabilize mode switch, and then motor output is cut as the chute algorithm kicks in. I think the chute sequence was nearly simultaneous with the switch back to RTL.

EDIT: Here’s velocity down against scaled RCOUT. The chute is configured to deploy at 6m/s down. This correlates nicely with motor output being cut. There are a series of intentional delays between motor cutoff and chute deployment that very likely account for the rest of the log, though I’m not overly familiar with the exact algorithm.

Yes it makes total sense that when the parachute is deployed it turns off the output completely, and when we can see them dropping from 1100 to 1000.

but even in stabilize we had output to motors above 1100 and when it switches to RTL is when all go to 1100, this is unexpected behaviour from arducopter. To clarify further im talking about 11:34:42 to 11:34:43.4

If RTL would have motor output as it does usually, then it wouldn’t have reached the critical sink rate for the CHUTE and the crash would not have happened

I think the throttle slew rate and physical response wasn’t fast enough to catch it before you reached that sink rate.

I really don’t see a problem other than operator error here.

1.6 seconds is not enough?

In 1.6 seconds it did not change any output from 1085

What is PSCD.VD? @Yuri_Rage

Velocity down as recorded by the position controller.

There is a 1 second check for loss of control/sink rate before parachute release. Thereafter, you have specified a 500ms delay to release the chute. I think that’s the timeline we are looking at. I did a little code review and can’t quite find why we’d see a throttle (or spin) min command during the “crash check” for chute release, but the timeline seems to match.

@rmackay9 or @peterbarker may have a little more insight.

Thank you @Yuri_Rage ! That makes sense, but as you can see here, the Critical sink rate (6m/s) was not achieved when it switched to RTL, it was about 0.6 seconds after that (which may have not been enough time to spool motors and reverse it eitherway), but the weird thing is that it didnt even send any output to the motors, all stayed at 1085.

Also the 30 degrees difference between desired and real attitude were not achieved before switching to RTL, only reached about 0.6 seconds after the switch to RTL as we can see in the following picture…

Hopefully @rmackay9 or @peterbarker can clarify further.

Thanks again!