Motor shutdown after failsafe for no (?) reason

A few days ago I was testing my 10" copter, and this test ended in a free fall from 70m.

There were a few radio failsafes just before it happened. I’m investigating those separately, as it happened before in exactly the same spot.

During the test before there was also a series of radio failsafes which were cleared almost immediately. I have radio FS action set to LAND because I haven’t tested RTL yet (was mainly testing receiver reception/antenna placement up to now).

So the copter switched to LAND after the radio FS as configured. But before I had time to switch to another mode (which was successful last time), the motors shut down in mid-air.

The only difference was that this time it happened in LOITER, while last time I was in STABILIZE.

I took a newbie’s look at the log but can’t figure out what made the motors shut down. I thought maybe because of LAND mode, the copter assumed it was already on the ground but the barometer displayed altitude correctly all the time, so that can’t be it I guess.

Log link: https://we.tl/t-cG7xuU5FNC

I found two sentences in the documentation about immediate disarm but they don’t seem to apply here:

  • If the copter is armed but has landed, the copter will immediately disarm.
  • If the copter is armed in Stabilize or Acro modes, and the throttle input is at minimum, the copter will immediately disarm.

Something odd I noticed: Throttle percentage in the OSD generally shows very low values with this craft, often just 10% in normal flight, although the throttle input was definitely much higher than that, and the copter didn’t seem underpowered at all.

Thanks for any hints.

Hello!

