Fix issue with removing skeletons without shapes#1625
Merged
jslee02 merged 2 commits intodartsim:mainfrom Dec 18, 2021
Merged
Conversation
When `subscribeTo` is called with a skeleton in `addSkeleton`, the skeleton is added to `mSkeletonSources`. However, inside `removeSkeleton`, `unsubscribeFrom` is not called. Instead, `removeShapeFrameOf` is called. This is fine for most cases, but if it fails to remove the skeleton from `mSkeletonSources` if the skeleton does not have any shapes within it. This causes `mSkeletonSources` to grow indefinitely. A hazardous side effect of this is that when an attempt is made to add a new skeleton via `subscribeTo`, the address of the skeleton might be the same as one of the stale entries in `mSkeletonSources`. Consequently, the new skeleton's shapes don't get added to the collision detection engine and very surprising results follow. Signed-off-by: Addisu Z. Taddese <addisu@openrobotics.org>
jslee02
requested changes
Dec 18, 2021
| boxShape); | ||
|
|
||
| // Needed to update subscribtions | ||
| world->step(1); |
Member
There was a problem hiding this comment.
Suggested change
| world->step(1); | |
| world->step(); |
I guess you use 1 as the parameter to take a single simulation step, presuming from the gazebo API, but the parameter of World::step() is boolean to set whether reset the commands (e.g., joint forces). You can safely omit the parameter in that case since the function takes single step anyway.
Contributor
Author
There was a problem hiding this comment.
Yup, you guessed right 😄. Removed the parameter in bc78a37.
Signed-off-by: Addisu Z. Taddese <addisu@openrobotics.org>
jslee02
approved these changes
Dec 18, 2021
Member
jslee02
left a comment
There was a problem hiding this comment.
LGTM! Let me create a new PR for updating the changelog for this PR
j-rivero
pushed a commit
to gazebo-release/dart-for-gz-gbp
that referenced
this pull request
Sep 19, 2023
Upstream reviewed and merged the following patches that are important for the robotics community: * Fix grouping of contact constraints dartsim/dart#1624 * Fix issue with removing skeletons without shapes dartsim/dart#1625 Add them in d/patches since upstream does not provide patch releases
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.
Description copied from gazebo-forks#4
When
subscribeTois called with a skeleton inaddSkeleton, the skeleton is added tomSkeletonSources. However, insideremoveSkeleton,unsubscribeFromis not called. Instead,removeShapeFrameOfis called. This is fine for most cases, but it fails to remove the skeleton frommSkeletonSourcesif the skeleton does not have any shapes within it. This causesmSkeletonSourcesto grow indefinitely. A hazardous side effect of this is that when an attempt is made to add a new skeleton viasubscribeTo, the address of the skeleton might be the same as one of the stale entries inmSkeletonSources. Consequently, the new skeleton's shapes don't get added to the collision detection engine and very surprising results follow.Here's a print out of
mSkeletonSourcesafter running several load/unload cycles via the levels feature of ign-gazebo where skeletons are removed and added repeatedly: https://gist.github.com/azeey/8fe5a55d19758923ef7c1b5df90869d3And here's the collision detection failing (failure after the 4th cycle):

Before creating a pull request
clang-formatBefore merging a pull request
CHANGELOG.md