Bad AHRS all the time

They are not at AP default.

Seems a lot of my EK3 parameters were not default. Hopefully this resolves my issue! Thanks all!
EK3 Alba4G Screenshot 2023-01-03 213453

In some cases, perhaps they should not be default (in the case of GSF only ops).

1 Like

We have a wiki page here on compass-less operation including using the GSF but I’m not sure that it is actually possible to use only a GPS for heading unless the GPS-for-yaw setup is enabled which involves two GPSs.

GSF is not really meant to be used as a full time source of yaw, it’s really for emergencies.

In short, I think you’ll need to enable the compass.

The “Bad AHRS” comes from the EKF not having a good attitude and position estimate so it needs both heading (e.g. compass) and location (e.g. GPS, wheel encoders, etc). We can make the “Bad AHRS” display go away but of course the vehicle will still not know its position so autonomous driving won’t work.

If it’s a “feature” it should be possible to at least disable the message if not relevant or required.

I did look at the GPS/Non GPS Transitions and wait for the automatic switching version - all three position switches are in use for other devices/actions so not practical.

I note nobody commented on why so many or actually how many GPS sats were required before messages stop? In real world terms 4 is the minimum for a 3D fix, three for XYZ positions in space and one for clock. Often the conditions we work in don’t have a clear view of the sky and 4 or 5 is the best you are ever likely to get but messages continue?

NO, that is NOT correct at all. The location of those 4 satellites is very important as well.
What if all satellites are very close to each other?
How would the GPS receiver perform 3D triangulation then?

It is just not as simple as you want it to be. Get proper signals, from properly located satellites and it will work fine. And that is the job of the GNSS receiver, not the autopilot. So there is nothing the Arudupilot FW can do, other then pass the GPS receiver’s complains to the user.

@rmackay9 if this was replying to me, I just want to clarify that I am using Plane. I was commenting here because of my similar issue. If your statement still applies to Plane, then what should the EK3_SRC1_YAW be for compass-less planes? I’ve never had any issues. And this plane (and several others) have been flying fine in guided, auto, cruise without a compass for several years now.

Many more than 4 or 5. The position estimate from that few will be very poor. These messages need to be shown (depending on how IMU’s the FC has):
1/4/2023 7:48:21 AM : EKF3 IMU1 is using GPS
1/4/2023 7:48:21 AM : EKF3 IMU0 is using GPS
1/4/2023 7:48:21 AM : EKF3 IMU1 origin set
1/4/2023 7:48:21 AM : EKF3 IMU0 origin set

Further dialog should be moved to Plane.

:rofl: From GPS.com - The satellites in the GPS constellation are arranged into six equally-spaced orbital planes surrounding the Earth. Each plane contains four “slots” occupied by baseline satellites. This 24-slot arrangement ensures users can view at least four satellites from virtually any point on the planet.
Nowhere on any official site does it say more than 4 sats are “needed” for a 3D fix nor does any use the excuse of closeness to each other…

You are conflating minimum requirements to achieve any fix with the amount of accuracy expected by a navigation controller (which is more complex than satellite count - the source code is open…feel free to read it).

I understand your frustration, but it seems misplaced. I even gave you an alternative, and you said you’d continue waiting for even more automation rather than exploring an existing solution.

At this point, the problem is yours, not ArduPilot’s.

Hi @Ed_209,

Yes, for the compass-less operation comments I made above I was referring to Rover. You’re right that planes can work fine without a compass because it has a built in assumption that it always moves forward. We sadly can’t make that assumption in Rover’s because they can stop or move backwards.

Thanks for the clarification.

Yes, that is funny when trying to apply that to the positional accuracy required for what we are talking about here.

1 Like

@pilotltd please use your common sense. And answer the question:

How to do accurate 3D triangulation, when all 4 satellites are far away from you, but close to each other?

How close is too close to each other? They never get close enough to make it impossible - that’s the whole idea :sunglasses: The orbits are 60 degrees away from each other tilted at 55 degrees, they are 20km up. Each of the satellites, positioned in 6 orbital planes, circles the earth twice a day. As I looked prior to replying four nearest are - GPS15 is mid Atlantic, GPS13 is over Germany, GPS 5 is over Congo, West Africa and GPS24 over the Caribbean. I’m in the UK, Is that too close?

In theory with the spatial positioning, and no obstructions, you can always see 8 from any point on earth.

However it does become confused if you take data from different providers like Glonass, Beidou, Galileo or NMEA at the same time, they can appear “close” but are at different heights and orbits. The limitation seems to be the math used to decipher the incoming information and the processing power available. Inav for instance defaults to six sats, but will accept five as a minimum, it appears to ignore any more than ten so as not to swamp the calculation with unnecessary data? - It seems to work accurately with five or six.

Still no straight answer on how many sats Ardupilot deems necessary to remove “bad ahrs” messages though… :face_with_raised_eyebrow:

Again, not as simple as you want it to be. GPS health is determined by a number of factors, some of which are model/driver specific. I don’t think there is a specific satellite count required at all. Practically speaking, to achieve required precision, it will be more than 4.

You are also arguing apples and oranges a bit. What you really need to do is properly account for GPS and non-GPS operation rather than continue to rant about GPS precision.

1 Like

It’s not based on the number of satellites. It’s the HDOP (horizontal dilution of precision). Much of the wiki will state that the HDOP needs to be below 2, but I think that is old and the default value is 1.4 or 1.2. (lower is better).

Surveyors will sometimes check what the expected satellite coverage for their given location will be in advance as some equipment or job requirements will mean they need very ideal satellites in view. You can use this website to predict that: Trimble GNSS Planning

Re the “Bad AHRS” warning (or more accurately “Unhealthy AHRS” as it appears now), I looked into this again yesterday and updated the relevant issue.

I’m afraid I likely won’t be able to remove the message for 4.4 because it is caused by a long running disagreement within the dev team as to whether DCM (the older estimation system still used as a backup on Rover and Plane) should display “unhealthy” when it doesn’t have a position estimate… or is DCM even required on Rover. It just wouldn’t be a good use of my time when more pressing issues including the move to SCurves are still outstanding.

The good news is that I think the message can be avoided if, like Yuri says above, the EK3_SRC1_POSXY, VELXY and VELZ are all set to 0 (None). If someone does want to use the GPS at times then GPS/Non-GPS transitions could allow them to only enable the GPS when they want to using an auxiliary switch.

2 Likes

At the risk of adding some complexity and confusion, the EKF3 requires a minimum of 6 satellites (see code here). I agree with what Yuri and Allister have said though because the EKF has a lot of other requirements to calculate a good position estimate so it is rarely the number of satellites that is the issue.

I’m not sure if this thread is more a mental exercise trying to understand AP more (which is great) or a practical issue of trying to use autonomous modes in poor GPS environments…

1 Like