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?
Can you please take a photo of the side of the PCB that has no plugs? I want to see exactly what sensors are fitted.
I don't mind doing that myself, but you'll need to walk me through the steps. I'm trying to follow the steps on this page: https://pixhawk.org/users/serial_connection but i'm not getting very far.
I installed the PX4 toolchain for windows. When I connect to the PX4 serial port via USB (57600,8N1) in Teraterm, I get a bunch of garbage characters on the screen. I guess it's just spitting out mavlink messages?
Same problem if I try connecting via TELEM1 (which is UART1, I think?), although I'm doing this via a 433MHz radio link.
I'll try via an FTDI on TELEM1, but I need to completely disassemble my copter first for this. What I don't understand is, how will the pixhawk know not to spit out Mavlink messages on these ports?
Tried connecting Teraterm via Telem1 and an FTDI, but no dice. I can connect to the COM port, but no sign of life. The pixhawk beeps like crazy (+/- 10 rapid beeps followed by a short pause -- low battery? - it's powered via the FTDI).
According to https://pixhawk.org/users/serial_connection I should be greeted by an nsh> prompt in the terminal.
Any ideas what I'm doing wrong? I'm not sure I'm connected to the right port - the setup section on the above webpage about which port/uart I need is confusing me...
OK, i'm an idiot.
I just realized I can get into the nsh shell via the "test" menu in mission planner's terminal. However, I'm not getting the failure right now. I may need to wait til later this afternoon when it cools down a bit.
Fast temperature changes is something what sensors don't like - for example baro can show you big alt changes (even with correct code for temp compensation). This is reason why I am trying to power board and then let it for a while to heat itself to some stable temperature,
But this could be point - internal generated heat can be jump in temperature of sensor what will make problem to pre arm check. If I put BT module on, it generates heat faster and so it make problems more often. Or when someone take copter from heated car and try to arm, it can change temperature in opposite way,
What about some kind of "temperature change" check during initialization ?
OK. I got the failure again. The first time I connected via MP's terminal, I got screenfulls of garbage characters. Tried a few more time and got into the nsh shell. Screenshots of the command results are attached (I can't copy-paste text from MP's terminal -- is there a trick to this?)
Only thing is: when connecting via the terminal, the pixhawk resets and the status light does not work as per usual, so I have know way of knowing for certain if the sensor failure is actually occurring by looking at the light. (It very likely is, since the other 5 "regular" startups I did get the failure)
I can do this, but I need to totally tear down my quad for this. Maybe I will do it this weekend. What are you looking for specifically?
Hi, I have recently had an interesting mid-flight failure with AC3.2 and Pixhawk.
Basically closer to the end of the flight both IMUs Z axis went mayhem while X and Y remained sane. Not sure if this is related, but would would appreciate Mr. Tridgell taking a look at it just to determine if it could be related, as right before the flight I had experienced bad_accel issue, it took me about 3-4 power cycles to pass the checks. Anyways, issue is more thoroughly explained here: http://diydrones.com/xn/detail/705844:Comment:1869597
I have been facing a similar problem. But in mine it says 'Bad Gyro Health'. I am sure I have done all the steps properly but it is never passing the PreArm Checks. Also the it is taking time to get a 3D GPS Fix. There are GPS problems in the part of the world I live, but 4 sats? That was never the case.
Please throw some light on this issue. Logs attached!
So, the mystery deepens. My Pixhawk is suffering with this issue and I have a log uploaded on this thread showing the IMU discrepancies on XYZ axes...
It has now got to the point where it will fail prearm checks the majority of the time with bad accel health.
However, whilst fiddling yesterday I worked out that when powered via USB (not lipo) it will pass pre-arm checks. As soon as I unplug the USB plug and plug the lipo in it fails pre-arm checks. I did this 5 times in a row with the same results?
yep, it never has acc problems when powered through USB or when USB is connected even if the main lipo is plugged in. Also, I can say that putting a 5.4v BEC on the RCIN input (basically plugging an extra BEC for servos/retracts into the RX with power wire connected to the Pixhawk) will NEVER pass the acc precheck. As soon as I unplugged the power wire from the Rx-pixhawk cable I had issue only once in a cold environment. Also, it seems that changing MPU6k filter frequency will contribute to this issue.
EDIT: I will try powering pixhawk with 5v and a bit less and see if the problem could be somewhere in the Pixhawks internal voltage regulation (as APM's 3.3v reg)