AC3.6, Usability Issue: 3D Fix not sufficient to use "GPS assisted" flight modes

General
1

Hey folks,

since I started using AC3.6-dev I observe that getting a 3DFix in MissionPlanner is no guarantee for being able to switch into a GPS-assisted mode, such as PosHold.

The usability issue comes from the “fact” that the signal “3DFix” has become kind of tautologous to that the GPS-assisted modes are available (I think it’s fair to assume this is because in the “old” days GPS 3DFix was indeed mostly equal to GPS-assisted mode available). The current situation is - IMHO - confusing, as it breaks with what the (average) user may have become accustomed to in many years.

I didn’t observe this behavior in AC3.4, I can’t speak for AC3.5 since I never used it.

Background:
My observation is this: I usually wait for the 3DFix to be shown, then take-off in Stabilize mode, and then switch to PosHold. With AC3.4 I can’t recall having had any “issues”. With AC3.6 I find that more often than not I have to wait, while airborne, a substantial time before I can switch to PosHold. Before that, this switch would be rejected. This also can be seen in logs.

I conclude, obviously, a 3DFix in MissionPlanner is NOT SUFFICIENT anymore (also in the mathematical sense).

I note that I have the gps prearm check disabled (important below), and I think (not tested, but follows from the below) that this would avoid this in as much as I wouldn’t be able to arm unless the GPS-assisted modes are available.

However, this is totally not the point I’d like to discuss. My point is that - IMHO - users over time have become accustomed to associate “3DFix” with “GPS-assisted modes available”.

Code Analysis:
I thus have investigate the code to see what the situation is. I won’t claim that the following is correct in any point. But this is not too important, since this section is not the main point, but just an addendum to dig deeper.

I find that e.g. poshold and loiter require a function position_ok() to be true to allow being switched into it. The gps prearm check also tests for position_ok() to be true. However, I think, MissionPlanner is displaying its “3DFix” based on the data send via AP_GPS::send_mavlink_gps_raw(), which reports the gps status, as defined by the GPS_Status enum in GPS.h.

I conclude, the above finding is related to how position_ok() and AP::gps().status() work.

Now, I understand, I think, that position_ok() is in general not neccessarily related to a gps 3DFix, when e.g. indoors navigation is available. I also understand, I think, that a raw gps 3DFix is in general not sufficient for position_ok() to be true.

However, what I think a user expects is that once the label “3DFix” appears, whatever it exactly means on a technical level, that “GPS-assisted” modes are available. Otherwise said, I would rather like to get a signal from which I can deduce a relevant information.

I note, I assume again as a reflection of how it was in the “old” days, that “GPSfix” and position_ok() are quite inconsistently used throughout the code. For instance, in gps_checks() it calls copter.flightmode->requires_GPS() in order to infer if position_ok() needs also to be checked. The presumed tautology is also frequently found in the docs, see e.g. http://ardupilot.org/copter/docs/flight-modes.html#gps-dependency.

Possible “Solutions”:
I didn’t wanted to call it a solution, hence the marks, since nothing is broken. I’m talking just about usability. Suggestions which come to my mind:

i) If the current behavior is intentional, I think that there should be at least clear statements somewhere telling about what 3DFix really means, and what it does not mean (i.e. the docs need a serious clean up). Personally I would regret if there wouldn’t be a signal from which one could infere if position_ok() is ok or not.

ii) One could stay with the label “3DFix” in MissionPlanner, but use it in the sense that the GPS-assisted modes are available. This would either mean that the status data which is send in the GSP_RAW MAvlink message is “faked” such as to yield what we want, or that additional info is send to the MissionPlanner which it digest in addition in order to determine when to display “3DFix”.

iii) One could introduce a new signal such as “PosFix” or “InavFix” or whatever, to inform the user when “GPS”-assisted modes are available.

This was a long text to bring across a short message, but I wanted to share the whole picture as I currently have it.

