Just looking to get some guidance on an issue I’ve never seen before.
One of our hexacopters (running AC 3.5.7) had a series of radio failsafe events (a normal occurance for us as we run Spektrum RC gear with satellite receivers on the drone for short distance manual ops as our systems are mostly used in auto missions). FS_THR was set to “2” which should just mean the copter continues on with the mission in AUTO mode.
In this particular case though, the log file (LINK) shows the drone erratically switching between STABILIZE, LOITER and AUTO (the three flight modes we setup) even though the pilot never touched the flight mode switch.
This happened on exactly the same mission that had been run 15mins prior, with the same drone, without incident. So it seems unlikely that external environmental factors would cause this.
What I don’t understand is the log file shows the radio inputs changing and thus the flight modes changing (as they should - as if the pilot was physically moving the switch on the Transmitter). This has never occured before and I’m wondering if anyone else has experienced this before or could help shed light on what might have caused this so we can work to ensure it never happens again.
We’ve ruled out the Transmitter and Receiver as they’ve both been re-used and re-tested and operate exactly as expected.
Could this be a receiver power issue? What would cause the receiver to change inputs without the transmitter changing?
Really appreciate anyone’s help or knowledge. Thanks in advance.
We have had a few issue’s in the past of receivers coming back into range in unpredictable ways. ie. if the throttle signal comes back the receiver is taken to be working again, however the other signals can sometimes take a little longer before they return to the correct value. So you get a short window of some channels being incorrect. I’m not sure if this is the issue in your case or not but a lot of work has gone into improving rc link robustness recently.
It seems that when you loose RC, CH5 goes to 1280 before RC3 goes to 932. This switch to stabilize mode.
Quick fix, set flight mode 1 to auto or RTL. On a long term, get a radio with sbus output.
Hi Pete, Thanks for the reply. Do you know in particular when the rc link changes were incorporated into code? This machine was running AC 3.5.7 and we’re now only up to AC 3.6.3 I believe so it wasn’t very old firmware.
Hi Andras, You’re correct in saying that it was commanded because it’s coming from the radio but this is not what the pilot says happened so it’s clearly an issue with the radio FS (hardware or software).
Unfortunately I’d prefer not to implement a hack but rather find the root cause of this issue but thanks for your suggestion anyway.
i’m not sure what protocol your using but this is what has gone in recently.
Copter 3.6.5-rc1 11-Jan-2019
b) Mode and Auxiliary switch range check to protect during FrSky SBUS failsafe recovery
2) RC protocol decoding for SRXL, SUMD and ST24 extended to all boards including pixracer and ChibiOS-only boards
Copter 3.6.5-rc2 15-Jan-2019
a) RC DSM sync bug fix (channel 8 could temporarily become zero, ChibiOS only)
I think the first point is the most important in this case.
Thanks Peter! We use Spektrum RC gear so it’s using the DSMX protocol. Still not sure that the first point is relevant to DSM (as it states FrSky SBUS)?
The last point “a) RC DSM sync bug fix (channel 8 could temporarily become zero, ChibiOS only)” sounds applicable but again it seems this is only on ch8 and it’s clear from the log file that the issue occured on ch5 and ch7.
it was a issue that a issue seen a couple of time when using frsky sbus, no reason it couldn’t happen with other protocols. The fix apply’s to everything.
I suggest you find a repeatable way to reproduce this, ideally on the ground, you may be able to use the range test function on your radio so you don’t have to go so far way. Then you can flash to the latest release and see if its fixed.
This is a great idea! I’ll try it tomorrow and see if we can make it repeatable. My concern is that it’s intermittent because 15mins prior to the flight in the log file above the drone flew this exact same mission without issue? Not even a failsafe!
It is definitely a problem with the radio hardware. If you look, RC5 and RC3 bounces all around, If rc3 below thr_failsafe then it is not a problem since rc5 is ignored. But if RC3 is not below thr_failsafe then a change in rc5 interpreted (correctly) as a mode change to stabilize. And once the copter is in stabilize mode then a change in rc3 to go below thr_failsafe initiates RTL. ultimately it is crappy radio receiver or faulty failsafe setting in the receiver.
Oh my, as others have said, the RC input values are wildly moving around for input channels 1, 3, 5, 6, 7 (maybe), 9, 11 (to a smaller extent), 12 and 13 (to a smaller extent).
The most common cause of interference is video transmitters being placed too close to the receiver. Broken cables are sometimes to blame. Beyond this I don’t have many ideas about why the RC inputs are being corrupted. As @iampete suggests Copter-3.6 does have some better error handling of RC input. This will probably help deal with the effects of the interference better.
Thanks Randy! There’s no video transmitters attached to these systems. The cable is quite long and was looped back and forth in a lovely “antenna shaped” bundle so this may have been the cause. We’ve not seen this issue on any of our other machines (which all use perfect length cables).
We’re also going to move from Spektrum to FrSky so hopefully that helps as well.
