"Compass not healthy" preventing arming even though compasses are disabled (using SLAM instead)

ArduCopter Copter 3.6
1

I am trying to provide a SLAM based position and orientation to the drone while operating inside a metal warehouse where the gps and compass do not work. I have disabled the compasses and the compass arming check, but i still receive the following error message when attempting to arm: CRITICAL:autopilot:PreArm: Compass not healthy. Here are some of the relevant parameters:

drone.vehicle.parameters["EK2_GPS_TYPE"] = 3
drone.vehicle.parameters["AHRS_EKF_TYPE"] = 2
drone.vehicle.parameters["EK2_ENABLE"] = 0
drone.vehicle.parameters["EK3_ENABLE"] = 1
drone.vehicle.parameters["GPS_TYPE"] = 0
drone.vehicle.parameters["AHRS_GPS_USE"] = 0
drone.vehicle.parameters["VISO_TYPE"] = 1
drone.vehicle.parameters["COMPASS_USE"] = 0
drone.vehicle.parameters["COMPASS_USE2"] = 0
drone.vehicle.parameters["COMPASS_USE3"] = 0

Is there something I am missing to make sure the drone realizes it doesnā€™t need the compass since it will be getting that information from the vision system?

I have tried supplying the same information via the MOCAP system as well, but have the exact same issue.

2

set the ekf origin and try to fly in loiter. it will work. the message compass not healthy will not disappear. you are sending vision_position_estimate ? you donā€™t need to set viso_type =1 ā€¦ look at the blog section in the website, you will different slam implementation that will help a lot

3

Try disabling COMPASS_ENABLE param (set to 0) as well. If the param is not available, you might need to use beta or dev firmware instead.

4

I am now using MAV_CMD_DO_SET_HOME to set the ekf origin and attempting to arm in the loiter mode. Even without any changes to the parameters above, the compass error seems to have gone away, but is replaced with:

APM: PreArm: gyros still settling
APM: PreArm: Waiting for Nav Checks

which is preventing the drone from arming. I have tried sending positions using both att_pos_mocap and vision_position_estimate commands.

I have looked at many blog posts as well as the various non gps implementations in the documentation: zed, pozyx, vicon, etc. In many cases, the solution is not relevant to what i am doing because they are communicating across UART instead of MAVLINK/USB as I am trying to do. Iā€™ve attempted to duplicate multiple of the other solutions i found in the blog/documentation, but none of them work which is why I have come here.

Iā€™m on the latest stable firmware, 3.6.9. Do I really need to move to a beta/dev firmware for this use case? It seems like a lot of trouble and danger, Iā€™m trying to build a production system, not a proof of concept. Is there a recent bug fix related to COMPASS_ENABLE that I am missing in the latest stable release?

5

If it is relevant at all, I am attempting to fly the drone with no remote control and no mission planner. Control is coming solely from an onboard computer.

7

Iā€™ve added SET_GPS_GLOBAL_ORIGIN and SET_HOME_POSITION messages which get sent on startup and now the local and global positions are being registered. However, iā€™m still not able to arm.

If I attempt to arm in STABLIZE mode, I get the message High GPS HDOP, which seems especially odd sense i specifically disabled GPS and it is successfully integrating my vision_position_estimate messages.

If I attempt to arm in LOITER mode, I still get the message APM: PreArm: Compass not healthy which is preventing it from arming.

8

After talking to KiloNovemberDelta on gitter, I was able to get past the High GPS HDOP error message by disabling GPS related ARMING_CHECK.

However, iā€™m still running into the Compass not healthy error.

I have tried running through multiple blog posts/tutorials including this one: Integration of ArduPilot and VIO tracking camera (Part 4): non-ROS bridge to MAVLink in Python but iā€™m still having this problem.

After looking through the source code, it looks like i might be hitting this line: https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/AP_Arming.cpp#L462 . It seems to be checking the compass health no matter the value of ARMING_CHECK. There is another place in the code which checks the compass health, but is gated by the value of ARMING_CHECK. Is there an easy way to determine if the ALLOW_ARM_NO_COMPASS compiler flag is defined in the default build of the firmware? Am I my looking down the wrong rabbit hole?

If I watch the local position and attitude, I am seeing the SLAM values coming out fine, and it is clear that it is being fused with the IMU because there is a very small amount of noise being added to an otherwise constant SLAM pose.

9

OK, so I figured out the issue, sort of. If I plug in a GPS/compass combo into the flight controller, I no longer get this error and I am able to arm. This is somewhat annoying as it means I need to connect this extra GPS/compass sensor to the drone even though I donā€™t need the values off the sensors. Maybe there is a configuration parameter I am missing that is causing this issue?

Here are two screen shots of QGroundControl showing sensor status with and without the GPS/compass connected:

02%20PM 05%20PM

Perhaps if I somehow make the internal compass the ā€œPrimaryā€ compass I will be allowed to arm without the external compass?

10

Could this be related to this Issue?


Because I would be interested Iā€™m starting with Ardupilot and thought this issue would be a good startā€¦

11

Iā€™m not very familiar with this codebase, but it does look potentially applicable. One thing I will also comment there is that it shouldnā€™t necessarily prevent guided and similar modes since there are alternatives to the compass like SLAM and motion capture systems that allow guided flight without GPS/compass.

12

@dwiel,

I think youā€™ve found the right place in the code (same link as above). Instead of blindly checking if the compass is healthy, we should check instead if we have an external source of heading (aka SLAM) and if ā€˜yesā€™ skip the check. Are you comfortable commenting out those lines and building AP yourself? If not I could create a binary for you if you tell me which flight controller you are using.

13

If you think it would helpful for me to build a few different versions as we sort this out, I can try to get a build environment set up, otherwise it would probably save me a few hours tonight if you can quickly put together a build. I am using AUAV X2.1.

14

@dwiel May I suggest that you try the following, using only internal compass, no external compass/GPS module connected:

  • Enable compass: COMPASS_USE = 1.
  • Perform compass calibration again.
  • Try to arm with compass enabled and then disabled COMPASS_USE = 0.

This works for me, regardless of whether external vision data is available or not.

1 Like
15

Thank you for the suggestion. I was about to try it, but after getting some changes made to our setup, I seem to have bricked my flight controller :frowning: Thanks for all the help!

16

Shouldnā€™t we be asking the EKF whether it can supply yaw?

1 Like