Mike's OpenTX/EdgeTX Clinic

Safe motor arming system

Powerful motors can cause serious injury! (Okay, so it's the prop that does the damage, but you get my drift...).

In this article I'll demonstrate a framework for creating arming systems which are (a) super safe and (b) avoid the need for switch checks at startup. Along the way you'll learn about the clever Sticky switch provided by EdgeTX and OpenTX. So join me as we explore how to do it.

Definitions

I'll use the following terms in the text:

• Arming: an action which allows the motor to run.
• Disarming: an action which prevents the motor from running, and stops it if already running. Note that killing is a special case of disarming, whereby the motor is disarmed unconditionally.
• Gesture: a user action which involves moving switches and/or sticks in a particular sequence.

The Sticky logical switch

The heart of an arming system is a switch. When the switch is True (on) the motor will be armed. When False (off) the motor is disarmed.

For our arming switch, we're going to use a 'Sticky' logical switch. Think of a sticky as an on/off switch where the 'on' and 'off' actions can be customised via the V1 parameter and V2 parameters.

• When V1 transitions to True, LS goes True.
• When V2 transitions to True, LS goes False

Here's the simplest possible example, where a Sticky emulates a 2-position switch:

Not very useful! However, things get interesting when V1 and V2 are themselves logical switches, as this allows us to program gestures like 'stick in corner' to switch on. But before we explore further, let's explore one of the benefits of using a sticky over a physical switch...

How to guarantee that the motor is disarmed at startup

One of the cools things about a Sticky switch is that it's False by default, which means that we can guarantee that the motor is disarmed at startup without switch checks. However, to take advantage of this, we must ensure that V1 doesn't transition to True immediately after startup. And that means that V1 should not represent a physical switch (since we cannot guarantee its position at the moment of switch on - at least without switch checks, which we want to avoid).

Instead V1 should should represent a user action, like moving a stick to the corner or pulling a momentary switch.

Example 1: safe arming system

Okay, so that's the theory, now to the practice! We'll program a real arming system, with the emphasis on safety.

For this kind of system, (a) arming should be difficult and (b) disarming should be easy (but not so easy as to do it accidentallly whilst flying the model). So we'll use the following gestures:

Arm:

1. Throttle to idle
2. Elevator stick back
3. Pull momentary switch briefly

Disarm:

• Pull and hold momentary for 2 secs

Implementation

The logical switches are shown in the Companion screenshot below. SH is a momentary switch. L3 is the arming switch.

How it works:

• L3 is the Sticky switch for arming and disarming the motor. L1 is the arming gesture, and L5 is the disarm gesture.
• L1 is the arming gesture: throttle to idle + elevator fully back + pull SH.
• L5 is the disarm gesture:
  • L5 goes True briefly, after L4 has been true for 2 seconds.
  • L4 is true while SH is pulled, but not while arming ('!L1')

Note that 'Thr' and 'Ele' refer to sticks (not inputs). In the mixer menu, inputs are prefixed with 'I', sticks have no prefix.

Example 2: 'smart' arming switch

Many pilots like to use a simple 2-position switch for arming. As I mentioned earlier, the problem is that switch checks are necessary to ensure the switch starts in the disarmed position. However, by making it 'smart', we can do away with switch checks, by making it report 'Off' at startup, regardless of the actual position of the switch. Again, the code is based around a Sticky logical switch.

Here's an example with switch SF.

The first line, L2, triggers a brief True pulse when SF ceases to be Off, in other words, when it transitions from Off to On. So, if SF starts in the On position, it will need to be moved Off then On. Therefore, regardless of the position of SF, L3 will always be False at startup. [Credit to Jesper Frickmann for this snippet.]

Note: In practice, a condition would be added to L2 for the throttle to be at idle.

Control the motor state

With the arming logic done, we can apply it to the motor channel. The method is the same regardless of the arming logic.

In the following example. CH7 is the motor channel, L3 is the arming switch:

How it works:

• The mix first line ('MAX') sets the motor to motor off. This is the default state.
• The second line ('Thr') is active only when L3 is true (motor armed). It passes control to the throttle stick. The 'multiplex' option must be set to 'Replace', so that the first line is ignored.

Using Channel Override special function

In theory, you could use a Channel Override special function to turn off the motor. However there are some drawbacks:

• It will not be possible to determine if the motor is running via a logical switch
• It's more difficult to debug since the logic is split between two menus
• There will be some data duplication.

I don't recommend this approach.

Download

Safety first!

• Remember to set the failsafe, so motor goes to idle on loss of signal
• Use the channel monitor to test operation before connecting up the motor
• Test, test and test again