Merged
Conversation
| // We want to do some floating point math at compile time | ||
| #![feature(const_fn_floating_point_arithmetic)] | ||
| // We need async traits for efficient yet generic IMUs | ||
| #![feature(async_fn_in_trait)] |
Check warning
Code scanning / clippy
the feature `async_fn_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
ImUrX
approved these changes
Jan 29, 2023
kitlith
reviewed
Jan 29, 2023
Collaborator
Author
|
will merge by end of day today (GMT-5) if there is no further feedback |
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 added an imu trait. Originally I was thinking there would be a fused and unfused imu, but it makes far more sense for there to just be one imu trait generic on its associated type, and that type can be fused or unfused. Also there was disagreement before on how to name stuff, like whether its
RawImuorImuorFusedImu. This makes that no longer necessary because all imus are theImutrait.I also added a
FusedImustruct that we can use to combine an unfused imu with aFuser. The idea is that theFuseris purely a math thing. It could be any fusion algorithm.One thing that remains to be solved is where filtering comes into the picture. If possible I think we should punt that to a later design iteration, when we have a need for it. Its possible that
FusedImuis the one without filtering, andFilteredFusedImuhas filtering also, which also implementsImu<Data=FusedData>. I'm not really sure which is why I think we should deal with it later in favor of unblocking present work.I did not touch any of the business logic of the current imu implementations (such as the bmi160) as I felt that was out of scope.
The bmi160 should become an unfused type in a followup pr, and we should also refactor the nonblocking imu functions into async blocking ones, if we can figure out how to do that using proper async (might be hard, because most drivers use a non-async blocking api).