Force arm #4891

peterbarker · 2016-09-26T13:12:47Z

Passing a parameter value of 2989 through as the second parameter to the long command used to arm a vehicle will bypass the arming checks.

peterbarker · 2016-09-26T13:20:53Z

Why is this a good idea?

Because when ground testing an aircraft it is often useful to not do arming checks - e.g. you haven't attached all the bits of the vehicle or you know you don't need an accurate position.

This is currently accomplished with the equivalent of "set ARMING_CHECK 0" - but that is a persistent change and aircraft have flown with that setting when they shouldn't have.

Using "arm throttle force" (or some clicky-clicky equivalent, I suppose....) is a temporary override reducing the risk of flying with checks disabled.

khancyr · 2016-09-26T16:34:35Z

@peterbarker
Agree with you or we can add a warning : arming check disable ! But it miss rover change ;-) .
Could be even better to have a testing mode. When programming a DJI 1000 (can't disconnect motor easily or remove propeller), I got some problem to test failsafe function like landing gear,RTL, and parachute since you need to arm and take off or put throttle and shake uav to put in in-flight state ! Testing mode should allow to test all auto function and failsage on ground without arming motor .

magicrub · 2016-09-26T16:46:54Z

ArduPlane/GCS_Mavlink.cpp

@@ -1455,7 +1455,8 @@ void GCS_MAVLINK_Plane::handleMessage(mavlink_message_t* msg)
        case MAV_CMD_COMPONENT_ARM_DISARM:
            if (is_equal(packet.param1,1.0f)) {
                // run pre_arm_checks and arm_checks and display failures
-                if (plane.arm_motors(AP_Arming::MAVLINK)) {
+                const bool do_arming_checks = !is_equal(packet.param2,2989.0f);


magic number? Needs to be documented

I'm not sure we document these magic numbers. Note the magic number on disarm force, for example - do we document that anywhere?

Ideally as an ardupilot.xml enum. Failing that a #define in GCS.h. But the proper place is a enum with exactly one value :)

magicrub · 2016-09-26T16:47:10Z

ArduCopter/GCS_Mavlink.cpp

-                copter.init_disarm_motors();
-                result = MAV_RESULT_ACCEPTED;
+            } else if (is_zero(packet.param1))  {
+                if (copter.ap.land_complete || is_equal(packet.param2,21196.0f)) {


another magic number?

dgrat · 2016-09-27T11:52:21Z

I have strong concerns. Additionally, I don't see a benefit, as the arming checks can be already deactivated.

OXINARF · 2016-09-27T14:56:21Z

@dgrat What are your concerns? Have you read Peter's second post? He perfectly explains the reasoning behind this: stop people from deactivating arming checks just because they what to arm while bench testing and then flying with the checks deactivated.

dgrat · 2016-09-27T15:51:20Z

@OXINARF
Beside that it seems unnecessary because it can be already deactivated by disabling the arming checks in the GCS.
This:

!is_equal(packet.param2,2989.0f);

It doen't really look confident

OXINARF · 2016-09-27T17:28:22Z

Beside that it seems unnecessary because it can be already deactivated by disabling the arming checks in the GCS.

And it has been explained why that is a bad option...

It doen't really look confident

What does this mean?

dgrat · 2016-09-27T17:52:05Z

@OXINARF
The implementation is weak, and this is why I think so:

The magic number definition could be at least put in a macro definition to enhance readability
The new MAVLink function takes two bools now, both containing a variable switching the arming
- This looks lazy: (const bool arming_from_gcs, const bool do_arming_checks)
- I am sure this can be solved in a more elegant manner
I don't like the fact that someone uses float for '==' comparisons (in general)
- Maybe convert it into an integer instead to be lazy using is_equal(), which I just added to the math-backend because of compatibility reasons ):

magicrub · 2016-09-27T20:44:31Z

I think casting the float to int32 is perfectly fine, we should do that in more places on mavlink params. Also, I pointed out the magic number thing, definitely needs to be documented via define const or something

R-Lefebvre · 2016-09-28T14:59:32Z

I think this is a good idea. I too often am looking at my parameters and realizing "Oops, this is another one that I turned off arming checks and forgot to reset!"

If this PR isn't merged, then I would at least like it if we could have something where, when doing standard arming with checks defeated, instead of just saying "Armed" the GCS will display something like "Armed. All checks defeated."

OXINARF · 2016-09-28T17:25:29Z

@dgrat

The magic number definition could be at least put in a macro definition to enhance readability

I don't have an issue with that, although this isn't something we want people to use in normal operation, so it being hidden in code isn't that bad.

The new MAVLink function takes two bools now, both containing a variable switching the arming

They have different meanings, how would you propose to do it differently?

I don't like the fact that someone uses float for '==' comparisons

I agree with that, but you should understand that it is transmitted in MAVLink as a float. Also, this isn't a safety problem, so if the check fails for some reason it isn't critical.

@peterbarker Have you though about adding a new command instead of adding a new magical number? MAVLink has MAV_CMD_DO_FLIGHTTERMINATION which should now be used instead of the magical number, maybe it could have a MAV_CMD_DO_FLIGHTTESTING or something like that?

dgrat · 2016-09-28T18:37:07Z

@OXINARF

I agree with that, but you should understand that it is transmitted in MAVLink as a float. Also, this isn't a safety problem, so if the check fails for some reason it isn't critical.

Agree, but still it isn't the optimal solution.

rmackay9 · 2016-10-05T07:41:14Z

I'm happy with this but there's one serious danger which is that I think it allows arming in Loiter, PosHold, etc when the EKF doesn't have a position estimate. We should not allow this under any circumstances because I think the vehicle could act very badly. I'm not sure what it will do actually.

peterbarker · 2016-10-05T09:13:40Z

@R-Lefebvre In regards to the "all checks defeated" warning you suggest - I actually added that to MAVProxy a few weeks back, 'though it actually just says, "arming checks disabled" if you have any checks disabled.

peterbarker · 2016-10-05T09:17:40Z

@OXINARF The shape of this patch is based on the existing "force disarm" functionality: https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/GCS_Mavlink.cpp#L1432

Note the use of magic numbers, and abusing random positional parameters to achieve a specific outcome :-)

peterbarker · 2016-10-05T09:27:46Z

@rmackay9 That sounds like fun. I would assume EKF would drop you into stabilize or land-without-gps mode.

But that's what "force" is for. It says you're happy to pretend you know what you're doing and will wear the consequences...

I would prefer to keep "force arming" a true force, but we could instead pass a bitmask around of checks to enforce in copter, passing through an empty mask if force is set.

OXINARF · 2016-10-05T17:51:29Z

I agree that a Force Arm should force arm no matter what. Otherwise it isn't a real force and we'll have requests to have a method to arm in any mode.

@peterbarker I know that this follows the same logic of the magic follow disarm, but that is a deprecated method. The new method is using a specific message, which I think should be the way to go with this.

peterbarker · 2017-05-08T09:56:00Z

@DonLakeFlyer @billbonney @meee1 Could I ask you to weigh in here, please?

Executeive summay - question is how we should implement a "force arm". There are two options:

implement it just as we do "force disarm" (a magic number in one of the parameters to MAV_CMD_COMPONENT_ARM_DISARM
create a new mavlink message, analogous to MAV_CMD_DO_FLIGHTTERMINATION

I'm not convinced a force-arm is the opposite of a MAV_CMD_DO_FLIGHTTERMINATION. In the OBC context, a FLIGHTTERMINATION is somewhat more serious thing to do to a plane than a disarm (setting control surfaces to maximum deflection etc etc). It is definitely the opposite of a force-disarm, however.

I'm asking your opinions here because all the GCS implementations I've looked at use the magic-number approach. No point making this force-arm change if the GCS aren't going to implement it. Modifying them to allow force-arm (a shift-click on arm, perhaps?) is going to be a relatively small change.

lvale · 2017-05-08T19:42:23Z

@peterbarker If this goes forward I believe that there should be a audible and visual warning for as long as the vehicle is armed in forced mode, so that users get notified of the extraordinary condition on which the vehicle was armed.

DonLakeFlyer · 2017-05-08T19:54:43Z

My feeling is that options which will be used/found by 1% of the user base should not be added.

peterbarker · 2017-05-09T02:12:18Z

On Mon, 8 May 2017, Don Gagne wrote: My feeling is that options which will be used/found by 1% of the user base should not be added.

I'm hoping people *would* use the option in preference to setting LOG_BITMASK to 0!

peterbarker · 2017-06-07T01:59:12Z

I've updated this to pull out the magic values into variables.

rmackay9 · 2017-06-07T04:19:40Z

We just need to make sure that some checks are still applied for copter. For example, it shouldn't be possible to arm in Loiter with no position estimate (i.e. no GPS). no matter how much the user thinks they want that, it would be a very bad result that would end in tears.

OXINARF · 2017-06-07T14:50:13Z

@rmackay9, you are the Copter maintainer, so you have the final word, but I strongly disagree with that. The disarming magic doesn't force any checks, and if this is going to force checks then we don't need it, we already have an arming method.

For example, it shouldn't be possible to arm in Loiter with no position estimate (i.e. no GPS). no matter how much the user thinks they want that

What prevents the user doing that now by disabling the arming checks?

I understand the concern of having this, but it should be deeply hidden in any GCS. The disarm aux switch looks way more dangerous to me and that went in. The forced disarm is always sent by MP when pressing the disarm button, which also looks more dangerous to me.

peterbarker · 2017-11-14T06:11:34Z

@lvale audible alarm when force-armed? You would also be OK with a MUCH LOUDER alarm if their arming-checks parameter is zero, then? Because 3/4 of the logs I see have them disabled - it's a "set and forget" way of making your problems go away, and I'm pretty sure the "forget" part is real.

peterbarker · 2018-06-15T23:57:48Z

I've verified that if you do not have position when arming in loiter/poshold then the vehicle behaves appropriately - mode land, disarm.

peterbarker · 2018-06-20T02:21:55Z

It was agreed on the dev-call to merge this in. I accidentally closed this issue before it was merged in - I've now pushed it in.

rmackay9 · 2018-06-20T02:27:22Z

As a side note, personally I prefer #defines rather than constants. The reason is just that I find them easier to differentiate from regular variables because they're normally in caps.

peterbarker · 2018-06-20T02:42:58Z

@rmackay9 You can have these variables in CAPS, too :-) That gives you type-safety, namespacing and differentiation. IIRC I did try it on for size once - but somebody didn't like it...

WickedShell · 2018-06-20T03:12:30Z

Either way if we make a MAVLink enum for it that can replace the constants anyways :)

magicrub reviewed Sep 26, 2016

View reviewed changes

peterbarker mentioned this pull request Oct 6, 2016

Copter: allow arming in AUTO #4919

Closed

lvale mentioned this pull request Oct 29, 2016

Copter: support for arming and disarming using an auxsw #4873

Closed

gmorph added Copter Plane labels Oct 30, 2016

peterbarker force-pushed the force-arm branch from 31ed57e to d22afa4 Compare November 30, 2016 01:59

peterbarker force-pushed the force-arm branch 2 times, most recently from 5c8d566 to 9953186 Compare December 24, 2016 05:11

peterbarker force-pushed the force-arm branch from 9953186 to dc8036e Compare January 4, 2017 05:09

peterbarker force-pushed the force-arm branch from dc8036e to 2f799f4 Compare January 16, 2017 01:17

peterbarker added this to the AC 3.6.0 milestone Jan 16, 2017

peterbarker force-pushed the force-arm branch from 2f799f4 to 4e5ddc3 Compare January 17, 2017 04:13

peterbarker force-pushed the force-arm branch from 4e5ddc3 to 630484b Compare February 27, 2017 22:49

peterbarker force-pushed the force-arm branch from 630484b to efe4571 Compare June 7, 2017 01:57

peterbarker force-pushed the force-arm branch from efe4571 to 15009dd Compare August 25, 2017 04:34

peterbarker added 7 commits June 16, 2018 09:47

Copter: return appropriate response to failed disarm

bb41757

Plane: option to force arm, bypassing checks

eb974d4

Copter: option to force arm, bypassing checks

14b996a

AP_Arming: option to force arm, bypassing checks

01afefe

GCS_MAVLink: add magic number definitions

9951ce7

Copter: use magic force arm/disarm definitions

b99f06d

Plane: use magic force arm/disarm definitions

a6b36e9

peterbarker force-pushed the force-arm branch from 15009dd to a6b36e9 Compare June 15, 2018 23:57

peterbarker added the DevCallTopic label Jun 15, 2018

peterbarker closed this Jun 19, 2018

peterbarker deleted the force-arm branch June 19, 2018 07:17

peterbarker mentioned this pull request Jun 21, 2018

Add support for ArduPilot's force-arm option mavlink/qgroundcontrol#6624

Closed

OXINARF removed the DevCallTopic label Jul 2, 2018

WickedShell mentioned this pull request Jul 17, 2018

There should be an ARM override #3825

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Force arm #4891

Force arm #4891

peterbarker commented Sep 26, 2016 •

edited

peterbarker commented Sep 26, 2016

khancyr commented Sep 26, 2016

magicrub Sep 26, 2016

peterbarker Oct 5, 2016

WickedShell Jan 17, 2017

magicrub Sep 26, 2016

dgrat commented Sep 27, 2016

OXINARF commented Sep 27, 2016

dgrat commented Sep 27, 2016

OXINARF commented Sep 27, 2016

dgrat commented Sep 27, 2016

magicrub commented Sep 27, 2016

R-Lefebvre commented Sep 28, 2016

OXINARF commented Sep 28, 2016

dgrat commented Sep 28, 2016

rmackay9 commented Oct 5, 2016 •

edited

peterbarker commented Oct 5, 2016

peterbarker commented Oct 5, 2016

peterbarker commented Oct 5, 2016

OXINARF commented Oct 5, 2016

peterbarker commented May 8, 2017

lvale commented May 8, 2017 •

edited

DonLakeFlyer commented May 8, 2017

peterbarker commented May 9, 2017 via email

peterbarker commented Jun 7, 2017

rmackay9 commented Jun 7, 2017 •

edited

OXINARF commented Jun 7, 2017

peterbarker commented Nov 14, 2017

peterbarker commented Jun 15, 2018

peterbarker commented Jun 20, 2018

rmackay9 commented Jun 20, 2018

peterbarker commented Jun 20, 2018

WickedShell commented Jun 20, 2018

Force arm #4891

Force arm #4891

Conversation

peterbarker commented Sep 26, 2016 • edited

peterbarker commented Sep 26, 2016

khancyr commented Sep 26, 2016

magicrub Sep 26, 2016

Choose a reason for hiding this comment

peterbarker Oct 5, 2016

Choose a reason for hiding this comment

WickedShell Jan 17, 2017

Choose a reason for hiding this comment

magicrub Sep 26, 2016

Choose a reason for hiding this comment

dgrat commented Sep 27, 2016

OXINARF commented Sep 27, 2016

dgrat commented Sep 27, 2016

OXINARF commented Sep 27, 2016

dgrat commented Sep 27, 2016

magicrub commented Sep 27, 2016

R-Lefebvre commented Sep 28, 2016

OXINARF commented Sep 28, 2016

dgrat commented Sep 28, 2016

rmackay9 commented Oct 5, 2016 • edited

peterbarker commented Oct 5, 2016

peterbarker commented Oct 5, 2016

peterbarker commented Oct 5, 2016

OXINARF commented Oct 5, 2016

peterbarker commented May 8, 2017

lvale commented May 8, 2017 • edited

DonLakeFlyer commented May 8, 2017

peterbarker commented May 9, 2017 via email

peterbarker commented Jun 7, 2017

rmackay9 commented Jun 7, 2017 • edited

OXINARF commented Jun 7, 2017

peterbarker commented Nov 14, 2017

peterbarker commented Jun 15, 2018

peterbarker commented Jun 20, 2018

rmackay9 commented Jun 20, 2018

peterbarker commented Jun 20, 2018

WickedShell commented Jun 20, 2018

peterbarker commented Sep 26, 2016 •

edited

rmackay9 commented Oct 5, 2016 •

edited

lvale commented May 8, 2017 •

edited

rmackay9 commented Jun 7, 2017 •

edited