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
etc.
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 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.
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).
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.
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.
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.
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.