Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to I-Term rotation based on consideration of aerodynamics #13473

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ChrisRosser
Copy link
Contributor

Only rotate pitch and roll I terms based on Yaw Rate.

A discussion of the reasoning behind this PR is attached as a PDF.

Improving_I-Term_Rotation.pdf

Copy link

Do you want to test this code? You can flash it directly from Betaflight Configurator:

  • Simply put #13473 (this pull request number) in the Select commit field of the Configurator firmware flasher tab (you need to Enable expert mode, Show release candidates and Development).

WARNING: It may be unstable. Use only for testing!

@ChrisRosser ChrisRosser force-pushed the Simplified-I-Term-Rotation branch 2 times, most recently from 61f19c4 to 589fd3b Compare March 22, 2024 16:57
src/main/flight/pid.c Outdated Show resolved Hide resolved
@ctzsnooze
Copy link
Member

I agree that rotating yaw iTerm makes no sense; I agree that yaw iTerm should be 'left out of' any iTerm rotation code.

I also agree that changes in roll should not change iTerm on pitch, and vice versa.

Hence the only question really is whether or not we should rotate iTerm between Pitch and Roll when there are yaw inputs.

The PDF is very good, but of course a quad is not a pizza box. It is longer than it is wider. Pitch Drag in forward flight from aerodynamics, and Pitch COG offsets, are not the same as those on Roll.

The iTerm accumulation on pitch, in forward flight, is an anti-rotation factor, so in the PDF, it should be drawn as a circular vector, not a linear vector. In most cases, while flying forward, there is drag backwards, so the iTerm vector that accumulates on pitch is a rotation force pushing forward (nose down) to oppose a drag that would lift the nose up.

If the battery is below and props are on top, as in a typical racer, the COG is usually below the centre of thrust, and when pitched forward, it is a long way behind. This also requires forward pitch iTerm accumulation as a correction factor in clean forward flight. Freestyle rigs are normally better balanced, so a significant COG offset in relation to centre of thrust are not such an issue (in most builds).

Overall most quads accumulate nose-down iTerm in fast pitch-forward level altitude flight.

We don't really know much about pure sideways flight, eg the kind that we get if we are flying fast forward, and abruptly turn 90 degrees, and and drift sideways for a short time at the same throttle.

The situation is not as definite as on pitch. In a racer, drifting sideways, most of the aero drag is below the props, so we would tend to roll downwards in the drift direction on the roll axis, and may need upwards iTerm accumulation on Roll. That would be the opposite of the down-wards direction of the previously accumulated pitch iTerm. In a freestyle build, drag is likely the same top and bottom of the thrust plane, so probably there is very little iTerm required in the roll direction. In a freestyle build, aero drag sideways is probably equal top and bottom, and COG is likely the same top and bottom; hence for Roll, it would likely need little or no iTerm to accumulate, or be 'given to it by iTerm rotation'. In both cases, with an abrupt 90 degree turn, simply rotating the previous iTerm quantity into Roll is not guaranteed to provide the right amount of iTerm on roll during the drift period. Indeed it is likely to transiently destabilise Roll, which is probably best left alone, I think, to accumulate whatever iTerm it needs, if any.

Additionally lets consider what might happen to iTerm on pitch if, at the time of an abrupt 90 degree yaw, we transfer all it's accumulated iTerm to Roll (which typically has none). it's true that from the drag perspective, immediately after the 90 degree turn, we don't have rearwards drag, so we don't need that forwards pitching accumulated iTerm element any more. However we will, if we intended to maintain pitch angle, soon re-accumulate velocity in the pitch forward direction, and need that iTerm to re-accumulate. From the COG perspective, in a racer, where the battery and COG below and out the the back of the quad when pitched forward, the pitch forward iTerm is required whether or not we are flying forward or drifting sideways. So a racer is likely, on a pure fast 90 degree yaw with the current code, to transiently dip the nose, but otherwise be stable on roll.

Without iTerm rotation, a race type build with a fast pure 90 degree yaw will have a stable Roll axis and only a transient nose forward dip on Pitch that will resolve quickly. With iTerm rotation the same quad in the same situation is likely to be transiently unstable on both Pitch and Roll due to abrupt transfers of Pitch iTerm to Roll.

A freestyle build is likely to be similarly affected but not to such a great extent.

Overall I very much doubt that any iTerm rotation code will improve flight performance or the stability of the quad with fast yaw inputs, to any meaningful extent. I think it will likely be a negative feature for race builds.

At the same time, anything that simplifies and improves on our current iTerm Rotation code is fine by me.

The proof of the pudding is in the eating, so let's see some videos of pure yaw inputs in acro, at speed, and compare the resulting pitch and roll stability when there is no change in pitch, roll, or throttle. We can easily assess stability with a camera at 45 degrees and the horizon centred at the time of the yaw. I expect that freestyle and race builds will behave differently.

@ctzsnooze
Copy link
Member

I guess another test of rotation code is when the quad is rotated abruptly 180 degrees on yaw. As the quad suddenly finds itself drifting backwards, all the aero forces are in the absolute opposite direction, tending to either do nothing, or push the nose down; hence we might expect that we should 'rotate' the sign of the 'nose forward' iTerm to an opposite sign 'nose up' factor, if we wanted the nose to stay stable. For a race quad, though, the COG factor won't change, so this is not such an interesting event, and they will accelerate away soon enough.

But what we should see with the current code is that a snap pure yaw 180 should lead to a transient pitch dip while drifting. With iTerm rotation I guess the iTerm should be made opposite in direction, which may alleviate the pitch dip. However the pitch dip helps to stop the quad, so I'm not so sure its a bad thing.

Update to I-Term rotation based on consideration of aerodynamics

Only rotate pitch and roll I terms based on Yaw Rate. Scale I term by P term ratio

Update pid_unittest.cc
@haslinghuis haslinghuis added this to the 4.6 milestone Mar 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

None yet

3 participants