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?
@DG, It could be. I see Randy has answered his post over there indicating he is having INAV issues
I have read this with interest and I will ask for some help to make sure I understand this issue.
I have 2 pixhawks (both 3DR), if I graph the dataflash values for IMU and IMU2 ACCx,y,z on one of the Pixhawks running the latest FIXED WING firmware both IMU, and IMU2 values are almost the same. I assume this is OK and correct?
The second Pixhawk is running the AC latest version for my Quad but when I graph the same results I see that the values for IMU and IMU2 are different by a factor of 10 or more and the phases do not match? is this board having the IMU problem or is this disparity normal. its a new board just installed and not flown yet. purchased in 1st week of Jan 2015
log for the possibly bad Pixhawk attached.
I fly fixed wing. Is there a way to get a definitive read on whether or not one's accels are going/gone South?
I frequently get Bad Accel Health or Bad AHRS. I can usually clear them by unplugging and plugging the battery. Recently, not. So I changed FC;s and all is good. So, that would seem to clearly indicate a hardware issue.
I have couple of questions for HW issue arround "Bad ACC health"
- is known what is bad with boards ? Soldering, chip, board design, power problems or something is out of tolerance ?
- is there way how to easily and 100% detect that my board is facing hw issue ? I had problems in cold weather so maybe if I put cooling bags around board ?
- how to setup logging to see what is reason for Acc failure during start
- what happen when new version detect MPU6K failure and do switchover to second Acc. Is this logged as error in log ?
- can Neo8 affect this ?
I am speaking just about bad Acc, there is lot of mixed answers like bad compass/gyro and so...
Seem to be having the same issue occasionally with my DroPix Autopilot board, which is similar to the pixhawk. It tends to happen after a step temperature change. After calibrating accels in the warm workshop then going outside, it will sometimes fail prearm with bad accel health.
I have the same question. This problem is maddening for me, as it doesn't occur 100% of the time.
In doing some research, I see that with the release of "plane 3.2" and beyond, there was a significant addition of fault detection of AHRS type errors, including the dreaded Bad Accel Health. However, one may ask, how did it fly ok before and what is the REAL impact of getting one of these errors.
I wish the developers could shed more light on this subject, please.
Correction, the "new" FC is now sporadically having the same problems.
What you guys are all confusing is the difference between the autopilot reporting a problem with the setup on your vehicle vs the autopilot reporting a problem with itself.
If you get a big temperature change it is going to cause problems for the gyros and the autopilot is just dutifully reporting it.
If you have a noisy GPS and the autopilot cannot use it to zero the gyros then we report that as an error. And guess what, when you change the autopilot it reports the same error. That is a good thing!
Look at these examples of accelermeter failures uav.tridgell.net/MPU6000-error/summary/summary.html
if you graph that file, does it look like any of those examples?
If it stops reporting the bad acc health then it's no longer seeing an issue I think?? For instance I often get the 'low hdop' warning but once it stops I'm good to go.