Pixhawk BAD ACCEL HEALTH APM 3.2 - collecting data

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:

3691166950?profile=original

and here are the same values on the second attempt, pre-arm.

3691167027?profile=original

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?

goodlog.bin

badlog.bin

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Hi,

    I´m from Brazil, work as a parkranger in a National Park and trying to build a fixed wing to map the illegal logging and hunt. To do this I had travelled to NYC in octuber, 2014 and purchased the components from 3DR (pixhawk Kit) and from rmrc (penguin finwing and eletronics). But I´m having some issues with pixhawk since june 2015 and had to stop the project.

    Looks very similar to the bad gyro accel relationed to this post. I have already tryed a reply to 3DR for a replacement, but they sayed that my guarantee has expired.

    So, is just me now...

    How can I detect the real problem with my board so I can fix it? I have put all the eletronics aside, and I´m using just the Pixhawk direct conected through the usb in my Notebook to eliminate other possible causes to the problem.

    The Problem: The Mission Planner shows the horizon aligned, but when I move the board to simulate a flight and put it again in the table, the horizon don´t return to the normal aligned position. When I tryed to calibrate the accel, all times it fails.

    The one time I have success in calibration was when I´ve turned OFF the accel IMU2 in parameters configuration. But even then, the horizon is slow to return to the aligned position when put the board back in the table.

    Please, I need some help! Craig Elder, Andrew Tridgell, someone?!!

    Best Regards!

    2016-06-22 00-52-14 - before calibration IMU2 on.tlog

    2016-06-22 03-26-19 - after calibration IMU2 off.tlog

    • Hi Leonardo,

      I would set ins_use2=0. This can be done in the full parameters list, or the full parameter tree. After that, try power cycling and then redo your accel calibration. When you apply the power, try to keep it motionless. The flight controller does a calibration when the lights alternate red and blue, but the IMUs themselves may do a self internal calibration at powerup (which would be the instant you apply power), although I'm not sure on that. Whether this is a factor in your horizon problem, I do not know. But the ins_use2=0 should allow you to operate normally on only one IMU. If you get "Bad accel health" errors, uncheck the INS check in arming checks

      edit upon reading your post again, did you already try the ins_use2=0?

  • Can someone possibly tell me if I have experienced the IMU problem reported here.  I have a genuine Pixhawk that I bought second hand.  I had one successful flight.  Then in my second flight the hexacopter immediately started spinning in stabilize mode until I was able to crash it "safely".  I have been able to fly it a couple times since and not had any problems. However I "randomly" get error messages about accel health.  I say randomly because I started to possibly correlate them to a particular 4S battery (brand new).  I was having trouble with this theory and then I stumbled on this thread about faulty IMUs

    I'm really at a loss here.  I've spent 12+ hours trying to figure this out.  I really want to trust this new copter!  Any help is super appreciated!  Thanks!

    Calvin

    16-03-07_17-23-36 CRASH SPIN.bin

    • Try shorting out the power module connector before each flight.  It fixes problems by zeroing out the bus voltage inside Pixhawk so that the bootup process initializes the gyros and accelerometers correctly. It can help with intermittent compass issues too.  It's the only thing that gets me back in the air.  I made a jumper using an old battery plug to make it easier.  Plug it in for 10 seconds, remove it, plug in the battery.

      Shorting_Plug.jpg

      • Kelly, it is not reliable workaround. Look here for proposed solutions: http://diydrones.com/forum/topics/solution-proposal-for-pixhawk-imu...

      • Thanks I will try this - sounds like a good practice. I have done 9-10 more test flights. All have gone very well. However, each time I plug in this particular battery things go wrong. My latest try also resulted in random behavior and a controlled crash (haven't looked at the log yet). I certainly won't be using this battery again! I only tried it again to verify if it was causing a problem. I find it strange that I haven't been able to find anything in the forums about something like this. I really want to know how a faulty battery could be messing up everything. Is it producing unusually high EMI?
        • Unsure about your battery and cause of crash, but in case your "Bad accel health" is related to IMU2 then here is a detailed description of problem and proposed solutions: http://diydrones.com/forum/topics/solution-proposal-for-pixhawk-imu...

          You don't need to short out power module connector. It is improper workaround.

        • Batteries definitely produce large amounts of magnetic interference, particularly at the cable end - and they all vary in how much. You can probably test this by running compass_mot

  • same issue here with a clone 2.4.5 board, all calibrations and arming great in the house, go out in the cold and it fails now and then, get home and its good - maybe should calibrate out in the cold ?  

    • Just gotta run out there and arm it before it goes bad ;) That's what I've been doing. Make sure to set ins_use2=0 so when it goes bad mid flight...

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @SahikaGenc: AWS DeepRacer & Hot Wheels Track https://youtu.be/4H0Ei07RdR4 via @YouTube
Monday
DIY Robocars via Twitter
Sep 8
DIY Robocars via Twitter
RT @davsca1: We are releasing the code of our Fisher Information Field, the first dedicated map for perception-aware planning that is >10x…
Sep 8
DIY Robocars via Twitter
RT @SmallpixelCar: How this works: 1)object detection to find cones in single camera image, 30 frames/sec on @NVIDIAEmbedded Xavier. 2)comp…
Sep 8
DIY Robocars via Twitter
RT @SmallpixelCar: Use two color cones to guide the robocar. No map needed, on onsite training needed. Just place the cones and it will fol…
Sep 7
DIY Robocars via Twitter
Sep 7
DIY Robocars via Twitter
RT @roboton_io: Great to see http://roboton.io running at 60fps on the cheapest #chromebook we could find! #edtech #robotics #educat…
Sep 3
DIY Robocars via Twitter
RT @openmvcam: Crazy in-depth article about using the OpenMV Cam for Astrophotography: https://github.com/frank26080115/OpemMV-Astrophotography-Gear https://t.co/BPoK9QDEwS
Sep 3
DIY Robocars via Twitter
RT @openmvcam: Hi folks, it's finally here! Our first draft of our Arduino Interface Library is out! It works over SoftwareSerial, Hardware…
Sep 3
DIY Robocars via Twitter
RT @chr1sa: Please let them have an open API. This would be perfect for @DIYRobocars races https://twitter.com/NintendoAmerica/status/1301513099707658246
Sep 3
DIY Robocars via Twitter
RT @SmallpixelCar: Lanenet pretty much used all my GPU power on @NVIDIAEmbedded Xavier since I optimized with tensorRT. I need to run anoth…
Sep 3
xemone liked Max Gilson's profile
Aug 31
DIY Robocars via Twitter
RT @LyftLevel5: Our @kaggle competition on Motion Prediction for Autonomous Vehicles is now live! Experiment with the largest-ever self-dri…
Aug 24
DIY Robocars via Twitter
RT @chr1sa: Our next @DIYRobocars virtual AI car race will be on Sept 26th. Sign up here https://www.meetup.com/DIYRobocars/events/272786977/ https://t.co/UENKGSOWO8
Aug 24
DIY Robocars via Twitter
New ready-to-run @NVIDIAEmbedded JetRacer car from Waveshare. Perfect for the next @diyrobocars race as soon as we… https://twitter.com/i/web/status/1297960223013867520
Aug 24
DIY Drones via Twitter
RT @chr1sa: The US government just approved 5 US-made drones for purchase, all based on the @Dronecode @PX4Autopilot standard. Great news f…
Aug 20
More…