Rover: Bad AHRS displayed on MP HUD when vehicle doesn't have GPS lock

[rmackay9]

In Rover-3.2 (and lower) users nearly always see the "Bad AHRS" and "Bad GPS Health" messages during startup. It's disconcerting to users and makes them think that something is wrong with the system, when in fact, it's booting up normally but is still in the initialisation phase.

Re the "Bad AHRS" message, I don't think the AHRS is actually "Bad", it simply doesn't have GPS lock yet.

I think we should make a few changes:

• don't send the system-status messages or at least don't send ahrs and gps error bits for 30 seconds or so to allow these subsystems to initialise.
• adjust the system-status messages so that an ahrs can appear healthy even without a GPS
• adjust the gps health reporting so that it simply needs to be sending messages to ardupilot to be "healthy".

[rmackay9]

This PR resolves the "Bad GPS Health" message but not the "Bad AHRS" message. https://github.com/ArduPilot/ardupilot/pull/7421

[peterbarker]

On Thu, 14 Dec 2017, Randy Mackay wrote:

I think we should make a few changes:

Another option might to stay in an "initialising" mode. That's previously been suggested on a dev call.

[rmackay9]

I think the issue with the AHRS health is actually within DCM. I think DCM itself returns "unhealthy" when it doesn't have a GPS. Rover currently uses DCM until the EKF is fully initialised I think. I haven't checked this theory in depth yet though, it's just a hunch.

[rmackay9]

The "Bad GPS Health" issue has been fixed by this commit. https://github.com/ArduPilot/ardupilot/commit/a8da459bafd943c2cdeedfca18ad8ad084350d36

@peterbarker, by the way, I noticed we have an "initialising" mode in Rover it seems. https://github.com/ArduPilot/ardupilot/blob/master/APMrover2/defines.h#L47. I guess it tells the user that some stage of the initialisation is done.

[amilcarlucas]

Hasn't this been fixed recently?

[rmackay9]

@amilcarlucas, no I'm afraid not.

[peterbarker]

@rmackay9 we no longer emit "Bad AHRS" (I think that's now "Need 3D Fix"?), and "Bad GPS Health" was also changed years ago?

What's the new, modern bad behaviour that needs to be sorted?

[rmackay9]

ok, so "Bad AHRS" has become, "Unhealthy AHRS". I suspect this message is displayed by MP based on some bit in the extended system status.

This can be reproduced by doing this:

• start MP
• open the Simulation page, check the "wipe" checkbox, then push the Rover icon
• on the Config >> Parameters page set GPS_TYPE = 0
• stop and restart MP
• on the Simulation page, click the rover icon

[nicolasgallardo]

@peterbarker is there any update on this? I am trying to run @rmackay9 's wheel encoder example found here https://ardupilot.org/rover/docs/wheel-encoder.html on ardurover 4.1.0 but as mentioned above Unhealthy AHRS prevents the switch to AUTO.

[rmackay9]

@nicolasgallardo,

It sounds like the issue you're facing is with getting wheel encoders working so it's probably best to raise this in the Rover support forums. This issue (7417) is really about the disconcerting "Unhealthy AHRS" message itself, not the underlying problem of the AHRS perhaps not having a position estimate in some situations.

By the way, the wheel encoder instructions on the wiki are for 4.0. For 4.1 the EK3_SRC_VELXY parameter should be set to "Wheel Encoder" and some of the other EK3SRC*** parameters will need to be set as well.

[peterbarker]

@rmackay9 that sounds like it might now be a MissionPlanner issue, esp. in light of this patch in master from @IamPete1 :

commit c1a831bbf49fda1013ad046b60baa2e0c185c75d
Author: Peter Hall <iampete@hotmail.co.uk>
Date:   Sat Feb 13 00:26:15 2021 +0000

    GCS_MAVLink: sensor flags, only mark AHRS as enabled once initialised

Should we close this issue now?

[peterbarker]

It is unknown as to whether this is still an issue, and whether it is a problem with ArduPilot or with MissionPlanner.

[IamPete1]

We still get "Unhealthy AHRS" for the period of time between the EKF setting origin and starting using the GPS.

[rmackay9]

After a bit more debugging (see branch here) the issue appears to be:

• When GPS_TYPE = 0, the AHRS is switching back to use DCM
• The switch occurs in AHRS::active_EKF_type() which is forcing the use of DCM when the EKF doesn't have a position and velocity estimate (see code here)
• DCM always returns unhealthy if it doesn't have a position estimate (I think). There are mixed opinions on the dev team about whether this is correct or not (I think it is not correct, I think the AHRS should be healthy as long as it has an attitude estimate)

One potential solution is to change AP_AHRS to always use the EKF for Rovers. This can be done by adding, " || APM_BUILD_TYPE(APM_BUILD_Rover)" to this line.

#if APM_BUILD_COPTER_OR_HELI || APM_BUILD_TYPE(APM_BUILD_ArduSub) || APM_BUILD_TYPE(APM_BUILD_Rover)
    // Copter and Sub force the use of EKF
    _ekf_flags |= AP_AHRS::FLAG_ALWAYS_USE_EKF;
#endif

.. and disabling the fallback-to-dcm logic here by removing, "_vehicle_class == VehicleClass::GROUND)) {"