Should collision objects allow separate colors per primitive/mesh, rather than be unicolored?

[ANogin]

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

Current Planning Scene API assumes that each attached object has a single color. E.g. in the C++ API, there are PlanningScene::setObjectColor and PlanningScene::getObjectColor that operate per object, and in the PlanningScene message, there is the object_colors array at the top level, where each element references the corresponding object by its id.

This is in contrast with e.g. a URDF representation of objects, where a link could have multiple visual components, each with its own color (or material).

Describe the solution you'd like

I am thinking the least disruptive way would be to extend the ObjectColor message to add primitive_colors and mesh_colors arrays with the following semantics:

• primitives in Collision object's primitives array would be colored using primitive_colors, but if the length of primitives is longer than primitive_colors, then the remaining primitives would be colored according to the color value
• similarly for meshes and mesh_colors

Note that the above specification implies, in particular, than when both primitive_colors and mesh_colors are empty, then the value of the color field in the ObjectColor message would be used for everything, therefore maintaining the current behavior.

Similarly, PlanningScene::setObjectColor and PlanningScene::getObjectColor C++ API calls would be extended to take optional primitive_colors and mesh_colors arguments.

Describe alternatives you've considered

Another option would be to directly embed the mesh and primitive colors into CollisionObject. One of the downsides of this approach would be having to retransmit the whole object just to change its color in an is_diff = true scene message, and generally having to update how certain things are done a lot more than with the ObjectColor proposal.

Additional context

No response

[sea-bass]

I think the proposal makes sense, noting:

• Message definition changes cannot be backported, so this can go into Rolling only.
• An example/test of such a composite object (a mesh + 2 collision primitives, for example) would be good
• The workflow for coloring an attached object purple and resetting its color when unattached (which could be heterogeneous after this update) should be tested.