Bad Accel Health on Copter 3.3.3

Hi all,

I just got the "Bad accel health" warning in mission planner. I haven't had this problem with my pixhawk before today, and the only change I've done is to remove the top cover of the pixhawk (i'm building a larger case which will hold all my pcbs, onboard computer, etc).

I'm in Norway, and we have zub-zero temps at the moment. Could the low temps coupled with flying the pixhawk with the "roof off" cause this? I'm clearly seeing IMU2 not outputting anything at all.

I know there was a problem related to earlier builds of apm, but from what I understand this should be resolved in 3.3.3?

Any pointers appreciated.

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

Join diydrones

Email me when people reply –

Replies

  • Here is a complete write up of the problem, inclusive of two fixes - either a software correction (on which the developers seemed to have stalled) or an easy hardware fix. (Note that, per this post, the SW fix might not resolve all cold-temperature failures)

    http://diydrones.com/forum/topics/solution-proposal-for-pixhawk-imu...

    Regarding the HW fix, it involves soldering a resistor in parallel (on top) of  a capacitor. It works, and can easily be verified:

    Put your unmodified Pixhawk in the freezer for a while (15 minutes or so). Remove it and power it up. Connect with USB or Mavlink telemetry to your PC. You should see Accel Health failures show in Mission Planner. Note that you might need to apply/disconnect power/reconnect quickly to easily trigger the failure.

    After the HW fix is in place, there are no further Accel Health failures. I have personally modified and tested my Pixhawk, and it works just fine . (as have others on the post  above).

  • Hi, this is a pretty common problem in colder weather. It has to do with the 2nd IMU which is the LSM303D 9 axis acc/gyro/mag. It fails in colder weather (as well as on battery reconnects). Here's a post I made to rcgroups, should help. You'll have to build a firmware yourself, directions are http://dev.ardupilot.com/wiki/building-px4-with-make/  then cut the sections of code I highlight in the links.

    I have some build files for those stuck on that Bad accel health error. I've had a lot of trouble with that error lately in the cold weather and I know others out there are also. Set the parameter ins_use2=0 so the controller doesn't use the second IMU (the one that usually generates the Bad accel health error due to cold or battery reconnects) and hope the first IMU (mpu6000) does not give trouble, and this code will do no IMU accelerometer checks. I basically cut out sections of code that do the accel health checks. Ideally I would have stuck some logic to skip those checks if the INS check is bypassed by the user, but this is just something quick and dirty to get past that error. Tested on my MR.

    ardupilot/libraries/AP_Arming/AP_Arming.cpp
    https://www.diffchecker.com/mtxyeway

    ardupilot/arducopter/arming_checks.cpp
    https://www.diffchecker.com/laxay6uw

    edit I think I had to delete lines 213-215 from GCS_Mavlink.cpp as well but can't remember for sure.

    • Thanks derek, I'll look at your suggested edit. Any reason this is not PR'd into the ardupilot codebase? Seems like a pretty glaring bug which should be permanently fixed.

      • Developer

        I don't think there's a software "bug" so to speak in this case.  I'd say that there's a work-around for what is essentially a hardware issue.

        In any case, while adding support for the PixRacer we added a workaround which ignores the gyro and accel errors for the first two seconds of startup.  If the errors persist longer than that it pops up as a real issue.

        So this work around will be out with Copter-3.4.

        • Agreed, its at heart a hardware bug. There may be a software bug, I'll have to check and see if its still doing it.. but it was giving the bad accel health error even with the ins check turned off (and "all" unchecked as well). Looking at the code I thought maybe

          (g.arming_check & ARMING_CHECK_INS))

          Was supposed to be

          (g.arming_check && ARMING_CHECK_INS))

          But its been so long since I programmed that I wasn't sure if it was just a way of using the address-of operator (pointers) that I hadn't seen before.

          • Apparently it is bitwise and operator. 

      • I'm not sure why the original code doesn't work. It has an if statement encompassing the sections I removed, where the if statement checks if the INS check is enabled (I was incorrect in my rcgroups post to suggest including more logic). I also might have removed more code than necessary (just wanted to gut all accelerometer checks)

        Regarding this statement in arming_checks.cpp

        if ((g.arming_check == ARMING_CHECK_ALL) || (g.arming_check & ARMING_CHECK_INS))

        Maybe someone can help me understand the use of the ampersand in this comparison? Is it the address-of operator? Its been a while since I programmed

  • Hi

    can we narrow down your descrition:

    1. change back to 3.2, the issue still existed?

    2. recover your done with code (remove the top cover of the pixhawk), issu still existed?

    3. move to a warm room to locate the temp intruduced.

    4. move your pixhawk far away other electronics devices, sometimes I found some sensor not work normally too nearby electronics devices.

    • Thanks for replying Xu. I'm not sure what you mean in step 2, could you clarify?

      I'm definetely seeing differences when powering the unit in room temperature. I think taking the lid off cools the unit faster, which is why I haven't seen the problem before.

      • I thought you  removed the top cover of the pixhawk and changed some code.

        so, suggest change back to original.

        Looks you've got conclusion and move to different temperture room and see different result.

This reply was deleted.

Activity