-
-
Notifications
You must be signed in to change notification settings - Fork 113
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
Fix the correction yaw gives in 2pass (Motor Output Mixer) (Thrust Linearization) #852
Conversation
@tylercorleone perhaps you can find a way to code this more efficiently, but long story short, I found that in 2pass the yaw axis would have less authority during pitch/roll moves. This change gives it the same authority as pitch and roll, but requires a fair bit more logic to make work :( |
I flew this and it flew good. submitted logs for review in discord. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- approved based on conversation
- will defer to @Quick-Flash to merge or not
@tylercorleone , are you interested in reviewing this PR? I've flown about 9 packs on it. |
Hi guys, honestly lately I lost some interest in quads but above all I've been for so long away that it's hard for me to understand the change. I would ask only two questions:
I'll try to look again at this PR anyway. |
So the change to your PR that was made changed the mixer slightly so that yaw axis moves would not cause more throttle movement unless it had to. Basically me and a few others complained that it seemed to sort of "float" during sharp turns due to yaw adding thrust. Without the yaw compensation if you just hovered and gave a little yaw you would see the drone move up due to this. Added some code to correct and compensate for that. Later I found out that this compensation would create a yaw value to the motors that would shrink as more roll/pitch was applied to the mixer. So you would end up with less yaw than your controller was commanding during roll/pitch moves. This fixes that so that yaw control stays the same regardless of pitch/roll (unless clipping starts to be involved in which case roll/pitch/yaw are all clipped). I should probably update this code so that these code changes are only applied if you have the mixer_yaw_throttle_comp turned on. Looking over the code again I would hope that there is a more cpu effective way to achieve this effect. Thanks for taking a look @tylercorleone and thanks for the original implementation! I've been flying this change for a while and don't notice a huge flight performance difference, but it does seem to be a little mathematically better way to mix the pidsums while the mixer_yaw_throttle_comp is enabled. |
would |
|
Looks good! |
Hi @Quick-Flash, @nerdCopter, reading the descriptio: For example, if I'm not wrong, given:
by looking at signs I can deduce that motors 1 and 2 will contribute "negatively" to roll movements (it would be better if they stay still or reverse), so the total roll contribute will be: total roll contribute is higher because the "0.2" input to the controller was thrust difference and not motor output, while yaw-related input is already proportional to motors' RPM. P.S. I'm tylercorleone using my work account, sorry :) |
I got the data without using any thrust linear, where roll/pitch/yaw should keep their ratios regardless of extra roll or pitch input. It's not to tricky to pull out the mixer code and run simulations based on the desired r/p/y and then back calculate things based on the motors to see the actual outputs it gives. |
i can produce BBL files upon request. i'm unsure how to analyze them as proof or disproof however. |
all these are from this branch |
Hi @Quick-Flash! It's not the thrust linearization thing the main "problem" (although it should be kept in consideration it is the only reason because the 2PASS mixer exists: handling roll and pitch separately from yaw because of their different nature :) ) but the steps like this: As I wrote you in a message we could play with the very first code proposed, e.g. here https://github.com/emuflight/EmuFlight/blob/master/src/main/flight/mixer.c#L1015. We could stard from there and tweak the very basic way we mix values avoiding additional "fixes". "When mixing an even amount of roll and yaw you would end up with the motors producing more roll than yaw" this is due to thrust normalization. Also it's difficult to compare roll and yaw :) you could compare the percentage of what the user is requesting and how many of that request is being applyed instantaneously. @nerdCopter it would be nice to see a log describing the issue of the initial code and then we could try to "fix" it! |
merging. i rather fly it than not fly it. |
Previously yaw correction would change based on how much roll and pitch was mixed. When mixing an even amount of roll and yaw you would end up with the motors producing more roll than yaw. This problem only even shows up during yaw movements that involve pitch or roll.
example from simulated roll and yaw pidsum with current and new code.
This code makes sure that yaw will not be shrunk during roll or pitch movements and should improve handling during quick yaw movements.