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.

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

Allow customization of contact surface properties #267

Merged
merged 16 commits into from
Oct 28, 2021

Conversation

peci1
Copy link
Contributor

@peci1 peci1 commented Jun 20, 2021

🎉 New feature

Closes #15, #82

Depends on gazebo-forks/dart#22 .

Is needed for gazebosim/gz-sim#869 and osrf/subt#958.

Summary

This PR adds support for registering callbacks that modify properties of all contact joints generated by the dynamics engine. Example implementation for DART is provided.

This feature might be highly useful for DARPA SubT virtual challenge to allow implementation of a proper track drivetrain.

Test it

Testing is best done by running some of the ign-gazebo examples added in PR #TODO .

Checklist

  • Signed all commits for DCO
  • Added tests
  • Added example and/or tutorial
  • Updated documentation (as needed)
  • Updated migration guide (as needed)
  • codecheck passed (See contributing)
  • All tests passed (See test coverage)
  • While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge

@peci1
Copy link
Contributor Author

peci1 commented Jun 20, 2021

Videos of ign-gazebo implementation (they only work in Chrome, I don't know why).

ign-tracked1.mp4.mp4
ign-tracked2.mp4.mp4
ign-tracked3.mp4.mp4
ign-tracked4.mp4.mp4

include/ignition/physics/detail/ContactJointProperties.hh Outdated Show resolved Hide resolved
public: template <typename PolicyT, typename FeaturesT>
class World : public virtual Feature::World<PolicyT, FeaturesT>
{
public: using JointPtrType = JointPtr<PolicyT, FeaturesT>;
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: type alias not used anywhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

removed

Copy link
Member

Choose a reason for hiding this comment

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

I think JointPtrType hasn't been removed but is unused

include/ignition/physics/ContactJointProperties.hh Outdated Show resolved Hide resolved
dartsim/src/SimulationFeatures.hh Outdated Show resolved Hide resolved
dartsim/src/SimulationFeatures.cc Outdated Show resolved Hide resolved
include/ignition/physics/ContactJointProperties.hh Outdated Show resolved Hide resolved
dartsim/src/SimulationFeatures.cc Outdated Show resolved Hide resolved
dartsim/src/SimulationFeatures.cc Outdated Show resolved Hide resolved
@peci1
Copy link
Contributor Author

peci1 commented Aug 17, 2021

I updated this PR to work with the latest changes in DART, and I addressed the two issues found in review.

@azeey azeey requested a review from scpeters as a code owner October 6, 2021 19:08
@azeey
Copy link
Contributor

azeey commented Oct 6, 2021

I think we can actually target ign-physics2. I'll go ahead and do that.

Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
@azeey azeey changed the base branch from ign-physics3 to ign-physics2 October 6, 2021 19:32
@codecov
Copy link

codecov bot commented Oct 6, 2021

Codecov Report

Merging #267 (6a1c257) into ign-physics2 (f1aee5a) will increase coverage by 0.07%.
The diff coverage is 88.18%.

Impacted file tree graph

@@               Coverage Diff                @@
##           ign-physics2     #267      +/-   ##
================================================
+ Coverage         83.16%   83.23%   +0.07%     
================================================
  Files               106      108       +2     
  Lines              4051     4158     +107     
================================================
+ Hits               3369     3461      +92     
- Misses              682      697      +15     
Impacted Files Coverage Δ
dartsim/src/SimulationFeatures.cc 82.90% <85.00%> (-3.59%) ⬇️
dartsim/src/SimulationFeatures.hh 100.00% <100.00%> (ø)
...clude/ignition/physics/detail/ContactProperties.hh 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f1aee5a...6a1c257. Read the comment docs.

@azeey azeey added 🏰 citadel Ignition Citadel and removed 🔮 dome Ignition Dome labels Oct 6, 2021
azeey and others added 2 commits October 11, 2021 14:18
This allows CI to pass on Focal.

Signed-off-by: Addisu Z. Taddese <addisu@openrobotics.org>
…zation.

Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
@peci1
Copy link
Contributor Author

peci1 commented Oct 24, 2021

I started working on adding the tests, but got stuck for some time because CMake told me DART does not support contact surface customization (even after resetting cache). Please check be31da3 which fixed it for me.

Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
@peci1
Copy link
Contributor Author

peci1 commented Oct 25, 2021

I extended the RetrieveContacts test to also check the functionality of the callback. It does not check it extensively, but the basic functionality is covered. What remains untested is e.g. the case when one collision shape has more contact points on it.

I ran the changed test with both DART_HAS_CONTACT_SURFACE_HEADER set to true and false and both compiled and succeeded.

A few things surprised me, but are not necessarily wrong:

  1. When DART creates the contact joint, but before the forward step is run, the contact joint force is reported to be zero. I'll add a comment about this so that it doesn't surprise more users.
  2. The first frictional direction computed in the contact.sdf world for the spheres is [0, 0, 1] which is weird because it is parallel to the contact normal. I'd expect something in the XY plane. The spheres do not change the direction settings, and SDF defaults to [0, 0, 0] which means (IMO) to compute the direction from the relative motion of the colliding bodies (but I always thought the result has to be perpendicular to the contact normal).
  3. Although the spheres intersect the ground plane (do not just touch it with their apex), each reports only a single contact point in the axis of the sphere. That's weird, I'd expect a circle of points. But it's probably how the particular collision engine works.

Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
@azeey
Copy link
Contributor

azeey commented Oct 25, 2021

I started working on adding the tests, but got stuck for some time because CMake told me DART does not support contact surface customization (even after resetting cache). Please check be31da3 which fixed it for me.

Yes, I was working on that last week and came to the same fix, I just hadn't pushed. I thought it was working properly before this fix, but I realized I was seeing the cached results.

peci1 and others added 2 commits October 25, 2021 19:12
Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
Signed-off-by: Addisu Z. Taddese <addisu@openrobotics.org>
@azeey
Copy link
Contributor

azeey commented Oct 25, 2021

The logs from the macOS build showed ContactSurface.hh was not found. 7ca8007 fixes the problem.

if (!warnedSecondaryRollingFrictionCoeff &&
pIgn.secondaryRollingFrictionCoeff)
{
ignwarn << "DART doesn't support secondary rolling friction setting"
Copy link
Member

Choose a reason for hiding this comment

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

one of my goals for the Feature system is that physics engine plugins can express what they do and do not implement, so you don't have to rely on console messages like this one. I discussed this with @azeey, and I think the API based on contact callback functions and single struct data structure make sense for performance reasons, so I wouldn't try to change that. I do, however, think that we could add Features to signal which parameters a physics engine claims to support. I will create an issue for this.

Copy link
Member

Choose a reason for hiding this comment

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

Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
Copy link
Contributor

@azeey azeey left a comment

Choose a reason for hiding this comment

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

This is great! Thanks for the contribution!

Copy link
Member

@scpeters scpeters left a comment

Choose a reason for hiding this comment

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

my apologies for all these renaming requests, but I'd like to see Joint removed from the Feature and header file name, since while some physics engines treat contacts as joints, not all do

so please rename to include/ignition/physics/ContactProperties.hh and SetContactPropertiesCallbackFeature

public: template <typename PolicyT, typename FeaturesT>
class World : public virtual Feature::World<PolicyT, FeaturesT>
{
public: using JointPtrType = JointPtr<PolicyT, FeaturesT>;
Copy link
Member

Choose a reason for hiding this comment

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

I think JointPtrType hasn't been removed but is unused

Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
Signed-off-by: Martin Pecka <peckama2@fel.cvut.cz>
@peci1
Copy link
Contributor Author

peci1 commented Oct 28, 2021

That's okay, it makes sense to not mention the joint if it's not called like that everywhere.

@azeey azeey merged commit 1fd83e0 into gazebosim:ign-physics2 Oct 28, 2021
Core development automation moved this from In review to Done Oct 28, 2021
@peci1
Copy link
Contributor Author

peci1 commented Oct 28, 2021

Thanks for getting this merged! Should the followup Gazebo part also target Citadel, or will we keep it targeted at Dome?

@azeey
Copy link
Contributor

azeey commented Oct 28, 2021

Yes, targetting Citadel would be great if possible.

@chapulina chapulina moved this from Done to Highlights in Core development Nov 1, 2021
@chapulina chapulina removed the needs upstream release Blocked by a release of an upstream library label Nov 1, 2021
@j-rivero j-rivero removed this from Highlights in Core development May 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏰 citadel Ignition Citadel DART DART engine
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants