I am running AC3.6.3 on Pixhawk 2.1 on my Quad frame.
I accidently set FS_THR_VALUE to 900 .
Then i fly my copter with this parameter.
I was doing a survey mission in AUTO till when all the motors were stopped and the quadcopter crashed.
Unfortunately there were no logs at that time , what i suspect is when the radio-failsafe
(Continue Mission) triggers , the mode shifted to Stabilize and the copter disarms in flight.
I wanted to confirm this from our developers.
Any one else having some information about this issue would be greatly appreciated.
I assume you have your transmitter failsafe programmed to send CH3 at something higher than 900 in failsafe, like 950 or something? And your CH5 mode switch goes to something else too? If so, your theory is reasonable and likely.
This would not be correct. There is no setting that causes disarm in flight even if it switched to Stabilize flight mode.
Most radios use no pulses for failsafe and ignore the FS_THR_VALUE. If it is an older radio that does not do no pulses and the failsafe value is set too low it won’t trigger. If RC signal was lost and the receiver is not set to hold last value on critical channels like flight mode, irregardless of the failsafe state in ArduPilot it will switch flight modes, but that is not an automatic disarm.
Some RC radios do not get all the channels back on the same frame at rebind after loss of signal. Which can cause undesired results. Spectrum radios have this problem, but tridge did a fix for those in 3.6.3.
If the aircraft is recoverable the log should be on the microSD in the controller, unless the microSD was ejected in the crash. I would say the most likely is that you do not have your receiver set to hold last value on channels 3 and 5. So failsafe from ArduPilot’s point of view never actually triggered due to the value being set wrong. But upon signal loss the flight mode switched and throttle went to minimum value. So it made rapid descent in an unpowered, but armed, state. If the radio is using no pulses for loss of signal, then ArduPilot’s logic will hold last value on every channel, even if the receiver becomes unplugged from the controller.
The log is required to see what actually happened.
I agree it is unlikely it actually disarmed. Switching to stabilize and going to minimum motor spin as if the stick is all the way down will have the same untimely demise. So to your ears, you may not even hear the motors turning and think it disarmed. But it is virtually impossible for it to actually disarm in the air.
The only way to get an in-air disarm is to use switch arming on a function switch, like say channel 7. Have a radio that doesn’t do no pulses. And not have the receiver set to to hold last value on your arming channel. That will cause it. But otherwise, yeah. It is pretty much impossible to get an in-air disarm.
I’ve started using “Motor Interlock”. It gives a convenient kill switch if you need to cut the motors. And it also stops you from completely cutting your throttle in the air. If in stab and you put the throttle all the way down, the motors still spin enough to keep the vehicle stable. I think if you had no RC control in this situation, it would basically do a hard landing. (If your situation is indeed that it switched to stab w/ zero throttle)
Interlock is a great feature… Better than motor stop and/or an arming switch, in my opinion.
Hmmmm… Basically a throttle hold like helicopters have, but does it actually affect engine throttle or collective for helicopters?. I’m going to have to take a look at the code for that. That function should probably be locked out for heli’s, if it’s not already.
Very fruitful discussion.
Now what i understand is , when the failsafe triggers (Contunue Mission) , FS_THR_VALUE =900 did not allow the Failsafe Action because radio Failsafe ch3 signal was 998 , so what happened that the mode shifts to stabilize with throttle at MOT_SPIN_MIN.