Miguel Prada

I think the short answer is that directly linking against the `liburX_kin` is not a well supported use case. The structure of the `ur_kinematics` package is directed towards using these...

> I've always thought the "best" way to deal with this would be to split out the kinematics plugins into packages. Not sure I get your point. AFAIK, the plugins...

> My idea behind using separate packages is that it conveniently allows for keeping the same code and fixes the deployment problem for consumers: by stating the correct dependency in...

Hi @gavanderhoorn, I'm working a bit on this with @asierfernandez. I don't remember there being a `joint_trajectory_action` server for both arms, but we will double check tomorrow and get back...

I see one issue with the suggested layout. We've been recently receiving a lot of issues by people getting confused about how to "connect" the MoveIt setup to the actual...

Out of curiosity, by checking the moveit configuration packages for the three UR models, all of them use the KDL kinematics plugin by default, which should have no issue with...

> IMHO using the committed container in different environments is not a supported use case. This is reasonable. > Even if you can remove the variables from the image/container somehow,...

> Are there additional cleanup steps that we should be considering in order to create deployable images? Or are there any particular reasons why you think this is a bad...

We've been exploring different ways to add `rosdep` sources and have experimented with: - adding them "manually" with a script executed in `BEFORE_SCRIPT` - adding them to a docker image,...

May also be related to ros-controls/ros_controllers#577.