[examples] Schunk WSG modeling is confusing, nonphysical, abuses System

[ggould-tri]

This issue records a conversation between myself and @sammy-tri about the state of WSG modeling.

For reference, the real WSG is actuated by a toothed belt that enforces a symmetric motion constraint between its fingers. It is commanded via UDP packets that command a target position and a force limit to be used in reaching that position. A driver presents this as an LCM endpoint, periodically sending a UDP command matching the most recent received LCM and and an LCM status message matching the most recent received UDP. In the absence of received LCM, the driver commands zero force -- in effect leaving the gripper to hold position with its (considerable) internal stiction alone.

By contrast the simulated WSG consists of a number of components, described in https://github.com/RobotLocomotion/drake/blob/master/manipulation/schunk_wsg/schunk_wsg_plain_controller.h . Notably, the simulation imagines a "controller" layer that models all of (1) the driver, (2) the gripper firmware, (3) the physical transmission between the motor and the fingers, and (4) the physical belt drive that enforces the finger symmetry constraint. By confounding the notions of the physical state of the belt drive and the commanded gripper state, the controller creates a hidden state problem whereby the initial conditions of a plant are unrelated to the initial conditions of the gripper's "controller" in a nonphysical way, resulting in the plant's initial state being wiped out by massive restoring forces in the first tick of simulation.

The most concrete manifestation of this is in schunk_wsg_controller.cc initializing with the default ctor argument for position in instantiating its SchunkWsgCommandReceiver regardless of either (1) The initial state of the plant, or (2) the fact that the Schunk driver defaults to zero force. This means in effect that SchunkWsgCommandReceiver is storing state information in a System class, and that that information is also wrong.

Frankly this whole section of the code is a mess, and I hesitate to get into it. It needs a complete rewrite in terms of symbolic expressions, with awareness of friction, or else in terms of some future loop joint mechanism. Failing that it at least needs a parameter exposing the SchunkWsgCommandReceiver ctor arguments, which are zero in the real world.

[avalenzu]

Now that the bushing element can be parsed from SDF, should we consider un-doing #8819 and seeing if we can live with the simulation speed of the closed-loop model?

[jwnimmer-tri]

The actual solution here should be to switch to using a mimic joint and implicit PD control.