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
This is it
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.
I wonder is this why 2.4.6 board was released? I noticed that if powered by USB pixhawk has no issues whatsoever even in low temperatures (I brought the copter into a walk-in freezer -15 deg. Celsius). In the same I had to reset mine 3 times if powered by lipo first. Also, if powered by both power module and a backup BEC it has much more trouble with acc health. My current solution with which I do not have issues so far for several weeks is: powering pixhawk with power module (verified at 5.13 volt), but power lead goes through a DIY LC filter (thoroid+487uf cap + 2xx uf cap). my retracts and Rx are powered with a separate BEC at 5.6v, and power wire is removed from the SBUS wire. Also, doing all the calibrations via USB vs telemetry radio connection affect how often I get bad acc health on the other model.
Anyway, there are a lot of reports related to temperature.
I didn't come up with a reproducable testing routine. In your massive log analysis did you check failure vs. baro-temperature or change of baro-temperature.
Hi Folks,
in a German Forum someone reported this issue on APM 2.6.
Don´t know if this helps, but still interesting.
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.
With respect,
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.
Regards,
pturcotte
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.
Regards,
pturecotte
Have had the exact same issues last few weeks or so. Hope this issue can be resolved soon!
Hi Guys,
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.
or
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.
Regards,
pturcotte
-
35
-
36
-
37
-
38
-
39
of 46 Next