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

If the copter is set-up with all the failsafes enabled (battery, radio, gcs, gps, ekf) and then it starts flying away and the pilot is unable to bring it back, I would expect to see errors of some sort in the logs.

If the vehicle just suddenly flips and crashes (which isn't a fly-away as such) then errors like brownouts or motors failures wouldn't show up as errors in the logs.

After a bit more  fiddling it turns out this is a weird channel mapping issue.

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 is the video of my pixhawk, when I connect to the mission planner and did not boot.


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?

From the video you have demonstrated that your Pixhawk is working perfectly fine.   It boots and the LEDs indicate that it has been loaded with firmware and is working correctly.

You get a programming error on the first attempt either because your VM is not handling the serial connection correctly or you have a bad USB cable.

On the second time when the programming completes, you do not have the buzzer connected so you do not hear any musical tones.

The virtual machine that you are running Mission Planner is not handling the serial connections well.

I suggest you attach the buzzer and the Safety Button and then install APM Planner 2.0 on your Mac instead of trying to run Mission Planner in the VM.

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 Craig Elder!

Here is another video from APM Planner 2.0 on Mac OS X Mavericks, and the same problem.


One thing I do not understand ; if this problem exists because of new manufacturing process at 3DR , why people with clone boards are also affected?

Great tjx. Will do.

Did you buy that Pixhawk from 3DR or is it a clone?

I'm curious to know if you are reading the instructions.
Please have a read of the wiki


A lot of us have put quite a lot of effort into the wiki and the instructions.  It is always a bit disappointing when people make the effort to post a video that their Pixhawk is damaged instead of reading the wki.  If you do have a read you'll find that sound means you don't have an SD card installed.


I know we ship the boards with the card installed.

Now that you have demonstrated that your Pixhawk is working correctly, how about changing the name on the video?


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

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service