Drake joint/dof limit semantics confuse ~everyone

[ggould-tri]

This is a highly speculative feature request, and I am creating it mostly to have an issue number to refer to as it continues to vex.

Is your feature request related to a problem? Please describe. We have had frequent confusions about whether Drake joint limits are constraints, ie, users expecting an error if they are violated, or writing code assuming that they represent bounds on the state space.

The correct interpretation -- that limit violations are commonplace and indeed expected in most equilibria -- is counterintuitive, and an error that even the most experienced Drake developers make; it would be foolish to expect our users to understand what even our developers struggle with.

Examples of people being misled by the semantics include:

• 15765 (proposing an error for violations), and on slack at https://drakedevelopers.slack.com/archives/C2WBPQDB7/p1631224880004600

• https://github.com/RussTedrake/manipulation/blob/511b26bb4871e8d07c670de70bd4bdd4eef7be0d/manipulation/envs/box_flipup.py#L228-L234 (Russ himself making the state space bounds error)
• https://stackoverflow.com/questions/61605694/how-to-implement-joint-limits-for-discrete-multibodyplant-simulation (inter alia) on stack overflow

Describe the solution you'd like

I don't know what the answer is, but I think solutions fall into three buckets:

Describe alternatives you've considered

• Admit defeat; somehow change the limit behaviour. I cannot imagine how to do this, but perhaps Dynamics has ideas?
• Find the place in the documentation that people could have discovered this more easily. But if even Russ can be fooled, this seems like a lost cause?
• Get a warning or error message into some common-case pathways -- an error on excessive penetration would address the stackoverflow question, e.g., and a method for computing practical state-space bounds might prevent things like the manipulation-repo code from arising in the first place.

[ggould-tri]

18756 is this issue again; https://drakedevelopers.slack.com/archives/C2WBPQDB7/p1676472897897249 on slack.

[amcastro-tri]

Related discussion in DrakeDevelopers Slack.

Even though the SAP solver models all constraints as compliant, it estimates a stiff set of parameters that prevent ill-conditioning of the problem. Therefore, even when constraint violations are expected (since the underlying model is compliant), these are significantly smaller than when using TAMSI.