Non-Repeatability in KinematicTrajectoryOptimization

[cohnt]

What happened?

Per the discussion in this stackoverflow post and a discussion with @hongkai-dai, I've been able to construct a trajopt instance where MathematicalProgram has nondeterministic behavior. It can be found here -- if one examines the SNOPT logs, they clearly diverge at some point during the solve. I'm suspicious of the MinimumDistanceLowerBoundConstraint, given that the logs are identical if that constraint is removed.

Version

No response

What operating system are you using?

No response

What installation option are you using?

No response

Relevant log output

No response

[hongkai-dai]

@cohnt in your python script, it looks for package://se3maze/models/maze.sdf and package://se3maze/models/box.sdf. I don't have these two sdf files. Could you share the sdf files as well? Thanks!

[cohnt]

A zip file with the models and a package.xml are also included in the gist. You'll just have to unzip it to get the files. (I think gist doesn't allow you to use directories.)

[hongkai-dai]

Sorry it took a while. I have pinned down to the function QueryObject::ComputeSignedDistancePairwiseClosestPoints which return a std::vector<SignedDistancePair<T>> object. For the same input, the returned std::vector should have the same ordering, but in reality the ordering changes.

Here is the computed distances in one call

distances[0]=0.05217582339447376233, grad[25]=0.00000000000000056585, grad[31]=0.00000000000000044963
distances[1]=0.07077759825297903762, grad[25]=-0.35937297264284862042, grad[31]=-0.28555681000760274602
distances[2]=0.04804141069317556523, grad[25]=-0.53185542592967094411, grad[31]=-0.42261090948719659544

Here is the output in another call

distances[0]=0.04804141069317556523, grad[25]=-0.53185542592967094411, grad[31]=-0.42261090948719659544
distances[1]=0.05217582339447376233, grad[25]=0.00000000000000056585, grad[31]=0.00000000000000044963
distances[2]=0.07077759825297903762, grad[25]=-0.35937297264284862042, grad[31]=-0.28555681000760274602

I will open a separate github issue to track this (since the problem is not in KinematicTrajectoryOptimization, but in evaluating signed distance in our collision engine).

[jwnimmer-tri]

To be sure I'm following... the distance returned are always the same bit-exact set, but just in a different order?

We eventually pass those distances to math::SoftOverMax to fold. With infinite-precision real numbers, input order would not affect its output, but with floating point round-off during the summation, the input order of the distances can affect the some low-order bits of the result?

[hongkai-dai]

Yes, the distance is the same bit-exact set, just the ordering is different, and math::SoftOverMax can generate slightly different result (differ by 1E-15) due to the ordering change.

[cohnt]

Confirmed that merging #21698 fixes this issue.