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


Reply to This

Replies to This Discussion

The wiki is correct. The LED blinks Red and Blue during the gyro calibration.

The double yellow indicates an error that you can read more about on the Planner screen.

The root cause is the divergence of the yaw estimate.  You can graph that yourself.

The most common way to create that divergence is by moving the vehicle when they are being calibrated, but sure there are other ways to mess up the gyros.

In any event the sensors are behaving correctly

Maybe it just needs a good night's sleep :)


Way back on page 4 of this thread, you asked me to do a register dump of the LSM303d IMU.  I posted some screenshots, but I think they got swamped in all these replies.

Can you take a quick look at those screenshots, and let me know if there's anything wrong?

By now, I'm thoroughly confused as to the issue. There are lots of relevant and some irrelevant posts in this thread.  Maybe one of the devs can post a summary on the front page of this thread.

As I understand, we are talking about two unrelated issues, that happen to have the same symptoms:

1) there is a batch of 3DR boards with a wonky MPU6000. (Are any clones confirmed to have this issue?) This is a HW issue, nothing to do with FW.

        Symptoms are:  

                  -erratic acc/gyro (IMU) values in the logs.

                  -Prearm warning: "Bad accel health" or "bad gyro health"  (also "altitude disparity"??)

        Fix:  Contact 3DR, get a replacement

2) there is some issue with the lsm303d, causing flatlining acc/gyro values. Issue is seen on 3DR and clone boards.  3DR has previous experience with a very similar issue, and it was thought to be fixed with a register tweak.  Is this the same issue, or a new HW problem?


                  -flatlined acc/gyro (IMU2) values in the logs.

                  -Prearm warning: "Bad accel health" or "bad gyro health"  (also "altitude disparity"??)

       Fix: contact manufacturer?  install AC3.2.1?

I think there can be corruption in the parameters that actually do not appear as changed parameters.  I've had this in my development work, usually if I am playing with parameter enumerations.  Strangely, doing a parameter reset, then restore the parameters fixes it.

Unfortunately, I can't explain what's going on.  Maybe Tridge knows.

FWIW I am going to give up on APM Planner 2.0. I fired up Mission Planner 1.3.19 because I was confused by MAG values and this is all completely obvious in MP without much analysis - errors all highlighted, nicely graphed etc. In APM Planner 2.0 it's practically garbage. -ve MAG values incorrectly represented, no highlighting of errors, no filtering etc. Perhaps my issue is that I am using the wrong software...


Yea.... I've had issue with that too. I do not like the way it doesn't readily show errors. I mentioned that over in the APM forum and was told they were working on that and would be available soon. That was several months ago. But... it's free so kinda hard to complain too loud. 


Thanks for sticking an issue in the issues list for APPlanner2.  That's the right thing to do.  It's not my baby so I can't make promises but you've done your part!

haha...fact is,next day, I cant force my hawk to show bad accel any more...


Thanks again for looking at my previous log. I was able to find another one of my logs that exhibited odd symptoms. This was an AUTO flight again in cold weather -5 based on the logs. I did find someone else on this thread mentioned odd behaviors/fly away/drift at the same temperature; could be coincidence.

Just before the crash using FPV I noticed it losing altitude in AUTO (the log not showing it in AUTO for some reason). This one I was not able to recover. I switch to RTL in hopes it would gain altitude (should have gone to manual). You can see that the Acc readings become inverted and and the Alt showing it gaining altitude when in fact it was still going down hence the CRASH_CHECK.

I inspected the aircraft while in the field without resetting the Pixhawk and everything looked fine, no damage to the props or motors; intent on wanting to keep flying I took off and did some high speed passes without any issues. It does however seem that from this point forward is when I started having major vibration readings and believe lead to the flyaway that I posted earlier. notice the 66.80 AccZ, I have a very hard time believing this is reflecting actual conditions. 

Can you explain the cause of the inverted vibrations and altitude increasing just before it crashed and before I land? 

DAlt flat lines in stabilize mode is that normal?

I have attached two log files, 2014-12-31 13-52 is the crash described above and and 2014-12-31 14-20 is another flight that has similar altitude and vibrations issues at zero throttle. 




I'm going to chime-in on "jesuis" post above (as I would like to pose a similar question).

I recently updated my firmware from 3.1.5 (new on 3DR genuine Pixhawk around 8/2014) to 3.2 AC (1/2015).  I have noticed since updating the firmware, I often get several pre-arm errors that I did not get previously, but in particular:

1) Bad gyro health

2) Bad Velocity

I'm running a genuine 3DR uBlox compass, and I did do a new compass calibration prior to my recent flights on the Pix.  I had four really nice flights on the first day after the FW upgrade (other than the arming errors that I simply power-cycled to clear).  I have reviewed the logs and nothing stands out as IMU errors, compass / mag errors, etc.  Yesterday, I flew one flight (again with a pre-arm gyro error, cleared with a power-cycle).  It flew pretty decent, except about 9 minutes into the flight, the hex suffered a slow descent (like no thrust), bounced off the ground and continued to fly (sort of fine until I could land it).  I thought maybe a vortex issue, but the descent was so slow, it seemed more like a battery issue.

I review the logs, and nothing.  The battery (both Vcc and Volt) were steady (and a recharge of the lipos indicated I had only used about 50% of a 10,000mAh pack).  The only error I could determine was from the "Auto Analysis - Test: Thrust = FAIL - Avg climb rate -3.16 cm/s for throttle avg 707).  I always take-off in "stab-mode" to ensure my "TRIM_THROTTLE" is updated based on the weight I am flying at (I use a variety of batteries, single 4S, parallel 4S, and a huge 6S).  Usually the TRIM_THROTTLE sets-up around 600-640.

Now I did change three items in my parameters this time which may have led to this incident (and may be unrelated to the F/C errors on arming).   1) I tightened-up THR_DZ from 100 to 50, thinking this would provide a smaller "dead-band" around mid-stick for Alt-hold, pos-hold, loiter modes, 2) adjusted PILOT_ACCEL_Z from 250 to 350 thinking this would give greater acceleration for Z-Axis ascents and descents, and 3) PILOT_VELZ_MAX set to 500 thinking this would allow for greater z-axis climb rates.

Perhaps someone could look at my log and see if anything stands out at the 9 minute mark.



A quick follow-up, although the discussion has now moved on:

I contacted 3DR regarding the crashes described above, and they confirmed that the Pixhawk has an MPU6000 failure. They will be sending me a replacement. 

A bad gyro health for a pixhawk card purchased between summer 2014 and end of year 2014 could mean, although not frequent according to 3DR, a hardware card issue. Fix : ask for a replacement to your distributor.

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service