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

Why don't you remove _mimic suffix? #96

Closed
ShotaAk opened this issue Nov 22, 2022 · 7 comments · Fixed by #276
Closed

Why don't you remove _mimic suffix? #96

ShotaAk opened this issue Nov 22, 2022 · 7 comments · Fixed by #276

Comments

@ShotaAk
Copy link

ShotaAk commented Nov 22, 2022

Currentry mimic joint impelemtation causes following error:

[move_group-3] [ERROR] [1669079269.679936655] [moveit_robot_model.robot_model]: Joint 'crane_x7_gripper_finger_b_joint_mimic' not found in model 'crane_x7'
[move_group-3] [ERROR] [1669079269.685043176] [moveit_robot_model.robot_model]: Joint 'crane_x7_gripper_finger_b_joint_mimic' not found in model 'crane_x7'
[move_group-3] [ERROR] [1669079269.690190959] [moveit_robot_model.robot_model]: Joint 'crane_x7_gripper_finger_b_joint_mimic' not found in model 'crane_x7'
[move_group-3] [ERROR] [1669079269.695329495] [moveit_robot_model.robot_model]: Joint 'crane_x7_gripper_finger_b_joint_mimic' not found in model 'crane_x7'
...

Actual the joint name in my URDF is crane_x7_gripper_finger_b_joint yet the controller outputs states of the crane_x7_gripper_finger_b_joint_mimic joint.

Maybe the reason why this happend is here:

Could you remove the _mimic suffix?

@bmagyar
Copy link
Member

bmagyar commented Nov 25, 2022

Sounds like a fair point.

@destogl
Copy link
Member

destogl commented Nov 27, 2022

Sounds like a fair point.

Nope it doesn't :D

Actual the joint name in my URDF is crane_x7_gripper_finger_b_joint yet the controller outputs states of the crane_x7_gripper_finger_b_joint_mimic joint.

The reason for adding this is not to intervene with URDF joint description used by Rviz and robot_state_publisher. They parse the URDF and calculate automatically mimicked joints. The mimicked joints you get published by JointStatePublisher are only "virtual" values used for debugging and internal functionality of ros2_control.

I don't understand in which case MoveIt gives you this error. Can you explain a bit more? If you have defined your proper joint name, i.e., crane_x7_gripper_finger_b_joint in Moveit configuration, this should be fine and MoveIt should ignore this _mimic suffixed joints.

You got the cause correctly. As I remember, I have added this joint so that the plugin for simulation works correctly. You can try removing this (not only the suffix – then you will get issues with Rviz and robot_state_publisher) and see what happens.

@ShotaAk
Copy link
Author

ShotaAk commented Jan 4, 2023

I'm sorry for the late reply.

Thank you for more detail comments.

I ran the command again.
I found that the mimic joint is working fine, although the error message is still displayed.

image

@mrjogo
Copy link
Contributor

mrjogo commented Aug 11, 2023

I also ran into this (and created https://robotics.stackexchange.com/questions/25107/ros2-moveit-cant-find-mimic-joint before finding this issue). The MoveIt error is from https://github.com/ros-planning/moveit2/blob/92ca89dca4fee679bc63a53bde9a992415a4d29e/moveit_core/robot_model/src/robot_model.cpp#L1301, and although I don't know the mechanism or reason, my best guess is that MoveIt is looking up all the controller interfaces by name, and one is not found because of the _mimic suffix.

@shonigmann
Copy link

shonigmann commented Aug 14, 2023

For reference, this issue has similarly been a pain point in the ROS2 Control Plugins for Gazebo Classic: ros-controls/gazebo_ros2_control#173

I appreciate the idea that adding the _mimic suffix adds some context that the joint is indirectly controlled / measured, but I'd argue that this should be the responsibility of the URDF designer and not the Gazebo plugin. Quietly adding a suffix leads to unexpected (and often unwanted) behavior in my view.

Edit:

The reason for adding this is not to intervene with URDF joint description used by Rviz and robot_state_publisher. They parse the URDF and calculate automatically mimicked joints. The mimicked joints you get published by JointStatePublisher are only "virtual" values used for debugging and internal functionality of ros2_control.

Apologies, I missed the comment about RViz and robot_state_publisher conflicts.

I'm trying to remember my initial use-case when I ran into this issue - it has been a long time since I was working on that project, but if memory serves the goal was to use Moveit to plan to move a mimicked joint to a given state in cases where this was more convenient or intuitive than indirectly directly planning for the controlled joint, hence needing the mimic joint to not be ignored by Moveit, and needing the URDF to match the controller manager's hardware list.

In any case, I would guess that there would be a way to avoid publishing duplicate joint state information while keeping the joint names consistent with the URDF

@shonigmann
Copy link

The reason for adding this is not to intervene with URDF joint description used by Rviz and robot_state_publisher. They parse the URDF and calculate automatically mimicked joints. The mimicked joints you get published by JointStatePublisher are only "virtual" values used for debugging and internal functionality of ros2_control.

@destogl - now that I have a bit more time to think about this, could you elaborate on what the RViz / robot_state_publisher issues were being avoided so I can better understand why the suffix is being added in the first place?

My understanding is that robot_state_publisher doesn't care whether a joint has a _mimic suffix in the name or not. It just looks for any joint that has the <mimic> element set and adds that to a set of mimic_ joints. When evaluating the state for the joints in the mimic_ set, the robot_state_publisher will override any state information in the JointState msg for those joints. I suppose that precludes your ability to track the "ground truth" Gazebo state of the mimic joint for debugging without manually passing the JointState msg, but would otherwise seem to be consistent with the "expected" operation.

For RViz, my understanding of any typical use cases that might involve joint states (visualizing TFs, Robot Models, etc), is that RViz again doesn't care what the name of a joint is or whether its a mimic. To my knowledge it uses the transforms published by robot_state_publisher, so as long as those are consistent, I don't foresee (or remember from when I tried this workaround ~1/2 a year ago) any RViz issues. I'm not aware of any RViz functionality that would break, but that's not to say they don't exist.

Please correct me if I'm wrong or missing something obvious

@christophfroehlich
Copy link
Contributor

MoveIt error was reported with gazebo_ros2_control as well ros-controls/gazebo_ros2_control#173

I also can't see any issues with removing _mimic suffix and rviz, see changes with #276
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants