Skip to content

AHRS: fixed initial attitude for non-zero AHRS_ORIENTATION #29667

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

Merged
merged 3 commits into from
Apr 2, 2025

Conversation

tridge
Copy link
Contributor

@tridge tridge commented Apr 1, 2025

we need to get the orientation right before any data is read

tridge added 3 commits April 2, 2025 10:39
for testing non-level flight controllers
we would update the orientation in the IMUs 1s after startup, leaving
a short time when the data was processed incorrectly
@rmackay9 rmackay9 mentioned this pull request Apr 2, 2025
75 tasks
Copy link
Contributor

@peterbarker peterbarker left a comment

Choose a reason for hiding this comment

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

LGTM

@tridge tridge merged commit 72fa9e8 into ArduPilot:master Apr 2, 2025
102 checks passed
@github-project-automation github-project-automation bot moved this to Pending in 4.6 Backports Apr 2, 2025
@IamPete1 IamPete1 removed the DevCallEU label Apr 5, 2025
@rmackay9
Copy link
Contributor

this is included in 4.6.0-beta6

@rmackay9 rmackay9 moved this from Pending to 4.6.0-beta6 in 4.6 Backports Apr 25, 2025
@dallinbriggs
Copy link

dallinbriggs commented May 7, 2025

@tridge
I would like to open this issue back up. I can confirm that the issue persists in this commit, at least with a Cube Orange Plus.
Test:

  • AHRS_orientation = 8
  • Cube orange booted while inverted and held still for the entire boot process

Results:

  • The vehicle's orientation could be seen flipping over after boot.

Here is a log of it happening after boot. I have also confirmed that cherry picking this commit back to 4.5.7 also gives the same results.
inverted_bootup.zip

@rmackay9
Copy link
Contributor

rmackay9 commented May 13, 2025

I've reviewed @dallinbriggs's log and also reproduced it on my own CubeOrange. I've created an issue to capture the problem here #30064

This is what I see with 4.6.0-beta6 and 4.7.0-dev using Copter:
image

Strangely 4.5.7 has very similar behaviour but it cannot be captured in the logs, perhaps because logging starts later?

Dallin's log shows slightly different behaviour with the roll-over to the correct attitude taking much longer. Maybe this is because DCM is the active attitude estimator in Plane?
image

EDIT: yes, the issue appears to be worse on Plane. here is the output from my test with Plane-4.7.0 and it looks like Dallin's
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 4.6.0-beta6
Development

Successfully merging this pull request may close these issues.

5 participants