Ask Your Question

Support for tool changing

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

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

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 imagesedwards ( 2014-11-12 23:00:33 -0600 )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 imageJeremy Corbett ( 2014-11-13 00:55:52 -0600 )edit

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


Damien gravatar imageDamien ( 2016-01-08 05:59:05 -0600 )edit

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

BrettHemes_ gravatar imageBrettHemes_ ( 2016-06-27 08:59:20 -0600 )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 imagegvdhoorn ( 2016-06-27 09:07:46 -0600 )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 imageBrettHemes_ ( 2016-06-27 09:28:09 -0600 )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 imagegvdhoorn ( 2016-06-27 09:32:44 -0600 )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 imagefvd ( 2018-07-31 21:36:30 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

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

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 imageJeremy Corbett ( 2014-11-13 16:04:53 -0600 )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 -0600

Seen: 637 times

Last updated: Jan 08 '16