Disarm without reason in mid air

[Antiheld86]

Board and Version

version

INAV/MATEKF722 1.9.1 Mar 23 2018 / 21:15:18 (c60386f9)

Behavior

I had my second flight with my new quarcopter build. While in 3D hold which worked nice, just a bit wobbly the quad disarmed without any reason i can see in 13m height with throttle 40%. The log says it Arm = off / Heading hold = on. I did not switch any mode while it happend. Before i already had a good first flight trying failsafe and RTH with no Problems.

TX: Taranis X9D RX: X8R with smartport telemetry

Blackbox logs/Config (.ZIP) where problem occurs

log fall out.zip dump.zip

Log and dump attached. In the dump are no NavModes configured because the Crash cutted one wire of the Magnetometer so These modes got disabled because of Hardware fault.

Is there any way to see in the log what gave the command to Switch modes?

I also ask myself where the Option is that disarm is not possible when throttle is not down.

[stronnag]

If my quad fell out of the sky with this much movement in the AH whilst doozing around in PH at < 3m/s and RSSI dropping < 20% at 14m from home, would one:

• Blame the firmware; or
• Fix the hardware

Tough choice.

https://vimeo.com/262424703

[Antiheld86]

I'm pretty aware about the fact that my quad is not perfectly configured. And i dont know why the rssi dropped before. But i already tried the failsafe and the rth and it performed well enough. But the log says that something disabled arm and enabled headless. And it was not me. So i would like to know what it was. I am new to this stuff and i am willing to think about that it was a failure of my configuration. But the last thing the Firmware should do, is to disarm and let it drop out of the sky. What i know is, that the failsaife wouldn't do that. And that if the rx Signal is lost, the failsafe should snap in. But that obviously did not happen.

The big movements in this Flight were given by my Input. After that i let it stay in one Position and it Held the position quiet well. But it was shaking al lot. i waited if it stabilised again without any Input. After a few seconds of waiting it disarmed.

It is very difficult to optimise PIDs or something to get flight behavior nicer if you are afraid that it just disarms because of - you don't know....

[shellixyz]

@Antiheld86 What is your receiver failsafe mode set to ? You should set it to "no pulses".

[Antiheld86]

It is set to "hold". But i don't think the Signal was lost. I could give commands all the time.

[shellixyz]

The disarm reason in your flight log is SWITCH so it looks like the FC has been disarmed by the ARM flight mode for some reason. And the reason must be that the channel controlling the ARM flight mode value got out of the set range.

[Antiheld86]

I don't understand why that whould be. I could not find the reason in the log. Where do i find it? The strange thing about that is, that my Arm mode is on channel 9 and headless is on channel 14. Level, AltHold, PosHold and RTH are on Channel 10 with Logical Switches. But obviosly just channel 9 an 14 changed. Is it possible to see the channel values in the log?

[shellixyz]

The disarm reason is recorded at the very end of the log. It is not displayed by the blackbox viewer. You need to open the file with a text editor. At the end of the log you will see "End of log (disarm reason:4)". 4 is disarm by switch.

typedef enum disarmReason_e {
    DISARM_NONE         = 0,
    DISARM_TIMEOUT      = 1,
    DISARM_STICKS       = 2,
    DISARM_SWITCH_3D    = 3,
    DISARM_SWITCH       = 4,
    DISARM_KILLSWITCH   = 5,
    DISARM_FAILSAFE     = 6,
    DISARM_NAVIGATION   = 7,
    DISARM_REASON_COUNT
} disarmReason_t;

Only the 4 first channels (thr/roll/pitch/yaw) are recorded in the log (rcData).

[Antiheld86]

I had the disarm_kill_switch=off, so it should not have been able to disarm, am i right?

[shellixyz]

Right, not if the throttle channel never went below min_check

[Antiheld86]

Actually i was wrong, the CLI say disarm_kill_switch = ON even though it is not enabled in the gui in the failsafe tab...

[Antiheld86]

I think there is a bug with the disarm_kill_switch feature. In the gui it is disabled no matter what i do. I can't eneble it in the gui. By Default disarm_kill_switch = ON in the CLI. I can disable it there. Enabling it in the CLI still leaves it disabled in the gui. So one reason my quad dropped is that it disarmed because of disarm_kill_switch = on even though it was disabled in the gui. Still don't know why the arm channel would Change.

[fiam]

disarm_kill_switch is no longer available in the configurator for safety reasons, you need to set it in the CLI. In most setups, you shouldn’t need to fiddle with that.

