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: 53660


Reply to This

Replies to This Discussion

Today i disabled the INS prearm check and then I also got the log files.

Link for logs: https://drive.google.com/folderview?id=0Bz59zIVOrHfLc0ZDMjZzMHNaUjQ...

I get this, as does another guy on RCG FPV UK thread. I thought it a temperature, condensation or FW update related problem, but sometimes even with a long time for temp to stabilise (it's around 2deg.c outside at the moment) it still wouldn't arm. I have taken to disabling the safety check and flying regardless. I'm on Pixhawk and the other chap is on a mini APM I think. 


Please do not assume it is a software failure.  The MPU6k failures at least are hardware failures.


how could you be sure that is not a software problem?

Hello everyone,

I have had similar pre-arm issues with my Pixhawk, but I have also experienced two mid-air accelerometer failures leading to my quadcopter crashing. I thought I'd share the details and logs with the community, hoping that they will be useful in diagnosing the problem.

I'm using an original Pixhawk from 3DR, with 3.2 firmware. The unit is powered by a combined BEC and power distribution board (HK Pilot Power VI Module - http://www.hobbyking.com/hobbyking/store/__68694__HK_Pilot_Power_VI...), with functionality corresponding to the 3DR power module. During testing I have used 4S LiPo batteries.

During setup I have experienced problems calibrating the accelerometer, as well as prearm checks failing, just like other people have reported. In addition to the "bad accel health" warning, I have also seen "bad gyro health", "alt disparity", and "compasses not consistent". Originally I had the Pixhawk powered with both the power module mentioned above and an additional backup 5V BEC. After disconnecting the backup BEC the problems seem to be at least partly solved, and I'm able to arm the copter. Having both USB and battery connected also seems to result in prearm checks failing. Does anyone have any idea why using two 5V power sources should pose a problem? After all, the Pixhawk has been designed with this option in mind.

After setup, I have been able to fly the quadcopter successfully a couple of times without any failures, using both Stabilize, AltHold and Loiter modes.

Now, to the crashes: Both of these happened in cold weather (approx -5 to -10 C), which seems to be one of the main candidates for why the problem arises.

Crash 1: I flew the copter for just a couple of minutes, mostly in stabilize mode, when it suddenly accelerated away from me. I cut the throttle and it crashed in the woods out of my sight. After analyzing the log I have found the reason for this behavior: The IMU1 (MPU6000) accelerometer values suddenly jump all over the place, causing the stabilize mode algorithm to tilt the copter and fly away. This is seen in the screenshot below. I have checked the IMU2 values as well (not included in screenshot), and these appear normal.

Crash 2: I attempted to run the AutoTune PID tuning while in AltHold mode. After a couple of minutes, the copter suddenly drops like a rock out of the sky. After analyzing the log I found that the z axis on the IMU1 accelerometer had very large negative values. This in turn resulted in very high values for the altitude rate of ascent, and the AltHold algorithm cut almost all throttle to counteract this. The screenshot below shows both the IMU1 accelerometer values, the barometric altitude and the altitude estimate. Again, the IMU2 values appear to be fine for this case.

I have attached the logs for both the crashes.

Basically, I think that the copter would fly fine using only the IMU2, and the fix included in the 3.2.1 firmware ("improved MPU6k health monitoring and re-configuration in case of in-flight failure") may very well help me. I will cross my fingers and try that, and report here if I find anything useful. 

If this is indeed a hardware failure, it seems odd that so many are experiencing the same problems. Was there a bad batch of accelerometers out there when these Pixhawks (and clones) were produced? Could I expect the problems to disappear if 3DR is willing to replace the unit?

Please let me know if there is anything else I can do to help diagnose or solve these problems.


In my opinion this looks like a hardware failure. Could be the MPU6k but RCin also looks strange on channel 4 in the first log and the gyro values on the second log ?!.

And Randy and Tridge stated quite clearly that the MPU6k failing is most probably a hardware failure...
I think you should have your board replaced...

Hi Martin, maybe all Pixhawk owners who experienced IMU problems should also supply info on date of purchase of their Pixhawk. Maybe then, we can see if this problem is related to a particular batch of Pixhawk.

Obviously there is an issue. I'm not suggesting there isn't but I wonder how many are caused by moving the copter while it's booting up? 

Ok, so got some logs. I'm running 3.2.1 beta, had issues with drone not arming (yellow flashing, "DA-DUM" sad sound during attempting to arm). The logs say ACCEL pre-check, checking the logs it looks like my IMU1 is fine but the IMU2 isn't reporting anything.

I flew the other day, four times on three batteries, the first two or three flights was perfect and then it failed. All i did was move location and change batteries, it was pretty cold outside but well above freezing. I've seen this issue before taking it from my warm office (next to fireplace to outside, cold 50F). Anyway, don't think it's a cold thing, since i was flying fine for quite a bit (30 minutes) before i experienced the error.

I basically need to disable INS checking to get it off the ground, since it's my IMU2 i dont' think she'll fall out of the sky, but still a problem.

Attached are the logs, the one ending in "BAD" has the faulty IMU2 and disabled INS checking, the one labeled "GOOD" was my first one, perfect flight with no errors.



That is definitely a failed lsm303d accelerometer. Can you tell me where you bought this Pixhawk? The reason I'm asking is that the pattern I've seen so far in the logs I've analysed is that the boards with lsm303d failures are not from 3DRobotics (3DR gave me access to their serial number database so I could check if a failure was in one of their boards).

I don't see your board in the 3DR list, so I assume it is from another manufacturer. If that is not the case please let me know, as it is possible the database I have is not complete.

If it isn't a 3DR board then can you try pointing your supplier at this discussion? Given the number of non-3DR failures I've seen I suspect they have a manufacturing problem related to the lsm303d accelerometer. It would be good to let them know about this so they can fix it.

Cheers, Tridge

I´ve got n RTFHawk ordered in April with lsm303D issues.

Got it from thanks-buyer on ebay Jun 2014, it was a model 2.4.5 board, i'm seeing 2.4.6 boards out there now. Is it possible that fixes the issue? They have a website now


So is it possible that 2.4.6 fixes the issue, looking at the changes between 2.4.5 and 2.4.6 they added a capacitor to "stabilize" the sensors. Sounds like the issue no?

- NEC original tantalum capacitor is added in back compass and main power supply, making each sensor has stable power supplying and lesser possibility of aircraft crashing

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service