gz-physics
gz-physics copied to clipboard
Implement SDF `<category_bitmask>`
Desired behavior
SDF has the <category_bitmask>
element which acts together with <collision_bitmask>
. Using these two, up to 16 categories can be defined and each object can selectively collide or not with each of the categories. So far, ign-physics implements only the default value of <category_bitmask>
described in SDF, which is the same value as <collision_bitmask>
. This decreases the versatility of the whole feature, as now you have to say that each object collides with all other objects sharing at least one category with it.
Here's an example to illustrate how much more powerful is the combination of categories and collision bitmasks. I have a tracked robot with tracks emulated by overlapping wheels. And say I have a front track and rear track, and they can be moved so that they could collide. And I don't want wheels inside one track to collide. With properly supported categories, I can set category 0b01
to front tracks and 0b10
to rear tracks, and collision masks to the opposites (0b10
and 0b01
). With the current state, I have to create a Cartesian product of all wheels in both tracks and set their bitmasks as e.g. 0b0000,0000,1111,0000
for front track wheel 2 and 0b0010,0010,0010,0010
for rear track wheel 2 (in front track, there's a block of 1111
moving 4 bits each wheel, and in rear track, there is a block of 0010
applied each 4 bits). This way, 4 wheels on a pair of tracks can be handled (not more, as the bitmask is only 16-bit). With categories, it would be infinite number of wheels the framework could support.
Alternatives considered
This worked somehow in Gazebo Classic, but not exactly as the SDF spec says: https://github.com/osrf/gazebo/issues/1855 .
Implementation suggestion
I don't provide a PR myself because I can't imagine all the places such change could bubble to (at least to ign-gazebo once it's supported here).
Additional context
This issue is basically just a tracking issue for the support of <category_bitmask>
.
While attempting to exploit bitmasks to set up collision checking for a complex scenario with many collision objects, I also found pretty restrictive the limitation of using <collide_bitmask>
only. Is there any update on the support for <category_bitmask>
?
I totally agree on the advantages of using both <collide_bitmask>
and <category_bitmask>
for setting up collision checking illustrated in the initial comment of this issue. It would be extremely useful to have this feature implemented!