Page 1 of 1
[FEATURE] r1685-two_stick_arm_with_timeout.patch
Posted: Wed Jul 30, 2014 2:07 am
by fuh
This patch adds a new feature:
This mode forces the arming sequence to be done with two sticks: THR DOWN + YAW RIGHT + PITCH DOWN + ROLL LEFT
It also will automatically disarm the FC if no throttle input is given during the user settable timeout period (in seconds). You may find this feature very similar to the DJI Naza arming sequence.
r1685-two_stick_arm_with_timeout.patchNote: This is my arming method for a couple of weeks now without issues. But as I had to do some stitching to extract the patch from my local repository (more code changed other than just this feature) please validate the functionality before going live with it. And as usual, report back your findings.

Re: [FEATURE] r1685-two_stick_arm_with_timeout.patch
Posted: Wed Jul 30, 2014 9:38 pm
by -ralf-
Good idea .... timeout in config.h is in seconds?
[FEATURE] r1685-two_stick_arm_with_timeout.patch
Posted: Wed Jul 30, 2014 10:23 pm
by fuh
Yes it is.
Re: [FEATURE] r1685-two_stick_arm_with_timeout.patch
Posted: Wed Jul 30, 2014 11:22 pm
by BirdShredder
I reviewed your patch by looking at the diff. (I don't have indepth knowledge of the MW code). Some comments:
- Your patch is a bit polluted with whitespace changes
- For some reason you expose go_disarm() in MultiWii.h(I'd say put a forward declaration in MultiWii.cpp if needed.)
- I consider it bad practice to undef other arming methods, especially since they do not conflict.
Re: [FEATURE] r1685-two_stick_arm_with_timeout.patch
Posted: Thu Jul 31, 2014 12:53 am
by fuh
I've taken your feedback and actually moved the go_disarm() prototype into a #ifdef clause inside Multiwii.cpp.
I also removed the the undefs, two stick arming can coexist with any other arming method, so it no longer is called SAFER_ARM_DISARM_VIA_TX but instead ALLOW_TWO_STICK_ARM_DISARM.
The patch file was updated.
Re: [FEATURE] r1685-two_stick_arm_with_timeout.patch
Posted: Sat Aug 02, 2014 10:05 pm
by Alexinparis
Hi,
I'm not fan of both ideas:
1) I think the security with one stick arming sequence is enough: even if arming is done by error, it can be done only in a idle motor state.
2) I think it must be up to the user to care about the arming state of the multi. + it can be confusing for those using the motor_stop option
[FEATURE] r1685-two_stick_arm_with_timeout.patch
Posted: Sat Aug 09, 2014 1:49 pm
by fuh
Hello Alex I was out for some time.
It started because I found very easy to arm the FC with the TX on my neck (DX8 is not a well balanced radio when sitting on it's neck strap). But I like the idea of a timeout of no input is giving, why would you want the props spinning in idle mode for more than just lift off ?
If you look at it from a safety standpoint then I don't like MOTOR_STOP, even for experienced people it's way too easy to cut a finger. The FC after being armed must always provide a good visual indication that it is on a dangerous state, props must be rolling as LEDs are not enough from a distance.
Re: [FEATURE] r1685-two_stick_arm_with_timeout.patch
Posted: Sat Aug 09, 2014 5:35 pm
by carlonb
fuh wrote:Hello Alex I was out for some time.
It started because I found very easy to arm the FC with the TX on my neck (DX8 is not a well balanced radio when sitting on it's neck strap). But I like the idea of a timeout of no input is giving, why would you want the props spinning in idle mode for more than just lift off ?
If you look at it from a safety standpoint then I don't like MOTOR_STOP, even for experienced people it's way too easy to cut a finger. The FC after being armed must always provide a good visual indication that it is on a dangerous state, props must be rolling as LEDs are not enough from a distance.
+1
Totally agree.