An Isaac Lab contact sensor can report the net normal contact force on its measured body and, with filtering, the force associated with selected counterpart objects. A foot resting on the ground can therefore have a nonzero net force while its cube-filtered force is zero. Those outputs answer different questions about the same foot.
Choose the question before designing the sensor. “Is this foot loaded?” needs a body-level result. “How much of the reported contact force comes from this box?” needs counterpart filtering and an explicit mapping between sensor bodies and filter targets.
The cube example separates load from attribution
The official Contact Sensor example places a cube under one front foot of an ANYmal robot. Each front foot has its own sensor, with the cube selected as a filter target. Both feet can report net contact force, but the foot away from the cube has a zero cube-filtered result.
Filtering does not turn the net-force field into “force from the filter.” The two outputs remain separate. In an application, retain both field names when logging them; a generic column called force would conceal which measurement a reward or termination rule used.
| Output | Question it answers | Reading to avoid |
|---|---|---|
net_forces_w |
What is the resultant reported normal contact force on each measured body? | Treating it as force from one selected object |
force_matrix_w |
What force is attributed to the configured counterpart filters? | Treating a zero filtered entry as an unloaded body |
| Body identity and order | Which physical link corresponds to each row? | Assuming a row is a particular foot without checking the resolved bodies |
The implementation at the checked revision describes normal contact forces in world coordinates. That scope is narrower than all forces acting on a link: gravity, actuator forces and other externally applied forces are not interchangeable with this contact field. Likewise, a vector norm discards direction; preserve the vector if the analysis depends on which way the contact acts.
Draw one measured body and its counterparts
The prose tutorial calls filtering “many-to-one,” while the source docstring calls it “one-to-many.” The concrete topology resolves the wording: a single sensor body can be filtered against several counterpart bodies. To query several robot feet against selected objects, the implementation’s stated approach is a separate sensor for each foot.
For example, name the left-foot body as one sensor’s scope and the platform and cube as its counterpart targets. Repeat for the right foot if both feet need object-specific attribution. That design keeps a clear answer to “which foot, against which object?”
A multi-body sensor is still useful for obtaining body-level net-force rows. In the tutorial’s hind-foot example, two feet share a sensor and the filtered matrix is None. Treat that as an unavailable filtered output for the demonstrated configuration, not as a matrix of measured zero forces. Whether an output is absent, zero or nonzero changes the interpretation of a contact event.
A force tensor needs its body names and time basis
The source allocates net_forces_w with environment, sensor-body and XYZ dimensions. When filters are configured, the force matrix adds a filter dimension. Log the resolved body names and filter configuration alongside the shape; a tensor with the expected dimensions can still have its rows assigned incorrectly in downstream code.
The same implementation obtains the PhysX contact-force values using the simulation’s physics timestep. Do not reinterpret a returned force as impulse and divide it by a logging interval again. A separate SAPIEN contact explanation in Korean starts from per-contact impulse, which is a different API contract.
A useful proposed check uses three distinct conditions: the foot touches only the ground, only the selected platform, and both. Inspect the net vector and each available filtered vector before deriving a binary contact flag. Then move the contact to another foot to check the row-to-body mapping. These checks were not executed for this article.
Connect the measurement to one control decision
For a contact-dependent reward, decide whether the rule concerns any supporting contact or a particular object. Use a body-level net-force condition for the former and a verified filtered field for the latter. Keep the threshold and coordinate interpretation with that rule.
This article uses the Isaac Lab main tutorial and source revision b0542fe2d45bf91c4e1d9ef6952b9c709c80b4e8, checked October 16, 2026. Its practical result is a sensor layout and a log whose body, counterpart and vector meaning remain visible throughout the control calculation.