Failsafe: Turnigy 6X (others?) Code Hack

[RiceCake]

Hey folks,

I'm sure failsafe stuff is grating to a lot of people. You either yearn to have it to protect yourself or you discover eventually you really should've looked into it. Thankfully I'm the former and haven't crashed yet. Thing is, I have a Turnigy 6X transmitter which is teamed with an XR7000 receiver. Long story short...it has no built in failsafe features. There is a red LED that surfaces when its lost a signal so theoretically it would be possible to build an output into it to trigger failsafe, but I made an observation I wanted to run by folks here. For those curious, I'm using the 2.4 developer version of MultiWii. Actually I'm using a direct pull off GitHub from a day ago, but, you get the point.

So here's my thought in terms of this transmitter, maybe others. Channels 1-4 when the transmitter is off do about the norm for (I'm sure a lot of) receivers, that is, they center roll, pitch and yaw, and the throttle is brought to idle. Good for planes, etc, but when the quad is brought to idle you're obviously a brick heading to the ground. But AUX channels 1-2 are where things get interesting. Normally, a switch in the high or low position sets these channels to 2000 or 1000 respectively. Pretty natural. But with the receiver off, it centers these channels on 1500. I haven't chewed into the MultiWii code extensively, but I'm curious how hard that would be to implement. Sort of like having failsafe on its own channel switch...just setting the midpoint of a channel with no midpoint to enable failsafe. About the only possible caveat is using AUX channels 1-2 means there's an incredibly brief pulse at 1500 as its transitioning between states, but normal failsafe coding waits a second to take over anyhow.

I plan to look into this a bit and fiddle with it, but I can admit, I'm not the most prolific of coders on this sort of thing. Just throwing an idea out there. I'm unsure how other transmitters handle their AUX channel switches but if more simply center those channels as a result of signal loss, I'm assuming this could be a rather simplistic approach to detecting (and reacting) to TX failure.

[RiceCake]

Well that was easy.

To enable the behavior I was mentioning, its as simple as adding an extra check to the values of RC channels to include AUX1 on the failsafe code.

First, the existing code, in RX.cpp, line 128;

Code: Select all

          if((rc_value_pos==THROTTLEPIN || rc_value_pos==YAWPIN ||   \
              rc_value_pos==PITCHPIN || rc_value_pos==ROLLPIN)       \
              && dTime>FAILSAFE_DETECT_TRESHOLD)                     \
                GoodPulses |= (1<<rc_value_pos);

And my addition, with comments below;

Code: Select all

          if((rc_value_pos==THROTTLEPIN || rc_value_pos==YAWPIN ||   \
              rc_value_pos==PITCHPIN || rc_value_pos==ROLLPIN)       \
              && dTime>FAILSAFE_DETECT_TRESHOLD && (rcValue[4]<1300 || rcValue[4]>1700))                     \
                GoodPulses |= (1<<rc_value_pos);                     \

Basically when rcValue[4] is not less then 1300, and not more then 1700, we trip the code up to believe something is wrong. rcValue[4] corresponds to channel 5 in the code and when the switch is cycled it naturally runs between 1000 and 2000. The very brief transient between the two values is basically invisible, and never trips up the failsafe code in regular operation. FAILSAFE_DETECT_TRESHOLD in config.h needs to be set to 900 for this receiver/transmitter, as the normal stick configuration of the Turnigy 6X can result in a throttle under 1000 which makes it impossible to arm (failsafe gets activated on low throttle).

With all that implemented, a disconnect of the transmitter causes a 1-second delay, per config.h, and application of angle mode, a failsafe throttle, and hopefully, a graceful landing.