search

moveit / moveit2

:robot: MoveIt for ROS 2
https://moveit.ai/
BSD 3-Clause "New" or "Revised" License
1.11k stars 537 forks source link

Add ability to attach and detach end-effector links #208

Open jrgnicho opened 4 years ago

jrgnicho commented 4 years ago

Is your feature request related to a problem? Please describe. Many industrial application involve changing end-effectors on the fly mid process and at the moment this can not be done directly; the workaround I'm aware of is to either use an attached object as and end effector or create various tool links in the URDF beforehand and turn their collision flags on and off. Therefore it would be very convenient if one could programatically attach and detach end-effector links.

Describe the solution you'd like I believe one of the limitations lies in the URDF library which doesn't allow modifications to the chain once it's initialized from the urdf file. Therefore some work would need to be done in exploring other scene management alternatives that would allow modifying the kinematic chain at runtime; some libraries that I'm aware of are boost Graph, KDL and Ogre3D.

AndyZe commented 4 years ago

This sounds important. Maybe a combined request from MoveIt and ROS-Industrial would be enough to convince the powers that be to update the URDF library.

gavanderhoorn commented 4 years ago

This was also discussed at the 1st MoveIt con in Macau.

The URDF format does not explicitly support dynamic removal or addition of links, but that's not really important: it's a serialisation format, which is inherently static.

The in-memory representation of the URDF DOM does not really prohibit anyone from making changes. Even after initial deserialisation There is API for it currently (or at least: if you get a Model ptr it's sort-of read-only), but there is nothing inherently difficult in adding some setters.

A bigger problem is ensuring that all consumers of the URDF will be notified of that change, in a timely manner and in a coherent way.

That does not seem to be a problem "for" URDF per se, and probably also not something solved by changing URDF.

gavanderhoorn commented 4 years ago

of course, if move_group (or whatever hosts the planning scene and robot models) is the only consumer, then this doesn't really matter, and it could simply be added to MoveIt. But that may not be what @jrgnicho had in mind.

jrgnicho commented 4 years ago

@gavanderhoorn , that's more or less what I envision for this feature I think since most moveit planning applications work with a move_group central node that host the robot model and planning scene then any online changes to the robot model would not be much of an issue as all planning operations have to go through the move_group node anyway. For applications that don't follow that workflow we could publish to a topic that notifies that changes to the robot model have been made or they could just call the get_planning_scene service to sync their local scene with the latest one

gavanderhoorn commented 4 years ago

Would URDF still be a limiting factor here then?

AndyZe commented 4 years ago

Why can't URDF have a flag to allow dynamic modification? It should be off by default.

That would be consistent and reliable for people who don't need updates, I think.

jrgnicho commented 4 years ago

@gavanderhoorn it was my impression that the urdf model in the urdf library was immutable but based on your comments that isn't the case, therefore it wouldn't be a limiting factor. I don't expect that this change would require adding new tags to the urdf file, if new attributes are needed we could just add those to the srdf file.

gavanderhoorn commented 4 years ago

What I'm confused about is the need to change the URDF format itself (so the on-disk format, not the DOM).

What change would you see needed there?

jrgnicho commented 4 years ago

I don't envision any changes to the URDF format actually, sorry if in my earlier comments I seemed to imply that.

nbbrooks commented 2 years ago

I was reviewing roadmap features and thought I would post Jafar's MoveGroupCapability implementation of the common workaround in Jorge's description. When it was implemented there was a bug with Rviz2 config exporting which prevented having the plugin have Rviz show/hide tool meshes as they are swapped. (You can manually change the visualized meshes in Rviz RobotModel, Save As the rviz conf, and open it to see what I'm talking about)

henrygerardmoore commented 2 years ago

Will be taking a look at this issue next week and seeing if we can add the functionality from Jafar's implementation of the work-around (as mentioned in Nathan's comment) into MoveIt.

henrygerardmoore commented 2 years ago

Made this issue so that we can implement the save, edit, load work around to make the visuals match up with the currently loaded end effector.