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


Reply to This

Replies to This Discussion

1. The issues existed before.  We used to not have the ability to detect and identify them.  Now we do.  If you are getting a warning now where before you did not then my suggestion is to fix the problem with the setup on your vehicle.

2. That is already built into the system.  When the error condition goes away, the error indicator will go away.

>>>in your example, the GPS gets adequate lock and HDOP?

Having GPS lock and a low HDOP are not adequate measurements of the GPS performance.  We used to only use those criteria and they are not adequate.  There were still times when the autopilot lost control of the vehicle.  Now we use the velocity information from the GPS.   The most common scenario is there is a lot of interference with the GPS and it reports a noisy velocity that cannot be reconciled with the other sensors.

>>>So at the end of the day, I want to know if it's safe to fly or not

The warnings are there to give you some indication that a problem exists and you should do something about it.  If you choose to ignore the warnings there is some risk that you will have a problem.  The risk is exactly the same as it was without the warnings, but then there is that day when you have a flyaway.  We used to not be able to explain the flyaway, but now we can and we provide warnings when conditions are not looking so good.

Craig, thank you for the explanation. I may be having GPS issues. That is the common denominator for my two Pixhawks.
Which attribute in the log files would indicate the GPS noise issue you mentioned?
Oh, one other thing. Since there is redundancy on the PH, are there different warnings for one sensor vs total sensor failure?

Get yourself a ublox message manual and look at the UBX1, UBX2, UBX3 messages in the log.  Look at the jamming indicator, the noiseperMS and the receiver gain. 

Same issue here. Attached logs for bad (1) and good (2). I don't know is bad log any good as I enabled logging when alert was on.

Seems that when I plug the battery in inside the house, I usually get no warnings. But if I do it outside (has been around -3 - -8 celsius) I get bad accel health all the time.

I have rtfq version of pixhawk board.

Read Craig's replies to my questions above. I think the answer you seek is there. Short answer, rapid temp. changes affect some sensors, causing instability.

I did, but I'm not getting really an answer there or earlier posts. I'm really confused with this. Sometimes it's bad accel, sometimes compass not calibrated and sometimes something else that prevents me flying. But there have been still more successful flights than fails. I have done calibrations really carefully as I had toilet bowling earlier. With current calibs, quad is really solid when it wants to fly.

I would like to know is that IMU behavior "a feature" or hardware failure. I have got the alert also inside the house, not only outside when temp does change.Has anyone confirmed that there is a cold soldering or something like that on the board? There has to be some reason for the another IMU to go nuts occasionally.

Should I try RMA or what?

I would contact tech support first. You do hav Pixhawk? Not a ***hawk?


2015-02-16 22-34-13 2.bin, is normal.

2015-02-16 22-34-07 1.bin shows a LSM303D failure.  

That serial number is not on my list of 3DRobotics manufacturered Pixhawks but if it is recent I might not have it.

If it is a genuine board then please contact help at 3DR for a replacement, otherwise you will need to contact the manufacturer for replacement.  Is it a 3DR manufactured board? 

I definitely agree. It is good think that FW is improved and reporting more potential problematic during start-up. Security first, no question, better than see fly away or crash.

But I am trying to get on core - what is real problem. Lot of different boards are affected (and it includes not just cheap clones but also overhauled solutions like DroPix) and it is something what make me worry. I don't believe that all of them have soldering problem. Maybe bad batch of sensors ? Maybe bad design ?

If it is temperature problem - fine, baro also don't like fast temperature changes. If I know that, don't problem, I will wait for temperature stabilization.

If it is bellow zero problem - fine, can we fix it by code (by datasheets it should run under zero).

I can even imagine pre-heater inside of copter to make it warmer faster (so we will not need to wait till heat from processor will heat up case to stable temperature) or slower (with fan for high temp areas)

I will look for some cooling bags

Craig, how can I see that it is LSM303D failure - because Acc on IMU2 is arround 60 which is out of scale ?

Craig, how do you see this issue as whole? Are there bad lsm chips on the loose or could it be something else? Has 3DR got any of these problematic boards back and had a chance to analyze those yet? As it seems this is not manufacturer dependent problem..

Like I told in the first post, I have rtf version of the board, so I'll contact rtfquads about the possible rma. But before that it would be nice to figure out the reason. If there's something wrong with the design, just a replacement would not do it. Are you able to take design problem out of the table?

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

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service