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

Tailsitter : correct rate setpoint to match rate for tailsitter #275

Merged
merged 3 commits into from
May 29, 2024

Conversation

ciresimo
Copy link
Contributor

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
Screenshot from 2024-03-21 13-51-43
rollrate_wrong

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:

  • yaw -> -roll
  • roll -> yaw

but this is not applied to the rates setpoint, so the result is that on the rollrate plot , for example , the data shown are:

  • in MC
  1. Roll rate
  2. Roll rate setpoint
  • in FW
  1. Inverse of yaw rate
  2. Roll rate setpoint

What I did was simply remapping also the setpoints in fixed wing so to have in the same plot

  • in FW
  1. Inverse of yaw rate
  2. Inverse of yaw rate setpoint
    rollrate_new

Tracking is still not perfect, but that's a problem with the simluation.
Aslo plot of yaw rate makes more sense:

  • Old
    yawrate_wrong

  • New
    yawrate_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

@bkueng bkueng requested a review from sfuhrer March 22, 2024 05:57
@ciresimo
Copy link
Contributor Author

ciresimo commented May 7, 2024

@sfuhrer can you give some feedback on this?

@khikmatovfarkhod
Copy link

@sfuhrer please let us know if this is true. the rates for roll, pitch and yaw don't make sense

@sfuhrer
Copy link
Contributor

sfuhrer commented May 23, 2024

Makes total sense to also transform the rate setpoints and not only the rate measurements from the body to the "fixed-wing" frame 👍

Copy link
Contributor

@sfuhrer sfuhrer left a 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?

@ciresimo ciresimo force-pushed the tailsitter-orientation-fix branch from 83d1705 to 3642248 Compare May 23, 2024 15:23
@ciresimo
Copy link
Contributor Author

I think I had some problems with pyulog. I rebased and now seems to be fine
I ran the test locally and got 10

@ciresimo ciresimo requested a review from sfuhrer May 23, 2024 15:49
Copy link
Contributor

@sfuhrer sfuhrer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@bkueng bkueng merged commit 2dad6c1 into PX4:main May 29, 2024
1 of 4 checks passed
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

Successfully merging this pull request may close these issues.

4 participants