Drone failed to disarm and lost control.

[JT-Klenke]

Current Behavior

I was testing a new drone it took off and flew extremely shakily, likely both because it has a very high center of mass and also because the motor braking is really aggressive and its untuned. I tried to disarm and the drone flew away and didn't appear to respond to stick inputs, after about 30 seconds it dropped. I believe the flyaway was caused by the drone entering a landing failsafe and the min throttle being set too high + bad tune meaning it wasn't going down. My main questions are why did the disarm not cut the motors when the drone was not in the failsafe, why did the drone enter the failsafe when the rssi was still good and why did the drone eventually drop? Theres a video of the flight if needed.

Here is what I think is the most relevant part of the logs:

LOG00029.TXT

Expected behavior

Motors should turn off when set to disarm and not in a failsafe state.

• FC Board name and vendor: MATEKH743
• INAV version string: INAV 7.1.2 (4e1e59e)

[breadoven]

Looks like it lost the Rx signal, went into a Failsafe Emergency Landing very soon after the disarm command was received then initially climbed before eventually descending finally disarming 20s after Failsafe triggered.

It did receive the disarm command but went into Failsafe before it executed (there's a small delay between the disarm command being received and actual disarm happening, switch_disarm_delay). Disarm isn't possible if Failsafe is active so the disarm command got cancelled. It's a bit odd the Rx signal was lost just at the time the disarm command was received.

It climbed during the emergency descent even though the throttle was at 0 although eventually it started to descend. Is it overpowered much ?

It disarmed by Failsafe in the end I'm guessing because the Failsafe 20s timeout kicked in, failsafe_off_delay. Although the Rx signal returned at exactly the same time ... which is also odd.

[JT-Klenke]

Ok thanks! I think this explains things and suggests that if I set switch_disarm_delay to 0 and failsafe mode to drop that'll solve the issue (or at least bandaid).

Do you have any ideas why rxSignalRecieved would go to 0 when the rssi was still good and would return after the failsafe timeout? The receiver is ELRS and I realized that arm isn't set to aux1 high like its supposed to be, could that cause this issue?

It climbed during the emergency descent even though the throttle was at 0 although eventually it started to descend. Is it overpowered much ?

Ha ha, yes, I think for now failsafe as drop is the safe option, once its tuned landing may work better

[sensei-hacker]

realized that arm isn't set to aux1 high like its supposed to be, could that cause this issue?

It is very likely that was part of the problem.The reason the ELRS docs tell you (repeatedly) to use channel 5 is precisely because it will cause this issue. Higher channels are sent only every so often. Channel 5 is sent with every packet.

Suppose you switch from cruise mode to RTH, using channel 8. A slight delay may be acceptable. If signal isn't perfect, you might get an even longer delay if the first packet that includes 8 doesn't happen make it through. You don't want a delay on your disarm!

[JLP04]

What would cause the massive spike in motor activity after the FC disarms but before it enters failsafe mode (based on the graph, which shows Flight Mode Change before the spike and failsafe activating after the spike)?

Here's a graph which shows the failsafe change but also includes when rxSignalRecieved goes to 0 (which the previous graph didn't include):

[JT-Klenke]

It is very likely that was part of the problem.The reason the ELRS docs tell you (repeatedly) to use channel 5 is precisely because it will cause this issue. Higher channels are sent only every so often. Channel 5 is sent with every packet.

Actually after looking at the config again, its set up properly, aux1 high is arm and low is disarm. But also it receives the arm signal (ie actually disarms), the thing I don't understand is why rxSignalReceived died when rssi is good, what could have caused this?

[sensei-hacker]

Actually after looking at the config again, its set up properly, aux1 high is arm and low is disarm. But also it receives the arm signal (ie actually disarms), the thing I don't understand is why rxSignalReceived died when rssi is good, what could have caused this?

Two things come to mind. First, the measurements of RC signal, in order of effectiveness, are:

Link quality (LQ)
SNR
RSSI

Link quality tells you if the messages were understood.

SNR tells you if the messages were stronger / louder than the background noise or interference.

RSSI tells you the overall loudness.

So imagine you're in a night club, having a conversation during some soft music. All three measures are good and you can understand the other person. Now the DJ turns on a fast dance song and cranks it up really loud. The RSSI (total loudness) has gone up, but your conversation partner probably doesn't raise their voice quite as much as the music, so the SNR goes down. You might not be able to understand a word they said, so LQ might be zero.

I had just such a situation when I flew too close to a radar. When the radar dish turned toward my aircraft, it was much stronger (higher RSSI) than my transmitter, so the RSSI went through the roof and my aircraft fell to the ground, with LQ and SNR of zero, and the electronics all frozen up for a few seconds.

Also, RSSI comes from the receiver. It tells you that the receiver heard something. That doesn't mean the FC got the message. A dodgy connection between the FC and the receiver would cause that. Also having the wires between the receiver and FC running right next to motor wires and parallel could cause that, if the interference from the motor wires swamped the serial signal on the receiver wires.

[JLP04]

Also, RSSI comes from the receiver. It tells you that the receiver heard something. That doesn't mean the FC got the message. A dodgy connection between the FC and the receiver would cause that. Also having the wires between the receiver and FC running right next to motor wires and parallel could cause that, if the interference from the motor wires swamped the serial signal on the receiver wires.

I was actually going to ask this yesterday. So it could just be that our motors are wired too close to the RX wiring and so it loses the signal once the motors get above a certain threshold?

[sensei-hacker]

Yep, that could be.

Keep it mind, it might be that your name is Jason Logan Prescott O'Leary the fourth (JLPO4). That's ALSO consistent with the evidence I've seen. Big difference between "could be" and "is". 😃

[JT-Klenke]

Link quality (LQ) SNR RSSI

Is there a way we can verify LQ in the blackbox data (I didn't see it or SNR) or set up logging for it, if its set up in the OSD will it log?

Keep it mind, it might be that your name is Jason Logan Prescott O'Leary the fourth (JLPO4). That's ALSO consistent with the evidence I've seen. Big difference between "could be" and "is". 😃

weirdly enough thats exactly his name!