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?
Replies
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!
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
Pixhawk runs fine in cold and hot. We have one sitting in a thermal chamber cycling between -40 and +40 C however this is more dramatic https://www.youtube.com/watch?v=DfZfNk-jYdI
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.
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.
Correction, the "new" FC is now sporadically having the same problems.
Hi
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.
Thanks guys
2015-02-13 19-58-26.log
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?
http://diydrones.com/forum/topics/development-help-tethered-uav-to-...
@Craig Elder
You mentioned inertial nav errors. Is that related to this thread?
http://diydrones.com/forum/topics/csgshop-neo-m8n-is-giving-pm-erro...
I know others that get these errors in large numbers in flight along with the twitching/drifting. The errors are consistent (every log since using 3.2), but the twitching is more random with varying severity. Nobody to my knowledge has yet explained what they mean, and I cannot find any reference in the Wiki documents.
Many people are switching to the more advanced GPS units such as the M8N because of the better Nsat/hdop capability so I think it is very important to know if there are communication issues with them and Pixhawk. I'm beginning to think there is, and will switch to the 3DR GPS LEA-6 to see if the error persists.
-
18
-
19
-
20
-
21
-
22
of 46 Next