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.
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
COMPASS_ENABLE param (set to
0) as well. If the param is not available, you might need to use beta or dev firmware instead.
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
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?
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.
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
If I attempt to arm in
LOITER mode, I still get the message
APM: PreArm: Compass not healthy which is preventing it from arming.
After talking to KiloNovemberDelta on gitter, I was able to get past the
High GPS HDOP error message by disabling GPS related
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.
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:
Perhaps if I somehow make the internal compass the “Primary” compass I will be allowed to arm without the external compass?
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…
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.
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.
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.
@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.
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 Thanks for all the help!
Shouldn’t we be asking the EKF whether it can supply yaw?