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

Change gyros to have a getRotation3d() and getAccel() methods #44

Merged
merged 4 commits into from
Mar 7, 2023

Conversation

7910f6ba7ee4
Copy link
Contributor

I feel like creating the Rotation3d at the gyro level instead of the SwerveDrive level could make more sense. I've also added a getAccel() method (even though we're not using that for pose estimation anymore) which creates a Translation3d at the gyro level, so it might also be better for the Rotation3d to be there too.

I have the array filler still there, but we could also remove it in this PR. Thoughts?

@thenetworkgrinch
Copy link
Contributor

thenetworkgrinch commented Mar 4, 2023

It is a logical step and reduces some level of redundancy however it does bind WPI non-representative (not a interface spec) types inside of abstractions, which is unprecedented, but not unwarranted.

@thenetworkgrinch
Copy link
Contributor

thenetworkgrinch commented Mar 4, 2023

I will approve it and accept the precedence.

@thenetworkgrinch
Copy link
Contributor

After a single test you can merge it @7910f6ba7ee4

@7910f6ba7ee4
Copy link
Contributor Author

Got it. Physical test?

@thenetworkgrinch
Copy link
Contributor

Yes

@7910f6ba7ee4
Copy link
Contributor Author

Tested and it doesn't break anything

@7910f6ba7ee4 7910f6ba7ee4 merged commit 2676860 into main Mar 7, 2023
@7910f6ba7ee4 7910f6ba7ee4 deleted the gyro-refactor branch March 7, 2023 02:01
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.

2 participants