MC: Crash due to Motor Stop (Kill Switch) but I doubt this

[tops4u]

Bug Report

I file this as a bug report since I'm concerned that my crash today may have other reasons than accidentally flipping the Kill Switch.

I was performing some tests to eliminate a strong Oszillation when braking in PosCTL. This was improving, when I wanted to do another Test, shortly after Taking of the Rotors stopped in Mid-Air and the Vehicle crashed on the road where Motors where spinning again. While hitting the Ground the Battery got disconnected (as can be seen in the Telemetry log).

Sadly the ULG stops shortly after start so about 2meters of flight are missing from the Vehicles Log (this is kind of strange). Also the OSD did not record anything since it claimed that there was no Communication (this may also be a bug of the OSD FW but it said that there was no data for more than 400 secs, which usually does not happen).

So I'm stuck with the Telemetry Log. This is the last I got over Telemetry (from the Log):

Here comes the 2nd strange Part. The Kill-Switch was engaged and disengaged under 0.5 sec and this twice in sequence. I checked with my Remote and it is almost impossible to really push the switch to the position in-between where it may flip back in this quick manner. I'm not aware that I flipped the Switch and the Telemetry RC Input (Channel 6) does not reflect any change in Signal. I performed many flights, and never flipped the switch unintentionally.

Telemetry Log (Check last 15 secs) : 2017-11-09 18-05-27.tlog.zip

ULog Upload : https://review.px4.io/plot_app?log=1452c840-3003-4913-b528-1fff3f17d447

[dagar]

Confirmed the log doesn't have the last couple seconds of data.

@tops4u could you describe your full RC setup?

[tops4u]

I'm using a Futaba RC System. The connection is directly SBus (so no PWM Converter). There was no change in the RC Setup for almost a Year.

Just to add on. I'm using a Futaba T10 the Kill Switch is on the upper side on the right. I was holding the Transmitter in the hands. So in order to flip the switch or even push it I would have to let go part of the Main Sticks in order to reach it. I can not at all remember to have performed such an action.

[dagar]

What happens if RC is lost?

[tops4u]

Receiver is preconfigured to issue Flightmode RTL.

[dagar]

I'm wondering about an actual loss of RC. Do some of the channels drop to 0 before the autopilot registers RC lost?

It's not yet clear if this is at all related, but I'm also wondering if we should debounce the RC switches.

[tops4u]

I‘ll produce a log tomorrow about what happens on RC loss with this receiver. Distance between Transmitter ans the Aircraft was less than 10m. So only reason could be an RC TX failure of some sort. I‘ll try tomorrow.

[tops4u]

Ok, I got a log for this. But this again is a bit weird, I have preconfigured the Receiver to go to FlightMode RTL and I can see that FlightMode changes to the desired Value in MAVLink Inspector, but the log does not reflect this (maybe due to the RC Link Failure detection?)

https://review.px4.io/plot_app?log=d056b0eb-00ca-4cd9-bea4-7c0124bda478

(Log created with identical Aircraft without Props).

[tops4u]

I did notice one strange thing this morning while doing some tests at the bench. During multiple test I suddenly noticed a fast flickering red Light in my FC Enclosure. The FC was booted up for some time but it was the same LED that flashes during boot time (I guess this is the IO Bootloader flashlight), just that it was flashing somewhat faster than at boot time. There was noting in the Logs nor MAVLINK regarding this. Is this connected to some Problem with the IO? Could this indicate a broken Board or some SW Issue with the IO?

As I have seen RC Input routes through the IO Chip. My SBUS Signal behaves a bit strange sometimes (there is a direct Wire from FMU <-> RC Receiver not many sources for faults. This is a standard genuine FUTABA Receiver R3008SB bundled with the TX):

• Most of the times 18 RC Channels are detected while my TX has only 10. The Display in QGC flickers sometimes between 18 and 10 Channels - but mostly shows 18.
• RC Lost Signal (when powering Down TX) is sometimes detected, and sometimes not. Sometimes it goes up and down. I assumed this to be unreliable with SBus until now.
  
• Just to note - to date I have performed many flight without any RC Issues at all! There have been no changes to the RC Equipment.

I'm about to Crosscheck with another FMUv2 Unit.

[tops4u]

Crosscheck with a newer Unit shows this when powering down TX multiple time - this is better (regained after Times match TX Activity):

It also immediately identifies the PostitionControl Mode. How come those two units behave so differently? FW Version is almost identical. The AUAV-X2 Unit is about 2.5 Years old the new one is a mRo X2.1 Unit which is about 1 Month old. Are there any changes in the IO Processor that do not get updated regulary with the Firmware Update?

[dagar]

The IO should be updating at every boot. You can force it by holding down the safety at boot up.
If you connect a console you'll see what's going on. https://dev.px4.io/en/debug/system_console.html

[tops4u]

Disregard my Comments regarding the Disconnect/Connect Messages. I Crosschecked today and it seems to be a Power Issue when the Aircraft is only Powered from my Notebook via USB. As soon as I Power it up completely with the Flight Battery it behaves correctly. This may probably also explain the IO Processor going to Bootloader Mode if USB Power alone may have been insufficient.

Still this does not resolve the crash, as obviously at this time it was not USB powered.

[tops4u]

This will maybe never resolved. As I did not trust the FMU HW after this event, it was replaced with a newer Unit.

[LorenzMeier]

Closing: #9271 (comment)