Tailsitter : correct rate setpoint to match rate for tailsitter #275
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.
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