Planning with tcf after attaching a tool (ROS backend)

What is the correct workflow to make the ROS backend plan motion/compute IK with tcf, instead of t0cf, after attaching a tool to the robot?

In our current workflow using KUKA robots and KUKA|prc for Grasshopper, we define a tool and its TCP(tcf) transformation, and then everything is based on TCP. Most of the time we don’t have to know anything about the frame of flange (t0cf).

In compas_fab, however, I can’t reproduce a similar workflow. The tool is not included in the URDF I used for the MoveIt config. Instead, the meshes and tcf in the frame of t0cf are defined and attached to the robot after the ROS backend was running. Yet, the inverse kinematic is still based on the initial end effector(t0cf).

I tried a workaround by including the tool in the URDF and defining a planning group for the end-effector. This works but I think this might be unfriendly to the end-users that aren’t familiar with ROS and Docker/VM.

Currently, I use the method robot.from_tcf_to_t0cf() to transform the goal plane before assigning it to the inverse kinematic component (as shown in the image). This workflow did the trick, but I wonder if it is the correct way to do this?


The approach you are using is indeed the correct one with the from_tcf_to_t0cf() method, but we’ll make it easier to use in a new release soon, because it’s rather redundant, ie. if you have a tool attached, you most likely want to use tcf for planning by default.

I’ll change this and get a new release out as soon as possible.


Hi! Thank you for making these improvements.

I have two questions regarding planning with tcf by default:

  1. In the GH component Constraints From Plane, I could set position and orientation tolerance. Will these tolerance settings also be based on the tcf if a tool is attached after the update?

  2. Will issue #122 be addressed in the following update? Right now it seems impossible to attach tools and plan motion if I have multiple manipulators in one robot.

Will try to tackle it as well, although fixing one does not necessarily mean fixing #122, but since it’s so related, we might give it a shot at once.

Hi Gonzalo,

Good to hear that, thank you and your team for developing these amazing frameworks. I’m still far from making a real contribution to source code development, but I hope I could get there soon.


1 Like