Substract minimum twist covariance from twist covariance #222
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.
This might sound a bit awkward at first, but I believe there's a use case for it, that I explain in a bit below.
First, what's the issue this is trying to solve?
If the twist covariance already had a minimum twist covariance added to it in order to prevent ill-conditioned covariance matrices, we need a way to substract that minimum twist covariance from it before we compute the pose relative covariance.
Otherwise, we cannot get the original pose relative covariance because the minimum twist covariance term is
multiplied by the time delta, which could actually make the resulting pose relative covariance ill-conditioned or very small, i.e.
overconfident.
How can we fix this?
In practice, this means that we can use the same minimum twist covariance that was added to the raw twist covariance to obtain the raw twist covariance and then compute the pose relative covariance and, if needed, add a minimum pose relative covariance to the result, which could be the same as the minimum twist covariance or different.
Use case
If we don't care too much about having a pose relative covariance that matches exactly what it should be for the raw twist covariance, it's true that with a minimum pose relative covariance we should be fine to guarantee the pose relative covariance isn't ill-conditioned.
However, we might not be able to remove the minimum twist covariance because other consumers might not have protection for ill-conditioned covariance matrices. For context, https://github.com/clearpathrobotics/ros_controllers/blob/38e474f3d05e42de1500f8486eb180803613d79d/diff_drive_controller/src/odometry.cpp#L203 is an example of an odometry producer that does this, and its output could be consumed by multiple consumers, not all able to handle the twist covariance if it were zero or very close to it.