Auto mission failed - mid air change to stabilize

Hi,
Things with arducopter aren’t going well for me these days.
I’ve been performing some flight tests with an octocopter (Coaxial X4), did all the calibrations and then prepared a simple auto mission.
During AUTO, the HUD was giving some warnings regarding EKF changes to either compass1 or compass0, but the copter was performing well. Suddenly it changed from AUTO to Stabilize by itself!
Looking at the logs I found that all channels went to 874 (which is the value when radio is off :open_mouth: but that was not the case, the radio was ON), because right after it changed to stabilize by itself I triggered the mode to LAND (set on channel 10) (so it would try to safely land) and it engaged.
-Radio Failsafe is set to RTL.

  • What caused the change from AUTO to STABILIZE ? [EKF failsafe is set to ALTHOLD]
  • Why is the value of ch5in going to 874 if the radio was ON ?
    ** If there was indeed a problem with lost communication with radio, why there is no record of NO RC Receiver on the telemetry logs?

Logs here

Definitely all rcin went to zero, so basicly the unit was comanded to do what it did. Can you give a little bit more details about your setup and radio used?

You definitely have to take a look at the magnetometer problem because it is switching countless times. This happened to me only once (i am runing 3.6 RC12 Chibi OS) on the bench, the unit was switching compasses continuosly, i rebooted and didn’t see it since.

Corrado

So basically you’re saying that the change from Auto to Stab is NOT related to EKF ?
The radio is a Taranis X9D and a X8R receiver. Radio was sit on the table and not touched during Auto mission. Only grabed the radio when I saw it descending in Stabilize mode, and then since i couldn’t exactly see the copter/ground i put it to Land mode.
The Radio failsafe is set to ‘Enabled Always RTL’, GCS failsafe is disabled, FS_EKF_ACTION is set to ‘AltHold’.
Bench tests with regards to Radio failsafe, resulted in the RTL behavior, so I can’t understand if radio comm was lost, why didn’t it trigger to RTL ? :open_mouth:

I had similar issue. It is a possible situation (for FrSky at least) that receiver lost signal and reports low values to FC instead of doing no pulses.
So flight controller thinks it is a RC command.

For that situation I’ve proposed to validate RC input by check the value is within calibrated range.

From the logs you can see RCIN telling the flight controllor to put channel on a very low pulse. Probably on CH5 that low pulse corresponds to stabilize mode.

Corrado

The thing is, i didn’t touch the Radio while it was flying in AUTO.
And i have previously set failsafe to no-pulses and tested it on bench and in-flight, it was ok, going to RTL when radio link was broken.

Maybe a problem in how Ardupilot handles sbus, the fact is that rcin wento very low

Been using pixhawk, arducopter and sbus for a while, never had anything similar.
Guess i’ll have to do some tests and see if I can replicate the problem.

why there is no record of NO RC Receiver on the telemetry logs

Such happenings are always a bummer… I am no expert in this, but we also at times had missing events in logs.
I am guessing this may have to do with how parameters described here are set up?
And how fast your microSD card is/ what your logging frequency is/ what you are logging, and your cache.

Regarding the Taranis behavior on failsafe, you may also want to check
if you are correctly set to no pulses/ no signal.

Radio was sit on the table

On an operational side note, it is NEVER advisable to put the TX aside - even if running an auto mission. You should ALWAYS be able to intervene and counteract anything unusual by switching to a “lower mode”. Your first line of defense (in VLOS flying at least) is the radio control, and your last one the use of sending commands from the GCS via telemetry (in Mission Planner > Flight Data > Actions tab).

As part of my procedures when flying with autonomous vehicles, I always have the radio in hand. This time i was checking a parameter on the vehicle. Nonetheless the area is free of people/propertys and even then I was quick enough to grab the radio and change the mode to LAN right after it switch to STABILIZE by itself, so there was nothing else i could do.

After some bench tests, the problem doesn’t show. Is there any way I could try to trigger this to happen again ?

Hmmh, that’s often hard - to get to the bottom of things and make an issue repeatable, until you found the actual culprit…

Here are some ideas for troubleshooting: it might make sense to go over the compass calibration again and maybe redo it in an area free of magnetic interference. That could help to cut down a source of EKF errors.

Then verify your failsafe/ no pulse settings on the RX again, to rule that out. Also have yet another look at antenna placement, cabling, possible sources of interference…

I know, having something work on the bench and not in the air is always strenuous, and not knowing what caused it lowers trust in the aircraft, definitely a challenge. Hope you can resolve it!

Thank you for your time @camti ! Really appreciated.

I was trying to dig further looking at the logs and there was indeed a problem with all channels. All went to 874 (that usually triggers the radio failsafe - but for some reason it didn’t this time!)
From the image below one can see that channel 8 (that is set to trigger AUTO mode) went to 874 but quickly raised to 2000 again - even before the copter changed to STABILIZE.

So, the question is: if the radio loss was very short, why did the firmware not acknowledge the mode (ch8 at 2000) again - and didn’t keep it in AUTO ?

As you noticed all channels went 874 then restored their normal values.
So depending on your configuration, it is possible that CH8 commanded to enable AUTO but CH5 commanded to enable STAB. Obliviously only one mode could win in such case.

According to my tests , if i have ch5 in STAB and ch8 in AUTO (last switch moved) and turn off the radio, then on, the mode is still AUTO - as it should.