[FEATURE] r1685-two_stick_arm_with_timeout.patch

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
User avatar
fuh
Posts: 72
Joined: Thu Jun 13, 2013 5:12 pm
Location: Portugal

[FEATURE] r1685-two_stick_arm_with_timeout.patch

Post 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.patch

Note: 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. :-)
Last edited by fuh on Thu Jul 31, 2014 12:55 am, edited 1 time in total.

-ralf-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: [FEATURE] r1685-two_stick_arm_with_timeout.patch

Post by -ralf- »

Good idea .... timeout in config.h is in seconds?

User avatar
fuh
Posts: 72
Joined: Thu Jun 13, 2013 5:12 pm
Location: Portugal

[FEATURE] r1685-two_stick_arm_with_timeout.patch

Post by fuh »

Yes it is.

BirdShredder
Posts: 31
Joined: Mon Jun 16, 2014 10:50 pm

Re: [FEATURE] r1685-two_stick_arm_with_timeout.patch

Post 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.

User avatar
fuh
Posts: 72
Joined: Thu Jun 13, 2013 5:12 pm
Location: Portugal

Re: [FEATURE] r1685-two_stick_arm_with_timeout.patch

Post 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.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: [FEATURE] r1685-two_stick_arm_with_timeout.patch

Post 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

User avatar
fuh
Posts: 72
Joined: Thu Jun 13, 2013 5:12 pm
Location: Portugal

[FEATURE] r1685-two_stick_arm_with_timeout.patch

Post 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.

carlonb
Posts: 210
Joined: Sun Apr 03, 2011 6:29 pm

Re: [FEATURE] r1685-two_stick_arm_with_timeout.patch

Post 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.

Post Reply