Bad AHRS all the time

Continually getting Bad AHRS - with Rover 4 and Pixhawk 2.1. Been calibrated many times but shows slight jumping on horizon continually. Any ideas?

1 Like

Post a log, and keep high current wires away from your compass.

1 Like

No high current cables near. Does it with only usb, battery and gps connected all laid on floor with battery and power cables running directly away. Showing 12 Sats and steady position. Seems to be in vertical plane where ardupilot thinks jitter occuring - obviously no movement happening. I’ll post a log as soon as I can, weather permitting.

@pilotltd, the “Bad AHRS” message isn’t great, it actually means that the vehicle doesn’t have a good GPS lock. It’s nothing more serious than that. I’m planning to remove this message in a future version. It’s slightly scary and there’s probably nothing really wrong.


It is a scary message :slight_smile: 12 sats in view but that implies I don’t have a good lock but GPS 3D message shows in HUD screen and map correctly shows my position. It does however drift around my actual position slightly over time but only a few metres at most. What are the requirements for a good lock? Is positional averaging performed within the software, or is it just using raw readings?


ArduPilot has a sophisticated Extended Kalman Filter (EKF) which combines the GPS with other sensors including gyros, accels and barometer.

The “Bad AHRS” message will go away once the EKF is happy the various sensors are consistent with each other. My guess is that even though there are 12 satellites, it’s still not enough or they’re not providing good readings.

Maybe it would be best to post a dataflash log.

Not sure what you mean by dataflash log but here’s one of the telemetry logs. No sat lock, but it shows the constant jumping on the altitude, vertical speed and to a lesser degree the yaw. Taken when cube was totally stationary on the ground.2019-12-11 17-54-31.tlog (279.3 KB)

This Link will take you to the Wiki area for logs

We generally need to see a dataflash log to be able to see the internals of what is going on the Flight Controller.

Thanks - found logging was disabled by default? Also docs are slightly wrong, to enable it’s shown as in Standard Params - it’s in Advanced. Cant upload here - refused - file size too big?


Logging while disarmed (the LOG_DISARMED parameter) is off by default, i.e. normally logging only occurs when the vehicle is armed. This is to reduce the amount of logging to just the (normally) important parts which helps keep log files smaller.

If there’s no GPS lock then the “Bad AHRS” message will certainly appear.

But how to use ardurover without a GPS? My application does not require GPS. And I can’t arm because of “Bad AHRS” (even though I’ve removed all pre check params)

EK2_GPS_TYPE to “no GPS”

I still cant get it to arm with just no GPS. The jitter on altitude, vertical speed and to a lesser degree the yaw is still there. I’ve reset the axis calibration numerous times but it still jumps about. I have to disable everything basically and it might as well then just be a radio receiver in there! I’m contemplating sending it back as faulty. I’ve built numerous UAV but never had as much trouble getting one to believe its stationary, when it is, as this. Don’t know whether it’s a software or hardware problem at this stage, the fact that I cant post a log here doesn’t help either…


It should be possible to arm in Manual mode without a GPS or wheel encoders. Skid-steering vehicles should also be able to arm in Acro mode. All other modes will not work I’m afraid because they require a position and speed estimate and this cannot be determined simply by having an IMU (because of drift).


Most people put a log file on a file sharing service like dropbox and then provide a link. It should be possible to arm in Manual mode without a GPS even if the “Bad AHRS” message is shown on the “HUD”… I’ve just checked in the simulator (I used the one built into Mission Planner) and it’s worked OK.

I can arm in manual mode by telling it to ignore everything! It seems this is a long standing problem with bad gyro and compass errors on Pixhawk 2.1 back to 2016/17 on 3.5 which still hasn’t been solved. The latest reply from seller is

"The manufacturer suggest usually to try rebooting the cube once after letting it warm up a little.
Also, it is very sensitive to magnetic field, make sure to move as farwaway from electrical components as possible.

There’s a few solutions here:
Pixhawk 2.1 gyro and compass problem "

Done all that, calibrated outside using a 5m USB cable as far away from laptop as possible - makes no difference whatsoever and I am convinced it is a hardware or design problem. I’m waiting for a reply from proficnc - but favourite at the moment is I’m going to return it for a refund as “not fit for purpose” and look for a different hardware solution.

It’s up to you of course how you tackle the problem but I think things will go better if we first determine if the issue is with the frame, software or hardware. The best way to do that is to provide me with a log which is really not hard:

  • Connect a usb cable between the autopilot and PC
  • connect with the mission planner, open the Config/Setup, full parameter list and set the LOG_DISARMED parameter to 1.
  • Try to arm the vehicle and check the HUD for error messages and report them below.
  • go to the flight data screen, click on the DataFlash tab on the bottom left and select the Download log via mavlink button. Select the last log and push download.
  • copy the .bin file to Dropbox (or similar) and provide a link here.

Anyway, it’s up to you and I won’t hassle you anymore, I’m just trying to avoid some grief between you and proficnc

Thanks for your help.

I’ve got a logfile from the last time we tried it. I assume you need the bin file? Can you let me know if this works. Thanks

Autoanalysis shows
Log File C:\Users\steve\AppData\Local\Temp\tmp7738.tmp.log
Size (kb) 47984.7998046875
No of lines 636416
Duration 0:00:00
Vehicletype ArduRover
Firmware Version V4.0.0
Firmware Hash 0e52bafa
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = NA -
Test: Brownout = UNKNOWN - No CTUN log data
Test: Compass = GOOD - mag_field interference within limits (1.01%)
Max mag field length (1144.45) > recommended (550.00)

Test: Dupe Log Data = FAIL - Duplicate data chunks found in log (116362 and 361850)
Test: Empty = GOOD -
Test: Event/Failsafe = GOOD -
Test: GPS = FAIL - Min satellites: 0, Max HDop: 99.99
Test: IMU Mismatch = FAIL - Check vibration or accelerometer calibration. (Mismatch: 1.67, WARN: 0.75, FAIL: 1.50)
Test: Motor Balance = NA -
Test: NaNs = FAIL - Found NaN in STER.LatAcc
Found NaN in THR.Speed

Test: OpticalFlow = FAIL - ‘FLOW_FXSCALER’ not found
Test: Parameters = GOOD -
Test: PM = NA -
Test: Pitch/Roll = NA -
Test: Thrust = NA -
Test: VCC = UNKNOWN - No CURR log data

Thanks for that. So I can see this is a Hex CubeBlack on a Ackerman vehicle (separate steering and throttle control). Here are some things I noticed from the log:

  • COMPASS_ORIENT is set to “6” which is “Yaw270” meaning that the arrow on the top of the GPS/compass unit is pointing to the left. From looking at the raw compass outputs I think the GPS/compass unit really is pointing left. The autopilot itself is oriented so that the arrow is pointing forward? (wiki page that discusses mounting the autopilot)
  • RC3_TRIM is set to 987 but normally for a vehicle that can travel both forwards and backwards this should be about 1500. Perhaps something went wrong during the RC input calibration. For example if the throttle stick was moved to the bottom during the final phase (where I think it says move all sticks to the middle). Does the transmitter have a sprung throttle? It’s not mandatory but it tends to work better if the vehicle has a sprung throttle.
  • The number of satellites is very low at only 9. I guess this test was indoors? It depends upon the type of roof but the GPS quality will be too low in most indoor environments to allowing any mode but manual to work.

Could you try setting ARMING_CHECKS = 1 and try arming and then tell me what message appear (or provide the log, the messages appear there too).

Thanks for looking. I’ll redo, probably tomorrow. Did you notice the jitter and drift on both baros?