Hi All!

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.

Views: 2043

Attachments:

Reply to This

Replies to This Discussion

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...

Attachments:

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.

Attachments:
Hi bro. I have same as ur problem. I have test 2 pixhawk is the same problem. Fly good with fw 3.2.1 but when update to 3.3.2 then see the problem. when i fly mode loiter theb i change to alt hold or poshold mode then my iris is fly up to sky full thortlle. Dont know what happen :(

Vesselin,

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.

The EKF then chooses to use IMU2 but it's very unsure about it's altitude and climb rate estimates.

..and those altitude and climb rate estimates are clearly off because the baro alt vs EKF alt separate dramatically.

...and the climb rate becomes massively negative (-12m/s) which causes the climb.

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.

TriTran,

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.

Thanks Randy,

First two logs (Test_Alt_Hold2712.bin,Test_ALT_HOLD2812.bin, were on the original controller (RC Timer), I have used for APM 3.2 before.

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.

Vesselin,

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.

Thanks Paul,

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 ;-)

Vesselin,

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.

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service