Bounty! RTL mode cuts motors off and falls to the ground

Hi all,

For anyone that can be give me a clear reason why this happened, I will paypal you $20.

I was flying around and experienced a radio failsafe. RTL was engaged for one second and seemed like all motors were cut off while in RTL. Failsafe went away & stabilize kicked in very quickly, but my full throttle was not enough to recover - thankfully slowed it down enough to have no damage.

I have tested RTL and it performed (previously) without issue. I always manually RTL once before taking longer flights. The only thing I can see is that I checked the throttle position for my radio failsafe - it is at zero. But this should not matter since in RTL throttle is not used (correct?).

I’ve been going through the logs but it does not make sense to me why would RTL set throttle to 0. Under CTUN, when graphing BarAlt + ThrIn + Thr out, at line 3104 ThrIn/out goes all the way down to 0 (when RTL kicked?). Shortly after on line 3126 you see full throttle, but BarALT continues to dip. Here is a zoom of the area:
api.ning.com/files/hSOUK3FODotZl … F/blah.jpg

Video of so you can hear motors cut out (I was trying new settings on my gimbal which is causing it to twitch in this video):
[youtube]http://www.youtube.com/watch?v=S1Hp6iAEnlU[/youtube]
youtube.com/watch?v=S1Hp6iAE … e=youtu.be
I checked if maybe my RTL ALT was set to zero, but it is not:
My THR_MID is set to 450.

Any help would be greatly appreciated… I’m afraid to do any real flying until I can figure out what happened. Log attached.

Well since i’ve gotten zero help on this, i figured i would perform some field tests. i’m not sure if this is a bug or not, but it sure seems like it.

The test:

  1. set radio failsafe to RTL with throttle in mid position. simulated failsafe by turning off my DX8 radio. RTL goes as planned.

  2. set radio failsafe to RTL with throttle at zero position. simulated failsafe by turning off my DX8 radio. Copter falls out of sky.

Is this by design? I thought throttle was ignored in RTL until the land sequence, and definitely should not turn off motors completely. Can a developer please chime in here? If this is by design for whatever reason, I really feel there should be a clear mention!

I guess your receiver s failsafe is programmed to mode= stabilize and throttle down.
if so, you can arm it and spin up without taking off, then turn off tx.
for safety, reproduce without propellers, or use a current limiting powersupply instead of battery.

I’m using ezUHF. To set it’s radio failsafe you place your radio inputs in whatever position you want for failsafe and press a button. So for the second test i just simply set my flight mode toggle to RTL and left my throttle at zero (vs test 1 when i left throttle at 50%+RTL).

i’m just trying to understand why RTL would kill the motors - throttle is not controlled by the user in RTL until you have reached ‘home’ (descending to final alt or landing). i’ve manually switched to RTL, then put my throttle to zero and it does not kill the motors.

after some digging we’ve found the cause and a new issue.

first off the reason RTL went to zero throttle was because of the way I set my failsafe. I use ezUFH for radio control, and to set it’s failsafe you place your remote in whatever position you want, then hit a button to save it as the failsafe action (ie: change mode to RTL). I made the mistake of leaving the throttle at zero when I set my failsafe to RTL, and as a safety precaution built into the code, RTL will not start with zero throttle even if you are in the air. The reason for this is a safety concern; users were walking up to their copters while armed, unplugging their remote and watching their copters fly up to RTL.

The second issue is more important. There is a problem with the current ppm encoder. If you use PPMSUM between your RX and APM, it will not detect a proper failsafe in case of an RX failure (if your radio RX loses power or fails while you are flying for example, the motors will cut out instead of performing the throttle failsafe). The only way around it is to load a beta firmware for the ppm encoder, or not use PPMSUM. reference: diydrones.com/xn/detail/7058 … nt:1493959