Why PX4 uses both yaw weighting and different axis P gains in attitude control

1

Hi,

I’ve been studying the implementation of yaw weighting in PX4’s AttitudeControl, and I’d like to verify my understanding of the design.

My current understanding is as follows:

  1. Yaw weight geometrically redefines the attitude error on SO(3). By first aligning the thrust vector (body z-axis) and then applying only a weighted portion of the remaining yaw rotation, it deprioritizes yaw in the overall attitude control.
  2. My understanding is that yaw weight mainly addresses the geometric priority during large attitude errors. By deprioritizing yaw in the overall attitude control, it allows the controller to align the thrust vector first, enabling the position controller to achieve the desired translational acceleration more quickly.
  3. MC_YAW_P, on the other hand, mainly addresses the difference in control authority and closed-loop dynamics among the three rotational axes. Since a multicopter naturally has much less yaw control authority than roll and pitch, using a smaller yaw proportional gain helps make the response dynamics of the three axes better match their respective physical capabilities, rather than redefining the geometric attitude error.

If this understanding is correct, I still have one question.

After yaw weighting, the controller has already recomputed the attitude error vector eq, where the yaw component has already been deprioritized according to MC_YAW_WEIGHT.

Immediately afterward, the controller computes:

Vector3f rate_setpoint = eq.emult(_proportional_gain);

Since the default gains are different (MC_ROLL_P = 4, MC_PITCH_P = 4, MC_YAW_P = 2.8), this applies an anisotropic scaling to the rotation vector (Lie algebra error), meaning that the direction of the commanded angular velocity changes again.

My question is:

If yaw weighting has already geometrically deprioritized yaw in the overall attitude control, why is it still necessary to use different proportional gains that further change the direction of the commanded angular velocity?

From a geometric point of view, this seems to deviate from the descent direction obtained after the tilt-prioritized attitude error is computed.

My current hypothesis (which may be incorrect) is that:

  • Yaw weight mainly addresses the geometric priority during large attitude errors. By deprioritizing yaw in the overall attitude control, it allows the controller to align the thrust vector first, enabling the position controller to achieve the desired translational acceleration more quickly.
  • MC_YAW_P mainly addresses the difference in control authority and closed-loop dynamics among the three rotational axes, allowing the response of roll, pitch, and yaw to better match their respective physical capabilities.

In other words, although both affect yaw behavior, they operate at two different levels: yaw weight defines the geometric control objective, while MC_YAW_P compensates for the different dynamic capabilities of the three axes.

Is this interpretation consistent with the original design intent of the controller? Or is there another reason why MC_YAW_P has a smaller default value even after yaw weighting has already been applied?
@bresch

2

Can your question be partly rephrased: “Since the default proportional gain for yaw is less than for roll and pitch, why is the additional yaw weighting necessary ?” ?
Your own answer, that for large attitude errors, the additional yaw weighting algorithm will behave differently and better than proportional gain, might be the real reason, I suppose.
And good software design requires standard PID yaw control.

I am interested in this topic because I’m building a hex copter with out-of-plane rotors to provide 6 “degrees of freedom”. This vehicle has yaw control authority comparable to roll and pitch, so I disable the additional yaw weighting, because there is no need for it.

Instead, I’ve modified PX4’s AttitudeControl to generate transient thrust tilt toward the desired direction, in addition to the usual tilt of vehicle attitude. The motivation is that the response to vehicle position errors can be much quicker, especially if the angular inertia of the vehicle is large, since thrust is now a first order correction, instead of being delayed by the time required to tilt attitude.

A flight-Review logs of SITL gazebo simulation:

I’ve now built it for a cube orange+ flight controller, to first test my electronics.

Might you or any others be interested in this new feature? If so I could submit a request to add it to PX4, since by default it does not affect normal vehicles. Otherwise I wont cast my pearls before swine.
Don

3

Thanks for your reply. This is a really nice piece of work. It is essentially a kind of feedforward based on the desired position.

However, my question is probably more mathematical.

My understanding is that the idea behind yaw weighting (tilt prioritization) is to redefine the attitude error so that the desired angular velocity around the body z-axis is reduced while leaving the x and y components essentially unchanged. In other words, it prioritizes roll and pitch, allowing the thrust vector to align first. Of course, this is just my current understanding, but I think this is a very elegant approach. It also seems reasonable for multicopters since the control authority in yaw is much weaker than in roll and pitch.

What still confuses me is the proportional gain applied afterward. If we interpret the output eq as defining the desired angular velocity direction (or more precisely, the rotation vector), then applying different proportional gains along each axis changes the direction of that vector. Geometrically, this feels somewhat unintuitive to me.

In addition, yaw weighting itself already seems to partially address the difference in control authority between yaw and roll/pitch. If the yaw proportional gain is reduced for the same reason, it feels somewhat redundant. More importantly, it changes the direction of the commanded angular velocity, whereas intuitively I would expect that reducing MC_YAW_WEIGHT alone should already achieve the desired prioritization.

4

Yes, having both yaw weighting and yaw proportional gain does seem redundant to me. But PX4 is also a piece of software engineering where it is desirable to use a standard PID controller for yaw. And remember that this PID controller will not have to process large yaw errors (which it would do very badly) if large yaw errors have already been reduced by the yaw weighting algorithm.