How do I tell over Mavlink whether Arducopter is ready for arming (2021 edition)?

Just wondering how would I tell that my drone is ready for arming using Mavlink? I mean, I can keep trying to arm it but it seems a bit unscientific. :slight_smile:

I have heard about EKF_STATUS_FLAGS in the past but I’d previously read that these were not implemented yet. What flags should I be checking in MAVLINK_MSG_ID_EKF_STATUS_REPORT if any?

Hopefully someone knows the answer and it’s not too complicated. Thanks!

They are implemented. Please update to ArduCopter 4.1.3-rc2

1 Like

Life is good in 2021.

The MAV_SYS_STATUS_PREARM_CHECK will be true if the vehicle’s prearm checks have passed (or the vehicle is armed…): mavlink/common.xml at master · ArduPilot/mavlink · GitHub

Note that the vehicle may still not be able to actually arm; there are some checks we do not make until the user actually tries to arm as they change the state of the vehicle - for example, we only try to start logging (and sometimes tell fancy GPS units to start logging) when the user tries to arm the vehicle.

1 Like

I think EKF origin must be one of those omitted checks as I see the prearm “onboard_control_sensors_health” bit set when in fact EKF origin (home) is not set. My SITL test has this output (you can see where I set guided mode and try to arm in bold):

AP: GPS 1: detected as u-blox at 230400 baud
pre-arm fail
AP: PreArm: GPS: waiting for home
AP: PreArm: GPS: waiting for home
AP: EKF3 IMU1 origin set
AP: EKF3 IMU0 origin set
AP: EKF3 IMU0 is using GPS
AP: EKF3 IMU1 is using GPS
pre-arm good
Flight battery warning

I had some issues with SITL for 4.1.3 so I am just looking at 4.1.2 right now… I cannot get the SITL drone to send me EKF_STATUS_REPORT messages despite successfully requesting other message types with MAV_CMD_SET_MESSAGE_INTERVAL (e.g. ATTITUDE messages come in fine).

I can see that QGroundControl does not have this problem - I can see lots of EKF_STATUS_REPORT messages coming in. I had a google and searched the forums to sanity check things. I looked at the source code and got as far as seeing the message supposedly sent in GCS_MAVLINK::try_send_message() when all things are working.

Is there something else I must do in order to receive these messages? Cheers.

It could be a bug in the set message interval logic.
As far as I know qgc uses sr_* rates instead.

1 Like

Good point, it does use the old method of requesting messages. I’ll do a bit of digging and report back.

It’s a Mavlink 1 vs Mavlink 2 bug. I created a new thread here to discuss this:

which links to here:

Okay, so I was premature to suggest the problem was Mavlink 1 vs Mavlink 2.

The problem is a hideous one. It was impossible to find without massive debugging.

All my pain was caused by one single line. This one in mavlink_helpers.h:

static const uint8_t mavlink_message_crcs[256] = MAVLINK_MESSAGE_CRCS;

MAVLINK_MESSAGE_CRCS is defined differently depending on which header you include first.

Yes, you have to include headers in the right order or the incorrect MAVLINK_MESSAGE_CRCS will be used!!!

Thinking of including common/common.h first? HAHAHAHA!

That has the wrong MAVLINK_MESSAGE_CRCS in. Nope, you need to make sure ardupilotmega/ardupilotmega.h is included before common/common.h

God knows why MAVLINK_MESSAGE_CRCS is wrong in common/common.h. Off to post on the Mavlink Github…

There is no need to include both.

You are only supposed to include ardupilotmega/ardupilotmega.h not comon/comon.h.

You mean ardupilotmega/mavlink.h?

There is this at the top of ardupilotmega/ardupilotmega.h:

#ifndef MAVLINK_H
    #error Wrong include order: MAVLINK_ARDUPILOTMEGA.H MUST NOT BE DIRECTLY USED. Include mavlink.h from the same directory instead or set ALL AND EVERY defines from MAVLINK.H manually accordingly, including the #define MAVLINK_H call.

although I have never actually seen that error message when compiling. :rofl:

I corrected my post above.

So is this message still the best bet to see if the vehicle is ready to be armed or is there another way to check?