RTL without reason

Hi guys!

On sunday I had two flights within 10 minutes. The first time was all right but during the second one something strange happened. Hovering in PosHold as well as in Stabilize the copter attempted to perform a RTL several times. As you can see in the diagram, the only switch moved was RCIN.C5 which is the flight mode. RCIN.C7 is a dedicated RTL switch and remained untouched at all time. Also there is no indication of a failsafe. This is the first time something like this happened and I can’t figure out what happened. Maybe someone can help me?

Some information on the rig:

Navio2 + AC 3.4.4 RC1
Raspberry Pi 3
Y6 Frame

Any help is highly appreciated! Thanks!

Regards,

finst

2017-03-26 14-55-01.log (2.6 MB)

RC7 is high when it should be low - so you can hit the switch to activate RTL; RTL wouldn’t have kicked if you set it that way;

do you use a pwm to sbus/ppm encoder? there are some spikes which shouldn’t occur without moving the switches on your remote; either due to interference on your cables or bad CPPM/sbus converter or due to your receiver or transmitter;

I noticed that RC7 was on high. But my understanding is that the RTL switch gets overwritten by the flightmode in case RTL is on high and I then move to another flight mode. Before taking off the flight mode was on PosHold + RTL on high. Next I switched to stabilize and took off, so RTL should have been inactive. If not, why doesn’t the graph show RTL right from the beginning?

it switched because your RTL “spiked” down to about 1500 and then back up to high; --> Navio believes you hit the switch from low to high;
I only mentionend this because that way you would get rid of the “RTL kick-in” for now;
Your problem is not really the way you set the channels:

you should get rid of the spikes!

Well, that makes kind of sense. I still think a switch should be either high or low (or at least something like 10% / 90%) to be recognized as flipped. Anyway, I guess there’s nothing to do about that for now.

Regarding the spikes, I’m using a 433Mhz radio to transmit ppm from my spektrum to the navio. It was all fine until now, so where to start? I guess I could shorten the cable between radio and navio or maybe shield it. Ideas?

I would investigate that issue by trying to reproduce the spikes; wiggle the cable(s)
let the motors spin at full speed (without props or reversed props)
shake your transmitter ( gently)
APM Planner2 has a nice view for live values (or Mission planner in status tab could not be fast enough for that)
alternatively try to replace transmitter/receiver and observe if the issue persists;

(only) RCIN 7 and 8 have those spikes - but at the same time; that’s strange especially if you have only one cable from receiver to navio; I would blame receiver/transmitter first before the cable but i never really experienced these spikes…

yesterday and they day before I had the exact same issue with a frsky tiny 8ch receiver and PPM or SBUS - but much bigger spikes;
since i have implemented an “emergency interlock” switch for the motors - copter dropped out of the sky; :scream: twice! first time the sdcard contacts became ruined - I didn’t have any logs and flew again; to the second crash due to emergency off; (with a pixhawk)
I just wrapped copper foil around my receiver, placed him further away from the escs and put a toroid on the PPM/SBUS cable and will test tomorrow and report!
Did you make any progress?

i never experienced these interferences with my x8r; but with this receiver my changes did not make any interference occur anymore (at least in my 10min flight yesterday)!

Sorry for not responding, I’ve been busy the last week.
No, I did not investigate the issue any further mainly because there was no time. I thought about getting a different receiver, but since your workaround seems to fix things, I maybe try them too before I buy something new.
Any updates on this?

I briefly checked flightlogs from previous flights, I didn’t find any spikes. Maybe the spikes result from some kind of interference rather from the receiver/transmitter failing?

i was flying today again with that setup; it was a very clean input; for a while; then i hit RTL flight mode - copter climbed 15meters and flew home; over home he loitered a few seconds - and fell out of the sky - again;
shielding and toroid did help great - until today; so actually did not help :frowning:
channel 6,7 and 8 show the same pattern of spikes;
i believe - it has to have something to do with the design of the receiver and interference and the protocol(i have no clue how protocol works); (he’s not really near to high power cables - but could be further)
my x8r did behave much better; i always implement emergency power off - so i would have noticed…

I know it has been a while since this issue was discussed. However I have had 3 separate incidences of what seems to be similar issue characterised by falling out the sky during the last stages of RTL. We initially attributed the incidents to battery failures as it appeared as if one cell had dropped suddenly. This may actually have been post crash and in the most recent incidence I have been able to eliminate battery failure as a problem.
To my eye the log appears normal but truncated just before the crash and the crash does not appear to be included in the log. I’m trying to eliminate a Pi crash or brownout issues. The ESCs did not beep and the motors kept running. I had immediately throttled down and attempted to disarm. I also - regretfully - pulled power as soon as I got to the copter thinking to avert issues with broken cables. I now wish I had logged in to the PI and tried to do some diagnostics.
The other area of concern is that perhaps the Navio2 hung up in some way or that it partially disconnected from the Pi. I don’t really see evidence in the logs for this but am fishing for things to troubleshoot.
The system is powered by a CastleCreations 10A uBEC via the servo rails. ESCs are all DJI 620S with all three wires connected - signal, ground and pos. Perhaps I should remove ground and pos?
Any thoughts would be much appreciated!2018-05-13 09-28-33.bin (3.1 MB)