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

Contact system: don't use 'EachNew' in PreUpdate #2303

Open
wants to merge 3 commits into
base: gz-sim8
Choose a base branch
from

Conversation

yschulz
Copy link

@yschulz yschulz commented Feb 2, 2024

🦟 Bug fix

Fixes #2223

Summary

The contact sensor system plugin could not be created through the UserCommand system and the factory service. The reason was a call to EachNew in the PreUpdate step. Similar to #1523 and as part of #1281 this PR separates the component from sensor creation in the pre and post updates.

Checklist

  • Signed all commits for DCO
  • Added tests
  • Updated documentation (as needed)
  • Updated migration guide (as needed)
  • Consider updating Python bindings (if the library has them)
  • 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 and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

@github-actions github-actions bot added the 🎵 harmonic Gazebo Harmonic label Feb 2, 2024
@azeey
Copy link
Contributor

azeey commented Feb 2, 2024

Thanks for the contribution @yschulz. It looks like this broke the TouchPlugin tests. Can you take a look?

@yschulz
Copy link
Author

yschulz commented Feb 2, 2024

I noticed, I will have a look first thing on Monday.

@yschulz
Copy link
Author

yschulz commented Feb 4, 2024

@azeey I had look earlier.

What happens is that most tests failed, except the parent entity removal and entity spawning test. So basically I created the inverse Problem. Starting the TouchPlugin via the create service works fine, but starting it through the SimulationRunner breaks it.

As far as I understand, the TouchPlugin requires the collision components (with ContactSensorData), that the Contact system creates in its PreUpdate, already created in its own PreUpdate function.

Also, as I can see, the major difference is that SimulationRunner runs each systems PostUpdate function before running sequential simulation steps, which explains why that happens.

I fixed the failing tests now by adding a check to the TouchPlugin PreUpdate function so it only runs when it already ran once before.

However, I am not sure if that is a desired fix for the problem.

@azeey azeey self-requested a review February 12, 2024 18:55
@azeey azeey self-assigned this Feb 28, 2024
@azeey
Copy link
Contributor

azeey commented Jun 10, 2024

@azeey to take another look.

@azeey azeey added the beta Targeting beta release of upcoming collection label Jul 29, 2024
Copy link
Contributor

@iche033 iche033 left a comment

Choose a reason for hiding this comment

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

I fixed the failing tests now by adding a check to the TouchPlugin PreUpdate function so it only runs when it already ran once before.

However, I am not sure if that is a desired fix for the problem.

I added a comment regarding this. We can check to make sure the ContactSensorData component type exists first before initializing the touch plugin.

@@ -384,7 +387,8 @@ void TouchPlugin::Configure(const Entity &_entity,
void TouchPlugin::PreUpdate(const UpdateInfo &, EntityComponentManager &_ecm)
{
GZ_PROFILE("TouchPlugin::PreUpdate");
if ((!this->dataPtr->initialized) && this->dataPtr->sdfConfig)

if ((!this->dataPtr->initialized) && this->dataPtr->sdfConfig && this->dataPtr->ranOnce)
Copy link
Contributor

Choose a reason for hiding this comment

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

instead of using ranOnce, you can check to make sure the ContactSensorData component type exists first:

Suggested change
if ((!this->dataPtr->initialized) && this->dataPtr->sdfConfig && this->dataPtr->ranOnce)
if ((!this->dataPtr->initialized) && this->dataPtr->sdfConfig &&
_ecm.HasComponentType(components::ContactSensorData::typeId))

continue;
}

for(const auto &collisionEntity : it->second->collisionEntities){
Copy link
Contributor

Choose a reason for hiding this comment

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

coding style nit:

Suggested change
for(const auto &collisionEntity : it->second->collisionEntities){
for (const auto &collisionEntity : it->second->collisionEntities)
{

@azeey
Copy link
Contributor

azeey commented Aug 7, 2024

One thing I realized about this PR is that it's trying to spawn the Contact system as part of a model, but that system is meant to be attached to the world, so the problem described as is may not be valid. That being said, if the Contact system is specified before the UserCommands system in <world>, we would still have a problem. Steve's recent work in #2487 can used to ensure that UserCommands comes before Contact, so maybe we should pursue that?

@scpeters scpeters changed the title Don't use 'EachNew' in Contact PreUpdate function Contact system: don't use 'EachNew' in PreUpdate Aug 14, 2024
@yschulz
Copy link
Author

yschulz commented Aug 19, 2024

I just had a look at the PR and indeed, that makes for a much cleaner solution. This also eliminates the need to delay the TouchPlugin creation as it is right now.
Any suggestion or convention on how to set a meaningful range for the priority cascade? I see the examples indicate a logarithmic approach here I will update this pr as soon as I can.

@azeey
Copy link
Contributor

azeey commented Aug 19, 2024

cc @scpeters

@scpeters
Copy link
Member

I just had a look at the PR and indeed, that makes for a much cleaner solution. This also eliminates the need to delay the TouchPlugin creation as it is right now. Any suggestion or convention on how to set a meaningful range for the priority cascade? I see the examples indicate a logarithmic approach here I will update this pr as soon as I can.

I used a logarithmic progression in the example because it's easier for me to visually see that numbers with more digits are larger. I also used a logarithmic progression in #2500, but a linear progression could be used as well. If you anticipate a cascade of N systems, then having a priority difference of at least N would be useful.

@scpeters
Copy link
Member

I just had a look at the PR and indeed, that makes for a much cleaner solution. This also eliminates the need to delay the TouchPlugin creation as it is right now. Any suggestion or convention on how to set a meaningful range for the priority cascade? I see the examples indicate a logarithmic approach here I will update this pr as soon as I can.

For harmonic, we backported the ability to set system priority explicitly in xml in a world file, but we made a better fix in Ionic, which sets some default system priorities to better values, including the UserCommands system. Would you be willing to test the new behavior with Ionic to see if a change is needed there? We would still be willing to merge a fix for Harmonic, but I'd like to know if it's a fix that we shouldn't merge forward or if a fix is needed in both places

@azeey azeey removed the beta Targeting beta release of upcoming collection label Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🎵 harmonic Gazebo Harmonic
Projects
Status: In review
Development

Successfully merging this pull request may close these issues.

System plugins (contact sensor) still not working when spawned
4 participants