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?
The 3S Battery is not the problem!
I believe that the 12 S connection for the motor with a spark is effecting the senors when the Pixhawk is already connected before the motor.
Have had the exact same issues last few weeks or so. Hope this issue can be resolved soon!
I know what the issue is, or at least, for now I know how to repeat it...
This is the vehicule.:
- DJI S900 using stock ESCs, motors, etc.
- Castle Creation CC BEC PRO at 5.1V to supply the PIXHAWK and all the electronic.
- Spektrum, TM1000 Telemetry module, Current Module, GPS Module,
- AR9020 + 2 Satellite Receivers
- PWM to PPM converter
- 3DR GPS + Compass
- 3DR 915MHz Telemetry Transceiver
- I am NOT using the Power module.
Details.: I am not using the PIXHAWK telemetry as I want everything on my DX9.
I have downgraded to 3.1.5 and I get the following symptoms.:
1- I connect the vehicule, virtual horizon is NEVER stable on the first time.
2- I have to wait few seconds,
3- then unplug it...
4- reconnect it, sometimes on the second try it is ok...
5- If not, I unplug it...
6- Third time is always the good one... ACC is ok, I can arm and I can fly it...
So far I have always flew it inside, never outside.
Temperature is always controlled and around 22oC.
For now I am using 2x 6S 5000mAh in //. Connecting only the first one to avoid any vibration at bootup and I connect the other one when ACC / "Virtual Horizon" is stable.
Here is what I think and I still need to investigate... I believe everything is related to the supply being unstable at the start-up.
I want to verify the supply at start-up, especially the 5V coming from the Castle Creation. This BEC is BUCK switcher, WAAAAY too overkill for the application I agree. The regular CC BEC is a linear BEC and could be more appropriate. (speculating here)...
It could be a voltage sag, as well during startup while charging all the capacitors.
Do we need to add a capacitor on the PIXHAWK to filter the voltages sags?
Because... I am using EC5 connectors and not the XT150 with built in anti-spark resistor that is included in the S900 (there might be a reason after all :P), it sparks when I connect the EC5...
So, a quick way to test this would be to supply the PIXHAWK with a RX pack without supplying the ESCs, etc.
by simply connect the S900 via the XT150 ( I still have them) this will avoid the sparks during start up...
I will verify it this week...
Keep you posted.
With all the respect, I think this is R&D related.
Do you really think that no one from 3DR reads the posts on this forum...
In all the posts I did these are speculations and assumptions. Nothing has been verified yet.
In the other hand I have connected it in a non standard manner because I was unable to use the power module and it might affect the power-up sequence.
I understand your concern all we have to do is isolate the problem and give enough input to understand how to recreate the problem.
This is R&D and absolutely normal from my point of view.
fair enough, same thing here...
Let me do my homework, come back with results, and then, we will have good results to show. I am sure we will find what causes the issue.
For what it is worth, while I am certainly not as tec savvy as many (most? all?) who post here I wanted to add that fact that I also have the problem and it has kept my IRIS grounded for a couple of months now. It developed after I replaced the power driver board. I will also note that I installed a gps mast prior to the power board replacement but that was working for several flights. Once the new power board was attached (solving problem where prop would intermittently change direction(did the same thing on 3 different motors) ) I first had problems with compasses calibration (would have 2 different assignments), but eventually with the help of this board was able to solve that. Now however the IRIS will not arm due to the error described in this thread.
It has however been cold in Nebraska so most attempts were at or below freezing, but yesterday it got up to 50 deg. and the result was the same.
I hope a solution is in the works.
I think this issue for at least some of the users on this thread basically a hardware issue and not a software issue. So in some ways it's similar to the blown 3.3V regulator issue we saw on the APM2. A new version of the software (AC3.2 in this case) has highlighted a hardware issue but the solution is likely not a software solution.
Tridge has put some effort into a recognise and recover algorithm which has been included in AC3.2.1. This is now in beta testing and it can be downloaded from the mission planner's beta firmwares list. This feature will try to recognise the failed accel and reset/reconfigure it. In my personal testing this works about 50% of the time but I don't have a failed board so I was only simulating the failure.
So my advice for people struggling with this issue is to first try AC3.2.1 and see if that helps and consider requesting a replacement board from your board manufacturer.
in a German Forum someone reported this issue on APM 2.6.
Don´t know if this helps, but still interesting.
After upgrading to 3.2 i can´t arm the copter if temperatures are belov +5 Celsius. PreArm: Accels Inconsistent I had no problems with 3.1.5 when there was -15 Celsius. I have tried 3 different boards. 2x HKPilot32 and 1x original 3DR Pixhawk and all have the same issue with 3.2 firmware. 2 were quad copters and one was octocopter. I can skip the INS prearm check and it flies like a bird but this is not a real solution. I think that this is a firmware bug in the 3.2 firmware because it wasn´t there with 3.1.5. This problem isn´t there when outside temperature is +15 Celsius. I really hope that 3.2.1 will have a solution that works for this issue.
This sounds like a different issue than what's being described in most of this thread. It sounds like you're tripping over one of the IMU pre-arm check but it's not clear which one. If you could enable logging (All+DisarmedLogging) and post it here we can see which pre-arm is failing. Also if you could write down what the message is that's being displayed when you try to arm that will help.
At the risk of being pedantic, it's unlikely to be a "bug" as such. It's likely a false triggering of a safety check because of a high speed temperature change affecting the IMU.