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
@DG, It could be. I see Randy has answered his post over there indicating he is having INAV issues
I have been having the same problem, could this be anything to do with a faulty batch of Pixhawks that was mentioned somewhere else?
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.
Tridge,
Way back on page 4 of this thread, you asked me to do a register dump of the LSM303d IMU. I posted some screenshots, but I think they got swamped in all these replies.
Can you take a quick look at those screenshots, and let me know if there's anything wrong?
By now, I'm thoroughly confused as to the issue. There are lots of relevant and some irrelevant posts in this thread. Maybe one of the devs can post a summary on the front page of this thread.
As I understand, we are talking about two unrelated issues, that happen to have the same symptoms:
1) there is a batch of 3DR boards with a wonky MPU6000. (Are any clones confirmed to have this issue?) This is a HW issue, nothing to do with FW.
Symptoms are:
-erratic acc/gyro (IMU) values in the logs.
-Prearm warning: "Bad accel health" or "bad gyro health" (also "altitude disparity"??)
Fix: Contact 3DR, get a replacement
2) there is some issue with the lsm303d, causing flatlining acc/gyro values. Issue is seen on 3DR and clone boards. 3DR has previous experience with a very similar issue, and it was thought to be fixed with a register tweak. Is this the same issue, or a new HW problem?
Symptoms:
-flatlined acc/gyro (IMU2) values in the logs.
-Prearm warning: "Bad accel health" or "bad gyro health" (also "altitude disparity"??)
Fix: contact manufacturer? install AC3.2.1?
I'm going to chime-in on "jesuis" post above (as I would like to pose a similar question).
I recently updated my firmware from 3.1.5 (new on 3DR genuine Pixhawk around 8/2014) to 3.2 AC (1/2015). I have noticed since updating the firmware, I often get several pre-arm errors that I did not get previously, but in particular:
1) Bad gyro health
2) Bad Velocity
I'm running a genuine 3DR uBlox compass, and I did do a new compass calibration prior to my recent flights on the Pix. I had four really nice flights on the first day after the FW upgrade (other than the arming errors that I simply power-cycled to clear). I have reviewed the logs and nothing stands out as IMU errors, compass / mag errors, etc. Yesterday, I flew one flight (again with a pre-arm gyro error, cleared with a power-cycle). It flew pretty decent, except about 9 minutes into the flight, the hex suffered a slow descent (like no thrust), bounced off the ground and continued to fly (sort of fine until I could land it). I thought maybe a vortex issue, but the descent was so slow, it seemed more like a battery issue.
I review the logs, and nothing. The battery (both Vcc and Volt) were steady (and a recharge of the lipos indicated I had only used about 50% of a 10,000mAh pack). The only error I could determine was from the "Auto Analysis - Test: Thrust = FAIL - Avg climb rate -3.16 cm/s for throttle avg 707). I always take-off in "stab-mode" to ensure my "TRIM_THROTTLE" is updated based on the weight I am flying at (I use a variety of batteries, single 4S, parallel 4S, and a huge 6S). Usually the TRIM_THROTTLE sets-up around 600-640.
Now I did change three items in my parameters this time which may have led to this incident (and may be unrelated to the F/C errors on arming). 1) I tightened-up THR_DZ from 100 to 50, thinking this would provide a smaller "dead-band" around mid-stick for Alt-hold, pos-hold, loiter modes, 2) adjusted PILOT_ACCEL_Z from 250 to 350 thinking this would give greater acceleration for Z-Axis ascents and descents, and 3) PILOT_VELZ_MAX set to 500 thinking this would allow for greater z-axis climb rates.
Perhaps someone could look at my log and see if anything stands out at the 9 minute mark.
Thanks.
119.BIN
AC3_2 2015-12-12 Settings.pdf
A bad gyro health for a pixhawk card purchased between summer 2014 and end of year 2014 could mean, although not frequent according to 3DR, a hardware card issue. Fix : ask for a replacement to your distributor.
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).
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.
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...
OSD wiki is moving https://github.com/diydrones/MinimOSD-Extra/wiki
-
19
-
20
-
21
-
22
-
23
of 46 Next