Open gavanderhoorn opened 7 years ago
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
A support package for YuMi is coming soon. Hopefully in 1-2 weeks.
is YuMi support still in the works?
Yes. See ros-industrial/abb_experimental#66.
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.
yumi_joint_1_l
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?
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.
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.
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)
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.