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
Andy, I also looked at your log and I encourage you to do the same.
Please graph AHRS2 Yaw, ATT Yaw, and ATT DesYaw.
ATTDes Yaw is the desired heading, ATTYaw is the DCM estimate of the actual heading and AHRS2 yaw is the EFK yaw estimate.
The vehicle is using the DCM solution for navigation and the ATTYaw tracks the ATTDesYaw quite well. What you will see when you graph these is that the the DCM Yaw solution diverges from the EKF Yaw estimate to the point where they are pointing in opposite directions.
The result is that the copter is disoriented and moving in the wrong direction.
You can induce this divergent behaviour by shaking or moving the vehicle while it is calibrating the gyros just after powering up.
Consequently my hypothesis is that the vehicle was being moved while the gyros were being calibrated and that caused the navigation solution to fail and the subsequent loss of control of the vehicle.
This is my first (very tentative) flight since my crash. I have been sidetracked by the RCMAP issues I have been encountering, so the flight was with standard satellite.
Log is attached. The compass values for both compasses seem good (which is a relief) and I was able to get into AltHold and Loiter ok. I have three concerns however:
1. The copter could not tell it had landed! The big yaw you see at the end is me trying to disarm and it thinking it's still flying. Why didn't it think had landed and why was this worse in Loiter? I thought this was supposed to be improved in 3.2.1? What's the correct way to shutdown if it's not happening automatically?
2. Plotting ATTYaw, ATTDesYaw and AHRS2Yaw shows them tracking quite nicely except in AltHold at the end. Is the AHRS2Yaw variance a concern?
3. Auto analysis shows "PM = FAIL - 21 slow loop lines found, max 12.03% on line 7008". Should I be concerned?
Thanks in advance
2015-03-07 13-57-15.bin
Hi Andy,
This is like my flight. Drone moved sharply to the right in land mode and I turn on a stable mode - http://diydrones.com/forum/topics/pixhawk-bad-accel-health-apm-3-2-...
1- I've experienced some great Auto landings and some delayed disarms as well. I am quick to switch to Stab when there is any delay. Sometimes I switch to Stab a bit before landing to remove all doubt.
Hi Craig,
Thanks! That's a great analysis and I'm sure exactly right because, tada:
http://diydrones.com/forum/topics/pixhawk-pre-arm-check-fails-compa...
So I did move the copter before arming because that seemed to be a way of clearing the "Compass not healthy" pre-arm failures. So I'm damned if I do and damned if I don't, so to speak.
So still seems like a hardware issue?
andy
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...
andy
Andy,
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!
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.
Ok, so I actually did what the wiki said - so absolutely no movement while the red/blue lights were flashing (it was stationary on the ground when the battery was connected). Movement when the yellow-yellow light was flashing to resolve the pre-arm failure. So are you saying the gyros are still calibrating while the yellow-yellow flash is going on? If so the wiki needs changing. If not then your root cause analysis is incorrect unfortunately :(
andy
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
-
23
-
24
-
25
-
26
-
27
of 46 Next