Is your feature request related to a problem? Please describe.

Currently, each ArmttachedObject can be specified with a touch_links array that makes it allowable for the object to collide with the given robot links. However, any pair of separate attached objects, unless they are attached to the same robot link (and therefore their relative position would never change) is always checked for collisions:

Imagine a use case of e.g. a robot with two manipulators, each with an object attached, where MoveIt IK and path planning are used to get the two objects to touch - right now this is impossible to do, at least in a straightforward way. Ideally, it should be possible to allow specific object/object collisions, similarly to how it is already possible to allow link/link and object/link collisions.

Describe the solution you'd like

I think the most straightforward way would be to just overload touch_links, making it possible to also include names of other attached objects there. If at least one of the two objects contains the other's name in its touch_link, then the collision would be allowed. At least for my use case, it appears that only the above-quoted lines have to be modified.

Describe alternatives you've considered

One downside of overloading the touch_links is that the field name would become a misleading. Also, I do not know whether it is possible to have an attached object with the same name as an existing link - if so, the proposed approach would clearly cause problems.

An alternative would be to create a separate touch_objects paralleling touch_links. Of course that would require a bunch of API and message type changes, and would potentially be a lot more invasive.

Finally, it may be a bit safer to only allow collisions when both objects include the other one in their touch_links. However, this is likely to necessitate additional somewhat messy code on the part of the user of the API, keeping the two sides in sync every time a collision is allowed or disallowed, and my expectation is that the "collisions are allowed when at least one object names the other in touch_links" semantics would be easier to use than "each object names the other" semantics.

Additional context

No response