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: 53647

Attachments:

Reply to This

Replies to This Discussion

Hello Nils,

thanks a lot for looking into my logs. I think I can explain the RC in and gyro values:

- In the first flight, I took off, landed, and took off again. I think the odd "yaw in" values are due to me disarming and rearming the copter.

- In the second flight, I was running the PID AutoTune mode, which yields oscillations in the gyro values.

... so I still think the accelerometer is the main problem. I have already had the board replaced once due to a faulty accelerometer (one axis was not working), and this process takes time, since the board has to be shipped to 3DR before they will send a replacement. I think I will do some more testing before I do so. :) Thanks again!

Good idea, Staq. My original Pixhawk was purchased in September 2014. This one had a faulty accelerometer and was never flown. I received a replacement in January 2015, this is the board which I'm struggling with now. I'm able to arm, but there seem to be in-flight accelerometer errors.

I purchased mine in January 2014 from 3DR in an Iris and it's flawless with 3.2. Over a 100 flights with no issues.

mp

So is it possible that 2.4.6 fixes the issue, looking at the changes between 2.4.5 and 2.4.6 they added a capacitor to "stabilize" the sensors. Sounds like the issue no?

- NEC original tantalum capacitor is added in back compass and main power supply, making each sensor has stable power supplying and lesser possibility of aircraft crashing

Possibly, but I can't tell from that description, sorry. You'd need to ask the vendor.

The logs show the lsm303d isn't initializing correctly. The patches I put in recently try to re-initialise it if it misbehaves, but it looks like that isn't helping.

Cheers, Tridge

@Mark,

I purchased mine in January 2014 from 3DR in an Iris and it's flawless with 3.2. Over a 100 flights with no issues.

I don't see a previous comment from you in this thread - maybe I missed it? Do you have an issue with your sensors with a more recent test firmware that you don't have with 3.2? If so, can you post a DF log?

Cheers, Tridge

Tridge,

I apologize for the lack of information. I have not posted in this thread before but I have been following it since it started. I just started thinking recently that if it's hardware then the bugs could have started in a certain version. Like the old Pixhawks have less issues than the new ones.

When someone mentioned posting the purchase dates I posted my first thread.

I have had no sensor issues in 3.1.4, 3.1.5, nor 3.2. Besides GPS/Compass issues in the first few months of purchase that I remedied the bird has always flown flawless.

I could be way off but from reading the thread I keep thinking that some FCs made after a certain date have this issue and maybe 3.2 exposed it.

mp

AutoTune, of course.
Looks like an ECG, and you even wrote that you did AutoTune.

Sorry for confusing...

Not sure if it is the same, but I logged a similar issue on the support forum here, with logs:

http://ardupilot.com/forum/viewtopic.php?f=80&t=11076

It isn't failing pre-arm checks for me, but IMU+IMU2 have a high degree of variance, and on one flight it lost its sense of horizon by about 15-20 degrees during the flight. The Pixhawk is direct from 3DR.

Hi Andrew,

That looks like vibration induced aliasing to me, not sensor failure. You have an awful lot of vibration, and probably a significant amount of vibrational energy at the 800Hz sampling frequency of the lsm303d.

Once you fix your vibration issues I think you'll find it will behave a lot better.

Cheers, Tridge

Thanks for looking Tridge -- I'll take another look but with vibes generally under 0.1g I would have thought I'm in the clear, do you think it is because of the frequency rather than the amplitude?

Also, I swapped out the Pixhawk for another one and the issue seems to have gone away. I'll keep testing and keep an eye one it, but good to rule out any link to this specific issue.

 Hi All, first post so let me know if anything is out of order.

I have a Pixhawk running 3.1.5 and it seems fine, flies well, vibration levels shown in the logs are well within the recommended range.

Update to v3.2 and the fun starts. Upgrade process works fine, radio, accel and compass calibrations all seem to be OK.

Set the craft on level surface, plug it in wait a few minutes for everything to settle. Arm the craft (no pre-arm errors) and take off.

The craft will roll to the right roughly 20 degrees, requiring full left stick to maintain a stable hover. When the craft is on a level surface the artificial horizon shows in MP the correct output and when moving the craft around all seems well.

I have formatted the SD card and done an eeprom erase from the CLI in 3.1.5 prior to each attempt.

Reload 3.1.5 and the craft returns to a flyable state.

Haven't tried 3.2.1 yet to see if there is any difference.

Let me know if there is any further information I can provide especially which logs may be of use.

Cheers

Justlookin,

Dataflash logs from a problem flight would be great.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service