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

mc_att_control: adjust attitude setpoint upon estimate reset #14738

Merged
merged 3 commits into from
May 26, 2020

Conversation

MaEtUgR
Copy link
Member

@MaEtUgR MaEtUgR commented Apr 22, 2020

Describe problem solved by this pull request
When the attitude estimate quaternion is reset the attitude controller uses the new reference in the next loop iteration. But the attitude setpoint is not updates to the new reference until the position controller generates a new attitude setpoint but it runs in a much slower rate. As a result there are glitches in the output rate setpoint. See #14676 (comment)

Describe your solution
The internal setpoint copy is updated with the delta quaaternion upon attitude estimate reset. It will get overwritten with the next attitude setpoint change.

Test data / coverage
Completely untested, tests still REQUIRED.

@MaEtUgR MaEtUgR self-assigned this Apr 22, 2020
@dagar dagar self-requested a review April 22, 2020 19:47
@MaEtUgR MaEtUgR force-pushed the fix-quaternion-reset-setpoint branch 2 times, most recently from 08f8fad to 3056a47 Compare April 23, 2020 10:52
@MaEtUgR
Copy link
Member Author

MaEtUgR commented Apr 23, 2020

http://ci.px4.io:8080/blue/organizations/jenkins/PX4_misc%2FFirmware-SITL_tests/detail/PR-14738/3/pipeline
If I test VTOL manually on my local machine I see no issue. Let's try again.

@MaEtUgR MaEtUgR force-pushed the fix-quaternion-reset-setpoint branch from 3056a47 to 6c5e266 Compare April 23, 2020 11:58
@MaEtUgR MaEtUgR marked this pull request as ready for review April 27, 2020 15:43
@MaEtUgR MaEtUgR force-pushed the fix-quaternion-reset-setpoint branch from 6c5e266 to d1ccc33 Compare May 12, 2020 17:14
@MaEtUgR
Copy link
Member Author

MaEtUgR commented May 12, 2020

@dagar During SITL testing I found the following case is quite common: A new attitude setpoint that was generated with the old reference overwrites the old adapted one because they get processed in the same loop iteration. Easy fix, first check for setpoints then for resets -> 3rd commit.

Doing above I found the far less common but still occuring case where there's a new attitude setpoint that was already generated with the new reference and it gets corrected again assuming it's an old one (see above). Since this is less likely I prefer the solution with the fix but it's annoying to not have all corner cases covered.

bresch
bresch previously approved these changes May 13, 2020
MaEtUgR added 3 commits May 25, 2020 16:54
The last attitude setpoint that is known from the position controller
is now kept inside the AttitudeControl class such that we don't
keep the whole vehicle_attitude_setpoint struct and always copy over from
there to run an update step.
There was a gap where the attitude controller already used the estimate
with a new reference but the last known attitude setpoint was still based
on the old reference. This leads to a big glitch on reset because until
the attitude setpoint gets updated the error is wrong and as large as the
attitude delta of the reset.
@MaEtUgR MaEtUgR force-pushed the fix-quaternion-reset-setpoint branch from d1ccc33 to 99b8e52 Compare May 25, 2020 14:54
@RomanBapst RomanBapst merged commit e482081 into master May 26, 2020
@RomanBapst RomanBapst deleted the fix-quaternion-reset-setpoint branch May 26, 2020 12:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants