Add initial mh6_support.

[de-vri-es]

This PR adds support for the MH6 [1]. I first send it ros-industrial/motoman#87. It used the package for the MH5 as template and updated the kinematic parameters and meshes. Please take the time to scrutinize it all properly.

A few points to note:

• I set myself as the maintainer in the package.xml for now, but I wouldn't mind at all to set it to @shaun-edwards again if that is preferred (it would be for me ^^). I did leave Shaun as author in addition to myself since I copied the MH5 package as template.
• I set the version to 0.0.1 for now. If there is some policy regarding version numbers, I can amend the PR. Or you can change it later, whichever is preferred.
• I changed the license from BSD to Apache v2.0. I'm fine with BSD too though.
• I used generated convex hulls (sometimes multiple per link) for the collision meshes. I saw that the MH5 package simply uses further decimated visuals. The convex hulls are about half the size of the MH5 collision meshes, but they will give somewhat more false positives, though only in pretty risky areas. Anyway, this can be discussed.
• I used a xacro property for pi in the URDF so that the numbers can easily be checked against the datasheet (which uses degrees). I kinda prefer it this way, but this can also be discussed. Not sure on the scoping rules for these parameters with xacro, so maybe it's a bad idea.
• If I decimated the visuals too far, I still got the undecimated meshes lying around.
• I don't have any hardware, so the only tests I ran was launching test_mh6.launch and playing around with the joint values.

[1] http://www.motoman.co.uk/en/products/robots/product-view/?tx_catalogrobot_pi1[uid]=444

[de-vri-es]

By the way, I would appreciate if the time comes to merge that I can make a new branch for the main repository to preserve the commit history, instead of everything being squashed into a single commit. See also ros-industrial/motoman#87 for a longer conversation on this topic.

[shaun-edwards]

@de-vri-es,

I set myself as the maintainer in the package.xml for now, but I wouldn't mind at all to set it to @shaun-edwards again if that is preferred (it would be for me ^^). I did leave Shaun as author in addition to myself since I copied the MH5 package as template.

If you are interested in being a maintainer, don't let me get in your way. Otherwise, I'm fine with being the maintainer.

I set the version to 0.0.1 for now. If there is some policy regarding version numbers, I can amend the PR. Or you can change it later, whichever is preferred.

The version is normally set (hard) once we do a binary release (under the "official" motoman repo).

I changed the license from BSD to Apache v2.0. I'm fine with BSD too though.

Since you changed things significantly, I think it's fair to change the license to whatever you wish. Apache 2.0 is the ROS-I preferred license.

I used generated convex hulls (sometimes multiple per link) for the collision meshes. I saw that the MH5 package simply uses further decimated visuals. The convex hulls are about half the size of the MH5 collision meshes, but they will give somewhat more false positives, though only in pretty risky areas. Anyway, this can be discussed.

I need some more details here. The goal is to never have a robot collide (with itself or the work cell). If the convex hulls are limiting the true workspace, then we would consider altering them.

I used a xacro property for pi in the URDF so that the numbers can easily be checked against the datasheet (which uses degrees). I kinda prefer it this way, but this can also be discussed. Not sure on the scoping rules for these parameters with xacro, so maybe it's a bad idea.

I believe properties are global. I will check.

If I decimated the visuals too far, I still got the undecimated meshes lying around.

Can you submit the undecimated visuals? We have permission from Motoman to utilize them. It makes for a much prettier visualization.

I don't have any hardware, so the only tests I ran was launching test_mh6.launch and playing around with the joint values.

We will need someone with hardware to do a final check (before this get absorbed into the official repo). Flipping joint axes and incorrect joint limits on the data sheet are common errors.

[de-vri-es]

If you are interested in being a maintainer, don't let me get in your way. Otherwise, I'm fine with being the maintainer.

I'm not up to speed with ROS-I protocol, and I imagine I would need write access to the repository if I was maintainer. My preference is not to be maintainer.

I used generated convex hulls (sometimes multiple per link) for the collision meshes. I saw that the MH5 package simply uses further decimated visuals. The convex hulls are about half the size of the MH5 collision meshes, but they will give somewhat more false positives, though only in pretty risky areas. Anyway, this can be discussed.

I need some more details here. The goal is to never have a robot collide (with itself or the work cell). If the convex hulls are limiting the true workspace, then we would consider altering them.

The convex hulls are marginally bigger. The easiest way to inspect the difference between the two is to run motoman_mh6_support test_mh6.launch and toggle the collision model on and off in rviz.

Convex hulls error on the safe side while decimated visual meshes error a bit on the dangerous side. However, I believe moveit expands collision meshes a bit, so it probably comes down to triangle count versus more snugly fitting meshes.

If I decimated the visuals too far, I still got the undecimated meshes lying around.

Can you submit the undecimated visuals? We have permission from Motoman to utilize them. It makes for a much prettier visualization.

I do have them lying around still, but they are 42 MB, as opposed to the 2.9 MB of the current visuals. But have a look at the current visuals, I think they're still pretty detailed.

[de-vri-es]

I forgot one more point:

The datasheet gives joint u high limits (-175 to +250 degrees), but using that full range will always result in an internal collision. That might be a reason to reduce the joint limits in the URDF?

[shaun-edwards]

Thanks for the clarification on convex hulls. I agree with the approach that you have taken.

Visuals look good as well. No need for the more detailed/larger models.

As far as the discrepancy between the datasheet and the true joint range, this happens all the time. I typically comment out the original (data sheet) ranges and set the true range. This makes planning fast as it typically eliminates self collision checking for the robot links. Can you submit this change before we accept this PR?

[de-vri-es]

Right, will do. Any tips on how to come up with good limited values? Just visually?

[de-vri-es]

I reduced the limits to [-90, 180] degrees. This seemed to fit pretty good.

However, at -90 the collision meshes for link_u and link_l overlap, which looks messy. They're adjacent so it shouldn't matter for moveit, but it doesn't look nice. I will make a more detailed collision model for link_u so that it shows there is no collision in that state.

[de-vri-es]

Updated the collision models for link U and L. They don't overlap any more at 180 degrees (it wasn't -90) for joint U.

[de-vri-es]

So, there are at least two questions remaining:

• Does the coordinate system of the URDF match that of the robot?
• Do the the directions of rotation (positive/negative) of the joints in the URDF match those of the robot?

For that we need a real robot, or perhabs MotoSim will suffice.