QuadPlane altitude loss in VTOL

[expntly]

Issue details

I've seen this with multiple other vehicles and this is becoming painful. When in VTOL, the QuadPlane suddenly feels very heavy and starts losing altitude. It usually results in the vehicle hitting the ground even when going full throttle when the initial alt loss is being noticed. Loss of yaw control at the same time is not unusual. This usually happens in QLOITER when maneuvering (e.g. doing slight rolls) but I've seen it happen in AUTO too when climbing straight up. Looking at the logs, it seems the vehicle is spending quite some energy yawing.

Here's an example in QLOITER where the vehicle is commanded a left roll, which works well with no alt loss. Then a right roll immediately causes the motors to "try to yaw" the vehicle CCW, with all the CW motors at 1615 and CCW motors at 1480, and the vehicle is going down. Max throttle doesn't prevent the vehicle from hitting the ground.

I thought my vehicle was too heavy but I've tested with another vehicle that has plenty of thrust available and this is still happening.

No problem to climb fast (a few m/s easily) when initially taking off.

Here's another example in AUTO VTOL_TAKEOFF with another vehicle (less power available overall but still). The vehicle is commanded to climb at 60m, but at 40m the motors start to diverge, the vehicle starts yawing and loses altitude. It manages to correct and climb again some 15s later though this time.

I should note that during another test it climbed no problem to 60m.

Is this yaw the root cause? If yes what is causing it? We've checked motors/props for alignment/level on all vehicles (they even use different motor mounts). We've re-calibrated the compasses.

Version

3.7.1 to 3.8.0-beta6

Platform

[ ] All [ ] AntennaTracker [ ] Copter [X] Plane [ ] Rover

Airframe type

X8 octaquadplane (multiple vehicles)

Hardware type

Pixhawk1, also tried Pixhawk2.1

Logs

DF logs of first example: https://www.dropbox.com/s/2j1bff3av6qk8ta/00000042.BIN?dl=0 DF logs of second example: https://www.dropbox.com/s/qbfrdib7zjuysug/27.BIN?dl=0

[expntly]

Any updates?

[tridge]

It is prioritising attitude control (and yaw) over altitude, and does indeed seem to be having some troubles holding altitude. I notice you have a significant yaw bias in the frame. The average power of your CCW motors is higher than your CW motors for the whole flight. I had this on my OctaQuad too, and I fixed it by putting some thin washers under half the bolts of the motors to give it a bit of left yaw bias to counteract the frame twist. That got the yaw balanced much better. See this graph of the average of CCW and CW motors in QLOITER

[iskess]

If the airframe has large tail surfaces it should naturally weathervane. If one were to de-tune the yaw and just let the yaw drift with the wind with a little bit of control remaining for damper, would that allow the motors more headroom for altitude control? I have an old open issue #4459 requesting the use of rudder to assist the yaw control in VTOL modes. This might help lighten the load on the quad motors trying to yaw. I don't see any harm in it.

[expntly]

@tridge Thanks for taking a look. I'll see if the frame yaw is true for all of my flights.

A couple of questions:

• I disabled weathervaning because when enabled, Plane will try to transition from VTOL to cruise in a very awkward way -- say it weathervanes heading North, and that the next WP after VTOL_TAKEOFF is South, Plane will start accelerating North AND make a turn AND transition, all at the same time. Transitions being tricky, this makes it much worse. I simple solution would be to first yaw South when still in VTOL and just before accelerating horizontally.

• Since I have weathervaning disabled, wouldn't wind explain such a graph? Our vehicle is rather large (14ft wingspan).

• is there a way in the logs to see the attitude control vs altitude dynamics?

• Any chance tuning Q_A_THRMIX{MIN,MAX} would help at all for the altitude loss issue? Or this is not really addressing the root issue?

ps: how do you plot formulas?

[auturgy]

@expntly MavExplorer takes python math arguments: http://ardupilot.org/dev/docs/using-mavexplorer-for-log-analysis.html

[expntly]

I had another instance of this happening on a vehicle that's loaded but definitely with enough thrust for the weight. In this instance, the vehicle was asked to climb in an AUTO mission, but a few seconds after take off, the climb stopped and the vehicle descended. A look at the DF logs shows the PWM on the motors are all over the place.

Is this ArduPlane trying to stabilize the attitude at the expense of thrust?

[magicrub]

What that plot is showing is motor C5 clipping at 100% which is holding the rest back in order to maintain stability. Is 1856 really the max? Seems low.

[lthall]

You are losing yaw control and the output mixer prioritises the motor power to roll and pitch, then yaw and finally thrust.

You may have oriented the motors such that the twist on your frame from the yaw motion causes opposite yaw that overrides the torque of the motors. You may also have a bad ESC calibration or faulty ESC or motor. You may also have a twist in your frame.

In any case this is being caused by a mechanical problem in your frame.

If you post a picture of your aircraft it may shed some light on the issue.

[expntly]

@magicrub @lthall

Thanks guys this is helpful! The clipping holding the rest back makes sense. Now trying to figure out why it's maxed out.

We have Q_M_PWM_MAX=1900, and Q_M_SPIN_MAX=0.95. Not sure how that ends up being 1854 since 0.95*1900=1805?

We're going to check our ESCs.

Also, should we start playing with Q_A_THR_MIX_MAX ? Currently set at 0.5.

[magicrub]

How about wine vein? If you're fighting the wind you're working harder with little to no benefit. Also, this pwm saturation generally indicates that your lift motors are underrated. Need to beef them up.

[DavidIngraham]

Perhaps this issue can be closed and discussion can continue in the forum?