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
In my opinion this looks like a hardware failure. Could be the MPU6k but RCin also looks strange on channel 4 in the first log and the gyro values on the second log ?!.
And Randy and Tridge stated quite clearly that the MPU6k failing is most probably a hardware failure...
I think you should have your board replaced...
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!
AutoTune, of course.
Looks like an ECG, and you even wrote that you did AutoTune.
Sorry for confusing...
I get this, as does another guy on RCG FPV UK thread. I thought it a temperature, condensation or FW update related problem, but sometimes even with a long time for temp to stabilise (it's around 2deg.c outside at the moment) it still wouldn't arm. I have taken to disabling the safety check and flying regardless. I'm on Pixhawk and the other chap is on a mini APM I think.
There is still some confusion and a lot of people asking the same questions.
As it is affecting quite some people, let´s try to clarify the issue and perhaps
@ThatJoshGuy
could append the approved findings to the starting post of this thread if that´s possible.
So we could divide speculations (may they be wrong or right) from facts.
I´ll try to start, please correct me if I´m wrong.
1. Which FCs are affected?
The issue only affects Pixhawks, Pixhawk clones (Fixhawk, RTFHawk, HKPilot32) and derivates(DroPix,...) as they have two separate IMUs onboard.
APMs of any built are not affected by this issue!
As Andrew Tridgell stated the issue could be related to different failures, the MPU6000 (IMU1) or the LSM303D (IMU2 + Internal Mag) failing.
As the ThatJoshGuy in the Starting Post explicitly stated IMU2 failing and as the MPU6000 was used for DCM in 3.1.5 in my opinion we should concentrate on the LSM303D failure. The MPU6000 failing would have casued issues in 3.1.5 also.
2. What are the indications of the LSM303D failing.
LSM303D is appearing in the DataflashLogs as "IMU2"
If it fails the Pre-Arm-Checks will report "Accels not healthy" in Mission Planner.
The Dataflash-Logs will show values for IMU2.AccX, IMU2.AccY, IMU2.AccZ which are far off and seem to bee constant e.g -80 in the original post.
3. Why has´t this been discovered before 3.2
Before 3.2 the values of IMU2 where neither used nor logged. That´s why the issue has only appeared in 3.2.
There is no way of finding out if the IMU2 was failing before by analysis of old logs.
Speculations:
- Temperature or changes of temperature could cause this.
There have been many reports on this, but obviously it´s difficult to be sure.
An if it´s related to temperature the question remains if it is the temperature directly influencing the sensor or the electronics around the sensor or even affecting the PCB/Sensor physically e.g. bad soldering joints,...
Especially as there have been people reporting having errors under normal temperatures it is certainly not the only cause.
- Sparks when connecting the battery.
- Power Source (PowerModule, BECs, USB)
For some people it seems to work, but no reproducible results for everybody.
Questions:
- If this is a hardware failure of some kind, will it be possible to come up with a testing routine.
- In my logs in case of failure I have seen constant ACC-values, very noisy Gyro-Values on at least one channel and quite normal mag-values. Does this mean that is probably the sensor itself which is failing and not the surrounding electronics or the connections to the PCB?
- Andrew Tridgell wrote about Mission Planner reporting "Gyro Failure". Was this a typo or is it related to the MPU6000 failing. In my case it´s clearly stating "Access not healthy"
Have a nice weekend and thanks to everybody for improving this incredible platform.
great nils
i hope this problem will be resolve rapidly in a next release
@titeuf007,
Please do not assume it is a software failure. The MPU6k failures at least are hardware failures.
randy:
how could you be sure that is not a software problem?
I had also the accel health issue with 1 original Pixhawk and a clone as discribed in that threat.
Since I use an antispark plug on plus pole (waiting for about 5secs untill complete plugin) I haven't had this issue anymore with around 15 flights.
Hopefully this info may help.
BR
Harald
I will give it a try, thanks Harald !!!
That's probably why the stock XT150 on the S900 are spark proof...
Regards,
Pascal
-
33
-
34
-
35
-
36
-
37
of 46 Next