-
Notifications
You must be signed in to change notification settings - Fork 197
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
Tailsitter : correct rate setpoint to match rate for tailsitter #275
Conversation
@sfuhrer can you give some feedback on this? |
@sfuhrer please let us know if this is true. the rates for roll, pitch and yaw don't make sense |
Makes total sense to also transform the rate setpoints and not only the rate measurements from the body to the "fixed-wing" frame 👍 |
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.
I agree with the necessity of the change, thanks for handling it!
Can you check the CI failures?
83d1705
to
3642248
Compare
I think I had some problems with pyulog. I rebased and now seems to be fine |
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.
Thanks!
I was analysing some logs for a quadtailsitter without control surfaces that i'm developing, and I notice that even though the angle tracking of roll was quite good, the plots for the rates did not make sense
Here the complete logs for reference
By looking into the
configured_plots.py
I saw that if the vehicle is a tailsitter angles and rates are reassigned to be plotted in a more consisten way for the instants that drone is flying in fixed wing:but this is not applied to the rates setpoint, so the result is that on the rollrate plot , for example , the data shown are:
What I did was simply remapping also the setpoints in fixed wing so to have in the same plot
Tracking is still not perfect, but that's a problem with the simluation.
Aslo plot of yaw rate makes more sense:
Old
New
Honestly this to me was very confusing, since I tried to find a reason for the behavior of correct angles but completely wrong rate control. In this way it makes more sense, so you could easily see if the rate controller is good at tracking. I think this was the way it was handled in the past, since I saw some old logs review that did not have this problem and I think is related on the new control approach.
I'm conscious that the code may need other adjustments, since probably I'm not considering some cases (did not look into PID analysis for now). I opened this PR just to understand if this was actually a problem or the was a specific reason for this