Closed dmcconachie-tri closed 4 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.
@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?
The MultibodyPlantConfig::time_step
default is 1ms, so I'd posit that's a good default for the planner as well.
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.
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.
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.)
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
Hmm, I didn't actually do end-to-end tests with some of those sample models. Possibly mimic joint visualization still doesn't work.
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.
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 viaVersion
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