Ask Your Question

Support for tool changing

asked 2014-11-12 21:15:51 -0500

updated 2014-11-13 16:00:34 -0500

This is probably more of a question for ROS-Industrial type applications, but with ROS what would be the best way to support the ability to load and unload a tool on the end of a robotic arm? Specifically to do with the dynamic plannning and collision geometry constraints.

To use a tool changer I believe the following is required;

  • Use a single IK fast generated kinematics solver for the robot arm + tool change mount. (as this won't change)
  • Load tools with transforms to the tool tip and collision geometry from either a URDF, yaml or database
  • Calculate IK solutions with modified end effector tool tip
  • Enable and disable the collision geometries associated with each gripped tool
  • Provide ability to adjust tool transforms at run-time after calibration routines

As far as I can tell robot_model doesn't really support such behavior. Has anyone managed to enable or disable specific end effectors and their associated collision geometry at runtime?

We have managed to prove that we can apply tool offset transform to the low level IK code and tie this into the planners.

One option is to treat the gripped tools like grasped objects, but this seems a bit hacky.

Has anyone had a similar use case?

I have found the following with similar scenarios;

  • UW biorobotics Raven 2 surgical robot;
  • USARSimROS using KUKA KR60 robot as example for their simulation bridge

    • Suggest that the robot urdf and generated ikfast IK should only be up to the tool changer mount.
    • "A robot with a toolchanger effector does not need a new URDF for each end effector that can be attached. The URDF should contain only a reference to the toolchanger, and will handle attaching/detaching end effectors from it as it runs."
  • Other tool changer question

edit retag flag offensive close merge delete


Jeremy, ros answers won't allow me to up vote this more than once :( I'm not aware of a clean solution to this problem, but one is needed (especially for ROS-I applications). Thanks for asking!

sedwards gravatar image sedwards  ( 2014-11-12 23:00:33 -0500 )edit

Thanks for the upvote Shaun. We are going to try a few things, I'll let you know how it goes.

Jeremy Corbett gravatar image Jeremy Corbett  ( 2014-11-13 00:55:52 -0500 )edit

Hi Jeremy, did you find a solution for your issue? It is indeed a hard requirement for any Industrial application...


Damien gravatar image Damien  ( 2016-01-08 05:59:05 -0500 )edit

+1 This is something we have recently begun trying to figure out as well...

BrettHemes_ gravatar image BrettHemes_  ( 2016-06-27 08:59:20 -0500 )edit

Something that should be possible with the current state of ROS / MoveIt would probably involve a 'bare' robot URDF (ie: sans EEF), and attaching the EEF as a collision object using the appropriate MoveIt APIs. For visualisation this wouldn't be too nice, but it should make planning work, with EEF.

gvdhoorn gravatar image gvdhoorn  ( 2016-06-27 09:07:46 -0500 )edit

Awesome; thanks for the comment gvdhoorn! This is the approach we are currently exploring so it is nice to get some confirmation that we are on the right path.

BrettHemes_ gravatar image BrettHemes_  ( 2016-06-27 09:28:09 -0500 )edit

Note that I haven't verified that too extensively yet.

Also note that you'd probably have to transform any EEF pose back to the tool0 (or whatever link you have configured as the last link of your chain) before asking MoveIt to plan for it. But that depends on some factors.

gvdhoorn gravatar image gvdhoorn  ( 2016-06-27 09:32:44 -0500 )edit

It would be interesting to hear an update from people who have attempted this. We have a similar use case (and I am sure many others will, too).

fvd gravatar image fvd  ( 2018-07-31 21:36:30 -0500 )edit

1 Answer

Sort by » oldest newest most voted

answered 2014-11-13 01:45:47 -0500

gvdhoorn gravatar image

Not a complete answer, but you might want to try and see how Rethink Robotics did this for Baxter. IIRC, the different EEFs that can be connected (gripper, suction cups) to Baxter's arms dynamically update the urdf, without the user needing to reconfigure and / or restart anything.

We have one here in a lab, so I can try to take a look if you want (I'm rather curious myself).

What I can imagine right now is a node that just overwrites the robot_description parameter when needed (and causes the needed transforms to be published). This would obviously require some special logic in other nodes in your system working with the robot_description parameter, as normally I retrieve it once and assume it never changes.

edit flag offensive delete link more


Thanks for the tip. I was wondering if this was a possibility, though I can see a few issues that would probably arise around robot_state. I will have a dig through Baxters, and the Rethink Robotics repo's.

Jeremy Corbett gravatar image Jeremy Corbett  ( 2014-11-13 16:04:53 -0500 )edit

Hi Jeremy, did you manage to get it to work. I have the same issue here in 2020 (implementing a tool changer for an industrial application) and surprisingly little has happened since 2014! ROS2 is supposedly going to solve this issue, but it is till not supported well enough and this thread is one of the few lifelines i have.

I tried downloading Rethink Robotics mutable_robot_state_publisher but catkin won't build it. (I work on ROS melodic while tha package was probably developed for an older distro.) Just wanted to know if it worked for you, before i dig deeper into trying to debug it.

The error code from catkin:

 robot_state_publisher.cpp:73:106: error: conversion from ‘std::map<std::__cxx11::basic_string<char>’ to non-scalar type` ‘std::map<std::__cxx11::basic_string<char>
StanislawZ gravatar image StanislawZ  ( 2020-12-30 09:33:17 -0500 )edit

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: 2014-11-12 21:15:51 -0500

Seen: 908 times

Last updated: Jan 08 '16