Pixhawk BAD ACCEL HEALTH APM 3.2 - collecting data

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?



You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


              • perfect so at least the Devs know. Everybody wins then.

      • Hm...my original Pixhawk (bought at Kopterworx) is from February 2014..showing no sign of bad accel ,but Whitespy RTF Hawk is from May 2014 and of curse problem is here, just siting on the ground...did they have you production process before you?

        "Our projections are Pixhawks produced from July, 2014 to Jan, 2015.  While we believe the true effected population is smaller than that, we are being conservative to so that customers can rest assured that the issue will be taken care of should they experience it."

        • Moderator

          Craig was only referring to genuine 3DR boards manufactured between July 2014 and January 2015. They would have no control over boards manufactured by Whitespy or any other third party. Boards manufactured by 3DR and sold by other vendors would be effected. While the design and tooling may have been copied by other manufacturers Quality control would not be something that could be as easily replicated.

          Boards manufactured elsewhere certainly may have defects outside this time frame that replicate this or other problems.Those individuals experiencing problems with boards not manufactured by 3DR should either contact that manufacturer, or the retailer they purchased their boards from.


          Nathaniel ~KD2DEY

    • Lol, I guess most of the boards are made in the same place by the same people :) 

      • @Artem

        Very true.

        And most of the times using the same components, which components are manufactured by a different company

  • Have there been reports of the LSM303D failing mid-flight?
    As far as I have been reading it looks like all the related crashes where MPU6K failures.
    And is the mentioned maufacturing process affecting only the MPU6K or both IMUs?
    • Developer

      If you look in the list of logs I posted earlier you will find several cases showing a problem with the LSM303D.

      We had problems with early versions of the board (2.4.2 and 2.4.3) that only had the LSM303D fitted and it would fail in flight so we added the MPU6000 to the board in Dec of 2013 to make 2.4.4.

      The manufacturing process affects only the MPU6K.  On the LSD303D, the SPI and I2C busses share the same pins.  The problem we encountered is that it would interpret SPI commands meant for other devices on the bus as I2C commands for it.  After contacting the manufacturer we found out about some hidden / undocumented registers that would disable the I2C bus and setting those registers resolved the problems with the sensor.

  • Hello everyone!


    I will count my bad experiences with the Pixhawk flight controllers; bought in date October 13, 2014 and January 14, 2015.


    With the first flight controller purchased in date October 3, 2014, I could make five flights in Stabilize mode but with many difficulties because during the configuration through the mission planner, I received many messages of error "bad accel health" and then the sixth and last flight made, my pixhawk collapsed and fell to the ground, so I decided to sell it and when the buyer used the pixhawk, he felt a big disappointment (the pixhawk flew unstable and uncontrolled), so I had to return the money the buyer and from that moment I realized that the first pixhawk was defective.


    With the second pixhawk purchased as of January 14, 2015, I could make three flights with AC3.2 release, and when the quad was beaten by the wind, this in turn rose sharply upwards and then downwards giving jumps uncontrollably, I made several adjustments to the settings by mission planner and I can not solve the problem, so I decided to save the pixhawk and buy a VR Brain 5.2 of VirtualRobotix to rule out the possibility that the problem it was because of my frame or AC3.2 firmware release, but thank God, is not it, my Quad works seamlessly with VR Brain 5.2 and firmware AC3.2 release, AC3.2.1-rc1 and AC3.2.1-rc2, is a solid and quiet as rock in the sky, but the connection system of flight controllers VirtualRobotix are not to my liking, for this reason I prefer the system connection pixhawk and today decided to pull out my closet the pixhawk and make various settings, but to connect the pixhawk a mission planner, this would not start, I made several attempts with other USB cables and no success, right now my pixhawk is dead.


    I really like the pixhawk by their physical characteristics, connection system and its integration with the arducopter firmware, but I lost confidence in them.


    Any suggestions or help with this?

    Thank You!


This reply was deleted.


DIY Robocars via Twitter
Sep 9
DIY Robocars via Twitter
RT @chr1sa: We've got another virtual @DIYRobocars race tomorrow at 9:00am PT. Two dozen autonomous cars will compete, four at a time. Ther…
Sep 4
DIY Robocars via Twitter
Sep 1
DIY Robocars via Twitter
Aug 31
DIY Robocars via Twitter
Aug 31
sam liked Jimmy Oliver's profile
Aug 25
DIY Robocars via Twitter
RT @ExplorerRobocar: Sometimes, I am really a big kid!! Having fun with my virtual RC car on the @diyrobocars track 😜😉, by using the « AR R…
Aug 24
DIY Robocars via Twitter
RT @grepLeigh: @donkey_car @unity3d @TensorFlow ~1050 episodes into training, my agent learned to erratically drive in the left lane. 🤖😆 ht…
Aug 24
DIY Robocars via Twitter
RT @EclipseCyclone: Sweet! http://Robotec.ai high performance #ROS 2 @unity3d #CycloneDDS bridge for @AutowareFdn @SVLSimulator now…
Aug 24
DIY Robocars via Twitter
RT @a1k0n: My car had a lot of trouble getting around the track at the last @diyrobocars event -- only one actual finished lap during the r…
Aug 24
DIY Robocars via Twitter
RT @SmallpixelCar: This is the run time map https://t.co/VzykOkUt2G
Aug 24
DIY Robocars via Twitter
RT @SmallpixelCar: Made a lot progress on Warm Spring Raceways track. Almost finished one lap. https://t.co/nUVpufZQyP
Aug 24
DIY Robocars via Twitter
RT @AntonioRobotics: Super fun time seeing these autonomous cars race at @circuitlaunch for the @diyrobocars quarterly meet up! The demolit…
Aug 15
DIY Robocars via Twitter
RT @a1k0n: I thought my dumb localization code was still working at the new @circuitlaunch track, but it was just *barely* working. I shoul…
Aug 14
DIY Robocars via Twitter
RT @DAVGtech: Recording of entire in person @diyrobocars race today @circuitlaunch. Fast forward a couple hours to go straight to the racin…
Aug 14
DIY Robocars via Twitter
RT @SmallpixelCar: This is the run time map. Very noisy Lidar signal https://t.co/bAbeVUMi10
Aug 14