[sin5678]

use this tool to check your INAV config https://github.com/sincoder/inav_checker.git ,maybe helpful

[Pairan]

@stronnag just a little off topic ... but what tool was that you used to visualise the dump?

[stronnag]

@Pairan mwp https://github.com/stronnag/mwptools

[Pairan]

thanks, mate :)

[Antiheld86]

@fiam thanks for the clear up. It was explained different by @shellixyz in #2983

[shellixyz]

@Antiheld86 Oops sorry for that.

[Antiheld86]

Thank you for your help anyway.

[fiam]

@Antiheld86 My pleasure. I'm the one who removed it from the configurator, so you can blame me for that :-).

We discussed this a bit and we thought that it was too easy for users to toggle it OFF accidentally or without understanding what it did. Betaflight completely removed the feature, but for INAV we decided to just hide it from the configurator and see how users react.

While for this specific case disabling disarm_kill_switch is a valid workaround, we definitely need to get to the bottom of this problem and either fix it or determine with reasonable certainty that the problem comes from the receivers (and maybe workaround it, if possible). Previous reports of this problem were all when using R9M RXs, so it looked like a bug in them. However, your report is the first one using another model of RX, so we'll keep an eye on this from now on.

[Antiheld86]

Still don't know what the reason for disarming was, but I also found out to have a bad X8R in terms of range. Got RSSI warnings at 10m range. Bought a new one and now range seems to be ok. I still would think failsafe should have behaved differnt but can't tell if there is an other problem with the R8X.

[digitalentity]

Blackbox log or OSD will show disarm reason. Without knowing what code path caused the disarm we can't fix.

[Antiheld86]

Blackbox log is attached in first post. The disarm reason in the log is 4. Disarmed by switch. But I did not turn any switch...

[digitalentity]

Disarm reason 4 can only appear if receiver sent appropriate switch position to the FC. No other reason is possible. Maybe (for a minor hickup of receiver protocol handling) we should introduce a safety delay for changing AUX channels (in terms of applying a median filter on them or some other method that would prevent momentary changes in AUX positions).

[shellixyz]

We could also log the channel used for arming to get a more precise idea of what is going on with it when an unexpected disarm happens.

[Billj747]

Ever since I downloaded 1.9.0 the Horizon mode & AltNav hold do not maintain altitude, and the plane enters a slow dive. The Altimeter is also extremely intermittent despite 10+ satellites.

