How to read the Position of the end effector from ROS

[ORCelada]

We have been working with the driver with a YuMi for a while. We have found that if we introduce the joint states to the urdf (https://github.com/robberthofmanfm/yumi/tree/egm_modifications/yumi_description/urdf), the tf from the base to the last link doesn't quite match with the Position outputed by the Pendant (we are talking a few mm in each direction). Is there a way to use this driver to get the position and rotation that the Pendant shows to use in ROS?

[gavanderhoorn]

There is currently no direct support for publishing the Cartesian transform / pose of any link.

The underlying protobuf msgs do contain that information though IIRC, so with some work, it could be exposed by the RobotHW implementation. Besides that, a ros_control controller/broadcaster (new terminology) would need to be created which can publish that information in the form of a TF frame or geometry_msgs/Pose (I'd prefer the former).

Alternatively, if there'd be a way to export/get hold of the calibration data from the IRC5, we could consider supporting something similar to what Universal_Robots_ROS_Driver does: update the URDF (at runtime) with the information from that calibration data.

That would not require any changes to the driver proper, nor any new ros_control controllers/broadcasters.

[bhomaidan1990]

@gavanderhoorn As a consequence this means that we can't control the fingers of the smart gripper directly? Are we obliged to use the SGCommand service (with the delay) to control the fingers of the smart gripper? or there is a more elegant and faster approach? thanks in advance.

[gavanderhoorn]

@bhomaidan1990 I'm not sure I understand what you're asking.

@ORCelada was asking for a way to retrieve the Cartesian position of the TCP. That's different from what you are asking about.

[bhomaidan1990]

@gavanderhoorn I mean that we can't neither read the Position of the end effector (gripper fingers) nor set the position of the gripper fingers using this driver (except by using SG Command of RAPID)?

[gavanderhoorn]

I mean that we can't neither read the Position of the end effector (gripper fingers)

there might be some confusion here, but "end effector" to me means "the piece of hw that you can attach to the flange". The discussion above was about the base->tool0 transform (or any other transform used to represent the on-IRC5 configured and activated TCP).

abb_robot_driver does not make any Cartesian information available. The only thing published are JointState messages which are used with FK to produce the TF tree (by robot_state_publisher).

Note that the TCP is essentially unrelated to the EEF (as in: it's very much possible to have a TCP configured which does not lie anywhere near the actual EEF you have attached).

Having written that: as I wrote above; no, abb_robot_driver does not publish the Cartesian position of the TCP.

nor set the position of the gripper fingers using this driver

regardless of what I wrote above: this is something completely different. As it's not about the position of the TCP at all.

And AFAIK, you don't control the position of the fingers like you'd control the position of the TCP (using RAPID that is). Those are always controlled in a different way.

However: the readme of abb_rws_service_provider explains (here) that if you have support for the SmartGripper loaded on your IRC5, abb_rws_service_provider should expose the necessary services to control the gripper (here).

You'd use set_sg_command fi.

If you are asking for a "position control" interface for the SmartGripper -- like you have for the individual joints of YuMi -- I don't believe that exists (and IIRC, has been discussed before).

[bhomaidan1990]

@gavanderhoorn thanks for your detailed explanation, it is crystal clear now.