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
Vu,
Something that might help you and the folks on this thread save time, and keep you from reviewing many logs is share with the community the skill of how you easily identify this issue. I am very interested in knowing so I can continue solving my own problems and keep flying. Can you also provide the effected manufacturing dates?
Kind Regards,
Scott
Scott you can see examples of our investigation of the problem here
http://uav.tridgell.net/MPU6000-error/summary/summary.html
this is a good example of what you will see in a log
Do you see the way the sensor values jump around?
That is a clear indicator of the problem occurring. Basically the sensor gets an offset and then it changes or goes away.
You may see
the accelerometer or gyro values for one sensor jump around,
only one IMU message present,
2 IMU messages present but no accelerometer data in one of them.
Craig, would it be safe to assume that all "flyaways" will have errors in the log? I am asking as I have experience a flyaway previous to the last.After recovering the parts on this one I was surprised that I had zero errors or alarms.
Regards,
Scott
If the copter is set-up with all the failsafes enabled (battery, radio, gcs, gps, ekf) and then it starts flying away and the pilot is unable to bring it back, I would expect to see errors of some sort in the logs.
If the vehicle just suddenly flips and crashes (which isn't a fly-away as such) then errors like brownouts or motors failures wouldn't show up as errors in the logs.
Do you mean an error event?
No. Lots of logs won't have error events in them
Thank you Craig.
Hi Scott,
Thank you for the suggestion. The issue is very apparent if it exists. Either there are NO values from MPU6K or you will see normal values, very erratic values, then normal values again.
Our projections are Pixhawks produced from July, 2014 to Jan, 2015. While we believe the true effected population is smaller than that, we are being conservative to so that customers can rest assured that the issue will be taken care of should they experience it.
Can you define the "specific vintage of Pixhawks" a little more clearly, and is this support/exchange open ended? For example I have a board that I purchased in early October 2014 from 3DR that I have installed in a 2014 3DR Y6B that I only got about 3-4 flights on before winter set in and I won't be able to resume flights until perhaps sometime in May.
Also is there a way to "bench test" the board to try to force the problem to occur without risking the whole craft/personal injury?
Regards,
Nathaniel ~KD2DEY
HI Nathaniel,
Our projections are Pixhawks produced from July, 2014 to Jan, 2015. While we believe the true effected population is smaller than that, we are being conservative to so that customers can rest assured that the issue will be taken care of.
As for the warranty/support question, yes. We will replace all Pixhawks that exhibit this problem purchased from July 2014 and on.
Unfortunately, we don't believe that there's a bench test that will expose this issue if it exists. That was part of the difficulty of identifying it. This is why updating to AC V3.2.1 is critical.
Perhaps the most important change for this release is the improvement to the detection and recovery of bad IMUs. We have had a number of reports of bad IMU data in flight from both the mpu6000 and lsm303d. Where possible the drivers how try to detect the failing sensor and reset it. Sometimes it can't be reset, in which case it will be locked out and the other IMU will be used, unless it is the last available IMU, in which case it will still be used. In either case the user is notified of the failure via the GCS so they can land.
Vu,
Thank you for your response. Are you able to share with the community the nature of the defect? Is it a problem with the chips themselves, or an issue with assembly technique resulting in weak solder joints? Does temperature seem to be a factor?
Regards,
Nathaniel ~KD2DEY
-
28
-
29
-
30
-
31
-
32
of 46 Next