I randomly lost arming (where the stats screen pops up) and had to ditch it in a lake. After replacing all the electronics, including a new FC, I still had the same problems with random disarming (and resetting the "Home" point to where it (eventually) rearms. If it rearms. I ended up losing my plane 1 mile out due to this random disarming.

Omnibus F4 Pro V3, R-XSR, iNav 1.9.0

[digitalentity]

@Billj747 did you notice the reason for disarming in OSD?

[Billj747]

@digitalentity - It always says Disarmed by Switch. But the switch was never flipped in any of the 4 times that it randomly disarmed.

[digitalentity]

@Billj747 if it says "Disarmed by a switch" than the disarm signal originated from the code processing the receiver input. We've noticed this problem with R9Slim receivers, maybe a buggy receiver firmware is responsible for this.

The real problem is that S.Bus doesn't have any protection against data corruption and a rogue noise pulse will disrupt comunication. Since a momentary AUX channel flip is enough to disarm the quad - this is a problem.

[digitalentity]

Actually our RC median filtering is applied to AUX channels as well. Signal has to be really messed up for the corruption to get through.

[stronnag]

On April 23, 2018 11:32:36 PM UTC, Konstantin Sharlaimov notifications@github.com wrote:

Actually our RC median filtering is applied to AUX channels as well. Signal has to be really messed up for the corruption to get through.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/iNavFlight/inav/issues/2981#issuecomment-383754985

Is this the same filter whose application logic was inverted in 1.9 and fixed in 1.9.1?

[digitalentity]

@stronnag yes. Since the "disabled" setting was actually enabling the filter, the issue reported was actually with filter enabled. I wonder how many data corruptions was there on the wire if they skipped the filter eventually.

[giacomo892]

@stronnag @digitalentity perhaps we should enable that filter back on AUX channels making to filter even more to avoid bad data to change flight modes or disarm the machine? We won't suffer than much in terms of latency from the AUX channels. If the machine is armed via stick combo it needs to be 2 channels to be in the disarm position for some time. Feels like a burst of bad PWM/PPM/SBUS (IBUS and FPort have cksum and they should be very safe to use) command can disarm a machine if the arming channel gets junk data.

[stronnag]

On April 24, 2018 8:36:31 AM UTC, giacomo892 notifications@github.com wrote:

@stronnag @digitalentity perhaps we should enable that filter back on AUX channels making to filter even more? We won't suffer than much in terms of latency from the AUX channels. Also if the machine is armed via stick combo it needs to be 2 channels to be in the disarm position for some time. Feels like a burst of bad PWM/PPM/SBUS (IBUS and FPort have cksum and they should be very safe to use) command can disarm a machine if the arming channel gets junk data.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/iNavFlight/inav/issues/2981#issuecomment-383850732

@fiam also had a suggestion for additional sbus validation, which I'm not in a position to look up at the moment (maybe sbus channels 17 and 18 bring zero (or not))

[brat002]

I also experienced such kind of problem on 1km height. That would be disaster, but I had armed again via switch. matek f405-ctr and Frsky L9r receiver. This is video of the incident https://youtu.be/lYcdIiO21Ss?t=36.

[digitalentity]

@brat002 also S.Bus?

[digitalentity]

@brat002 @Billj747 @Antiheld86 Can you post output of tasks CLI command when your receiver is powered up and RC link is enabled?

[brat002]

@brat002 also S.Bus?

Yes. I thought I am alone with the problem, but it is not.

Can you post output of tasks CLI command when your receiver is powered up and RC link is enabled?

I will do this at evening.

[Billj747]

@digitalentity - unfortunately the first FC & Rx met its death in a lake. The second FC & Rx was lost with the plane. I'm a bit hesitant to build another one after losing $500 in electronics and the plane from 4 random disarming events, only 2 of which were able to rearm and save the plane.

FWIW, they were both Omnibus F4 Pro V3 boards and R-XSR receivers with the R-XSRFCC171009.frk firmware and the uninverted SBUS signal taken from the "P" pad of the Rx. I'm not sure if that helps diagnose anything.

[digitalentity]

@Billj747 if it's hardware modified RX, I'll blame it. Small CPUs have very week output drivers barely capable to drive a long wire from hacked RX to the FC. Such long wire coupled with week drivers might introduce all sorts of signal disruptions. Inverter installed on those RXes not only inverts the signal, it also adds better capabilities to drive the long line.

[Billj747]

@digitalentity Do you really think adding 5mm of line to the "P" pad on a total length of 12cm MAX length of wire from the Rx to the FC would have an effect?

[digitalentity]

@Billj747 it actually might. It's not about adding more length to the wire itself. It's about significantly reducing receiver's ability to drive the long wire. And at 100kbps 12cm of unbalanced transfer line is a "long wire"

[Billj747]

12cm is long? I don't have the plane anymore but it's probably closer to 8-10cm. If that's the case, i'll pick a different FC where I have enough UARTS to use the inverted SBUS signal.

[digitalentity]

It depends on how you drive the wire. In many cases 12cm would be considered a "long wire" indeed.

Think of a signal over a long wire as of a 100kg weight you need to lift. You can try lifting it manually - possible, but unreliable (this is receiver CPU's weak pin). Alternatively you can use a crane which will make the task much easier (this is an inverter-driver on RX having stronger source/sink capabilities).

[Billj747]

@digitalentity my earlier message was incorrect. I am taking an uninverted SMART PORT signal from the "P" pad of the Rx (which is for S.Port. The "B" pad is the uninverted SBUS).

Since I am connected to the inverted SBUS, do your comments still apply?

[digitalentity]

@Billj747 with an invertor chip you probably don't have the noise issue and it's likely the receiver itself that misbehaves.

[Billj747]

@digitalentity Has multiple people running the R-XSR have this problem? What is known to be a reliable receiver?

[Scripto23]

I don't think it is the R-XSR. I was running Crossfire (full rx) with ppm to an Omnibus F4 board, and had the "disarmed by switch issue". I was about 2 miles out and lost the whole plane. The common denominator in these scenarios seems to be the Omnibus F4.

[Skaloverus]

I had the disarm issue today. Running F35 board with R9m. One thing as suggested by my wingman, is to off the telemetry module on the Tx and I did just that. Seems like the problem goes away. Manage to fly 2 packs. But I've no visibility of my Rssi after that.

[Billj747]

@Scripto23 Then what is a popular FC that's known to be reliable? @Skaloverus Can you not view RSSI through the OSD even with telemetry turned off?

It sounds like there is some programming work that needs to be done, and not just pointing blame at hardware.