I have a very similar thing happening with my plane on 2.7...... but my plane just lost power and went inverted into the ground on the first time I attempted to use it after several successful autonomous flights, so I have no idea what that means. Having problems with getting the logs off the board in the mission planner, I'll let you know if the airspeed caused any problems.
This has been confirmed (to me) by replacing the uBlox with a Mediatek gps. The instability goes away, the pitch, roll and horizon settle down to normal "stability". My hunch is that they are somehow using the uBlox position data to make an ArduCopter hold position. This has come over to the ArduPlane code and all plane users with uBlox gps's are seeing it. I also went back to AP 2.68 and the same unstable behavior was there with the uBlox.
What's curious is that the uBlox is advertised as a better gps receiver, but I get more satellites and a more stable lat/lon position with the Mediatek.
Gary, there is nothing wrong with the software. This is by design. The issue is this:
If the IMU is all by itself, "blind" to the world around it, it will sometimes get confused. The best example is if you were to fly an airplane in a circle. The centripetal force being created by flying in a circle will appear to the IMU as if the airplane is tipped sideways. All it sees is the acceleration in the Y direction. It does not know that it is actually moving in a circle.
The same is true any time you accelerate or change the direction of the aircraft. It sees the acceleration as a false signal that the APM has tipped over. Previously, this was causing problems with the stability. Generally it wasn't a problem, if you are mostly flying in a straight line, or hovering. But when you start flying faster and turning, it becomes a problem. One of the other developers noticed that his airplane pitched down whenever he went around a corner. I did with my heli too.
So what is happening in the code now is that we use the GPS to detect when we are actually accelerating, or turning. And we artificially "subtract" the calculated acceleration from the g-force measurement. This makes the attitude estimation more reliable and stable. It works very well.
This is why you will see the HUD move around a little bit while the APM is sitting on a table, armed. As the GPS position falsely moves around, the code is subtracting the acceleration force from zero. This makes a small error in the attitude estimation. This should only be happening when indoors. Outdoors with a good fix, the effect should be very small.
Now, why is it so bad when disarmed?
This goes back quite a ways to the days when "leans" was a problem. "Leans" was what happened when we had really bad vibration sensitivity for the APM. Vibes on the accelerometers would make the attitude estimation go bad. After landing and shutting off the motors, it took a little while to get the attitude to level out before you could take off again. To speed this up, they made the accelerometer correction in the AHRS 8 times stronger while disarmed.
However, this has had the effect that when disarmed, the GPS correction error is now also 8 times stronger. That's why it looks worse when disarmed.
However, since leans is no longer a problem, I think we can remove this 8-times effect when disarmed, which will stabilize the HUD when disarmed.
Alexey, the GPS parameter absolutely CAN be used with Arducopter. I strongly recommend it if you do anything other than simple hovering and gentle flight. If you fly aggressively, you are much better off with the AHRS_GPS_GAIN turned on! I have flown my heli and pulled a 3-G turn, with the GPS correction turned off, the heli pitches down noticeably. It's a temporary effect, but trust me, sport flight is more stable and predictable with this turned on.
For the same reason I believe. Pressure fluctuations when stationary make the system think it is accelerating, so it uses a similar compensation scheme as for the GPS. It should not be an issue in flight.
That's a good explanation... So, why does the instability appear worse with the uBlox gps and hardly noticeable with the Mediatek when all other variables are held constant?
I don't know. My guess would be that the Mtek is much more heavily filtered, or simply doesn't get a lock at all indoors. The Ublox, having better reception, might be more likely to report a fix when it doesn't really have a good one. And we might be filtering it less.
Just a guess.
Thanks for your reply. This was my first uBlox and it peformed worse in just about all measures. Side by side with an Mtek, the uBlox heard fewer satellites, had more position jitter and the HDOP was almost always above 2.5 and never went below 1.5. The Mtek HDOP was reading about 0.8 during the comparison, which I have found to be "typical". Just my two cents.
Your Ublox must be defective then. My experience, with multiple units of each, is that the Ublox is golden, and the Mtek isn't useful for anything really. Can't even use it as a coaster because it's not flat enough. ;)
i mean its parameter wrong implemented to correction level.
it cant be used when frame pith and roll angles is low (for detect low speed fly and gps drift ) hdop gps parameter may be used for it too. if hdop > 1.0 gps fix with low prection
otherwise, when you fly in the room can cause serious problems
Oh, well I never fly indoors. Yeah, I would turn it off if you're inside. Best to just disconnect the GPS in that case.
That's funny that I found this topic discussion trying to find a solution for a gimball swinging problem :). I followed the manual connecting gimball servos to the AC11 and AC10 yesterday. After powering my quad I noticed that the camera platform of the gimball is swinging slighty in both tilt and roll axes when my quad stays on the desk. Checking the cabling and servos showed nothing wrong. So I started wondering what I am doing bad watching MP screens one by one... When I realized that the artifficial horizon on my Flight Data tab is also slightly swinging - I found the way home which is here. What I think it may be usefull to tag this topic also with a keywords as: GIMBAL SWINGING PROBLEM or simmilar. Brt