A few users, myself included, appear to be having issues calibrating accels and/or arming when using APM 3.2 on a Pixhawk.  I see posts here and there, but thought it may be best if those having the issue could all 'check in' to one post so that the developers can see how widespread the issue is and gather data.

My Pixhawk will arm occasionally, and will even fly successfully.  Occasionally however it will not arm and I will receive the pre-arm error "Accels not healthy".  A few days ago I was able to arm and fly thorugh one lipo, then after landing and swapping batteries I could not arm due to this reason.  I have attached the logs from the successful flight, as well as the failed pre-arm logs, to this post.

As you can see from these images there is something amiss with IMU2.  This is a snippit from the good flight, showing values for AccX on IMU1 and IMU2:

and here are the same values on the second attempt, pre-arm.

In the 3.2 release thread a few users had mentioned the issue and Randy advised to set the log_bitmask to "131070" so that it will log everything including the pre-arm checks.  I encourage others having the issue to do the same and share the logs and experiences here so that we can find out what is going on here - is there a bad batch of Pixhawks in the wild that only now show the hardware errors due to something new in 3.2, or is there an issue in the APM software?

Views: 53913


Reply to This

Replies to This Discussion

My apologies if it seems I am insinuating it is something you did intentionally - that is not the case.  I agree that this is most likely a hardware issue, and apparently it is not affecting official hardware (or at least as much).  However if a hardware check was put in place that detects this issue where it didn't before, it would be worth it to the community to explain why it is doing so and why it was implemented in 3.2 at all.

I don't know much about the code, but if IMU2 has been providing bad data all this time (which is very likely) then it apparently isn't used for anything currently.  Do the devs have plans for it in the future, or was the hardware check put in place for some other reason?  If it is unused, perhaps you could add an option to disable this check so that those with third-party boards could fly again?

@ThatJoshGuy, I am concerned that your question "or was the hardware check put in place for some other reason?" may be at the heart of the matter.  I hope the check was not coded intentionally, to make certain kinds of boards inoperable. 

Your suggestion/solution " If it is unused, perhaps you could add an option to disable this check so that those with third-party boards could fly again?" is a stellar idea

Thank you Rob, glad it is being looked into. The issue I guess we have is that we could replace clone boards with 3DR only for the same problem to occur.

As you point out, things were fine until 3.2 (also the last 2 beta's of 3.2 in my case) and this would tend to say that the code has either exposed new hardware functions (checking 2nd IMU) or is being stricter on checks. 

It is really odd that connecting / disconnecting a battery 3-4 times will clear the problem. If it was a simple hardware issue, I'd expect it to be reproducible with reasonable consistency. Mind you, same could be said of many s/w issues <grin> Oh, to be a coder ...

All your hard work is genuinely appreciated. Bit nervous now as my flight test is in a week and I'll look really daft if I can't even get the thing to fly on the day!

My baro temperature is actually rising during flights.
It's probably some component heating up the interior of the case.
The baro temperature won't neccesarily correspond to the outside temperaure. Especially as it is normally packed in foam or something similar.
That's not a sign of a fault.
There have been reports of 3DR boards with the fault, too.
In 3.2 both IMUs data is used for the EKF. That's probably why it is tested more thoroughly.
The "option to disable this check" is already there.
Just disable the prearm checks.
I'm flying a clone and I want to know if any component ist faulty.
Thank you from my side, too.
If you suggest any testing routine I would happily do it, when I'm back in Germany in January.

Hi Everyone,

I've been leading the effort within the dev team to work out why we have been seeing some of these IMU errors (eg. accelerometers on the MPU6000 not matching the accelerometers on the LSM303D). I've written a tool to analyse large numbers of log files looking for the issue, and we've used that tool to analyse over 40k log files from droneshare.

It looks like there are two separate issues:

  • the mpu6000 can get into a state where it has large offsets or just flatlines
  • the lsm303d can get into a state where it has the wrong scaling

For the first issue I have remote access to two boards in San Diego that show the issue. For the 2nd (lsm303d) issue I'm waiting on a board to be posted in that showed up in the droneshare log search that shows the lsm303d issue on a regular basis.

Meanwhile I've been working on a set of software changes that try to both detect and fix the issues. The changes are now in ardupilot master, so if you use the 'latest' firmware from firmware.diydrones.com you will get the changes. I'd very much appreciate it if as many people as possible could bench test (and flight test if you are feeling brave) those firmwares to see if it helps. What I expect to happen with this new firmware is:

  • if either issue occurs then the GCS will display a IMU failure message ("gyro failure" on MissionPlanner).
  • the dataflash logs will show a non-zero error count in the IMU or IMU2 messages (last 2 columns, called ErrG and ErrA)
  • the bad IMU will be automatically reset, but will also be locked out from use, unless both IMUs are bad

Tests with both 'good' and 'bad' boards would be appreciated so we can have some confidence in these changes for an upcoming release.


Cheers, Tridge


same issue :-(   bad accel health,wont arm

weather 3°C, imu2 (~ -8g constant on XYZ)

HW: Dropix ,French made pixhawk

after several reboot (5/6) i managed to fly.

one days before, normal init in my garage (T°?), and cool poshold flight in 20/50 km/h of wind.

makes more test for the T° today,   max 2°C outside, 17/18° expected inside.

I hope that some else in the tropic have the same issue...

volunteer for tests ;-)


Hi Vic,

Can you please do some testing with this firmware:


That version includes an attempt to fix the issue you are seeing. I don't have direct access to a board that has this problem, so a DF log would be much appreciated.

Cheers, Tridge

Hi Andrew!

i'd haven't see your post before mine.(family Christmas holidays, several things in same time ;-) )

Just restart my drone,in my workshop (18°! yes!! ): ok.

Put it outside, without woolly hat, just to see...waiting

flying session with friend is planning this afternoon, if i have same issue, i hope, I'll flash the FW and make a return here.

I'm afraid to miss-understand DF logs?


Right, but it would be nice if the temperature was correct as I think it should be.  Even if I left the unit outside for half an hour the temperature is still high.  I have notice other peoples logs show high temperatures as well.

I am working with a MS5607 barometer chip and it is dead on for the temperature.  Not sure why the Pixhawk is not as well.

With the temperature off it can effect altitude calculations being off as well.

Also is the number displayed allowed to go negative.  If the value is unsigned it is possible that it is showing a negative number go up.

Nobody really looks at the temperature when there done flying to see its right.


I'm afraid to miss-understand DF logs?

DF logs are "DataFlash" logs - the name for onboard logs stored on the microSD on Pixhawk.

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service