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

            • You can check it by selecting for example accx from both IMUs and compare their readings. When mine is misbehaving, it shows constant +57 value as the working one shows changing values around zero. I'm sure other kind of anomalies are quite clearly also visible, if there are sudden value jumps and so on..

              Mine seems intermittent, imu2 could work just fine on another boot.. Havent got enough data to tell if it happens during flight yet.

              • Are you saying only accel x acts up and not Y and Z? It's very strange that rebooting can clear the problem. Of course, I am not privy to the root cause of the failure, the manufacturing process that Craig has alluded to.

                Your point is also valid. Once one gets a clean boot, will the accels behave properly until the next boot or can they go South?

                • All axis behaves the same way. I just put the x as an example.

                  I haven't been able to do good flight after I enabled full logging so it's work in progress. But the LSM has behaved that way when I connect it to usb. On some connection all is fine, the other it has failed. Same with battery.

          • Thank you for the detailed response! So it seems in my case who ever assembles rtf boards has probably some trouble in the line with LSM chips.

            Shouldn't it be just fine to fly with the working mpu6000? Now it's only possible if I switch off the boot time check?

            One more time, so these damaged chips are not totally dead, as they seem to work part-time (at least in my case)? Was that also the case with mpu6000 or were they totally dead? I'm sure you understand the confusion as the chip seems to have mind of it's own..

            • Developer

              Again I see no evidence that there is anything wrong with the devices themselves.  In the manufacturing process the solder that holds the chips to the board is fractured. Some times there is a connection and sometimes not.

              >>>Shouldn't it be just fine to fly with the working mpu6000? 

              No.

              Well I guess that depends on how much you value your vehicle. At some point it is going to crash.

              • My bad, I just understood that manufacturing process could have broken the chip but it was just a joint.

                I do value the vehicle and I'll of course try to rma my board as it seems clearly have a problem.

                Asked that because I thought one is main accel (mpu?) and second one a backup (lsm?).

              • You are writing that Tridges log summary shows "more" failures of the LSM303D with clone boards. Do you mean more LSM303D failures than MPU6K failures with clone boards?

                I think I haven´t found one statement of LSM303D failure with genuine 3DR Pixhawks.
                So is there any significant number of genuine 3DR Pixhawks with LSM303D failures.

                I think there are quite some people like me in the line to replace faulty clone boards with 3DR boards and this info would be quite useful as the MPU6K problem is somehow resolved...

      • Craig, how can I see that it is LSM303D failure - because Acc on IMU2 is arround 60 which is out of scale ?

    • I would contact tech support first. You do hav Pixhawk? Not a ***hawk?
This reply was deleted.

Activity