Add case for rotating in place in odometry #75
Merged
Conversation
This file contains 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
Odometry calculations were not taking in account the case of the robot rotating in place. This would cause a division by zero and make the plugin return invalid data. This commit handles this case by not using the arc method if the distance traveled by the robot is close to zero.
Only the displacement along X and the combined displacement were used to calculate the angle between the X-axis and the robot drive direction. This resulted in a positive angle whatever if the displacement along Y was positive or negative. This commit addresses the issue by using both displacements along X and Y to calculate the angle.
|
Thank you for the update! That is indeed something that should be addressed even though it will only happen if |
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.
My previous PR #71 added support for holonomic vehicles by taking in account the Y axis. I realized that there is a possibility for a bug when the traveled distance
distChangeis equal to zero, as theangleDriveDirectionwould become invalid because of a division by zero.This was not happening when I tested PR #71 because of Gazebo noise/imprecision, but I think it would be good of addressing it for the sake of robustness.