Correct the IMU angular velocity axes #159
Merged
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.
See SDK issue here: FIRST-Tech-Challenge/FtcRobotController#251
In essence, as of SDK <v7.0, the X and Z axes from
getAngularVelocity()
in the BNO055IMU class are flipped. This has affected users who use these two axes when running the MaxAngVeloTuner for the last few months, where the maximum angular velocity is reported to be very low, in the 0-5 degree range. The general advice in places like the FTC Discord since the issues were first noticed with this tuner was to use an approximate value for the maximum angular velocity and acceleration such astoRadians(180);
.Recently, with the increase in people using the LearnRoadRunner guide (which instructs to use the MaxAngVeloTuner), many people have used the incorrect values, and experience issues when their track width tuning does not work due to it. Last week, I started trying to figure out the cause of these problems, and my search eventually led to the main SDK issue that I linked above. This fix would be a temporary one until a larger main SDK version comes out which fixes it, but as there is no known time estimate for that, it might be good to go ahead and act on it.
My fix includes a comment on the
getExternalHeadingVelocity()
function describing the changes and changes the default Z axis to the inverse X axis (the inverse is necessary because the BNO055IMU inverses the X axis since it expects it to be the Z axis).I can realize that such a change may not be desirable when it will break upon the next SDK release, so if it is wanted I can edit the PR to instead just include an instructional comment about the necessary changes to the angular velocity axis when using an SDK version <7.0.
Hope this is helpful.