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

Possible bug assigning K factors to knife edge flick rolls on looping segments #274

Closed
Bdavy92960 opened this issue Mar 10, 2023 · 3 comments

Comments

@Bdavy92960
Copy link
Contributor

I think we’ve uncovered a bug in Openaero regarding the K factor assignment for flick rolls from knife edge in a loop. The program appears to be using the attitude of the plane, not the wing loading, to determine the correct assignment of the K factor.

For example, in figure 7.4.2.2, an outside/inside loop with a 3x4 followed by a positive ¾ same direction flick. The program is assigning the lower K factor to the flick because it's interpreting the pilot using the top rudder at the top of the loop. But the wing loading is negative at the entry of the figure. After the 3x4, the pilot would be using either no or bottom rudder to maintain the flight path between the rotational elements, which is the same rudder he/she would be using to perform the same direction positive flick, so it should be assigned the lower K factor. It should be interpreted as the top rudder because it’s the direction the pilot uses to continue the loop radius. IAC rules state “Where a snap roll located on a horizontal, 45°, or looping segment is preceded by a roll of any type, careful consideration must be made of the loading required after the first roll to maintain the desired flightpath between the two rolls.

Reference IAC Rulebook chapter 36.10.1, page 57 (https://www.iac.org/sites/www.iac.org/files/IAC%20Rule%20Book%202023.pdf). In the example case using the table, the plane is “inverted” at the top of the loop because of the negative wing loading preceding the first roll. So Per the table in the IAC rules, Inverted entry, ¾ initial roll, Positive Snap Same Direction should be the higher K.

Brad

@OpenAero
Copy link
Owner

OpenAero commented Mar 13, 2023

OpenAero follows the rule as stated in the Aresti Catalog "Positive and negative flick rolls":
25. In the case of flick rolls initiated from knife-flight, the K-factor accorded
to the manoeuvre shall be determined by whether the flick is initiated
using top rudder or bottom rudder. When top rudder is used, the lower
coefficient shall apply, while the higher coefficient shall apply to flicks
initiated with bottom rudder.

If IAC rules deviate from this, OpenAero would need a specific determination algorithm for IAC flick roll K factor. The term "carefull consideration" in the IAC rules is rather vague. In any case, the wing loading before a knife edge flick roll is never positive or negative, it is always 0. A positive or negative wing loading in knife edge results in the aircraft changing course. The rudder position to maintain pitch is much more relevant, which is why the Aresti Catalogue rule is stated as it is. It is true that this position would be somewhat different in a loop, but this can vary dramatically between aircraft and power setting.

The best solution may be to change the IAC rules to conform to the Aresti Catalogue. In this aspect, it's interesting to note that this rule was added to the catalogue in 2009. Before this, there was no agreed-upon definition for knife-edge flick K factor. Could it be that the IAC rule is from before 2009, and no attention has been given to updating it?

@Bdavy92960
Copy link
Contributor Author

I sent an email to the IAC rules chair asking for their interpretation. Further consultation with some of my colleagues at IMAC shows I may be wrong in how I am interpreting the table, and the current Openaero is probably correct. Hopefully I'll hear back from IAC. Will let you know. Thx

@Bdavy92960
Copy link
Contributor Author

After discussion and consideration, i've altered my thinking on how I've been interpreting, and accept the way the program is making the K factor assignments. No issue. Closing the issue.

Brad

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants