# Potential Bug in Parasite Drag Formula

Problem: The parasite drag formula used by this script (and the Firmware) seems incorrect because it violate the principle of force decomposition.

Maybe I’m missing some details, but the quadratic term `0.5 * rho * v_body ** 2 * np.sign(v_body) * x` in the aerodynamic coefficient estimation script:

seems inconsistent with the publication reference.

where V0 is the relative air velocity in the inertia frame. If my understanding is correct, the “v” in the drag equation should be the total relative airspeed (v = ||V0||, the length of V0, a scalar), NOT the velocity components at each axis.

Using the velocity component in this formula seems violate the principle of force decomposition.

Proof: If it is consistent with the principle, then both ways(see below) should get the same drag force/acceleration. Without loss of generality, we take X-axis drag acceleration for example:

1. Calculate with Vx, the x-axis component of airspeed, just like the script and firmware does.
2. Calculate the total drag acceleration with V0 first, then decompose it to get the reading at the X-axis.

The first way is straight forward because it already written in the script.

For the second way, since the body drag force (vector) has same direction with V0, the relative velocity to the air. Decomposing the drag acceleration along 3-axis (says the x axis) will get: Because the norm (length) of a vector can greater than its component, the drag equation in the script may no longer hold if both axis has air flow simultaneously (wind from Northeast, for example).

2 Likes

@rroche who is the best to tag for this?

@wangww I tried to find a convincing answer to this but you’re right, the model assumes Drag = Drag_x + Drag_y, which isn’t correct since the drag is a vector.

Maybe this was done because it creates a simpler jacobian? I will talk to the author of the code to see if this was intentional or not.

1 Like

perhaps is refering to the vector addition and not algebraic sum?
Drag(vector)=drag_x_i+drag_y_j?

Yep, that is what it supposed to do.

If they use the vector addition correctly, then the drag force at each axis should match the decomposed total drag force. (see Proof section in the main thread for more details)

The bluff body drag is modelled as a flat plate facing forward and another facing sideways which simplifies the equations but does over estimate the drag in the ‘corners’. The alternative is to do the computation in polar coordinates. I will have a look to see what is required to do that.

2 Likes

composed, not decomposed… but i got the idea

Finally addressed here: EKF2: Improve bluff body drag model by bresch · Pull Request #20848 · PX4/PX4-Autopilot · GitHub
@wangww could you please have a look?

It looks good! Gladly to see this problem solved! I’ll mark this reply as the solution.

1 Like