Issues with Barometer -> Poor AltHold performance

I’m still facing massive AltHold problems from time to time. It appears to be related to gusty wind situations.

Here is an example from today’s test flight. After climbing to 5-7 m in Stabilize mode I invoked AltHold mode. Over the 1 1/2 - 2 minutes I slightly corrected x and y movements but basically didn’t touch the throttle stick for z correction. Wind was at 5-8 km/h with gusts of 8-10 km/h.

[attachment=1]RelAlt_GPSAlt.png[/attachment]

Yet, you can see that BarAlt and GPS RelAlt start dancing all over the place. Even worse: BarAlt and GPS RelAlt diverge quite a lot.
Shortly after 2 min into the flight you can see that IRIS dropped from 7m and basically landed itself.
That made flying in AltHold or Loiter mode completely impossible today.

Is the Barometer in the Pixhawk that susceptible to slight wind? Anyone else having similar issues?
Any ideas on how to fix this?

I don’t have Iris, but I had similar problem with althold and loiter to my Okto, and I solved it by changing the following parameters:
Throttle_Acc_P: 0.500 (default 0.7500)
Throttle_Acc_I: 1.0000 (default 1.5000)
It might not be the right solution for you because our setups are very different but you can try it;

Ciao - Giuseppe

My altitude indication seems to be solid. It maintains alt perfect when hovering but as I fly it horizontal the altitude steadily decreases. This weekend I plant to try increasing the alt hold P (proportional gain) setting. The default is 1.0 on the Iris. I’ll start with a 1.2.

mp

@mikronerd: Thanks, I’ll give this a try.

Also have a look at this posting here: diydrones.com/group/iris/forum/t … %3A1445744

“[…] and noticed that when in alt hold moving forward or left/right results in an immediate drop, however when moving backwards it rises.”

That correlation between direction of travel and drop/rise to me appears to be caused by Barometer issues.

I’m still seeing issues where CTUN->BarAlt and GPS->RelAlt diverge from each other quite dramatically (up to 10m). The result is poor performance in AltHold mode and IRIS dropping or ascending.

This is from a flight this morning. Conditions were wind-free.
You can see the divergence between CTUN->BarAlt and GPS->RelAlt between Minute 1 and 2:
[attachment=3]IRIS_Drop1.png[/attachment]

I notice that this divergence correlates with high vibrations along the z-Axis:
[attachment=2]IRIS_Drop2.png[/attachment]

RoglioN mentioned in another post that vibrations could be causing AltHold issues, but didn’t go into specifics.

I further noticed that the divergence and the vibrations also correlate to the Out channels oscillating:
[attachment=1]IRIS_Drop3.png[/attachment]

I have ruled out the usual suspects:

  • Motor are mounted with 3x10mm screws + loctite and are rock-solid.
  • Propellers are mounted correctly and tight.
  • GPS coverage and xDOP was good.

If you look at the rest of the flight, you’ll notice that the rest of the flight is uneventful, with low vibrations and no AltHold issues.

What’s concerning me is that I’m running into this issue during almost every flight. It’s just unpredictable when during the flight it will hit and how big the drops or ascents are. That makes flying IRIS in anything but Stabilize mode a bit of a lottery game.

Any help would be appreciated!

[color=#00BF00]I moved this to the Copter/3.1 forum because that looks more like a software or tuning issue to me than a hardware issue, so the chance of getting a solution should be higher here.[/color]

Thank you Stefan!

Here you can find more about the vibrations:
“High vibrations cause the APM:Copter’s accelerometer based altitude and horizontal position estimates to drift far off from reality which leads to problems with alt hold (normally rocketing into the sky) or Loiter (drifting).”
copter.ardupilot.com/wiki/common … Vibrations

Rogelio, thank you for the pointer to the vibrations.

But looking at the link you provided, I can see that my vibrations throughout the flight are very well within the acceptable range, except for that 20 second window towards the beginning where z-Axis vibrations go all crazy:

[attachment=0]IRIS_Drop4.png[/attachment]

So my follow-up question: What could be the cause of that short spike in z-Axis vibrations?

As I wrote earlier, there seems to be correlation with motor stuttering / oscillation on the Out channels 1-4. I don’t if the vibrations are the cause of the stuttering or vice versa?

I’d be grateful if someone has an idea on the root-cause! Thanks.

[quote=“kangajump”]Rogelio, thank you for the pointer to the vibrations.

But looking at the link you provided, I can see that my vibrations throughout the flight are very well within the acceptable range, except for that 20 second window towards the beginning where z-Axis vibrations go all crazy:

[attachment=0]IRIS_Drop4.png[/attachment]

So my follow-up question: What could be the cause of that short spike in z-Axis vibrations?

As I wrote earlier, there seems to be correlation with motor stuttering / oscillation on the Out channels 1-4. I don’t if the vibrations are the cause of the stuttering or vice versa?

I’d be grateful if someone has an idea on the root-cause! Thanks.[/quote]

That is interesting. You probably hit just the right vibration frequency where aliasing occurs.

AC 3.2 will introduce a couple things that will massively increase robustness: the EKF and support for dual accelerometers (PIXHAWK has 2 accels and they are sampled at different frequencies, APM is about to start exploiting that)

Jonathan, thanks a lot for your help. Really appreciate that.

Is there anything I can help with gathering more data on this issue, so that you can better address it in the new version?

Also any idea on a workaround in the meantime? I guess I could introduce vibrations by a non-balanced prop and thereby hope I’m not within the aliasing range anymore. Would that work?

Also, as this was on a stock IRIS without any modifications I’m concerned that there will be other folks hitting exactly the same issue. I’ve seen some reports which could point in this direction,

Last but not least: Would it make sense to update the log how to with the information on the aliasing as seen via Chan Out? That way other people can quicker determine if they are hitting this issue.

Thanks

Chris

It appears as if I have found the root cause the of the z-axis vibrations which in return seem to be causing the oscillation.

On a stock consumer version IRIS, the uBlox GPS module touches the Pixhawk, transferring vibrations from the engines via the frame into the hull and via the uBlox into the Pixhawk. Maybe because of the shape of the hull serving as a damper itself these vibrations appear to be along the z-axis and also sporadic.

Isolating the Pixhawk from the GPS again will make these sporadic spikes go away, so that the vibrations look like the white noise that it should be again.

Have a look at this post for more details.

On a stock consumer version IRIS, the uBlox GPS module touches the Pixhawk,

On a stock consumer version of Iris the uBlox GPS module does not touch the Pixhawk.