Pre-Arm Safety Checks

ArduPilot includes a suite of Pre-arm Safety Checks which will prevent the vehicle from arming its propulsion system if any of a fairly large number of issues are discovered before movement including missed calibration, configuration or bad sensor data. These checks help prevent crashes or fly-aways but some can also be disabled if necessary.


Never disable the arming checks (ie ARMING_CHECK not = “1”, except for bench testing. Always resolve any prearm or arming failures BEFORE attempting to fly. Doing otherwise may result in the loss of the vehicle.

Recognising which Pre-Arm Check has failed using the GCS

The pilot will notice a pre-arm check failure because he/she will be unable to arm the vehicle and the notification LED, if available, will be flashing yellow. To determine exactly which check has failed:

  1. Connect the Autopilot to the ground station using a USB cable or Telemetry.

  2. Ensure the GCS is connected to the vehicle (i.e. on Mission Planner and push the “Connect” button on the upper right).

  3. Turn on your radio transmitter and attempt to arm the vehicle (regular procedure is using throttle down, yaw right or via an RCx_OPTION switch)

  4. The first cause of the Pre-Arm Check failure will be displayed in red on the HUD window

Pre-arm checks that are failing will also be sent as messages to the GCS while disarmed, about every 30 seconds. If you wish to disable this and have them sent only when an attempt arm fails, then set the ARMING_OPTIONS bit 1 (value 1).

Most are obvious as to the issue, but some can have multiple sources and the message cant identify them all in its limited length. The most common of those are:

AHRS: waiting for home : autopilot has not gotten a home location, usually because the GPS is detached or has not gotten a fix yet with enough precision. Common experience while indoors.

EKF3 Roll/Pitch inconsistent by X degs : The autopilot is not using EKF3 because its roll or pitch disagrees with the current ARHS system being used (usually DCM). Normally due to EKF3 not getting good enough GPS accuracy (are you indoors??), but could be due to other sensors producing errors. Wait or go outdoors.

EKF3 Yaw inconsistent by x degs: The autopilot is not using EKF3 because its yaw disagrees with the current ARHS system being used (usually DCM). Normally a compass issue caused by metal objects nearby.

AHRS: not using configured AHRS type: Normally, if EKF3 is being used, it has not started or has fallen back to DCM because its not healthy yet. Can also be caused by misconfiguring which EKF is enabled versus being used by AHRS_EKF_TYPE.

EKF3 waiting for GPS config data: A DroneCAN GPS has been configured but is disconnected or not setup.

Other Failure messages


Any failsafe (RC, Battery, GCS,etc.) will display a message and prevent arming.

RC failures:

Waiting for RC or RC not found : No RC has been detected. If operating with only a GCS, see Operation Using Only a Ground Control Station (GCS).

RC not calibrated : the radio calibration has not been performed. RC3_MIN and RC3_MAX must have been changed from their default values (1100 and 1900), and for channels 1 to 4, MIN value must be 1300 or less, and MAX value 1700 or more.

Barometer failures:

Baro not healthy : the barometer sensor is reporting that it is unhealthy which is normally a sign of a hardware failure.

Alt disparity : the barometer altitude disagrees with the inertial navigation (i.e. Baro + Accelerometer) altitude estimate by more than 1 meters. This message is normally short-lived and can occur when the autopilot is first plugged in or if it receives a hard jolt (i.e. dropped suddenly). If it does not clear the accelerometers may need to be calibrated or there may be a barometer hardware issue.

Compass failures:

Compass not healthy : the compass sensor is reporting that it is unhealthy which is a sign of a hardware failure.

Compass not calibrated : the compass(es) has not been calibrated. the COMPASS_OFS_X, _Y, _Z parameters are zero or the number or type of compasses connected has been changed since the last compass calibration was performed.

Compass offsets too high : the primary compass’s offsets length (i.e. sqrt(x^2+y^2+z^2)) are larger than 500. This can be caused by metal objects being placed too close to the compass. If only an internal compass is being used (not recommended), it may simply be the metal in the board that is causing the large offsets and this may not actually be a problem in which case you may wish to disable the compass check.

Check mag field : the sensed magnetic field in the area is 35% higher or lower than the expected value. The expected length is 530 so it’s > 874 or < 185. Magnetic field strength varies around the world but these wide limits mean it’s more likely the compass calibration has not calculated good offsets and should be repeated.

Compasses inconsistent : the internal and external compasses are pointing in different directions (off by >45 degrees). This is normally caused by the external compasses orientation (i.e. COMPASS_ORIENT parameter) being set incorrectly.

INS checks (i.e. Acclerometer and Gyro checks):

INS not calibrated: some or all of the accelerometer’s offsets are zero. The accelerometers need to be calibrated.

Accels not healthy: one of the accelerometers is reporting it is not healthy which could be a hardware issue. This can also occur immediately after a firmware update before the board has been restarted.

Accels inconsistent: the accelerometers are reporting accelerations which are different by at least 1m/s/s. The accelerometers need to be re-calibrated or there is a hardware issue.

Gyros not healthy: one of the gyroscopes is reporting it is unhealthy which is likely a hardware issue. This can also occur immediately after a firmware update before the board has been restarted.

Gyro cal failed: the gyro calibration failed to capture offsets. This is most often caused by the vehicle being moved during the gyro calibration (when red and blue lights are flashing) in which case unplugging the battery and plugging it in again while being careful not to jostle the vehicle will likely resolve the issue. Sensors hardware failures (i.e. spikes) can also cause this failure.

Gyros inconsistent: two gyroscopes are reporting vehicle rotation rates that differ by more than 20deg/sec. This is likely a hardware failure or caused by a bad gyro calibration.

Board Voltage checks:

Check Board Voltage: the board’s internal voltage is below 4.3 Volts or above 5.8 Volts.

If powered through a USB cable (i.e. while on the bench) this can be caused by the desktop computer being unable to provide sufficient current to the autopilot - try replacing the USB cable.

If powered from a battery this is a serious problem and the power system (i.e. Power Module, battery, etc) should be carefully checked before flying.

Parameter checks:

Ch7&Ch8 Opt cannot be same: Auxiliary Function Switches are set to the same option which is not permitted because it could lead to confusion.

Check FS_THR_VALUE: the radio failsafe pwm value has been set too close to the throttle channels (i.e. ch3) minimum.

Check ANGLE_MAX: the ANGLE_MAX parameter which controls the vehicle’s maximum lean angle has been set below 10 degrees (i.e. 1000) or above 80 degrees (i.e. 8000).

ACRO_BAL_ROLL/PITCH: the ACRO_BAL_ROLL parameter is higher than the Stabilize Roll P and/or ACRO_BAL_PITCH parameter is higher than the Stabilize Pitch P value. This could lead to the pilot being unable to control the lean angle in ACRO mode because the Acro Trainer stabilization would overpower the pilot’s input.

Battery/Power Monitor:

If a power monitor voltage is below its failsafe low or critical voltages or failsafe remaining capacity low or critical set points, this check will fail and indicate which set point it is below. It will also fail if these set points are inverted, ie critical point is higher than low point. See Battery Failsafe for Copter, Plane Failsafe Function for Plane, or Failsafes for Rover for more information on these.

In addition, minimum arming voltage and remaining capacity parameters for each battery/power monitor can be set, for example BATT_ARM_VOLT and BATT_ARM_MAH for the first battery, to provide a check that the battery is not only above failsafe levels, but also has enough capacity for operation.


If an airspeed sensor is configured, and it is not providing a reading or failed to calibrate, this check will fail.

Airspeed not healthy


Logging failed: Logging pre-armed was enabled but failed to write to the log.

No SD Card: Logging is enabled, but no SD card is detected.

Safety Switch:

Hardware safety switch: Hardware safety switch has not been pushed.


Param storage failed: A check of reading the parameter storage area failed.

Internal errors (0xx): An internal error has occurred. Report to ArduPilot development team here

KDECAN Failed: KDECAN system failure.

DroneCAN Failed: DroneCAN system failure.



No mission library present: Mission checking is enabled, but no mission is loaded.

No rally library present: Rally point checking is enabled, but no rally points loaded.

Missing mission item: xxxx: A required mission items is missing.


IF a rangefinder has been configured, a reporting error has occurred.

Disabling the Pre-arm Safety Check


Disabling pre-arm safety checks is not recommended. The cause of the pre-arm failure should be corrected before operation of the vehicle if at all possible. If you are confident that the pre-arm check failure is not a real problem, it is possible to disable a failing check.

Arming checks can be individually disabled by setting the ARMING_CHECK parameter to something other than 1. Setting to 0 completely removes all pre-arm checks. For example, setting to 4 only checks that the GPS has lock.

This can also be configured using Mission Planner:

  • Connecting your Autopilot to the Mission Planner

  • Go to Mission Planner’s Config/Tuning >> Standard Params screen

  • set the Arming Check drop-down to “Disabled” or one of the “Skip” options which more effectively skips the item causing the failure.

  • Push the “Write Params” button