-
Notifications
You must be signed in to change notification settings - Fork 16.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rover: Bad AHRS displayed on MP HUD when vehicle doesn't have GPS lock #7417
Comments
This PR resolves the "Bad GPS Health" message but not the "Bad AHRS" message. #7421 |
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.
|
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. |
The "Bad GPS Health" issue has been fixed by this commit. a8da459 @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. |
Hasn't this been fixed recently? |
@amilcarlucas, no I'm afraid not. |
@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? |
@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. |
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 EK3_SRC_*** parameters will need to be set as well. |
@rmackay9 that sounds like it might now be a MissionPlanner issue, esp. in light of this patch in master from @IamPete1 :
Should we close this issue now? |
It is unknown as to whether this is still an issue, and whether it is a problem with ArduPilot or with MissionPlanner. |
We still get "Unhealthy AHRS" for the period of time between the EKF setting origin and starting using the GPS. |
After a bit more debugging (see branch here) the issue appears to be:
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.
.. and disabling the fallback-to-dcm logic here by removing, "_vehicle_class == VehicleClass::GROUND)) {" |
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:
The text was updated successfully, but these errors were encountered: