FW Att and Rate Controller, Tailsitter: fix tailsitter frame transformations #20904
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…mations Strictly follow the following convention for tailsitter: FW Attitude and FW rate controller always operate in the FW frame, meaning that roll is roll in FW, which for tailsitter means around the yaw axis in the body frame. The interfaces between modules is though always in body frame. That enables us to do the axis transformations for tailsitter, that are currently distributed all over the controller (attitude, rate, vtol module), only at the input and output data of modules. Side effect is that the FW rate control tuning gains meanings change: while before the roll gains where meant for the body axis, they are now always applied for the FW roll axis (also in hover). So the naming now is correct for FW, while before it was for Hover. Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Jaeyoung-Lim
approved these changes
Jan 13, 2023
|
Tested on a tailsitter with only control surfaces and works as expected! Thanks for the quick fix! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Solved Problem
Tailsitters that require control surfaces are currently broken on main since #20237, as we there forgot to do a couple of required tailsitter axes transformations. We didn't notice in SITL testing because the model there has 4 motors that it uses for hover control, without the need of control surfaces and thus the FW rate controller.
Problem found by @Jaeyoung-Lim while working on #20859.
Solution
Strictly follow the following convention for tailsitter: FW Attitude and FW rate controller always operate in the FW frame, meaning that roll is roll in FW, which for tailsitter means around the yaw axis in the body frame. The interfaces between modules is though always in body frame.
That enables us to do the axis transformations for tailsitter, that are currently distributed all over the controller (attitude, rate, vtol module), only at the input and output data of modules.
Side effect is that the FW rate control tuning gains meanings change: while before the roll gains where meant for the body axis, they are now always applied for the FW roll axis (also in hover). So the naming now is correct for FW, while before it was for Hover.
Test coverage
SITL tested for all modes and in both hover and aerodynamic flight, and hover tested on real platform.