Cheers, Olli

2

This has annoyed me for quite some time too. That indictor is just telling you the GPS itself is reporting it has a 3D fix. But that has no actual impact on the EKF accepting the position and using it for flight (what is generally referred to as fusion). If the EKF is unhappy with the position, usually do to velocity drift, it will still not accept it and not be usable for flight modes that require GPS.

There is no current GPS fusion status indicator, and that is really what is important. The 3D fix indicator is misleading and nothing is actually done based on it. I think this has been on a to-do list for a while now actually.

For this very reason, I actually made a flag in the AP_NOTIFY library called GPS_FUSION which indicates as actually desired. Today it is only used to control the rear LED color on the solo in ArduCopter 3.5+. Yellow for GPS not usable, white for GPS usable. This flag can of course be used for anything else too.

3

yeah
today I did flights where I had switched poshold from the beginning, and the infos in the HUD are really “funny” …
it very soon, within 10secs or so, gives me a nice clear 3DFix, yet there are plenty of big red “PreArm: Need 3D Fix” warnings for a while … LOL
it hardly couldn’t be more contradicting information
good to hear that it’s not only me who finds that worth a discussion

4

This is one reason I have been a big fan of the OLED status display because it shows the actual HDOP and Satellite count. I have been ranting for a while that most folks do not understand that just getting a 3D fix indication is not enough to fly in GPS dependent modes.

5

the HDOP and satellites are unfortunately useless in this matter … in my case they are also quite good very quickly … yet you have to wait quite a bit until position_ok() gives ok

6

Yep. The publicly visible and generally user-understood data is sat count, HDOP, and “3D Fix”. Ironically, none of those things (individually or in combination) actually indicate the GPS reported position is usable by the EKF. You could have 20 sats, an HDOP of 0.7, and “3D Fix” reported by the GPS. But if the position/velocity is still settling or drifting, the EKF will still not use it. And it will continue to report that it needs a 3D Fix.

The EKF Filter State is the only actual indicator that the GPS position is usable for flight, and that is not reported in any status or GCS. This is where I snagged it for use in the notify library to control the Solo’s LEDs. And this is also where a future status report to the GCS would probably come from.
(EKF2) https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_AHRS/AP_AHRS_NavEKF.cpp#L205
(EKF3) https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_AHRS/AP_AHRS_NavEKF.cpp#L278

7

I think the position_ok() function would be a better, more general choice
(as it is exactly the function which controls the pre-arm, arm, and flight mode changes)

8

position_ok() is actually part of the vehicle code for each different vehicle type. It works a little different in each vehicle type. For example, in ArduSub, it just returns the EKF Failsafe true or false, which would not be the right way to indicate specifically if the GPS position is usable. But looking through what it does in copter, it actually does eventually drill down to returning the filter state from the same spot I pulled the notify flag from.

I think ultimately a status report on usable position should probably come from the AHRS library, reporting true or false on the filter state, using existing logging functions already there. That way it is universal regardless of vehicle type, and can be consumed and displayed by any GCS for any vehicle type. Take the vehicle types out of the loop. And that prevents future vehicle specific changes from affecting the flag.

9

honestly, doen’t make sense to me
I don’t need an additional techi number which doesn’t correlate with the available (flight)modes, would be as useful or useless as teh GPS thing, for the same reasons. It’s normal tat different vehicles have different rules for their different modes.
my 2 cents

10

Different people maintain different vehicle types, with functionality added at different times. And different vehicles may need different criteria. A submarine may have good reason to do it differently for the purpose of arming and modes.

Something on the GCS HUD or OLED display for example need stop be consistent since everyone sees it.

11

today I did flights where I had switched poshold from the beginning, and the
infos in the HUD are really “funny” …
it very soon, within 10secs or so, gives me a nice clear 3DFix, yet there
are plenty of big red “PreArm: Need 3D Fix” warnings for a while … LOL
it hardly couldn’t be more contradicting information
good to hear that it’s not only me who finds that worth a discussion

