Ask Your Question

Tool0 URDF Modifications Break Path Planning

asked 2017-03-07 16:13:16 -0500

jbeck28 gravatar image

updated 2017-03-08 02:10:48 -0500

gvdhoorn gravatar image

I've been trying to properly define my tool frame in ROS so that it matches the tool frame of the physical robot. Doing this requires changing the following lines of code in the URDF:

  <joint name="joint_6-tool0" type="fixed">
    <origin rpy="3.1415926535 -1.570796327 0" xyz="0 0 0"/>
    <!--<origin rpy="3.1415926535 -1.570796327 0" xyz="0 0 0"/> This was original, reinstating this allows MOVEIT to calculate paths....-->
    <parent link="link_6"/>
    <child link="tool0"/>

If I change the origin rpy in any way, it will no longer be able to find any valid states when I plan any orientation goal (even 1,0,0,0). Any help would be much appreciated.

Thanks, Josh

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2017-03-08 02:26:47 -0500

gvdhoorn gravatar image

updated 2022-04-13 14:38:27 -0500

I've been trying to properly define my tool frame in ROS so that it matches the tool frame of the physical robot. Doing this requires changing the following lines of code in the URDF:

You're not actually supposed to change tool0 in any way, one of the reasons being exactly that this doesn't work with the IK plugins we provide. The IK plugin works with the base_link->tool0 chain and is generated code, changing tool0 will result in mismatches between what the plugin expects and what your actual model provides.

The tool0 frame is described both in the Create a URDF for an Industrial Robot tutorial, section Additional/Standard Frames, as well as in Working with ROS-Industrial Robot Support Packages, section Standardised links / frames. The former has this to say about tool0:

tool0 The tool0 frame (pronounced: 'tool-zero') shall match exactly an all-zeros TCP configuration as defined on the robot controller. For most controllers, this is equal to an unconfigured TCP, which lies on the physical robot's mounting flange.

This transform (between the last robot link and tool0) may be defined in any way (so may consist of all combinations of translations and rotations), as long as it is a fixed joint type in the URDF. Users are advised to never change tool0, but instead add additional frame(s) as (a) child(ren) of tool0.

The recommendation is thus to add child links to your composite / top-level xacro that add your toolframe as a child of flange (for robots which have that frame), but in any case as siblings of tool0. This will keep the chain consistent with the IK solver and should allow things to keep working.

One difficulty with this is that in some cases, (goal) poses defined for your new toolframe will have to be transformed back to tool0 before you pass them to a motion planner (MoveIt used to require this, I can't say for sure now whether that is still the case, or whether you can tell it to do this for you).

If you really do want to change tool0, then you could switch to KDL or Trac IK as your IK solver. Both of these can work with runtime defined kinematic chains, so they don't have the problem of requiring the chain to match whatever it was when the code was generated (we use IKFast as it solves in microseconds, as opposed to milliseconds for KDL/Trac IK).

PS: the current definition (and use) of tool0 mixes the concepts of 'flange' and 'unconfigured toolframe', which leads to confusion such as yours. We're working on a revision of our modelling standards that will rectify this, most likely by introducing a separate flange frame / extension point (edit: this flange frame was indeed introduced, and decouples the orientation constraints of tool0 from the eef-attachment-point semantics of flange).

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2017-03-07 16:13:16 -0500

Seen: 532 times

Last updated: Apr 13