Initial commit of KUKA KR120 support package

[tingelst]

Added support for the KUKA KR120 R2500 PRO manipulator
Meshes are based on the Unigraphics files found at http://www.kuka-robotics.com/res/sps/8ba89f50-3ccd-4361-9b9a-60bdd0662ac6_KR120_R2500_pro.prt.zip
Note that the rotation directions of the KUKA manipulators are different than e.g. the ABB manipulator. For joint 1 this is implemented using .

[gavanderhoorn]

This is only needed if you have roslaunch_add_file_check(..) checks.

[tingelst]

Shall I remove find_package(roslaunch) ?

[gavanderhoorn]

If you don't intend to add any roslaunch checks it is unneeded, so you can remove it.

[gavanderhoorn]

@tingelst: thanks for this. The package looks ok, but there are some minor things (see inline comments).

In addition to those:

1. Have you considered adding a base_link -> base transform to the xacro? This would make it possible to express / correlate the tool0 pose in / to the Cartesian space of the KUKA controller. See tool0: ROS-I vs industrial controllers (discussion) ros_industrial_issues#24 for the discussion.
2. Direction of face normals of the collision STLs: all STLs seem to have normals pointing inwards (in addition to correct ones pointing outside). I'm not sure whether that can influence collision detection in any way, but it results in meshes with 'holes' in them when visualising the robot model in RViz. Meshlab can easily clean these up for you.

[tingelst]

I added a base to base_link joint. This corresponds to the $ROBROOT coordinate system used by KUKA. The use of the name base can become confusing as $BASE is used for user defined coordinate systems in the KUKA KRC controllers.

[gavanderhoorn]

The use of the name base can become confusing as $BASE is used for user defined coordinate systems in the KUKA KRC controllers.

Yes that is unfortunate, but unavoidable: we thought about alternative names for it, but we'd probably come up with something that was used in some other control system.

[gavanderhoorn]

@tingelst: I just checked the collada visual models: do they render with washed out colours for you as well? I'm not getting the deep red I was expecting.

[tingelst]

Yes, I get the same washed out effect in RViz. I have chosen to have the colors like that as they look good in gazebo and correspond to the RAL colors used by KUKA on the real robots. The washed out effect comes from the Phong shading parameters used. The same issue is presented in this blog post. We can get more 'popping' colors by changing the ambient, diffuse and specular parameters. The youbot gazebo model use more bright parameters.

[tingelst]

The URDF and the meshes are now updated and corresponds to the kinematics on the KRC controller

[gavanderhoorn]

@tingelst wrote:

I added a base to base_link joint. This corresponds to the $ROBROOT coordinate system used by KUKA. The use of the name base can become confusing as $BASE is used for user defined coordinate systems in the KUKA KRC controllers.

Forgive my ignorance (I'm not too familiar with KUKA controllers), but does the $ROBROOT ever change? I'm just trying to gauge what the re-usability of a ROS-I provided urdf for KUKA robots is. If it can change (in normal usage), we should probably document this somewhere.

[gavanderhoorn]

@tingelst wrote:

Yes, I get the same washed out effect in RViz. I have chosen to have the colors like that as they look good in gazebo and correspond to the RAL colors used by KUKA on the real robots. The washed out effect comes from the Phong shading parameters used. [..]

Ah ok. I figured something like that was going on.

+1 on using the official RAL colours, this should definitely be the default practice when creating meshes / urdfs.

We can address the shading later.

[gavanderhoorn]

@tingelst: this is looking good. Two minor things:

1. we can do this in a later commit, but some of the collada meshes have a very high vertex / face count (link_1.dae has over 100k faces). This is often the case with meshes derived from CAD models. Most of the time the face count can be reduced significantly without affecting the appearance, resulting in smaller filesizes and faster loading times. I can do this later (almost trivial in Blender, using the Decimate modifier).
2. Could you squash the later commits in this PR into the Initial commit of KUKA KR120 support package commit? Then just force push. This makes for a cleaner history when merging.

[tingelst]

@gavanderhoorn Sure. I will squash the commits when I am back in the office on Monday.

[gavanderhoorn]

Great, thanks a lot. Really appreciate all the effort @tingelst.

[tingelst]

I have now updated the joint names and squashed the commits.

[gavanderhoorn]

Thanks @tingelst.

This may not have been clear, but we use the joint_ and link_ prefixes for joint and links respectively, independent of what the mfg uses to refer to them. In this case, that would become joint_a1, joint_a2, etc. I can make the change later, if you want.

Also: could it be that the urdf in the commit has not been regenerated after your recent changes? The base link is not present in the urdf fi, while it is in the xacro.

[tingelst]

@gavanderhoorn: Yeah, I misunderstood that. Its now updated to joint_a1 etc. Also updated the urdf.

[gavanderhoorn]

+1 from me @tingelst.

We'll deal with shading & mesh complexity later, as those issues do not prevent anyone from using the support package.

I'll merge the PR.

[gavanderhoorn]

Thanks again @tingelst. Looking forward to your other PRs.

[tingelst]

@gavanderhoorn This is great! More PRs coming soon.