EKF checks not allowing arming


I’m having some troubles getting past EKF prearm checks.

I added some debugging statements to NavEKF2_core::calcGpsGoodToAlign()

“false” is always returned, and prearm_fail_string varies between a bunch of different reasons
GPS horiz error 5.1m (needs 5.0)
Mag yaw error x=0.0 y=0.0

I tried upgrading my NEO-7M to a NEO-M8N, it doesn’t seem to help.

Is EKF2 compatible with my GPS cells?

I should note that I’m doing tests indoor. 10 GPS satellites that have been identified. HDOP/VDOP are between 1 and 2. 3D DGPS lock. I tried on my balcony as well.

Also, is there a way to have prearm_fail_string surface on the GCS? I tried both QGC and MP and didn’t see it.

Testing indoors is bound to give you these kind of problems with the GPS. What kind of testing are you doing that you need GPS? If you are in a mode that doesn’t require GPS then this check won’t happen.

EKF2 is compatible with every GPS ArduPilot is compatible with, so yes, EKF2 supports your GPS.

As I’ve said in the issue you had opened, you should be able to see the message in the MP HUD and also in the Messages tab.

The “Messages” tab doesn’t have more than just the handshake from the FC, essentially this:

APM:Copter V3.3.3 (acf2e10c)
PX4: 34e1d543 NuttX: 7c5ef883
Frame: QUAD
PX4v2 0022002D 34355101 37373730

The HUD shows other messages, such as off the top of my head “prearm: inconsistent compasses”, which isn’t the prearm_fail_string as far as I can see in AP_NavEKF2_VehicleStatus.cpp.

I searched all the other tabs and a bunch of other views, no success. That’s sad since this function purposefully fills in that string to help diagnose the issue.

Regarding why I’m doing this, I’m basically putting together a new build and trying to make sure everything works together, including some dronekit code running on a companion computer. DK’s vehicle.is_armable() won’t pass because of (bad) EKF reports: https://github.com/dronekit/dronekit-python/blob/8a5191adc8737c1ed638cd51d88117368caeaced/dronekit/init.py#L1706

In the version you are using, only one pre-arm check message at a time is shown (this is something that is changing in 3.4). That means, that you won’t see the GPS messages before you have fixed the “inconsistent compasses” one.

Regarding what you are trying to do, you only get GPS checks if you are in a mode that needs GPS. If is_armable doesn’t return true even in a mode that doesn’t need GPS then you need to take this to Dronekit (looking at that code it doesn’t look correct to what ArduPilot does).

I agree that is_armable probably isn’t implemented correctly.

However, is there a way for Dronekit to know whether a given mode requires GPS (this seems FC specific), or to know whether the vehicle is armable?

No, I don’t think there is.

Wait I’m confused, if you had to rewrite is_armable(), how would you do it then?

I wouldn’t provide it in the API since there is no correct way to do it.

It’s probably a long shot and would require changes to be made in AP and DK.

But technically speaking, the FC knows which modes are GPS or not. Why not expose this information as a map for instance? Or if there’s already an API to pull the list of modes, then attach a gps_enabled bool to the list?

What we need is a way to request the FC to the arming checks and return what checks are failing - this has been discussed many times and a conclusion hasn’t yet been reached because it isn’t as simple as it sounds.

Beyond that, I’m reading here [1] the following.

The most common sources of difficulty taking off are:
Starting in any mode other than GUIDED.
Attempting to takeoff when the vehicle is not armed. This can happen if you call takeoff too slowly after arm throttle, or if the vehicle fails pre-arm checks.

So given that AC won’t let me get past GPS checks and arm, and that AC won’t takeoff unless in GUIDED, how is one supposed to be able to take-off in those conditions (indoor) ?

Is the information here [2] still up to date? I set AHRS_GPS_USE to 0 but it doesn’t seem to be enough, and I cannot find GPS_FAILSAFE.

[1] http://ardupilot.org/dev/docs/copter-sitl-mavproxy-tutorial.html
[2] http://ardupilot.org/copter/docs/indoor-flying.html

You can takeoff in any mode you want. Auto takeoff only works in Auto and Guided modes since those are the _auto_matic modes. In Copter 3.4 there will be a new Guided-NoGPS mode, but I’m not sure if you can takeoff in that one.

That page about indoor flying isn’t up-to-date, but most still applies. As you can see there’s no talk about auto modes there.

http://ardupilot.org/dev/docs/copter-sitl-mavproxy-tutorial.html says

At time of writing, Copter only supports takeoff in guided mode

Please clarify.

I guess takeoff should be in italic because it means it only supports the takeoff command in Guided mode. Auto also supports it like the end of the statement says.