Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Extract extended contact data (force, normal, penetration depth) #179

Closed
wants to merge 5 commits into from
Closed

Extract extended contact data (force, normal, penetration depth) #179

wants to merge 5 commits into from

Conversation

diegoferigo
Copy link
Collaborator

@diegoferigo diegoferigo commented Apr 20, 2020 •
edited
Loading

This PR shows how gazebosim/gz-physics#40 could be used to extract data provided by the DART ign-physics plugin.

Still in WIP state waiting to receive feedback from upstream.

@diegoferigo diegoferigo self-assigned this Apr 20, 2020
@diegoferigo diegoferigo force-pushed the refactor/extend_contact_data branch from bead1a5 to 43477f4 Compare April 20, 2020 17:13
@diegoferigo diegoferigo force-pushed the refactor/extend_contact_data branch from 43477f4 to ff81894 Compare April 20, 2020 17:15
@diegoferigo diegoferigo requested a review from traversaro April 20, 2020 17:19
@diegoferigo
Copy link
Collaborator Author

@traversaro this PR is ready to be reviewed even though it all depends on how the upstream PR will be handled. Can you please double check the method Link::contactWrench()? Tests on my machine pass and it should be fine, but all of them use a planar surface.

raffaello-camoriano
raffaello-camoriano approved these changes Apr 26, 2020
View reviewed changes
Copy link
Collaborator

@raffaello-camoriano raffaello-camoriano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

tests/test_scenario/test_contacts.py
Comment on lines +205 to +206
assert contact1.bodyB == "cube1::cube"
assert contact2.bodyB == "cube2::cube"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is cube1::cube always associated with contact1 (and cube2 with contact2)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the simulation is reproducible this order is always respected. Though, I had to check beforehand because in cases like this in which contacts are created in the same moment you cannot know a priory how contacts get detected.

@diegoferigo diegoferigo closed this May 3, 2020
@diegoferigo
Copy link
Collaborator Author

diegoferigo commented May 5, 2020 •
edited
Loading

Damn, I forgot to change the target branch to devel before merging refactoring. Now github does not allow to me to change the targeted branch. I guess I have to reopen a new PR. Let's wait some upstream activity before doing it.

@diegoferigo diegoferigo mentioned this pull request Jul 7, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@raffaello-camoriano raffaello-camoriano raffaello-camoriano approved these changes

@traversaro traversaro Awaiting requested review from traversaro

Assignees

@diegoferigo diegoferigo

Labels
complexity::medium pr::resolution::withdrawn
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@diegoferigo @raffaello-camoriano