Add support package for YuMi (IRB 14000)

[gavanderhoorn]

The IRB 14000 has been around for quite some time, so we should add a support package for it to this repository.

I've already seen quite a nr of urdfs 'out there', so importing one of those is an option.

They would have to be adapted to follow ROS-Industrial conventions.

[kazoo-kmt]

I've seen several projects using ROS for YuMi (+ MoveIt!). Do you plan to include them in this package?
https://www.youtube.com/watch?v=z3qqP_NCGJ8
https://github.com/OrebroUniversity/yumi

[jontje]

A support package for YuMi is coming soon. Hopefully in 1-2 weeks.

[Rahtron3030]

is YuMi support still in the works?

[gavanderhoorn]

Yes. See ros-industrial/abb_experimental#66.

[robberthofmanfm]

I'm not sure where to post this, but I'd like to point out that different naming conventions are being used for the YuMi joints.

• In the pull request gavanderhoorn is referring to, as in https://github.com/kth-ros-pkg/yumi and https://github.com/OrebroUniversity/yumi, where it stems from, the naming convention is yumi_joint_1_l
• In ros-industrial/abb_robot_driver, in the controller configuration file, it is yumi_robl_joint_1, of which is said Joint names extracted from the ABB robot controller.

Does ABB have a naming convention for these joints?

[gavanderhoorn]

ABB's convention is just to incrementally number joints. So joint_1, joint_2, etc.

That's what abb_robot_driver is using, but as a YuMi is basically two robots joined together (literally), you need some way to identify the left and right joint_n. So they do that by prefixing the name of the unit (ie: robl in the example you give).

The yumi prefix is not something the controller uses internally afaik, but perhaps @jontje will correct me.

The PR you link to (from kth-ros-pkg) was opened long before abb_robot_driver was created, and kth-ros-pkg itself was created long before that. It's very likely -- and understandable -- for them to (have) use(d) different names for joints.

Unfortunately there still isn't an official support package for IRB 14000 robots. However, if we end up reusing the one in the referenced PR, the jointnames will most likely be updated to match what abb_robot_driver uses.

[robberthofmanfm]

Okay thanks, then yumi_robl_joint_1 makes more sense, since there's hierarchy in the name, as yumi contains robl contains joint_1. I hope other packages agree to that naming, since it impedes using these packages together.

ABB's convention is just to incrementally number joints. So joint_1, joint_2, etc.

Apparently in the IRB 14000 product specification on page 10, there's a diagram where ABB is not even following that convention, they've labeled the third joint with number 7. This is probably also why you find the joints defined in this order in the kth-ros-pkg, OrebroUniversity and the PR link.

[gavanderhoorn]

I hope other packages agree to that naming, since it impedes using these packages together.

I wouldn't count on it. As I wrote: abb_robot_driver is a pretty recent addition to the ROS ecosystem for ABB robots.

Apparently in the IRB 14000 product specification on page 10, there's a diagram where ABB is not even following that convention, they've labeled the third joint with number 7

I understand why you write that, but it's not correct.

A YuMi is two 7 dof robots combined, where each arm is essentially 6 dof + 1 extra joint. That extra joint is configured as joint_7. But that extra joint is in the third 'position' of the serial chain.

This is not that strange, as it allows reuse of existing software, documentation, and more importantly, experience of users (ie: "joint_6 is the one which connects the flange with the last link of the robot", which wouldn't work any more if we renumber everything).

Other OEMs do something similar: in Yaskawa's fi, the E joint is also the 7th in their 7 dof robots, but is in the 3rd position of the chain.

(note: I do not work for ABB, so my comment here is based on my understanding of ABB industrial robots and controllers. It could be incorrect)