ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

Changing End effector in realtime in moveit

asked 2017-09-15 04:25:19 -0600

akash_p gravatar image

Hello all, I am using UR5 robot with some custom end effector which obviously works good.Now my requirement is I need to change end effector in run time while move group is running which means URDF which is loaded as robot_description on ros param server is to be changed to other URDF which consist of my second gripper.Also I need to change semantic description on ros param server.Anybody has worked in such scnerio or can help me regarding this?

edit retag flag offensive close merge delete


Hello, I'm exactly in the same situation, did you manage to find a solution for this ?

matEhickey gravatar image matEhickey  ( 2017-10-10 02:31:41 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2017-10-10 02:50:33 -0600

akash_p gravatar image

updated 2017-10-10 02:51:07 -0600

Yup.I found a workaround to solve this issue not a complete solution though.Following are the steps.

1.Load robot_description to rosparam server with urdf consisting of 1st end effector.

2.Whenever you want to switch to new end effector replace robot_descritption on rosparam server by reading data from URDF of new end effector with complete robot and also replace robot_description_semantic on rosparam server by new srdf file corrosponding to your new URDF.

3.Now I am doing all this replacing through my cpp node and then using system() function to kill move_group node,robot_description node and rviz_node.(Remember to set respawn=true for all these nodes in your corresponding moveit package launch files).

4.All the killed nodes will respawn now and will load my newly uploaded robot_description and robot_description_semantic from rosparam server and in rviz you will be able to visualize your new end effector.

Since moveit move_group node spawns up moveit_planning_scene service once at the start and it loads robot_description only once at start we need to respawn all the nodes to take up our new robot URDF and its corresponding semantic description.Hope this helps you!

edit flag offensive delete link more


Thank you, well played for this solution, I will try to implement this for my needs !

matEhickey gravatar image matEhickey  ( 2017-10-10 03:35:36 -0600 )edit

A note of caution: this isn't really a solution, but more of a work-around, and, as you're only restarting some of the consumers of those parameters/artefacts, you run the risk of ending up with a 'desynced' ROS node graph, in which some participants are using one version of robot_description ..

gvdhoorn gravatar image gvdhoorn  ( 2017-10-10 03:59:02 -0600 )edit

.. and related parameters, and others another. In controlled environments this probably won't be a big problem, but I wanted to note it (for future readers) in any case.

The real problem here is the immutability of robot_description, and the fact that none of its current consumers are set up ..

gvdhoorn gravatar image gvdhoorn  ( 2017-10-10 04:00:05 -0600 )edit

.. to deal with changes to that parameter.

Also note: there are multiple ways to parse urdfs (raw xml, urdf_dom, custom parsers, etc), and many nodes even use a combination of those different ways at the same time. This all makes "changing EEFs in 'real-time'" a rather complex piece of ..

gvdhoorn gravatar image gvdhoorn  ( 2017-10-10 04:02:07 -0600 )edit

.. functionality to implement. Much more complex than a lot of people assume.

gvdhoorn gravatar image gvdhoorn  ( 2017-10-10 04:02:33 -0600 )edit

Finally: some alternative work-arounds:

  1. if the EEF doesn't require any control (based on URDF, that is): use MoveIt's attached collision object infrastructure for your gripper. Those can be attached and detached at runtime without the earlier mentioned complications (although it will be ..
gvdhoorn gravatar image gvdhoorn  ( 2017-10-10 04:03:47 -0600 )edit

.. MoveIt-specific)

2 . run two move_group instances in parallel. Namespaced and each with their own robot_description and related parameters.

gvdhoorn gravatar image gvdhoorn  ( 2017-10-10 04:04:51 -0600 )edit

@akash_p wrote:

but move_group loads robot_description only at start was my main concern

as it should: robot_description is a parameter, and those are only intended to be read in a node's initialisation phase.

That is why having robot_description being a parameter is such a limitation.

gvdhoorn gravatar image gvdhoorn  ( 2017-10-10 04:08:03 -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: 2017-09-15 04:25:19 -0600

Seen: 1,291 times

Last updated: Oct 10 '17