MAVSDK: Arming fails without GPS but external vision position estimates

You’re right, that safety is important. But the user also has some responsibility. So there is always the question, how much safety checks the SDK should do and what is left to the user/developer, that is using the SDK. I don’t know, if there’s already a consensus about this in the MAVSDK project.

One solution might be to provide two methods, one just arming the drone and one with additional safety checks (or the current implementation plus a version without the additional step). But this might also lead to users, that blindly rely on the MAVSDK to do safety checks.

In any case, the documentation should be updated to clearly state, what the method actually does (after this discussion has come to a conclusion).

Why you guys talking a lot, just use a parameter arm(force=True) and it’ll solve all sorts of problems.

How do you do that? 😄 That’s potentially unsafe but that’s up to you.

I would hope that with the changes in #886 it will work better for you.

Why you guys talking a lot, just use a parameter arm(force=True) and it’ll solve all sorts of problems.

Now, without that parameter, I can’t even arm the drone (let motor run) in Offboard Mode.

To be clear, I connected a drone with a raspberry_pi, then use the raspberry_pi as a companion computer.

If I run the example https://github.com/mavlink/MAVSDK-Python/blob/master/examples/offboard_position_ned.py, codes running (but arm function will case mavsdk.generated.action.ActionError: COMMAND_DENIED: 'Command denied'; origin: arm(); params: () error). The real drone motor won’t start.

Only if I use a radio remote controller to arm it first, then start offboard_position_ned.py program, it runs.

We could work around the one case where we’re in MISSION mode by checking if we’re in MISSION mode and if so we switch to HOLD. For anything else, we just arm.

One such a dangerous case would be if the vehicle is in a manual mode like stabilized with a spring loaded throttle stick at 50 %. If you arm the vehicle like that it will shoot up in the sky, of course depending on how much throttle it needs to takeoff.

Isn’t arming prevented, when the throttle stick of not all the way down? At least that was the cat, as I tried to steer my rover FMU with QGC’s on-screen controls and also using the quadcopter with a remote control. So normally this shouldn’t be an issue.

May I ask, why the arm() command changes the flight mode first? I don’t know, why this might be useful, but I’m also not that experienced with PX4.

As far as I have thought of it, I don’t expect the arm() action to change the flight mode. I have understood the (C++) API Reference, that I need to arm first and then takeoff. So it’s the same, as it is done with QGC. And the takeoff will lead to a position hold anyway.

Otherwise, the API must differentiate between different airframe types. I have to lookup, if the MAVSDK can know this. But that solution would be a pain to maintain and is not a “nice” design.

This also affects rovers, or all vehicles, that might not need a (global) position at all to drive/ fly. So please also keep this use case in mind.

The FMU on my rover arms just fine using commander arm or QGC, but not using the Python MAVSDK and the offboard_attitude.py example:

-- Arming
Traceback (most recent call last):
  File "./main.py", line 77, in <module>
    loop.run_until_complete(run())
  File "/usr/local/Cellar/python/3.7.4_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncio/base_events.py", line 579, in run_until_complete
    return future.result()
  File "./main.py", line 40, in run
    await drone.action.arm()
  File "/Users/jannik/Development/MAVSDK-Python/mavsdk/generated/action.py", line 230, in arm
    raise ActionError(result, "arm()")
mavsdk.generated.action.ActionError: COMMAND_DENIED: 'Command denied'; origin: arm(); params: ()