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
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.
same subject
http://ardupilot.com/forum/viewtopic.php?f=80&t=11048&p=28904
it is always good to check magnetic interference with log auto analyzer. do a quick flight in stab mode with couple full throttle passes and run that log through the MP log analyzer if the mag interference is greater than 35 one definitely has issues with the current compass position. I had this with 6s and 8s setups. twisting all DC wiring and making it as short as possible + getting compass away from it helps. compasmot is a great work around, but better to reduce the mag field in the first place.
In my case I don't think the problem was the parameters / settings. Look at the off-sets I had here http://ardupilot.com/forum/viewtopic.php?f=100&t=10932 Something else was going on I think???
hi im getting bad compass health error a lot now. soon as I fly it the buzzer and LED goes absolutely mental. It flashes blue and green so fast I cant keep up. model flies weird and I cant get this issue resolved at all. Dont know how to upload a log but its very frustrating I have to say.
Its getting to the point where ill have to sell the pixhawk and replace it with a DJI and I HATE DJI!!!
Sorry to hear of your issues. The good news is the logs will tell the story if they are set right.
The LED's are already telling you something by the color.
I would recommend starting with MP and getting familiar with the HUD and GPS Sat count, HDOP (gps signal quality) etc.
Here's the link explaining how to DL and analyze logs
I know this may be just a random failure but I recently suffered with Bad Velocity, Bad GPS Health messages and flipping at takeoff when I re- installed my Pixhawk on my quad. The PH had flown without incident on an Octo so I felt that it was not a basic hardware problem. I had upgraded to APM 3.2 so suspected that might be the cause of all my problems. On the odd times when I could arm the 'copter and try and fly it leaned to the right so far that I could not lift off without flipping. Finally after reloading the software and setting up the 'copter more times than I could imagine I found the following:
1. Not having geofencing failsafe switched on improved my ability to arm the 'copter to almost every time and got rid of Bad GPS Health and Bad Velocity. Rechecking the geofence failsafe did not then give a problem.
2. The flipping stopped and I could fly by not using the RC_MAP function. I use JR gear which uses TAER for channel order, hgence my use of RC_MAP. I changed the Tx channel order to the PH default (AETR?) and this gave me what I expected as far as arming and flying.
Something does seem to have changed in terms of the the reliability of the arming process and HDOP values seem to be much higher than I have previously seen.
Sorry I don't have any logs or other info - weather is once again windy here in the UK so flying has stopped again.
Peter
FWIW I too am using TAER with PPM sum and hence RC_MAP. When I was using a Spektrum satellite directly it did seem more stable (mapping is done in the decoding as far as I can tell). My Tx (Dx8) doesn't allow me to change channel order.
andy
I have not heard the 'bad accel' voice in a long time but I did today. I flew,,, had no problems,,, landed,,, walk down to my basement and let it sit for a minute and got that warning. I bought this one sep 21st 2014. Might be nothing but if it isn't pls let me know. Here's the log.
325.BIN
That log does not have an IMU failure in it
-
21
-
22
-
23
-
24
-
25
of 46 Next