Pixhawk BAD ACCEL HEALTH APM 3.2 - collecting data

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:

3691166950?profile=original

and here are the same values on the second attempt, pre-arm.

3691167027?profile=original

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?

goodlog.bin

badlog.bin

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

    • I have had the same "Bad Accel Health" issue for 3 different Pixhawks in a row.  Two were purchased directly from 3DR.  The 3rd is a knockoff.  I have tried many different firmware versions without success.  When they boot up correctly, they fly great!  But it is very frustrating to have to cycle power repeatedly to get a blue or green light.  I have found that powering up using a USB power source without the XT60 power module connected to a battery works every time.  But I only have USB power in the garage, not in the field.  I think I'll have to make a portable USB power supply so I can change batteries in the field without 30 reboots. :0

      Could the issue be with the APM Power Module sending crappy power the the Pixhawk on power-up?  I have two genuine 3DR Pixhawk XT60 power modules and problems occur using both.

  • I'm fairly sure I have also been suffering from this problem ever since upgrading from 3.1.5 to 3.2. Unfortunately I haven't got telemetry radios, although these are now on order, so wasn't generally able to see, and log the issues as they happened but there were numerous times where I had to re-power my Y6 3 or 4 times before it would behave. When I did connect to it directly I did get the accel warning and after re-calibrating things would be fine.

    This also manifest itself in apparent accel drift as described when the Y6 doesn't see itself as level at which point getting it off the ground becomes virtually impossible. I actually held it in the air with the props spinning and you could feel it only wanted to fly at an angle of approx 20 degrees backward bank.

    My confusion is I never had this issue under 3.1.5 which always would arm within 30 sec of powering up. The only change in configuration I made between the two versions was to enable geo fencing so I originally assumed this was what was causing the delay.

    I have now enabled full logging, including before arming so I should capture the issue when it happens again.

    PS. My Pixhawk was purchased in May last year, hence if there is a hardware problem I'm really keen to nail it before my warranty runs out, and has never been involved in a crash, only occasional tips due to the drifting calibration issue. It is currently running 3.2.1.

    • Here's one of my old logs highlighting the IMU Mismatch fails, PM Fails and GPS HDop issues I've been experiencing. I'd really appreciate it if someone could let me know if this looks to be a hardware issue so I can get the return underway before 3dr my warranty expires.

      Hopefully I will be able to get some other logs showing the pre arming failures now that I have logging set to capture pre arming data.

      Thanks in advance for any help.

      2015-03-22 17-12-39.bin

  • So I think I am being affected by this.  I bought a Pixhawk direct from 3DR in December 2014.  Right off the bat (using Arducopter 3.2), I was having a lot of trouble calibrating it and would frequently calibrate it at home, and then get to the field and it would fail to arm with the accel health warnings or indicate that it was not level even though it was.  One thing I noticed is that when I would calibrate the access sometimes it would say it had calibrated Offset[0] and Scaling[0] and sometimes it would indicate it had done two sets--[0] and [1].  

    I came across this thread and decided to wait to report the issue until I could install 3.2.1.  After the upgrade, things seemed better for a while--calibration usually succeeded (always indicating both sets [0] and [1] were set) and I was not getting the accel health warnings.  Until a couple days ago.  I have faced this issue multiple times using 3.2.1 now.  I calibrated everything last night, and then when I got to the field today I was getting accel health warnings. I had to unpower and repower the pixhawk 4 or 5 times and it finally quit giving those errors.  I was able to fly, but there were obvious calibration issues.  When I got home, I checked the calibration, and sure enough, it appeared as though the quad was rolled about 20 degrees even when on a level surface.  

    So I recalibrated again.  It succeeded, but only showed that that set [0] of the params was set--no mention of set [1] this time.  Is this a bad board?  Anything else I can do to prove that out?

    • Does anyone have any ideas on this?  Why do I sometimes get two sets of calibration values, and sometimes only one?

  • Hi,

    i have just build a quad using this pixhawk: http://www.ebay.de/itm/261825646287

    After finishing this build, i was able to fly the copter for some time. after that, i was not able to arm it outside. (5°C) whenever i go inside ~23°C i can arm the copter. 

    I tried to read all 33 pages of comments here, but i am still really confused: 

    - Is there a fix for this problem? (like downgrading to 3.1.5?)

    - what exactly is the Problem? (HW related? software related?)

    I hope someone can clarify my problems!

    Thanks!

    • Hi!

      Please give more additional info:

      * for ex when you try to arm what color leds are flashing?

      * Have you tried connecting MP outside (then from the screen mp should tell you why its not arming). If led is flashing yellow then most probably prearm check is violated.

      Also when you are changing battery outside, make sure gyro gets calibrated (automatic calibration is carried our every time pixhawk starts, so do not touch it for few seconds when You plug battery in).

      For me, I flied my drone whole winter, no problems with cold weather for flight controller. I have tried out firmware 3.1.5, 3.2.1 (which went to live on February 2015). Now I am using just pure 3.2, I think it is most stable version.

      All the best, Eva

      • Hi,

        i am getting the bad ACCEL HEALTH warning + a yellowish blinking light on the Pixhawk. I tried firmwares from 3.1.5 to the most recent dev build (3.3)

        Reading through all the answers and theories here leads me to the point that i will just disable all the pre_arm checks - it works. BUT it really feels wrong.

        From how i understand the Problem, it is because there are now (since 3.2) two IMUs recognized. From the posts here i guess that the second IMU is maybe faulty on some Pixhawk clones - so is there any way to disable the second imu in the code or Missionplanner? Could this maybe help to solve the issue (just a little bit ;) )?  

        Any Idea to solve this?

        ...i thought upgrading form APM to Pixhawk is a good idea ;)... false...

        • It's my understanding the biggest reason for more access health warnings since updating is the code is more picky on what it deems as okay to fly. So you were probably flying before with the same IMU/s performances but just didn't know they were a little off. In other words the pixhawk is just doing what it's suppose to do and letting you know. I get that from time to time but if it stops reporting then it's okay to fly as far as I know. If it continues to report this constantly on every start I'd be concerned or if your ground station reports this and sets it to go into land mode by itself then that is certainly not good either. If your really concerned you have a bad IMU post a few logs when you got the warning and or look at them yourself and see if they look like what is described as a failure in several places in this thread. Last but not least... it cannot be mentioned enough... do not touch or move the pixhawk while it's arming. I have definitely cause this error myself doing that.

          • ..arming is one thing and connecting LiPo another....so what is it?

