Support for tool changing

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

397 ●11 ●18 ●19 http://sssmanufacturing.com/

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;
- https://github.com/uw-biorobotics/rav...
- Suggest using dynamic reconfigure / service to modify tools
USARSimROS using KUKA KR60 robot as example for their simulation bridge
- http://sourceforge.net/p/usarsimros/w...
- 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
- http://answers.ros.org/question/49818...
- Suggests loading tool urdfs separately and using node to publish transforms of tools to robot
- Is this compatible with collision checking?

edit retag flag offensive close merge delete

Comments

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 ( 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 ( 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...

Thanks

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

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

BrettHemes_ ( 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 ( 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_ ( 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 ( 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 ( 2018-07-31 21:36:30 -0600 )edit

see more comments

0

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

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

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

Comments

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 ( 2014-11-13 16:04:53 -0600 )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 ( 2020-12-30 09:33:17 -0600 )edit

add a comment

2

answered 2023-03-23 09:03:41 -0600

pablomalvido
41 ●2 ●3

We have developed a solution for this issue, you can check it here: https://github.com/ros-planning/movei.... The developed class adds the automatic tool changing capability in MoveIt. The class allows to detach and attach tools to the robot’s wrists, considers collisions for the tools, and provides a function to transform the planned trajectories from the robot’s wrist frame to the actuation frame of the current end effector.

The performance of this class on an SDA10F Yaskawa robot can be seen in this video: https://www.youtube.com/watch?v=DJXKW....

edit flag offensive delete link

add a comment

1

answered 2021-05-19 16:06:54 -0600

guru_florida
280 ●10 ●22 ●22

I solved this on Ros2 for Rviz2. This is a simple python script that monitors your URDF/xacro file and publishes to robot_description anytime a change is detected. Rviz2 updates in about a second.

Monitor URDF file and dynamically update RViz2

edit flag offensive delete link

Comments

Have you added anything which makes sure all the consumers of the URDF also see the change, and more importantly, act on it? Should there be something which guarantees all nodes are in a consistent state (ie: they all use the same version of the URDF)?

gvdhoorn ( 2021-05-20 01:35:34 -0600 )edit

Point taken for sure. Many of the nodes I coded, so I coded them to act on a new URDF when published. RViz2 supports it and it updates quickly. It was much easier to code a URDF when you can see the result in about a second so this is beneficial if only for this reason. You're right in that all nodes subscribing to the URDF would have to be coded properly and many probably aren't so updating in normal operation could have mixed results. Hopefully as Ros2 progresses developers will be aware, it wasn't hard to do.

guru_florida ( 2021-05-23 15:49:34 -0600 )edit

add a comment

Support for tool changing

Comments

3 Answers

Comments

Comments

Question Tools

Stats

Related questions

Support for tool changing edit

Comments

3 Answers

Comments

Comments

Question Tools

Stats

Related questions

Support for tool changing