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

            • 3D Robotics

              Hi Nathaniel,

              The nature of the defect was stress to the chip during a specific manufacturing process.  All of the boards must pass a sensor test before shipping.  The majority of the time the chips failed out right, but in some rare instances, the chips passed, only to fail in the field.  We tested the boards and temperature does not seem to be a factor.

          • Vu,

            I currently have an open RMA ticket with 3DR for a replacement TX and Pixhawk.  I was informed via email that these two items were currently not in stock.  I assume warranty tickets such as mine will be serviced with new TX and Pixhawk production.  Do you have any estimated time frame for these parts to become available?

            Regards,

            Steve Hayes

            • 3D Robotics

              Hi Steve,

              Yes, all replacements will be with non-defective new units.  We are getting Pixhawks every day so I expect that to be shipped soon.  As for the TX, let me check and get back with you.  I see your ticket in the queue and we'll notify you as soon as stock comes in.  It shouldn't be too long.

        • Admin

          @Nathaniel,

          I was told that any Pixhawk produced from July 2014 on could possibly be suspect.

          Regards,

          TCIII AVD

    • Developer

      Hi Hugues
         Please supply a log of your issue.  if it is anything that looks like a manufacturing issue, we will let you know.  

         For anyone that has an issue with their genuine 3DR systems, you can send an email to help (at) 3drobotics.com

         I am yet to hear of the 3DR help department turning someone away who has a faulty piece of hardware.  they are there to help!

  • Hi, several weeks ago (about a month actually) I had an attempted flyaway and lucky recovery with logs looking about the same as Scotts, except my vibrations went off on only Z axes of both IMUs, while X and Y remained well within acceptable limits. I initially reported on the AC 3.2 beta thread and thought that pos.hold (used at the moment of the flyaway) could have been some how related to this, however after Julien checked my logs it was all pretty evident that pos.hold was not related to this at all. After Julien's conclusion I mentioned my accident on this thread couple of pages ago, but my post got buried away and was left w/o responce. Unfortunatelly I am not near a computer and wont be for the next 24 hours I have to resrt to giving here a link to the original (AC 3.2 beta) thread post where logs from that particular flight is attached: http://diydrones.com/xn/detail/705844:Comment:1869597

    I would really appreciate Mr. Tridgell taking look at my log and say if it is an IMU failure. Thank you! 

    • Developer

      @Artem,

      If you mean 2014-12-31 07-56-37.log, then that log does not have any signs of IMU failure.

      Cheers, Tridge

  • I have recently flown in some cool weather and had a very bad flyaway. The temperature recorded on the pixhawk is not accurate and should be reading about 31F. The first problem was the previous day during a waypoint flight. The aircraft slowly lost elevation as the flight progressed until inches from the ground and was able to recover it. I assume the barometer is sensitive to temperature and caution should be had when flying in cold weather. The following day I had a bigger problem; about a min before it flew away I noticed it developed a slight drift forward. I landed and had a quick check to see if everything was still attached and not loose. After taking off a second time I decided to do a few yaw rotations then bang wiz it was off. You can see in the picture with the flight path the nice arc it made during its rebellion and me switching flight modes trying to recover it.  After collecting all of the parts I was able to review the camera footage and heard the errors as shown in the photos. Many threads before have mentioned that vibration is one of the main causes for a flyaway and I am a believer, but what is the cause of the high vibration or should I say high vibration reading?  At a high level look I noticed the errors started when the vibration was high and then resolved themselves after the vibration dropped.  I have always paid attention to the vibration level when building all of my aircraft and if you look at the logs or the pictures you will see that I am well within the recommended limits for a good duration of the flight. This particular flight is odd in the fact that vibes are good until it gets above 65% throttle then all hell breaks loose. IMU1 & 2 AccX doesn’t track well with IMU1 having the lower values and AccZ is way out of limits. Flyaway took place near line 33600.

    I don’t want to give my interpretation of the problem before the community has a stab at it; I don’t want to corrupt the free thinking  ;)  I have been gathering data here and there when I get a chance and then I noticed this topic a few days ago. I was not sure if I should start another thread or could this possibly be related to the bad Accel health problem.

    Common themes; cold weather, drifting, IMUs’ not agreeing

    Questions for the community:

    Why are the high vibes going on and off like a switch and not gradually increasing with throttle?

    Why are IMU1 & 2 AccX not tracking in the high vibration between lines 33400 35000?

    Do we know the natural frequency of the IMU or the pixhawk board?

    How can we verify Autopilot integrity after a major crash?

     

    Cheers, 3701929026?profile=original3701928725?profile=original3701929101?profile=original

    2015-01-02 12-08-29.log

    • Developer

      Scott,

      I totally agree with your analysis that it's high vibration in the frame which is incredibly bad when the throttle is at full.  So perhaps a motor is in rough shape or a prop, not sure but I think your analysis is completely correct. So this is not an IMU failure which is the main topic of this discussion.

      3702546655?profile=original

      • Randy, 

        Thanks again for looking at my previous log. I was able to find another one of my logs that exhibited odd symptoms. This was an AUTO flight again in cold weather -5 based on the logs. I did find someone else on this thread mentioned odd behaviors/fly away/drift at the same temperature; could be coincidence.

        Just before the crash using FPV I noticed it losing altitude in AUTO (the log not showing it in AUTO for some reason). This one I was not able to recover. I switch to RTL in hopes it would gain altitude (should have gone to manual). You can see that the Acc readings become inverted and and the Alt showing it gaining altitude when in fact it was still going down hence the CRASH_CHECK.

        I inspected the aircraft while in the field without resetting the Pixhawk and everything looked fine, no damage to the props or motors; intent on wanting to keep flying I took off and did some high speed passes without any issues. It does however seem that from this point forward is when I started having major vibration readings and believe lead to the flyaway that I posted earlier. notice the 66.80 AccZ, I have a very hard time believing this is reflecting actual conditions. 

        Can you explain the cause of the inverted vibrations and altitude increasing just before it crashed and before I land? 

        DAlt flat lines in stabilize mode is that normal?

        I have attached two log files, 2014-12-31 13-52 is the crash described above and and 2014-12-31 14-20 is another flight that has similar altitude and vibrations issues at zero throttle. 

        Cheers, 

        3702686289?profile=original

         

        2014-12-31 13-52-28.log.gpx

        2014-12-31 14-20-32.log.gpx

This reply was deleted.

Activity