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

[yschulz]

🦟 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.

[azeey]

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

[yschulz]

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

[yschulz]

@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 to take another look.

[iche033]

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.

[iche033]

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))

[iche033]

coding style nit:

Suggested change

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

[azeey]

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?

[yschulz]

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]

cc @scpeters

[scpeters]

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]

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