# robotiq_2f_85/140 does not have fingers attached to base_link in tf tree

I am attempting to add the robotiq hande gripper to the end of my yaskawa gp12. In order to use this with a moveit move group to use an octomap for object avoidance, I created a gp12.xacro that included the robotiq_arg2f_140_model (also tried with the 85 and c2 models) attached to the end as seen below. These grippers are similar in size, shape, and function and since I will be controlling the gripper through a script instead of through the rviz gui, it is essentially just a placeholder for me so that the robot can properly pathfind and the octomap does not see the gripper as an obstacle. I created a moveit package off this xacro and it properly creates and compiles and I can even launch and perform movements on the real robot however, because the fingers tf tree's are disconnected from the base link of the gripper and therefore my robot, I cannot get an octomap to be generated. In fact, when I spawn in a robot model, the gripper fingers have in fact spawned at the origin of the world (xyz: 0 0 0) which is underneath the base_link of the robot. However when working with the motion planning model, the fingers are where they are supposed to be and additionally, the fingers are actuatable via the joints tab of moveit motion planning. Why are the fingers not part of the base link tf tree. See relevant files and pictures below.

Custom gp12 xacro

<?xml version="1.0" ?>
<robot name="motoman_gp12" xmlns:xacro="http://ros.org/wiki/xacro">
<xacro:include filename="$(find motoman_gp12_support)/urdf/gp12.xacro" /> <xacro:include filename="$(find robotiq_2f_140_gripper_visualization)/urdf/robotiq_arg2f_140_model.xacro"/>

<joint name="gripper_to_robot" type="fixed">
<origin xyz="0 0 0" rpy="0 0 1.5708"/>
</joint>

<joint name="arm_joint_tcp" type="fixed">
<origin xyz="0.0 0.0 0.171" rpy="0.0 0.0 0.0" />
</joint>

</robot>


tf tree

Posted here, I don't have enough "points(?)" to upload a file I guess

robotiq_2f_140_model.xacro cloned from github here and not modified

<?xml version="1.0"?>
<robot name="robotiq_arg2f_140_model" xmlns:xacro="http://ros.org/wiki/xacro">
<xacro:include filename="$(find robotiq_2f_140_gripper_visualization)/urdf/robotiq_arg2f_140_model_macro.xacro" /> <xacro:robotiq_arg2f_140 prefix=""/> </robot>  edit retag close merge delete ## Comments You're including two top-level .xacro files. That is not what you need/want to do. You need to include the _macro.xacro (similar to how it's done in the robotiq_2f_140_model.xacro and then instantiate (ie: call) the macro (again, as it's done in the robotiq_2f_140_model.xacro). Same for your robot model actually. Top-level .xacros are just that: top-level. They cannot be used to create a composite. ( 2020-09-23 15:07:58 -0500 )edit @gvdhoorn apologies as I have limited ROS experience but it was my understanding that the .xacro (non macro version) of both models do still contain macros, the macros just simply "spawn" the model defined in the macro.xacro files so then if I wanted to combine and further implement them, I could just use the .xacros and call the contained macros e.g. <xacro:robotiq_arg2f_140_model prefix="">  and then that would create an instance of the model for me. edit: I do see that I did not utilize the calling of the model macros in my file, I had them when I created the tf tree however I removed them in order to troubleshoot in another area and seems I forgot to repair my file before pasting here. ( 2020-09-24 07:09:25 -0500 )edit Top-level files do typically call macros themselves, that's not the problem. The problem is that by including them, you essentially concatenating different complete files together. That typically doesn't work. Just for testing, I would suggest to include the macro defining files and calling the two macros. Then connect the links with the joint you already have. ( 2020-09-24 08:19:12 -0500 )edit @gvdhoorn I remade the xacro as you said, utilizing the macro.xml's but unfortunately I have the exact same tf tree. Here is my updated xacro file: <?xml version="1.0" ?> <robot name="eng_motoman" xmlns:xacro="http://ros.org/wiki/xacro"> <xacro:include filename="$(find motoman_gp12_support)/urdf/gp12_macro.xacro" />
<xacro:include filename="\$(find robotiq_2f_85_gripper_visualization)/urdf/robotiq_arg2f_85_model_macro.xacro" />

<xacro:motoman_gp12 prefix=""/>
<xacro:robotiq_arg2f_85 prefix=""/>

<joint name="gripper_to_robot" type="fixed">
<origin xyz="0.0 0.0 0.0" rpy="0.0 0.0 0.0" />
</joint>

<joint name="arm_joint_tcp" type="fixed">
<origin xyz="0.0 0.0 0.13" rpy="0.0 0.0 0.0" />
</joint>

</robot>

( 2020-09-24 08:47:47 -0500 )edit

To clarify, I did also remake my moveit config based on this xacro.

( 2020-09-24 08:49:03 -0500 )edit

So how do you start everything now?

Do you use a specific .launch file? Do you actually have the hw that your .xacro models? If you do, do you have the drivers running which publish the JointStates which would be needed by the robot_state_publisher to be able to calculate FK and broadcast the transforms? If you don't have the hw, do you have a joint_state_publisher active which fakes the JointState messages for the hw you don't have?

If you answer with "no" to both of these, that would be a good candidate for a cause of the problem you see.

( 2020-09-24 09:40:28 -0500 )edit

@gvdhoorn I have a moveit_planning_execution.launch file which launches the drivers for my yaskawa gp12, robotiq hande, and kinectv1. All of these function correctly and I do get feedback from all of the joints. The hande is the only thing that is different from the xacro however the firmware is the same for this as it is for the 2f 85 (I can operate the gripper through rviz via its own driver) and it operates correctly. The issue I run into is for some reason with my attachment of the gripper to the gp12, the fingers tf tree's do not link back to the robotiq gripper base link. To add some context, if i modify the xacro to only import and instantiate the base link macro of the gripper, everything functions correctly, and the octomap is generated. However, on some path plans, the kinematics, understandably, cannot path plan for ...(more)

( 2020-09-24 10:26:05 -0500 )edit