Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dmcconachie-tri opened this issue Mar 5, 2024 · 9 comments · Fixed by #21098
Closed
Assignees
Labels
component: planning and control Optimization-based planning and control, and search- and sampling-based planning priority: medium type: bug

Comments

@dmcconachie-tri
Copy link
Contributor

dmcconachie-tri commented Mar 5, 2024

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

71b3913

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
Copy link
Collaborator

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
Copy link
Collaborator

@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 jwnimmer-tri self-assigned this Mar 5, 2024
@jwnimmer-tri jwnimmer-tri added the component: planning and control Optimization-based planning and control, and search- and sampling-based planning label Mar 5, 2024
@jwnimmer-tri
Copy link
Collaborator

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

@dmcconachie-tri
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Collaborator

jwnimmer-tri commented Mar 6, 2024

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
Copy link

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.

@github-project-automation github-project-automation bot moved this from In Progress to Done in #dynamics (Drake board) Apr 4, 2024
@jwnimmer-tri
Copy link
Collaborator

jwnimmer-tri commented Apr 5, 2024

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
Copy link
Collaborator

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.

@github-project-automation github-project-automation bot moved this from In Progress to Done in #dynamics (Drake board) Apr 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: planning and control Optimization-based planning and control, and search- and sampling-based planning priority: medium type: bug
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants