Recently I had my drone lift off and continue upward. There was no answer to the sticks or mode control. The only thing that I could think to do was to turn the radio off and let the radio failsafe perform an RTL. However, when I turned off the radio the drone just plummeted to the ground.
I have not figured out the near flyaway event but I wanted to find out what happened to the radio failsafe.
Subsequent bench testing showed that three possible scenarios could happen on a loss of radio signal (2 of them are not good):
1 - The failsafe will properly implement an RTL and on subsequent restoration of radio signal I can resume control and change the mode away from RTL.
2 - The failsafe will properly implement an RTL however on subsequent restoration of radio signal when I change the mode away from RTL the PreArm Radio Failsafe disarms the drone (even though the drone is armed).
3 - The PreArm Radio Failsafe disarms the drone (even though the drone is armed)
The radio settings are as follows
Normal minimum with radio on - 1014
FS_THR_VALUE - 975
Radio minimum on loss of signal - 965
My inquiry is why can a prearm failsafe, disaram an armed drone.
I have included the bin files from the event and the testing. I can see the disarms that occur when the radio failure is introduced. However, I cannot see the disarm that occurs during the attempt to recover from an RTL (item 2 above).
Any thoughts or insights would be greatly appreciated.
Vibrations do rise and altitude goes up (which is a problem that can occur) but in your case it’s hard to tell if the vibrations are a cause or symptom because of the short flight time and minimal good data.
For testing start in Stabilise mode and if behaviour is Ok then switch to AltHold mode.
When everything is more sorted out, use Loiter instead of PosHold.
The radio failsafe issue
What radio and transmitter do you have?
Run your radio calibration again, the Min/Max values are not saved.
Check in your radio and receiver documentation on how to set the failsafe actions. Some transmitters only output specific, pre-set values on channels, and some can be set to no output or no pulses (and this is preferred).
If you have the type that will only output pre-set values on the channels, you need to trim the radio throttle output down very low, below the FS_THR_VALUE, then bind the transmitter and receiver.
Set the throttle channel back to normal.
Connect to MissionPlanner (or QGC) and see what the flight controller reports when you switch off the radio - you dont need to arm and you should see the RC Failsafe message, or something about “no RC receiver”
Generally
Let’s see the next .bin log after those fixes and tests.
These were set while doing the motor tests during setup of the unit. These settings have worked for months before the crash. However since the crash I have had to make the following changes as 3 of the motors fail to spin at the previous setting:
MOT_SPIN_ARM,0.18
MOT_SPIN_MIN,0.20
I do not recall ever setting MOT_THST_HOVER, I have set it to the default shown in parameter list of 35.
The motors are RS 2212-920kv and the ESCs are SimonK 30A. Not to change the subject but could the change in the minimum spin be damage to the ESCs? I tried a replacement motor and the performance is the same.
The radio failsafe issue
What radio and transmitter do you have?
Flysky i6 and fs-x6B. I believe that everything is set properly as the receiver drops below the FS_THR_VALUE on loss of signal.
Connect to MissionPlanner (or QGC) and see what the flight controller reports when you switch off the radio - you dont need to arm and you should see the RC Failsafe message, or something about “no RC receiver”
The only way I can see the “Failsafe NO RC Receiver” is if it is armed. If not armed I only get the “PreArm Radio Failsafe” message.
In that I have viewed that the system can implement a PreArm Failsafe during flight I do not understand how that is a good thing. Shutting down the motors mid flight can only result in a bad outcome. Having a RTL Failsafe on signal loss that can be defeated by a check that should only be done when the unit is on the ground seems inconsistent.
Let’s see the next .bin log after those fixes and tests.
I am hoping to get back out soon and will post performance.
You have confirmed a few things so that’s good.
I would do the radio calibration again because your params seemed like it hadnt been done.
Sounds like your radio failsafe is working as planned.
Another reason you can have radio problems in-flight is if the battery is shielding the radio antennas. Check radio antennas a clear of other electricals and not in a RF shadow cast by the battery.
I was just pointing out how high the hover throttle is, as an indicator - you wont need to change it manually, but it will take time to relearn in AltHold or Loiter mode if you make any changes to other MOT_ params.
Those ESCs are old style. Maybe they need to be calibrated again and then recheck the MOT_SPIN_ARM and MOT_SPIN_MIN, since they are very high. Do this after you run the radio calibration.
Thanks so much for your suggestion of recalibration of the ESCs. Huge change in performance. MOT_SPIN_ARM is now at 0.09. But other issues have cropped up that appear to be affecting flight ops.
I have decided to start over with setup and tuning after this lesson. I feel that it will be an experience that will help me to better understand the drone.
