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
perfect so at least the Devs know. Everybody wins then.
Hm...my original Pixhawk (bought at Kopterworx) is from February 2014..showing no sign of bad accel ,but Whitespy RTF Hawk is from May 2014 and of curse problem is here, just siting on the ground...did they have you production process before you?
"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."
Craig was only referring to genuine 3DR boards manufactured between July 2014 and January 2015. They would have no control over boards manufactured by Whitespy or any other third party. Boards manufactured by 3DR and sold by other vendors would be effected. While the design and tooling may have been copied by other manufacturers Quality control would not be something that could be as easily replicated.
Boards manufactured elsewhere certainly may have defects outside this time frame that replicate this or other problems.Those individuals experiencing problems with boards not manufactured by 3DR should either contact that manufacturer, or the retailer they purchased their boards from.
Regards,
Nathaniel ~KD2DEY
Lol, I guess most of the boards are made in the same place by the same people :)
@Artem
Very true.
And most of the times using the same components, which components are manufactured by a different company
As far as I have been reading it looks like all the related crashes where MPU6K failures.
And is the mentioned maufacturing process affecting only the MPU6K or both IMUs?
If you look in the list of logs I posted earlier you will find several cases showing a problem with the LSM303D.
We had problems with early versions of the board (2.4.2 and 2.4.3) that only had the LSM303D fitted and it would fail in flight so we added the MPU6000 to the board in Dec of 2013 to make 2.4.4.
The manufacturing process affects only the MPU6K. On the LSD303D, the SPI and I2C busses share the same pins. The problem we encountered is that it would interpret SPI commands meant for other devices on the bus as I2C commands for it. After contacting the manufacturer we found out about some hidden / undocumented registers that would disable the I2C bus and setting those registers resolved the problems with the sensor.
Hello Craig Elder!
Here is another video from APM Planner 2.0 on Mac OS X Mavericks, and the same problem.
https://www.youtube.com/watch?v=93C4UIJdXy0&feature=youtu.be
Did you buy that Pixhawk from 3DR or is it a clone?
I'm curious to know if you are reading the instructions.
Please have a read of the wiki
http://copter.ardupilot.com/wiki/common-apm-board-leds/#pixhawkpx4_...
A lot of us have put quite a lot of effort into the wiki and the instructions. It is always a bit disappointing when people make the effort to post a video that their Pixhawk is damaged instead of reading the wki. If you do have a read you'll find that sound means you don't have an SD card installed.
http://dev.ardupilot.com/wp-content/uploads/sites/6/2013/06/NoSDCar...
I know we ship the boards with the card installed.
Now that you have demonstrated that your Pixhawk is working correctly, how about changing the name on the video?
Thanks
Hello everyone!
I will count my bad experiences with the Pixhawk flight controllers; bought in date October 13, 2014 and January 14, 2015.
With the first flight controller purchased in date October 3, 2014, I could make five flights in Stabilize mode but with many difficulties because during the configuration through the mission planner, I received many messages of error "bad accel health" and then the sixth and last flight made, my pixhawk collapsed and fell to the ground, so I decided to sell it and when the buyer used the pixhawk, he felt a big disappointment (the pixhawk flew unstable and uncontrolled), so I had to return the money the buyer and from that moment I realized that the first pixhawk was defective.
With the second pixhawk purchased as of January 14, 2015, I could make three flights with AC3.2 release, and when the quad was beaten by the wind, this in turn rose sharply upwards and then downwards giving jumps uncontrollably, I made several adjustments to the settings by mission planner and I can not solve the problem, so I decided to save the pixhawk and buy a VR Brain 5.2 of VirtualRobotix to rule out the possibility that the problem it was because of my frame or AC3.2 firmware release, but thank God, is not it, my Quad works seamlessly with VR Brain 5.2 and firmware AC3.2 release, AC3.2.1-rc1 and AC3.2.1-rc2, is a solid and quiet as rock in the sky, but the connection system of flight controllers VirtualRobotix are not to my liking, for this reason I prefer the system connection pixhawk and today decided to pull out my closet the pixhawk and make various settings, but to connect the pixhawk a mission planner, this would not start, I made several attempts with other USB cables and no success, right now my pixhawk is dead.
I really like the pixhawk by their physical characteristics, connection system and its integration with the arducopter firmware, but I lost confidence in them.
Any suggestions or help with this?
Thank You!
15-01-26_12-17-04.bin
-
26
-
27
-
28
-
29
-
30
of 46 Next