RobotLocomotion / drake

Model-based design and verification for robotics.
https://drake.mit.edu
Other
3.24k stars 1.25k forks source link

`model_visualizer` does not support mimic joints or implicit PD controlled joints #21095

Closed dmcconachie-tri closed 4 months ago

dmcconachie-tri commented 6 months ago

What happened?

model_visualizer does not support modelling choices that are currently only supported by discrete time plants. In one case it throws a warning about ignoring mimic joints, in the other it terminates. This can be reproduced from within anzu via

./run --build '' //models:show models/visuomotor/add_prudential_finray_mimic.dmd.yaml

Version

71b39137e0946f2521171866082df6eaffe71577

What operating system are you using?

Ubuntu 22.04

What installation option are you using?

compiled from source code using Bazel

Relevant log output

WARNING: /home/dmcconachie/coding/anzu/bazel-bin/models/show.runfiles/anzu/models/food_prep/panda_hand_finray_actuated_mesh_mimic.urdf:134: warning: Joint 'panda_finger_joint2' specifies a mimic element that will be ignored. Mimic elements are currently only supported by MultibodyPlant with a discrete time step and using DiscreteContactSolver::kSap.

...

RuntimeError: Continuous model with PD controlled joint actuators. This feature is only supported for discrete models. Refer to MultibodyPlant's documentation for further details.
jwnimmer-tri commented 6 months ago

FYI #18917 is about having the joint sliders actually account for the mimic (so that the joints are dependently postured).

I guess we can keep this issue separate, just about the throwing part.

jwnimmer-tri commented 6 months ago

@calderpg-tri Do you remember why RobotDiagramBuilder defaults to a continuous-time plant? That seems like a trap now, since MbP is extremely finicky now about features that are unsupported in continuous-time plants. Maybe we can change the default to be 1ms or something?

jwnimmer-tri commented 6 months ago

The MultibodyPlantConfig::time_step default is 1ms, so I'd posit that's a good default for the planner as well.

dmcconachie-tri commented 6 months ago

Thanks; I was looking for the joint actuator part of this and didn't see #18917 during my search. I'm fine with leaving this issue as just tracking the joint actuator part.

calderpg-tri commented 6 months ago

IIRC, several years ago the predecessor to RobotDiagram similarly defaulted to a non-zero timestep due to limitations in the continuous-time capabilities. The ideal answer would be a way to specify that the MbP is not being used for simulation at all, but in the absence of that the discrete-time default sounds reasonable.

jwnimmer-tri commented 6 months ago

Well, I was hoping this would be a 10-minute fix so I wrote #21098 to get it out of the way quickly. However, as that CI failure indicates, switching to a discrete time plant for visualization causes the visualizer to throw a different exception now, because it tries to compute inertias even though we're not simulating, and fails some inertia sanity checks. I guess the continuous time plant was ignoring the invalid inertias, or somehow avoided the error. I'll put this onto the backlog again, to schedule into a sprint when we have more time available.

(For the record -- when the exception is thrown, the MbP function on the call stack is MultibodyPlant<double>::CopyContactResultsOutput for visualizing contact results, with SapDriver<double>::CalcContactProblemCache and SapDriver<double>::CalcLinearDynamicsMatrix next on the list.)

MengMengMengH commented 5 months ago

The MultibodyPlantConfig::time_step default is 1ms, so I'd posit that's a good default for the planner as well.

The problem I have met is that when I used the tag “drake:mimic”,everything goes ok at the beginning. But when I want to add a lower controller in my simulation,I was told that I have to use a discrete system,or the drake:mimic joint would be ignored. I did set it as a discrete system.But the controller is a continues system. I have no methods to solve it. Did you meet this problem before? I'm depressed due to this problem.

jwnimmer-tri commented 5 months ago

Hmm, I didn't actually do end-to-end tests with some of those sample models. Possibly mimic joint visualization still doesn't work.

jwnimmer-tri commented 4 months ago

Possibly mimic joint visualization still doesn't work.

Actually, it's mostly fine. It doesn't crash anymore, it just prints a warning: panda_hand_finray_actuated_mesh_mimic.urdf:136: warning: Joint 'panda_finger_joint2' specifies a mimic element that will be ignored. Mimic elements are currently only supported by MultibodyPlant with a discrete time step and using DiscreteContactSolver::kSap. Ideally it would actually enforce the mimic and have one less joint slider dof, but that's out of scope here.