My Pixhawk is installed on Mariner quad (500). With the version 3.2 it has many nice flights, with very good ALT Hold control and AUTO flights.
After recent upgrade to 3.3.2, it changed its behavior: in Stabilize all is OK, stable and smooth control, hovers on 50% Throttle. When switch to Alt Hold, it starts rising up at full throttle! When switch back to Stabilize, all is OK with the control. Sometimes the rise up is hard to compensate with the trottle....
Looking at the logs, all seems OK, except the inconsistency in the IMU - accelerometers 1 and 2 shows different phase after switching to Alt Hold.
Do you have any explanation? Hardware fault or 3.3.2 software bug?
The last test flight log is enclosed.
I did another test with the same hardware - Pixhawk and Mariner frame.
The ALT_HOLD did same wrong behavior - immediately after switch to ALT_HOLD, the copter rises full throttle up, until switched back to stabilize. Unfortunately it looses height fast and is very hard to keep in air without crash...
The Auto Analysis gives IMU Mismatch = FAIL - Check vibration or accelerometer calibration. (Mismatch: 2.30, WARN: 0.75, FAIL: 1.50)
Can be seen the vibrations at the moment I switched to ALT_HOLD, but this is result of max throttle and vertical acceleration.
I have decided then to change the hardware from another copter, very new Pixhawk.
After the tests with the same Mariner frame the result is still full throttle up on ALT_HOLD. The Stabilize is pretty good and smooth even in high wind.
Cannot find solution. Same Pixhawk controllers had very good ALT_HOLD in the previous APM:Copter version 3.2.
This is a bit unusual. IMU1 and IMU2 suddenly diverge. This looks like a sensor error to me or perhaps it's some kind of weird vibration aliasing that's only affecting one IMU.
So the question then is what can you do about it? It could simply be a hardware problem with the flight controller board so you could replace it. Alternatively you could turn off one of the IMUs using INS_USE or INS_USE2. My guess is setting INS_USE2 = 0 will resolve the problem but you could try turning off INS_USE = 0 instead (of course one of either INS_USE or INS_USE2 must be 1).
Copter-3.2.1 only ever used one IMU (the MPU6k) which is why you're only seeing the problem with Copter-3.3.
Indeed, it's very clear that your vehicle is suffering from the same sensor failure. i've replied back on the Copter-3.3-beta testing thread but you might want to try to do an RMA with 3DR. They did have a manufacturing issue about a year ago which caused the MPU6k to be fail intermittently. It's possible that even if you purchased the IRIS a few months after Feb 2015 that you still got a bad one - it depends upon how long the IRIS was held in stock before being shipped.
The log you analyzed (Test_ALT_HOLD090115.bin), is for replacement, brand new Pixhawk, but the results are exactly the same.
Will try to switch off one of the IMUs.
Probably intentionally the IMUs are with different phase readings, to calculate more accurate results for the vertical position. It will be good idea to implement this calculation in the new versions.
No problem. It was a slightly more interesting log than most.
If the log I analysed is from a 3DR Pixhawk then I think you should definitely "RMA" it to get a replacement from 3DR. Few other manufacturers will replace a bad board for you. I think that's one of the perks of buying from 3DR so you might as well take advantage of it.
I have another controller, recently bought from 3DR, and will test and let you know. But seems, that there is software solution, using data from both IMUs.
Well, the software solution is either to turn off the bad IMU or with Copter-3.4 to better detect which IMU to use or not use. Neither of these software solutions is as good as having a board with two reliable IMUs.
Yes, you are right! But seems still a lot of controllers suffer same issue.
I will look as option to repair one of my old controllers, will change the IMUs.
Looking on the first Randy's picture, the IMU2 gives the negative acceleration values, so you are right, that is the correct reading!
Will try to test with disabled IMU1, once the rain stops ;-)
And I guess you've seen the comment from Greg Fletcher on the other thread reminding people that this is likely caused by the buzzer. Sorry, this issue totally slipped my mind even though we added it to the wiki (see warning in pink) the last time this happened.