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?

Views: 53642

Attachments:

Reply to This

Replies to This Discussion

How common is this (bad gyro)?  And does this issue become more apparent between AC 3.1.5 and AC 3.2?  I did not notice these issues on the earlier FW, but I do notice it a lot on the AC 3.2 since upgrading (like 50% of the boot-ups).

So, since the MPU6K failures are somehow "resolved".

What about the LSM303D.

Are there genuine 3DR Pixhakws with IMU2 Errors. I think Tridge stated that it´s only(?) clones.

And is there any way of knowing if it is a definitive hardware problem.

Joe, this is not a firmware issue, this is a HARDWARE issue. why it was not apparent on AC3.1.5 or earlier is because there was no testing done in the firmware. AC3.2+ has those checks in place this is why the problem boards have 50/50 chances of exhibiting the issue. I actually was able to almost get rid of those messages by powering pixhawk with a very "clean" 5.3v, but since I heard that it can happen mid flight I have taken off the problem boards and trying to RMA them. Some were purchase back in February some in August. My cousin had an unrecovered flyaway into ocean back in July of his original 3DR Pixhawk on AC3.1.5 w/o apparent cause. I wonder now if this issue could have been the reason, but since than no logs and the pixhawk is somewhere on the bottom of Bodega Bay in CA along with $1k+ copter. It was a workhorse machine which flew 7x 6Ah worth of lipo that day and many more since it was built in June 2015. 

Joe, your statement needs a bit of clarification

I think you guys are confusing cases where the sensors detect a problem with the setup in the vehicle with the case where sensors themselves failing.  In both cases we report the problem.

It is really important that you guys understand that you can have gyro / inertial nav problems with any version of the firmware.

We have learned how to detect problems and provide warnings rather than just having people arm and then have crashes. When you see the warning messages that means the sensors and the autopilot are dutifully doing their job and detecting and reporting errors.  That means you should fix something with your setup, not question the messager and say the autopilot is not working correctly.

If you are getting a message about bad gyro health then you have some issue where the gyro drift is too high.  It might be voltage related. It might be temperature related. It might be caused by bad GPS. There are many possibilities.  The autopilot is doing it's job to tell you something is wrong.  It is up to you to look at the logs and figure out what is wrong.

If you get a message about a sensor failing, that is different kind of problem but again the autopilot will tell you there you about it.

Well this is very disconcerting to say the least.

I have limited my flights to "over-land" for the most part (though I did fly around a large pond recently).  Any fly-away or uncontrollable flight is very saddening, especially if it results in a crash or complete loss.  My pix machine has about $1800 into it, and to be honest, I have never been extremely happy with the flight characteristics, programming, and tireless hours I have spent "tuning" this machine compared to my DJI F450 with NAZA V2.

I have to say though, I did have four really nice flights over the weekend when I upgraded to AC3.2 (especially liked the characteristics of the POSHOLD flight mode).  But all the boot-up errors between the flights seemed odd to say the least, again it didn't give me the warm-fuzzies like my NAZA V2.  I have close to 300 flights on my NAZA V2 machine with only one unexplained flight crash (likely due to interference between a GoPro WifI signal turned on by accident prior to the flight).

I've spent a lot of time trolling the Internet trying to really understand the characteristics of the Pixhawk, as far as setting it up, analyzing data logs, tuning, etc. (it's the electrical engineer in me, so I understand much of the programming, electronics, wiring, etc.).  Also, I usually try to eliminate / troubleshoot cause and effect issues by making only minor changes one at a time, but the Pix just seems to eat-up a lot of my time (like trying to get the MinimOSD to update the FW and characters, communicate with the Pix, etc.) .  I spent close to five hours screwing around with the MinimOSD just trying to get the characters to show-up right and to receive Mavlink data (to that end, why the heck would the SR0 / SR1 settings change between boot-ups on the Pix)??  I'm just about ready to pull the Pix from my bigger machine and put it on a cheap little quad.  Parts are getting expensive...rant, rant, rant.

I'll see if I can get my retailer to trade-out my Pix hardware (wrote a quick note to them), but I'm not expecting much...

Craig - I am going to PM you as my post below you is actually to Artem, yours just came in sooner.  Sorry about that.

about minimOSD firmware: flash the r800 firmware found here:  http://diydrones.com/forum/topics/adding-extra-functions-to-minimos...

just flash the char flasher first, than charset itself and only than the copter firmware. 

Oh, I did that (FW r800).  That's what led me to more than five hours of screwing around with the MinimOSD.

I did the Character Flash first, then the Copter Firmware.  That led to issues with my SR0 and SR1 settings in the Pix.  The OSD worked fine with my original Pix settings, but for whatever reason, I was getting the dreaded No Mavlink Data.  Why the heck would it work, then not work?  I got it figured-out (from here: https://code.google.com/p/minimosd-extra/wiki/APM).

Then, sometimes the panels would update with the "OSD text" location change I would make, then sometimes it would not.  On my particular OSD (genuine 3DR), I have to power-up both the analog and digital side (and even in the right order), and then there's only a 10% chance the any change will take place).  Then other times, the OSD would just be blank (extremely frustrating to say the least).  And yes, I am using Panel 1, Panel 2, and no panel via a three-way switch on my TX.  Seems to be working nicely, but it sure took a long time to get from Point A to Point B...

oh, SR0/SR1.... those are erroneously zeroed out in the 3.2+ been this way since the RC1.  honestly, minimosd needs a better wiki to explain the process. I kind of figured it out faster, since I never new about r800 and used whatever firmware was in the wiki downloads and there is a guide on how to set up those.  it took me about 10min to setup everything, however I "discovered" the r800 only about a month ago. just flashed that one and am using that one since than on all copters.

I have been having the same problem, could this be anything to do with a faulty batch of Pixhawks that was mentioned somewhere else?

@Craig Elder

You mentioned inertial nav errors. Is that related to this thread?

http://diydrones.com/forum/topics/csgshop-neo-m8n-is-giving-pm-erro...

  

DG,

I should be more clear.  The PM message's long-loops error is a red-herring.  The inav errors are likely a real problem. I don't know why in your logs it keeps having problems.  Rob apparently looked at your logs and the GPS seems to be updating at the correct rate.

I know others that get these errors in large numbers in flight along with the twitching/drifting. The errors are consistent (every log since using 3.2), but the twitching is more random with varying severity. Nobody to my knowledge has yet explained what they mean, and I cannot find any reference in the Wiki documents.

Many people are switching to the more advanced GPS units such as the M8N because of the better Nsat/hdop capability so I think it is very important to know if there are communication issues with them and Pixhawk. I'm beginning to think there is, and will switch to the 3DR GPS LEA-6 to see if the error persists.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service