Skip to content

Include user sensor dimension in model signature - #3485

Open
ousamabenyounes wants to merge 4 commits into
google-deepmind:mainfrom
ousamabenyounes:fix/issue-3307
Open

Include user sensor dimension in model signature#3485
ousamabenyounes wants to merge 4 commits into
google-deepmind:mainfrom
ousamabenyounes:fix/issue-3307

Conversation

@ousamabenyounes

Copy link
Copy Markdown

Summary

mjCModel::Signature() serialized each sensor's type but not its dim. For
mjSENS_USER, the sensor dim directly determines nsensordata and therefore
the compiled model's memory layout. As a result, two models differing only in a
user sensor's dimension produced identical signatures despite different layouts.

This appends the sensor dim to the signature string and adds a regression test.

Fixes #3307

Change

src/user/user_model.cc — serialize spec.dim after spec.type for each
sensor in the signature string.

Test verification (RED → GREEN)

New test SensorTest.UserSensorDimAffectsModelSignature compiles two models with
user sensors of dim=100 and dim=200 and asserts their signatures differ.

RED — new test on the unmodified upstream base (fix reverted, test only):

[ RUN      ] SensorTest.UserSensorDimAffectsModelSignature
test/user/user_objects_test.cc:588: Failure
Expected: (model1->signature) != (model2->signature), actual: 1677162445386741321 vs 1677162445386741321
[  FAILED  ] SensorTest.UserSensorDimAffectsModelSignature
 1 FAILED TEST

GREEN — with the fix:

[ RUN      ] SensorTest.UserSensorDimAffectsModelSignature
[       OK ] SensorTest.UserSensorDimAffectsModelSignature
[  PASSED  ] 1 test.

No regression: user_recompile_test (which checks signature stability across
recompile/copy for every bundled model) still passes — the added dim is applied
symmetrically to both sides of every signature comparison.

Note

This completes the approach approved in #3308, which stalled on the CLA and was
closed. This PR uses RAII (MjModelPtr) for model cleanup and ships the
regression test.

yuvaltassa and others added 4 commits August 16, 2026 00:05
Three diagnostics that clang does not emit, so they were missed until the
gcc-14 CI jobs, which build with -Werror:

- mji_scl3 takes a restrict-qualified destination, so passing the same array
  as source and destination is undefined. Two calls did: negating the edge
  separating axis, and halving the witness midpoint. The first now negates in
  place, the second forms the midpoint directly.
- Adding const to a pointer to array is not a valid implicit conversion before
  C23. The pointer it qualified was a redundant alias of the clip buffer, and
  is removed.

No functional change: the box-box fuzzer's output hash over 60k configurations
is identical before and after.
- The 25-line comment describing the collider's two stages, the reference and
  incident face convention, and why the manifold is not reduced below the
  clipped polygon. The last paragraph is load-bearing: reducing the patch to
  four points is what an earlier draft did, and it costs two to three orders of
  magnitude of residual motion on stacks of plates.

- contact_net.xml's b1 orientation, from euler="5 4 3" back to "5 5 5". The
  re-posed model does not converge under mjUSESINGLE: SensorTest.ContactNet
  spends minutes in mj_solPrimal instead of hundredths of a second, so the
  single-precision suite never finishes. The original orientation passes in
  both precisions with the current collider, in 0.02s and 0.01s.

No functional change to the collider: the box-box fuzzer's output hash over 60k
configurations is unchanged.
On mjWARN_BADQACC the warning handler resets mjData, which rewinds data->time
to one timestep. A loop conditioned on data->time then cannot terminate: the
model diverges, resets, falls, diverges again, indefinitely. Every step is
sub-millisecond, so it presents as a compute hang rather than a failure, and a
CI job sits in it until the runner is killed. This test hit that under
mjUSESINGLE: 100k steps without data->time reaching 0.2.

Bounding by step count turns the same event into a prompt failure. 80 further
occurrences of the idiom remain across the test suite; they are only latent as
long as their models do not diverge.
mjCModel::Signature() serialized each sensor's type but not its dimension.
For mjSENS_USER the sensor dim determines nsensordata and therefore the
compiled model's memory layout, so two models differing only in a user
sensor's dim produced identical signatures despite different layouts.

Include the sensor dim in the signature string and add a regression test.

Fixes google-deepmind#3307
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

User sensor's dim does not change model's signature

2 participants