Adds is_armable property.

[tcr3dr]

Questions:

• Should we throw if armed is set and we are not is_armamble?

See #416.

[hamishwillee]

I think arming requires a 3D Fix (on Copter at least) based on various comments around the place. Should be checked. And yes, I know my tests look at <2 ... I do wonder though if perhaps the 3D fix happens very quickly after 2d fix and I've just got lucky.

[hamishwillee]

Should we throw if armed is set and we are not is_armamble?

I think so. They really do need to make this check because there is no other way to check on ekf warmup. That means that not checking is a programmatic error, which is where you want to throw (to force good programming practice). That said, if we didn't, I think everyone is going to copy our example code, so the same thing will happen by stealth.

Originally you were talking about publishing a reason so people could work out why things were failing. Decided not to do that? I guess we can publish the checks.

[tcr3dr]

I don't want to delve too heavily into "feature development" around this, but to address the reason question, maybe this should be a different function:

(armable, reasons) = vehicle.arm_check()

Reasons can be a dict of checks that were performed, armable can be a simple boolean value.

In reality, we also do nothing to allow you to read the acknowledgement value which is how we should be doing this—vehicle.armed = True should throw if the acknowledgement fails, but we currently don't check for that.

Given that ACKs would be really nice to integrate but is a breaking change and not well thought out, I'm a bit of a loss on what to do here. arm_check() and infrastructure for checking arming? Implement ACKs? Implement a second, explicit mechanism .acknowledge() that throws if the command failed?

[hamishwillee]

@tcr3dr As you say, we could go around this all day.

I guess what I really want is to be able to have a simple instruction that tells the system to arm that I can wait on until arming is confirmed to succeed. It should have (optional) debug output on what we are waiting on and a time timeout or fail retry timout.

So something like the below, where debug rate is the spacing between printing conditions you're waiting on to console (None for don't print), retry is how many times it will try resend the arm command after EKF warmup is complete.

arm(await=True, retry=3, debug_rate=None)

Which returns after arming is detected.

I see the method we have discussed as a primitive for this sort of functionality. Which is why I quite like the ability to get the reasons (though only the ones that are holding us up or we are waiting on).

Does that help? If not, lets keep it simple - deliver this exactly as currently specced, no throw, no checking, no reasons.

[tcr3dr]

Considering how much work this involves, and that we can do it in a backward-compatible way, I'm going to classify this as "enhancement" and go ahead with is_armable as we've specced. I'd love to develop a more coherent response to awaiting data and acknowledgement (particularly in Python) but that could take some time. No time to lose!

[hamishwillee]

@tcr3dr OK. I've added the docs for this, and updated the examples which have a takeoff to use it. Merge at will!