I think that I have found the reason. If you have a look at the Radio Failsafe documentation (https://ardupilot.org/copter/docs/radio-failsafe.html), it is written that if the radio failsafe is triggered, the copter will disarm if it is in stabilize (or acro) and the throttle input is at minimum.

So looking at your logs, I found that there is a moment when you are in stabilize, the radio failsafe is triggering and clearing all the time and your trhrottle is at minimum (or at least very low):

That is the only reason that I have found. I hope that can help you a bit.

Regards!

Thanks, but I had already quoted that part of the documentation and I don’t think it applies here because:

  • I was in LOITER
  • Throttle input only reaches minimum after the motors had already shut down

But actually there is still something I down understand. On radio FS, shouldn’t the throttle go down to 965 (or similar) and then back up to stick input every time the FS is cleared? It doesn’t look like it here, yet another thing that puzzles me as newbie.

The thing that is odd here is that the moment the drone starts to fall - there is no error message.
the last message is radio FS cleared.

you did not reach at any moment the FS_THR_VALUE . this is not the case here.

Your RC6_option is arm/disarm and the switch was moved to disarm. It was either by mistake by you or a wrong failsafe setting in your receiver.


image

Hmmm… I wonder if it’s really possible I flipped the arming switch by mistake, even if that would be the first time in many years of flying, and always using the same switch.

I wasn’t even overly panicking as I expected to get control back after the failsafes, just like last time.

The only thing I could imagine is that I mixed up the flight mode and disarm switches…?! There was a camera running on the ground but it filmed the copter, without the transmitter in view unfortunately.

FS is set to “cut” in Crossfire Nano Diversity receiver, and it’s not set to send anything by itself on CH6, so I guess it’s out.

If there is no other explanation I must have really had some kind of blackout. :roll_eyes:

What version of AC are you using? Are you using CRSF or SBUS or MAVLINK for RC control?

I’m using the latest AC version posted in the CRSF Yaapu thread on Kakute F7 AIO: https://github.com/yaapu/ardupilot/releases/download/ver_0.8/KakuteF7_crsf_ver_0.8.zip

And by the way, neither me nor somebody else present remember the script saying “Motors disamed”, and there was no disarm message on the OSD either.

So I think therefore there is a non-zero chance that this could be a bug in CRSF or that patch. Could it be related to the switch between mode 2 and mode 1? If you can, can you verify that this works ok on master?

This touches on an issue I had on the list to check out more closely. I have an unmodded QX7 which allows for only a slower baud rate. There is a small piece of hardware available to mod the transmitter (https://www.team-blacksheep.com/products/prod:qx7mod), but since I’m ok with higher latency and didn’t want to risk the transmitter, I went for the other solution and simply lowered the baud rate (https://team-blacksheep.freshdesk.com/support/solutions/articles/4000133896-do-i-need-taranis-mod-inverter-for-my-frsky-radio-).

I think I read somewhere this means that only one of the modes is actually available? I did see some mode changes however in the OSD. Since this doesn’t seem logical it was already on my to-check list.

At the moment I’m not so motivated to try and reproduce this and risk another free fall. There were only 2 props broken and lots of dirt in one motor this time - I don’t want to push my luck. :wink:

I’m not sufficiently knowledgeable about the TX side. On the RX side we require 416k baud, but this should only be between RX and FC. Not sure what happens to the RF link in your case.

Not asking you to fly - just a ground test to see if you can provoke a failsafe that makes channels go to zero :slight_smile:

Yes I know all about generating failsafes at home because I had been investigating the reason for these radio FS in between the tests. :wink:

I probably just need to attach the Runcam 4k (big orange standalone one) again, which seems to be responsible - which is actually very strange. On a smaller copter where it is much closer to the RX and its antenna and that is running the same type of receiver, there is no problem.

Hm, speaking of this, maybe this does point just a little bit to some kind of bug in AC being involved here - because the smaller quad is still running iNav.

Adding to this, I found it very strange that those radio FS were never preceded by any loss in LQ. In fact LQ was at 99 during the whole flight, no degradation at all. Then suddenly the FS happens, in a way like the transmitter was switched off. Or as if I had flown behind a wall, but I didn’t.

On the other had it might also have been the Runcam 4k getting between the RX antennas and the transmitter at exactly that point, because I was higher than before and turning the quad.

In any case, it would be great if the displayed LQ actually went to zero in these cases - at the moment it doesn’t, as explained in the documentation, because cases like this are not expected, except when the transmitter is turned off.

Anyway, the failsafe itself didn’t shut down the motors, that much is for sure I guess.

I will see if I can replicate this, I usually did the radio tests with an unarmed quad, in this case I’ll have to clean the dirty motor first. :wink:

Another question, does “Land Complete” mean anything, regarding the fact that the copter was in LAND mode? With the altitude still at 70 meters and moving, I’m just wondering if there should be any checks preventing this interpretation. If AC assumed the copter had completed the auto landing, this would be a valid reason to shut down the motors?

@UnknownPilot sorry for your crash :frowning:

These are the commits vs master https://github.com/yaapu/ardupilot/commits/ver_0.8 that you were flying in the hope it helps debug your issue

I removed a time constraint here that “should” not affect RC nor telemetry but might be worth checking it out https://github.com/yaapu/ardupilot/commit/1f73e45667c05eb49ef8296d3e75d4e63c93b5d5#diff-b461323452ea70e83fbc1217b71154b88fad81484395ac5dde19ba7ad5c57327L323

You might try on the bench to force rf mode changes and see how that is handled by your soft modded QX7 setup and by my code.
I compiled version 0.8 with telemetry rates debug enabled
arducopter_crsf_ver0.8_debug_rates.zip (627.4 KB)

If the RunCam provokes it and is connected to a serial port then it could also be a UART/DMA issue. What ports do you have the RunCam and RX connected to?

So the little copter is the same setup and same RX but no issues?

This is a standalone RunCam, neither Split nor Hybrid, no UART connection: https://shop.runcam.com/runcam2-4k-edition/

OT: There is actually a way to remote control it, but via “an unoccupied S or LED pad” - just in case you ever feel like implementing even more RunCam stuff: https://www.runcam.com/download/runcam2-4k/RC2_4K_MANUAL_EN.pdf

Hah, RunCam already want the RunCam Split4 I bought back so that they can test it. I think I have enough RunCam stuff to do. Just wish they had written a proper protocol and used it consistently everywhere …

Thanks for your efforts! I will install this, clean the motor, and then provoke some radio failsafes indoors while armed to see if the motors shut down, in STABILIZE with throttle above zero.

I’m still wondering if I flipped that switch… Can OpenTX be set to log all input? If that was possible, I’d have definite proof in a case like this next time.

This seems really simple though, probably because the old RunCam 2 (without 4k) has been around for years. Just 2 PWM ranges for start and stop - just what I’d wish for with the Splits/Hybrid…