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. 
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
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.
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
Got COMMAND_ACK: DO_SET_MODE: ACCEPTED
Mode GUIDED
pre-arm fail
Got COMMAND_ACK: COMPONENT_ARM_DISARM: FAILED
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.
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:
https://discuss.ardupilot.org/t/certain-mavlink-1-messages-arriving-with-bad-crc-signatures/80073
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.
#endif
although I have never actually seen that error message when compiling. 
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?