[Question] How to set the 'filter_prim_paths_expr' attribute for ContactSensors correctly?

[TheExplorer95]

Cheers,
I just saw the commit #3563 here and wanted to include the friction forces in my observation space. However, I get the following error:
2026-01-08T16:01:08Z [25,224ms] [Error] [omni.physx.tensors.plugin] Filter pattern '/World/ground/*/mesh' did not match the correct number of entries (expected 118784, found 0)

I generate different terrain for training and evaluation, and name those accordingly. Using the regex expression filter_prim_paths_expr=["/World/ground/.*/mesh"] results in the aforementioned error. Explicitly setting the value to e.g. /World/ground/train/mesh does result in a similar error with changed filter pattern string. (I tried close to any string combination, omitting parts)

Here an image of my stage entities:

Anyone here that could help me out and explain why I'm not able to acquire the friction forces using the used expressions? I'm a bit lost and not sure where I could further dig into and resolve the issue myself.

Thanks!!!

Best Janosch

[RandomOakForest]

Thank you for posting this.You’re hitting that error because the PhysX tensor contact filter expects a fixed, known number of rigid bodies for each filter pattern at sensor creation time, and your regex does not resolve to any rigid body prims (or resolves to a different number than expected) in the current stage layout.¹²

What the error actually means

The message

Filter pattern '/World/ground/*/mesh' did not match the correct number of entries (expected 118784, found 0)

comes from the GPU contact filtering backend in omni.physx.tensors.plugin and does not mean the regex syntax itself is invalid.²³

It means:

• At sensor initialization, Isaac Lab / PhysX computes how many rigid bodies should match each filter_prim_paths_expr pattern and bakes that into the contact tensor setup.⁴⁵
• Later, when it builds/updates the contact tensors, it runs the same patterns and expects to find exactly that many rigid bodies again. If it finds 0 (or any different count), you get this error.¹²

This typically happens if:

• The prims you expect (e.g. /World/ground/train/mesh) don’t exist at the time the sensor is created.³
• Or the prim type / hierarchy changed, so the pattern no longer matches the same set of rigid bodies (e.g. ground mesh moved under a different Xform).³

Why your patterns fail with procedural terrain

With procedurally generated train/eval terrains:

• If terrain is spawned after the contact sensor(s) are configured/attached, your pattern /World/ground/.*/mesh will match 0 prims at sensor setup, so the “expected” count becomes 0; later, when terrain appears, the pattern matches many, causing a mismatch, or vice‑versa.²¹
• If you swap between /World/ground/train/mesh and /World/ground/eval/mesh across resets or different runs, the number of rigid bodies in each mesh can differ, so the filter expects one count (e.g. 118784) and finds another (0 or a different number).¹²

On top of that, the filter works on rigid bodies, not arbitrary prims; if your terrain is not a RigidBody/collider prim (or is nested deeper than your pattern accounts for), the matcher also returns 0.³

How to make it work and get friction forces into observations

To reliably get friction forces from the contact sensor, you need to ensure that:

1. Terrain prims exist before sensor creation

   • Spawn your train/eval terrain meshes before creating the ContactSensorCfg or calling scene.add_* that instantiates the sensors.⁵⁴
   • In RL tasks, that usually means the terrain asset/ground plane is part of the task’s SceneCfg (or spawned in set_up_scene) before ContactSensorCfg is attached.

2. Use patterns that point to the actual rigid body prims

   • Confirm in the stage (USD view) what the rigid body prim paths are for ground: e.g. /World/ground/train/mesh vs /World/ground/train/geometry/mesh_0.
   • Your filter_prim_paths_expr must match the collider/rigid prim, not just an Xform container.⁴³

3. Keep the number of matched bodies constant across runs
   Good patterns in Isaac Lab usually use the environment namespace token:⁴

from isaaclab.sensors import ContactSensorCfg

contact_sensor = ContactSensorCfg(
    prim_path="{ENV_REGEX_NS}/Robot/LF_FOOT",
    update_period=0.0,
    history_length=6,
    debug_vis=False,
    track_friction_forces=True,
    filter_prim_paths_expr=["{ENV_REGEX_NS}/ground/.*/mesh"],
)

• Here {ENV_REGEX_NS} expands to /World/envs/env_\d+ so the sensor and filter prims are both scoped per environment, with fixed per‑env body counts.⁴
• Make sure every env instantiation creates the same number of terrain rigid bodies so the “expected” count is stable.¹

4. Check that friction forces are actually available in the data struct
   In the latest Isaac Lab, friction forces are exposed as part of the contact sensor data if filter_prim_paths_expr is non‑empty:⁵
   • force_matrix_w_history: normal forces between sensor body and filtered bodies.
   • friction_forces_w_history: friction forces between sensor body and filtered bodies.
   • If filter_prim_paths_expr is empty or invalid (pattern mismatch), those fields are None.⁵

A minimal observation snippet after the commit you referenced would look like:

# assuming you added the sensor to the scene with name "contact_forces"
contact_data = scene["contact_forces"].data  # ContactSensorData

# latest net friction forces (no filtering, summed over contacts at each body)
friction_latest = contact_data.friction_forces_w  # (N, B, 3)

# if you enabled history_length > 0, you can use:
friction_hist = contact_data.friction_forces_w_history  # (N, T, B, 3)

# e.g. flatten per-env friction for observations
obs["friction_forces"] = friction_latest.reshape(friction_latest.shape[0], -1)

This may vary eventually depending on the contact sensor data structure from that commit.⁴⁵

5. Avoid changing terrain topology at runtime for the same sensor instance
   If you regenerate terrain with a different mesh resolution or number of sub‑meshes but reuse the same sensor object, PhysX will see a different number of matched rigid bodies and throw the error again.²¹
   • Either keep the number of mesh parts constant, or recreate the scene/sensors when you change terrain discretization.

Footnotes

1. https://github.com/isaac-sim/IsaacLab/issues/364 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. https://forums.developer.nvidia.com/t/gpu-contact-filter-for-collider-is-not-supported/290590 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. https://forums.developer.nvidia.com/t/omni-physx-tensors-plugin-provided-pattern-list-did-not-match-any-rigid-bodies/296418 ↩ ↩² ↩³ ↩⁴ ↩⁵

4. https://isaac-sim.github.io/IsaacLab/main/source/api/lab/isaaclab.sensors.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

5. https://isaac-sim.github.io/IsaacLab/main/source/overview/core-concepts/sensors/contact_sensor.html ↩ ↩² ↩³ ↩⁴ ↩⁵