This reply was deleted.

Activity

DIY Robocars via Twitter
Videos from the ICRA autonomous racing workshop are now available: https://linklab-uva.github.io/icra-autonomous-racing/
Thursday
DIY Robocars via Twitter
RT @SmallpixelCar: Prepared race track for Warm Spring Raceways @wsraceways and looking forward to test my new car at RAMS RC @ramsaicar fa…
Jun 6
DIY Robocars via Twitter
RT @f1tenth: Trying out some nasty blocking maneuvers 🏎️🤖 #f1tenth #autonomousracing https://t.co/nMTstsaogM
Jun 5
DIY Robocars via Twitter
May 27
DIY Robocars via Twitter
RT @araffin2: I will talk this Saturday from 18:00 to 19:00 Paris time for the @diyrobocars community about learning to race in hours using…
May 27
DIY Robocars via Twitter
RT @a1k0n: Luckily the infeasible hairpin problem was easily reproducible in simulation and I could test the fix before bringing the car ba…
May 26
DIY Robocars via Twitter
RT @a1k0n: Another problem was that I was over-constraining the car's allowed accelerations, so it didn't think it could turn as tight as i…
May 26
DIY Robocars via Twitter
RT @a1k0n: Breaking the map up into two halves worked, but I had to be more careful about separating the inner track from outer. There's se…
May 26
DIY Robocars via Twitter
RT @a1k0n: Here's a datalog for my fastest lap of the day. Lap timer is tiny window lower-left. https://t.co/myrlWWrKUY
May 26
DIY Robocars via Twitter
May 26
DIY Robocars via Twitter
RT @a1k0n: Here was my car's POV. Man this track is confusing in first-person! After the incident my camera was all scuffed up and I was af…
May 23
DIY Robocars via Twitter
RT @circuitlaunch: Loved seeing so many familiar (masked) faces at Circuit Launch today for our first in person @diyrobocars in over a year…
May 22
DIY Robocars via Twitter
RT @circuitlaunch: Last but not least, mystery guest @BostonDynamics Spot took to the track @diyrobocars He enjoyed the #brazilianbbq too 😂…
May 22
DIY Robocars via Twitter
RT @SmallpixelCar: Today’s race @circuitlaunch for @diyrobocars with @a1k0n Was busy in the morning and did not get a chance to tune camera…
May 22
DIY Robocars via Twitter
RT @a1k0n: This was epic. My car was barely working this morning, had to make a lot of changes and extremely dirty hacks. Post-race analysi…
May 22
DIY Robocars via Twitter
DIY Robocars @ Circuit Launch, 3/7/2020 https://twitch.tv/diyrobocars
May 22
More…