Yep, @olliw’s initial summary here was pretty much spot on.

Note the current master code doesn’t have “Need 3D Fix” in it; it’s been
replaced with a failure reason coming from the EKF.

Also note my ok-to-enter PR makes any mode change failure return a string
to the GCS as to why the mode change failure occured.

12

The EKF Filter State is the only actual indicator that the GPS position is
usable for flight, and that is not reported in any status or GCS. This is
where I snagged it for use in the notify library to control the Solo’s LEDs.
And this is also where a future status report to the GCS would probably come
from.
(EKF2)https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_AHRS/AP_AHR
S_NavEKF.cpp#L205
(EKF3)https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_AHRS/AP_AHR
S_NavEKF.cpp#L278

the EKF status flags are currently available to the GCS (assuming your
streams are set up that way. MAVProxy has an “EKF” indicator in its
console. Of course, health doesn’t actually indicate you can arm :wink:

13

??
I’m on master of three days ago, and it does show “PreArm: Need 3D Fix”, bot in MP and in the code
is this something which changed very recently?

14

Note the current master code doesn’t have “Need 3D Fix” in it; it’s been
replaced with a failure reason coming from the EKF.

@peterbarker It’s a copter special. Master still emits that:

15

I’m on master of three days ago, and it does show “PreArm: Need 3D Fix”, bot
in MP and in the code
is this something which changed very recently?

Apologies, there certainly is a code path which emits this. There
shouldn’t be - it indicates the AHRS isn’t telling us why it’s unhappy.

16

I tried to interest the Dev’s in fixing this to no avail quite some time ago.
It crept in with the EKF and now necessitates that you switch to an assisted flight mode before takeoff to check the EKF is happy with the 3DFix.
In situations where you might not have a GCS, or Telemetry, you are relying on the RGB LED to indicate a “ready for Flight in Guided” situation and this is not happening.
The RGB goes green on 3DFix, but if you switch to a guided mode it will revert to blue.
I personally don’t see the sense in indicating green if, in fact, it is not sufficient for guided flight.
Whats the point?
This is giving false and misleading signals.
If it is too hard to do in code then the RGB should be dropped, but I think that is a bad idea.

All auto missions I fly with copter I use Stab to takeoff, then switch to loiter and check for any toilet bowling or wandering, just as a final check that nothing has gone wrong or changed, then switch to auto for the mission.
It used to be sufficient that while standing on site and waiting for the GPS to just watch the LED, or have someone read off the GCS, that the 3DFix is achieved.
That is no longer the case.
Without switching to a guided mode on the ground and noting that the LED goes blue, or the GCS does not show a mode change, there is no way to tell.

Ohh… and if you take off in Stab and switch to a guided mode that doesn’t work, say loiter, and the copter drifts off, and you land, the LED will be green, and stay green in any flight mode, until you disarm.

It would be great if we could get a consensus on what should happen to indicate the EKF is ready for guided modes and then hopefully a Dev might take it on board to fix.

1 Like
17

nice brief summary :slight_smile:

18

Yes, I totally agree. The LED shouldn’t go green until the EKF has a good position estimate.

I’ve already created an issue for Rover here but it applies equally well to Copter and Plane.

We should try and do this for Copter-3.6 and the next Rover release.

2 Likes
19

Well I think the design right now is that green also means ready to arm. Which is accurate for what it is doing in a flight mode that doesn’t require GPS. What if you do not have or care about GPS? Ready to arm still needs to be indicated somehow.

The whole led color thing certainly leaves a lot to be desired as this whole topic illustrates. This is exactly why I made my own for the solo to actually say what we needed to say.

20

Actually Blue is ready to arm.
Once the pre-arm checks run and all pass you get the blue LED, then you can arm in non assisted modes.
Once the GPS has a 3D Fix the LED goes green.