Model visualizer should know about mimic tags (coupled joints) #18917
Comments
jwnimmer-tri
added
type: feature request
priority: low
component: geometry illustration
|
The limitation is more general than model visualizer. For instance, the inverse dynamics controller currently also falls down if a model is specified with constraints (e.g. I think the right solution is to use a general machinery like Also, if 2 of our university friends are both running into this at the very beginning of their projects, perhaps it deserves a higher priority? |
|
I'd like to have a separate issue for the inverse dynamics controller. Could you please file one explaining what's happening, with a high-level outline of how to reproduce the problem, and what you'd prefer to happen vs what actually happens? I think one thing we lack is any robot model anywhere in Drake that uses mimic joints. We should work to have at least one in-tree, so that the all of us (including the dynamics team) can more easily understand and reproduce problems like this. We can collaborate across the two (or more) mimic-related issues to get the model added -- whichever one gets there first can add the file(s). (Possibly "no example of mimic joints" is documentation-like defect all on its own, and we should open a new issue for it, and coordinate there.) I suspect when we throw it at other subsystems within Drake it will likewise fail to perform as desired. My reasoning for using separate issues is that different people will probably work on them, with different priorities. To my understanding at least, the lack of effective mimic joints in model_visualizer is embarrassing (and maybe should have a warning?) but is not a major roadblock to collaboration. I expect that things like IDC failures are much more of a blocker, so we should prioritize them more urgently. |
|
FWIW, I don't think this ticket has any strong connection to "mimic tags" -- won't the visualizers be reading constraints directly from the model(s) in Mbp? |
|
My view of the victory condition is that a model loaded from XML with mimic tags visualizes correctly (i.e., by obeying the mimic constraint so that the robot always displays a valid posture). Yes, the visualizer code would get that information from MbP. However, the victory condition is not that every possible kind of SAP constraint visualizes correctly -- only that this one specific thing does so. In that light, if we were to rename this issue to something like "visualize MbP's SAP constraints", that would would blur the goal. |
I met the same problem here.When I want to use in my simulation,I was told that it was a continous system and would ignore the drake:mimic joint. |
This method creates a mapping from the constraints used in MultibodyPlant/SAP to the constraints used in MathematicalProgram. Towards RobotLocomotion#18917.
This method creates a mapping from the constraints used in MultibodyPlant/SAP to the constraints used in MathematicalProgram. Towards RobotLocomotion#18917.
This method creates a mapping from the constraints used in MultibodyPlant/SAP to the constraints used in MathematicalProgram. Towards RobotLocomotion#18917.
This method creates a mapping from the constraints used in MultibodyPlant/SAP to the constraints used in MathematicalProgram. Towards RobotLocomotion#18917.
This method creates a mapping from the constraints used in MultibodyPlant/SAP to the constraints used in MathematicalProgram. Towards RobotLocomotion#18917.
This method creates a mapping from the constraints used in MultibodyPlant/SAP to the constraints used in MathematicalProgram. Towards RobotLocomotion#18917.
This method creates a mapping from the constraints used in MultibodyPlant/SAP to the constraints used in MathematicalProgram. Towards #18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
and by implication also to ModelVisualizer Resolves RobotLocomotion#18917.
and by implication also to ModelVisualizer Resolves RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards RobotLocomotion#18917.
Also moves the joint limits / joint locking logic from the IK constructor to AddMultibodyPlantConstraints. Towards #18917.
Updates JointSliders to have discrete state (previously it was stateless). Additionally, if the new ResolveConstraints logic is active, we publish the (rounded) resolved constraints back to Meshcat, so that the other sliders are updated. Deprecates JointSliders::SetPositions(q), which has been replaced with JointSliders::SetPositions(context, q). Resolves RobotLocomotion#18917.
Updates JointSliders to have discrete state (previously it was stateless). Additionally, if the new ResolveConstraints logic is active, we publish the (rounded) resolved constraints back to Meshcat, so that the other sliders are updated. Deprecates JointSliders::SetPositions(q), which has been replaced with JointSliders::SetPositions(context, q). Resolves RobotLocomotion#18917.
Updates JointSliders to have discrete state (previously it was stateless). Additionally, if the new ResolveConstraints logic is active, we publish the (rounded) resolved constraints back to Meshcat, so that the other sliders are updated. Deprecates JointSliders::SetPositions(q), which has been replaced with JointSliders::SetPositions(context, q). Resolves RobotLocomotion#18917.
Updates JointSliders to have discrete state (previously it was stateless). Additionally, if the new ResolveConstraints logic is active, we publish the (rounded) resolved constraints back to Meshcat, so that the other sliders are updated. Since ModelVisualizer uses JointSliders, now ModelVisualizer also satisfies the multibody constraints. Resolves RobotLocomotion#18917. Deprecates `JointSliders::SetPositions(q)`, which has been replaced with `JointSliders::SetPositions(context, q)`.
Updates JointSliders to have discrete state (previously it was stateless). Additionally, if the new ResolveConstraints logic is active, we publish the (rounded) resolved constraints back to Meshcat, so that the other sliders are updated. Since ModelVisualizer uses JointSliders, now ModelVisualizer also satisfies the multibody constraints. Resolves RobotLocomotion#18917. Deprecates `JointSliders::SetPositions(q)`, which has been replaced with `JointSliders::SetPositions(context, q)`.
Updates JointSliders to have discrete state (previously it was stateless). Additionally, if the new ResolveConstraints logic is active, we publish the (rounded) resolved constraints back to Meshcat, so that the other sliders are updated. Since ModelVisualizer uses JointSliders, now ModelVisualizer also satisfies the multibody constraints. Resolves RobotLocomotion#18917. Deprecates `JointSliders::SetPositions(q)`, which has been replaced with `JointSliders::SetPositions(context, q)`.
See #17663 and #18728 for background.
When we are displaying a model with coupled joints, we should be enforcing the constraint during visualization.
The text was updated successfully, but these errors were encountered: