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
I did, but I'm not getting really an answer there or earlier posts. I'm really confused with this. Sometimes it's bad accel, sometimes compass not calibrated and sometimes something else that prevents me flying. But there have been still more successful flights than fails. I have done calibrations really carefully as I had toilet bowling earlier. With current calibs, quad is really solid when it wants to fly.
I would like to know is that IMU behavior "a feature" or hardware failure. I have got the alert also inside the house, not only outside when temp does change.Has anyone confirmed that there is a cold soldering or something like that on the board? There has to be some reason for the another IMU to go nuts occasionally.
Should I try RMA or what?
Seem to be having the same issue occasionally with my DroPix Autopilot board, which is similar to the pixhawk. It tends to happen after a step temperature change. After calibrating accels in the warm workshop then going outside, it will sometimes fail prearm with bad accel health.
I have couple of questions for HW issue arround "Bad ACC health"
- is known what is bad with boards ? Soldering, chip, board design, power problems or something is out of tolerance ?
- is there way how to easily and 100% detect that my board is facing hw issue ? I had problems in cold weather so maybe if I put cooling bags around board ?
- how to setup logging to see what is reason for Acc failure during start
- what happen when new version detect MPU6K failure and do switchover to second Acc. Is this logged as error in log ?
- can Neo8 affect this ?
I am speaking just about bad Acc, there is lot of mixed answers like bad compass/gyro and so...
Which attribute in the log files would indicate the GPS noise issue you mentioned?
Get yourself a ublox message manual and look at the UBX1, UBX2, UBX3 messages in the log. Look at the jamming indicator, the noiseperMS and the receiver gain.
I get what you are saying but there are two things I didn't convey well enough;
1.These same FCs were operating without these errors before the last couple of "plane" FW updates. I reviewed the release notes, and indeed it looks like enhanced error reporting was added. Obvious question: it worked before but now I have warnings. Is it an important malfunction or not?
2. Is there no watchdog or similar to go back and check if the error is cleared. For instance, in your example, the GPS gets adequate lock and HDOP?
So at the end of the day, I want to know if it's safe to fly or not. And if I do fly, what the risks of doing so with these warnings? In other words, is it a "gas is low" and I keep driving or "engine oil" where I need to pull over immediately?
Thank you.
1. The issues existed before. We used to not have the ability to detect and identify them. Now we do. If you are getting a warning now where before you did not then my suggestion is to fix the problem with the setup on your vehicle.
2. That is already built into the system. When the error condition goes away, the error indicator will go away.
>>>in your example, the GPS gets adequate lock and HDOP?
Having GPS lock and a low HDOP are not adequate measurements of the GPS performance. We used to only use those criteria and they are not adequate. There were still times when the autopilot lost control of the vehicle. Now we use the velocity information from the GPS. The most common scenario is there is a lot of interference with the GPS and it reports a noisy velocity that cannot be reconciled with the other sensors.
>>>So at the end of the day, I want to know if it's safe to fly or not
The warnings are there to give you some indication that a problem exists and you should do something about it. If you choose to ignore the warnings there is some risk that you will have a problem. The risk is exactly the same as it was without the warnings, but then there is that day when you have a flyaway. We used to not be able to explain the flyaway, but now we can and we provide warnings when conditions are not looking so good.
If it stops reporting the bad acc health then it's no longer seeing an issue I think?? For instance I often get the 'low hdop' warning but once it stops I'm good to go.
-
17
-
18
-
19
-
20
-
21
of 46 Next