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
This has absolutely nothing to do with the subject of this thread. Can we please try to remain on-topic? It's not helpful for dealing with the issue at hand, to randomly bring up every problem that has ever happened to a Pixhawk.
I forget what the problem was there, but it is not widespread, and is not in any way related to IMU failures.
Yes, I have the same failure with a genuine (original) 3DR PIXHAWK, and don´t know how to solve it. Its out of 3DR 90 days warranty, so 3DR won´t replace it.
For 3DR not to replace these units that had a manufacturing defect from the 1st day is really unacceptable. Terrible service. If you purchased it within the EU, the warranty can be up to 3 years no matter what the manufacturer states.
Most people including myself have had a really good experience with 3dr customer service. Did you actually call them or just assume your out of luck because it's past 90 days?
The CS wrote sth. like this.: "Yes, The warranty is 90 days and the only and last thing you could do to fix it would be downloading Q GROUND CONTROL and choose Pixhawk4 if this doesn´t not work would just be to buy one."
Sorry for this, but it is related, since some user with IMU errors should keep an eye onto those 90 days.
European custumers like me usually don´t realize this short time period being important.
I recommended my friends to buy genuine 3DR @ that time, and did not know, that there is a big disadvantage, buying this directly from 3DR US.
Its just exactly the same defect, but not out of the box. It needed a couple of months to show up.
And true, if it would have been purchased in Germany , there might be no discussion about a replacement .
I did not read the 3DR US 90 days warranty rule, until this happened, my fault.
(Always reading in the forums "Please apply for a RMA and return it"..so no worries about that, and 3DR replaced the PIXHAWK for my dev. IRIS even without asking for it )
Not to mention the damage and the time waisted. All things considered why do we punish ourselves when one only needs to buy a DJI Product that works every time. I always end up comparing against this benchmark. After all these years we still have this endless saga. When Pixhawk can learn to walk with 100% reliability then that is the time to start being clever.
I wonder what happens when someone spends 20 K on a top of the range mapping X8 from 3DR or even a simple Iris. Are these products being shipped with the same quality control?
"DJI works everytime", that's funny! If you're using DJI as your benchmark you have your standards set pretty low. I challenge you to contact DJI support and actually get a reply! But back to the subject of this thread, 3DR has identified a Pixhawk hardware issue caused by stress testing proceedures. They have corrected the manufacturing proceedure and they are actively working through it. They have identified the manufacturing dates from July 2014 to Jan 2015 as being possibly effected. The symptoms started showing up with the release of 3.2 firmware which does an accel prearm comparison between the two accel chips that was not performed in earlier firmware releases. They have released firmware 3.2.1 which now attempts to resolve the problem. 3DR has stated they will replace your Pixhawk manufactured between these dates if you can provide evidence in the form of a log file showing you have the accel problem. You clowns need to read the entire thread from the beginning and if you suspect you have this issue stop whining and CONTACT 3DR SUPPORT!
If you would like to trade a system that self-identifies a problem on startup, and/or is capable of handling an in-flight sensor failure, for one that cannot, and is also prone to uncontrollable flyaways, then that would be your choice.
OK, in my attempt to gather more BIN / Log files from recent flights related to the this topic, I have since lost my SD card between taking it out of the Pix and getting it to my PC (DOH!) Can someone point me to the right location to re-develop the files that need to be on the SD card so I can make a new one? I can handle the firmware and parameters (settings) part.
Thanks.
-
12
-
13
-
14
-
15
-
16
of 46 Next